idnits 2.17.1 draft-srisuresh-ospf-te-01.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 an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 223 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 378: '...nfigurable network MUST have a minimum...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 391 has weird spacing: '...niquely ident...' == Line 751 has weird spacing: '...sources that ...' == Line 925 has weird spacing: '...bes the reach...' == Line 1639 has weird spacing: '...TE link ineff...' == Line 1710 has weird spacing: '...LSAs as descr...' -- 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 417, but not defined == Missing Reference: 'MPLS-ARCH' is mentioned on line 211, but not defined == Missing Reference: 'OSPF-NSSA' is mentioned on line 417, but not defined == Missing Reference: 'BGP-OSPF' is mentioned on line 589, but not defined == Unused Reference: 'IETF-STD' is defined on line 1778, but no explicit reference was found in the text == Unused Reference: 'RFC 1700' is defined on line 1781, but no explicit reference was found in the text == Unused Reference: 'OSPF-FL2' is defined on line 1817, 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 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-rsvp-lsp-tunnel-08 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-cr-ldp-05 ** 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. '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 (~~), 17 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 January 20, 2002 P. Joseph 5 Jasmine Networks 6 July, 2001 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 well established link state routing protocol used for 35 topology discovery and computing forwarding table based on 36 shortest-Path criteria. Traffic Engineering extensions (OSPF-TE) 37 will use criteria different from shortest-path so as to route 38 traffic around congestion paths and meet varying Service Level 39 agreements. OSPF-TE may also be used by non-IP networks such as 40 photonic and TDM (SONET/SDH) circuit switch networks for 41 light-path or TDM circuit setup between two end-points. The 42 approach outlined in this document differs from that of 43 [OPQLSA-TE]. The document does not suggest the use of Opaque LSAs 44 to add TE extensions to OSPF. Rather, new TE LSAs, modeled after 45 existing LSAs and flooding scope are proposed to overcome the 46 scaling limitations of the approach outlined in [OPQLSA-TE]. The 47 document draws a distinction between TE and non-TE topologies and 48 restricts flooding of TE LSAs into non-TE topology. The document 49 covers OSPF extensions for packet and non-packet networks alike, 50 providing a unified extension mechanism for all networks. As such, 51 this approach improves interoperability between peer network 52 elements. Lastly, the document specifies a transition path for 53 vendors currently using opaque LSAs to transition to using new 54 TE LSAs outlined here. 56 Table of Contents 58 1. Introduction ................................................3 59 2. Traffic Engineering .........................................4 60 3. Terminology .................................................5 61 3.1. OSPF-TE router (or) TE-compliant OSPF router ...........5 62 3.2. Native OSPF router .....................................5 63 3.3. TE nodes vs. non-TE (native) nodes .....................6 64 3.4. TE links vs. non-TE (native) links .....................6 65 3.5. Packet interface vs. non-packet interface ..............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. Motivation and Implicit assumptions for the TE extensions ...7 71 5. The OSPF Options field ......................................9 72 6. Bringing up TE adjacencies; TE vs. Non-TE topologies .......10 73 6.1. The Hello Protocol ...................................10 74 6.2. Flooding and the Synchronization of Databases .........10 75 6.3. The Designated Router ................................11 76 6.4. The Backup Designated Router .........................12 77 6.5. The graph of adjacencies .............................12 78 7. TE LSAs ....................................................13 79 7.1. TE-Router LSA .........................................14 80 7.2. Changes to Network LSA ................................20 81 7.2.1. Positional-Ring type network LSA ...............20 82 7.3. TE-Summary LSAs .......................................20 83 7.3.1. TE-Summary Network LSA (0x83) ..................20 84 7.3.2. TE-Summary router LSA (0x84) ...................21 85 7.4. TE-AS-external LSAs (0x85) ............................23 86 7.5. TE-Circuit-paths LSA (0x8C) ...........................24 87 7.6. TE-Link-Update LSA (0x8d) .............................25 88 7.7. TE-Router-Proxy LSA (0x8e) ............................27 89 8. Link State Databases .......................................28 90 9. Abstract topology representation with TE support ...........29 91 10. Changes to Data structures in OSPF-TE routers ..............32 92 10.1. Changes to Router data structure .....................32 93 10.2. Two set of Neighbors .................................32 94 10.3. Changes to Interface data structure ..................32 95 11. Motivations to this approach ...............................33 96 11.1. TE flooding isolated to TE-only nodes ................33 97 11.2. Clean separation between native and TE LSDBs .........34 98 11.3. Scalability across a hierarchical Area topology ......35 99 11.4. Usable across packet and non-packet TE networks ......35 100 11.5. SLA enforceable network modeling .....................36 101 11.6. Framework for future extensibility ...................36 102 11.7. Real-world scenarios benefiting from this approach ...37 103 12. Transition strategy for implementations using Opaque LSAs ..37 104 13. IANA Considerations ........................................38 105 13.1. TE-compliant-SPF routers Multicast address allocation 38 106 13.2. New TE-LSA Types .....................................38 107 13.3. New TLVs (Router-TE and Link-TE TLVs) ................38 108 13.3.1. TE-selection-Criteria TLV (Tag ID = 1) .......38 109 13.3.2. MPLS-Signaling protocol TLV (Tag ID = 3) .....38 110 13.3.3. Constraint-SPF algorithms-Support TLV (Tag ID=4) 111 13.3.4. SRLG-TLV (Tag ID = 0x81) .....................38 112 13.3.5. BW-TLV (Tag ID = 0x82) .......................38 113 13.3.6. CO-TLV (Tag ID = ox83) .......................38 114 14. Acknowledgements ...........................................39 115 15. Security Considerations ....................................39 116 References .....................................................40 118 1. Introduction 120 There is substantial industry experience with deploying OSPF link 121 state routing protocol. That makes OSPF a good candidate to adapt 122 for traffic engineering purposes. The dynamic discovery of network 123 topology, flooding algorithm and the hierarchical organization of 124 areas can all be used effectively in creating and tearing traffic 125 links on demand. The intent of the document is to build an abstract 126 view of the topology in conjunction with the traffic engineering 127 characteristics of the nodes and links involved. 129 The connectivity topology may remain relatively stable, except when 130 the existing links or networking nodes go down or flap or new nodes 131 and links are added to the network. The objective of traffic 132 engineering is to set up circuit path(s) across a pair of nodes or 133 links, as the case may be, so as to forward traffic of a certain 134 forwarding equivalency class. Circuit emulation in a packet network 135 is accomplished by each MPLS intermediary node performing label 136 swapping. Whereas, circuit emulation in a TDM or Fiber cross-connect 137 network is accomplished by configuring the switch fabric in each 138 intermediary node to do the appropriate switching (TDM, fiber or 139 Lamda) for the duration of the circuit. 141 The objective of this document is not how to set up traffic circuits, 142 but rather provide the necessary TE parameters for the nodes and 143 links that constitute the TE topology. Unlike the traditional OSPF, 144 the TE extended OSPF will be used to build circuit paths, meeting 145 certain TE criteria. The only requirement is that end-nodes and/or 146 end-links of a circuit be identifiable with an IP address. For 147 non-IP networks (such as TDM or photonic cross connect networks), 148 Mapping IP addresses to a well-known name can be done through a 149 DNS-like mechanism. 151 The approach suggested in this document is different from the 152 Opaque-LSA-based approach outlined in [OPQLSA-TE]. Section 11 153 describes the motivations behind conceiving this approach and 154 why the authors claim the benefits of the approach significantly 155 substantial over the opaque LSA based approach. Section 12 156 outlines a strategy to transition from Opaque-LSA based deployments 157 to the new-TE-LSA approach outlined here. 159 2. Traffic Engineering 161 A traffic engineered circuit may be identified by the tuple of 162 (Forwarding Equivalency Class, TE parameters for the circuit, 163 Origin Node/Link, Destination node/Link). 165 The forwarding Equivalency class(FEC) may be constituted of a number 166 of criteria such as (a) Traffic arriving on a specific interface, 167 (b) Traffic meeting a certain classification criteria (ex: based on 168 fields in the IP and transport headers), (c) Traffic in a certain 169 priority class, (d) Traffic arriving on a specific set of TDM (STS) 170 circuits on an interface, (e) Traffic arriving on a certain 171 wave-length of an interface, (f) Traffic arriving at a certain time 172 of day, and so on. A FEC may be constituted as a combination of one 173 or more of the above criteria. Discerning traffic based on the FEC 174 criteria is a mandatory requirement on Label Edge Routers (LERs). 175 Traffic content is transparent to the Intermediate Label Switched 176 Routers (LSRs), once a circuit is formed. LSRs are simply 177 responsible for keeping the circuit in-tact for the lifetime of the 178 circuit(s). As such, this document will not address FEC or the 179 associated signaling to setup circuits. [MPLS-TE] and [GMPLS-TE] 180 address the FEC criteria. Whereas, [RSVP-TE] and [CR-LDP] address 181 different types of signaling protocols. 183 As for TE parameters for the circuit, this refers to the TE 184 parameters for all the nodes and links constituting a circuit. 185 Typically, TE parameters for a node in a TE circuit may include 186 the following. 188 * Traffic prioritization ability, 189 * Ability to provision bandwidth on interfaces, 190 * Support of CSPF algorithms, 191 * TE-Circuit switch type, 192 * Automatic protection switching. 194 TE parameters for the link include: 196 * Bandwidth availability, 197 * reliability of the link, 198 * color assigned to the link 199 * cost of bandwidth usage on the link. 200 * membership to a Shared Risk Link Group and so on. 202 Only the unicast paths circuit paths are considered here. Multicast 203 variations are currently considered out of scope for this document. 204 The requirement is that the originating as well as the terminating 205 entities of a TE path are identifiable by their IP address. 207 3. Terminology 209 Definitions for majority of the terms used in this document with 210 regard to OSPF protocol may be found in [OSPF-V2]. MPLS and traffic 211 engineering terms may be found in [MPLS-ARCH]. RSVP-TE and CR-LDP 212 signaling specific terms may be found in [RSVP-TE] and [CR-LDP] 213 respectively. 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 217 this document are to be interpreted as described in RFC 2119. 219 Below are definitions for the terms used within this document. 221 3.1. OSPF-TE node (or) TE-compliant OSPF node 223 This is a router that supports the OSPF TE extensions described 224 in this document and at least one of the attached links support TE 225 extensions. Further, this requires that at least one of the 226 attached links support Packet termination and run the OSPF-TE 227 protocol. 229 An OSPF-TE node supports native OSPF as well as the TE extensions 230 outlined here. 232 3.2. Native OSPF router 234 A native OSPF router is an OSPF router that does not support 235 the TE extensions described in this document or does not have 236 a TE link attached to it. An autonomous system (AS) could be 237 constituted of a combination of native-OSPF and OSPF-TE nodes. 239 A native OSPF router, when enhanced to include the extensions 240 described in this document can become a OSPF-TE node. 242 3.3. TE nodes vs. non-TE (native) nodes 244 A TE-Node is an intermediate or edge node taking part in the 245 traffic engineered (TE) network. Specifically, a TE circuit 246 is constituted of a series of TE nodes connected to each other 247 via the TE links. 249 A non-TE node or a native node is a node that does not have any 250 TE links attached to it and does not take part in a TE network. 251 Specifically, native OSPF nodes that do not take part in a TE 252 network fall under this category. 254 3.4. TE links vs. non-TE (native) links 256 A TE Link is a network attachment that supports traffic 257 engineering. Specifically, a TE circuit can only be setup using 258 a combination of TE nodes and TE links connected to each other. 260 Non-TE link or a native link is one that supports IP packet 261 communication, but does not support traffic engineering on the 262 link. For example, native OSPF protocol and least-cost criteria 263 may be used to determine reachability of subnets in a network 264 constituted of native OSPF nodes and native OSPF links. 266 3.5. Packet interface vs. non-packet interface 268 Interfaces on an OSPF-TE node may be characterized as those that 269 terminate (i.e., send and receive) IP packet data and those that 270 do not. Both types of links can be part of a traffic engineered 271 network. In contrast, a native OSPF router does not support 272 non-packet interfaces. 274 Needless to say, the OSPF protocol and its TE extensions can only 275 be enabled on interfaces supporting IP packet termination. While 276 the OSPF protocol can be run only on interfaces terminating IP 277 packets - the protocol can advertise link state information of 278 non-packet interfaces attached to it - thereby allowing for traffic 279 engineering over non-packet links. For example - control interfaces 280 can advertise link state information of the SONET interfaces on a 281 SONET Add-Drop Multiplexer. 283 3.6. TE topology vs. non-TE topology 284 A TE topology is constituted of a set of contiguous TE nodes and 285 TE links. Associated with each TE node and TE link is a set of TE 286 criteria that may be supported at any given time. A TE topology 287 allows circuits to be overlayed statically or dynamically based 288 on a specific TE criteria. 290 A non-TE topology specifically refers to the network that does not 291 support TE. Control protocols such as OSPF may be run on the non-TE 292 topology. IP forwarding table used to forward IP packets on this 293 network is built based on the control protocol specific algorithm, 294 such as OSPF shortest-path criteria. 296 3.7. TLV 298 A TLV, strictly stands for an object in the form of Tag-Length-Value. 299 However, this term is also used in the document, at times, to simply 300 refer a Traffic Engineering attribute of a TE-node or TE-link. 302 All TLVs are assumed to be of the following format, unless specified 303 otherwise. The Tag and length are 16 bits wide each. The length 304 includes the 4 bytes required for Tag and Length specification. 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Tag | Length (4 or more) | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Value .... | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | .... | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 3.8. Router-TE TLVs 318 TLVs used to describe the TE capabilities of a TE-node. 320 3.9. Link-TE TLVs 322 TLVs used to describe the TE capabilities of a TE-link. 324 4. Motivation and Implicit assumptions for the TE extensions 326 The motivation behind the OSPF-TE described in this document is to 327 dynamically discover the TE-network topology, devise a scalable 328 flooding methodology and benefit from the hierarchical area 329 organization and other techniques of the native OSPF. The result 330 would be the ability to build an abstract view of a network 331 topology with all the traffic engineering characteristics. 333 With traditional OSPF, the goal is to build a forwarding table to 334 reach various subnets in the IP network with least-cost as the 335 basis. However, the goal of OSPF-TE is to determine a circuit path 336 (that can be pinned-down for a desired duration) meeting a certain 337 set of traffic engineering criteria. Further, the circuit path 338 could consist entirely of nodes and links that do not carry IP 339 traffic. 341 The following assumptions are made throughout the document for 342 the discussion of OSPF-TE. 344 1. Interfaces on an OSPF-TE node may be characterized as those 345 that can terminate (i.e., send and receive) IP packet data and 346 those that wont. Both types of links can be part of a traffic 347 engineered network. Needless to say, the OSPF-TE protocol can 348 only be enabled on interfaces that support IP packet data 349 termination. As such, the control network over which TE LSAs 350 are exchanged may be constituted of a combination of non-TE 351 links and TE links that also permit non-TE packet traffic. 353 2. Unlike traditional OSPF, OSPF-TE protocol must be capable of 354 advertising link state of interfaces that are not capable of 355 handling packet data. As such, the OSPF-TE protocol cannot be 356 required to synchronize its link-state database with neighbors 357 across all its links. It is sufficient to synchronize 358 link-state database in an area, across a subset of the links - 359 say, the packet terminating interfaces. Yet, the TE LSDB 360 (LSA database) should be synchronized across all OSPF-TE nodes 361 within an area. 363 All interfaces or links described by the TE LSAs will be 364 present in the TE topology database (a.k.a. TE LSDB). 366 3. An OSPF-TE node with links in an OSPF area will need to 367 establish router adjacency with at least one other neighboring 368 OSPF-TE node in order for the router's database to be 369 synchronized with other routers in the area. Failing this, the 370 OSPF router will not be in the TE calculations of other TE 371 routers in the area. Refer [OSPF-FL1] for flooding 372 optimizations. 374 However, two routers that are physically connected to the same 375 link (or broadcast network) neednt be router adjacent via the 376 Hello protocol, if the link is not packet terminated. 378 4. Each IP subnet on a TE-configurable network MUST have a minimum 379 of one node with an interface running OSPF-TE protocol. This is 380 despite the fact that all nodes on the subnet may take part in 381 Traffic Engineering. (Example: SONET/SDH TDM ring with a single 382 Gateway Network Element, a.k.a. GNE running the OSPF protocol, 383 yet all other nodes in the ring are also full members of a TE 384 circuit). 386 An OSPF-TE node may advertise more than itself and the links 387 it is directly attached to. It may also advertise other TE 388 participants and their links, on their behalf. 390 5. As a general rule, all nodes and links that may be party 391 to a TE circuit should be uniquely identifiable by an IP 392 address. As for router ID, a separate loopback IP address 393 for the router, independent of the links attached, is 394 recommended. 396 6. This document does not require any changes to the existing OSPF 397 LSDB implementation. Rather, it suggests the use of another 398 database, the TE-LSDB, comprised of the TE LSAs, for TE 399 purposes. TE nodes may have 2 types of link state databases - 400 a native OSPF LSDB and a TE-LSDB. A native OSPF LSDB, 401 constituted of native links and nodes attached to these links 402 (i.e., non-TE as well as TE nodes), will use shortest-path 403 criteria to forward IP packets over native links. The TE-LSDB, 404 constituted only of TE nodes and TE links, may be used to setup 405 TE circuit paths along the TE topology. 407 5. The OSPF Options field 409 A new TE flag is introduced to identify TE extensions to the OSPF. 410 With this, the OSPF v2 will have no more reserved bits left for 411 future option extensions. This bit will be used to distinguish 412 between routers that support Traffic engineering extensions and 413 those that do not. 415 The OSPF options field is present in OSPF Hello packets, Database 416 Description packets and all link state advertisements. See 417 [OSPF-V2], [OSPF-NSSA] and [OPAQUE] for a description of the 418 bits in options field. Only the TE-Bit is described in this 419 section. 421 -------------------------------------- 422 |TE | O | DC | EA | N/P | MC | E | * | 423 -------------------------------------- 424 The OSPF options field - TE support 426 TE-Bit: This bit is set to indicate support for Traffic Engineering 427 extensions to the OSPF. The Hello protocol which is used for 428 establishing router adjacency and bidirectionality of the 429 link will use the TE-bit to build adjacencies between two 430 nodes that are either both TE-compliant or not. Two routers 431 will not become TE-neighbors unless they agree on the state 432 of the TE-bit. TE-compliant OSPF extensions are advertised 433 only to the TE-compliant routers. All other routers may 434 simply ignore the advertisements. 436 6. Bringing up TE adjacencies; TE vs. Non-TE topologies 438 OSPF creates adjacencies between neighboring routers for the purpose 439 of exchanging routing information. In the following subsections, we 440 describe the use of Hello protocol to establish TE capability 441 compliance between neighboring routers of an area. Further, the 442 capability is used as the basis to build a TE vs. non-TE network 443 topology. 445 6.1. The Hello Protocol 447 The Hello Protocol is primarily responsible for dynamically 448 establishing and maintaining neighbor adjacencies. In a TE network, 449 it may not be required or possible for all links and neighbors to 450 establish adjacency using this protocol. 452 The Hello protocol will use the TE-bit to establish Traffic 453 Engineering capability (or not) between two OSPF routers. 455 For NBMA and broadcast networks, this protocol is responsible for 456 electing the designated router and the backup designated router. 457 For a TDM ring network, the designated and backup designated 458 routers may either be preselected (ex: GNE, backup-GNE) or 459 determined via the same Hello protocol. In any case, routers 460 supporting the TE option shall be given a higher precedence 461 for becoming a designated router over those that donot support TE. 463 6.2. Flooding and the Synchronization of Databases 465 In OSPF, adjacent routers within an area must synchronize their 466 databases. However, as observed in [OSPF-FL1], the requirement 467 may be stated more concisely that all routers in an area must 468 converge on the same link state database. To do that, it suffices 469 to send single copies of LSAs to the neighboring routers in an 470 area, rather than send one copy on each of the connected 471 interfaces. [OSPF-FL1] describes in detail how to minimize 472 flooding (Initial LSDB synchronization as well as the 473 asynchronous LSA updates) within an area. 475 With the OSPF-TE described here, a TE-only network topology is 476 constructed based on the TE option flag in the Hello packet. 477 Subsequent to that, TE LSA flooding in an area is limited to 478 TE-only routers in the area, and do not impact non-TE routers 479 in the area. A network may be constituted of a combination of 480 a TE topology and a non-TE (control) topology. Standard IP 481 packet forwarding and routing protocols are possible along the 482 control topology. 484 In the case where some of the neighbors are TE compliant and 485 others are not, the designated router will exchange different 486 sets of LSAs with its neighbors. TE LSAs are exchanged only 487 with the TE neighbors. Native LSAs do not include description 488 for TE links. As such, native LSAs are exchanged with all 489 neighbors (TE and non-TE alike) over a shared non-TE link. 491 Flooding optimization in a TE network is essential 492 for two reasons. First, the control traffic for a TE network is 493 likely to be much higher than that of a non-TE network. Flooding 494 optimizations help to minimize the announcements and the 495 associated retransmissions and acknowledgements on the network. 496 Secondly, the TE nodes need to converge at the earliest to keep 497 up with TE state changes occurring throughout the TE network. 499 This process of flooding along a TE topology cannot be folded 500 into the Opaque-LSA based TE scheme ([OPQLSA-TE]), because 501 Opaque LSAs (say, LSA #10) have a pre-determined flooding 502 scope. Even as a TE topology is available from the use of 503 TE option flag, the TE topology is not usable for flooding 504 unless a new TE LSA is devised, whose boundaries can be set to 505 span the TE-only routers in an area. 507 NOTE, a new All-SPF-TE Multicast address may be used for the 508 exchange of TE compliant database descriptors. 510 6.3. The Designated Router 512 The Designated Router is elected by the Hello Protocol on broadcast 513 and NBMA networks. In general, when a router's interface to a 514 network first becomes functional, it checks to see whether there is 515 currently a Designated Router for the network. If there is, it 516 accepts that Designated Router, regardless of its Router Priority, 517 so long as the current designated router is TE compliant. Otherwise, 518 the router itself becomes Designated Router if it has the highest 519 Router Priority on the network and is TE compliant. 521 Clearly, TE-compliance must be implemented on the most robust 522 routers only, as they become most likely candidates to take on 523 additional role as designated router. 525 Alternatively, there can be two sets of designated routers, one for 526 the TE compliant routers and another for the native OSPF routers 527 (non-TE compliant). 529 6.4. The Backup Designated Router 531 The Backup Designated Router is also elected by the Hello 532 Protocol. Each Hello Packet has a field that specifies the 533 Backup Designated Router for the network. Once again, TE-compliance 534 must be weighed in conjunction with router priority in determining 535 the backup designated router. Alternatively, there can be two sets 536 of backup designated routers, one for the TE compliant routers and 537 another for the native OSPF routers (non-TE compliant). 539 6.5. The graph of adjacencies 541 An adjacency is bound to the network that the two routers have 542 in common. If two routers have multiple networks in common, 543 they may have multiple adjacencies between them. The adjacency 544 may be split into two different types - Adjacency between 545 TE-compliant routers and adjacency between non-TE compliant 546 routers. A router may choose to support one or both types of 547 adjacency. 549 Two graphs are possible, depending on whether a Designated 550 Router is elected for the network. On physical point-to-point 551 networks, Point-to-MultiPoint networks and virtual links, 552 neighboring routers become adjacent whenever they can 553 communicate directly. The adjacency can only be one of 554 (a) TE-compliant or (b) non-TE compliant. In contrast, on 555 broadcast and NBMA networks the Designated Router and the 556 Backup Designated Router may maintain two sets of adjacency. 557 However, the remaining routers will participate in either 558 TE-compliant adjacency or non-TE-compliant adjacency, but not 559 both. In the Broadcast network below, you will notice that 560 routers RT7 and RT3 are chosen as the designated and backup 561 routers respectively. Within the network, Routers RT3, RT4 562 and RT7 are TE-compliant. RT5 and RT6 are not. So, you will 563 notice the adjacency variation with RT4 vs. RT5 or RT6. 565 +---+ +---+ 566 |RT1|------------|RT2| o---------------o 567 +---+ N1 +---+ RT1 RT2 569 RT7 570 o:::::::::: 571 +---+ +---+ +---+ /|: : 572 |RT7| |RT3| |RT4| / | : : 573 +---+ +---+ +---+ / | : : 574 | | | / | : : 575 +-----------------------+ RT5o RT6o oRT4 : 576 | | N2 * * ; : 577 +---+ +---+ * * ; : 578 |RT5| |RT6| * * ; : 579 +---+ +---+ **; : 580 o:::::::::: 581 RT3 583 Figure 6: The graph of adjacencies with TE-compliant routers. 585 7. TE LSAs 587 The native OSPF protocol, as of now, has a total of 11 LSA types. 588 LSA types 1 through 5 are defined in [OSPF-v2]. LSA types 6, 7 589 and 8 are defined in [MOSPF], [NSSA] and [BGP-OSPF] respectively. 590 Lastly, LSA types 9 through 11 are defined in [OPAQUE]. 592 Each of the LSA types have a unique flooding scope defined. 593 Opaque LSA types 9 through 11 are general purpose LSAs, with 594 flooding scope set to link-local, area-local and AS-wide (except 595 stub areas) respectively. As will become apparent from this 596 document, the general purpose content format and the coarse 597 flooding scope of Opaque LSAs are not suitable for disseminating 598 TE data. 600 In the following subsections, we define new LSAs for Traffic 601 engineering use. The Values for the new TE LSA types are assigned 602 such that the high bit of the LS-type octet is set to 1. The new 603 TE LSAs are largely modeled after the existing LSAs for content 604 format and have a custom suited flooding scope. Flooding 605 optimizations discussed in previous sections shall be used to 606 disseminate TE LSAs along the TE-restricted topology. 608 A TE-router LSA is defined to advertise TE characteristics 609 of the router and all the TE-links attached to the TE-router. 610 TE-Link-Update LSA is defined to advertise individual link 611 specific TE updates. Flooding scope for both these LSAs is the 612 TE topology within the area to which the links belong. I.e., 613 only those OSPF nodes within the area with TE links will receive 614 these TE LSAs. 616 TE-Summary network and router LSAs are defined to advertise 617 the reachability of area-specific TE networks and Area border 618 routers(along with router TE characteristics) to external 619 areas. Flooding Scope of the TE-Summary LSAs is the TE topology 620 in the entire AS less the non-backbone area for which the 621 the advertising router is an ABR. Just as with native OSPF 622 summary LSAs, the TE-summary LSAs do not reveal the topological 623 details of an area to external areas. But, the two summary LSAs 624 do differ in some respects. The flooding scope of TE summary 625 LSAs is different. As for content, TE summary network LSAs 626 simply describe reachability without summarization of network 627 access costs. And, unlike the native summary router LSA, 628 TE-summary router LSA content includes TE capabilities of the 629 advertising TE router. 631 TE-AS-external LSA and TE-Circuit-Path LSA are defined to 632 advertise AS external network reachability and pre-engineered 633 TE circuits respectively. While flooding scope for both 634 these LSAs can be the TE-topology in the entire AS, flooding 635 scope for the pre-engineered TE circuit LSA may optionally be 636 restricted to just the TE topology within an area. 638 Lastly, the new TE LSAs are defined so as to permit peer 639 operation of packet networks and non-packet networks alike. 640 As such, a new TE-Router-Proxy LSA is defined to allow 641 advertisement of a TE router, that is not OSPF capable, by 642 an OSPF-TE node as a proxy. 644 7.1. TE-Router LSA 646 Router LSAs are Type 1 LSAs. The TE-router LSA is modeled after the 647 router LSA with the same flooding scope as the router-LSA, except 648 that the scope is further restricted to TE-only nodes within the 649 area. A value of 0x81 is assigned to TE-router LSA. The TE-router 650 LSA describes the router-TE metrics as well as the link-TE metrics 651 of the TE links attached to the router. Below is the format of the 652 TE-router LSA. Unless specified explicitly otherwise, the fields 653 carry the same meaning as they do in a router LSA. Only the 654 differences are explained below. 656 0 1 2 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | LS age | Options | 0x81 | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Link State ID | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Advertising Router | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | LS sequence number | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | LS checksum | length | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | 0 |V|E|B| 0 | Router-TE flags | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Router-TE flags (contd.) | Router-TE TLVs | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | .... | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | .... | # of TE links | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Link ID | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Link Data | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Type | 0 | Link-TE flags | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Link-TE flags (contd.) | Zero or more Link-TE TLVs | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Link ID | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Link Data | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | ... | 691 Option 692 In TE-capable router nodes, the TE-compliance bit is set to 1. 694 Router-TE flags field (TE capabilities of the router node) 696 Below is an initial set of definitions. More may be standardized 697 if necessary. The TLVs are not expanded in the current rev. Will 698 be done in the follow-on revs. The field imposes a restriction 699 of no more than 32 flags to describe the TE capabilities of a 700 router-TE. 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 |L|L|P|T|L|F| |S|S|S|C| 704 |S|E|S|D|S|S| |T|E|I|S| 705 |R|R|C|M|C|C| |A|L|G|P| 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| 709 Bit LSR 710 When set, the router is considered to have LSR capability. 712 Bit LER 713 When set, the router is considered to have LER capability. 714 All MPLS border routers will be required to have the LER 715 capability. When the E bit is also set, that indicates an 716 AS Boundary router with LER capability. When the B bit is 717 also set, that indicates an area border router with LER 718 capability. 720 Bit PSC 721 Indicates the node is Packet Switch Capable. 723 Bit TDM 724 Indicates the node is TDM circuit switch capable. 726 Bit LSC 727 Indicates the node is Lamda switch Capable. 729 Bit FSC 730 Indicates the node is Fiber (can also be a non-fiber link 731 type) switch capable. 733 Bit STA 734 Label Stack Depth limit TLV follows. This is applicable only 735 when the PSC flag is set. 737 Bit SEL 738 TE Selection Criteria TLV, supported by the router, follows. 740 Bit SIG 741 MPLS Signaling protocol support TLV follows. 743 BIT CSPF 744 CSPF algorithm support TLV follows. 746 Router-TE TLVs 747 The following Router-TE TLVs are defined. 749 TE-selection-Criteria TLV (Tag ID = 1) 751 The values can be a series of resources that may be used 752 as the criteria for traffic engineering (typically with the 753 aid of a signaling protocol such as RSVP-TE or CR-LDP or LDP). 755 - Bandwidth based LSPs (1) 756 - Priority based LSPs (2) 757 - Backup LSP (3) 758 - Link cost (4) 760 Bandwidth criteria is often used in conjunction with Packet 761 Switch Capable nodes. The unit of bandwidth permitted to be 762 configured may however vary from vendor to vendor. Bandwidth 763 criteria may also be used in conjunction with TDM nodes. Once 764 again, the granularity of bandwidth allocation may vary from 765 vendor to vendor. 767 Priority based traffic switching is relevant only to Packet 768 Switch Capable nodes. Nodes supporting this criteria will 769 be able to interpret the EXP bits on the MPLS header to 770 prioritize the traffic across the same LSP. 772 Backup criteria refers to whether or not the node is capable 773 of finding automatic protection path in the case the 774 originally selected link fails. Such a local recovery is 775 specific to the node and may not need to be notified to the 776 upstream node. 778 MPLS-Signaling protocol TLV (Tag ID = 3) 779 The value can be 2 bytes long, listing a combination of 780 RSVP-TE, CR-LDP and LDP. 782 Constraint-SPF algorithms-Support TLV (Tag ID = 4) 783 List all the CSPF algorithms supported. Support for CSPF 784 algorithms on a node is an indication that the node may be 785 requested for all or partial circuit path selection during 786 circuit setup time. This can be beneficial in knowing 787 whether or not the node is capable of expanding loose 788 routes (in an MPLS signaling request) into an LSP. Further, 789 the CSPF algorithm support on an intermediate node can be 790 beneficial when the node terminates one or more of the 791 hierarchical LSP tunnels. 793 Label Stack Depth TLV (Tag ID = 5) 794 Applicable only for PSC-Type traffic. A default value of 1 795 is assumed. This indicates the depth of label stack the 796 node is capable of processing on an ingress interface. 798 The following fields are used to describe each router link (i.e., 799 interface). Each router link is typed (see the below Type field). 800 The Type field indicates the kind of link being described. 802 Type 803 A new link type "Positional-Ring Type" (value 5) is defined. 804 This is essentially a connection to a TDM-Ring. TDM ring network 805 is different from LAN/NBMA transit network in that, nodes on the 806 TDM ring donot necessarily have a terminating path between 807 themselves. Secondly, the order of links is important in 808 determining the circuit path. Third, the protection switching 809 and the number of fibers from a node going into a ring are 810 determined by the ring characteristics. I.e., 2-fiber vs 811 4-fiber ring and UPSR vs BLSR protected ring. 813 Type Description 814 __________________________________________________ 815 1 Point-to-point connection to another router 816 2 Connection to a transit network 817 3 Connection to a stub network 818 4 Virtual link 819 5 Positional-Ring Type. 821 Link ID 822 Identifies the object that this router link connects to. 823 Value depends on the link's Type. For a positional-ring type, 824 the Link ID shall be IP Network/Subnet number, just as with a 825 broadcast transit network. The following table summarizes the 826 updated Link ID values. 828 Type Link ID 829 ______________________________________ 830 1 Neighboring router's Router ID 831 2 IP address of Designated Router 832 3 IP network/subnet number 833 4 Neighboring router's Router ID 834 5 IP network/subnet number 836 Link Data 837 This depends on the link's Type field. For type-5 links, this 838 specifies the router interface's IP address. 840 Link-TE options (TE capabilities of a link) 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 |T|N|P|T|L|F|D| |S|L|B|C| 844 |E|T|K|D|S|S|B| |R|U|W|O| 845 | |E|T|M|C|C|S| |L|G|A|L| 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| 849 TE - Indicates whether TE is permitted on the link. A link 850 can be denied for TE use by setting the flag to 0. 852 NTE - Indicates whether non-TE traffic is permitted on the 853 TE link. This flag is relevant only when the TE 854 flag is set. 856 PKT - Indicates whether or not the link is capable of 857 packet termination. 859 TDM, LSC, FSC bits 860 - Same as defined for router TE options. 862 DBS - Indicates whether or not Database synchronization 863 is permitted on this link. 865 SRLG Bit - Shared Risk Link Group TLV follows. 867 LUG bit - Link usage cost metric TLV follows. 869 BWA bit - Data Link bandwidth TLV follows. 871 COL bit - Data link Color TLV follows. 873 Link-TE TLVs 875 SRLG-TLV 876 This describes the list of Shared Risk Link Groups the link 877 belongs to. Use 2 bytes to list each SRLG. 879 BWA-TLV 880 This indicates the maximum bandwidth, available bandwidth, 881 reserved bandwidth for later use etc. This TLV may also 882 describe the Data link Layer protocols supported and the 883 Data link MTU size. 885 LUG-TLV 886 This indicates the link usage cost - Bandwidth unit, Unit 887 usage cost, LSP setup cost, minimum and maximum durations 888 permitted for setting up the TLV etc., including any time 889 of day constraints. 891 COLOR-TLV 892 This is similar to the SRLG TLV, in that an autonomous 893 system may choose to issue colors to link based on a 894 certain criteria. This TLV can be used to specify the 895 color assigned to the link within the scope of the AS. 897 7.2. Changes to Network LSA 899 Network-LSA is the Type 2 LSA. With the exception of the following, 900 no additional changes will be required to this LSA for TE 901 compatibility. The LSA format and flooding scope remains unchanged. 903 A network-LSA is originated for each broadcast, NBMA and 904 Positional-Ring type network in the area which supports two or 905 more routers. The TE option is also required to be set while 906 propagating the TDM network LSA. 908 7.2.1. Positional-Ring type network LSA - New Network type for TDM-ring. 909 - Ring ID: (Network Address/Mask) 910 - No. of elements in the ring (a.k.a. ring neighbors) 911 - Ring Bandwidth 912 - Ring Protection (UPSR/BLSR) 913 - ID of individual nodes (Interface IP address) 914 - Ring type (2-Fiber vs. 4-Fiber, SONET vs. SDH) 916 Network LSA will be required for SONET RING. Unlike the broadcast 917 type, the sequence in which the NEs are placed on a RING-network 918 is pertinent. The nodes in the ting must be described clock wise, 919 assuming the GNE as the starting element. 921 7.3. TE-Summary LSAs 923 TE-Summary-LSAs are the Type 0x83 and 0x84 LSAs. These LSAs are 924 originated by area border routers. TE-Summary-network-LSA (0x83) 925 describes the reachability of TE networks in a non-backbone 926 area, advertised by the Area Border Router. Type 0x84 927 summary-LSA describes the reachability of Area Border Routers 928 and AS border routers and their TE capabilities. 930 One of the benefits of having multiple areas within an AS is 931 that frequent TE advertisements within the area donot impact 932 outside the area. Only the TE abstractions as befitting the 933 external areas are advertised. 935 7.3.1. TE-Summary Network LSA (0x83) 937 TE-summary network LSA may be used to advertise reachability of 938 TE-networks accessible to areas external to the originating 939 area. The scope of flooding is AS wide, with the exception of 940 the originating area and the stub areas. For example, the 941 TE-summary network LSA advertised by the border router of a 942 non-backbone area is readvertised to all other areas, not just 943 the backbone area. The area border router for each 944 non-backbone area is responsible for advertising the 945 reachability of backbone networks into the area. 947 The flooding scope of TE-summary network LSA is unlike that 948 of the summary network LSA (type 0x03), which simply uses this 949 as an inter-area exchange of network accessibility and limits 950 the flooding scope to just the backbone area. 952 0 1 2 3 953 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 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | LS age | Options | 0x83 | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 | Link State ID (IP Network Number) | 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Advertising Router (Area Border Router) | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | LS sequence number | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | LS checksum | length | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | Network Mask | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Area-ID | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 7.3.2. TE-Summary router LSA (0x84) 972 TE-summary router LSA may be used to advertise the availability of 973 Area Border Routers (ABRs) and AS Border Routers (ASBRs) that are 974 TE capable. The TE-summary router LSAs are originated by the Area 975 Border Routers. The scope of flooding for the TE-summary router LSA 976 is the entire AS, with the exception of the non-backbone areas the 977 advertising ABRs belong to. 979 0 1 2 3 980 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 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | LS age | Options | 0x84 | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Link State ID | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 | Advertising Router (ABR) | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 988 | LS sequence number | 989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 990 | LS checksum | length | 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | 0 |E|B| 0 | No. of Areas | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | Area-ID | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | ... | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | Router-TE flags | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | Router-TE TLVs | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | .... | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 Link State ID 1006 The ID of the Area border router or the AS border router whose 1007 TE capability is being advertised. 1009 Advertising Router 1010 The ABR that advertises its TE capabilities (and the OSPF areas 1011 it belongs to) or the TE capabilities of an ASBR within one of 1012 the areas the ABR is a border router of. 1014 No. of Areas 1015 Specifies the number of OSPF areas the link state ID belongs to. 1017 Area-ID 1018 Specifies the OSPF area(s) the link state ID belongs to. When 1019 the link state ID is same as the advertising router ID, this 1020 lists all the areas the ABR belongs to. In the case the 1021 link state ID is an ASBR, this simply lists the area the 1022 ASBR belongs to. The advertising router is assumed to be the 1023 ABR from the same area the ASBR is located in. 1025 Summary-router-TE flags 1027 Bit E - When set, the advertised Link-State ID is an AS boundary 1028 router (E is for external). The advertising router and 1029 the Link State ID belong to the same area. 1031 Bit B - When set, the advertised Link state ID is an Area 1033 border router (B is for Border) 1035 Router-TE flags, 1036 Router-TE TLVs (TE capabilities of the link-state-ID router) 1038 TE Flags and TE TLVs are as applicable to the ABR/ASBR 1039 specified in the link state ID. The semantics is same as 1040 specified in the Router-TE LSA. 1042 7.4. TE-AS-external LSAs (0x85) 1044 TE-AS-external-LSAs are the Type 0x85 LSAs. This is modeled after 1045 AS-external LSA format and flooding scope. These LSAs are originated 1046 by AS boundary routers with TE extensions (say, a BGP node which can 1047 communicate MPLS labels across to external ASes), and describe 1048 networks and pre-engineered TE links external to the AS. The 1049 flooding scope of this LSA is similar to that of an AS-external LSA. 1050 I.e., AS wide, with the exception of stub areas. 1052 0 1 2 3 1053 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 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | LS age | Options | 0x85 | 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | Link State ID | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | Advertising Router | 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 | LS sequence number | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | LS checksum | length | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Network Mask | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | Forwarding address | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | External Route Tag | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | # of Virtual TE links | 0 | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | Link-TE flags | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | Link-TE TLVs | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1077 | ... | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | TE-Forwarding address | 1080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 | External Route TE Tag | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | ... | 1085 Network Mask 1086 The IP address mask for the advertised TE destination. For 1087 example, this can be used to specify access to a specific 1088 TE-node or TE-link with an mask of 0xffffffff. This can also 1089 be used to specify access to an aggregated set of destinations 1090 using a different mask, ex: 0xff000000. 1092 Link-TE flags, 1093 Link-TE TLVs 1094 The TE attributes of this route. These fields are optional and 1095 are provided only when one or more pre-engineered circuits can 1096 be specified with the advertisement. Without these fields, 1097 the LSA will simply state TE reachability info. 1099 Forwarding address 1100 Data traffic for the advertised destination will be forwarded to 1101 this address. If the Forwarding address is set to 0.0.0.0, data 1102 traffic will be forwarded instead to the LSA's originator (i.e., 1103 the responsible AS boundary router). 1105 External Route Tag 1106 A 32-bit field attached to each external route. This is not 1107 used by the OSPF protocol itself. It may be used to communicate 1108 information between AS boundary routers; the precise nature of 1109 such information is outside the scope of this specification. 1111 7.5. TE-Circuit-paths LSA (0x8C) 1113 TE-Circuit-paths LSA may be used to advertise the availability of 1114 pre-engineered TE circuit path(s) originating from any router in 1115 the network. The flooding scope may be Area wide or AS wide. 1117 0 1 2 3 1118 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 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | LS age | Options | 0x84 | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | Link State ID | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | Advertising Router | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | LS sequence number | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | LS checksum | length | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | 0 |S|E|B| 0 | # of TE circuit paths | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | TE-Link ID | 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 | TE-Link Data | 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | Type | 0 | Link-TE flags | 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | Link-TE flags (contd.) | Zero or more Link-TE TLVs | 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | TE-Link ID | 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | TE-Link Data | 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | ... | 1146 Link State ID 1147 The ID of the router to which the TE circuit path(s) is being 1148 advertised. 1150 TE-circuit-path(s) flags 1152 Bit S - When set, the flooding scope is set to be AS wide. 1153 Otherwise, the flooding scope is set to be area wide. 1155 Bit E - When set, the advertised Link-State ID is an AS boundary 1156 router (E is for external). The advertising router and 1157 the Link State ID belong to the same area. 1159 Bit B - When set, the advertised Link state ID is an Area border 1160 router (B is for Border) 1162 No. of Virtual TE Links 1163 This indicates the number of pre-engineered TE links between the 1164 advertising router and the router specified in the link state ID. 1166 TE-Link ID 1167 This is the ID by which to identify the virtual link on the 1168 advertising router. This can be any private interface index or 1169 handle that the advertising router uses to identify the 1170 pre-engineered TE virtual link to the ABR/ASBR. 1172 TE-Link Data 1173 This specifies the IP address of the physical interface 1174 on the advertising router. 1176 7.6. TE-Link-Update LSA (0x8d) 1178 A significant difference between a non-TE OSPF network and a TE OSPF 1179 network is that the latter is subject to dynamic circuit pinning and 1180 is more likely to undergo state updates. Specifically, some links 1181 might undergo more changes and more frequently than others. 1182 Advertising the entire TE-router LSA in response to a change in any 1183 single link could be repetitive. Flooding the network with TE-router 1184 LSAs at the aggregated speed of all the dynamic changes is simply 1185 not desirable. Hence, the new TE-link-update LSA, that advertises 1186 link specific updates alone. 1188 The TE-link-Update LSA will be advertised as frequently as the link 1189 state is changed. The TE-link sequence is largely the advertisement 1190 of a sub-portion of router LSA. The sequence number on this will be 1191 incremented with the TE-router LSA's sequence as the basis. When an 1192 updated TE-router LSA is advertised within 30 minutes of the 1193 previous advertisement, the updated TE-router LSA will assume a 1194 sequence no. that is larger than the most frequently updated of 1195 its links. 1197 Below is the format of the TE-link update LSA. 1199 0 1 2 3 1200 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 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | LS age | Options | 0x8d | 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | Link State ID (same as Link ID) | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | Advertising Router | 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 | LS sequence number | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 | LS checksum | length | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | Link Data | 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1214 | Type | 0 | Link-TE options | 1215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 | Link-TE options | Zero or more Link-TE TLVs | 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 | # TOS | metric | 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 | ... | 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | TOS | 0 | TOS metric | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 Link State ID 1226 This would be exactly the same as would have been specified as 1227 as Link ID for a link within the router-LSA. 1229 Link Data 1230 This specifies the router ID the link belongs to. In majority of 1231 cases, this would be same as the advertising router. 1233 The tuple of (LS Type, LSA ID, Advertising router) uniquely identify 1234 the LSA and replace LSAs of the same tuple with an older sequence 1235 number. However, there is an exception to this rule in the context 1236 of TE-link-update LSA. TE-Link update LSA will initially assume the 1237 sequence number of the TE-router LSA it belongs to. Further, 1238 when a new TE-router LSA update with a larger sequence number is 1239 advertised, the newer sequence number is assumed by al the link 1240 LSAs. 1242 7.7. TE-Router-Proxy LSA (0x8e) 1244 This is a variation to the TE-router LSA in that the TE-router LSA 1245 is not advertised by the network element, but rather by a trusted 1246 TE-router Proxy. This is typically the scenario in a non-packet 1247 TE network, where some of the nodes donot have OSPF functionality 1248 and count on a helper node to do the advertisement for them. One 1249 such example would be the SONET/SDH ADM nodes in a TDM ring. The 1250 nodes may principally depend upon the GNE (Gateway Network Element) 1251 to do the advertisement for them. TE-router-Proxy LSA shall not be 1252 used to advertise Area Border Routers and/or AS border Routers. 1254 0 1 2 3 1255 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 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 | LS age | Options | 0x8e | 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 | Link State ID (Router ID of the TE Network Element) | 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Advertising Router | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | LS sequence number | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | LS checksum | length | 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 | 0 | Router-TE flags | 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 | Router-TE flags (contd.) | Router-TE TLVs | 1270 +---------------------------------------------------------------+ 1271 | .... | 1272 +---------------------------------------------------------------+ 1273 | .... | # of TE links | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 | Link ID | 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | Link Data | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | Type | 0 | Link-TE options | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | Link-TE flags | Zero or more Link-TE TLVs | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | Link ID | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | Link Data | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | ... | 1289 8. Link State Databases 1291 With the new TE-LSA scheme, an OSPF-TE node will have two types 1292 of Link state databases (LSDB). A native LSDB that describes the 1293 control (non-TE) topology and a TE-LSDB that describes the TE 1294 topology. Shortest-Path-First algorithm will be used to forward 1295 IP packets along the native control network. OSPF neighbors data 1296 structure will be used for flooding along the control topology. 1298 The TE-LSDB is constituted only of TE nodes and TE links. A variety 1299 of CSPF algorithms may be used to dynamically setup TE circuit 1300 paths along the TE network. A new TE-neighbors data structure will 1301 be used to flood TE LSAs along the TE-only topology. Clearly, the 1302 the TE nodes will need the control (non-TE) network for OSPF 1303 communication. The control network may also be used for pinging 1304 OSPF-TE nodes and performing any debug and monitoring tasks on 1305 the nodes. However, the ability to make distinction between 1306 TE and non-TE topologies, allows the bandwidth on TE links to be 1307 strictly SLA enforceable, even as a TE link is packet-capable. 1308 The actual characteristics of the TE-link are irrelevant from the 1309 OPSF-TE perspective. As such, that allows for packet and non-packet 1310 networks to operate in peer mode. 1312 Consider the following network where some of the routers and links 1313 are TE enabled and others are native OSPF routers and links. All 1314 nodes in the network belong to the same OSPF area. 1316 +---+ 1317 | |--------------------------------------+ 1318 |RT6|\\ | 1319 +---+ \\ | 1320 || \\ | 1321 || \\ | 1322 || \\ | 1323 || +---+ | 1324 || | |----------------+ | 1325 || |RT1|\\ | | 1326 || +---+ \\ | | 1327 || //| \\ | | 1328 || // | \\ | | 1329 || // | \\ | | 1330 +---+ // | \\ +---+ | 1331 |RT2|// | \\|RT3|------+ 1332 | |----------|----------------| | 1333 +---+ | +---+ 1334 | | 1335 | | 1336 | | 1337 +---+ +---+ 1338 |RT5|--------------|RT4| 1339 +---+ +---+ 1340 Legend: 1341 -- Native(non-TE) network link 1342 | Native(non-TE) network link 1343 \\ TE network link 1344 || TE network link 1346 Figure 6: A (TE + native) OSPF network topology 1348 In the above network, TE and native OSPF Link State Data bases 1349 (LSDB) would have been synchronized within the area along the 1350 following nodes. 1352 Native OSPF LSDB nodes TE-LSDB nodes 1353 ---------------------- ------------- 1354 RT1, RT2, RT3. RT4, RT5, RT6 RT1, RT2, RT3, RT6 1356 Nodes such as RT1 will have two LSDBs, a native LSDB and a TE-LSDB 1357 to reach native and TE networks. The TE LSA updates will not impact 1358 non-TE nodes RT4 and RT5. 1360 9. Abstract topology representation with TE support 1362 Below, we assume a TE network that is composed of three OSPF areas, 1363 namely Area-1, Area-2 and Area-3, attached together through the 1364 backbone area. The following figure is an inter-area topology 1365 abstraction from the perspective of routers in Area-1. The 1366 abstraction is similar, but not the same, as that of the non-TE 1367 abstraction. As such, the authors claim the model is easy to 1368 understand and emulate. The abstraction illustrates reachability 1369 of TE networks and nodes in areas external to the local area and 1370 ASes external to the local AS. The abstraction also illustrates 1371 pre-engineered TE links that may be advertised by ABRs and ASBRs. 1373 Area-1 an has a single border router, ABR-A1 and no ASBRs. Area-2 1374 has an Area border router ABR-A2 and an AS border router ASBR-S1. 1375 Area-3 has two Area border routers ABR-A2 and ABR-A3; and an AS 1376 border router ASBR-S2. There may be any number of Pre-engineered 1377 TE links amongst ABRs and ASBRs. The following example assumes a 1378 single TE-link between ABR-A1 and ABR-A2; between ABR-A1 and 1379 ABR-A3; between ABR-A2 to ASBR-S1; and between ABR-A3 to ASBR-S2. 1380 All Area border routers and AS border routers are assumed to 1381 be represented by their TE capabilities. 1383 +-------+ 1384 |Area-1 | 1385 +-------+ 1386 +-------------+ | 1387 |Reachable TE | +------+ 1388 |networks in |--------|ABR-A1| 1389 |backbone area| +------+ 1390 +-------------+ | | | 1391 +-------------+ | +-------------------+ 1392 | | | 1393 +-----------------+ | +-----------------+ 1394 |Pre-engineered TE| +----------+ |Pre-engineered TE| 1395 |circuit path(s) | | Backbone | |circuit path(s) | 1396 |to ABR-A2 | | Area | |to ABR-A3 | 1397 +-----------------+ +----------+ +-----------------+ 1398 | | | | 1399 +----------+ | | | 1400 | | +--------------+ | 1401 +-----------+ | | | | +-----------+ 1402 |Reachable | +------------+ +------+ |Reachable | 1403 |TE networks|---| ABR-A2 | |ABR-A3|--|TE networks| 1404 |in Area A2 | +------------+ +------+ |in Area A3 | 1405 +-----------+ / | | | | | +-----------+ 1406 / | | +-------------------+ | +----------+ 1407 / | +-------------+ | | | 1408 +-----------+ +--------------+ | | | +--------------+ 1409 |Reachable | |Pre-engineered| | | | |Pre-engineered| 1410 |TE networks| |TE Ckt path(s)| +------+ +------+ |TE Ckt path(s)| 1411 |in Area A3 | |to ASBR-S1 | |Area-2| |Area-3| |to ASBR-S2 | 1412 +-----------+ +--------------+ +------+ +------+ +--------------+ 1413 | / | / 1414 +-------------+ | / | / 1415 |AS external | +---------+ +-------------+ 1416 |TE-network |------| ASBR-S1 | | ASBR-S2 | 1417 |reachability | +---------+ +-------------+ 1418 |from ASBR-S1 | | | | 1419 +-------------+ | | | 1420 +-----------------+ +-------------+ +-----------------+ 1421 |Pre-engineered TE| |AS External | |Pre-engineered TE| 1422 |circuit path(s) | |TE-Network | |circuit path(s) | 1423 |reachable from | |reachability | |reachable from | 1424 |ASBR-S1 | |from ASBR-S2 | |ASBR-S2 | 1425 +-----------------+ +-------------+ +-----------------+ 1427 Figure 9: Inter-Area Abstraction as viewed by Area-1 TE-routers 1429 10. Changes to Data structures in OSPF-TE nodes 1431 10.1. Changes to Router data structure 1433 The router with TE extensions must be able to include all the 1434 TE capabilities (as specified in section 7.1) in the router data 1435 structure. Further, routers providing proxy service to other TE 1436 routers must also track the router and associated interface data 1437 structures for all the TE client nodes for which the proxy 1438 service is being provided. Presumably, the interaction between 1439 the Proxy server and the proxy clients is out-of-band. 1441 10.2. Two set of Neighbors 1443 Two sets of neighbor data structures will need to be maintained. 1444 TE-neighbors set is used to advertise TE LSAs. Only the TE-nodes 1445 will be members of the TE-neighbor set. Native neighbors set will 1446 be used to advertise native LSAs. All neighboring nodes supporting 1447 non-TE links can be part of this set. As for flooding optimizations 1448 based on neighbors set, readers may refer [OSPF-FL1]. 1450 10.3. Changes to Interface data structure 1452 The following new fields are introduced to the interface data 1453 structure. These changes are in addition to the changes specified 1454 in [OSPF-FL1]. 1456 TePermitted 1457 If the value of the flag is TRUE, the interface is permissible 1458 to be advertised as a TE-enabled interface. 1460 NonTePermitted 1461 If the value of the flag is TRUE, the interface permits non-TE 1462 traffic on the interface. Specifically, this is applicable to 1463 packet networks, where data links may permit both TE and non-TE 1464 packets. For FSC and LSC TE networks, this flag will be set to 1465 FALSE. For Packet networks that donot permit non-TE traffic on 1466 TE links also, this flag is set to TRUE. 1468 PktTerminated 1469 If the value of the flag is TRUE, the interface terminates 1470 Packet data and hence may be used for IP and OSPF data exchange. 1472 AdjacencySychRequired 1473 If the value of the flag is TRUE, the interface may be used to 1474 synchronize the LSDB across all adjacent neighbors. This is 1475 TRUE by default to all PktTerminated interfaces that are 1476 enabled for OSPF. However, it is possible to set this to FALSE 1477 for some of the interfaces. 1479 TE-TLVs 1480 Each interface may potentially have a maximum of 16 TLVS that 1481 describe the link characteristics. 1483 The following existing fields in Interface data structure will take 1484 on additional values to support TE extensions. 1486 Type 1487 The OSPF interface type can also be of type "Positional-RING". 1488 The Positional-ring type is different from other types (such 1489 as broadcast and NBMA) in that the exact location of the nodes 1490 on the ring is relevant, even as they are all on the same 1491 ring. SONET ADM ring is a good example of this. Complete ring 1492 positional-ring description may be provided by the GNE on a 1493 ring as a TE-network LSA for the ring. 1495 List of Neighbors 1496 The list may be statically defined for an interface, without 1497 requiring the use of Hello protocol. 1499 11. Motivations to this approach 1501 Use of TE LSAs bring substantial benefits over using Opaque LSAs 1502 as described below. These benefits cannot be retrofitted into 1503 Opaque LSAs due to fundamental scalability limitations of the 1504 Opaque-LSA approach. 1506 The primary motivation behind the TE-LSA model is that the 1507 approach is clean (clean separation of LSDB between TE vs non-TE 1508 networks), scalable (across more than one OSPF area), unified 1509 (for packet and non-packet networks alike), efficient (efficient 1510 flooding algorithm) and SLA enforceable. The model proposed also 1511 provides the right framework for future enhancements. 1513 11.1. TE flooding isolated to TE-only nodes 1515 A TE network can generate a large number of LSA updates due 1516 to the many state changes the TE links undergo dynamically. For 1517 example, bandwidth assignment on a TE link for a specific circuit 1518 path setup will mandate that the change in bandwidth availability 1519 be communicated network wide. While such frequent link state 1520 updates is reasonable for an OSPF-TE node, neither the frequency 1521 nor the content of TE link state is desirable for native OSPF 1522 nodes. This can be a considerable interruption to non-TE nodes in 1523 a network that is constituted of multiple types of nodes and links 1524 (ex: A network constituted of packet routing nodes/links and SONET 1525 network ADMs/links, A packet-network where the ratio of TE nodes 1526 to non-TE nodes is quite considerable). 1528 The wider the flooding scope (and number of TE nodes), the larger 1529 the number of retransmissions and acknowledgements. The same 1530 information (needed or not) may reach a router through multiple 1531 links. Even if the router did not forward the information past the 1532 node, it would still have to send acknowledgements across all the 1533 multiple links on which the LSAs tried to converge. By restricting 1534 the flooding of TE LSAs to TE-only nodes within a TE topology, we 1535 obviate any TE based processing for non-TE nodes. 1537 The flooding topology for opaque LSAs makes no distinction between 1538 TE and native OSPF nodes. In a network where the TE and native 1539 nodes coexist, a native OSPF router would be bombarded with opaque 1540 LSAs. It is possible for the native OSPF nodes to silently ignore 1541 the unsupported Opaque LSAs (during network migration) or add 1542 knobs within implementation to decide whether or not a certain 1543 opaque LSA mandates dijkstra SPF recomputation. But, the latter 1544 can be tricky and will need non-trivial amounts of Opaque LSA 1545 processing to make the determination. In the case where routers 1546 donot validate the need to recompute, routers might end up 1547 recomputing for all new Opaque LSA advertisements. Clearly, that 1548 would be a considerable computational demand and can be cause for 1549 instability on the OSPF routers. 1551 11.2. Clean separation between native and TE LSDBs 1553 Most vendors wishing to support MPLS based TE in their network 1554 tend to migrate gradually to support the TE extensions. Perhaps, 1555 add new TE links or convert existing links into TE links within 1556 an area first and progressively advance to offer in the entire 1557 AS. As such, the TE network cannot be assumed to exist 1558 independently without native OSPF network even in the long term. 1560 Not all routers will support TE extensions at the same time 1561 during the migration process. Use of TE specific LSAs and their 1562 flooding to OSPF-TE only nodes will allow the vendor to 1563 introduce MPLS TE without destabilizing the existing network. 1564 As such, the native OSPF-LSDB will remain undisturbed while 1565 newer TE links are added to network. 1567 With the new TE-LSA scheme, native OSPF nodes will keep just the 1568 native OSPF link state database. The OSPF-TE nodes will keep 1569 native as well as the TE LSDB. The native LSDB describes the 1570 control (non-TE) topology. Shortest-Path-First algorithm will be 1571 used to forward IP packets along this network. OSPF neighbors 1572 data structure will be used for flooding along the control 1573 topology. 1575 In the Opaque-LSA-based TE scheme, the TE-LSDB built using opaque 1576 LSAs will be required to refer the native LSDB to build the TE 1577 topology. Even with that, there is way to know the TE capabilities 1578 of the routers. The Opaque-LSA approach does not deal with TE 1579 capabilities for a router. Opaque LSAs are flooded to all nodes. 1580 Some nodes that happen to support the TE extensions will have a 1581 hit and accept the opaque LSAs. Others that donot support will 1582 have a miss and simply drop the received Opaque LSAs. This type of 1583 hit-and-miss approach is not only disruptive, but also blind to 1584 SLA requirements on TE links. 1586 11.3. Scalability across a hierarchical Area topology 1588 Use of TE LSAs for inter-area communication is clearly superior 1589 to using Opaque LSAs with AS wide scoping. Without revealing 1590 the TE nodes and characteristics of the attached links, an Opaque 1591 LSA (type 11) simply does not disseminate reachability of TE 1592 networks and nodes outside the area. Stated differently, 1593 Use of opaque LSA can, work at best, for a single area AS. 1595 Providing area level abstraction and having this abstraction be 1596 distinct for TE and native topologies is a necessity in inter-area 1597 communication. When the topologies are separate, the area border 1598 routers can advertise different summary LSAs for TE and 1599 non-TE routers. For example, a native Area Border router (ABR) 1600 simply announces the shortest path network summary LSAs (LSA 1601 type 3) for nodes outside the area. A TE ABR, on the other hand, 1602 could use TE-summary network LSA to advertise network Reachability 1603 information - not aggregated path metric as required for a native 1604 OSPF LSDB. Clearly, the data content and flooding scope should be 1605 different for the TE nodes. The flooding boundary for TE-summary 1606 LSAs would be (AS - OriginatingArea - StubAreas - NSSAs). 1608 Opaque-LSAs are suitable neither for content nor for flooding scope 1609 in the context of inter-area communication. The flooding boundaries 1610 of Opaque LSAs make the approach suitable at best to single-area 1611 topologies. For example, Opaque LSAs cannot support the flooding 1612 scope of TE-summary-networks. Opaque LSAs (AS-wide scope) will be 1613 unable to restrict flooding in its own originating area. 1614 Opaque LSAs are also not adequate to establish TE peering 1615 relationship with neighbors. 1617 11.4. Usable across packet and non-packet TE networks 1619 In a peer networking TE model, you are likely to want different 1620 types of TE information flooded by various nodes, as they are 1621 heterogenous and will remain that way. The TE LSA based approach 1622 offers a single set of LSAs that may uniformly be used across 1623 packet and non-packet nodes and links. Once a link is declared 1624 as TE, the TE properties advertised of the link can be link 1625 specific, but all advertisements would use the same LSA format. 1627 Implementations reusing the opaque LSA with GMPLS extensions 1628 are burden for the routers that do not need it. Clear 1629 separation (as proposed here) between TE and native LSAs 1630 and having independent flooding scopes for native and TE state 1631 information will be extremely useful in inheriting the right 1632 set of LSAs for the right application (i.e, TE vs native). 1634 11.5. SLA enforceable network modeling 1636 When TE and native topologies are not separated (as is the case 1637 with Opaque-LSAs), a native OSPF node could be utilizing a TE 1638 link as its least cost link, thereby stressing the TE link and 1639 effectively rendering the TE link ineffective for TE purposes. 1640 Separating the two topologies (as advocated by this document with 1641 new TE LSAs and TE option flag) ensure that the SLA objectives on 1642 TE links are properly met. 1644 11.6. Framework for future extensibility 1646 The approach outlined provides a framework for future 1647 extensibility based on service provider needs. 1649 There may be many types of information that should not be 1650 disseminated along the Opaque LSA flooding boundaries. Take for 1651 example, the TE-summary network LSA. This LSA does not follow 1652 the scope of an area or an AS, but something in between. As a 1653 general rule, the proposed framework can be extended to define 1654 newer TE LSAs with a suitable flooding scope. 1656 Having a clean framework which argues for having different 1657 link state databases for different applications on the same network 1658 will provide the right forum for future extensibility. Just as 1659 the TE LSDB may be used for MPLS TE application, a different type 1660 of LSDB may be used for yet another type of application (such as 1661 QOS based IP forwarding) using the same IP network. 1663 lastly, an opaque LSA is restricted in the format in which it can 1664 express different types of data. Everything should be expressible 1665 in the form of a TLV. Summary-TE-networks-from each Area, TE-ABR 1666 routers, TE-ASBR routers, TE-AS-External-networks, TE-Router 1667 Capabilities, TE-link updates, Pre-engineered-TE-Links - All of 1668 these data have to be engineered to be expressible in a TLV form 1669 with one or more sub-TLVs. Some of the TLVs will be required to 1670 be mandatory. Some would be expected to appear in a pre-specified 1671 order and some are expected to appear just once in the LSA. 1672 TLVs should not be a panacea for all kinds of TE data. TLVs are 1673 generally more difficult to process and debug than fixed format 1674 messages. 1676 Opaque LSAs demand more processing to assimilate into topology 1677 abstraction. A single Opaque LSA type is bent in many 1678 ways (using a variety of TLVs) to update the native OSPF topology 1679 abstraction nodes. Not a framework that could be easily extended 1680 for future applications. 1682 11.7. Real-world scenarios benefiting from this approach 1684 Many real-world scenarios are better served by the new-TE-LSAs 1685 scheme. Here are a few examples. 1687 1. Multi-area network. 1689 2. Single-Area networks - The TE links are not cannibalized by the 1690 non-TE routers for SPF forwarding. 1692 3. Credible SLA enforcement in a (TE + non-TE) packet network. 1693 Ability to restrict flooding to some links (say, non-TE links) 1694 ensures the service provider is able to devote the entire 1695 bandwidth of a TE-link for TE circuit purposes. This makes SLA 1696 enforcement credible. 1698 4. For a non-Packet TE network, the Opaque-LSA-based-TE scheme is 1699 not adequate to represent 1700 (a) "Positional-Ring" type network LSA and 1701 (b) Router Proxying - allowing a router to advertise on behalf 1702 of other nodes (that are not Packet/OSPF capable). 1704 12. Transition strategy for implementations using Opaque LSAs 1706 Below is a strategy to transition current implementations to 1707 adapt the new TE LSA scheme in a gradual fashion. Implementations 1708 using Opaque-LSAs can take the following steps to accomplish this. 1709 Once the OSPF-TE is completely transitioned to using the new TE 1710 LSAs as described here, the TE network can reap the full benefits 1711 of the scheme. Amongst other things, packet and non-packet networks 1712 may be combined with ease into a unified network. As such, the MPLS 1713 traffic engineering can be based on either of the overlayed or peer 1714 models espoused in [GMPLS-TE]. 1716 1. Restrict the use of Opaque-LSAs for within an area. 1718 2. Fold in the TE option flag to construct the TE and non-TE 1719 topologies in an area, even if the topologies cannot be used 1720 for flooding within the area. 1722 3. Use TE-Summary LSAs and AS-external-LSAs for inter-area 1723 Communication. Make use of the TE-topology within area to 1724 summarize the TE networks in the area and advertise the same 1725 to all TE-routers in the backbone. The TE-ABRs on the backbone 1726 area will in-turn advertise these summaries again within their 1727 connected areas. 1729 4. Replace Opaque LSAs with TE LSAs within the area as well. 1731 13. IANA Considerations 1733 13.1. TE-compliant-SPF routers Multicast address allocation 1735 13.2. New TE-LSA Types 1737 13.3. New TLVs (Router-TE and Link-TE TLVs) 1739 13.3.1. TE-selection-Criteria TLV (Tag ID = 1) 1740 - Bandwidth based LSPs (1) 1741 - Priority based LSPs (2) 1742 - Backup LSP (3) 1743 - Link cost (4) 1745 13.3.2. MPLS-Signaling protocol TLV (Tag ID = 3) 1746 - RSVP-TE signaling 1747 - LDP signaling 1748 - CR-LDP signaling 1750 13.3.3. Constraint-SPF algorithms-Support TLV (Tag ID = 4) 1751 - CSPF Algorithm Codes. 1753 13.3.4. SRLG-TLV (Tag ID = 0x81) 1754 - SRLG group IDs 1756 13.3.5. BW-TLV (Tag ID = 0x82) 1758 13.3.6 CO-TLV (Tag ID = ox83) 1759 14. Acknowledgements 1761 The authors wish to thank Vishwas manral, Riyad Hartani and Tricci 1762 So for their valuable comments and feedback on the draft. 1764 15. Security Considerations 1766 This memo does not create any new security issues for the OSPF 1767 protocol. Security considerations for the base OSPF protocol are 1768 covered in [OSPF-v2]. As a general rule, a TE network is likely 1769 to generate significantly more control traffic than a native 1770 OSPF network. The excess traffic is almost directly proportional 1771 to the rate at which TE circuits are setup and torn down within 1772 an autonomous system. It is important to ensure that TE database 1773 sychronizations happen quickly when compared to the aggregate 1774 circuit setup an tear-down rates. 1776 REFERENCES 1778 [IETF-STD] Bradner, S., " The Internet Standards Process -- 1779 Revision 3", RFC 1602, IETF, October 1996. 1781 [RFC 1700] J. Reynolds and J. Postel, "Assigned Numbers", 1782 RFC 1700 1784 [MPLS-TE] Awduche, D., et al, "Requirements for Traffic 1785 Engineering Over MPLS," RFC 2702, September 1999. 1787 [GMPLS-TE] P.A. Smith et. al, "Generalized MPLS - Signaling 1788 Functional Description", 1789 draft-ietf-mpls-generalized-signaling-03.txt, work 1790 in progress. 1792 [RSVP-TE] Awduche, D.O., L. Berger, Der-Hwa Gan, T. Li, 1793 V. Srinivasan and G. Swallow, "RSVP-TE: Extensions 1794 to RSVP for LSP Tunnels", Work in progress, 1795 draft-ietf-mpls-rsvp-lsp-tunnel-08.txt 1797 [CR-LDP] Jamoussi, B. et. al, "Constraint-Based LSP Setup 1798 using LDP", draft-ietf-mpls-cr-ldp-05.txt, 1799 Work in Progress. 1801 [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1803 [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, 1804 March 1994. 1806 [NSSA] Coltun, R., V. Fuller and P. Murphy, "The OSPF NSSA 1807 Option", draft-ietf-ospf-nssa-update-10.txt, Work in 1808 Progress. 1810 [OPAQUE] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, 1811 July 1998. 1813 [OSPF-FL1] Zinin, A. and M. Shand, "Flooding Optimizations in 1814 link-state routing protocols", work in progress, 1815 1817 [OSPF-FL2] Moy, J., "Flooding over a subset topology", 1818 , work in progress. 1820 [OPQLSA-TE] Katz, D., D. Yeung and K. Kompella, "Traffic 1821 Engineering Extensions to OSPF", work in progress, 1822 1823 Authors' Addresses 1825 Pyda Srisuresh 1826 Kuokoa Networks, Inc. 1827 2901 Tasman Dr., Suite 202 1828 Santa Clara, CA 95054 1829 U.S.A. 1830 EMail: srisuresh@yahoo.com 1832 Paul Joseph 1833 Jasmine Networks 1834 3061 Zanker Road, Suite B 1835 San Jose, CA 95134 1836 U.S.A. 1837 EMail: pjoseph@jasminenetworks.com