idnits 2.17.00 (12 Aug 2021) /tmp/idnits56256/draft-srisuresh-ospf-te-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([OPQLSA-TE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 306: '...nfigurable network MUST have a minimum...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 319 has weird spacing: '...niquely ident...' == Line 643 has weird spacing: '...sources that ...' == Line 815 has weird spacing: '...bes the reach...' == Line 1365 has weird spacing: '...TE link ineff...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'OSPF-V2' is mentioned on line 342, but not defined == Missing Reference: 'MPLS-ARCH' is mentioned on line 146, but not defined == Missing Reference: 'OSPF-NSSA' is mentioned on line 342, but not defined == Missing Reference: 'BGP-OSPF' is mentioned on line 516, but not defined == Unused Reference: 'IETF-STD' is defined on line 1549, but no explicit reference was found in the text == Unused Reference: 'RFC 1700' is defined on line 1552, but no explicit reference was found in the text == Unused Reference: 'OSPF-FL2' is defined on line 1588, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1602 (ref. 'IETF-STD') (Obsoleted by RFC 2026) ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. 'MPLS-TE') == Outdated reference: draft-ietf-mpls-generalized-signaling has been published as RFC 3471 == Outdated reference: draft-ietf-mpls-rsvp-lsp-tunnel has been published as RFC 3209 == Outdated reference: draft-ietf-mpls-cr-ldp has been published as RFC 3212 ** Downref: Normative reference to an Historic RFC: RFC 1584 (ref. 'MOSPF') == Outdated reference: draft-ietf-ospf-nssa-update has been published as RFC 3101 ** Obsolete normative reference: RFC 2370 (ref. 'OPAQUE') (Obsoleted by RFC 5250) -- Possible downref: Non-RFC (?) normative reference: ref. 'OSPF-FL1' -- Possible downref: Non-RFC (?) normative reference: ref. 'OSPF-FL2' -- Possible downref: Non-RFC (?) normative reference: ref. 'OPQLSA-TE' Summary: 12 errors (**), 0 flaws (~~), 16 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Srisuresh 3 INTERNET-DRAFT P. Joseph 4 Expires as of December 25, 2001 Jasmine Networks 5 June, 2001 7 New TE LSAs to extend OSPF for Traffic Engineering 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet- Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 OSPF is a well established link state routing protocol used for 34 topology discovery and computing forwarding table based on 35 shortest-Path criteria. Traffic Engineering extensions (OSPF-TE) 36 will use criteria different from shortest-path so as to route 37 traffic around congestion paths and meet varying Service Level 38 agreements. OSPF-TE may also be used by non-IP networks such as 39 photonic and TDM (SONET/SDH) circuit switch networks for 40 light-path or TDM circuit setup between two end-points. The 41 approach outlined in this document differs from that of 42 [OPQLSA-TE]. The document does not suggest the use of Opaque LSAs 43 to add TE extensions to OSPF. Rather, new TE LSAs, modeled after 44 existing LSAs and flooding scope are proposed to overcome the 45 scaling limitations of the approach outlined in [OPQLSA-TE]. The 46 document draws a distinction between TE and non-TE topologies and 47 restricts flooding of TE LSAs into non-TE topology. The document 48 covers OSPF extensions for packet and non-packet networks alike, 49 providing a unified extension mechanism for all networks. As such, 50 this approach improves interoperability between peer network 51 elements. Lastly, the document specifies a transition path for 52 vendors currently using opaque LSAs to transition to using new 53 TE LSAs outlined here. 55 1. Introduction 57 There is substantial industry experience with deploying OSPF link 58 state routing protocol. That makes OSPF a good candidate to adapt for 59 traffic engineering purposes. The dynamic discovery of network 60 topology, flooding algorithm and the hierarchical organization of 61 areas can all be used effectively in creating and tearing traffic 62 links on demand. The intent of the document is to build an abstract 63 view of the topology in conjunction with the traffic engineering 64 characteristics of the nodes and links involved. 66 The connectivity topology may remain relatively stable, except when 67 the existing links or networking nodes go down or flap or new nodes 68 and links are added to the network. The objective of traffic 69 engineering is to set up circuit path(s) across a pair of nodes or 70 links, as the case may be, so as to forward traffic of a certain 71 forwarding equivalency class. Circuit emulation in a packet network 72 is accomplished by each MPLS intermediary node performing label 73 swapping. Whereas, circuit emulation in a TDM or Fiber cross-connect 74 network is accomplished by configuring the switch fabric in each 75 intermediary node to do the appropriate switching (TDM, fiber or 76 Lamda) for the duration of the circuit. 78 The objective of this document is not how to set up traffic circuits, 79 but rather provide the necessary TE parameters for the nodes and 80 links that constitute the TE topology. Unlike the traditional OSPF, 81 the TE extended OSPF will be used to build circuit paths, meeting 82 certain TE criteria. The only requirement is that end-nodes and/or 83 end-links of a circuit be identifiable with an IP address. For 84 non-IP networks (such as TDM or photonic cross connect networks), 85 Mapping IP addresses to a well-known name can be done through a 86 DNS-like mechanism. 88 The approach suggested in this document is different from the 89 Opaque-LSA-based approach outlined in [OPQLSA-TE]. Section 10 90 compares the two approaches and outlines a strategy to transition 91 from Opaque-LSA based deployments to the new-TE-LSA approach 92 outlined here. 94 2. Traffic Engineering 96 A traffic engineered circuit may be identified by the tuple of 97 (Forwarding Equivalency Class, TE parameters for the circuit, 98 Origin Node/Link, Destination node/Link). 100 The forwarding Equivalency class(FEC) may be constituted of a number 101 of criteria such as (a) Traffic arriving on a specific interface, 102 (b) Traffic meeting a certain classification criteria (ex: based on 103 fields in the IP and transport headers), (c) Traffic in a certain 104 priority class, (d) Traffic arriving on a specific set of TDM (STS) 105 circuits on an interface, (e) Traffic arriving on a certain 106 wave-length of an interface, (f) Traffic arriving at a certain time 107 of day, and so on. A FEC may be constituted as a combination of one 108 or more of the above criteria. Discerning traffic based on the FEC 109 criteria is a mandatory requirement on Label Edge Routers (LERs). 110 Traffic content is transparent to the Intermediate Label Switched 111 Routers (LSRs), once a circuit is formed. LSRs are simply 112 responsible for keeping the circuit in-tact for the lifetime of the 113 circuit(s). As such, this document will not address FEC or the 114 associated signaling to setup circuits. [MPLS-TE] and [GMPLS-TE] 115 address the FEC criteria. Whereas, [RSVP-TE] and [CR-LDP] address 116 different types of signaling protocols. 118 As for TE parameters for the circuit, this refers to the TE 119 parameters for all the nodes and links constituting a circuit. 120 Typically, TE parameters for a node in a TE circuit may include 121 the following. 123 * Traffic prioritization ability, 124 * Ability to provision bandwidth on interfaces, 125 * Support of CSPF algorithms, 126 * TE-Circuit switch type, 127 * Automatic protection switching. 129 TE parameters for the link include: 131 * Bandwidth availability, 132 * reliability of the link, 133 * color assigned to the link 134 * cost of bandwidth usage on the link. 135 * membership to a Shared Risk Link Group and so on. 137 Only the unicast paths circuit paths are considered here. Multicast 138 variations are currently considered out of scope for this document. 139 The requirement is that the originating as well as the terminating 140 entities of a TE path are identifiable by their IP address. 142 3. Terminology 144 Definitions for majority of the terms used in this document with 145 regard to OSPF protocol may be found in [OSPF-V2]. MPLS and traffic 146 engineering terms may be found in [MPLS-ARCH]. RSVP-TE and CR-LDP 147 signaling specific terms may be found in [RSVP-TE] and [CR-LDP] 148 respectively. 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 152 this document are to be interpreted as described in RFC 2119. 154 Below are definitions for the terms used within this document. 156 3.1. OSPF-TE router (or) TE-compliant OSPF router 158 This is a router that supports the OSPF TE extensions described 159 in this document. This requires that at least one of the links 160 attached to the router support TE extensions and, at least one of 161 the links attached to the router support Packet termination and 162 run the OSPF-TE protocol. 164 An OSPF-TE router supports native OSPF as well as the TE 165 extensions outlined here. 167 3.2. Native OSPF router 169 A native OSPF router is an OSPF router that does not support 170 the TE extensions described in this document. An autonomous 171 system could be constituted of a combination of native OSPF 172 routers and OSPF-TE routers. 174 A native OSPF router, when enhanced to include the extensions 175 described in this document can become a OSPF-TE router. 177 3.3. TE nodes vs. non-TE (bormal) nodes 179 A TE-Node is an intermediate or edge node taking part in the 180 traffic engineered (TE) network. Specifically, a TE circuit 181 is constituted of a series of TE nodes connected to each other 182 via the TE links. 184 A non-TE node or a normal node is a node that does not have any 185 TE links attached to it and does not take part in a TE network. 186 Specifically, native OSPF-nodes that do not take part in a TE 187 network fall under this category. 189 3.4. TE links vs. non-TE (normal) links 191 A TE Link is a network attachment that supports traffic 192 engineering. Specifically, a TE circuit can only be setup using 193 a combination of TE nodes and TE links connected to each other. 195 Non-TE links or a normal link is one that that does not 196 support traffic engineering. For example, native OSPF protocol 197 and least cost criteria may be used to determine reachability 198 of subnets in a network constituted of normal OSPF nodes and 199 normal OSPF links. 201 3.5. Packet interface vs. non-packet interface 203 Interfaces on an OSPF-TE router may be characterized as those 204 that can terminate (i.e., send and receive) IP packet data and 205 those that can not. Both types of links can be part of a 206 traffic engineered network. In contrast, a native OSPF router 207 does not support non-packet interfaces. 209 Needless to say, the OSPF protocol and its TE extensions can only 210 be enabled on interfaces supporting IP packet termination. 212 3.6. TE topology vs. non-TE topology 214 A TE topology is constituted of a set of contiguous TE nodes and 215 TE links. Associated with each TE node and TE link is a set of TE 216 criteria that may be supported at any given time. A TE topology 217 allows circuits to be overlayed statically or dynamically based 218 on a specific TE criteria. 220 A non-TE topology specifically refers to the network that does not 221 support TE. Control protocols such as OSPF may be run on the non-TE 222 topology. IP forwarding table used to forward IP packets on this 223 network is built based on the control protocol specific algorithm, 224 such as OSPF shortest-path criteria. 226 3.7. TLV 228 A TLV, strictly stands for an object in the form of Tag-Length-Value. 229 However, this term is also used in the document, at times, to simply 230 refer a Traffic Engineering attribute of a TE-node or TE-link. 232 All TLVs are assumed to be of the following format, unless specified 233 otherwise. The Tag and length are 16 bits wide each. The length 234 includes the 4 bytes required for Tag and Length specification. 236 0 1 2 3 237 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Tag | Length (4 or more) | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Value .... | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | .... | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 3.8. Router-TE TLVs 248 TLVs used to describe the TE capabilities of a TE-node. 250 3.9. Link-TE TLVs 252 TLVs used to describe the TE capabilities of a TE-link. 254 4. Motivation and Implicit assumptions for the TE extensions 256 The motivation behind the OSPF-TE described in this document is to 257 dynamically discover the TE-network topology, devise a scalable 258 flooding methodology and benefit from the hierarchical area 259 organization and other techniques of the native OSPF. The result 260 would be the ability to build an abstract view of a network 261 topology with all the traffic engineering characteristics. 263 With traditional OSPF, the goal is to build a forwarding table to 264 reach various subnets in the IP network with least-cost as the 265 basis. However, the goal of OSPF-TE is to determine a circuit path 266 (that can be pinned-down for a desired duration) meeting a certain 267 set of traffic engineering criteria. Further, the circuit path 268 could consist entirely of nodes and links that do not carry IP 269 traffic. 271 The following assumptions are made throughout the document for 272 the discussion of OSPF-TE. 274 1. Interfaces on an OSPF-TE router may be characterized as those 275 that can terminate (i.e., send and receive) IP packet data and 276 those that wont. Both types of links can be part of a traffic 277 engineered network. Needless to say, the OSPF-TE protocol can 278 only be enabled on interfaces that support IP packet data 279 termination. And, TE LSAs may be exchanged over non-TE links. 281 2. Unlike traditional OSPF, OSPF-TE protocol must be capable of 282 advertising link state of interfaces that are not capable of 283 handling packet data. As such, the OSPF-TE protocol cannot be 284 required to synchronize its link-state database with neighbors 285 across all its links. It is sufficient to synchronize 286 link-state database in an area, across a subset of the links - 287 say, the packet terminating interfaces. Yet, the TE LSDB 288 (LSA database) should be synchronized across all OSPF-TE nodes 289 within an area. 291 All interfaces or links described by the TE LSAs will be 292 present in the TE topology database (a.k.a. TE LSDB). 294 3. An OSPF-TE router with links in an OSPF area will need to 295 establish router adjacency with at least one other OSPF-TE 296 neighboring router in order for the router's database to be 297 synchronized with other routers in the area. Failing this, the 298 OSPF router will not be in the TE calculations of other TE 299 routers in the area. Refer [OSPF-FL1] for flooding 300 optimizations. 302 However, two routers that are physically connected to the same 303 link (or broadcast network) neednt be router adjacent via the 304 Hello protocol, if the link is not packet terminated. 306 4. Each IP subnet on a TE-configurable network MUST have a minimum 307 of one node with an interface running OSPF-TE protocol. This is 308 despite the fact that all nodes on the subnet may take part in 309 Traffic Engineering. (Example: SONET/SDH TDM ring with a single 310 Gateway Network Element, a.k.a. GNE running the OSPF protocol, 311 yet all other nodes in the ring are also full members of a TE 312 circuit). 314 An OSPF-TE node may advertise more than itself and the links 315 it is directly attached to. It may also advertise other TE 316 participants and their links, on their behalf. 318 5. As a general rule, all nodes and links that may be party 319 to a TE circuit should be uniquely identifiable by an IP 320 address. As for router ID, a separate loopback IP address 321 for the router, independent of the links attached, is 322 recommended. 324 6. TE nodes may have 2 types of link state databases - a normal 325 LSDB and a TE-LSDB. A normal LSDB, constituted of non-TE 326 links and nodes attached to these links(i.e., non-TE as well 327 as TE nodes), will use shortest-path criteria to forward IP 328 packets over normal non-TE links. The TE-LSDB, constituted 329 of TE nodes and TE links, may be used to setup TE circuit 330 paths along the TE topology. 332 5. The OSPF Options field 334 A new TE flag is introduced to identify TE extensions to the OSPF. 335 With this, the OSPF v2 will have no more reserved bits left for 336 future option extensions. This bit will be used to distinguish 337 between routers that support Traffic engineering extensions and 338 those that do not. 340 The OSPF options field is present in OSPF Hello packets, Database 341 Description packets and all link state advertisements. See 342 [OSPF-V2], [OSPF-NSSA] and [OPAQUE] for a description of the 343 bits in options field. Only the TE-Bit is described in this 344 section. 346 -------------------------------------- 347 |TE | O | DC | EA | N/P | MC | E | * | 348 -------------------------------------- 350 The OSPF options field - TE support 352 TE-Bit: This bit is set to indicate support for Traffic Engineering 353 extensions to the OSPF. The Hello protocol which is used for 354 establishing router adjacency and bidirectionality of the 355 link will use the TE-bit to build adjacencies between two 356 nodes that are either both TE-compliant or not. Two routers 357 will not become TE-neighbors unless they agree on the state 358 of the TE-bit. TE-compliant OSPF extensions are advertised 359 only to the TE-compliant routers. All other routers may 360 simply ignore the advertisements. 362 6. Bringing up TE adjacencies; TE vs. Non-TE topologies 364 OSPF creates adjacencies between neighboring routers for the purpose 365 of exchanging routing information. In the following subsections, we 366 describe the use of Hello protocol to establish TE capability 367 compliance between neighboring routers of an area. Further, the 368 capability is used as the basis to build a TE vs. non-TE network 369 topology. 371 6.1. The Hello Protocol 373 The Hello Protocol is primarily responsible for dynamically 374 establishing and maintaining neighbor adjacencies. In a TE network, 375 it may not be required or possible for all links and neighbors to 376 establish adjacency using this protocol. 378 The Hello protocol will use the TE-bit to establish Traffic 379 Engineering capability (or not) between two OSPF routers. 381 For NBMA and broadcast networks, this protocol is responsible for 382 electing the designated router and the backup designated router. 383 For a TDM ring network, the designated and backup designated 384 routers may either be preselected (ex: GNE, backup-GNE) or 385 determined via the same Hello protocol. In any case, routers 386 supporting the TE option shall be given a higher precedence 387 for becoming a designated router over those that donot support TE. 389 6.2. Flooding and the Synchronization of Databases 391 In OSPF, adjacent routers within an area must synchronize their 392 databases. However, as observed in [OSPF-FL1], the requirement 393 may be stated more concisely that all routers in an area must 394 converge on the same link state database. To do that, it suffices 395 to send single copies of LSAs to the neighboring routers in an 396 area, rather than send one copy on each of the connected 397 interfaces. [OSPF-FL1] describes in detail how to minimize 398 flooding (Initial LSDB synchronization as well as the 399 asynchronous LSA updates) within an area. 401 With the OSPF-TE described here, a TE-only network topology is 402 constructed based on the TE option flag in the Hello packet. 403 Subsequent to that, TE LSA flooding in an area is limited to 404 TE-only routers in the area, and do not impact non-TE routers 405 in the area. A network may be constituted of a combination of 406 a TE topology and a non-TE (control) topology. Standard IP 407 packet forwarding and routing protocols are possible along the 408 control topology. 410 In the case where some of the neighbors are TE compliant and 411 others are not, the designated router will exchange different 412 sets of LSAs with its neighbors. TE LSAs are exchanged only 413 with the TE neighbors. Normal LSAs do not include description 414 for TE links. As such, normal LSAs are exchanged with all 415 neighbors (TE and non-TE alike) over a shared non-TE link. 417 Flooding optimization in a TE network is essential 418 for two reasons. First, the control traffic for a TE network is 419 likely to be much higher than that of a non-TE network. Flooding 420 optimizations help to minimize the announcements and the 421 associated retransmissions and acknowledgements on the network. 422 Secondly, the TE nodes need to converge at the earliest to keep 423 up with TE state changes occuring throughout the TE network. 425 This process of flooding along a TE topology cannot be folded 426 into the Opaque-LSA based TE scheme ([OPQLSA-TE]), because 427 Opaque LSAs (say, LSA #10) have a pre-determined flooding 428 scope. Even as a TE topology is available from the use of 429 TE option flag, the TE topology is not usable for flooding 430 unless a new TE LSA is devised, whose boundaries can be set to 431 span the TE-only routers in an area. 433 NOTE, a new All-SPF-TE Multicast address may be used for the 434 exchange of TE compliant database descriptors. 436 6.3. The Designated Router 438 The Designated Router is elected by the Hello Protocol on broadcast 439 and NBMA networks. In general, when a router's interface to a 440 network first becomes functional, it checks to see whether there is 441 currently a Designated Router for the network. If there is, it 442 accepts that Designated Router, regardless of its Router Priority, 443 so long as the current designated router is TE compliant. Otherwise, 444 the router itself becomes Designated Router if it has the highest 445 Router Priority on the network and is TE compliant. 447 Clearly, TE-compliance must be implemented on the most robust 448 routers only, as they become most likely candidates to take on 449 additional role as designated router. 451 Alternatively, there can be two sets of designated routers, one for 452 the TE compliant routers and another for the native OSPF routers 453 (non-TE compliant). 455 6.4. The Backup Designated Router 457 The Backup Designated Router is also elected by the Hello 458 Protocol. Each Hello Packet has a field that specifies the 459 Backup Designated Router for the network. Once again, TE-compliance 460 must be weighed in conjunction with router priority in determining 461 the backup designated router. Alternatively, there can be two sets 462 of backup designated routers, one for the TE compliant routers and 463 another for the native OSPF routers (non-TE compliant). 465 6.5. The graph of adjacencies 467 An adjacency is bound to the network that the two routers have 468 in common. If two routers have multiple networks in common, 469 they may have multiple adjacencies between them. The adjacency 470 may be split into two different types - Adjacency between 471 TE-compliant routers and adjacency between non-TE compliant 472 routers. A router may choose to support one or both types of 473 adjacency. 475 Two graphs are possible, depending on whether a Designated 476 Router is elected for the network. On physical point-to-point 477 networks, Point-to-MultiPoint networks and virtual links, 478 neighboring routers become adjacent whenever they can 479 communicate directly. The adjacency can only be one of 480 (a) TE-compliant or (b) non-TE compliant. In contrast, on 481 broadcast and NBMA networks the Designated Router and the 482 Backup Designated Router may maintain two sets of adjacency. 483 However, the remaining routers will participate in either 484 TE-compliant adjacency or non-TE-compliant adjacency, but not 485 both. In the Broadcast network below, you will notice that 486 routers RT7 and RT3 are chosen as the designated and backup 487 routers respectively. Within the network, Routers RT3, RT4 488 and RT7 are TE-compliant. RT5 and RT6 are not. So, you will 489 notice the adjacency variation with RT4 vs. RT5 or RT6. 491 +---+ +---+ 492 |RT1|------------|RT2| o---------------o 493 +---+ N1 +---+ RT1 RT2 495 RT7 496 o:::::::::: 497 +---+ +---+ +---+ /|: : 498 |RT7| |RT3| |RT4| / | : : 499 +---+ +---+ +---+ / | : : 500 | | | / | : : 501 +-----------------------+ RT5o RT6o oRT4 : 502 | | N2 * * ; : 503 +---+ +---+ * * ; : 504 |RT5| |RT6| * * ; : 505 +---+ +---+ **; : 506 o:::::::::: 507 RT3 509 Figure 6: The graph of adjacencies with TE-compliant routers. 511 7. New TE LSAs 513 The native OSPF protocol has a total of 11 LSA types. Definitions 514 for LSA types 1 through 5 may be found in [OSPF-v2]. LSA type 6 is 515 defined in [MOSPF]. LSA type 7 definition may be found in [NSSA]. 516 LSA type 8 may be found in [BGP-OSPF]. Lastly, LSA types 9 through 517 11 are defined in [OPAQUE]. 519 Each of the LSA types defined are different in content and flooding 520 scope. For instance, Opaque LSA types 9 through 11 are general 521 purpose LSAs, with flooding scope set to link-local, area-local and 522 AS-wide (except into stub areas) respectively. As will become 523 apparent soon, the boundaries for Opaque LSAs are not appropriate 524 for flooding TE data. 526 In the following subsections, we define new LSAs for Traffic 527 engineering use. The new TE LSAs are largely modeled after the 528 existing LSAs for content format and flooding scope. The LSA types 529 are assigned such that the high bit of the LS-type octet is set 530 to 1. Standard link-state database flooding mechanisms (with 531 optimizations discussed in previous sections) are used for 532 distribution of TE LSAs along the TE-restricted topology. The 533 flooding scope is also defined for each of the newly defined TE 534 LSAs. 536 7.1. TE-Router LSA 538 Router LSAs are Type 1 LSAs. The TE-router LSA is modeled after the 539 router LSA with the same flooding scope as the router-LSA, except 540 that the scope is further restricted to TE-only nodes within the 541 area. A value of 0x81 is assigned to TE-router LSA. The TE-router 542 LSA describes the router-TE metrics as well as the link-TE metrics 543 of the TE links attached to the router. Below is the format of the 544 TE-router LSA. Unless specified explicitly otherwise, the fields 545 carry the same meaning as they do in a router LSA. Only the 546 differences are explained below. 548 0 1 2 3 549 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | LS age | Options | 0x81 | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Link State ID | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Advertising Router | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | LS sequence number | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | LS checksum | length | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | 0 |V|E|B| 0 | Router-TE flags | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Router-TE flags (contd.) | Router-TE TLVs | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | .... | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | .... | # of TE links | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Link ID | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Link Data | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Type | 0 | Link-TE flags | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Link-TE flags (contd.) | Zero or more Link-TE TLVs | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Link ID | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Link Data | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | ... | 583 Option 584 In TE-capable router nodes, the TE-compliance bit is set to 1. 586 Router-TE flags field (TE capabilities of the router node) 588 Below is an initial set of definitions. More may be standardized 589 if necessary. The TLVs are not expanded in the current rev. Will 590 be done in the follow-on revs. The field imposes a restriction 591 of no more than 32 flags to describe the TE capabilities of a 592 router-TE. 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 |L|L|P|T|L|F| |S|S|S|C| 596 |S|E|S|D|S|S| |T|E|I|S| 597 |R|R|C|M|C|C| |A|L|G|P| 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| 601 Bit LSR 602 When set, the router is considered to have LSR capability. 604 Bit LER 605 When set, the router is considered to have LER capability. 606 All MPLS border routers will be required to have the LER 607 capability. When the E bit is also set, that indicates an 608 AS Boundary router with LER capability. When the B bit is 609 also set, that indicates an area border router with LER 610 capability. 612 Bit PSC 613 Indicates the node is Packet Switch Capable. 615 Bit TDM 616 Indicates the node is TDM circuit switch capable. 618 Bit LSC 619 Indicates the node is Lamda switch Capable. 621 Bit FSC 622 Indicates the node is Fibre (can also be a non-fibre link 623 type) switch capable. 625 Bit STA 626 Label Stack Depth limit TLV follows. This is applicable only 627 when the PSC flag is set. 629 Bit SEL 630 TE Selection Criteria TLV, supported by the router, follows. 632 Bit SIG 633 MPLS Signaling protocol support TLV follows. 635 BIT CSPF 636 CSPF algorithm support TLV follows. 638 Router-TE TLVs 639 The following Router-TE TLVs are defined. 641 TE-selection-Criteria TLV (Tag ID = 1) 643 The values can be a series of resources that may be used 644 as the criteria for traffic engineering (typically with the 645 aid of a signaling protocol such as RSVP-TE or CR-LDP or LDP). 647 - Bandwidth based LSPs (1) 648 - Priority based LSPs (2) 649 - Backup LSP (3) 650 - Link cost (4) 652 Bandwidth criteria is often used in conjunction with Packet 653 Switch Capable nodes. The unit of bandwidth permitted to be 654 configured may however vary from vendor to vendor. Bandwidth 655 criteria may also be used in conjunction with TDM nodes. Once 656 again, the granularity of bandwidth allocation may vary from 657 vendor to vendor. 659 Priority based traffic switching is relevant only to Packet 660 Switch Capable nodes. Nodes supporting this criteria will 661 be able to interpret the EXP bits on the MPLS header to 662 prioritize the traffic across the same LSP. 664 Backup criteria refers to whether or not the node is capable 665 of finding automatic protection path in the case the 666 originally selected link fails. Such a local recovery is 667 specific to the node and may not need to be notified to the 668 upstream node. 670 MPLS-Signaling protocol TLV (Tag ID = 3) 671 The value can be 2 bytes long, listing a combination of 672 RSVP-TE, CR-LDP and LDP. 674 Constraint-SPF algorithms-Support TLV (Tag ID = 4) 675 List all the CSPF algorithms supported. Support for CSPF 676 algorithms on a node is an indication that the node may be 677 requested for all or partial circuit path selection during 678 circuit setup time. Further, the CSPF algorithm support on 679 an intermediate node can be beneficial when the node 680 terminates one or more of the hierarchical LSP tunnels. 682 Label Stack Depth TLV (Tag ID = 5) 683 Applicable only for PSC-Type traffic. A default value of 1 684 is assumed. This indicates the depth of label stack the 685 node is capable of processing on an ingress interface. 687 The following fields are used to describe each router link (i.e., 688 interface). Each router link is typed (see the below Type field). 689 The Type field indicates the kind of link being described. 691 Type 692 A new link type "Positional-Ring Type" (value 5) is defined. 693 This is essentially a connection to a TDM-Ring. TDM ring network 694 is different from LAN/NBMA transit network in that, nodes on the 695 TDM ring donot necessarily have a terminating path between 696 themselves. Secondly, the order of links is important in 697 determining the circuit path. Third, the protection switching 698 and the number of fibers from a node going into a ring are 699 determined by the ring characteristics. I.e., 2-fibre vs 700 4-fibre ring and UPSR vs BLSR protected ring. 702 Type Description 703 __________________________________________________ 704 1 Point-to-point connection to another router 705 2 Connection to a transit network 706 3 Connection to a stub network 707 4 Virtual link 708 5 Positional-Ring Type. 710 Link ID 711 Identifies the object that this router link connects to. 712 Value depends on the link's Type. For a positional-ring type, 713 the Link ID shall be IP Network/Subnet number, just as with a 714 broadcast transit network. The following table summarizes the 715 updated Link ID values. 717 Type Link ID 718 ______________________________________ 719 1 Neighboring router's Router ID 720 2 IP address of Designated Router 721 3 IP network/subnet number 722 4 Neighboring router's Router ID 723 5 IP network/subnet number 725 Link Data 726 This depends on the link's Type field. For type-5 links, this 727 specifies the router interface's IP address. 729 Link-TE options (TE capabilities of a link) 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 |T|N|P|T|L|F|D| |S|L|B|C| 733 |E|T|K|D|S|S|B| |R|U|W|O| 734 | |E|T|M|C|C|S| |L|G|A|L| 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| 738 TE - Indicates whether TE is permitted on the link. A link 739 can be denied for TE use by setting the flag to 0. 741 NTE - Indicates whether non-TE traffic is permitted on the 742 TE link. This flag is relevant only when the TE 743 flag is set. 745 PKT - Indicates whether or not the link is capable of 746 packet termination. 748 TDM, LSC, FSC bits 749 - Same as defined for router TE options. 751 DBS - Indicates whether or not Database synchronization 752 is permitted on this link. 754 SRLG Bit - Shared Risk Link Group TLV follows. 756 LUG bit - Link usage cost metric TLV follows. 758 BWA bit - Data Link bandwidth TLV follows. 760 COL bit - Data link Color TLV follows. 762 Link-TE TLVs 764 SRLG-TLV 765 This describes the list of Shared Risk Link Groups the link 766 belongs to. Use 2 bytes to list each SRLG. 768 BWA-TLV 769 This indicates the maximum bandwidth, available bandwidth, 770 reserved bandwidth for later use etc. This TLV may also 771 describe the Data link Layer protocols supported and the 772 Data link MTU size. 774 LUG-TLV 775 This indicates the link usage cost - Bandwidth unit, Unit 776 usage cost, LSP setup cost, minimum and maximum durations 777 permitted for setting up the TLV etc., including any time 778 of day constraints. 780 COLOR-TLV 781 This is similar to the SRLG TLV, in that an autonomous 782 system may choose to issue colors to link based on a 783 certain criteria. This TLV can be used to specify the 784 color assigned to the link within the scope of the AS. 786 7.2. Changes to Network LSAs 788 Network-LSAs are the Type 2 LSAs. With the exception of the 789 following, no additional changes will be required to this LSA 790 for TE compatibility. The LSA format and flooding scope 791 remains unchanged. 793 A network-LSA is originated for each broadcast, NBMA and 794 Positional-Ring type network in the area which supports two or 795 more routers. The TE option is also required to be set while 796 propagating the TDM network LSA. 798 7.2.1. Positional-Ring type network LSA - New Network type for TDM-ring. 799 - Ring ID: (Network Address/Mask) 800 - No. of elements in the ring (a.k.a. ring neighbors) 801 - Ring Bandwidth 802 - Ring Protection (UPSR/BLSR) 803 - ID of individual nodes (Interface IP address) 804 - Ring type (2-Fibre vs. 4-Fibre, SONET vs. SDH) 806 Network LSA will be required for SONET RING. Unlike the broadcast 807 type, the sequence in which the NEs are placed on a RING-network 808 is pertinent. The nodes in the ting must be described clock wise, 809 assuming the GNE as the starting element. 811 7.3. TE-Summary LSAs 813 TE-Summary-LSAs are the Type 0x83 and 0x84 LSAs. These LSAs are 814 originated by area border routers. TE-Summary-network-LSA (0x83) 815 describes the reachability of TE networks in a non-backbone 816 area, advertised by the Area Border Router. Type 0x84 817 summary-LSA describes the reachability of Area Border Routers 818 and AS border routers and their TE capabilities. 820 One of the benefits of having multiple areas within an AS is 821 that frequent TE advertisements within the area donot impact 822 outside the area. Only the TE abstractions as befitting the 823 external areas are advertised. 825 7.3.1. TE-Summary Network LSA (0x83) 827 TE-summary network LSA may be used to advertise reachability of 828 TE-networks accessible to areas external to the originating 829 area. The scope of flooding is AS wide, with the exception of 830 the originating area and the stub areas. For example, the 831 TE-summary network LSA advertised by the border router of a 832 non-backbone area is readvertised to all other areas, not just 833 the backbone area. The area border router for each 834 non-backbone area is responsible for advertising the 835 reachability of backbone networks into the area. 837 The flooding scope of TE-summary network LSA is unlike that 838 of the summary network LSA (type 0x03), which simply uses this 839 as an inter-area exchange of network accessibility and limits 840 the flooding scope to just the backbone area. 842 0 1 2 3 843 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | LS age | Options | 0x83 | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Link State ID (IP Network Number) | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Advertising Router (Area Border Router) | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | LS sequence number | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | LS checksum | length | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Network Mask | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Area-ID | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 7.3.2. TE-Summary router LSA (0x84) 863 TE-summary router LSA may be used to advertise the availability of 864 Area Border Routers (ABRs) and AS Border Routers (ASBRs) that are 865 TE capable. The TE-summary router LSAs are originated by the Area 866 Border Routers. The scope of flooding for the TE-summary router LSA 867 is the entire AS, with the exception of the non-backbone areas the 868 advertising ABRs belong to. 870 0 1 2 3 871 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | LS age | Options | 0x84 | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | Link State ID | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Advertising Router (ABR) | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | LS sequence number | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | LS checksum | length | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | 0 |E|B| 0 | No. of Areas | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Area-ID | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | ... | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | Router-TE flags | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Router-TE TLVs | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | .... | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 Link State ID 897 The ID of the Area border router or the AS border router whose 898 TE capability is being advertised. 900 Advertising Router 901 The ABR that advertises its TE capabilities (and the OSPF areas 902 it belongs to) or the TE capabilities of an ASBR within one of 903 the areas the ABR is a border router of. 905 No. of Areas 906 Specifies the number of OSPF areas the link state ID belongs to. 908 Area-ID 909 Specifies the OSPF area(s) the link state ID belongs to. When 910 the link state ID is same as the advertising router ID, this 911 lists all the areas the ABR belongs to. In the case the 912 link state ID is an ASBR, this simply lists the area the 913 ASBR belongs to. The advertising router is assumed to be the 914 ABR from the same area the ASBR is located in. 916 Summary-router-TE flags 918 Bit E - When set, the advertised Link-State ID is an AS boundary 919 router (E is for external). The advertising router and 920 the Link State ID belong to the same area. 922 Bit B - When set, the advertised Link state ID is an Area 923 border router (B is for Border) 925 Router-TE flags, 926 Router-TE TLVs (TE capabilities of the link-state-ID router) 928 TE Flags and TE TLVs are as applicable to the ABR/ASBR 929 specified in the link state ID. The semantics is same as 930 specified in the Router-TE LSA. 932 7.4. TE-AS-external LSAs (0x85) 934 TE-AS-external-LSAs are the Type 0x85 LSAs. This is modeled after 935 AS-external LSA format and flooding scope. These LSAs are originated 936 by AS boundary routers with TE extensions (say, a BGP node which can 937 communicate MPLS labels across to external ASes), and describe 938 networks and pre-engineered TE links external to the AS. The 939 flooding scope of this LSA is similar to that of an AS-external LSA. 940 I.e., AS wide, with the exception of stub areas. 942 0 1 2 3 943 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | LS age | Options | 0x85 | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | Link State ID | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Advertising Router | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | LS sequence number | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | LS checksum | length | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | Network Mask | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Forwarding address | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | External Route Tag | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | # of Virtual TE links | 0 | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Link-TE flags | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | Link-TE TLVs | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | ... | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | TE-Forwarding address | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | External Route TE Tag | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | ... | 975 Network Mask 976 The IP address mask for the advertised TE destination. For 977 example, this can be used to specify access to a specific 978 TE-node or TE-link with an mask of 0xffffffff. This can also 979 be used to specify access to an aggregated set of destinations 980 using a different mask, ex: 0xff000000. 982 Link-TE flags, 983 Link-TE TLVs 984 The TE attributes of this route. These fields are optional and 985 are provided only when one or more pre-engineered circuits can 986 be specified with the advertisement. Without these fields, 987 the LSA will simply state TE reachability info. 989 Forwarding address 990 Data traffic for the advertised destination will be forwarded to 991 this address. If the Forwarding address is set to 0.0.0.0, data 992 traffic will be forwarded instead to the LSA's originator (i.e., 993 the responsible AS boundary router). 995 External Route Tag 996 A 32-bit field attached to each external route. This is not 997 used by the OSPF protocol itself. It may be used to communicate 998 information between AS boundary routers; the precise nature of 999 such information is outside the scope of this specification. 1001 7.5. TE-Circuit-paths LSA (0x8C) 1003 TE-Circuit-paths LSA may be used to advertise the availability of 1004 pre-engineered TE circuit path(s) originating from any router in 1005 the network. The flooding scope may be Area wide or AS wide. 1007 0 1 2 3 1008 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | LS age | Options | 0x84 | 1011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1012 | Link State ID | 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | Advertising Router | 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 | LS sequence number | 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | LS checksum | length | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | 0 |S|E|B| 0 | # of TE circuit paths | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | TE-Link ID | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | TE-Link Data | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | Type | 0 | Link-TE flags | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | Link-TE flags (contd.) | Zero or more Link-TE TLVs | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | TE-Link ID | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | TE-Link Data | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | ... | 1036 Link State ID 1037 The ID of the router to which the TE circuit path(s) is being 1038 advertised. 1040 TE-circuit-path(s) flags 1042 Bit S - When set, the flooding scope is set to be AS wide. 1043 Otherwise, the flooding scope is set to be area wide. 1045 Bit E - When set, the advertised Link-State ID is an AS boundary 1046 router (E is for external). The advertising router and 1047 the Link State ID belong to the same area. 1049 Bit B - When set, the advertised Link state ID is an Area border 1050 router (B is for Border) 1052 No. of Virtual TE Links 1053 This indicates the number of pre-engineered TE links between the 1054 advertising router and the router specified in the link state ID. 1056 TE-Link ID 1057 This is the ID by which to identify the virtual link on the 1058 advertising router. This can be any private interface index or 1059 handle that the advertising router uses to identify the 1060 pre-engineered TE virtual link to the ABR/ASBR. 1062 TE-Link Data 1063 This specifies the IP address of the physical interface 1064 on the advertising router. 1066 7.6. TE-Link-Update LSA (0x8d) 1068 A significant difference between a non-TE OSPF network and a TE OSPF 1069 network is that the latter is subject to dynamic circuit pinning and 1070 is more likely to undergo state updates. Specifically, some links 1071 might undergo more changes and more frequently than others. 1072 Advertising the entire TE-router LSA in response to a change in any 1073 single link could be repetitive. Flooding the network with TE-router 1074 LSAs at the aggregated speed of all the dynamic changes is simply 1075 not desirable. Hence, the new TE-link-update LSA, that advertises 1076 link specific updates alone. 1078 The TE-link-Update LSA will be advertised as frequently as the link 1079 state is changed. The TE-link sequence is largely the advertisement 1080 of a sub-portion of router LSA. The sequence number on this will be 1081 incremented with the TE-router LSA's sequence as the basis. When an 1082 updated TE-router LSA is advertised within 30 minutes of the 1083 previous advertisement, the updated TE-router LSA will assume a 1084 sequence no. that is larger than the most frequently updated of 1085 its links. 1087 Below is the format of the TE-link update LSA. 1089 0 1 2 3 1090 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | LS age | Options | 0x8d | 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 | Link State ID (same as Link ID) | 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1096 | Advertising Router | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1098 | LS sequence number | 1099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1100 | LS checksum | length | 1101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 | Link Data | 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | Type | 0 | Link-TE options | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | Link-TE options | Zero or more Link-TE TLVs | 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | # TOS | metric | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 | ... | 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 | TOS | 0 | TOS metric | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 Link State ID 1116 This would be exactly the same as would have been specified as 1117 as Link ID for a link within the router-LSA. 1119 Link Data 1120 This specifies the router ID the link belongs to. In majority of 1121 cases, this would be same as the advertising router. 1123 The tuple of (LS Type, LSA ID, Advertising router) uniquely identify 1124 the LSA and replace LSAs of the same tuple with an older sequence 1125 number. However, there is an exception to this rule in the context 1126 of TE-link-update LSA. TE-Link update LSA will initially assume the 1127 sequence number of the TE-router LSA it belongs to. Further, 1128 when a new TE-router LSA update with a larger sequence number is 1129 advertised, the newer sequence number is assumed by al the link 1130 LSAs. 1132 7.7. TE-Router-Proxy LSA (0x8e) 1134 This is a variation to the TE-router LSA in that the TE-router LSA 1135 is not advertised by the network element, but rather by a trusted 1136 TE-router Proxy. This is typically the scenario in a non-packet 1137 TE network, where some of the nodes donot have OSPF functionality 1138 and count on a helper node to do the advertisement for them. One 1139 such example would be the SONET/SDH ADM nodes in a TDM ring. The 1140 nodes may principally depend upon the GNE (Gateway Network Element) 1141 to do the advertisement for them. TE-router-Proxy LSA shall not be 1142 used to advertise Area Border Routers and/or AS border Routers. 1144 0 1 2 3 1145 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 | LS age | Options | 0x8e | 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 | Link State ID (Router ID of the TE Network Element) | 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | Advertising Router | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | LS sequence number | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | LS checksum | length | 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 | 0 | Router-TE flags | 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | Router-TE flags (contd.) | Router-TE TLVs | 1160 +---------------------------------------------------------------+ 1161 | .... | 1162 +---------------------------------------------------------------+ 1163 | .... | # of TE links | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1165 | Link ID | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 | Link Data | 1168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1169 | Type | 0 | Link-TE options | 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 | Link-TE flags | Zero or more Link-TE TLVs | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 | Link ID | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 | Link Data | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | ... | 1179 8. Abstract topology representation with TE support 1181 Below, we assume a TE network that is composed of three OSPF areas, 1182 namely Area-1, Area-2 and Area-3, attached together through the 1183 backbone area. The following figure is an inter-area topology 1184 abstraction from the perspective of routers in Area-1. The 1185 abstraction is similar, but not the same, as that of the non-TE 1186 abstraction. As such, the authors claim the model is easy to 1187 understand and emulate. The abstraction illustrates reachability 1188 of TE networks and nodes in areas external to the local area and 1189 ASes external to the local AS. The abstraction also illustrates 1190 pre-engineered TE links that may be advertised by ABRs and ASBRs. 1192 Area-1 an has a single border router, ABR-A1 and no ASBRs. Area-2 1193 has an Area border router ABR-A2 and an AS border router ASBR-S1. 1194 Area-3 has two Area border routers ABR-A2 and ABR-A3; and an AS 1195 border router ASBR-S2. There may be any number of Pre-engineered 1196 TE links amongst ABRs and ASBRs. The following example assumes a 1197 single TE-link between ABR-A1 and ABR-A2; between ABR-A1 and 1198 ABR-A3; between ABR-A2 to ASBR-S1; and between ABR-A3 to ASBR-S2. 1199 All Area border routers and AS border routers are assumed to 1200 be represented by their TE capabilities. 1202 +-------+ 1203 |Area-1 | 1204 +-------+ 1205 +-------------+ | 1206 |Reachable TE | +------+ 1207 |networks in |--------|ABR-A1| 1208 |backbone area| +------+ 1209 +-------------+ | | | 1210 +-------------+ | +-------------------+ 1211 | | | 1212 +-----------------+ | +-----------------+ 1213 |Pre-engineered TE| +----------+ |Pre-engineered TE| 1214 |circuit path(s) | | Backbone | |circuit path(s) | 1215 |to ABR-A2 | | Area | |to ABR-A3 | 1216 +-----------------+ +----------+ +-----------------+ 1217 | | | | 1218 +----------+ | | | 1219 | | +--------------+ | 1220 +-----------+ | | | | +-----------+ 1221 |Reachable | +------------+ +------+ |Reachable | 1222 |TE networks|---| ABR-A2 | |ABR-A3|--|TE networks| 1223 |in Area A2 | +------------+ +------+ |in Area A3 | 1224 +-----------+ / | | | | | +-----------+ 1225 / | | +-------------------+ | +----------+ 1226 / | +-------------+ | | | 1227 +-----------+ +--------------+ | | | +--------------+ 1228 |Reachable | |Pre-engineered| | | | |Pre-engineered| 1229 |TE networks| |TE Ckt path(s)| +------+ +------+ |TE Ckt path(s)| 1230 |in Area A3 | |to ASBR-S1 | |Area-2| |Area-3| |to ASBR-S2 | 1231 +-----------+ +--------------+ +------+ +------+ +--------------+ 1232 | / | / 1233 +-------------+ | / | / 1234 |AS external | +---------+ +-------------+ 1235 |TE-network |------| ASBR-S1 | | ASBR-S2 | 1236 |reachability | +---------+ +-------------+ 1237 |from ASBR-S1 | | | | 1238 +-------------+ | | | 1239 +-----------------+ +-------------+ +-----------------+ 1240 |Pre-engineered TE| |AS External | |Pre-engineered TE| 1241 |circuit path(s) | |TE-Network | |circuit path(s) | 1242 |reachable from | |reachability | |reachable from | 1243 |ASBR-S1 | |from ASBR-S2 | |ASBR-S2 | 1244 +-----------------+ +-------------+ +-----------------+ 1246 Figure 8: Inter-Area Abstraction as viewed by Area-1 TE-routers 1248 9. Changes to Data structures in OSPF-TE routers 1250 9.1. Changes to Router data structure 1252 The router with TE extensions must be able to include all the 1253 TE capabilities (as specified in section 7.1) in the router data 1254 structure. Further, routers providing proxy service to other TE 1255 routers must also track the router and associated interface data 1256 structures for all the TE client nodes for which the proxy 1257 service is being provided. Presumably, the interaction between 1258 the Proxy server and the proxy clients is out-of-band. 1260 9.2. Two set of Neighbors 1262 Two sets of neighbor data structures will need to be maintained. 1263 TE-neighbors set is used to advertise TE LSAs. Only the 1264 TE-routers will be members of the TE-neighbor set. 1265 Normal neighbors set will be used to advertise native LSAs. All 1266 neighboring nodes supporting non-TE links canbe part of this 1267 set. As for flooding optimizations based on neighbors set, 1268 readers may refer [OSPF-FL1]. 1270 9.3. Changes to Interface data structure 1272 The following new fields are introduced to the interface data 1273 structure. These changes are in addition to the changes specified 1274 in [OSPF-FL1]. 1276 TePermitted 1277 If the value of the flag is TRUE, the interface is permissible 1278 to be advertised as a TE-enabled interface. 1280 NonTePermitted 1281 If the value of the flag is TRUE, the interface permits non-TE 1282 traffic on the interface. Specifically, this is applicable to 1283 packet networks, where data links may permit both TE and non-TE 1284 packets. For FSC and LSC TE networks, this flag will be set to 1285 FALSE. For Packet networks that donot permit non-TE traffic on 1286 TE links alos, this flag is set to TRUE. 1288 PktTerminated 1289 If the value of the flag is TRUE, the interface terminates 1290 Packet data and hence may be used for IP and OSPF data exchange. 1292 AdjacencySychRequired 1293 If the value of the flag is TRUE, the interface may be used to 1294 synchronize the LSDB across all adjacent neighbors. This is 1295 TRUE by default to all PktTerminated interfaces that are 1296 enabled for OSPF. However, it is possible to set this to FALSE 1297 for some of the interfaces. 1299 TE-TLVs 1300 Each interface may potentially have a maximum of 16 TLVS that 1301 describe the link characteristics. 1303 The following existing fields in Interface data structure will take 1304 on additional values to support TE extensions. 1306 Type 1307 The OSPF interface type can also be of type "Positional-RING". 1308 The Positional-ring type is different from other types (such 1309 as broadcast and NBMA) in that the exact location of the nodes 1310 on the ring is relevant, even as they are all on the same 1311 ring. SONET ADM ring is a good example of this. Complete ring 1312 positional-ring description may be provided by the GNE on a 1313 ring as a TE-network LSA for the ring. 1315 List of Neighbors 1316 The list may be statically defined for an interface, without 1317 requiring the use of Hello protocol. 1319 10. Comparison between Opaque-LSAs & the new TE-LSAs 1321 The following subsections attempt to identify the various issues 1322 such as flooding scope and scalability that are fundamentally 1323 lacking in the Opage-LSA based approach. Section 10.2 goes on to 1324 describe a transition strategy to eventually transition completely 1325 to the new TE-LSA scheme. 1327 Once the OSPF-TE is completely transitioned to the scheme 1328 described in this document, the packet and non-packet networks 1329 can be combined and issued addresses across the unified network. 1330 As such, the traffic engineering can be based on the overlayed or 1331 the peer model espoused in [GMPLS-TE]. 1333 10.1. TE flooding load on a non-TE network 1335 In a non-TE network, when a link is flapping, that can cause 1336 considerable hardship on all routers in the area. The hardship is 1337 not so much because of the LSAs that are generated, but because 1338 that causes the OSPF routing table to be recalculated. 1340 A TE network can also have a large number of LSA updates due to 1341 the many state changes the TE links undergo dynamically. These 1342 LSA updates are neither infrequent nor undesirable as with link 1343 flaps. 1345 Now, consider the case where Opaque LSAs are used for TE 1346 extensions. The flooding topology for opaque LSAs makes no 1347 distinction between TE nodes and non-TE nodes. In a network 1348 where the TE and non-TE nodes coexist, a non-TE router would be 1349 bombarded with Opaque LSAs. 1351 These Opaque LSAs carry TE metric state changes, which the non-TE 1352 router does not care about. If the router simply dropped the opaque 1353 LSAs and didnt recompute the dijkstra, that might be OK. But, it 1354 may be that some routers will recompute routes (because they process 1355 some of the Opaque LSAs that say that a particular link is no longer 1356 available for non-TE use). In the latter case, the routers might 1357 choose to simply recompute for all new Opaque LSA advertisements. 1358 Clearly, that would be a considerable computational demand and 1359 cause for instability on non-TE routers, triggered by the frequent 1360 opaque LSA advertisements. 1362 Secondly, If the TE and non-TE topologies are not separated (as is 1363 the case with Opaque-LSAs), the non-TE router could be utilizing the 1364 TE link as its least cost link, thereby stressing the TE link and 1365 effectively rendering the TE link ineffective for TE purposes. 1366 Separating the two topologies (as advocated by this document with 1367 new TE LSAs and TE option flag) ensure that the SLA objectives on 1368 TE links are properly met. 1370 Thirdly, the wider the flooding scope, the larger the number of 1371 retransmissions and acknowledgements. The same information or 1372 sometimes unneeded information may reach a router through multiple 1373 links. Even if the router didnt forward the information past the 1374 time, it would still have to send acknowledgements across all the 1375 multiple links on which the LSAs tried to converge. By moving the 1376 concept of flooding from "per interface" to "per neighbor", we 1377 minimize the flooding, without compromising on the untimate goal 1378 of LSDB convergence for TE and non-TE networks. 1380 Lastly, separating TE and non-TE topologies is beneficial in 1381 inter-area communication. When the topologies are separate, the 1382 area border routers can advertise different summary LSAs for TE and 1383 non-TE routers. Opaque LSAs are not adequate to establish 1384 TE peering relationship with the neighbors. 1386 For example, a non-TE Area Border router (ABR) could simply announce 1387 the non-TE-network summary LSAs (LSA type 3) for non-TE networks 1388 outside the area. A TE ABR, on the other hand, could advertise 1389 just the TE-network summary LSAs (0x83). Clearly, the advertised 1390 data is different. The boundary of TE-network summary LSA flooding 1391 is also different. The flooding boundary for TE-summary LSAs would 1392 be (AS - OriginatingArea - StubAreas - NSSAs). Clearly, the 1393 Opaque-LSA flooding boundary will not permit this type of flooding 1394 granularity. Without an AS-wide flooding (with the exception of stub 1395 areas), it is impossible to know which outside-are networks are 1396 TE-configurable and which are not. 1398 In summary, lack of flexible flooding topology can be an operational 1399 and functional nightmare. Folks will be forced to an unscalable, 1400 single-area topology to get around the shortcoming of the opaque 1401 LSAs. 1403 10.2. Scaling concerns What is lacking in Opaque-LSA-based TE scheme? 1405 The Opaque LSA based mechanism has the following fundamental scaling 1406 problems. These cannot be fixed by mere extensions to the same 1407 approach. We suggest below a transition strategy to migrate to the 1408 scheme proposed in this document. 1410 1. The flooding boundaries of Opaque LSAs make the OSPF-TE suitable 1411 at best to single-area topologies. Extending TE beyond one area 1412 can cause a lot of flooding problems. e.g.: Opaque LSAs cannot 1413 support the flooding scope of TE-summary-networks. 1414 Opaque LSAs (AS-wide scope) will be unable to restrict flooding 1415 in its own originating area. 1417 2. The Opaque LSA is also restricted in the way it can express 1418 different types of data. Everything should be expressible in 1419 in the form of a TLV. Summary-TE-networks-from each-Area, 1420 TE-ABR routers, TE-ASBR routers, TE-AS-External-networks, 1421 TE-Router-Capabilities, TE-link-updates, Pre-engineered-TE-Links 1422 - All of these data have to be engineered to be expressible in a 1423 TLV form with one or more sub-TLVs. TLVs should not be a panacea 1424 for all kinds of TE data. TLVs are generally more difficult to 1425 process and debug than fixed format messages. 1427 Opaque LSAs demand more processing to assimilate into topology 1428 abstraction. A single Opaque LSA type is bent in many 1429 ways (using a variety of TLVs) to update the native OSPF topology 1430 abstraction nodes. 1432 One way to transition from the current Opaque-LSA-based TE scheme to 1433 the new-TE scheme could be as follows. 1435 1. Use the existing Opaque-LSA-based-TE scheme for single area 1436 topologies. You will still need to find a way that a non-TE 1437 router doesnt cannibalize a TE-link for SPF forwarding. 1439 2. Fold in the TE option flag to construct the TE and non-TE 1440 topologies in an area, even if the topologies cannot be used 1441 for flooding within the area. 1443 3. Do away with Opaque LSAs for inter-area communication. Make use 1444 of the TE-topology within area to summarize the TE networks in 1445 the area and advertise the same to all TE-routers in the backbone. 1446 The TE-ABRs on the backbone area will in-turn advertise these 1447 summaries again within their connected areas. Use new LS types 1448 for summary LSAs, AS-external-LSAs and so forth, as specified 1449 in this document. 1451 4. Replace the use of Opaque LSAs with the TE LSAs within the area 1452 as well. 1454 10.3. Link State Database. 1456 With the new TE-LSA scheme, a TE node will have two types of 1457 Link state databases. The normal LSDB describes the control 1458 (non-TE) topology. Shortest-Path-First algorithm will be used to 1459 forward IP packets along this network. OSPF neighbors data 1460 structure will be used for flooding along the control topology. 1462 The TE node will have a separate TE-LSDB that describes the TE 1463 topology, constituted only of TE nodes and TE links. A variety of 1464 CSPF algorithms may be used to dynamically setup TE circuit paths 1465 along this TE network. TE-neighbors data structure is used for 1466 flooding TE LSAs alongs the TE-only topology. Having a clear 1467 distinction between the two LSDBs (and hence topologies) makes 1468 this approach more desirable to service providers desiring to 1469 offer strictly enforceable SLAs (Service Level Agreements) 1470 along their TE topology. 1472 Whereas, in the Opaque-LSA-based TE scheme, the TE-LSDB built 1473 using opaque LSAs will be required to refer the normal LSDB to 1474 build the TE topology. Even with that, there is way to know the 1475 TE capabilities of the routers. The Opaque-LSA approach does 1476 not deal with TE capabilities for a router. Opaque LSAs 1477 are flooded to all nodes. Some nodes that happen to support 1478 the TE extensions will have a hit and accept the opaque LSAs. 1479 Others that donot support will have a miss and simply drop the 1480 received Opaque LSAs. This type of hit-and-miss approach is 1481 not only disruptive, but also blind to the SLA requirements 1482 on TE links. 1484 10.4. Real-world scenarios better served by the new-TE-LSAs scheme. 1486 Many real-world scenarios are better served by the new-TE-LSAs 1487 scheme. Here are a few examples. 1489 1. Multi-area network. 1491 2. Single-Area networks - The TE links are not cannibalized by the 1492 non-TE routers for SPF forwarding. 1494 3. Credible SLA enforcement in a (TE + non-TE) packet network. 1495 Ability to restrict flooding to some links (say, non-TE links) 1496 ensures the service provider is able to devote the entire 1497 bandwidth of a TE-link for TE circuit purposes. This makes SLA 1498 enforcement credible. 1500 4. For a non-Packet TE network, the Opaque-LSA-based-TE scheme is 1501 not adequate to represent 1502 (a) "Positional-Ring" type network LSA and 1503 (b) Router Proxying - allowing a router to advertise on behalf 1504 of other nodes (that are not Packet/OSPF capable). 1506 11. IANA Considerations 1508 11.1. All-TE-compliant-SPF routers Multicast address allocation 1510 11.2. New TE-LSA Types 1512 11.3. New TLVs (Router-TE and Link-TE TLVs) 1514 11.3.1. TE-selection-Criteria TLV (Tag ID = 1) 1515 - Bandwidth based LSPs (1) 1516 - Priority based LSPs (2) 1517 - Backup LSP (3) 1518 - Link cost (4) 1520 11.3.2. MPLS-Signaling protocol TLV (Tag ID = 3) 1521 - RSVP-TE signaling 1522 - LDP signaling 1523 - CR-LDP signaling 1525 11.3.3. Constraint-SPF algorithms-Support TLV (Tag ID = 4) 1526 - CSPF Algorithm Codes. 1528 11.3.4. SRLG-TLV (Tag ID = 0x81) 1529 - SRLG group IDs 1531 11.3.5. BW-TLV (Tag ID = 0x82) 1533 11.3.6 CO-TLV (Tag ID = ox83) 1535 12. Security Considerations 1537 This memo does not create any new security issues for the OSPF 1538 protocol. Security considerations for the base OSPF protocol are 1539 covered in [OSPF-v2]. As a general rule, a TE network is likely 1540 to generate significantly more control traffic than a native 1541 OSPF network. The excess traffic is almost directly proportional 1542 to the rate at which TE circuits are setup and torn down within 1543 an autonomous system. It is important to ensure that TE database 1544 sychronizations happen quickly when compared to the aggregate 1545 circuit setup an tear-down rates. 1547 REFERENCES 1549 [IETF-STD] Bradner, S., " The Internet Standards Process -- 1550 Revision 3", RFC 1602, IETF, October 1996. 1552 [RFC 1700] J. Reynolds and J. Postel, "Assigned Numbers", 1553 RFC 1700 1555 [MPLS-TE] Awduche, D., et al, "Requirements for Traffic 1556 Engineering Over MPLS," RFC 2702, September 1999. 1558 [GMPLS-TE] P.A. Smith et. al, "Generalized MPLS - Signaling 1559 Functional Description", 1560 draft-ietf-mpls-generalized-signaling-03.txt, work 1561 in progress. 1563 [RSVP-TE] Awduche, D.O., L. Berger, Der-Hwa Gan, T. Li, 1564 V. Srinivasan and G. Swallow, "RSVP-TE: Extensions 1565 to RSVP for LSP Tunnels", Work in progress, 1566 draft-ietf-mpls-rsvp-lsp-tunnel-08.txt 1568 [CR-LDP] Jamoussi, B. et. al, "Constraint-Based LSP Setup 1569 using LDP", draft-ietf-mpls-cr-ldp-05.txt, 1570 Work in Progress. 1572 [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1574 [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, 1575 March 1994. 1577 [NSSA] Coltun, R., V. Fuller and P. Murphy, "The OSPF NSSA 1578 Option", draft-ietf-ospf-nssa-update-10.txt, Work in 1579 Progress. 1581 [OPAQUE] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, 1582 July 1998. 1584 [OSPF-FL1] Zinin, A. and M. Shand, "Flooding Optimizations in 1585 link-state routing protocols", work in progress, 1586 1588 [OSPF-FL2] Moy, J., "Flooding over a subset topology", 1589 , work in progress. 1591 [OPQLSA-TE] Katz, D., D. Yeung and K. Kompella, "Traffic 1592 Engineering Extensions to OSPF", work in progress, 1593 1595 Authors' Addresses 1597 Pyda Srisuresh 1598 Jasmine Networks 1599 3061 Zanker Road, Suite B 1600 San Jose, CA 95134 1601 U.S.A. 1602 EMail: srisuresh@yahoo.com 1604 Paul Joseph 1605 Jasmine Networks 1606 3061 Zanker Road, Suite B 1607 San Jose, CA 95134 1608 U.S.A. 1609 EMail: pjoseph@jasminenetworks.com