idnits 2.17.1 draft-srisuresh-ospf-te-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2119. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 44 longer pages, the longest (page 5) being 73 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 48 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1365 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 (December 31, 2004) is 7055 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 179, but not defined == Missing Reference: 'MPLS-ARCH' is mentioned on line 180, but not defined == Missing Reference: 'OSPF' is mentioned on line 637, but not defined == Missing Reference: 'BGP-OSPF' is mentioned on line 784, but not defined == Missing Reference: 'Ref 11' is mentioned on line 1954, but not defined == Unused Reference: 'IETF-STD' is defined on line 2040, but no explicit reference was found in the text == Unused Reference: 'RFC 1700' is defined on line 2043, but no explicit reference was found in the text == Unused Reference: 'RFC 2434' is defined on line 2046, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 2702 (ref. 'MPLS-TE') ** Downref: Normative reference to an Experimental RFC: RFC 2154 (ref. 'SEC-OSPF') == Outdated reference: A later version (-11) exists of draft-ietf-ospf-cap-04 -- Obsolete informational reference (is this intentional?): RFC 2370 (ref. 'OPAQUE') (Obsoleted by RFC 5250) Summary: 14 errors (**), 0 flaws (~~), 15 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P. Srisuresh 2 INTERNET-DRAFT Caymas Systems 3 Expires as of June 31, 2005 P. Joseph 4 Symbol Technologies 5 December 31, 2004 7 OSPF-xTE: An experimental extension to OSPF for Traffic Engineering 8 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 or will be disclosed, and any of which I become aware will be 15 disclosed, in accordance with RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 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/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html" 32 Abstract 34 This document defines OSPF-xTE, an experimental traffic engineering 35 (TE) extension to the link-state routing protocol OSPF. OSPF-xTE 36 defines new TE LSAs to disseminate TE metrics within an autonomous 37 System (AS), which may consist of multiple areas. Further, When an 38 AS consists of TE and non-TE nodes, OSPF-xTE ensures that Non-TE 39 nodes in the AS are uneffected by the TE LSAs. OSPF-xTE generates 40 a stand-alone TE Link State Database (TE-LSDB), distinct from the 41 native OSPF LSDB, for computation of TE circuit paths. OSPF-xTE is 42 versatile and extendible to non-packet networks such as SONET/TDM 43 and optical networks. 45 Table of Contents 47 1. Introduction ................................................3 48 2. Principles of traffic engineering ...........................3 49 3. Terminology .................................................4 50 3.1. Native OSPF terms ......................................5 51 3.2. OSPF-xTE terms .........................................5 52 4. Motivations behind the design of OSPF-xTE ...................8 53 4.1. Scalable design ........................................9 54 4.2. Operable in mixed and peer networks ....................9 55 4.3. Efficient in flooding reach ............................9 56 4.4. Ability to reserve TE-exclusive links .................10 57 4.5. Extendible design .....................................10 58 4.6. Unified for packet and non-packet networks ............10 59 4.7. Networks benefiting from the OSPF-xTE design ..........11 60 5. OSPF-xTE solution overview .................................12 61 5.1. OSPF-xTE Solution .....................................12 62 5.2. Assumptions ...........................................13 63 6. Opaque LSAs to OSPF-xTE transition strategy ................14 64 7. OSPF-xTE router adjacency - TE topology discovery ..........14 65 7.1. The OSPF-xTE router adjacency .........................14 66 7.2. The Hello Protocol ....................................15 67 7.3. The Designated Router .................................15 68 7.4. The Backup Designated Router ..........................15 69 7.5. Flooding and the Synchronization of Databases .........16 70 7.6. The graph of adjacencies ..............................16 71 8. TE LSAs for packet network .................................18 72 8.1. TE-Router LSA (0x81) ..................................19 73 8.2. TE-incremental-link-Update LSA (0x8d) .................27 74 8.3. TE-Circuit-paths LSA (0x8C) ...........................29 75 8.4. TE-Summary LSAs .......................................32 76 8.5. TE-AS-external LSAs (0x85) ............................34 77 9. TE LSAs for non-packet network .............................36 78 9.1. TE-Router LSA (0x81) ..................................36 79 9.2. TE-Positional-ring-network LSA (0x82) .................38 80 9.3. TE-Router-Proxy LSA (0x8e) ............................40 81 10. Abstract topology representation with TE support ...........41 82 11. Changes to Data structures in OSPF-xTE routers .............43 83 11.1. Changes to Router data structure .....................43 84 11.2. Two set of Neighbors .................................43 85 11.3. Changes to Interface data structure ..................43 86 12. IANA Considerations ........................................44 87 12.1. TE LSA type values ...................................44 88 12.2. TE TLV tag values ....................................45 89 13. Acknowledgements ...........................................45 90 14. Security Considerations ....................................46 91 15. Normative References .......................................47 92 16. Informative References .....................................47 93 17. Authors' Addresses .........................................48 94 18. Full Copyright Statement ...................................48 96 1. Introduction 98 This document defines OSPF-xTE, an experimental traffic 99 engineering (TE) extension to the link-state routing protocol 100 OSPF. The objective of OSPF-xTE is to discover TE network 101 topology and disseminate TE metrics within an autonomous system 102 (AS). A stand-alone TE Link State Database (TE-LSDB), different 103 from the native OSPF LSDB, is created to facilitate computation 104 of TE circuit paths. Devising algorithms to compute TE circuit 105 paths is not an objective of this document. 107 OSPF-xTE is different from the Opaque-LSA-based approach 108 outlined in [OPQLSA-TE]. Section 4 describes the motivations 109 behind the design of OSPF-xTE. Section 6 outlines a transition 110 path for those currently using [OPQLSA-TE] for intra-area and 111 wish to extend this using OSPF-xTE across the AS. 113 Readers interested in TE extensions for the packet networks 114 alone may skip section 9.0. 116 2. Principles of traffic engineering 118 The objective of traffic engineering (TE) is to set up circuit 119 path(s) between a pair of nodes or links and to forward traffic 120 of a certain forwarding equivalency class (FEC) through the 121 circuit path. Only the unicast circuit paths are considered 122 in this section. Multicast variations are outside the scope. 124 A traffic engineered circuit path is uni-directional and may 125 be identified by the tuple of (FEC, TE circuit parameters, 126 Origin Node/Link, Destination node/Link). 128 Forwarding Equivalency Class (FEC) is a grouping of traffic 129 that is forwarded in the same manner by a node. A FEC may be 130 classified based on a number of criteria as follows. 131 a) Traffic arriving on a specific interface, 132 b) Traffic arriving at a certain time of day, 133 c) Traffic meeting a certain packet based classification 134 criteria (ex: based on a match of the fields in the IP 135 and transport headers within a packet), 136 d) Traffic in a certain priority class, 137 e) Traffic arriving on a specific set of TDM (STS) circuits 138 on an interface, 140 f) Traffic arriving on a certain wavelength of an interface 142 Discerning traffic based on the FEC criteria is mandatory for 143 Label Edge Routers (LERs). The intermediate Label Switched Routers 144 (LSRs) are transparent to the traffic content. LSRs are merely 145 responsible for keeping the circuit in-tact for the circuit 146 lifetime. This document will not address defining FEC criteria, 147 or the mapping of a FEC to circuit, or the associated signaling to 148 set up circuits. [MPLS-TE] and [GMPLS-TE] address the FEC criteria. 149 [RSVP-TE] and [CR-LDP] address signaling protocols to set up 150 circuits. 152 This document is concerned with the collection of TE metrics for 153 all the TE enforceable nodes and links within an autonomous system. 154 TE metrics for a node may include the following. 155 a) Ability to perform traffic prioritization, 156 b) Ability to provision bandwidth on interfaces, 157 c) Support for Constrained Shortest Path First (CSPF) 158 algorithms, 159 d) Support for certain TE-Circuit switch type, 160 e) Support for a certain type of automatic protection 161 switching 163 TE metrics for a link may include the following. 164 a) Available bandwidth, 165 b) Reliability of the link, 166 c) Color assigned to the link, 167 d) Cost of bandwidth usage on the link, 168 e) Membership to a Shared Risk Link Group (SRLG) 170 A number of CSPF algorithms may be used to dynamically set up 171 TE circuit paths in a TE network. 173 OSPF-xTE mandates the originating and the terminating entities of 174 a TE circuit path to be identifiable by their IP addresses. 176 3. Terminology 178 Definitions of majority of the terms used in the context of the 179 OSPF protocol may be found in [OSPF-V2]. MPLS and traffic 180 engineering terms may be found in [MPLS-ARCH]. RSVP-TE and 181 CR-LDP signaling specific terms may be found in [RSVP-TE] and 182 [CR-LDP] respectively. 184 The following subsections describe the native OSPF terms and 185 the OSPF-xTE terms used within this document. 187 3.1. Native OSPF terms 189 3.1.1. Native node (Non-TE node) 191 A native or non-TE node is an OSPF router capable of IP packet 192 forwarding and does not take part in a TE network. A native 193 OSPF node forwards IP traffic using the shortest-path 194 forwarding algorithm and does not run the OSPF-xTE extensions. 196 3.1.2. Native link (Non-TE link) 198 A native (or non-TE) link is a network attachment to a TE or 199 non-TE node used for IP packet traversal. 201 3.1.3. Native OSPF network (Non-TE network) 203 A native OSPF network refers to an OSPF network that does not 204 support TE. Non-TE network, native-OSPF network and non-TE 205 topology are used synonymously throughout the document. 207 3.1.4. LSP 209 LSP stands for "Label Switched Path". LSP is a TE circuit path 210 in a packet network. The terms LSP and TE circuit path are 211 used synonymously in the context of packet networks. 213 3.1.5. LSA 215 LSA stands for OSPF "Link State Advertisement". 217 3.1.6. LSDB 219 LSDB stands for "LSA Database". LSDB is a representation of the 220 topology of a network. A native LSDB, constituted of native OSPF 221 LSAs, represents the topology of a native IP network. TE-LSDB, on 222 the other hand, is constituted of TE LSAs and is a representation 223 of the TE network topology. 225 3.2. OSPF-xTE terms 227 3.2.1. TE node 229 TE-Node is a node in the traffic engineered (TE) network. A 230 TE-node has a minimum of one TE-link attached to it. Associated 231 with each TE node is a set of supported TE metrics. A TE node 232 may also participate in a native IP network. 234 In a SONET/TDM or photonic cross-connect network, a TE node is 235 not required to be an OSPF-xTE node. An external OSPF-xTE node 236 may act as proxy for the TE nodes that cannot be routers 237 themselves. 239 3.2.2. TE link 241 TE Link is a network attachment point to a TE-node and is 242 intended for traffic engineering use. Associated with each 243 TE link is a set of supported TE metrics. A TE link may also 244 optionally carry native IP traffic. 246 Of the various links attached to a TE-node, only the links that 247 take part in a traffic engineered network are called the TE 248 links. 250 3.2.3. TE circuit path 252 A TE circuit path is a uni-directional data path, defined by a 253 list of TE nodes connected to each other through TE links. A 254 TE circuit path is also often referred merely as a circuit path 255 or a circuit. 257 For the purposes of OSPF-xTE, the originating and terminating 258 entities of a TE circuit path must be identifiable by their 259 IP addresses. As a general rule, all nodes and links party to a 260 Traffic Engineered network should be uniquely identifiable by an 261 IP address. 263 3.2.4. OSPF-xTE node (OSPF-xTE router) 265 An OSPF-xTE node is a TE node that runs the OSPF routing protocol 266 and the OSPF-xTE extensions described in this document. 268 An autonomous system (AS) may be constituted of a combination of 269 native and OSPF-xTE nodes. 271 3.2.5. TE Control network 273 The IP network used by the OSPF-xTE nodes for OSPF-xTE 274 communication is referred as the TE control network or simply 275 the control network. The control network can be independent of 276 the TE data network. 278 3.2.6. TE network (TE topology) 280 A TE network is a network of connected TE-nodes and TE-links 281 for the purpose of setting up one or more TE circuit paths. 282 The terms TE network, TE data network and TE topology are 283 used synonymously throughout the document. 285 3.2.7. Packet-TE network (Packet network) 287 A packet-TE network is a TE network in which the nodes switch 288 MPLS packets. An MPLS packet is defined in [MPLS-TE] as a 289 packet with an MPLS header, followed by data octets. The 290 intermediary node(s) of a circuit path in a packet-TE network 291 perform MPLS label swapping to emulate the circuit. 293 Unless specified otherwise, the term packet network is used 294 throughout the document to refer a packet-TE network. 296 3.2.8. Non-packet-TE network (Non-packet network) 298 A non-packet-TE network is TE-network in which the nodes 299 switch non-packet entities such as an STS time slot, a Lambda 300 wavelength or simply an interface. 302 SONET/TDM and Fiber cross-connect networks are examples of 303 non-packet-TE networks. Circuit emulation in these networks 304 is accomplished by the switch fabric in the intermediary 305 nodes (based on TDM time slot, fiber interface or Lambda). 307 Unless specified otherwise, the term non-packet network is 308 used throughout the document to refer a non-packet-TE 309 network. 311 3.2.9. Mixed network 313 A mixed network is a network that is constituted of 314 packet-TE and non-TE networks combined. Traffic in the 315 network is strictly datagram oriented - IP datagrams or 316 MPLS packets. Routers in a mixed network may be TE or 317 native nodes. 319 OSPF-xTE is usable within a packet network or a mixed 320 network. 322 3.2.10. Peer network 324 A peer network is a network that is constituted of packet-TE 325 and non-packet-TE networks combined. In a peer network, a TE 326 node could potentially support TE links for the packet as 327 well as non-packet data. 329 OSPF-xTE is usable within a packet network or a non-packet 330 network or a peer network, which is a combination of the two. 332 3.2.11. CSPF 334 CSPF stands for "Constrained Shortest Path First". Given a TE 335 LSDB and a set of constraints that must be satisfied to form a 336 circuit path, there may be several CSPF algorithms to obtain a 337 TE circuit path that meets the criteria. 339 3.2.12. TLV 341 A TLV stands for an object in the form of Tag-Length-Value. All 342 TLVs are assumed to be of the following format, unless specified 343 otherwise. The Tag and length are 16 bits wide each. The length 344 includes the 4 octets required for Tag and Length specification. 345 All TLVs described in this document are padded to 32-bit 346 alignment. Any padding required for alignment will not be a part 347 of the length field, however. TLVs are used to describe traffic 348 engineering characteristics of the TE nodes, TE links and TE circuit 349 paths. 351 0 1 2 3 352 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 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Tag | Length (4 or more) | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Value .... | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | .... | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 3.2.13. Router-TE TLVs (Router TLVs) 363 TLVs used to describe the TE capabilities of a TE-node. 365 3.2.14. Link-TE TLVs (Link TLVs) 367 TLVs used to describe the TE capabilities of a TE-link. 369 4. Motivations behind the design of OSPF-xTE 371 There are several motivations that led to the design of OSPF-xTE. 372 OSPF-xTE is scalable, efficient and usable across a variety of 373 network topologies. These motivations are explained in detail in 374 the following subsections. The last subsection lists real-world 375 network scenarios that benefit from the OSPF-xTE. 377 4.1. Scalable design 379 OSPF-xTE area level abstraction provides the scaling required 380 for the TE topology in a large autonomous system (AS). 381 An OSPF-xTE area border router will advertise summary LSAs for 382 TE and non-TE topologies independent of each other. Readers 383 may refer to section 10 for a topological view of the AS from 384 the perspective of a OSPF-xTE node in an area. 386 [OPQLSA-TE], on the other hand, is designed for intra-area and 387 is not scalable to AS-wide scope. 389 4.2. Operable in mixed and peer networks 391 OSPF-xTE assumes that an AS may be constituted of coexisting 392 TE and non-TE networks. OSPF-xTE dynamically discovers TE 393 topology and the associated TE metrics of the nodes and links 394 that form the TE network. As such, OSPF-xTE generates a 395 stand-alone TE-LSDB that is fully representative of the TE 396 network. Stand-alone TE-LSDB allows for speedy TE computations. 398 [OPQLSA-TE] is designed for packet networks and is not suitable 399 for mixes and peer networks. TE-LSDB in [OPQLSA-TE] is derived 400 from the combination of opaque LSAs and native LSDB. Further, 401 the TE-LSDB thus derived has no knowledge of the TE 402 capabilities of the routers in the network. 404 4.3. Efficient in flooding reach 406 OSPF-xTE is able to identify the TE topology in a mixed network 407 and will limit the flooding of TE LSAs to just the TE-nodes. 408 Non-TE nodes are not bombarded with TE LSAs. 410 In a TE network, a subset of the TE metrics may be prone to rapid 411 change, while others remain largely unchanged. Changes in TE 412 metrics must be communicated at the earliest throughout the 413 network to ensure that the TE-LSDB is up-to-date within the 414 network. As a general rule, a TE network is likely to generate 415 significantly more control traffic than a native network. The 416 excess traffic is almost directly proportional to the rate at 417 which TE circuits are set up and torn down within the TE network. 418 The TE database synchronization should occur much quicker compared 419 to the aggregate circuit set up and tear-down rates. OSPF-xTE 420 defines TE-Incremental-Link-update LSA (section 8.2) to advertise 421 just a subset of the metrics that are prone to rapid changes. 423 The more frequent and wider the flooding frequency, the larger 424 the number of retransmissions and acknowledgements. The same 425 information (needed or not) may reach a router through multiple 426 links. Even if the router did not forward the information past 427 the node, it would still have to send acknowledgements across 428 all the various links on which the LSAs tried to converge. 429 It is undesirable to flood non-TE nodes with TE information. 431 4.4. Ability to reserve TE-exclusive links 433 OSPF-xTE draws a clear distinction between TE and non-TE 434 links. A TE link may be configured to permit TE traffic 435 alone, and not permit best-effort IP traffic on the link. 436 This permits TE enforceability on the TE links. 438 When links of a TE-topology do not overlap the links of a 439 native IP network, OSPF-xTE allows for virtual isolation of 440 the two networks. Best-effort IP network and TE network often 441 have different service requirements. Keeping the two networks 442 physically isolated can be expensive. Combining the two 443 networks into a single physically connected network will 444 bring economies of scale, while service enforceability 445 can be maintained individually for each of the TE and non-TE 446 sections of the network. 448 [OPQLSA-TE] does not support the ability to isolate best- 449 effort IP traffic from TE traffic on a link. All links are 450 subject to best-effort IP traffic. An OSPF router could 451 potentially select a TE link to be its least cost link and 452 inundate the link with best-effort IP traffic, thereby 453 rendering the link unusable for TE purposes. 455 4.5. Extendible design 457 OSPF-xTE design is based on the tried and tested OSPF paradigm, 458 and inherits all the benefits of the OSPF, present and future. 459 TE-LSAs are extendible, just as the native OSPF on which 460 OSPF-xTE is founded. 462 4.6. Unified for packet and non-packet networks 464 OSPF-xTE is usable within a packet network or a non-packet 465 network or a combination peer network. 467 Signaling protocols such as RSVP and LDP work the same across 468 packet and non-packet networks. Signaling protocols merely need 469 the TE characteristics of nodes and links so they can signal the 470 nodes to formulate TE circuit paths. In a peer network, the 471 underlying control protocol must be capable of providing a 472 unified LSDB for all TE nodes (nodes with packet-TE links as well 473 as non-packet-TE links) in the network. OSPF-xTE meets this 474 requirement. 476 4.7. Networks benefiting from the OSPF-xTE design 478 Below are examples of some real-world network scenarios that 479 benefit from OSPF-xTE. 481 4.7.1. IP providers transitioning to provide TE services 483 Providers needing to support MPLS based TE in their IP network 484 may choose to transition gradually. Perhaps, add new TE links 485 or convert existing links into TE links within an area first 486 and progressively advance to offer in the entire AS. 488 Not all routers will support TE extensions at the same time 489 during the migration process. Use of TE specific LSAs and their 490 flooding to OSPF-xTE only nodes will allow the vendor to 491 introduce MPLS TE without destabilizing the existing network. 492 The native OSPF-LSDB will remain undisturbed while newer TE 493 links are added to the network. 495 4.7.2. Providers offering Best-effort-IP & TE services 497 Providers choosing to offer both best-effort-IP and TE based 498 packet services simultaneously on the same physically connected 499 network will benefit from the OSPF-xTE design. By maintaining 500 independent LSDBs for each type of service, TE links are not 501 cannibalized in a mixed network. 503 4.7.3. Large TE networks 505 The OSPF-xTE design is advantageous in large TE networks that 506 require the AS to be sub-divided into multiple areas. OSPF-xTE 507 permits inter-area exchange of TE information, which ensures 508 that all nodes in the AS have up-to-date As-wide TE 509 reachability knowledge. This in turn will make TE circuit 510 setup predictable and computationally bounded. 512 4.7.4. Non-packet networks and Peer networks 514 Vendors may also use OSPF-xTE for their non-packet TE networks. 515 OSPF-xTE defines the following functions in support of 516 non-packet TE networks. 517 (a) "Positional-Ring" type network LSA and 518 (b) Router Proxying - allowing a router to advertise on behalf 519 of other nodes (that are not Packet/OSPF capable). 521 5. OSPF-xTE solution overview 523 5.1. OSPF-xTE Solution 525 Locally scoped opaque LSA (type 9) is used to discovery the TE 526 topology within a network. Section 7.1 describes in detail the 527 use of type 9 Opaque LSA for TE topology discovery. TE LSAs are 528 designed for use by the OSPF-xTE nodes. Section 8.0 describes 529 the TE LSAs in detail. Changes required of the OSPF data 530 structures to support OSPF-xTE are described in section 11.0. 531 A new TE-neighbors data structure will be used to advertise 532 TE LSAs along TE-topology. 534 An OSPF-xTE node will have the native LSDB and the TE-LSDB, 535 A native OSPF node will have just the native LSDB. 536 Consider the following OSPF area constituted of OSPF-xTE and 537 native OSPF routers. Nodes RT1, RT2, RT3 and RT6 are OSPF-xTE 538 routers with TE and non-TE link attachments. Nodes RT4 and RT5 539 are native OSPF routers with no TE links. When the LSA database 540 is synchronized, all nodes will share the same native LSDB. 541 OSPF-xTE nodes alone will have the additional TE-LSDB. 543 +---+ 544 | |--------------------------------------+ 545 |RT6|\\ | 546 +---+ \\ | 547 || \\ | 548 || \\ | 549 || \\ | 550 || +---+ | 551 || | |----------------+ | 552 || |RT1|\\ | | 553 || +---+ \\ | | 554 || //| \\ | | 555 || // | \\ | | 556 || // | \\ | | 557 +---+ // | \\ +---+ | 558 |RT2|// | \\|RT3|------+ 559 | |----------|----------------| | 560 +---+ | +---+ 561 | | 562 | | 563 | | 564 +---+ +---+ 565 |RT5|--------------|RT4| 566 +---+ +---+ 567 Legend: 568 -- Native(non-TE) network link 569 | Native(non-TE) network link 570 \\ TE network link 571 || TE network link 573 Figure 6: A (TE + native) OSPF network topology 575 5.2. Assumptions 577 OSPF-xTE is an extension to the native OSPF protocol and does not 578 mandate changes to the existing OSPF. OSPF-xTE design makes the 579 following assumptions. 581 1. An OSPF-xTE node will need to establish router adjacency with 582 at least one other OSPF-xTE node in the area in order for the 583 router's TE-database to be synchronized within the area. 584 Failing this, the OSPF router will not be in the TE 585 calculations of other TE routers in the area. 587 It is the responsibility of the network administrator(s) to 588 ensure connectedness of the TE network. Otherwise, there can 589 be disjoint TE topologies within a network. 591 2. OSPF-xTE nodes must advertise the link state of its TE-links. 592 TE-links are not obligated to support native IP traffic. 593 Hence, an OSPF-xTE node cannot be required to synchronize 594 its link-state database with neighbors on all its links. 595 The only requirement is to have the TE LSDB synchronized 596 across all OSPF-xTE nodes in the area. 598 3. A link in a packet network may be designated as a TE-link or 599 a native-IP link or both. For example, a link may be used for 600 both TE and non-TE traffic, so long as the link is 601 under-subscribed in bandwidth for TE traffic - say, 50% of 602 the link capacity is set aside for TE traffic. 604 4. Non-packet TE sub-topologies must have a minimum of one node 605 running OSPF-xTE protocol. For example, a SONET/SDH TDM ring 606 must have a minimum of one Gateway Network Element(GNE) 607 running OSPF-xTE. The OSPF-xTE node will advertise on behalf 608 of all the TE nodes in the ring. 610 6. Opaque LSAs to OSPF-xTE transition strategy 612 Below is a strategy to transition implementations currently using 613 opaque LSAs ([OPQLSA-TE]) within an area to adapt OSPF-xTE in 614 a gradual fashion across the AS. 616 1. Use [OPQLSA-TE] within an area. Derive TE topology within the 617 area from the combination of opaque LSAs and native LSDB. 619 2. Use TE-Summary LSAs and TE-AS-external-LSAs for inter-area 620 Communication. Make use of the TE-topology within an area to 621 summarize the TE networks in the area and advertise the same 622 to all TE-nodes in the backbone. The TE-ABRs on the backbone 623 area will in-turn advertise these summaries within their 624 connected areas. 626 7. OSPF-xTE router adjacency - TE topology discovery 628 OSPF creates adjacencies between neighboring routers for the purpose 629 of exchanging routing information. In the following subsections, we 630 describe the use of locally scoped Opaque LSA to discover OSPF-xTE 631 neighboring routers. The capability is used as the basis to build 632 TE topology. 634 7.1. The OSPF-xTE router adjacency 636 OSPF uses the options field in the hello packet to advertise optional 637 router capabilities [OSPF]. However, all the bits in this field have 638 been allocated and there is no way to advertise OSPF-xTE capability 639 using the options field at this time. This document proposes using 640 local scope opaque lsa (OPAQUE-9 LSA) to advertise support for 641 OSPF-xTE and establish OSPF-xTE adjacency. In order to exchange 642 Opaque LSAs, the neighboring routers must have the O-bit (Opaque 643 option bit) set in the options field as a prerequisite. 645 [OSPF-CAP] proposes a format for exchanging router capabilities 646 via OPAQUE-9 LSA. Routers supporting OSPF-xTE will be required to 647 set the "OSPF Experimental TE" bit within the "router 648 capabilities" field. Two routers will not become TE-neighbors 649 unless they share a common network link on which both routers 650 advertise support for OSPF-xTE. Routers that donot support 651 OSPF-xTE may simply ignore the advertisement. 653 7.2. The Hello Protocol 655 The Hello Protocol is primarily responsible for dynamically 656 establishing and maintaining neighbor adjacencies. In a TE network, 657 it is not required for all links and neighbors to establish 658 adjacency using this protocol. OSPF-xTE router adjacency between 659 two routers is established using the method described in the 660 previous section. 662 For NBMA and broadcast networks, the HELLO protocol is responsible 663 for electing the Designated Router and the Backup Designated 664 Router. Routers supporting the TE option shall be given a higher 665 precedence for becoming a designated router over those that do 666 not support TE. 668 7.3. The Designated Router 670 When a router's non-TE link first becomes functional, it checks to 671 see whether there is currently a Designated Router for the network. 672 If there is one, it accepts that Designated Router, regardless of 673 its Router Priority, so long as the current designated router is 674 TE compliant. Otherwise, the router itself becomes Designated 675 Router if it has the highest Router Priority on the network and is 676 TE compliant. 678 OSPF-xTE must be implemented on the most robust routers, as they 679 become likely candidates to take on the role as designated router. 681 7.4. The Backup Designated Router 683 The Backup Designated Router is also elected by the Hello 684 Protocol. Each Hello Packet has a field that specifies the 685 Backup Designated Router for the network. Once again, TE-compliance 686 must be weighed in conjunction with router priority in electing 687 the backup designated router. 689 7.5. Flooding and the Synchronization of Databases 691 In OSPF, adjacent routers within an area are required to 692 synchronize their databases. However, a more concise requirement 693 is that all routers in an area must converge on the same LSDB. 694 However, as stated in item 2 of section 5.2, a basic assertion 695 by OSPF-xTE is that the links used by the OSPF-xTE control 696 network for flooding must not be required to match the links 697 used by the data network for real-time data forwarding. For 698 instance, it should not be required to run the OSPF-xTE messages 699 over a TE-link that is configured not to permit non-TE traffic. 700 However, the control network must be setup such that a minimum 701 of one path exists between any two OSPF or OSPF-xTE routers 702 within the network for flooding purposes. This revised control 703 network connectivity requirement does not jeopardize 704 convergence of LSDB within an area. 706 In a mixed network, where some of the neighbors are TE 707 compliant and others are not, the designated OSPF-xTE router 708 will exchange different sets of LSAs with its neighbors. 709 TE LSAs are exchanged only with the TE neighbors. Native 710 LSAs are exchanged with all neighbors (TE and non-TE alike). 711 Restricting the scope of TE LSA flooding to just the 712 OSPF-xTE nodes will not effect the native nodes that coexist 713 with the OSPF-xTE nodes. 715 The control traffic for a TE network (i.e., TE LSA 716 advertisement) is likely to be higher than that of a native 717 OSPF network. This is because the TE metrics may vary with each 718 TE circuit setup and the corresponding state change must be 719 advertised at the earliest, not exceeding the MinLSInterval 720 of 5 seconds. To minimize advertising repetitive content, 721 OSPF-xTE defines a new TE-incremental-Link-update LSA 722 (section 8.2) that would advertise just the TLVs that changed 723 for a link. 725 A new OSPFIGP-TE multicast address 224.0.0.24 may be used for 726 the exchange of TE compliant database descriptors during 727 database synchronization. 729 7.6. The graph of adjacencies 731 If two routers have multiple networks in common, they may have 732 multiple adjacencies between them. The adjacency may be one of 733 two types - native OSPF adjacency and TE adjacency. OSPF-xTE 734 routers will form both types of adjacency. 736 Two types of adjacency graphs are possible depending on whether 737 a Designated Router is elected for the network. On physical 738 point-to-point networks, Point-to-Multipoint networks and 739 Virtual links, neighboring routers become adjacent whenever they 740 can communicate directly. The adjacency can be one of 741 (a) TE-compliant or (b) native. In contrast, on broadcast and 742 NBMA networks the designated router and the backup designated 743 router may maintain two sets of adjacency. The remaining routers 744 will form either TE-compliant or native adjacency. In the 745 Broadcast network below, routers RT7 and RT3 are chosen as the 746 designated and backup routers respectively. Routers RT3, RT4 747 and RT7 are TE-compliant. RT5 and RT6 are not. So, RT4 will 748 have TE-compliant adjacency with the designated and backup 749 routers. RT5 and RT6 will only have native adjacency with the 750 designated and backup routers. 752 Network Adjacency 754 +---+ +---+ 755 |RT1|------------|RT2| o--------------------o 756 +---+ N1 +---+ RT1 RT2 758 RT7 759 o::::: 760 +---+ +---+ +---+ /| : 761 |RT7| |RT3| |RT4| / | : 762 +---+ +---+ +---+ / | : 763 | | | / | : 764 +-----------------------+ RT5o RT6o oRT4 765 | | N2 * * : 766 +---+ +---+ * * : 767 |RT5| |RT6| * * : 768 +---+ +---+ ** : 769 o::::: 770 RT3 772 Adjacency Legend: 773 ----- Native adjacency (primary) 774 ***** Native adjacency (Backup) 775 ::::: TE-compliant adjacency (primary) 776 ;;;;; TE-compliant adjacency (Backup) 778 Figure 6: The graph of adjacencies with TE-compliant routers. 780 8. TE LSAs for packet network 782 The OSPFv2 protocol, as of now, has a total of 11 LSA types. 783 LSA types 1 through 5 are defined in [OSPF-v2]. LSA types 6, 7 784 and 8 are defined in [MOSPF], [NSSA] and [BGP-OSPF] respectively. 785 LSA types 9 through 11 are defined in [OPAQUE]. 787 Each LSA type has a unique flooding scope. Opaque LSA types 788 9 through 11 are general purpose LSAs, with flooding 789 scope set to link-local, area-local and AS-wide (except stub 790 areas) respectively. 792 In the following subsections, we define new LSAs for traffic 793 engineering (TE) use. The Values for the new TE LSA types are 794 assigned such that the high bit of the LSA-type octet is set 795 to 1. The new TE LSAs are largely modeled after the existing 796 LSAs for content format and have a unique flooding scope. 798 TE-router LSA is defined to advertise TE characteristics of 799 an OSPF-xTE router and all the TE-links attached to the 800 router. TE-incremental-Link-Update LSA is defined to 801 advertise incremental updates to the metrics of a TE link. 802 Flooding scope for both these LSAs is restricted to an area. 804 TE-Summary network and router LSAs are defined to advertise 805 the reachability of area-specific TE networks and Area Border 806 Routers (along with router TE characteristics) to external 807 areas. Flooding Scope of the TE-Summary LSAs is the TE topology 808 in the entire AS less the non-backbone area for which the 809 the advertising router is an ABR. Just as with native OSPF 810 summary LSAs, the TE-summary LSAs do not reveal the topological 811 details of an area to external areas. 813 TE-AS-external LSA and TE-Circuit-Path LSA are defined to 814 advertise AS external network reachability and pre-engineered 815 TE circuits respectively. While flooding scope for both these 816 LSAs can be the entire AS, flooding scope for the 817 pre-engineered TE circuit LSA may optionally be restricted to 818 just the TE topology within an area. 820 8.1. TE-Router LSA (0x81) 822 The TE-router LSA (0x81) is modeled after the router LSA and has the 823 same flooding scope as the router-LSA. However, the scope is 824 restricted to only the OSPF-xTE nodes within the area. The TE-router 825 LSA describes the TE metrics of the router as well as the TE-links 826 attached to the router. Below is the format of the TE-router LSA. 827 Unless specified explicitly otherwise, the fields carry the same 828 meaning as they do in a router LSA. Only the differences are 829 explained below. Router-TE flags, Router-TE TLVs, Link-TE options, 830 and Link-TE TLVs are each described in the following sub-sections. 832 0 1 2 3 833 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 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | LS age | Options | 0x81 | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | Link State ID | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | Advertising Router | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | LS sequence number | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | LS checksum | length | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | 0 |V|E|B| 0 | Router-TE flags | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Router-TE flags (contd.) | Router-TE TLVs | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | .... | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | .... | # of TE links | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Link ID | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Link Data | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Type | 0 | Link-TE flags | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Link-TE flags (contd.) | Zero or more Link-TE TLVs | 860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 861 | Link ID | 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Link Data | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | ... | 867 8.1.1. Router-TE flags - TE capabilities of the router 869 The following flags are used to describe the TE capabilities of an 870 OSPF-xTE router. The remaining bits of the 32-bit word are reserved 871 for future use. 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 |L|L|P| | | | |L|S|C| 875 |S|E|S| | | | |S|I|S| 876 |R|R|C| | | | |P|G|P| 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| 880 Bit LSR 881 When set, the router is considered to have LSR capability. 883 Bit LER 884 When set, the router is considered to have LER capability. 885 All MPLS border routers will be required to have the LER 886 capability. When the E bit is also set, that indicates an 887 AS Boundary router with LER capability. When the B bit is 888 also set, that indicates an area border router with LER 889 capability. 891 Bit PSC 892 Indicates the node is Packet Switch Capable. 894 Bit LSP 895 MPLS Label switch TLV TE-NODE-TLV-MPLS-SWITCHING follows. 896 This is applicable only when the PSC flag is set. 898 Bit SIG 899 MPLS Signaling protocol support TLV 900 TE-NODE-TLV-MPLS-SIG-PROTOCOLS follows. 902 BIT CSPF 903 CSPF algorithm support TLV TE-NODE-TLV-CSPF-ALG follows. 905 8.1.2. Router-TE TLVs 907 The following Router-TE TLVs are defined. 909 8.1.2.4. TE-NODE-TLV-MPLS-SWITCHING 911 MPLS switching TLV is applicable only for packet switched nodes. The 912 TLV specifies the MPLS packet switching capabilities of the TE 913 node. 915 0 1 2 3 916 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 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 | Tag = 0x8001 | Length = 6 | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Label depth | QOS | | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 'Label depth' is the depth of label stack the node is capable of 924 processing on its ingress interfaces. An octet is used to represent 925 label depth. A default value of 1 is assumed when the TLV is not 926 listed. Label depth is relevant when an LER has to pop off multiple 927 labels off the MPLS stack. 929 'QOS' is a single octet field that may be assigned '1' or '0'. Nodes 930 supporting QOS are able to interpret the EXP bits in the MPLS header 931 to prioritize multiple classes of traffic through the same LSP. 933 8.1.2.2. TE-NODE-TLV-MPLS-SIG-PROTOCOLS 935 MPLS signaling protocols TLV lists all the signaling protocol 936 supported by the node. An octet is used to list each signaling 937 protocol supported. 939 0 1 2 3 940 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 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Tag = 0x8002 | Length = 5, 6 or 7 | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Protocol-1 | ... | .... | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 RSVP-TE protocol is represented as 1, CR-LDP as 2 and LDP as 3. 948 These are the only permitted signaling protocols at this time. 950 8.1.2.3. TE-NODE-TLV-CSPF-ALGORITHMS 952 The CSPF algorithms TLV lists all the CSPF algorithm codes 953 supported. Support for CSPF algorithms makes the node eligible to 954 compute complete or partial circuit paths. Support for CSPF 955 algorithms can also be beneficial in knowing whether or not a node 956 is capable of expanding loose routes (in an MPLS signaling request) 957 into a detailed circuit path. 959 Two octets are used to list each CSPF algorithm code. The algorithm 960 codes may be vendor defined and unique within an Autonomous System. 961 If the node supports 'n' CSPF algorithms, the Length would be 962 (4 + 4 * ((n+1)/2)) octets. 964 0 1 2 3 965 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 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Tag = 0x8003 | Length = 4(1 + (n+1)/2) | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | CSPF-1 | .... | 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | CSPF-n | | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 8.1.2.4. TE-NODE-TLV-NULL 976 When a TE-Router or a TE-link has multiple TLVs to describe the 977 metrics, the NULL TLV is used to terminate the TLV list. 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 | Tag = 0x8888 | Length = 4 | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 985 8.1.3. Link-TE flags - TE capabilities of a link 987 The following flags are used to describe the TE capabilities of a 988 link. The remaining bits of the 32-bit word are reserved for 989 future use. 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 |T|N|P| | | |D| |S|L|B|C| 993 |E|T|K| | | |B| |R|U|W|O| 994 | |E|T| | | |S| |L|G| |L| 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| 998 TE - Indicates whether TE is permitted on the link. A link 999 can be denied for TE use by setting the flag to 0. 1001 NTE - Indicates whether non-TE traffic is permitted on the 1002 TE link. This flag is relevant only when the TE 1003 flag is set. 1005 PKT - Indicates whether or not the link is capable of IP 1006 packet processing. 1008 DBS - Indicates whether or not Database synchronization 1009 is permitted on this link. 1011 SRLG Bit - Shared Risk Link Group TLV TE-LINK-TLV-SRLG follows. 1013 LUG bit - Link usage cost metric TLV TE-LINK-TLV-LUG follows. 1015 BW bit - One or more Link bandwidth TLVs follow 1017 COL bit - Link Color TLV TE-LINK-TLV-COLOR follows. 1019 8.1.4. Link-TE TLVs 1021 8.1.4.1. TE-LINK-TLV-SRLG 1023 The SRLG describes the list of Shared Risk Link Groups (SRLG) the 1024 link belongs to. Two octets are used to list each SRLG. If the link 1025 belongs to 'n' SRLGs, the Length would be (4 + 4 * ((n+1)/2)) octets. 1027 0 1 2 3 1028 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 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | Tag = 0x0001 | Length = 4(1 + (n+1)/2) | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | SRLG-1 | .... | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1034 | SRLG-n | | 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 8.1.4.2. TE-LINK-TLV-BANDWIDTH-MAX 1039 The bandwidth TLV specifies maximum bandwidth of the link as follows. 1041 0 1 2 3 1042 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 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | Tag = 0x0002 | Length = 8 | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | Maximum Bandwidth | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 Bandwidth is expressed in units of 32 bytes/sec (256 bits/sec). 1050 A 32-bit field for bandwidth would permit specification not exceeding 1051 1 tera-bits/sec. 1053 'Maximum bandwidth' is be the maximum link capacity expressed in 1054 bandwidth units. Portions or all of this bandwidth may be used for 1055 TE use. 1057 8.1.4.3. TE-LINK-TLV-BANDWIDTH-MAX-FOR-TE 1059 The bandwidth TLV specifies maximum bandwidth available for TE use 1060 as follows. 1062 0 1 2 3 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Tag = 0x0003 | Length = 8 | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | Maximum Bandwidth available for TE use | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 Bandwidth is expressed in units of 32 bytes/sec (256 bits/sec). 1071 A 32-bit field for bandwidth would permit specification not exceeding 1072 1 tera-bits/sec. 1074 'Maximum bandwidth available for TE use' is the total reservable 1075 bandwidth on the link for use by all the TE circuit paths traversing 1076 the link. The link is oversubscribed when this field is more than 1077 the 'Maximum Bandwidth'. When the field is less than the 1078 'Maximum Bandwidth', the remaining bandwidth on the link may 1079 be used for non-TE traffic in a mixed network. 1081 8.1.4.4. TE-LINK-TLV-BANDWIDTH-TE 1083 The bandwidth TLV specifies the bandwidth reserved for TE as follows. 1085 0 1 2 3 1086 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 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 | Tag = 0x0004 | Length = 8 | 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 | TE Bandwidth subscribed | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 Bandwidth is expressed in units of 32 bytes/sec (256 bits/sec). 1094 A 32-bit field for bandwidth would permit specification not exceeding 1095 1 tera-bits/sec. 1097 'TE Bandwidth subscribed' is the bandwidth that is currently 1098 subscribed from of the link. 'TE Bandwidth subscribed' must be less 1099 than the 'Maximum bandwidth available for TE use'. New TE circuit 1100 paths are able to claim no more than the difference between the 1101 two bandwidths for reservation. 1103 8.1.4.5. TE-LINK-TLV-LUG 1105 The link usage cost TLV specifies Bandwidth unit usage cost, 1106 TE circuit set-up cost, and any time constraints for setup and 1107 teardown of TE circuits on the link. 1109 0 1 2 3 1110 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 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 | Tag = 0x0005 | Length = 28 | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 | Bandwidth unit usage cost | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | TE circuit set-up cost | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | TE circuit set-up time constraint | 1119 | | 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | TE circuit tear-down time constraint | 1122 | | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 Circuit Setup time constraint 1126 This 64-bit number specifies the time at or after which a 1127 TE-circuit path may be set up on the link. The set-up time 1128 constraint is specified as the number of seconds from the start 1129 of January 1, 1970 UTC. A reserved value of 0 implies no circuit 1130 setup time constraint. 1132 Circuit Teardown time constraint 1133 This 64-bit number specifies the time at or before which all 1134 TE-circuit paths using the link must be torn down. The teardown 1135 time constraint is specified as the number of seconds from the 1136 start of January 1 1970 UTC. A reserved value of 0 implies no 1137 circuit teardown time constraint. 1139 8.1.4.6. TE-LINK-TLV-COLOR 1141 The color TLV is similar to the SRLG TLV, in that an Autonomous 1142 System may choose to issue colors to a TE-link meeting certain 1143 criteria. The color TLV can be used to specify one or more colors 1144 assigned to the link as follows. Two octets are used to list each 1145 color. If the link belongs to 'n' number of colors, the Length 1146 would be (4 + 4 * ((n+1)/2)) octets. 1148 0 1 2 3 1149 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 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | Tag = 0x0006 | Length = 4(1 + (n+1)/2) | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | Color-1 | .... | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | Color-n | | 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 8.1.4.7. TE-LINK-TLV-NULL 1160 When a TE-link has multiple TLVs to describe its metrics, the NULL 1161 TLV is used to terminate the TLV list. The TE-LINK-TLV-NULL is same 1162 as the TE-NODE-TLV-NULL described in section 8.1.2.4 1164 8.2. TE-incremental-link-Update LSA (0x8d) 1166 A significant difference between a native OSPF network and a TE 1167 network is that the latter may be subject to frequent real-time 1168 circuit pinning and is likely to undergo TE-state updates. Some 1169 links might undergo changes more frequently than others. Flooding 1170 the network with TE-router LSAs at the aggregated speed of all 1171 link metric changes is simply not desirable. A smaller in size, 1172 TE-incremental-link-update LSA is designed to advertise only the 1173 incremental link updates. 1175 TE-incremental-link-Update LSA will be advertised as frequently 1176 as the link state is changed (not exceeding once every 1177 MinLSInterval seconds). The TE-link sequence is largely the 1178 advertisement of a sub-portion of router LSA. The sequence number on 1179 this will be incremented with the TE-router LSA's sequence as the 1180 basis. When an updated TE-router LSA is advertised within 30 minutes 1181 of the previous advertisement, the updated TE-router LSA will assume 1182 a sequence no. that is larger than the most frequently updated of 1183 its links. 1185 Below is the format of the TE-incremental-link-update LSA. 1187 0 1 2 3 1188 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 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | LS age | Options | 0x8d | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1192 | Link State ID (same as Link ID) | 1193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1194 | Advertising Router | 1195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1196 | LS sequence number | 1197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1198 | LS checksum | length | 1199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1200 | Link Data | 1201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1202 | Type | 0 | Link-TE options | 1203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1204 | Link-TE options | Zero or more Link-TE TLVs | 1205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 | # TOS | metric | 1207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1208 | ... | 1209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1210 | TOS | 0 | TOS metric | 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 Link State ID 1214 This would be exactly the same as would have been specified as 1215 as Link ID for a link within the router-LSA. 1217 Link Data 1218 This specifies the router ID the link belongs to. In majority of 1219 cases, this would be same as the advertising router. This choice 1220 for Link Data is primarily to facilitate proxy advertisement for 1221 incremental link updates. 1223 Say, a router-proxy-LSA was used to advertise the TE-router-LSA 1224 of a SONET/TDM node. Say, the proxy router is now required to 1225 advertise incremental-link-update for the same SONET/TDM node. 1226 Specifying the actual router-ID the link in the 1227 incremental-link-update-LSA belongs to helps receiving nodes in 1228 finding the exact match for the LSA in their database. 1230 The tuple of (LS Type, LSA ID, Advertising router) uniquely identify 1231 the LSA and replace LSAs of the same tuple with an older sequence 1232 number. However, there is an exception to this rule in the context 1233 of TE-link-update LSA. TE-Link update LSA will initially assume the 1234 sequence number of the TE-router LSA it belongs to. Further, when a 1235 new TE-router LSA update with a larger sequence number is advertised, 1236 the newer sequence number is assumed by al the link LSAs. 1238 8.3. TE-Circuit-path LSA (0x8C) 1240 TE-Circuit-path LSA may be used to advertise the availability of 1241 pre-engineered TE circuit path(s) originating from any router 1242 in the network. The flooding scope may be Area wide or AS wide. 1244 0 1 2 3 1245 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 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | LS age | Options | 0x84 | 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 | Link State ID | 1250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1251 | Advertising Router | 1252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 | LS sequence number | 1254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1255 | LS checksum | length | 1256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1257 | 0 |G|E|B|D|S|T|CktType| Circuit Duration (Optional) | 1258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 | Circuit Duration cont... | 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Circuit Duration cont.. | Circuit Setup time (Optional) | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1263 | Circuit Setup time cont... | 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | Circuit Setup time cont.. |Circuit Teardown time(Optional)| 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 | Circuit Teardown time cont... | 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 | Circuit Teardown time cont.. | No. of TE circuit paths | 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 | Circuit-TE ID | 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | Circuit-TE Data | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 | Type | 0 | Circuit-TE flags | 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1277 | Circuit-TE flags (contd.) | Zero or more Circuit-TE TLVs | 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | Circuit-TE ID | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | Circuit-TE Data | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | ... | 1285 Link State ID 1286 The ID of the far-end router or the far-end Link-ID to which the 1287 TE circuit path(s) is being advertised. 1289 TE-circuit-path(s) flags 1291 Bit G - When set, the flooding scope is set to be AS wide. 1292 Otherwise, the flooding scope is set to be area wide. 1294 Bit E - When set, the advertised Link-State ID is an AS boundary 1295 router (E is for external). The advertising router and 1296 the Link State ID belong to the same area. 1298 Bit B - When set, the advertised Link state ID is an Area border 1299 router (B is for Border) 1301 Bit D - When set, this indicates that the duration of circuit 1302 path validity follows. 1304 Bit S - When set, this indicates that Setup-time of the circuit 1305 path follows. 1307 Bit T - When set, this indicates that teardown-time of the 1308 circuit path follows. 1310 CktType 1311 This 4-bit field specifies the Circuit type of the Forward 1312 Equivalency Class (FC). 1314 0x01 - Origin is Router, Destination is Router. 1315 0x02 - Origin is Link, Destination is Link. 1316 0x04 - Origin is Router, Destination is Link. 1317 0x08 - Origin is Link, Destination is Router. 1319 Circuit Duration (Optional) 1320 This 64-bit number specifies the seconds from the time of the 1321 LSA advertisement for which the pre-engineered circuit path 1322 will be valid. This field is specified only when the D-bit is 1323 set in the TE-circuit-path flags. 1325 Circuit Setup time (Optional) 1326 This 64-bit number specifies the time at which the TE-circuit 1327 path may be set up. This field is specified only when the 1328 S-bit is set in the TE-circuit-path flags. The set-up time is 1329 specified as the number of seconds from the start of January 1330 1 1970 UTC. 1332 Circuit Teardown time (Optional) 1333 This 64-bit number specifies the time at which the TE-circuit 1334 path may be torn down. This field is specified only when the 1335 T-bit is set in the TE-circuit-path flags. The teardown time 1336 is specified as the number of seconds from the start of 1337 January 1 1970 UTC. 1339 No. of TE Circuit paths 1340 This specifies the number of pre-engineered TE circuit paths 1341 between the advertising router and the router specified in the 1342 link state ID. 1344 Circuit-TE ID 1345 This is the ID of the far-end router for a given TE-circuit 1346 path segment. 1348 Circuit-TE Data 1349 This is the virtual link identifier on the near-end router for 1350 a given TE-circuit path segment. This can be a private 1351 interface or handle the near-end router uses to identify the 1352 virtual link. 1354 The sequence of (circuit-TE ID, Circuit-TE Data) list the 1355 end-point nodes and links in the LSA as a series. 1357 Circuit-TE flags 1358 This lists the Zero or more TE-link TLVs that all member 1359 elements of the LSP meet. 1361 8.4. TE-Summary LSAs 1363 TE-Summary-LSAs are the Type 0x83 and 0x84 LSAs. These LSAs are 1364 originated by area border routers. TE-Summary-network-LSA (0x83) 1365 describes the reachability of TE networks in a non-backbone 1366 area, advertised by the Area Border Router. Type 0x84 1367 summary-LSA describes the reachability of Area Border Routers 1368 and AS border routers and their TE capabilities. 1370 One of the benefits of having multiple areas within an AS is 1371 that frequent TE advertisements within the area do not impact 1372 outside the area. Only the TE abstractions befitting the 1373 external areas are advertised. 1375 8.4.1. TE-Summary Network LSA (0x83) 1377 TE-summary network LSA may be used to advertise reachability of 1378 TE-networks accessible to areas external to the originating 1379 area. The content and the flooding scope of a TE-Summary LSA 1380 is different from that of a native summary LSA. 1382 The scope of flooding for a TE-summary network is AS wide, with 1383 the exception of the originating area and the stub areas. The 1384 area border router for each non-backbone area is responsible 1385 for advertising the reachability of backbone networks into the 1386 area. 1388 Unlike a native-summary network LSA, TE-summary network LSA does 1389 not advertise summary costs to reach networks within an area. 1390 This is because TE parameters are not necessarily additive or 1391 comparative. The parameters can be varied in their expression. 1392 For example, a TE-summary network LSA will not summarize a 1393 network whose links do not fall under an SRLG (Shared-Risk Link 1394 Group). This way, the TE-summary LSA merely advertises the 1395 reachability of TE networks within an area. The specific circuit 1396 paths can be computed by the BDRs. Pre-engineered circuit paths 1397 are advertised using TE-Circuit-path LSA (refer section 8.3). 1399 0 1 2 3 1400 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 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | LS age | Options | 0x83 | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 | Link State ID (IP Network Number) | 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 | Advertising Router (Area Border Router) | 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | LS sequence number | 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1410 | LS checksum | length | 1411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1412 | Network Mask | 1413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1414 | Area-ID | 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 8.4.2. TE-Summary router LSA (0x84) 1419 TE-summary router LSA may be used to advertise the availability of 1420 Area Border Routers (ABRs) and AS Border Routers (ASBRs) that are 1421 TE capable. The TE-summary router LSAs are originated by the Area 1422 Border Routers. The scope of flooding for the TE-summary router LSA 1423 is the non-backbone area the advertising ABR belongs to. 1425 0 1 2 3 1426 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 1427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 | LS age | Options | 0x84 | 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 | Link State ID | 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | Advertising Router (ABR) | 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 | LS sequence number | 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 | LS checksum | length | 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | 0 |E|B| 0 | No. of Areas | 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 | Area-ID | 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 | ... | 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 | Router-TE flags | 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | Router-TE TLVs | 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 | .... | 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 Link State ID 1452 The ID of the Area border router or the AS border router whose 1453 TE capability is being advertised. 1455 Advertising Router 1456 The ABR that advertises its TE capabilities (and the OSPF areas 1457 it belongs to) or the TE capabilities of an ASBR within one of 1458 the areas the ABR is a border router of. 1460 No. of Areas 1461 Specifies the number of OSPF areas the link state ID belongs to. 1463 Area-ID 1464 Specifies the OSPF area(s) the link state ID belongs to. When 1465 the link state ID is same as the advertising router ID, the 1466 Area-ID lists all the areas the ABR belongs to. In the case 1467 the link state ID is an ASBR, the Area-ID simply lists the 1468 area the ASBR belongs to. The advertising router is assumed to 1469 be the ABR from the same area the ASBR is located in. 1471 Summary-router-TE flags 1473 Bit E - When set, the advertised Link-State ID is an AS boundary 1474 router (E is for external). The advertising router and 1475 the Link State ID belong to the same area. 1477 Bit B - When set, the advertised Link state ID is an Area 1478 border router (B is for Border) 1480 Router-TE flags, 1481 Router-TE TLVs (TE capabilities of the link-state-ID router) 1483 TE Flags and TE TLVs are as applicable to the ABR/ASBR 1484 specified in the link state ID. The semantics is same as 1485 specified in the Router-TE LSA. 1487 8.5. TE-AS-external LSAs (0x85) 1489 TE-AS-external-LSAs are the Type 0x85 LSAs. This is modeled after 1490 AS-external LSA format and flooding scope. TE-AS-external LSAs are 1491 originated by AS boundary routers with TE extensions, and describe 1492 the TE networks and pre-engineered circuit paths external to the 1493 AS. As with AS-external LSA, the flooding scope of the 1494 TE-AS-external LSA is AS wide, with the exception of stub areas. 1496 0 1 2 3 1497 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 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 | LS age | Options | 0x85 | 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 | Link State ID | 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | Advertising Router | 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 | LS sequence number | 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 | LS checksum | length | 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 | Network Mask | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | Forwarding address | 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | External Route Tag | 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 | # of Virtual TE links | 0 | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | Link-TE flags | 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 | Link-TE TLVs | 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 | ... | 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 | TE-Forwarding address | 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 | External Route TE Tag | 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 | ... | 1529 Network Mask 1530 The IP address mask for the advertised TE destination. For 1531 example, this can be used to specify access to a specific 1532 TE-node or TE-link with an mask of 0xffffffff. This can also 1533 be used to specify access to an aggregated set of destinations 1534 using a different mask. ex: 0xff000000. 1536 Link-TE flags, 1537 Link-TE TLVs 1538 The TE attributes of this route. These fields are optional and 1539 are provided only when one or more pre-engineered circuits can 1540 be specified with the advertisement. Without these fields, 1541 the LSA will simply state TE reachability info. 1543 Forwarding address 1544 Data traffic for the advertised destination will be forwarded to 1545 this address. If the Forwarding address is set to 0.0.0.0, data 1546 traffic will be forwarded instead to the LSA's originator (i.e., 1547 the responsible AS boundary router). 1549 External Route Tag 1550 A 32-bit field attached to each external route. This is not 1551 used by the OSPF protocol itself. It may be used to communicate 1552 information between AS boundary routers; the precise nature of 1553 such information is outside the scope of this specification. 1555 9. TE LSAs for non-packet network 1557 A non-packet network would use the TE LSAs described in the 1558 previous section for a packet network with some variations. 1559 These variations are described in the following subsections. 1561 Two new LSAs, TE-Positional-ring-network LSA and TE-Router-Proxy 1562 LSA are defined for use in non-packet TE networks. 1564 Readers may refer to [SONET-SDH] for a detailed description of 1565 the terms used in the context of SONET/SDH TDM networks, 1567 9.1. TE-Router LSA (0x81) 1569 The following fields are used to describe each router link (i.e., 1570 interface). Each router link is typed (see the below Type field). 1571 The Type field indicates the kind of link being described. 1573 Type 1574 A new link type "Positional-Ring Type" (value 5) is defined. 1575 This is essentially a connection to a TDM-Ring. TDM ring network 1576 is different from LAN/NBMA transit network in that nodes on the 1577 TDM ring do not necessarily have a terminating path between 1578 themselves. Secondly, the order of links is important in 1579 determining the circuit path. Third, the protection switching 1580 and the number of fibers from a node going into a ring are 1581 determined by the ring characteristics. I.e., 2-fiber vs 1582 4-fiber ring and UPSR vs BLSR protected ring. 1584 Type Description 1585 __________________________________________________ 1586 1 Point-to-point connection to another router 1587 2 Connection to a transit network 1588 3 Connection to a stub network 1589 4 Virtual link 1590 5 Positional-Ring Type. 1592 Link ID 1593 Identifies the object that this router link connects to. 1594 Value depends on the link's Type. For a positional-ring type, 1595 the Link ID shall be IP Network/Subnet number just as the case 1596 with a broadcast transit network. The following table 1597 summarizes the updated Link ID values. 1599 Type Link ID 1600 ______________________________________ 1601 1 Neighboring router's Router ID 1602 2 IP address of Designated Router 1603 3 IP network/subnet number 1604 4 Neighboring router's Router ID 1605 5 IP network/subnet number 1607 Link Data 1608 This depends on the link's Type field. For type-5 links, this 1609 specifies the router interface's IP address. 1611 9.1.1. Router-TE flags - TE capabilities of the router 1613 Flags specific to non-packet TE-nodes are described below. 1615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1616 |L|L|P|T|L|F| |S|S|S|C| 1617 |S|E|S|D|S|S| |T|E|I|S| 1618 |R|R|C|M|C|C| |A|L|G|P| 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| 1622 Bit TDM 1623 Indicates the node is TDM circuit switch capable. 1625 Bit LSC 1626 Indicates the node is Lambda switch Capable. 1628 Bit FSC 1629 Indicates the node is Fiber (can also be a non-fiber link 1630 type) switch capable. 1632 9.1.2. Link-TE options - TE capabilities of a TE-link 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 |T|N|P|T|L|F|D| |S|L|B|C| 1636 |E|T|K|D|S|S|B| |R|U|W|O| 1637 | |E|T|M|C|C|S| |L|G|A|L| 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| 1640 TDM, LSC, FSC bits 1641 - Same as defined for router TE options. 1643 9.2. TE-Positional-ring-network LSA (0x82) 1645 Network LSA is adequate for packet TE networks. A new 1646 TE-Positional-Ring-network-LSA is defined to represent type-5 1647 link networks, found in non-packet networks such as SONET/SDH 1648 TDM rings. A type-5 ring is a collection of network elements 1649 (NEs) forming a closed loop. Each NE is connected to two 1650 adjacent NEs via a duplex connection to provide redundancy 1651 in the ring. The sequence in which the NEs are placed on the 1652 Ring is pertinent. The NE that provides the OSPF-xTE 1653 functionality is termed the Gateway Network Element (GNE). 1654 The GNE selection criteria is outside the scope of this 1655 document. The GNE is also termed the Designated Router for 1656 the ring. 1658 The TE-Positional-ring-network LSA (0x82) is modeled after the 1659 network LSA and has the same flooding scope as the network-LSA 1660 amongst the OSPF-xTE nodes within the area. Below is the format 1661 of the TE-Positional-ring-network LSA. Unless specified 1662 explicitly otherwise, the fields carry the same meaning as they 1663 do in a network LSA. Only the differences are explained below. 1664 TE-Positional-ring-network-LSA is originated for each 1665 Positional-Ring type network in the area. The tuple of (Link 1666 State ID, Network Mask) below uniquely represents a ring. The 1667 TE option must be set in the Options flag while propagating 1668 the LSA. 1670 0 1 2 3 1671 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 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 | LS age | Options | 0x82 | 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 | Link State ID | 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | Advertising Router | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 | LS sequence number | 1680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 | LS checksum | length | 1682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 | Network Mask | 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 | Ring Type | Capacity Unit | Reserved | 1686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1687 | Ring capacity | 1688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1689 | Network Element Node Id | 1690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1691 | ... | 1693 Link State ID 1694 This is the IP interface address of the network's Gateway 1695 Network Element, which is also the designated router. 1697 Advertising Router 1698 Router ID of the network's Designated Router. 1700 Ring type 1702 There are 8 types of SONET/SDH rings defined as follows. 1704 1 - A Unidirectional Line Switched 2-fiber ring (2-fiber ULSR) 1705 2 - A bi-directional Line switched 2-fiber ring (2-fiber BLSR) 1706 3 - A Unidirectional Path Switched 2-fiber ring (2-fiber UPSR) 1707 4 - A bi-directional Path switched 2-fiber ring (2-fiber BPSR) 1708 5 - A Unidirectional Line Switched 4-fiber ring (4-fiber ULSR) 1709 6 - A bi-directional Line switched 4-fiber ring (4-fiber BLSR) 1710 7 - A Unidirectional Path Switched 4-fiber ring (4-fiber UPSR) 1711 8 - A bi-directional Path switched 4-fiber ring (4-fiber BPSR) 1713 Capacity unit 1714 Two units are defined at this time as follows. 1715 1 - Synchronous Transport Signal (STS), which is the basic 1716 signal rate for SONET signals. The rate of an STS signal 1717 is 51.84 Mbps 1718 2 - Synchronous Transport Multiplexer(STM), which is the 1719 basic signal rate for SDH signals. The rate of an STM 1720 signal is 155.52 Mbps 1722 Ring capacity 1723 Ring capacity expressed in number of Capacity units. 1725 Network Element Node Id 1727 The Router ID of each of the routers in the positional-ring 1728 network. The list must start with the designated router as 1729 the first element. The Network Elements (NEs) must be listed 1730 in strict clockwise order as they appear on the ring, 1731 starting with the Gateway Network Element (GNE). The number 1732 of NEs in the ring can be deduced from the LSA header's 1733 length field. 1735 9.3. TE-Router-Proxy LSA (0x8e) 1737 This is a variation to the TE-router LSA in that the TE-router LSA 1738 is not advertised by the network element, but rather by a trusted 1739 TE-router Proxy. This is typically the scenario in a non-packet 1740 TE network, where some of the nodes do not have OSPF functionality 1741 and count on a helper node to do the advertisement for them. One 1742 such example would be the SONET/SDH ADM nodes in a TDM ring. The 1743 nodes may principally depend upon the GNE (Gateway Network 1744 Element) to do the advertisement for them. TE-router-Proxy LSA 1745 shall not be used to advertise Area Border Routers and/or AS border 1746 Routers. 1748 0 1 2 3 1749 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 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 | LS age | Options | 0x8e | 1752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 | Link State ID (Router ID of the TE Network Element) | 1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1755 | Advertising Router | 1756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1757 | LS sequence number | 1758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1759 | LS checksum | length | 1760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1761 | 0 | Router-TE flags | 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1763 | Router-TE flags (contd.) | Router-TE TLVs | 1764 +---------------------------------------------------------------+ 1765 | .... | 1766 +---------------------------------------------------------------+ 1767 | .... | # of TE links | 1768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 | Link ID | 1770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1771 | Link Data | 1772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 | Type | 0 | Link-TE options | 1774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1775 | Link-TE flags | Zero or more Link-TE TLVs | 1776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1777 | Link ID | 1778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1779 | Link Data | 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1781 | ... | 1783 10. Abstract topology representation with TE support 1785 Below, we consider a TE network composed of three OSPF areas - 1786 Area-1, Area-2 and Area-3, attached together through the backbone 1787 area. Area-1 an has a single area border router, ABR-A1 and no 1788 ASBRs. Area-2 has an area border router ABR-A2 and an AS border 1789 router ASBR-S1. Area-3 has two area border routers ABR-A2 and 1790 ABR-A3 and an AS border router ASBR-S2. The following network 1791 also assumes a pre-engineered TE circuit path between ABR-A1 1792 and ABR-A2; between ABR-A1 and ABR-A3; between ABR-A2 and 1793 ASBR-S1; and between ABR-A3 and ASBR-S2. 1795 The following figure is an inter-area topology abstraction 1796 from the perspective of routers in Area-1. The abstraction 1797 illustrates reachability of TE networks and nodes within area 1798 to the external areas in the same AS and to the external ASes. 1799 The abstraction also illustrates pre-engineered TE circuit 1800 paths advertised by ABRs and ASBRs. 1802 +-------+ 1803 |Area-1 | 1804 +-------+ 1805 +-------------+ | 1806 |Reachable TE | +--------+ 1807 |networks in |-------| ABR-A1 | 1808 |backbone area| +--------+ 1809 +-------------+ | | | 1810 +--------------+ | +-----------------+ 1811 | | | 1812 +-----------------+ | +-----------------+ 1813 |Pre-engineered TE| +----------+ |Pre-engineered TE| 1814 |circuit path(s) | | Backbone | |circuit path(s) | 1815 |to ABR-A2 | | Area | |to ABR-A3 | 1816 +-----------------+ +----------+ +-----------------+ 1817 | | | | 1818 +----------+ | +--------------+ | 1819 +-----------+ | | | | +-----------+ 1820 |Reachable | +--------+ +--------+ |Reachable | 1821 |TE networks|------| ABR-A2 | | ABR-A3 |--|TE networks| 1822 |in Area A2 | +--------+ +--------+ |in Area A3 | 1823 +-----------+ | | | | | | +-----------+ 1824 +-------------+ | | +-----------------+ | +----------+ 1825 | | +-----------+ | | | 1826 +-----------+ +--------------+ | | | +--------------+ 1827 |Reachable | |Pre-engineered| | | | |Pre-engineered| 1828 |TE networks| |TE Ckt path(s)| +------+ +------+ |TE Ckt path(s)| 1829 |in Area A3 | |to ASBR-S1 | |Area-2| |Area-3| |to ASBR-S2 | 1830 +-----------+ +--------------+ +------+ +------+ +--------------+ 1831 | | | | 1832 | +--------+ | +-----------+ 1833 +-------------+ | | | | 1834 |AS external | +---------+ +---------+ 1835 |TE-network |----| ASBR-S1 | | ASBR-S2 | 1836 |reachability | +---------+ +---------+ 1837 |from ASBR-S1 | | | | 1838 +-------------+ +---+ +-------+ +-----------+ 1839 | | | 1840 +-----------------+ +-------------+ +-----------------+ 1841 |Pre-engineered TE| |AS External | |Pre-engineered TE| 1842 |circuit path(s) | |TE-Network | |circuit path(s) | 1843 |reachable from | |reachability | |reachable from | 1844 |ASBR-S1 | |from ASBR-S2 | |ASBR-S2 | 1845 +-----------------+ +-------------+ +-----------------+ 1847 Figure 9: Inter-Area Abstraction as viewed by Area-1 TE-routers 1849 11. Changes to Data structures in OSPF-xTE nodes 1851 11.1. Changes to Router data structure 1853 An OSPF-xTE router must be able to include the router-TE 1854 capabilities (as specified in section 8.1) in the router data 1855 structure. OSPF-xTE routers providing proxy service to other TE 1856 routers must also track the router and associated interface data 1857 structures for all the TE client nodes for which the proxy 1858 service is being provided. Presumably, the interaction between 1859 the Proxy server and the proxy clients is out-of-band. 1861 11.2. Two sets of Neighbors 1863 Two sets of neighbor data structures are required. TE-neighbors 1864 set is used to advertise TE LSAs. Only the TE-nodes will be 1865 members of the TE-neighbor set. Native neighbors set will be used 1866 to advertise native LSAs. All neighboring nodes supporting 1867 non-TE links are part of the Native neighbors set. 1869 11.3. Changes to Interface data structure 1871 The following new fields are introduced to the interface data 1872 structure. 1874 TePermitted 1875 If the value of the flag is TRUE, the interface may be 1876 advertised as a TE-enabled interface. 1878 NonTePermitted 1879 If the value of the flag is TRUE, the interface permits non-TE 1880 traffic on the interface. Specifically, this is applicable to 1881 packet networks, where data links may permit both TE and IP 1882 packets. For FSC and LSC TE networks, this flag is set to 1883 FALSE. 1885 FloodingPermitted 1886 If the value of the flag is TRUE, the interface may be used 1887 for OSPF and OSPF-xTE packet exchange to synchronize the 1888 LSDB across all adjacent neighbors. This is TRUE by default 1889 to all NonTePermitted interfaces that are enabled for OSPF. 1890 However, it is possible to set this to FALSE 1891 for some of the interfaces. 1893 TE-TLVs 1894 Each interface may define any number of TLVS that describe 1895 the link characteristics. 1897 The following existing fields in Interface data structure will take 1898 on additional values to support TE extensions. 1900 Type 1901 The OSPF interface type can also be of type "Positional-RING". 1902 The Positional-ring type is different from other types (such 1903 as broadcast and NBMA) in that the exact location of the nodes 1904 on the ring is relevant, even though they are all on the same 1905 ring. SONET ADM ring is a good example of this. Complete ring 1906 positional-ring description may be provided by the GNE on a 1907 ring as a TE-network LSA for the ring. 1909 List of Neighbors 1910 The list may be statically defined for an interface without 1911 requiring the use of Hello protocol. 1913 12. IANA Considerations 1915 This document proposes that TE LSA types and TE TLVs be 1916 maintained by the IANA. The document also proposes an OSPFIGP-TE 1917 multicast address be assigned by the IANA for the exchange of 1918 TE database descriptors. 1920 OSPFIGP-TE multicast address is suggested a value of 224.0.0.24 1921 so as not to conflict with the recognized multicast address 1922 definitions, as defined in 1923 http://www.iana.org/assignments/multicast-addresses 1925 The following sub-section explains the criteria to be used by the 1926 IANA to assign TE LSA types and TE TLVs. 1928 12.1. TE LSA type values 1930 LSA type is an 8-bit field required by each LSA. TE LSA types 1931 will have the high bit set to 1. TE LSAs can range from 0x80 1932 through 0xFF. The following values are defined in sections 1933 8.0 and 9.0. The remaining values are available for assignment 1934 by the IANA with IETF Consensus [Ref 11]. 1936 TE LSA Type Value 1937 _________________________________________ 1938 TE-Router LSA 0x81 1939 TE-Positional-ring-network LSA 0x82 1940 TE-Summary Network LSA 0x83 1941 TE-Summary router LSA 0x84 1942 TE-AS-external LSAs 0x85 1943 TE-Circuit-paths LSA 0x8C 1944 TE-incremental-link-Update LSA 0x8d 1945 TE-Router-Proxy LSA 0x8e 1947 12.2. TE TLV tag values 1949 TLV type is a 16-bit field required by each TE TLV. TLV type 1950 shall be unique across the router and link TLVs. A TLV type 1951 can range from 0x0001 through 0xFFFF. TLV type 0 is reserved 1952 and unassigned. The following TLV types are defined in sections 1953 8.0 and 9.0. The remaining values are available for assignment 1954 by the IANA with IETF Consensus [Ref 11]. 1956 TE TLV Tag Reference Value 1957 Section 1958 _________________________________________________________ 1960 TE-LINK-TLV-SRLG Section 8.1.4.1 0x0001 1961 TE-LINK-TLV-BANDWIDTH-MAX Section 8.1.4.2 0x0002 1962 TE-LINK-TLV-BANDWIDTH-MAX-FOR-TE Section 8.1.4.3 0x0003 1963 TE-LINK-TLV-BANDWIDTH-TE Section 8.1.4.4 0x0004 1964 TE-LINK-TLV-LUG Section 8.1.4.5 0x0005 1965 TE-LINK-TLV-COLOR Section 8.1.4.6 0x0006 1966 TE-LINK-TLV-NULL Section 8.1.4.7 0x8888 1967 TE-NODE-TLV-MPLS-SWITCHING Section 8.1.2.1 0x8001 1968 TE-NODE-TLV-MPLS-SIG-PROTOCOLS Section 8.1.2.2 0x8002 1969 TE-NODE-TLV-CSPF-ALG Section 8.1.2.3 0x8003 1970 TE-NODE-TLV-NULL Section 8.1.2.4 0x8888 1972 13. Acknowledgements 1974 The authors wish to specially thank Chitti Babu and his team 1975 for implementing the protocol specified in a packet network 1976 and verifying several portions of the specification in a 1977 mixed packet network. The authors also wish to thank Vishwas 1978 Manral, Riyad Hartani and Tricci So for their valuable 1979 comments and feedback on the draft. Lastly, the authors wish 1980 to thank Alex Zinin and Mike Shand for their draft (now 1981 defunct) titled "Flooding optimizations in link state routing 1982 protocols". The draft provided inspiration to the authors to 1983 be sensitive to the high flooding rate, likely in TE networks. 1985 14. Security Considerations 1987 Security considerations for the base OSPF protocol are covered 1988 in [OSPF-v2] and [SEC-OSPF]. This memo does not create any new 1989 security issues for the OSPF protocol. Security measures 1990 applied to the native OSPF (refer [SEC-OSPF]) are directly 1991 applicable to the TE LSAs described in the document. Discussed 1992 below are the security considerations in processing TE LSAs. 1994 Secure communication between OSPF-xTE nodes has a number of 1995 components. Authorization, authentication, integrity and 1996 confidentiality. Authorization refers to whether a particular 1997 OSPF-xTE node is authorized to receive or propagate the TE LSAs 1998 to its neighbors. Failing the authorization process might 1999 indicate a resource theft attempt or unauthorized resource 2000 advertisement. In either case, the OSPF-xTE nodes should take 2001 proper measures to audit/log such attempts so as to alert the 2002 administrator to take necessary action. OSPF-xTE nodes may 2003 refuse to communicate with the neighboring nodes that fail to 2004 prompt the required credentials. 2006 Authentication refers to confirming the identity of an originator 2007 for the datagrams received from the originator. Lack of strong 2008 credentials for authentication of OSPF-xTE LSAs can seriously 2009 jeopardize the TE service rendered by the network. A consequence 2010 of not authenticating a neighbor would be that an attacker could 2011 spoof the identity of a "legitimate" OSPF-xTE node and manipulate 2012 the state, and the TE database including the topology and 2013 metrics collected. This could potentially cause 2014 denial-of-service on the TE network. Another consequence of not 2015 authenticating is that an attacker could pose as OSPF-xTE 2016 neighbor and respond in a manner that would divert TE data to the 2017 attacker. 2019 Integrity is required to ensure that an OSPF-xTE message has not 2020 been accidentally or maliciously altered or destroyed. The result 2021 of a lack of data integrity enforcement in an untrusted environment 2022 could be that an imposter will alter the messages sent by a 2023 legitimate adjacent neighbor and bring the OSPF-xTE on a node and 2024 the whole network to a halt or cause a denial of service for the 2025 TE circuit paths effected by the alteration. 2027 Confidentiality of MIDCOM messages ensure that the TE LSAs are 2028 accessible only to the authorized entities. When OSPF-xTE is 2029 deployed in an untrusted environment, lack of confidentiality will 2030 allow an intruder to perform traffic flow analysis and snoop the 2031 TE control network to monitor the traffic metrics and the rate at 2032 which circuit paths are being setup and torn-down. The intruder 2033 could cannibalize a lesser secure OSPF-xTE node and destroy or 2034 compromise the state and TE-LDSB on the node. Needless to say, the 2035 least secure OSPF-xTE will become the Achilles heel and make the 2036 TE network vulnerable to security attacks. 2038 15. Normative References 2040 [IETF-STD] Bradner, S., "Key words for use in RFCs to indicate 2041 Requirement Levels", BCP 14, RFC 2119, March 1997. 2043 [RFC 1700] J. Reynolds and J. Postel, "Assigned Numbers", 2044 RFC 1700 2046 [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for 2047 writing an IANA Considerations Section in RFCs", 2048 BCP 26, RFC 2434, October 1998. 2050 [MPLS-TE] Awduche, D., et al, "Requirements for Traffic 2051 Engineering Over MPLS," RFC 2702, September 1999. 2053 [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 2055 [SEC-OSPF] Murphy, S., Badger, M., and B. Wellington, "OSPF with 2056 Digital Signatures", RFC 2154, June 1997. 2058 [OSPF-CAP] Lindem, A., Shen, N., Aggarwal, R., Schaffer, S., and 2059 Vasseur, JP., "Extensions to OSPF for advertising 2060 optional router capabilities", 2061 draft-ietf-ospf-cap-04.txt (work in progress) 2063 16. Informative References 2065 [RSVP-TE] Awduche, D., L. Berger, D. Gan, T. Li, V. Srinivasan, 2066 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2067 Tunnels", RFC 3209, IETF, December 2001 2069 [CR-LDP] Jamoussi, B. et al, "Constraint-Based LSP Setup 2070 using LDP", RFC 3212, January 2002. 2072 [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, 2073 March 1994. 2075 [NSSA] P. Murphy, "The OSPF NSSA Option", RFC 3101, January 2076 2003 2078 [OPAQUE] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 2079 July 1998. 2081 [OPQLSA-TE] Katz, D., D. Yeung and K. Kompella, "Traffic 2082 Engineering Extensions to OSPF", RFC 3630, September 2083 2003. 2085 [SONET-SDH] Ming-CHwan Chow, "Understanding SONET/SDH Standards 2086 and Applications" - A paperback or bound book, 2087 Published by Andan publisher. 2089 [GMPLS-TE] L. Berger, "Generalized Multi Protocol Label 2090 Switching (GMPLS) Signaling Functional Description", 2091 RFC 3471, January 2003 2093 17. Authors' Addresses 2095 Pyda Srisuresh 2096 Caymas Systems, Inc. 2097 1179-A North McDowell Blvd. 2098 Petaluma, CA 94954 2099 U.S.A. 2100 EMail: srisuresh@yahoo.com 2102 Paul Joseph 2103 Symbol Technologies 2104 U.S.A. 2105 EMail: 2107 18. Full Copyright Statement 2109 Copyright (C) The Internet Society (2004). This document is subject 2110 to the rights, licenses and restrictions contained in BCP 78, and 2111 except as set forth therein, the authors retain all their rights." 2113 This document and the information contained herein are provided on an 2114 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2115 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2116 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2117 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2118 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2119 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.