idnits 2.17.1 draft-srisuresh-ospf-te-02.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? == 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 are 208 instances 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 707: '...on a TE-configurable network MUST have...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 501 has weird spacing: '...TE link ineff...' == Line 700 has weird spacing: '...niquely ident...' == Line 1146 has weird spacing: '...sources that ...' == Line 1392 has weird spacing: '...bes the reach...' -- 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.) -- The document date (January 4, 2002) is 8147 days in the past. Is this intentional? 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 762, but not defined == Missing Reference: 'MPLS-ARCH' is mentioned on line 208, but not defined == Missing Reference: 'OSPF-NSSA' is mentioned on line 762, but not defined == Missing Reference: 'BGP-OSPF' is mentioned on line 940, but not defined == Unused Reference: 'IETF-STD' is defined on line 1848, but no explicit reference was found in the text == Unused Reference: 'RFC 1700' is defined on line 1851, 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: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-03 ** Downref: Normative reference to an Historic RFC: RFC 1584 (ref. 'MOSPF') == Outdated reference: A later version (-11) exists of draft-ietf-ospf-nssa-update-10 ** Obsolete normative reference: RFC 2370 (ref. 'OPAQUE') (Obsoleted by RFC 5250) -- Possible downref: Non-RFC (?) normative reference: ref. 'FLOOD-OPT' -- Possible downref: Non-RFC (?) normative reference: ref. 'OPQLSA-TE' -- Possible downref: Non-RFC (?) normative reference: ref. 'OPQLSA-GMPLS' Summary: 11 errors (**), 0 flaws (~~), 13 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 Kuokoa Networks 4 Expires as of July 04, 2002 P. Joseph 5 Vivace Networks 6 January 4, 2002 8 TE LSAs to extend OSPF for Traffic Engineering 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet- Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 OSPF is a link state routing protocol used for IP-network 35 topology discovery and collection and dissemination of link 36 access metrics. The resulting Link State Database (LSDB) is 37 used to compute IP address forwarding table based on 38 shortest-path criteria. Traffic Engineering extensions(OSPF-TE) 39 outlined in this document are built on the native OSPF 40 foundation, utilizing new LSAs, designed specifically for TE. 41 OSPF-TE sets out to discover TE network topology and perform 42 collection and dissemination of TE metrics within the TE network. 43 This results in the generation of an independent TE-LSDB, that 44 would permit computation of TE circuit paths. Unlike the native 45 OSPF link metrics, TE metrics can be rapidly changing and 46 varied across different elements of the network. TE circuit 47 paths are computed using varied TE criteria, often different 48 from the shortest-path, to route traffic around congestion 49 paths. Principal motivations to designing the OSPF-TE over 50 [OPQLSA-TE] and transition path for vendors currently using 51 [OPQLSA-TE] to adapt the OSPF-TE are outlined in separate 52 sections within the document. OSPF-TE provides a single unified 53 mechanism for traffic engineering across packet and non-packet 54 networks, and may be adapted for a peer networking model. 56 Table of Contents 58 1. Introduction ................................................3 59 2. Traffic Engineering .........................................4 60 3. Terminology .................................................5 61 3.1. OSPF-TE node ...........................................5 62 3.2. Native OSPF node .......................................5 63 3.3. TE nodes vs. native(non-TE) nodes ......................6 64 3.4. TE links vs. native(non-TE) links ......................6 65 3.5. Packet-TE network vs. non-packet-TE network ............6 66 3.6. TE topology vs. non-TE topology ........................6 67 3.7. TLV ....................................................7 68 3.8. Router-TE TLVs .........................................7 69 3.9. Link-TE TLVs ...........................................7 70 4. Motivations to designing the OSPF-TE using TE-LSAs ..........7 71 4.1. Clean design - TE-LSDB, independent of the native LSDB .7 72 4.2. Extendible design - based on the OSPF foundation .......8 73 4.3. Scalable design - TE-AS may be sub-divided into areas ..9 74 4.4. Unified design - for packet and non-packet networks ....9 75 4.5. Efficient design - in LSA content and flooding reach ..10 76 4.6. SLA enforceable TE network can coexist with IP network 10 77 4.7. Right Framework for future OSPF extensibility .........11 78 4.8. Network scenarios benefiting from the OSPF-TE design ..12 79 4.8.1. IP providers transitioning to TE services ......12 80 4.8.2. Providers offering Best-effort IP & TE services.12 81 4.8.3. Multi-area networks ............................12 82 4.8.4. Non-packet and Peer-networking models ..........12 83 5. OSPF-TE solution, assumptions and limitations ..............13 84 5.1. OSPF-TE Solution ......................................14 85 5.2. Assumptions ...........................................16 86 5.3. Limitations ...........................................16 87 6. Transition strategy for implementations using Opaque LSAs ..16 88 7. The OSPF Options field .....................................16 89 8. Bringing up TE adjacencies; TE vs. Non-TE topologies .......17 90 8.1. The Hello Protocol ....................................17 91 8.2. Flooding and the Synchronization of Databases .........18 92 8.3. The Designated Router .................................19 93 8.4. The Backup Designated Router ..........................19 94 8.5. The graph of adjacencies ..............................19 95 9. TE LSAs ....................................................20 96 9.1. TE-Router LSA (0x81) ..................................22 97 9.1.1. Router-TE flags - TE capabilities of the router.24 98 9.1.2. Router-TE TLVs .................................25 99 9.1.3. Link-TE options - TE capabilities of a TE-link .26 100 9.1.4. Link-TE TLVs ...................................26 101 9.2. TE-incremental-link-Update LSA (0x8d) .................27 102 9.3. TE-Circuit-paths LSA (0x8C) ...........................29 103 9.4. TE-Summary LSAs .......................................30 104 9.4.1. TE-Summary Network LSA (0x83) ..................30 105 9.4.2. TE-Summary router LSA (0x84) ...................31 106 9.5. TE-AS-external LSAs (0x85) ............................33 107 9.6. Changes to Network LSA ................................34 108 9.6.1. Positional-Ring type network LSA ...............34 109 9.7. TE-Router-Proxy LSA (0x8e) ............................35 110 9.8. Others ................................................36 111 10. Abstract topology representation with TE support ...........36 112 11. Changes to Data structures in OSPF-TE routers ..............38 113 11.1. Changes to Router data structure .....................38 114 11.2. Two set of Neighbors .................................38 115 11.3. Changes to Interface data structure ..................38 116 12. IANA Considerations ........................................39 117 12.1. TE-compliant-SPF routers Multicast address allocation 39 118 12.2. New TE-LSA Types .....................................39 119 12.3. New TLVs (Router-TE and Link-TE TLVs) ................39 120 12.3.1. TE-selection-Criteria TLV (Tag ID = 1) .......39 121 12.3.2. MPLS-Signaling protocol TLV (Tag ID = 3) .....39 122 12.3.3. Constraint-SPF algorithms-Support TLV (Tag ID=4) 123 12.3.4. SRLG-TLV (Tag ID = 0x81) .....................39 124 12.3.5. BW-TLV (Tag ID = 0x82) .......................40 125 12.3.6. CO-TLV (Tag ID = ox83) .......................40 126 13. Acknowledgements ...........................................40 127 14. Security Considerations ....................................40 128 References .....................................................40 130 1. Introduction 132 There is substantial industry experience with deploying OSPF link 133 state routing protocol. That makes OSPF a good candidate to adapt 134 for traffic engineering purposes. The dynamic discovery of network 135 topology, link access metrics, flooding algorithm and the 136 hierarchical organization of areas can all be used effectively in 137 creating and tearing traffic links on demand. The intent of 138 OSPF-TE is to discover TE network topology and the TE metrics 139 of the nodes and links in the network. 141 The objective of traffic engineering is to set up circuit path(s) 142 across a pair of nodes or links, as the case may be, so as to 143 forward traffic of a certain forwarding equivalency class. Circuit 144 emulation in a packet network is accomplished by each MPLS 145 intermediary node performing label swapping. Whereas, circuit 146 emulation in a TDM or Fiber cross-connect network is accomplished 147 by configuring the switch fabric in each intermediary node to do 148 the appropriate switching (TDM, fiber or Lamda) for the duration 149 of the circuit. 151 The objective of this document is not how to set up traffic circuits, 152 but rather provide the necessary TE parameters for the nodes and 153 links that constitute the TE topology. Unlike the native OSPF, 154 OSPF-TE will be used to build circuit paths, meeting certain TE 155 criteria. The only requirement is that end-nodes and/or end-links of 156 a circuit be identifiable with an IP address. 158 The approach suggested in this document is different from the 159 Opaque-LSA-based approach outlined in [OPQLSA-TE]. Section 4 160 describes the motivations behind designing OSPF-TE. Section 6 161 outlines a strategy to transition Opaque-LSA based implementations 162 to adapt the OSPF-TE outlined here. 164 2. Traffic engineering overview 166 A traffic engineered circuit may be identified by the tuple of 167 (Forwarding Equivalency Class, TE parameters for the circuit, 168 Origin Node/Link, Destination node/Link). 170 The Forwarding Equivalency Class(FEC) may be constituted of a number 171 of criteria such as (a) Traffic arriving on a specific interface, 172 (b) Traffic meeting a certain classification criteria (ex: based on 173 fields in the IP and transport headers), (c) Traffic in a certain 174 priority class, (d) Traffic arriving on a specific set of TDM (STS) 175 circuits on an interface, (e) Traffic arriving on a certain 176 wave-length of an interface, (f) Traffic arriving at a certain time 177 of day, and so on. A FEC may be constituted as a combination of one 178 or more of the above criteria. Discerning traffic based on the FEC 179 criteria is a mandatory requirement on Label Edge Routers (LERs). 180 Traffic content is transparent to the Intermediate Label Switched 181 Routers (LSRs), once a circuit is formed. LSRs are simply 182 responsible for keeping the circuit in-tact for the lifetime of the 183 circuit(s). As such, this document will not address FEC or the 184 associated signaling to setup circuits. [MPLS-TE] and [GMPLS-TE] 185 address the FEC criteria. Whereas, [RSVP-TE] and [CR-LDP] address 186 different types of signaling protocols. 188 This document is concerned with the collection of TE parameters for 189 all the nodes and links within an autonomous system. TE parameters 190 for a node may include a) ability to perform traffic prioritization, 191 b) ability to provision bandwidth on interfaces, c) support for zero 192 or more CSPF algorithms, d) support for a specific TE-Circuit switch 193 type, e) support for a certain type of automatic protection 194 switching and so forth. TE parameters for a link may include 195 a) available bandwidth, b) reliability of the link, c) color 196 assigned to the link, d) cost of bandwidth usage on the link, and 197 e) membership to a Shared Risk Link Group (SRLG) and so forth. 199 Only the unicast paths circuit paths are considered here. Multicast 200 variations are currently considered out of scope for this document. 201 The requirement is that the originating as well as the terminating 202 entities of a TE path are identifiable by their IP address. 204 3. Terminology 206 Definitions for majority of the terms used in this document with 207 regard to OSPF protocol may be found in [OSPF-V2]. MPLS and traffic 208 engineering terms may be found in [MPLS-ARCH]. RSVP-TE and CR-LDP 209 signaling specific terms may be found in [RSVP-TE] and [CR-LDP] 210 respectively. 212 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", 213 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 214 this document are to be interpreted as described in RFC 2119. 216 Below are definitions for the terms used within this document. 218 3.1. OSPF-TE node 220 This is a router that supports the OSPF-TE described in this 221 document. At least one of the attached links for the node 222 supports IP packet termination and runs the OSPF-TE protocol. 224 An OSPF-TE node supports native OSPF as well as the OSPF-TE. 226 3.2. Native OSPF node 228 A native OSPF node is an OSPF router that does not support 229 the TE extensions described in this document or does not have 230 a TE link attached to it. A Native OSPF node forwards IP 231 traffic, using the shortest-path forwarding algorithm. 233 A native OSPF node may be enhanced to be an OSPF-TE node. An 234 autonomous system (AS) could be constituted of a combination 235 of native-OSPF and OSPF-TE nodes. 237 3.3. TE nodes vs. native(non-TE) nodes 239 A TE-Node is an intermediate or edge node taking part in the 240 traffic engineered (TE) network. A TE-circuit is constituted of 241 a series of TE nodes connected to each other through TE links. 242 In a SONET/TDM network or a photonic cross-connect network, 243 a TE node is not required to support OSPF-TE. An external 244 OSPF-TE node may represent the TE node for protocol processing. 246 A native (or non-TE) node is an IP router capable of IP packet 247 forwarding, does not have TE link attachments and does not take 248 part in a TE network. 250 3.4. TE links vs. native(non-TE) links 252 A TE Link is a network attachment that supports traffic 253 engineering. A TE-circuit is constituted of a series of TE 254 nodes connected to each other through TE links. 256 A native (or non-TE) link is one that is used for IP packet 257 traversal. A link may be configured to be pure TE link or 258 native link or a both. 260 3.5. Packet-TE network vs. non-packet-TE network 262 Packet-TE network is one in which TE-circuit emulation is 263 accomplished by each MPLS intermediary node performing label 264 swapping on the packet data. 266 Non-packet-TE network, such as SONET/TDM or Fiber 267 cross-connect network is one in which TE-circuit emulation is 268 accomplished by configuring the switch fabric in each 269 intermediary node to do the appropriate switching (TDM, fiber 270 or Lamda) for the duration of the circuit. 272 In either case, OSPF-TE can only be enabled on interfaces 273 supporting IP packet termination. Interfaces supporting OSPF 274 and/or OSPF-TE constitute the OSPF control network. The OSPF 275 control network can be independent of the packet or non-packet 276 data network. 278 3.6. TE topology vs. non-TE topology 280 A TE topology is constituted of a set of contiguous TE nodes and 281 TE links. Associated with each TE node and link is a set of TE 282 criteria that may be supported at any given time. A TE topology 283 allows circuits to be overlayed statically or dynamically based 284 on a specific TE criteria. 286 A non-TE topology specifically refers to the network that does not 287 support TE. Control protocols such as OSPF may be run on the non-TE 288 topology. IP forwarding table used to forward IP packets on this 289 network is built based on the control protocol specific algorithm, 290 such as OSPF shortest-path criteria. 292 3.7. TLV 294 A TLV stands for an object in the form of Tag-Length-Value. All TLVs 295 are assumed to be of the following format, unless specified 296 otherwise. The Tag and length are 16 bits wide each. The length 297 includes the 4 bytes required for Tag and Length specification. 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Tag | Length (4 or more) | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Value .... | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | .... | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 3.8. Router-TE TLVs 311 TLVs used to describe the TE capabilities of a TE-node. 313 3.9. Link-TE TLVs 315 TLVs used to describe the TE capabilities of a TE-link. 317 4. Motivations to designing the OSPF-TE using TE-LSAs 319 The motivation behind designing the OSPF-TE using TE-LSAs is 320 that the approach is clean, extendible, scalable, unified, 321 efficient, and SLA enforceable. The approach also provides 322 the right framework for future OSPF extensibility. Each of 323 these motivations is explained in detail in the following 324 subsections. 326 The last subsection lists network scenarios that benefit from 327 the TE-LSA design. 329 4.1. Clean design - TE-LSDB, independent of the native LSDB 330 OSPF-TE using TE LSAs provides a clean separation of Link State 331 Data Bases (LSDB) between native (SPF-based) and TE networks. 332 The OSPF-TE dynamically discovers TE network topology and the 333 associated TE metrics of the nodes and links in the TE network. 334 OSPF-TE design is based on the tried and tested OSPF paradigm. 335 As such, it inherits all the benefits of the OSPF, present and 336 future. 338 With OSPF-TE, native OSPF nodes will keep just the native OSPF 339 link state database. The OSPF-TE nodes will keep the native as 340 well as the TE LSDB. In the case, where the network is used 341 only for Traffic engineering purposes, the native-LSDB 342 describes the control topology. 344 In the Opaque-LSA-based TE scheme([OPQLSA-TE]), the TE-LSDB built 345 using opaque LSAs refers the native LSDB to build the TE topology. 346 Further, the LSDB has no knowledge of the TE capabilities of the 347 routers. Point-to-point links are the only type of links that can 348 form a TE network. It is apparent that [OPQLSA-TE] is a new 349 protocol in itself within the constraints of an Opaque-LSA and is 350 not tailored to benefit from the tried and tested native-OSPF. 352 4.2. Extendible design - based on the OSPF foundation 354 TE LSAs are extendible, just as the native OSPF on which OSPF-TE 355 is founded. [OPQLSA-TE], on the other hand, is not extendible 356 and is constrained by the Opaque LSA on which it is founded. 358 For example, Opaque LSAs are not suited to advertising summary 359 LSAs along a restricted flooding scope (as with TE-Summary 360 network LSA). Opaque LSAs are also not suited to advertising 361 incremental TLV changes. A change in any TLV of a TE-link will 362 mandate the entire Opaque-LSA (with all the TLVs included) to be 363 transmitted. TE-incremental-link-update LSA, on the other hand, 364 is capable of advertising just the delta TLVs. Opaque LSAs 365 are also not extendible to support advertisement of TLVs for 366 non-members of the OSPF control network. This is a necessity 367 for certain non-packet networks such as a SONET/TDM network. In 368 a SONET/TDM network, data-path topology often differs from 369 its OSPF control network counterpart. TE-Router-Proxy-LSA 370 (section 9.7) permits advertising LSAs for non-members via 371 a proxy node that is a member of the control network. 373 Lastly, the expressibility of data in an Opaque LSA is strictly 374 restricted to being in the form of TLVs and sub-TLVs, some 375 mandatorily required and some positionally dependent in the 376 TLV sequence for interpretation. 378 4.3. Scalable design - TE-AS may be sub-divided into areas 380 OSPF-TE using TE LSAs inherits the hierarchical area organization 381 used within native-OSPF. Without revealing the nodes and 382 characteristics of the attached links within a TE-area, the 383 TE-Summary network LSA (refer section 9.4) advertises the 384 reachability of TE networks within an area to the areas outside 385 in the same AS. 387 Providing area level abstraction and having the abstraction be 388 distinct for TE and native topologies is a necessity for 389 inter-area communication. When the topologies are separate, the 390 area border routers can advertise different summary LSAs to TE 391 and non-TE routers. For example, a native Area Border router (ABR) 392 simply announces the shortest path network summary LSAs (LSA 393 type 3) for nodes outside the area. A TE-ABR, on the other hand, 394 would use TE-summary network LSA to advertise network Reachability 395 information - not aggregated path metric as required for a native 396 OSPF LSDB. Clearly, the data content and flooding scope should be 397 different for the TE nodes. The flooding boundary for TE-summary 398 LSAs would be (AS - OriginatingArea - StubAreas - NSSAs). 400 Opaque-LSA-based TE scheme([OPQLSA-TE]) is restricted for use 401 within an area and is not applicable for flooding across areas. 402 As-wide scope Opaque LSAs (Type 11 LSAs) will be unable to restrict 403 flooding in its own originating area. 405 4.4. Unified design - for packet and non-packet networks 407 OSPF-TE uses the same set of TE LSAs for disseminating TE 408 characteristics - irrespective of whether the network is a packet 409 network or a non-packet network or a combination of both. Only 410 the TLVs used to describe the characteristics will vary. Each TE 411 node will be required to advertise its own TE capabilities and 412 that of the attached TE links. 414 In a peer networking TE model, the TE nodes are heterogeneous 415 and have different TE characteristics. As such, the signaling 416 protocols will need the TE characteristics of all nodes and 417 attached links so they can signal the nodes to formulate TE 418 circuits across heterogeneous nodes. The underlying control 419 protocol must be capable of providing a unified LSDB for all 420 nodes in the network. OSPF-TE clearly meets this requirement. 422 Opaque-LSA-based TE scheme([OPQLSA-TE]) is limited in scope for 423 packet networks. Extensions ([OPQLSA-GMPLS]) are underway to 424 support GMPLS links within opaque LSAs. However, neither 426 [OPQLSA-TE] nor [OPQLSA-GMPLS] is sufficient by itself or when 427 combined for use within a peer networking model with heterogeneous 428 nodes. Neither of the Opaque LSA based extensions have provision 429 to distinguish between the various nodes and link attachments that 430 are different from point-to-point connections. SONET specific 431 ring topologies and packet network specific LAN and other mesh 432 topologies are not permitted. 434 4.5. Efficient design - in LSA content and flooding reach 436 OSPF-TE is capable of identifying the boundaries of a TE topology 437 and limits the flooding of TE LSAs to only the TE-nodes. Nodes 438 that do not have TE link attachments are not bombarded with TE 439 specific LSAs. This is a useful characteristic for networks 440 supporting native and TE traffic in the same connected network. 442 The more frequent and wider the flooding scope, the larger the 443 number of retransmissions and acknowledgements. The same 444 information (needed or not) may reach a router through multiple 445 links. Even if the router did not forward the information past 446 the node, it would still have to send acknowledgements across 447 all the various links on which the LSAs tried to converge. 448 Clearly, it is not desirable to flood LSAs to nodes that do not 449 require it. This can be a considerable impediment to non-TE 450 nodes in a network that is constituted of native and TE nodes. 452 Opaque-LSA-based TE scheme([OPQLSA-TE]) makes no distinction 453 between TE and native OSPF nodes as far as LSA flooding is 454 concerned. It is possible for the native OSPF nodes to silently 455 ignore the unsupported Opaque LSAs or add knobs within 456 implementation to decide whether or not a certain opaque LSA 457 mandates dijkstra SPF recomputation. In any case, unintended 458 LSAs are disruptive and can be the cause of a large number of 459 acknowledgements and retransmissions. 461 TE metrics in a network could be rapidly changing. Only a subset 462 of the metrics may be prone to rapid change, while others remain 463 largely unchanged. Changes must be communicated at the earliest 464 throughout the network to ensure that the TE-LSDB is up-to-date. 465 TE-Incremental-Link-update LSA (section 9.2) permits advertising 466 only a subset of the link metrics and not the entire router-LSA 467 all over. [OPQLSA-TE] does not have provision to advertise just 468 the TLVs that changed. A change in any TLV of a TE-link will 469 mandate the entire LSA to be transmitted. This is clearly a 470 serious shortcoming in the protocol. 472 4.6. SLA enforceable TE network can coexist with IP network 473 OSPF-TE is designed to draw distinction between links that 474 support TE traffic and links that support native best-effort 475 IP traffic. This flexibility to configure links as appropriate 476 for a service, permits enforceability of service level 477 agreements (SLAs). A link, configured to support TE traffic 478 alone will not permit native IP traffic on the link. 480 Best-effort IP transit network and constraint based TE network 481 have different SLA requirements and hence different billing 482 models. Keeping the two networks physically isolated will enable 483 SLA enforceability, but can be expensive. Combining the two 484 networks into a single physically connected network will bring 485 economies of scale, if the SLA enforceability can be retained. 486 When the links of a TE-network LSDB do not overlap the links 487 of a native LSDB, such a virtual isolation of networks and 488 hence SLA enforceability becomes possible. 490 Opaque-LSA-based TE scheme([OPQLSA-TE]) is inherently not capable 491 of having two virtual networks in a single physically connected 492 network. All point-to-point links in a packet network are subject 493 to best-effort IP traffic, irrespective of whether a link is 494 usable for TE traffic or not. In order to ensure that TE links are 495 not cannibalized by best-effort traffic, the network provider will 496 simply have to restrict best-effort traffic from entering the 497 network. This is a severe limitation and is a direct result of 498 not having LSDB isolation. When TE and native topologies 499 are not separated (as is the case with Opaque-LSAs), a native OSPF 500 node could be utilizing a TE link as its least cost link, thereby 501 stressing the TE link and rendering the TE link ineffective for 502 TE purposes. 504 4.7. Right Framework for future OSPF extensibility 506 OSPF-TE design provides the right framework for future OSPF 507 extensions based on independent service provider needs. The 508 framework essentially calls for building independent service 509 specific LSDBs. Each such LSDB will consist of service specific 510 metrics of all resources within the service-specific topology. 511 The TE-LSDB permits TLV scalability as well as the ability 512 to perform fast searches through the database. Just as the 513 TE-LSDB may be used for MPLS TE application, a different type 514 of LSDB may be used for a different type of application across 515 the same physically connected IP network. E.g., one can derive 516 QOS based IP forwarding on an IP network. 518 Limiting flooding scope of service specific LSAs within the 519 service specific topology eliminates LSA contamination between 520 virtual service networks of a single physically connected 521 network. Using service specific LSAs provides flexibility in 522 LSA content and flooding scope. 524 Opaque-LSA-based TE scheme([OPQLSA-TE]) works best when a single 525 type of service is assumed for a single physically connected 526 network. As such, multiple disparate networks can function 527 running various flavors of OSPF. [OSPF-v2] for native best-effort 528 IP networks, [OPQLSA-TE] for packet networks and [OPQLSA-GMPLS] 529 for non-packet networks. 531 4.8. Network scenarios benefiting from the OSPF-TE design 533 Many real-world scenarios are better served by the new-TE-LSAs 534 scheme. Here are a few examples. 536 4.8.1. IP providers transitioning to TE services 538 Providers needing to support MPLS based TE in their IP network 539 may choose to transition gradually. Perhaps, add new TE links 540 or convert existing links into TE links within an area first 541 and progressively advance to offer in the entire AS. 543 Not all routers will support TE extensions at the same time 544 during the migration process. Use of TE specific LSAs and their 545 flooding to OSPF-TE only nodes will allow the vendor to 546 introduce MPLS TE without destabilizing the existing network. 547 As such, the native OSPF-LSDB will remain undisturbed while 548 newer TE links are added to network. 550 4.8.2. Providers offering Best-effort-IP & TE services 552 Providers choosing to offer both best-effort-IP and TE based 553 packet services simultaneously on the same physically connected 554 network will benefit from the OSPF-TE design. By maintaining 555 independent LSDBs for each type of service, TE links are not 556 cannibalized by the non-TE routers for SPF forwarding. Unlike 557 the [OPQLSA-TE] scheme, OSPF-TE provides the framework for SLA 558 enforcement. 560 4.8.3. Multi-area networks 562 The OSPF-TE design parallels the tried and tested native-OSPF 563 design. Unlike [OPQLSA-TE], OSPF-TE scales naturally to multi-area 564 networks. 566 4.8.4. Non-packet and Peer-networking models 568 OSPF-TE is the only scheme that can support the following 569 network attachments For a non-Packet TE network. 570 (a) "Positional-Ring" type network LSA and 571 (b) Router Proxying - allowing a router to advertise on behalf 572 of other nodes (that are not Packet/OSPF capable). 574 Opaque LSA based extensions ([OPQLSA-TE], [OPQLSA-GMPLS]) are not 575 suited to distinguish the heterogeneous nodes in a peer-connected 576 network. Opaque-LSA based extensions are also not suited to support 577 link attachments that are different from point-to-point connections. 579 5. OSPF-TE solution, assumptions and limitations 581 5.1. OSPF-TE Solution 583 The OSPF-TE uses the options flag as a means to determine the 584 TE topology. New TE LSAs are designed to generate an independent 585 TE-service tailored LSDB. Sections 8.0 and 9.0 describe the TE 586 extensions in detail. Changes required of the OSPF data 587 structures in order to support OSPF-TE are described in section 588 11.0. The OSPF-TE design is based on the tried and tested OSPF 589 paradigm. With TE-LSDB, you have the advantages of retaining the 590 scalability of TLV's and the ability to run fast searches through 591 the database. 593 With the new TE-LSA scheme, an OSPF-TE node will have two types 594 of Link state databases (LSDB). A native LSDB that describes the 595 native control topology and a TE-LSDB that describes the TE 596 topology. Shortest-Path-First algorithm will be used to forward 597 IP packets along the native control network. OSPF neighbors data 598 structure will be used for flooding along the control topology. 600 The TE-LSDB is constituted only of TE nodes and TE links. A variety 601 of CSPF algorithms may be used to dynamically setup TE circuit 602 paths along the TE network. A new TE-neighbors data structure will 603 be used to flood TE LSAs along the TE-only topology. Clearly, the 604 the TE nodes will need the control (non-TE) network for OSPF 605 communication. The control network may also be used for pinging 606 OSPF-TE nodes and performing any debug and monitoring tasks on 607 the nodes. However, the ability to make distinction between 608 TE and non-TE topologies, allows the bandwidth on TE links to be 609 strictly SLA enforceable, even as a TE link is packet-capable. 610 The actual characteristics of the TE-link are irrelevant from the 611 OPSF-TE perspective. As such, that allows for packet and non-packet 612 networks to operate in peer mode. 614 Consider the following network where some of the routers and links 615 are TE enabled and others are native OSPF routers and links. All 616 nodes in the network belong to the same OSPF area. 618 +---+ 619 | |--------------------------------------+ 620 |RT6|\\ | 621 +---+ \\ | 622 || \\ | 623 || \\ | 624 || \\ | 625 || +---+ | 626 || | |----------------+ | 627 || |RT1|\\ | | 628 || +---+ \\ | | 629 || //| \\ | | 630 || // | \\ | | 631 || // | \\ | | 632 +---+ // | \\ +---+ | 633 |RT2|// | \\|RT3|------+ 634 | |----------|----------------| | 635 +---+ | +---+ 636 | | 637 | | 638 | | 639 +---+ +---+ 640 |RT5|--------------|RT4| 641 +---+ +---+ 642 Legend: 643 -- Native(non-TE) network link 644 | Native(non-TE) network link 645 \\ TE network link 646 || TE network link 648 Figure 6: A (TE + native) OSPF network topology 650 In the above network, TE and native OSPF Link State Data bases 651 (LSDB) would have been synchronized within the area along the 652 following nodes. 654 Native OSPF LSDB nodes TE-LSDB nodes 655 ---------------------- ------------- 656 RT1, RT2, RT3. RT4, RT5, RT6 RT1, RT2, RT3, RT6 658 Nodes such as RT1 will have two LSDBs, a native LSDB and a TE-LSDB 659 to reach native and TE networks. The TE LSA updates will not impact 660 non-TE nodes RT4 and RT5. 662 5.2. Assumptions 664 OSPF-TE design makes the following assumptions. 666 1. An OSPF-TE node with links in an OSPF area will need to 667 establish router adjacency with at least one other neighboring 668 OSPF-TE node in order for the router's database to be 669 synchronized with other routers in the area. Failing this, the 670 OSPF router will not be in the TE calculations of other TE 671 routers in the area. Refer [FLOOD-OPT] for flooding 672 optimizations. 674 2. Unlike the native OSPF, OSPF-TE must be capable of advertising 675 link state of interfaces that are not capable of handling IP 676 packet data. As such, the OSPF-TE protocol cannot be required 677 to synchronize its link-state database with neighbors across 678 all its links. It is sufficient to synchronize link-state 679 database in an area, across a subset of the IP termination 680 links. Yet, the TE LSDB (LSA database) should be synchronized 681 across all OSPF-TE nodes within an area. 683 All nodes and interfaces described by the TE LSAs will be 684 present in the TE topology database (a.k.a. TE LSDB). 686 3. A link in a packet network can be a TE-link or a native-IP 687 link or both. There may be different ways by which to use 688 a link for TE and non-TE traffic. For example, a link may 689 be used for both types of traffic and satisfy the TE SLA 690 requirements, so long as the link is under-subscribed for 691 TE (say, 50% of the link capacity is being used). Once the 692 TE capacity requirement exceeds the set mark (say, the 50% 693 mark), the link may be removed from the non-TE topology. 695 4. This document does not require any changes to the existing OSPF 696 LSDB implementation. Rather, it suggests the use of another 697 database, the TE-LSDB, comprised of the TE LSAs, for TE purposes. 699 5. As a general rule, all nodes and links that may be party 700 to a TE circuit should be uniquely identifiable by an IP 701 address. As for router ID, a separate loopback IP address 702 for the router, independent of the links attached, is 703 recommended. 705 6. The assumption about to be stated is principally meant for 706 non-packet networks such as a SONET TDM network. In non-packet 707 networks, each IP subnet on a TE-configurable network MUST have 708 a minimum of one node with an interface running OSPF-TE protocol. 709 For example, a SONET/SDH TDM ring must have a minimum of one node 710 (say, a Gateway Network Element) running the OSPF protocol in 711 order to enable TE configuration on all nodes within the ring. 713 An OSPF-TE node may advertise more than itself and the links 714 it is directly attached to. It may also advertise other TE 715 participants and their links, on their behalf. 717 5.3. Limitations 719 Below are the limitations of the OSPF-TE. 721 1. Disjoint TE topologies would have the same problem as an 722 OSPF-TE node not forming adjacencies with any other node. 723 The disjoint nodes will not be included in the TE topology 724 of the rest of the TE routers. It will be the 725 responsibility of the network administrator(s) to ensure 726 connectedness of the TE network. 728 For example, two routers that are physically connected to 729 the same link (or broadcast network) need not be router 730 adjacent via the Hello protocol, if the link is not IP 731 packet terminated. 733 6. Transition strategy for implementations using Opaque LSAs 735 Below is a strategy to transition implementations using opaque 736 LSAs to adapt the new TE LSA scheme in a gradual fashion. 738 1. Restrict the use of Opaque-LSAs to within an area. 740 2. Fold in the TE option flag to construct the TE and non-TE 741 topologies in an area, even if the topologies cannot be used 742 for flooding within the area. 744 3. Use TE-Summary LSAs and TE-AS-external-LSAs for inter-area 745 Communication. Make use of the TE-topology within area to 746 summarize the TE networks in the area and advertise the same 747 to all TE-routers in the backbone. The TE-ABRs on the backbone 748 area will in-turn advertise these summaries again within their 749 connected areas. 751 7. The OSPF Options field 753 A new TE flag is introduced within the options field to identify 754 TE extensions to the OSPF. This bit will be used to distinguish 755 between routers that support Traffic engineering extensions and 756 those that do not. The OSPF options field is present in OSPF 757 Hello packets, Database Description packets and all link state 758 advertisements. The TE bit, however, is a requirement only for 759 the Hello packets. Use of TE-bit is optional in Database 760 Description packets or LSAs. 762 Below is a description of the TE-Bit. Refer [OSPF-V2], [OSPF-NSSA] 763 and [OPAQUE] for a description of the remaining bits in options 764 field. 766 -------------------------------------- 767 |TE | O | DC | EA | N/P | MC | E | * | 768 -------------------------------------- 769 The OSPF options field - TE support 771 TE-Bit: This bit is set to indicate support for Traffic Engineering 772 extensions to the OSPF. The Hello protocol which is used for 773 establishing router adjacency and bidirectionality of the 774 link will use the TE-bit to build adjacencies between two 775 nodes that are either both TE-compliant or not. Two routers 776 will not become TE-neighbors unless they agree on the state 777 of the TE-bit. TE-compliant OSPF extensions are advertised 778 only to the TE-compliant routers. All other routers may 779 simply ignore the advertisements. 781 There is however a caveat with the above use of the last remaining 782 reserved bit in the options field. OSPF v2 will have no more 783 reserved bits left for future option extensions. If it is deemed 784 necessary to leave this bit as is, we could use OPAQUE-9 LSA (Local 785 scope) along each interface to communicate the support for OSPF-TE. 787 8. Bringing up TE adjacencies; TE vs. Non-TE topologies 789 OSPF creates adjacencies between neighboring routers for the purpose 790 of exchanging routing information. In the following subsections, we 791 describe the use of Hello protocol to establish TE capability 792 compliance between neighboring routers of an area. Further, the 793 capability is used as the basis to build a TE vs. non-TE network 794 topology. 796 8.1. The Hello Protocol 798 The Hello Protocol is primarily responsible for dynamically 799 establishing and maintaining neighbor adjacencies. In a TE network, 800 it may not be required or possible for all links and neighbors to 801 establish adjacency using this protocol. 803 The Hello protocol will use the TE-bit to establish Traffic 804 Engineering capability (or not) between two OSPF routers. 806 For NBMA and broadcast networks, this protocol is responsible for 807 electing the designated router and the backup designated router. 808 For a TDM ring network, the designated and backup designated 809 routers may either be preselected (ex: GNE, backup-GNE) or 810 determined via the same Hello protocol. In any case, routers 811 supporting the TE option shall be given a higher precedence for 812 becoming a designated router over those that do not support TE. 814 8.2. Flooding and the Synchronization of Databases 816 In OSPF, adjacent routers within an area must synchronize their 817 databases. However, as observed in [FLOOD-OPT], the requirement 818 may be stated more concisely that all routers in an area must 819 converge on the same link state database. To do that, it suffices 820 to send single copies of LSAs to the neighboring routers in an 821 area, rather than send one copy on each of the connected 822 interfaces. [FLOOD-OPT] describes in detail how to minimize 823 flooding (Initial LSDB synchronization as well as the 824 asynchronous LSA updates) within an area. 826 With the OSPF-TE described here, a TE-only network topology is 827 constructed based on the TE option flag in the Hello packet. 828 Subsequent to that, TE LSA flooding in an area is limited to 829 TE-only routers in the area, and do not impact non-TE routers 830 in the area. A network may be constituted of a combination of 831 a TE topology and a non-TE (control) topology. Standard IP 832 packet forwarding and routing protocols are possible along the 833 control topology. 835 In the case where some of the neighbors are TE compliant and 836 others are not, the designated router will exchange different 837 sets of LSAs with its neighbors. TE LSAs are exchanged only 838 with the TE neighbors. Native LSAs do not include description 839 for TE links. As such, native LSAs are exchanged with all 840 neighbors (TE and non-TE alike) over a shared non-TE link. 842 Flooding optimization in a TE network is essential 843 for two reasons. First, the control traffic for a TE network is 844 likely to be much higher than that of a non-TE network. Flooding 845 optimizations help to minimize the announcements and the 846 associated retransmissions and acknowledgements on the network. 847 Secondly, the TE nodes need to converge at the earliest to keep 848 up with TE state changes occurring throughout the TE network. 850 This process of flooding along a TE topology cannot be folded 851 into the Opaque-LSA based TE scheme ([OPQLSA-TE]), because 852 Opaque LSAs (say, LSA #10) have a pre-determined flooding 853 scope. Even as a TE topology is available from the use of 854 TE option flag, the TE topology is not usable for flooding 855 unless a new TE LSA is devised, whose boundaries can be set to 856 span the TE-only routers in an area. 858 NOTE, a new All-SPF-TE Multicast address may be used for the 859 exchange of TE compliant database descriptors. 861 8.3. The Designated Router 863 The Designated Router is elected by the Hello Protocol on broadcast 864 and NBMA networks. In general, when a router's interface to a 865 network first becomes functional, it checks to see whether there is 866 currently a Designated Router for the network. If there is, it 867 accepts that Designated Router, regardless of its Router Priority, 868 so long as the current designated router is TE compliant. Otherwise, 869 the router itself becomes Designated Router if it has the highest 870 Router Priority on the network and is TE compliant. 872 Clearly, TE-compliance must be implemented on the most robust 873 routers only, as they become most likely candidates to take on 874 additional role as designated router. 876 Alternatively, there can be two sets of designated routers, one for 877 the TE compliant routers and another for the native OSPF routers 878 (non-TE compliant). 880 8.4. The Backup Designated Router 882 The Backup Designated Router is also elected by the Hello 883 Protocol. Each Hello Packet has a field that specifies the 884 Backup Designated Router for the network. Once again, TE-compliance 885 must be weighed in conjunction with router priority in determining 886 the backup designated router. Alternatively, there can be two sets 887 of backup designated routers, one for the TE compliant routers and 888 another for the native OSPF routers (non-TE compliant). 890 8.5. The graph of adjacencies 892 An adjacency is bound to the network that the two routers have 893 in common. If two routers have multiple networks in common, 894 they may have multiple adjacencies between them. The adjacency 895 may be split into two different types - Adjacency between 896 TE-compliant routers and adjacency between non-TE compliant 897 routers. A router may choose to support one or both types of 898 adjacency. 900 Two graphs are possible, depending on whether a Designated 901 Router is elected for the network. On physical point-to-point 902 networks, Point-to-MultiPoint networks and virtual links, 903 neighboring routers become adjacent whenever they can 904 communicate directly. The adjacency can only be one of 905 (a) TE-compliant or (b) non-TE compliant. In contrast, on 906 broadcast and NBMA networks the Designated Router and the 907 Backup Designated Router may maintain two sets of adjacency. 908 However, the remaining routers will participate in either 909 TE-compliant adjacency or non-TE-compliant adjacency, but not 910 both. In the Broadcast network below, you will notice that 911 routers RT7 and RT3 are chosen as the designated and backup 912 routers respectively. Within the network, Routers RT3, RT4 913 and RT7 are TE-compliant. RT5 and RT6 are not. So, you will 914 notice the adjacency variation with RT4 vs. RT5 or RT6. 916 +---+ +---+ 917 |RT1|------------|RT2| o---------------o 918 +---+ N1 +---+ RT1 RT2 920 RT7 921 o:::::::::: 922 +---+ +---+ +---+ /|: : 923 |RT7| |RT3| |RT4| / | : : 924 +---+ +---+ +---+ / | : : 925 | | | / | : : 926 +-----------------------+ RT5o RT6o oRT4 : 927 | | N2 * * ; : 928 +---+ +---+ * * ; : 929 |RT5| |RT6| * * ; : 930 +---+ +---+ **; : 931 o:::::::::: 932 RT3 934 Figure 6: The graph of adjacencies with TE-compliant routers. 936 9. TE LSAs 938 The native OSPF protocol, as of now, has a total of 11 LSA types. 939 LSA types 1 through 5 are defined in [OSPF-v2]. LSA types 6, 7 940 and 8 are defined in [MOSPF], [NSSA] and [BGP-OSPF] respectively. 941 Lastly, LSA types 9 through 11 are defined in [OPAQUE]. 943 Each of the LSA types have a unique flooding scope defined. 944 Opaque LSA types 9 through 11 are general purpose LSAs, with 945 flooding scope set to link-local, area-local and AS-wide (except 946 stub areas) respectively. As will become apparent from this 947 document, the general purpose content format and the coarse 948 flooding scope of Opaque LSAs are not suitable for disseminating 949 TE data. 951 In the following subsections, we define new LSAs for Traffic 952 engineering use. The Values for the new TE LSA types are assigned 953 such that the high bit of the LS-type octet is set to 1. The new 954 TE LSAs are largely modeled after the existing LSAs for content 955 format and have a custom suited flooding scope. Flooding 956 optimizations discussed in previous sections shall be used to 957 disseminate TE LSAs along the TE-restricted topology. 959 A TE-router LSA is defined to advertise TE characteristics 960 of the router and all the TE-links attached to the TE-router. 961 TE-Link-Update LSA is defined to advertise individual link 962 specific TE updates. Flooding scope for both these LSAs is the 963 TE topology within the area to which the links belong. I.e., 964 only those OSPF nodes within the area with TE links will receive 965 these TE LSAs. 967 TE-Summary network and router LSAs are defined to advertise 968 the reachability of area-specific TE networks and Area border 969 routers(along with router TE characteristics) to external 970 areas. Flooding Scope of the TE-Summary LSAs is the TE topology 971 in the entire AS less the non-backbone area for which the 972 the advertising router is an ABR. Just as with native OSPF 973 summary LSAs, the TE-summary LSAs do not reveal the topological 974 details of an area to external areas. But, the two summary LSAs 975 do differ in some respects. The flooding scope of TE summary 976 LSAs is different. As for content, TE summary network LSAs 977 simply describe reachability without summarization of network 978 access costs. And, unlike the native summary router LSA, 979 TE-summary router LSA content includes TE capabilities of the 980 advertising TE router. 982 TE-AS-external LSA and TE-Circuit-Path LSA are defined to 983 advertise AS external network reachability and pre-engineered 984 TE circuits respectively. While flooding scope for both 985 these LSAs can be the TE-topology in the entire AS, flooding 986 scope for the pre-engineered TE circuit LSA may optionally be 987 restricted to just the TE topology within an area. 989 Lastly, the new TE LSAs are defined so as to permit peer 990 operation of packet networks and non-packet networks alike. 991 As such, a new TE-Router-Proxy LSA is defined to allow 992 advertisement of a TE router, that is not OSPF capable, by 993 an OSPF-TE node as a proxy. 995 9.1. TE-Router LSA (0x81) 997 The TE-router LSA (0x81) is modeled after the router LSA with the 998 same flooding scope as the router-LSA, except that the scope is 999 restricted to TE-only nodes within the area. The TE-router LSA 1000 describes the TE metrics of the router as well as the TE-links 1001 attached to the router. Below is the format of the TE-router LSA. 1002 Unless specified explicitly otherwise, the fields carry the same 1003 meaning as they do in a router LSA. Only the differences are 1004 explained below. Router-TE flags, Router-TE TLVs, Link-TE options, 1005 and Link-TE TLVs are each independently described in a separate 1006 sub-section. 1008 0 1 2 3 1009 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 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | LS age | Options | 0x81 | 1012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1013 | Link State ID | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1015 | Advertising Router | 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | LS sequence number | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | LS checksum | length | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | 0 |V|E|B| 0 | Router-TE flags | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | Router-TE flags (contd.) | Router-TE TLVs | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | .... | 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | .... | # of TE links | 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | Link ID | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | Link Data | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | Type | 0 | Link-TE flags | 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 | Link-TE flags (contd.) | Zero or more Link-TE TLVs | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | Link ID | 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 | Link Data | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 | ... | 1043 Option 1044 In TE-capable router nodes, the TE-bit may be set to 1. 1046 The following fields are used to describe each router link (i.e., 1047 interface). Each router link is typed (see the below Type field). 1048 The Type field indicates the kind of link being described. 1050 Type 1051 A new link type "Positional-Ring Type" (value 5) is defined. 1052 This is essentially a connection to a TDM-Ring. TDM ring network 1053 is different from LAN/NBMA transit network in that, nodes on the 1054 TDM ring do not necessarily have a terminating path between 1055 themselves. Secondly, the order of links is important in 1056 determining the circuit path. Third, the protection switching 1057 and the number of fibers from a node going into a ring are 1058 determined by the ring characteristics. I.e., 2-fiber vs 1059 4-fiber ring and UPSR vs BLSR protected ring. 1061 Type Description 1062 __________________________________________________ 1063 1 Point-to-point connection to another router 1064 2 Connection to a transit network 1065 3 Connection to a stub network 1066 4 Virtual link 1067 5 Positional-Ring Type. 1069 Link ID 1070 Identifies the object that this router link connects to. 1071 Value depends on the link's Type. For a positional-ring type, 1072 the Link ID shall be IP Network/Subnet number, just as with a 1073 broadcast transit network. The following table summarizes the 1074 updated Link ID values. 1076 Type Link ID 1077 ______________________________________ 1078 1 Neighboring router's Router ID 1079 2 IP address of Designated Router 1080 3 IP network/subnet number 1081 4 Neighboring router's Router ID 1082 5 IP network/subnet number 1084 Link Data 1085 This depends on the link's Type field. For type-5 links, this 1086 specifies the router interface's IP address. 1088 9.1.1. Router-TE flags - TE capabilities of the router 1090 Below is an initial set of definitions. More may be standardized 1091 if necessary. The TLVs are not expanded in the current rev. Will 1092 be done in the follow-on revs. The field imposes a restriction 1093 of no more than 32 flags to describe the TE capabilities of a 1094 router-TE. 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 |L|L|P|T|L|F| |S|S|S|C| 1098 |S|E|S|D|S|S| |T|E|I|S| 1099 |R|R|C|M|C|C| |A|L|G|P| 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1101 |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| 1103 Bit LSR 1104 When set, the router is considered to have LSR capability. 1106 Bit LER 1107 When set, the router is considered to have LER capability. 1108 All MPLS border routers will be required to have the LER 1109 capability. When the E bit is also set, that indicates an 1110 AS Boundary router with LER capability. When the B bit is 1111 also set, that indicates an area border router with LER 1112 capability. 1114 Bit PSC 1115 Indicates the node is Packet Switch Capable. 1117 Bit TDM 1118 Indicates the node is TDM circuit switch capable. 1120 Bit LSC 1121 Indicates the node is Lamda switch Capable. 1123 Bit FSC 1124 Indicates the node is Fiber (can also be a non-fiber link 1125 type) switch capable. 1127 Bit STA 1128 Label Stack Depth limit TLV follows. This is applicable only 1129 when the PSC flag is set. 1131 Bit SEL 1132 TE Selection Criteria TLV, supported by the router, follows. 1134 Bit SIG 1135 MPLS Signaling protocol support TLV follows. 1137 BIT CSPF 1138 CSPF algorithm support TLV follows. 1140 9.1.2. Router-TE TLVs 1142 The following Router-TE TLVs are defined. 1144 TE-selection-Criteria TLV (Tag ID = 1) 1146 The values can be a series of resources that may be used 1147 as the criteria for traffic engineering (typically with the 1148 aid of a signaling protocol such as RSVP-TE or CR-LDP or LDP). 1150 - Bandwidth based LSPs (1) 1151 - Priority based LSPs (2) 1152 - Backup LSP (3) 1153 - Link cost (4) 1155 Bandwidth criteria is often used in conjunction with Packet 1156 Switch Capable nodes. The unit of bandwidth permitted to be 1157 configured may however vary from vendor to vendor. Bandwidth 1158 criteria may also be used in conjunction with TDM nodes. Once 1159 again, the granularity of bandwidth allocation may vary from 1160 vendor to vendor. 1162 Priority based traffic switching is relevant only to Packet 1163 Switch Capable nodes. Nodes supporting this criteria will 1164 be able to interpret the EXP bits on the MPLS header to 1165 prioritize the traffic across the same LSP. 1167 Backup criteria refers to whether or not the node is capable 1168 of finding automatic protection path in the case the 1169 originally selected link fails. Such a local recovery is 1170 specific to the node and may not need to be notified to the 1171 upstream node. 1173 MPLS-Signaling protocol TLV (Tag ID = 3) 1174 The value can be 2 bytes long, listing a combination of 1175 RSVP-TE, CR-LDP and LDP. 1177 Constraint-SPF algorithms-Support TLV (Tag ID = 4) 1178 List all the CSPF algorithms supported. Support for CSPF 1179 algorithms on a node is an indication that the node may be 1180 requested for all or partial circuit path selection during 1181 circuit setup time. This can be beneficial in knowing 1182 whether or not the node is capable of expanding loose 1183 routes (in an MPLS signaling request) into an LSP. Further, 1184 the CSPF algorithm support on an intermediate node can be 1185 beneficial when the node terminates one or more of the 1186 hierarchical LSP tunnels. 1188 Label Stack Depth TLV (Tag ID = 5) 1189 Applicable only for PSC-Type traffic. A default value of 1 1190 is assumed. This indicates the depth of label stack the 1191 node is capable of processing on an ingress interface. 1193 9.1.3. Link-TE options - TE capabilities of a TE-link 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 |T|N|P|T|L|F|D| |S|L|B|C| 1197 |E|T|K|D|S|S|B| |R|U|W|O| 1198 | |E|T|M|C|C|S| |L|G|A|L| 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| 1202 TE - Indicates whether TE is permitted on the link. A link 1203 can be denied for TE use by setting the flag to 0. 1205 NTE - Indicates whether non-TE traffic is permitted on the 1206 TE link. This flag is relevant only when the TE 1207 flag is set. 1209 PKT - Indicates whether or not the link is capable of 1210 packet termination. 1212 TDM, LSC, FSC bits 1213 - Same as defined for router TE options. 1215 DBS - Indicates whether or not Database synchronization 1216 is permitted on this link. 1218 SRLG Bit - Shared Risk Link Group TLV follows. 1220 LUG bit - Link usage cost metric TLV follows. 1222 BWA bit - Data Link bandwidth TLV follows. 1224 COL bit - Data link Color TLV follows. 1226 9.1.4. Link-TE TLVs 1227 SRLG-TLV 1228 This describes the list of Shared Risk Link Groups the link 1229 belongs to. Use 2 bytes to list each SRLG. 1231 BWA-TLV 1232 This indicates the maximum bandwidth, available bandwidth, 1233 reserved bandwidth for later use etc. This TLV may also 1234 describe the Data link Layer protocols supported and the 1235 Data link MTU size. 1237 LUG-TLV 1238 This indicates the link usage cost - Bandwidth unit, Unit 1239 usage cost, LSP setup cost, minimum and maximum durations 1240 permitted for setting up the TLV etc., including any time 1241 of day constraints. 1243 COLOR-TLV 1244 This is similar to the SRLG TLV, in that an autonomous 1245 system may choose to issue colors to link based on a 1246 certain criteria. This TLV can be used to specify the 1247 color assigned to the link within the scope of the AS. 1249 9.2. TE-incremental-link-Update LSA (0x8d) 1251 A significant difference between a non-TE OSPF network and a TE OSPF 1252 network is that the latter is subject to dynamic circuit pinning and 1253 is more likely to undergo state updates. Specifically, some links 1254 might undergo changes more frequently than others. Advertising the 1255 entire TE-router LSA in response to a change in any single link 1256 could be repetitive. Flooding the network with TE-router LSAs at the 1257 aggregated speed of all the dynamic changes is simply not desirable. 1258 The TE-incremental-link-update LSA advertises only the incremental 1259 link updates. 1261 The TE-incremental-link-Update LSA will be advertised as frequently 1262 as the link state is changed. The TE-link sequence is largely the 1263 advertisement of a sub-portion of router LSA. The sequence number on 1264 this will be incremented with the TE-router LSA's sequence as the 1265 basis. When an updated TE-router LSA is advertised within 30 minutes 1266 of the previous advertisement, the updated TE-router LSA will assume 1267 a sequence no. that is larger than the most frequently updated of 1268 its links. 1270 Below is the format of the TE-incremental-link-update LSA. 1272 0 1 2 3 1273 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 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 | LS age | Options | 0x8d | 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | Link State ID (same as Link ID) | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | Advertising Router | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | LS sequence number | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | LS checksum | length | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | Link Data | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | Type | 0 | Link-TE options | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 | Link-TE options | Zero or more Link-TE TLVs | 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | # TOS | metric | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | ... | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | TOS | 0 | TOS metric | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 Link State ID 1299 This would be exactly the same as would have been specified as 1300 as Link ID for a link within the router-LSA. 1302 Link Data 1303 This specifies the router ID the link belongs to. In majority of 1304 cases, this would be same as the advertising router. This choice 1305 for Link Data is primarily to facilitate proxy advertisement for 1306 incremental link updates. 1308 Say, a router-proxy-LSa was used to advertise the TE-router-LSA 1309 of a SONET/TDM node. Say, the proxy router is now required to 1310 advertise incremental-link-update for the same SONET/TDM node. 1311 Specifying the actual router-ID the link in the 1312 incremental-link-update-LSA belongs to helps receiving nodes in 1313 finding the exact match for the LSA in their database. 1315 The tuple of (LS Type, LSA ID, Advertising router) uniquely identify 1316 the LSA and replace LSAs of the same tuple with an older sequence 1317 number. However, there is an exception to this rule in the context 1318 of TE-link-update LSA. TE-Link update LSA will initially assume the 1319 sequence number of the TE-router LSA it belongs to. Further, when a 1320 new TE-router LSA update with a larger sequence number is advertised, 1321 the newer sequence number is assumed by al the link LSAs. 1323 9.3. TE-Circuit-paths LSA (0x8C) 1325 TE-Circuit-paths LSA may be used to advertise the availability of 1326 pre-engineered TE circuit path(s) originating from any router in 1327 the network. The flooding scope may be Area wide or AS wide. 1329 0 1 2 3 1330 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 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | LS age | Options | 0x84 | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | Link State ID | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 | Advertising Router | 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 | LS sequence number | 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | LS checksum | length | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | 0 |S|E|B| 0 | # of TE circuit paths | 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 | TE-Link ID | 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 | TE-Link Data | 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 | Type | 0 | Link-TE flags | 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 | Link-TE flags (contd.) | Zero or more Link-TE TLVs | 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 | TE-Link ID | 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 | TE-Link Data | 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 | ... | 1358 Link State ID 1359 The ID of the router to which the TE circuit path(s) is being 1360 advertised. 1362 TE-circuit-path(s) flags 1364 Bit S - When set, the flooding scope is set to be AS wide. 1365 Otherwise, the flooding scope is set to be area wide. 1367 Bit E - When set, the advertised Link-State ID is an AS boundary 1368 router (E is for external). The advertising router and 1369 the Link State ID belong to the same area. 1371 Bit B - When set, the advertised Link state ID is an Area border 1372 router (B is for Border) 1374 No. of Virtual TE Links 1375 This indicates the number of pre-engineered TE links between the 1376 advertising router and the router specified in the link state ID. 1378 TE-Link ID 1379 This is the ID by which to identify the virtual link on the 1380 advertising router. This can be any private interface index or 1381 handle that the advertising router uses to identify the 1382 pre-engineered TE virtual link to the ABR/ASBR. 1384 TE-Link Data 1385 This specifies the IP address of the physical interface 1386 on the advertising router. 1388 9.4. TE-Summary LSAs 1390 TE-Summary-LSAs are the Type 0x83 and 0x84 LSAs. These LSAs are 1391 originated by area border routers. TE-Summary-network-LSA (0x83) 1392 describes the reachability of TE networks in a non-backbone 1393 area, advertised by the Area Border Router. Type 0x84 1394 summary-LSA describes the reachability of Area Border Routers 1395 and AS border routers and their TE capabilities. 1397 One of the benefits of having multiple areas within an AS is 1398 that frequent TE advertisements within the area do not impact 1399 outside the area. Only the TE abstractions as befitting the 1400 external areas are advertised. 1402 9.4.1. TE-Summary Network LSA (0x83) 1404 TE-summary network LSA may be used to advertise reachability of 1405 TE-networks accessible to areas external to the originating 1406 area. The content and the flooding scope of a TE-Summary LSA 1407 is different from that of a native summary LSA. 1409 The scope of flooding for a TE-summary network is AS wide, with 1410 the exception of the originating area and the stub areas. The 1411 area border router for each non-backbone area is responsible 1412 for advertising the reachability of backbone networks into the 1413 area. 1415 Unlike a native-summary network LSA, TE-summary network LSA does 1416 not advertise summary costs to reach networks within an area. 1417 This is because, TE parameters are not necessarily additive or 1418 comparative. The parameters can be varied in their expression. 1419 A TE-summary network LSA will not be know to summarize a 1420 network whose links do not fall under an SRLG (Shared-Risk Link 1421 Group). This is way, the TE-summary LSA merely advertises the 1422 reachable of TE networks within an area. The specific circuit 1423 paths can be computed by the BDRs. On the other hand, if there 1424 are specific circuit paths to advertise, that can be done 1425 independently using TE-Circuit-path LSA (refer: section 9.3) 1427 0 1 2 3 1428 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 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 | LS age | Options | 0x83 | 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | Link State ID (IP Network Number) | 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 | Advertising Router (Area Border Router) | 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 | LS sequence number | 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | LS checksum | length | 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 | Network Mask | 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 | Area-ID | 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 9.4.2. TE-Summary router LSA (0x84) 1447 TE-summary router LSA may be used to advertise the availability of 1448 Area Border Routers (ABRs) and AS Border Routers (ASBRs) that are 1449 TE capable. The TE-summary router LSAs are originated by the Area 1450 Border Routers. The scope of flooding for the TE-summary router LSA 1451 is the non-backbone area the advertising ABR belongs to. 1453 0 1 2 3 1454 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 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 | LS age | Options | 0x84 | 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 | Link State ID | 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | Advertising Router (ABR) | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 | LS sequence number | 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 | LS checksum | length | 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 | 0 |E|B| 0 | No. of Areas | 1467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 | Area-ID | 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | ... | 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 | Router-TE flags | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 | Router-TE TLVs | 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1476 | .... | 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 Link State ID 1480 The ID of the Area border router or the AS border router whose 1481 TE capability is being advertised. 1483 Advertising Router 1484 The ABR that advertises its TE capabilities (and the OSPF areas 1485 it belongs to) or the TE capabilities of an ASBR within one of 1486 the areas the ABR is a border router of. 1488 No. of Areas 1489 Specifies the number of OSPF areas the link state ID belongs to. 1491 Area-ID 1492 Specifies the OSPF area(s) the link state ID belongs to. When 1493 the link state ID is same as the advertising router ID, this 1494 lists all the areas the ABR belongs to. In the case the 1495 link state ID is an ASBR, this simply lists the area the 1496 ASBR belongs to. The advertising router is assumed to be the 1497 ABR from the same area the ASBR is located in. 1499 Summary-router-TE flags 1501 Bit E - When set, the advertised Link-State ID is an AS boundary 1502 router (E is for external). The advertising router and 1503 the Link State ID belong to the same area. 1505 Bit B - When set, the advertised Link state ID is an Area 1506 border router (B is for Border) 1507 Router-TE flags, 1508 Router-TE TLVs (TE capabilities of the link-state-ID router) 1510 TE Flags and TE TLVs are as applicable to the ABR/ASBR 1511 specified in the link state ID. The semantics is same as 1512 specified in the Router-TE LSA. 1514 9.5. TE-AS-external LSAs (0x85) 1516 TE-AS-external-LSAs are the Type 0x85 LSAs. This is modeled after 1517 AS-external LSA format and flooding scope. These LSAs are originated 1518 by AS boundary routers with TE extensions (say, a BGP node which can 1519 communicate MPLS labels across to external ASes), and describe 1520 networks and pre-engineered TE links external to the AS. The 1521 flooding scope of this LSA is similar to that of an AS-external LSA. 1522 I.e., AS wide, with the exception of stub areas. 1524 0 1 2 3 1525 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 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 | LS age | Options | 0x85 | 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 | Link State ID | 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 | Advertising Router | 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 | LS sequence number | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 | LS checksum | length | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | Network Mask | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 | Forwarding address | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | External Route Tag | 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 | # of Virtual TE links | 0 | 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 | Link-TE flags | 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 | Link-TE TLVs | 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 | ... | 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 | TE-Forwarding address | 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 | External Route TE Tag | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 | ... | 1557 Network Mask 1558 The IP address mask for the advertised TE destination. For 1559 example, this can be used to specify access to a specific 1560 TE-node or TE-link with an mask of 0xffffffff. This can also 1561 be used to specify access to an aggregated set of destinations 1562 using a different mask, ex: 0xff000000. 1564 Link-TE flags, 1565 Link-TE TLVs 1566 The TE attributes of this route. These fields are optional and 1567 are provided only when one or more pre-engineered circuits can 1568 be specified with the advertisement. Without these fields, 1569 the LSA will simply state TE reachability info. 1571 Forwarding address 1572 Data traffic for the advertised destination will be forwarded to 1573 this address. If the Forwarding address is set to 0.0.0.0, data 1574 traffic will be forwarded instead to the LSA's originator (i.e., 1575 the responsible AS boundary router). 1577 External Route Tag 1578 A 32-bit field attached to each external route. This is not 1579 used by the OSPF protocol itself. It may be used to communicate 1580 information between AS boundary routers; the precise nature of 1581 such information is outside the scope of this specification. 1583 9.6. Changes to Network LSA 1585 Network-LSA is the Type 2 LSA. With the exception of the following, 1586 no additional changes will be required to this LSA for TE 1587 compatibility. The LSA format and flooding scope remains unchanged. 1589 A network-LSA is originated for each broadcast, NBMA and 1590 Positional-Ring type network in the area which supports two or 1591 more routers. The TE option is also required to be set while 1592 propagating the TDM network LSA. 1594 9.6.1. Positional-Ring type network LSA - New Network type for TDM-ring. 1595 - Ring ID: (Network Address/Mask) 1596 - No. of elements in the ring (a.k.a. ring neighbors) 1597 - Ring Bandwidth 1598 - Ring Protection (UPSR/BLSR) 1599 - ID of individual nodes (Interface IP address) 1600 - Ring type (2-Fiber vs. 4-Fiber, SONET vs. SDH) 1601 Network LSA will be required for SONET RING. Unlike the broadcast 1602 type, the sequence in which the NEs are placed on a RING-network 1603 is pertinent. The nodes in the ting must be described clock wise, 1604 assuming the GNE as the starting element. 1606 9.7. TE-Router-Proxy LSA (0x8e) 1608 This is a variation to the TE-router LSA in that the TE-router LSA 1609 is not advertised by the network element, but rather by a trusted 1610 TE-router Proxy. This is typically the scenario in a non-packet 1611 TE network, where some of the nodes do not have OSPF functionality 1612 and count on a helper node to do the advertisement for them. One 1613 such example would be the SONET/SDH ADM nodes in a TDM ring. The 1614 nodes may principally depend upon the GNE (Gateway Network Element) 1615 to do the advertisement for them. TE-router-Proxy LSA shall not be 1616 used to advertise Area Border Routers and/or AS border Routers. 1618 0 1 2 3 1619 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 1620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 | LS age | Options | 0x8e | 1622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1623 | Link State ID (Router ID of the TE Network Element) | 1624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1625 | Advertising Router | 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 | LS sequence number | 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 | LS checksum | length | 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 | 0 | Router-TE flags | 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 | Router-TE flags (contd.) | Router-TE TLVs | 1634 +---------------------------------------------------------------+ 1635 | .... | 1636 +---------------------------------------------------------------+ 1637 | .... | # of TE links | 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 | Link ID | 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 | Link Data | 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 | Type | 0 | Link-TE options | 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 | Link-TE flags | Zero or more Link-TE TLVs | 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | Link ID | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | Link Data | 1650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1651 | ... | 1653 9.8. Others 1655 We may also introduce a new TE-NSSA LSA, similar to the native-NSSA 1656 LSA. TE-NSSA will help ensure that not all external TE routes are 1657 flooded into the NSSA area. A TE capable router can become the NSSA 1658 translator. All parameters and contents of TE-NSSA LSAs are 1659 transferred as is. 1661 10. Abstract topology representation with TE support 1663 Below, we assume a TE network that is composed of three OSPF areas, 1664 namely Area-1, Area-2 and Area-3, attached together through the 1665 backbone area. The following figure is an inter-area topology 1666 abstraction from the perspective of routers in Area-1. The 1667 abstraction is similar, but not the same, as that of the non-TE 1668 abstraction. As such, the authors claim the model is easy to 1669 understand and emulate. The abstraction illustrates reachability 1670 of TE networks and nodes in areas external to the local area and 1671 ASes external to the local AS. The abstraction also illustrates 1672 pre-engineered TE links that may be advertised by ABRs and ASBRs. 1674 Area-1 an has a single border router, ABR-A1 and no ASBRs. Area-2 1675 has an Area border router ABR-A2 and an AS border router ASBR-S1. 1676 Area-3 has two Area border routers ABR-A2 and ABR-A3; and an AS 1677 border router ASBR-S2. There may be any number of Pre-engineered 1678 TE links amongst ABRs and ASBRs. The following example assumes a 1679 single TE-link between ABR-A1 and ABR-A2; between ABR-A1 and 1680 ABR-A3; between ABR-A2 to ASBR-S1; and between ABR-A3 to ASBR-S2. 1681 All Area border routers and AS border routers are assumed to 1682 be represented by their TE capabilities. 1684 +-------+ 1685 |Area-1 | 1686 +-------+ 1687 +-------------+ | 1688 |Reachable TE | +------+ 1689 |networks in |--------|ABR-A1| 1690 |backbone area| +------+ 1691 +-------------+ | | | 1692 +-------------+ | +-------------------+ 1693 | | | 1694 +-----------------+ | +-----------------+ 1695 |Pre-engineered TE| +----------+ |Pre-engineered TE| 1696 |circuit path(s) | | Backbone | |circuit path(s) | 1697 |to ABR-A2 | | Area | |to ABR-A3 | 1698 +-----------------+ +----------+ +-----------------+ 1699 | | | | 1700 +----------+ | | | 1701 | | +--------------+ | 1702 +-----------+ | | | | +-----------+ 1703 |Reachable | +------------+ +------+ |Reachable | 1704 |TE networks|---| ABR-A2 | |ABR-A3|--|TE networks| 1705 |in Area A2 | +------------+ +------+ |in Area A3 | 1706 +-----------+ / | | | | | +-----------+ 1707 / | | +-------------------+ | +----------+ 1708 / | +-------------+ | | | 1709 +-----------+ +--------------+ | | | +--------------+ 1710 |Reachable | |Pre-engineered| | | | |Pre-engineered| 1711 |TE networks| |TE Ckt path(s)| +------+ +------+ |TE Ckt path(s)| 1712 |in Area A3 | |to ASBR-S1 | |Area-2| |Area-3| |to ASBR-S2 | 1713 +-----------+ +--------------+ +------+ +------+ +--------------+ 1714 | / | / 1715 +-------------+ | / | / 1716 |AS external | +---------+ +-------------+ 1717 |TE-network |------| ASBR-S1 | | ASBR-S2 | 1718 |reachability | +---------+ +-------------+ 1719 |from ASBR-S1 | | | | 1720 +-------------+ | | | 1721 +-----------------+ +-------------+ +-----------------+ 1722 |Pre-engineered TE| |AS External | |Pre-engineered TE| 1723 |circuit path(s) | |TE-Network | |circuit path(s) | 1724 |reachable from | |reachability | |reachable from | 1725 |ASBR-S1 | |from ASBR-S2 | |ASBR-S2 | 1726 +-----------------+ +-------------+ +-----------------+ 1728 Figure 9: Inter-Area Abstraction as viewed by Area-1 TE-routers 1730 11. Changes to Data structures in OSPF-TE nodes 1732 11.1. Changes to Router data structure 1734 The router with TE extensions must be able to include all the 1735 TE capabilities (as specified in section 7.1) in the router data 1736 structure. Further, routers providing proxy service to other TE 1737 routers must also track the router and associated interface data 1738 structures for all the TE client nodes for which the proxy 1739 service is being provided. Presumably, the interaction between 1740 the Proxy server and the proxy clients is out-of-band. 1742 11.2. Two set of Neighbors 1744 Two sets of neighbor data structures will need to be maintained. 1745 TE-neighbors set is used to advertise TE LSAs. Only the TE-nodes 1746 will be members of the TE-neighbor set. Native neighbors set will 1747 be used to advertise native LSAs. All neighboring nodes supporting 1748 non-TE links can be part of this set. As for flooding optimizations 1749 based on neighbors set, readers may refer [FLOOD-OPT]. 1751 11.3. Changes to Interface data structure 1753 The following new fields are introduced to the interface data 1754 structure. These changes are in addition to the changes specified 1755 in [FLOOD-OPT]. 1757 TePermitted 1758 If the value of the flag is TRUE, the interface is permissible 1759 to be advertised as a TE-enabled interface. 1761 NonTePermitted 1762 If the value of the flag is TRUE, the interface permits non-TE 1763 traffic on the interface. Specifically, this is applicable to 1764 packet networks, where data links may permit both TE and non-TE 1765 packets. For FSC and LSC TE networks, this flag will be set to 1766 FALSE. For Packet networks that do not permit non-TE traffic on 1767 TE links also, this flag is set to TRUE. 1769 PktTerminated 1770 If the value of the flag is TRUE, the interface terminates 1771 Packet data and hence may be used for IP and OSPF data exchange. 1773 AdjacencySychRequired 1774 If the value of the flag is TRUE, the interface may be used to 1775 synchronize the LSDB across all adjacent neighbors. This is 1776 TRUE by default to all PktTerminated interfaces that are 1777 enabled for OSPF. However, it is possible to set this to FALSE 1778 for some of the interfaces. 1780 TE-TLVs 1781 Each interface may potentially have a maximum of 16 TLVS that 1782 describe the link characteristics. 1784 The following existing fields in Interface data structure will take 1785 on additional values to support TE extensions. 1787 Type 1788 The OSPF interface type can also be of type "Positional-RING". 1789 The Positional-ring type is different from other types (such 1790 as broadcast and NBMA) in that the exact location of the nodes 1791 on the ring is relevant, even as they are all on the same 1792 ring. SONET ADM ring is a good example of this. Complete ring 1793 positional-ring description may be provided by the GNE on a 1794 ring as a TE-network LSA for the ring. 1796 List of Neighbors 1797 The list may be statically defined for an interface, without 1798 requiring the use of Hello protocol. 1800 12. IANA Considerations 1802 12.1. TE-compliant-SPF routers Multicast address allocation 1804 12.2. New TE-LSA Types 1806 12.3. New TLVs (Router-TE and Link-TE TLVs) 1808 12.3.1. TE-selection-Criteria TLV (Tag ID = 1) 1809 - Bandwidth based LSPs (1) 1810 - Priority based LSPs (2) 1811 - Backup LSP (3) 1812 - Link cost (4) 1814 12.3.2. MPLS-Signaling protocol TLV (Tag ID = 3) 1815 - RSVP-TE signaling 1816 - LDP signaling 1817 - CR-LDP signaling 1819 12.3.3. Constraint-SPF algorithms-Support TLV (Tag ID = 4) 1820 - CSPF Algorithm Codes. 1822 12.3.4. SRLG-TLV (Tag ID = 0x81) 1823 - SRLG group IDs 1824 12.3.5. BW-TLV (Tag ID = 0x82) 1826 12.3.6 CO-TLV (Tag ID = 0x83) 1828 13. Acknowledgements 1830 The authors wish to thank Vishwas Manral, Chitti Babu, Riyad 1831 Hartani and Tricci So for their valuable comments and feedback 1832 on the draft. 1834 14. Security Considerations 1836 This memo does not create any new security issues for the OSPF 1837 protocol. Security considerations for the base OSPF protocol are 1838 covered in [OSPF-v2]. As a general rule, a TE network is likely 1839 to generate significantly more control traffic than a native 1840 OSPF network. The excess traffic is almost directly proportional 1841 to the rate at which TE circuits are setup and torn down within 1842 an autonomous system. It is important to ensure that TE database 1843 synchronizations happen quickly when compared to the aggregate 1844 circuit setup an tear-down rates. 1846 REFERENCES 1848 [IETF-STD] Bradner, S., " The Internet Standards Process -- 1849 Revision 3", RFC 1602, IETF, October 1996. 1851 [RFC 1700] J. Reynolds and J. Postel, "Assigned Numbers", 1852 RFC 1700 1854 [MPLS-TE] Awduche, D., et al, "Requirements for Traffic 1855 Engineering Over MPLS," RFC 2702, September 1999. 1857 [GMPLS-TE] P.A. Smith et. al, "Generalized MPLS - Signaling 1858 Functional Description", work in progress, 1859 draft-ietf-mpls-generalized-signaling-03.txt 1861 [RSVP-TE] Awduche, D., L. Berger, D. Gan, T. Li, V. Srinivasan, 1862 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1863 Tunnels", RFC3209, IETF, December 2001 1865 [CR-LDP] Jamoussi, B. et al, "Constraint-Based LSP Setup 1866 using LDP", draft-ietf-mpls-cr-ldp-06.txt, 1867 Work in Progress. 1869 [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1871 [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, 1872 March 1994. 1874 [NSSA] Coltun, R., V. Fuller and P. Murphy, "The OSPF NSSA 1875 Option", draft-ietf-ospf-nssa-update-10.txt, Work in 1876 Progress. 1878 [OPAQUE] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, 1879 July 1998. 1881 [FLOOD-OPT] Zinin, A. and M. Shand, "Flooding Optimizations in 1882 link-state routing protocols", work in progress, 1883 1885 [OPQLSA-TE] Katz, D., D. Yeung and K. Kompella, "Traffic 1886 Engineering Extensions to OSPF", work in progress, 1887 1889 [OPQLSA-GMPLS] Kompella, K., Y. Rekhter, A. Banerjee, J. Drake, 1890 G. Bernstein, D. Fedyk, E. Mannie, D. Saha and 1891 V. Sharma, "OSPF Extensions in Support of Generalized 1892 MPLS", , 1893 work in progress. 1895 Authors' Addresses 1897 Pyda Srisuresh 1898 Kuokoa Networks, Inc. 1899 2901 Tasman Dr., Suite 202 1900 Santa Clara, CA 95054 1901 U.S.A. 1902 EMail: srisuresh@yahoo.com 1904 Paul Joseph 1905 Vivace Networks 1906 2730 Orchard Parkway 1907 San Jose, CA 95134 1908 U.S.A. 1909 Tel: (408) 432 7655 1910 EMail: paul.joseph@vivacenetworks.com