idnits 2.17.1 draft-srisuresh-ospf-te-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 142 instances of lines with control characters in the document. ** The abstract seems to contain references ([OPQLSA-TE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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: ---------------------------------------------------------------------------- == Line 1397 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 (February 7, 2003) is 7748 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 655, but not defined == Missing Reference: 'MPLS-ARCH' is mentioned on line 177, but not defined == Missing Reference: 'OSPF-NSSA' is mentioned on line 655, but not defined == Missing Reference: 'BGP-OSPF' is mentioned on line 813, but not defined == Missing Reference: 'Ref 11' is mentioned on line 1987, but not defined == Unused Reference: 'IETF-STD' is defined on line 2072, but no explicit reference was found in the text == Unused Reference: 'RFC 1700' is defined on line 2075, but no explicit reference was found in the text == Unused Reference: 'RFC 2434' is defined on line 2078, 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') -- Obsolete informational reference (is this intentional?): RFC 2370 (ref. 'OPAQUE') (Obsoleted by RFC 5250) Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Srisuresh 3 INTERNET-DRAFT Consultant 4 Expires as of August 7, 2003 P. Joseph 5 Force10 Networks 6 February 7, 2003 8 OSPF-xTE: An experimental extension to OSPF for Traffic Engineering 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet- Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document defines OSPF-xTE, an experimental traffic engineering 35 (TE) extension to the link-state routing protocol OSPF. New TE LSAs 36 are defined to disseminate TE metrics within an autonomous 37 System (AS) - intra-area as well as inter-area. An Autonomous 38 System may consist of TE and non-TE nodes. Non-TE nodes are 39 uneffected by the distribution of TE LSAs. A stand-alone TE Link 40 State Database (TE-LSDB), separate from the native OSPF LSDB, is 41 generated for the computation of TE circuit paths. OSPF-xTE is 42 also extendible to non-packet networks such as SONET/TDM and 43 optical networks. A transition path is provided for those using 44 [OPQLSA-TE] and wish to adapt OSPF-xTE. 46 Table of Contents 48 1. Introduction ................................................3 49 2. Principles of traffic engineering ...........................3 50 3. Terminology .................................................4 51 3.1. Native OSPF terms ......................................4 52 3.2. OSPF-xTE terms .........................................5 53 4. Motivations behind the design of OSPF-xTE ...................8 54 4.1. Scalable design ........................................8 55 4.2. Operable in mixed and peer networks ....................9 56 4.3. Efficient in flooding reach ............................9 57 4.4. Ability to reserve TE-exclusive links .................10 58 4.5. Extendible design .....................................10 59 4.6. Unified for packet and non-packet networks ............10 60 4.7. Networks benefiting from the OSPF-xTE design ..........11 61 5. OSPF-xTE solution overview .................................12 62 5.1. OSPF-xTE Solution .....................................12 63 5.2. Assumptions ...........................................13 64 6. Opaque LSAs to OSPF-xTE transition strategy ................14 65 7. OSPF-xTE router adjacency - TE topology discovery ..........14 66 7.1. The OSPF Options field ................................15 67 7.2. The Hello Protocol ....................................15 68 7.3. Flooding and the Synchronization of Databases .........16 69 7.4. The Designated Router .................................16 70 7.5. The Backup Designated Router ..........................16 71 7.6. The graph of adjacencies ..............................17 72 8. TE LSAs for packet network .................................18 73 8.1. TE-Router LSA (0x81) ..................................19 74 8.2. TE-incremental-link-Update LSA (0x8d) .................28 75 8.3. TE-Circuit-paths LSA (0x8C) ...........................30 76 8.4. TE-Summary LSAs .......................................32 77 8.5. TE-AS-external LSAs (0x85) ............................35 78 9. TE LSAs for non-packet network .............................37 79 9.1. TE-Router LSA (0x81) ..................................37 80 9.2. TE-Positional-ring-network LSA (0x82) .................39 81 9.3. TE-Router-Proxy LSA (0x8e) ............................41 82 10. Abstract topology representation with TE support ...........42 83 11. Changes to Data structures in OSPF-xTE routers .............44 84 11.1. Changes to Router data structure .....................44 85 11.2. Two set of Neighbors .................................44 86 11.3. Changes to Interface data structure ..................44 87 12. IANA Considerations ........................................45 88 12.1. TE LSA type values ...................................45 89 12.2. TE TLV tag values ....................................46 90 13. Acknowledgements ...........................................46 91 14. Security Considerations ....................................47 92 15. Normative References .......................................48 93 16. Informative References .....................................48 95 1. Introduction 97 This document defines OSPF-xTE, an experimental traffic 98 engineering (TE) extension to the link-state routing protocol 99 OSPF. The objective of OSPF-xTE is to discover TE network 100 topology and disseminate TE metrics within an autonomous system 101 (AS). A stand-alone TE Link State Database (TE-LSDB), different 102 from the native OSPF LSDB, is created to facilitate computation 103 of TE circuit paths. Devising algorithms to compute TE circuit 104 paths is not an objective of this document. 106 OSPF-xTE is different from the Opaque-LSA-based design outlined 107 in [OPQLSA-TE]. Section 4 describes the motivations behind the 108 design of OSPF-xTE. Section 6 outlines a strategy to transition 109 Opaque-LSA based implementations to adapt OSPF-xTE. 111 Readers interested in TE extensions for the packet networks 112 only may skip section 9.0. 114 2. Principles of traffic engineering 116 The objective of traffic engineering (TE) is to set up circuit 117 path(s) between a pair of nodes or links and to forward traffic 118 of a certain forwarding equivalency class (FEC) through the 119 circuit path. Only the unicast circuit paths are considered 120 in this section. Multicast variations are outside the scope. 122 A traffic engineered circuit path is uni-directional and may 123 be identified by the tuple of (FEC, TE circuit parameters, 124 Origin Node/Link, Destination node/Link). 126 Forwarding Equivalency Class (FEC) is a grouping of traffic 127 that is forwarded in the same manner by a node. A FEC may be 128 classified based on a number of criteria as follows. 129 a) Traffic arriving on a specific interface, 130 b) Traffic arriving at a certain time of day, 131 c) Traffic meeting a certain packet based classification 132 criteria (ex: based on a match of the fields in the IP 133 and transport headers within a packet), 134 d) Traffic in a certain priority class, 135 e) Traffic arriving on a specific set of TDM (STS) circuits 136 on an interface, 137 f) Traffic arriving on a certain wavelength of an interface 139 Discerning traffic based on the FEC criteria is mandatory for 140 Label Edge Routers (LERs). The intermediate Label Switched Routers 141 (LSRs) are transparent to the traffic content. LSRs are merely 142 responsible for keeping the circuit in-tact for the circuit 143 lifetime. This document will not address defining FEC criteria, 144 or the mapping of a FEC to circuit, or the associated signaling to 145 set up circuits. [MPLS-TE] and [GMPLS-TE] address the FEC criteria. 146 [RSVP-TE] and [CR-LDP] address signaling protocols to set up 147 circuits. 149 This document is concerned with the collection of TE metrics for 150 all the TE enforceable nodes and links within an autonomous system. 151 TE metrics for a node may include the following. 152 a) Ability to perform traffic prioritization, 153 b) Ability to provision bandwidth on interfaces, 154 c) Support for Constrained Shortest Path First (CSPF) 155 algorithms, 156 d) Support for certain TE-Circuit switch type, 157 e) Support for a certain type of automatic protection 158 switching 160 TE metrics for a link may include the following. 161 a) Available bandwidth, 162 b) Reliability of the link, 163 c) Color assigned to the link, 164 d) Cost of bandwidth usage on the link, 165 e) Membership to a Shared Risk Link Group (SRLG) 167 A number of CSPF algorithms may be used to dynamically set up 168 TE circuit paths in a TE network. 170 OSPF-xTE mandates the originating and the terminating entities of 171 a TE circuit path to be identifiable by their IP addresses. 173 3. Terminology 175 Definitions of majority of the terms used in the context of the 176 OSPF protocol may be found in [OSPF-V2]. MPLS and traffic 177 engineering terms may be found in [MPLS-ARCH]. RSVP-TE and 178 CR-LDP signaling specific terms may be found in [RSVP-TE] and 179 [CR-LDP] respectively. 181 The following subsections describe the native OSPF terms and 182 the OSPF-xTE terms used within this document. 184 3.1. Native OSPF terms 186 3.1.1. Native node (Non-TE node) 187 A native or non-TE node is an OSPF router capable of IP packet 188 forwarding and does not take part in a TE network. A native 189 OSPF node forwards IP traffic using the shortest-path 190 forwarding algorithm and does not run the OSPF-xTE extensions. 192 3.1.2. Native link (Non-TE link) 194 A native (or non-TE) link is a network attachment to a TE or 195 non-TE node used for IP packet traversal. 197 3.1.3. Native OSPF network (Non-TE network) 199 A native OSPF network refers to an OSPF network that does not 200 support TE. Non-TE network, native-OSPF network and non-TE 201 topology are used synonymously throughout the document. 203 3.1.4. LSP 205 LSP stands for "Label Switched Path". LSP is a TE circuit path 206 in a packet network. The terms LSP and TE circuit path are 207 used synonymously in the context of packet networks. 209 3.1.5. LSA 211 LSA stands for OSPF "Link State Advertisement". 213 3.1.6. LSDB 215 LSDB stands for "LSA Database". LSDB is a representation of the 216 topology of a network. A native LSDB, constituted of native OSPF 217 LSAs, represents the topology of a native IP network. TE-LSDB, on 218 the other hand, is constituted of TE LSAs and is a representation 219 of the TE network topology. 221 3.2. OSPF-xTE terms 223 3.2.1. TE node 225 TE-Node is a node in the traffic engineered (TE) network. A 226 TE-node has a minimum of one TE-link attached to it. Associated 227 with each TE node is a set of supported TE metrics. A TE node 228 may also participate in a native IP network. 230 In a SONET/TDM or photonic cross-connect network, a TE node is 231 not required to be an OSPF-xTE node. An external OSPF-xTE node 232 may act as proxy for the TE nodes that cannot be routers 233 themselves. 235 3.2.2. TE link 237 TE Link is a network attachment point to a TE-node and is 238 intended for traffic engineering use. Associated with each 239 TE link is a set of supported TE metrics. A TE link may also 240 optionally carry native IP traffic. 242 Of the various links attached to a TE-node, only the links that 243 take part in a traffic engineered network are called the TE 244 links. 246 3.2.3. TE circuit path 248 A TE circuit path is a uni-directional data path, defined by a 249 list of TE nodes connected to each other through TE links. A 250 TE circuit path is also often referred merely as a circuit path 251 or a circuit. 253 For the purposes of OSPF-xTE, the originating and terminating 254 entities of a TE circuit path must be identifiable by their 255 IP addresses. As a general rule, all nodes and links party to a 256 Traffic Engineered network should be uniquely identifiable by an 257 IP address. 259 3.2.4. OSPF-xTE node (OSPF-xTE router) 261 An OSPF-xTE node is a TE node that runs the OSPF routing protocol 262 and the OSPF-xTE extensions described in this document. 264 An autonomous system (AS) may be constituted of a combination of 265 native and OSPF-xTE nodes. 267 3.2.5. TE Control network 269 The IP network used by the OSPF-xTE nodes for OSPF-xTE 270 communication is referred as the TE control network or simply 271 the control network. The control network can be independent of 272 the TE data network. 274 3.2.6. TE network (TE topology) 276 A TE network is a network of connected TE-nodes and TE-links 277 for the purpose of setting up one or more TE circuit paths. 278 The terms TE network, TE data network and TE topology are 279 used synonymously throughout the document. 281 3.2.7. Packet-TE network (Packet network) 282 A packet-TE network is a TE network in which the nodes switch 283 MPLS packets. An MPLS packet is defined in [MPLS-TE] as a 284 packet with an MPLS header, followed by data octets. The 285 intermediary node(s) of a circuit path in a packet-TE network 286 perform MPLS label swapping to emulate the circuit. 288 Unless specified otherwise, the term packet network is used 289 throughout the document to refer a packet-TE network. 291 3.2.8. Non-packet-TE network (Non-packet network) 293 A non-packet-TE network is TE-network in which the nodes 294 switch non-packet entities such as an STS time slot, a Lambda 295 wavelength or simply an interface. 297 SONET/TDM and Fiber cross-connect networks are examples of 298 non-packet-TE networks. Circuit emulation in these networks 299 is accomplished by the switch fabric in the intermediary 300 nodes (based on TDM time slot, fiber interface or Lambda). 302 Unless specified otherwise, the term non-packet network is 303 used throughout the document to refer a non-packet-TE 304 network. 306 3.2.9. Mixed network 308 A mixed network is a network that is constituted of 309 packet-TE and non-TE networks combined. Traffic in the 310 network is strictly datagram oriented - IP datagrams or 311 MPLS packets. Routers in a mixed network may be TE or 312 native nodes. 314 OSPF-xTE is usable within a packet network or a mixed 315 network. 317 3.2.10. Peer network 319 A peer network is a network that is constituted of packet-TE 320 and non-packet-TE networks combined. In a peer network, a TE 321 node could potentially support TE links for the packet as 322 well as non-packet data. 324 OSPF-xTE is usable within a packet network or a non-packet 325 network or a peer network, which is a combination of the two. 327 3.2.11. CSPF 329 CSPF stands for "Constrained Shortest Path First". Given a TE 330 LSDB and a set of constraints that must be satisfied to form a 331 circuit path, there may be several CSPF algorithms to obtain a 332 TE circuit path that meets the criteria. 334 3.2.12. TLV 336 A TLV stands for an object in the form of Tag-Length-Value. All 337 TLVs are assumed to be of the following format, unless specified 338 otherwise. The Tag and length are 16 bits wide each. The length 339 includes the 4 octets required for Tag and Length specification. 340 All TLVs described in this document are padded to 32-bit 341 alignment. Any padding required for alignment will not be a part 342 of the length field, however. TLVs are used to describe traffic 343 engineering characteristics of the TE nodes, TE links and TE circuit 344 paths. 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Tag | Length (4 or more) | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Value .... | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | .... | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 3.2.13. Router-TE TLVs (Router TLVs) 358 TLVs used to describe the TE capabilities of a TE-node. 360 3.2.14. Link-TE TLVs (Link TLVs) 362 TLVs used to describe the TE capabilities of a TE-link. 364 4. Motivations behind the design of OSPF-xTE 366 There are several motivations that led to the design of OSPF-xTE. 367 OSPF-xTE is scalable, efficient and usable across a variety of 368 network topologies. These motivations are explained in detail in 369 the following subsections. The last subsection lists real-world 370 network scenarios that benefit from the OSPF-xTE. 372 4.1. Scalable design 374 OSPF-xTE area level abstraction provides the scaling required 375 for the TE topology in a large autonomous system (AS). 377 An OSPF-xTE area border router will advertise summary LSAs for 378 TE and non-TE topologies independent of each other. Readers 379 may refer to section 10 for a topological view of the AS from 380 the perspective of a OSPF-xTE node in an area. 382 4.2. Operable in mixed and peer networks 384 OSPF-xTE regards an AS as constituted of a TE and non-TE networks 385 coexisting within the same bounds. OSPF-xTE dynamically discovers 386 TE topology and the associated TE metrics of the nodes and links 387 within, just as the native OSPF does of a non-TE network. An 388 independent TE-LSDB, representative of the TE topology is 389 generated as a result. A stand-alone TE-LSDB allows for speedy 390 searches through the database. 392 In [OPQLSA-TE], the TE-LSDB is derived from the combination of 393 opaque LSAs and native LSDB. Further, the TE-LSDB thus derived has 394 no knowledge of the TE capabilities of the routers in the network. 396 4.3. Efficient in flooding reach 398 OSPF-xTE is able to identify the TE topology in a mixed network 399 and will limit the flooding of TE LSAs to just the TE-nodes. 400 Non-TE nodes are not bombarded with TE LSAs. 402 In a TE network, a subset of the TE metrics may be prone to rapid 403 change, while others remain largely unchanged. Changes in TE 404 metrics must be communicated at the earliest throughout the 405 network to ensure that the TE-LSDB is up-to-date within the 406 network. As a general rule, a TE network is likely to generate 407 significantly more control traffic than a native network. The 408 excess traffic is almost directly proportional to the rate at 409 which TE circuits are set up and torn down within the TE network. 410 The TE database synchronization should occur much quicker compared 411 to the aggregate circuit set up and tear-down rates. OSPF-xTE 412 defines TE-Incremental-Link-update LSA (section 8.2) to advertise 413 just a subset of the metrics that are prone to rapid changes. 415 The more frequent and wider the flooding frequency, the larger 416 the number of retransmissions and acknowledgements. The same 417 information (needed or not) may reach a router through multiple 418 links. Even if the router did not forward the information past 419 the node, it would still have to send acknowledgements across 420 all the various links on which the LSAs tried to converge. 421 It is undesirable to flood non-TE nodes with TE information. 423 [OPQLSA-TE] uses Opaque LSAs for advertising TE information. 424 Opaque LSAs reach all nodes within the network - TE-nodes and 425 non-TE nodes alike. [OPQLSA-TE] also does not have provision 426 to advertise just the TLVs that changed. A change in any TLV 427 of a link will mandate the entire LSA to be transmitted. 429 4.4. Ability to reserve TE-exclusive links 431 OSPF-xTE draws a clear distinction between TE and non-TE 432 links. A TE link may be configured to permit TE traffic 433 alone, and not permit best-effort IP traffic on the link. 434 This permits TE enforceability on the TE links. 436 When links of a TE-topology do not overlap the links of a 437 native IP network, OSPF-xTE allows for virtual isolation of 438 the two networks. Best-effort IP network and TE network often 439 have different service requirements. Keeping the two networks 440 physically isolated can be expensive. Combining the two 441 networks into a single physically connected network will 442 bring economies of scale, while service enforceability 443 can be maintained individually for each of the TE and non-TE 444 sections of the network. 446 [OPQLSA-TE] does not support the ability to isolate best- 447 effort IP traffic from TE traffic on a link. All links are 448 subject to best-effort IP traffic. An OSPF router could 449 potentially select a TE link to be its least cost link and 450 inundate the link with best-effort IP traffic, thereby 451 rendering the link unusable for TE purposes. 453 4.5. Extendible design 455 OSPF-xTE design is based on the tried and tested OSPF paradigm, 456 and inherits all the benefits of the OSPF, present and future. 457 TE-LSAs are extendible, just as the native OSPF on which 458 OSPF-xTE is founded. 460 [OPQLSA-TE], on the other hand, is constrained by the semantics 461 of the Opaque LSA on which it is founded. The content within an 462 Opaque LSA is restricted to being in the form of TLVs and 463 sub-TLVs, some of which are mandatory. Opaque LSAs are also 464 restrictive when the flooding scope is required to be different 465 from the scope of the opaque LSA itself. 467 4.6. Unified for packet and non-packet networks 469 OSPF-xTE is usable within a packet network or a non-packet 470 network or a combination peer network. 472 Signaling protocols such as RSVP and LDP work the same across 473 packet and non-packet networks. Signaling protocols merely need 474 the TE characteristics of nodes and links so they can signal the 475 nodes to formulate TE circuit paths. In a peer network, the 476 underlying control protocol must be capable of providing a 477 unified LSDB for all TE nodes (nodes with packet-TE links as well 478 as non-packet-TE links) in the network. OSPF-xTE meets this 479 requirement. 481 [OPQLSA-TE] is limited in scope for packet networks and does 482 not have provision to distinguish between node types within 483 a TE network. 485 4.7. Networks benefiting from the OSPF-xTE design 487 Below are examples of some real-world network scenarios that 488 benefit from OSPF-xTE. 490 4.7.1. IP providers transitioning to provide TE services 492 Providers needing to support MPLS based TE in their IP network 493 may choose to transition gradually. Perhaps, add new TE links 494 or convert existing links into TE links within an area first 495 and progressively advance to offer in the entire AS. 497 Not all routers will support TE extensions at the same time 498 during the migration process. Use of TE specific LSAs and their 499 flooding to OSPF-xTE only nodes will allow the vendor to 500 introduce MPLS TE without destabilizing the existing network. 501 The native OSPF-LSDB will remain undisturbed while newer TE 502 links are added to the network. 504 4.7.2. Providers offering Best-effort-IP & TE services 506 Providers choosing to offer both best-effort-IP and TE based 507 packet services simultaneously on the same physically connected 508 network will benefit from the OSPF-xTE design. By maintaining 509 independent LSDBs for each type of service, TE links are not 510 cannibalized in a mixed network. 512 4.7.3. Large TE networks 514 The OSPF-xTE design is advantageous in large TE networks that 515 require the AS to be sub-divided into multiple areas. OSPF-xTE 516 permits inter-area exchange of TE information, which ensures 517 that all nodes in the AS have up-to-date As-wide TE 518 reachability knowledge. This in turn will make TE circuit 519 setup predictable and computationally bounded. 521 4.7.4. Non-packet networks and Peer networks 523 Vendors may also use OSPF-xTE for their non-packet TE networks. 524 OSPF-xTE defines the following functions in support of 525 non-packet TE networks. 526 (a) "Positional-Ring" type network LSA and 527 (b) Router Proxying - allowing a router to advertise on behalf 528 of other nodes (that are not Packet/OSPF capable). 530 5. OSPF-xTE solution overview 532 5.1. OSPF-xTE Solution 534 A new TE flag is introduced within the OSPF options field to 535 to enable discovery of TE topology. Section 8.0 describes the 536 semantics of the TE flag. TE LSAs are designed for use by the 537 OSPF-xTE nodes. Section 9.0 describes the TE LSAs in detail. 538 Changes required of the OSPF data structures to support 539 OSPF-xTE are described in section 11.0. A new TE-neighbors data 540 structure will be used to flood TE LSAs along TE-topology. 542 An OSPF-xTE node will have the native LSDB and the TE-LSDB, 543 A native OSPF node will have just the native LSDB. 544 Consider the following OSPF area constituted of OSPF-xTE and 545 native OSPF routers. Nodes RT1, RT2, RT3 and RT6 are OSPF-xTE 546 routers with TE and non-TE link attachments. Nodes RT4 and RT5 547 are native OSPF routers with no TE links. When the LSA database 548 is synchronized, all nodes will share the same native LSDB 549 OSPF-xTE nodes alone will have the additional TE-LSDB. 551 +---+ 552 | |--------------------------------------+ 553 |RT6|\\ | 554 +---+ \\ | 555 || \\ | 556 || \\ | 557 || \\ | 558 || +---+ | 559 || | |----------------+ | 560 || |RT1|\\ | | 561 || +---+ \\ | | 562 || //| \\ | | 563 || // | \\ | | 564 || // | \\ | | 565 +---+ // | \\ +---+ | 566 |RT2|// | \\|RT3|------+ 567 | |----------|----------------| | 568 +---+ | +---+ 569 | | 570 | | 571 | | 572 +---+ +---+ 573 |RT5|--------------|RT4| 574 +---+ +---+ 575 Legend: 576 -- Native(non-TE) network link 577 | Native(non-TE) network link 578 \\ TE network link 579 || TE network link 581 Figure 6: A (TE + native) OSPF network topology 583 5.2. Assumptions 585 OSPF-xTE is an extension to the native OSPF protocol and does not 586 mandate changes to the existing OSPF. OSPF-xTE design makes the 587 following assumptions. 589 1. An OSPF-xTE node will need to establish router adjacency with 590 at least one other OSPF-xTE node in the area in order for the 591 router's TE-database to be synchronized within the area. 592 Failing this, the OSPF router will not be in the TE 593 calculations of other TE routers in the area. 595 It is the responsibility of the network administrator(s) to 596 ensure connectedness of the TE network. Otherwise, there can 597 be disjoint TE topologies within a network. 599 2. OSPF-xTE nodes must advertise the link state of its TE-links. 600 TE-links are not obligated to support native IP traffic. 601 Hence, an OSPF-xTE node cannot be required to synchronize 602 its link-state database with neighbors on all its links. 603 The only requirement is to have the TE LSDB synchronized 604 across all OSPF-xTE nodes in the area. 606 3. A link in a packet network may be designated as a TE-link or 607 a native-IP link or both. For example, a link may be used for 608 both TE and non-TE traffic, so long as the link is 609 under-subscribed in bandwidth for TE traffic - say, 50% of 610 the link capacity is set aside for TE traffic. 612 4. Non-packet TE sub-topologies must have a minimum of one node 613 running OSPF-xTE protocol. For example, a SONET/SDH TDM ring 614 must have a minimum of one Gateway Network Element(GNE) 615 running OSPF-xTE. The OSPF-xTE node will advertise on behalf 616 of all the TE nodes in the ring. 618 6. Opaque LSAs to OSPF-xTE transition strategy 620 Below is a strategy to transition implementations using opaque 621 LSAs ([OPQLSA-TE]) to adapt OSPF-xTE in a gradual fashion. 623 1. Restrict the use of Opaque-LSAs to within an area. 625 2. Use the TE option flag to construct the TE topologies 626 area-wise. By doing this, the TE topology for the AS will 627 be available at area level abstraction. 629 3. Use TE-Summary LSAs and TE-AS-external-LSAs for inter-area 630 Communication. Make use of the TE-topology within an area to 631 summarize the TE networks in the area and advertise the same 632 to all TE-nodes in the backbone. The TE-ABRs on the backbone 633 area will in-turn advertise these summaries within their 634 connected areas. 636 7. OSPF-xTE router adjacency - TE topology discovery 638 OSPF creates adjacencies between neighboring routers for the purpose 639 of exchanging routing information. In the following subsections, we 640 describe modifications to the OSPF options field and the use of 641 Hello protocol to establish TE capability compliance between 642 neighboring routers in an area. The capability is used as the basis 643 to build TE topology. 645 7.1. The OSPF Options field 647 A new TE flag is introduced within the options field to identify TE 648 extensions to the OSPF. This bit will be used to distinguish routers 649 that support OSPF-xTE. The OSPF options field is present in OSPF 650 Hello packets, Database Description packets, and all link state 651 advertisements. The TE bit, however, is a requirement only for the 652 Hello packets. Use of TE-bit is optional in Database Description 653 packets and LSAs. 655 Below is a description of the TE-Bit. Refer [OSPF-V2], [OSPF-NSSA] 656 and [OPAQUE] for a description of the remaining bits in the 657 options field. 659 -------------------------------------- 660 |TE | O | DC | EA | N/P | MC | E | * | 661 -------------------------------------- 662 The OSPF options field - TE support 664 TE-Bit: This bit is set to indicate support for traffic engineering 665 extensions to the OSPF. The Hello protocol which is used for 666 establishing router adjacency will use the TE-bit to 667 establish OSPF-xTE adjacency. Two routers will not become 668 TE-neighbors unless they agree on the state of the TE-bit. 669 TE-compliant OSPF extensions are advertised only to the 670 TE-compliant routers. All other routers may simply ignore 671 the advertisements. 673 There is however a caveat with the above use of the last remaining 674 reserved bit in the options field. OSPF v2 will have no more 675 reserved bits left for future option extensions. If deemed 676 necessary to leave this bit as is, the OPAQUE-9 LSA (local scope) 677 can be used on each interface to communicate the support for 678 OSPF-xTE. For the reminder of the document, we will assume the 679 above defined TE-bit in options filed is permissible. 681 7.2. The Hello Protocol 683 The Hello Protocol is primarily responsible for dynamically 684 establishing and maintaining neighbor adjacencies. In a TE network, 685 it is not required for all links and neighbors to establish 686 adjacency using this protocol. The Hello protocol will use the 687 TE-bit to establish traffic engineering capability between two 688 OSPF routers. 690 For NBMA and broadcast networks, this protocol is responsible for 691 electing the Designated Router and the Backup Designated Router. 693 Routers supporting the TE option shall be given a higher 694 precedence for becoming a designated router over those that do 695 not support TE. 697 7.3. The Designated Router 699 When a router's non-TE link first becomes functional, it checks to 700 see whether there is currently a Designated Router for the network. 701 If there is one, it accepts that Designated Router, regardless of 702 its Router Priority, so long as the current designated router is 703 TE compliant. Otherwise, the router itself becomes Designated 704 Router if it has the highest Router Priority on the network and is 705 TE compliant. 707 OSPF-xTE must be implemented on the most robust routers, as they 708 become likely candidates to take on the role as designated router. 710 7.4. The Backup Designated Router 712 The Backup Designated Router is also elected by the Hello 713 Protocol. Each Hello Packet has a field that specifies the 714 Backup Designated Router for the network. Once again, TE-compliance 715 must be weighed in conjunction with router priority in electing 716 the backup designated router. 718 7.5. Flooding and the Synchronization of Databases 720 In OSPF, adjacent routers within an area are required to 721 synchronize their databases. However, a more concise requirement 722 is that all routers in an area must converge on the same LSDB. 723 However, as stated in item 2 of section 5.2, a basic assertion 724 by OSPF-xTE is that the links used by the OSPF-xTE control 725 network for flooding must not be required to match the links 726 used by the data network for real-time data forwarding. For 727 instance, it should not be required to run the OSPF-xTE messages 728 over a TE-link that is configured not to permit non-TE traffic. 729 However, the control network must be setup such that a minimum 730 of one path exists between any two OSPF or OSPF-xTE routers 731 within the network for flooding purposes. This revised control 732 network connectivity requirement does not jeopardize 733 convergence of LSDB within an area. 735 In a mixed network, where some of the neighbors are TE 736 compliant and others are not, the designated OSPF-xTE router 737 will exchange different sets of LSAs with its neighbors. 738 TE LSAs are exchanged only with the TE neighbors. Native 739 LSAs are exchanged with all neighbors (TE and non-TE alike). 740 Restricting the scope of TE LSA flooding to just the 741 OSPF-xTE nodes will not effect the native nodes that coexist 742 with the OSPF-xTE nodes. 744 The control traffic for a TE network (i.e., TE LSA 745 advertisement) is likely to be higher than that of a native 746 OSPF network. This is because the TE metrics may vary with each 747 TE circuit setup and the corresponding state change must be 748 advertised at the earliest, not exceeding the MinLSInterval 749 of 5 seconds. To minimize advertising repetitive content, 750 OSPF-xTE defines a new TE-incremental-Link-update LSA 751 (section 8.2) that would advertise just the TLVs that changed 752 for a link. 754 A new OSPFIGP-TE multicast address 224.0.0.24 may be used for 755 the exchange of TE compliant database descriptors during 756 database synchronization. 758 7.6. The graph of adjacencies 760 If two routers have multiple networks in common, they may have 761 multiple adjacencies between them. The adjacency may be one of 762 two types - native OSPF adjacency and TE adjacency. OSPF-xTE 763 routers will form both types of adjacency. 765 Two types of adjacency graphs are possible depending on whether 766 a Designated Router is elected for the network. On physical 767 point-to-point networks, Point-to-Multipoint networks and 768 Virtual links, neighboring routers become adjacent whenever they 769 can communicate directly. The adjacency can be one of 770 (a) TE-compliant or (b) native. In contrast, on broadcast and 771 NBMA networks the designated router and the backup designated 772 router may maintain two sets of adjacency. The remaining routers 773 will form either TE-compliant or native adjacency. In the 774 Broadcast network below, routers RT7 and RT3 are chosen as the 775 designated and backup routers respectively. Routers RT3, RT4 776 and RT7 are TE-compliant. RT5 and RT6 are not. So, RT4 will 777 have TE-compliant adjacency with the designated and backup 778 routers. RT5 and RT6 will only have native adjacency with the 779 designated and backup routers. 781 Network Adjacency 783 +---+ +---+ 784 |RT1|------------|RT2| o--------------------o 785 +---+ N1 +---+ RT1 RT2 787 RT7 788 o::::: 789 +---+ +---+ +---+ /| : 790 |RT7| |RT3| |RT4| / | : 791 +---+ +---+ +---+ / | : 792 | | | / | : 793 +-----------------------+ RT5o RT6o oRT4 794 | | N2 * * : 795 +---+ +---+ * * : 796 |RT5| |RT6| * * : 797 +---+ +---+ ** : 798 o::::: 799 RT3 801 Adjacency Legend: 802 ----- Native adjacency (primary) 803 ***** Native adjacency (Backup) 804 ::::: TE-compliant adjacency (primary) 805 ;;;;; TE-compliant adjacency (Backup) 807 Figure 6: The graph of adjacencies with TE-compliant routers. 809 8. TE LSAs for packet network 811 The OSPFv2 protocol, as of now, has a total of 11 LSA types. 812 LSA types 1 through 5 are defined in [OSPF-v2]. LSA types 6, 7 813 and 8 are defined in [MOSPF], [NSSA] and [BGP-OSPF] respectively. 814 LSA types 9 through 11 are defined in [OPAQUE]. 816 Each LSA type has a unique flooding scope. Opaque LSA types 817 9 through 11 are general purpose LSAs, with flooding 818 scope set to link-local, area-local and AS-wide (except stub 819 areas) respectively. 821 In the following subsections, we define new LSAs for traffic 822 engineering (TE) use. The Values for the new TE LSA types are 823 assigned such that the high bit of the LSA-type octet is set 824 to 1. The new TE LSAs are largely modeled after the existing 825 LSAs for content format and have a unique flooding scope. 827 TE-router LSA is defined to advertise TE characteristics of 828 an OSPF-xTE router and all the TE-links attached to the 829 router. TE-incremental-Link-Update LSA is defined to 830 advertise incremental updates to the metrics of a TE link. 831 Flooding scope for both these LSAs is restricted to an area. 833 TE-Summary network and router LSAs are defined to advertise 834 the reachability of area-specific TE networks and Area Border 835 Routers (along with router TE characteristics) to external 836 areas. Flooding Scope of the TE-Summary LSAs is the TE topology 837 in the entire AS less the non-backbone area for which the 838 the advertising router is an ABR. Just as with native OSPF 839 summary LSAs, the TE-summary LSAs do not reveal the topological 840 details of an area to external areas. 842 TE-AS-external LSA and TE-Circuit-Path LSA are defined to 843 advertise AS external network reachability and pre-engineered 844 TE circuits respectively. While flooding scope for both these 845 LSAs can be the entire AS, flooding scope for the 846 pre-engineered TE circuit LSA may optionally be restricted to 847 just the TE topology within an area. 849 8.1. TE-Router LSA (0x81) 851 The TE-router LSA (0x81) is modeled after the router LSA and has the 852 same flooding scope as the router-LSA. However, the scope is 853 restricted to only the OSPF-xTE nodes within the area. The TE-router 854 LSA describes the TE metrics of the router as well as the TE-links 855 attached to the router. Below is the format of the TE-router LSA. 856 Unless specified explicitly otherwise, the fields carry the same 857 meaning as they do in a router LSA. Only the differences are 858 explained below. Router-TE flags, Router-TE TLVs, Link-TE options, 859 and Link-TE TLVs are each described in the following sub-sections. 861 0 1 2 3 862 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 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | LS age | Options | 0x81 | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Link State ID | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Advertising Router | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | LS sequence number | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | LS checksum | length | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | 0 |V|E|B| 0 | Router-TE flags | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | Router-TE flags (contd.) | Router-TE TLVs | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | .... | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | .... | # of TE links | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Link ID | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | Link Data | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | Type | 0 | Link-TE flags | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Link-TE flags (contd.) | Zero or more Link-TE TLVs | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Link ID | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Link Data | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | ... | 896 Option 897 In TE-capable router nodes, the TE-bit may be set to 1. 899 8.1.1. Router-TE flags - TE capabilities of the router 901 The following flags are used to describe the TE capabilities of an 902 OSPF-xTE router. The remaining bits of the 32-bit word are reserved 903 for future use. 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 |L|L|P| | | | |L|S|C| 907 |S|E|S| | | | |S|I|S| 908 |R|R|C| | | | |P|G|P| 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| 912 Bit LSR 913 When set, the router is considered to have LSR capability. 915 Bit LER 916 When set, the router is considered to have LER capability. 917 All MPLS border routers will be required to have the LER 918 capability. When the E bit is also set, that indicates an 919 AS Boundary router with LER capability. When the B bit is 920 also set, that indicates an area border router with LER 921 capability. 923 Bit PSC 924 Indicates the node is Packet Switch Capable. 926 Bit LSP 927 MPLS Label switch TLV TE-NODE-TLV-MPLS-SWITCHING follows. 928 This is applicable only when the PSC flag is set. 930 Bit SIG 931 MPLS Signaling protocol support TLV 932 TE-NODE-TLV-MPLS-SIG-PROTOCOLS follows. 934 BIT CSPF 935 CSPF algorithm support TLV TE-NODE-TLV-CSPF-ALG follows. 937 8.1.2. Router-TE TLVs 939 The following Router-TE TLVs are defined. 941 8.1.2.4. TE-NODE-TLV-MPLS-SWITCHING 943 MPLS switching TLV is applicable only for packet switched nodes. The 944 TLV specifies the MPLS packet switching capabilities of the TE 945 node. 947 0 1 2 3 948 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 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Tag = 0x8001 | Length = 6 | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | Label depth | QOS | | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 'Label depth' is the depth of label stack the node is capable of 956 processing on its ingress interfaces. An octet is used to represent 957 label depth. A default value of 1 is assumed when the TLV is not 958 listed. Label depth is relevant when an LER has to pop off multiple 959 labels off the MPLS stack. 961 'QOS' is a single octet field that may be assigned '1' or '0'. Nodes 962 supporting QOS are able to interpret the EXP bits in the MPLS header 963 to prioritize multiple classes of traffic through the same LSP. 965 8.1.2.2. TE-NODE-TLV-MPLS-SIG-PROTOCOLS 967 MPLS signaling protocols TLV lists all the signaling protocol 968 supported by the node. An octet is used to list each signaling 969 protocol supported. 971 0 1 2 3 972 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 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | Tag = 0x8002 | Length = 5, 6 or 7 | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | Protocol-1 | ... | .... | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 RSVP-TE protocol is represented as 1, CR-LDP as 2 and LDP as 3. 980 These are the only permitted signaling protocols at this time. 982 8.1.2.3. TE-NODE-TLV-CSPF-ALGORITHMS 984 The CSPF algorithms TLV lists all the CSPF algorithm codes 985 supported. Support for CSPF algorithms makes the node eligible to 986 compute complete or partial circuit paths. Support for CSPF 987 algorithms can also be beneficial in knowing whether or not a node 988 is capable of expanding loose routes (in an MPLS signaling request) 989 into a detailed circuit path. 991 Two octets are used to list each CSPF algorithm code. The algorithm 992 codes may be vendor defined and unique within an Autonomous System. 993 If the node supports 'n' CSPF algorithms, the Length would be 994 (4 + 4 * ((n+1)/2)) octets. 996 0 1 2 3 997 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 998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 999 | Tag = 0x8003 | Length = 4(1 + (n+1)/2) | 1000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 | CSPF-1 | .... | 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | CSPF-n | | 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 8.1.2.4. TE-NODE-TLV-NULL 1008 When a TE-Router or a TE-link has multiple TLVs to describe the 1009 metrics, the NULL TLV is used to terminate the TLV list. 1011 0 1 2 3 1012 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 1013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1014 | Tag = 0x8888 | Length = 4 | 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 8.1.3. Link-TE flags - TE capabilities of a link 1019 The following flags are used to describe the TE capabilities of a 1020 link. The remaining bits of the 32-bit word are reserved for 1021 future use. 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 |T|N|P| | | |D| |S|L|B|C| 1025 |E|T|K| | | |B| |R|U|W|O| 1026 | |E|T| | | |S| |L|G| |L| 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| 1030 TE - Indicates whether TE is permitted on the link. A link 1031 can be denied for TE use by setting the flag to 0. 1033 NTE - Indicates whether non-TE traffic is permitted on the 1034 TE link. This flag is relevant only when the TE 1035 flag is set. 1037 PKT - Indicates whether or not the link is capable of IP 1038 packet processing. 1040 DBS - Indicates whether or not Database synchronization 1041 is permitted on this link. 1043 SRLG Bit - Shared Risk Link Group TLV TE-LINK-TLV-SRLG follows. 1045 LUG bit - Link usage cost metric TLV TE-LINK-TLV-LUG follows. 1047 BW bit - One or more Link bandwidth TLVs follow 1049 COL bit - Link Color TLV TE-LINK-TLV-COLOR follows. 1051 8.1.4. Link-TE TLVs 1053 8.1.4.1. TE-LINK-TLV-SRLG 1055 The SRLG describes the list of Shared Risk Link Groups (SRLG) the 1056 link belongs to. Two octets are used to list each SRLG. If the link 1057 belongs to 'n' SRLGs, the Length would be (4 + 4 * ((n+1)/2)) octets. 1059 0 1 2 3 1060 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 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | Tag = 0x0001 | Length = 4(1 + (n+1)/2) | 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 | SRLG-1 | .... | 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1066 | SRLG-n | | 1067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 8.1.4.2. TE-LINK-TLV-BANDWIDTH-MAX 1071 The bandwidth TLV specifies maximum bandwidth of the link as follows. 1073 0 1 2 3 1074 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 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 | Tag = 0x0002 | Length = 8 | 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 | Maximum Bandwidth | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 Bandwidth is expressed in units of 32 bytes/sec (256 bits/sec). 1082 A 32-bit field for bandwidth would permit specification not exceeding 1083 1 tera-bits/sec. 1085 'Maximum bandwidth' is be the maximum link capacity expressed in 1086 bandwidth units. Portions or all of this bandwidth may be used for 1087 TE use. 1089 8.1.4.3. TE-LINK-TLV-BANDWIDTH-MAX-FOR-TE 1091 The bandwidth TLV specifies maximum bandwidth available for TE use 1092 as follows. 1094 0 1 2 3 1095 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 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Tag = 0x0003 | Length = 8 | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Maximum Bandwidth available for TE use | 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 Bandwidth is expressed in units of 32 bytes/sec (256 bits/sec). 1103 A 32-bit field for bandwidth would permit specification not exceeding 1104 1 tera-bits/sec. 1106 'Maximum bandwidth available for TE use' is the total reservable 1107 bandwidth on the link for use by all the TE circuit paths traversing 1108 the link. The link is oversubscribed when this field is more than 1109 the 'Maximum Bandwidth'. When the field is less than the 1110 'Maximum Bandwidth', the remaining bandwidth on the link may 1111 be used for non-TE traffic in a mixed network. 1113 8.1.4.4. TE-LINK-TLV-BANDWIDTH-TE 1115 The bandwidth TLV specifies the bandwidth reserved for TE as follows. 1117 0 1 2 3 1118 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | Tag = 0x0004 | Length = 8 | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | TE Bandwidth subscribed | 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1125 Bandwidth is expressed in units of 32 bytes/sec (256 bits/sec). 1126 A 32-bit field for bandwidth would permit specification not exceeding 1127 1 tera-bits/sec. 1129 'TE Bandwidth subscribed' is the bandwidth that is currently 1130 subscribed from of the link. 'TE Bandwidth subscribed' must be less 1131 than the 'Maximum bandwidth available for TE use'. New TE circuit 1132 paths are able to claim no more than the difference between the 1133 two bandwidths for reservation. 1135 8.1.4.5. TE-LINK-TLV-LUG 1137 The link usage cost TLV specifies Bandwidth unit usage cost, 1138 TE circuit set-up cost, and any time constraints for setup and 1139 teardown of TE circuits on the link. 1141 0 1 2 3 1142 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 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 | Tag = 0x0005 | Length = 28 | 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | Bandwidth unit usage cost | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 | TE circuit set-up cost | 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | TE circuit set-up time constraint | 1151 | | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | TE circuit tear-down time constraint | 1154 | | 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1157 Circuit Setup time constraint 1158 This 64-bit number specifies the time at or after which a 1159 TE-circuit path may be set up on the link. The set-up time 1160 constraint is specified as the number of seconds from the start 1161 of January 1, 1970 UTC. A reserved value of 0 implies no circuit 1162 setup time constraint. 1164 Circuit Teardown time constraint 1165 This 64-bit number specifies the time at or before which all 1166 TE-circuit paths using the link must be torn down. The teardown 1167 time constraint is specified as the number of seconds from the 1168 start of January 1 1970 UTC. A reserved value of 0 implies no 1169 circuit teardown time constraint. 1171 8.1.4.6. TE-LINK-TLV-COLOR 1173 The color TLV is similar to the SRLG TLV, in that an Autonomous 1174 System may choose to issue colors to a TE-link meeting certain 1175 criteria. The color TLV can be used to specify one or more colors 1176 assigned to the link as follows. Two octets are used to list each 1177 color. If the link belongs to 'n' number of colors, the Length 1178 would be (4 + 4 * ((n+1)/2)) octets. 1180 0 1 2 3 1181 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 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | Tag = 0x0006 | Length = 4(1 + (n+1)/2) | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | Color-1 | .... | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | Color-n | | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 8.1.4.7. TE-LINK-TLV-NULL 1192 When a TE-link has multiple TLVs to describe its metrics, the NULL 1193 TLV is used to terminate the TLV list. The TE-LINK-TLV-NULL is same 1194 as the TE-NODE-TLV-NULL described in section 8.1.2.4 1196 8.2. TE-incremental-link-Update LSA (0x8d) 1198 A significant difference between a native OSPF network and a TE 1199 network is that the latter may be subject to frequent real-time 1200 circuit pinning and is likely to undergo TE-state updates. Some 1201 links might undergo changes more frequently than others. Flooding 1202 the network with TE-router LSAs at the aggregated speed of all 1203 link metric changes is simply not desirable. A smaller in size, 1204 TE-incremental-link-update LSA is designed to advertise only the 1205 incremental link updates. 1207 TE-incremental-link-Update LSA will be advertised as frequently 1208 as the link state is changed (not exceeding once every 1209 MinLSInterval seconds). The TE-link sequence is largely the 1210 advertisement of a sub-portion of router LSA. The sequence number on 1211 this will be incremented with the TE-router LSA's sequence as the 1212 basis. When an updated TE-router LSA is advertised within 30 minutes 1213 of the previous advertisement, the updated TE-router LSA will assume 1214 a sequence no. that is larger than the most frequently updated of 1215 its links. 1217 Below is the format of the TE-incremental-link-update LSA. 1219 0 1 2 3 1220 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 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | LS age | Options | 0x8d | 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 | Link State ID (same as Link ID) | 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | Advertising Router | 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | LS sequence number | 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 | LS checksum | length | 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | Link Data | 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 | Type | 0 | Link-TE options | 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | Link-TE options | Zero or more Link-TE TLVs | 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 | # TOS | metric | 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | ... | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | TOS | 0 | TOS metric | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 Link State ID 1246 This would be exactly the same as would have been specified as 1247 as Link ID for a link within the router-LSA. 1249 Link Data 1250 This specifies the router ID the link belongs to. In majority of 1251 cases, this would be same as the advertising router. This choice 1252 for Link Data is primarily to facilitate proxy advertisement for 1253 incremental link updates. 1255 Say, a router-proxy-LSA was used to advertise the TE-router-LSA 1256 of a SONET/TDM node. Say, the proxy router is now required to 1257 advertise incremental-link-update for the same SONET/TDM node. 1258 Specifying the actual router-ID the link in the 1259 incremental-link-update-LSA belongs to helps receiving nodes in 1260 finding the exact match for the LSA in their database. 1262 The tuple of (LS Type, LSA ID, Advertising router) uniquely identify 1263 the LSA and replace LSAs of the same tuple with an older sequence 1264 number. However, there is an exception to this rule in the context 1265 of TE-link-update LSA. TE-Link update LSA will initially assume the 1266 sequence number of the TE-router LSA it belongs to. Further, when a 1267 new TE-router LSA update with a larger sequence number is advertised, 1268 the newer sequence number is assumed by al the link LSAs. 1270 8.3. TE-Circuit-path LSA (0x8C) 1272 TE-Circuit-path LSA may be used to advertise the availability of 1273 pre-engineered TE circuit path(s) originating from any router 1274 in the network. The flooding scope may be Area wide or AS wide. 1276 0 1 2 3 1277 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 1278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 | LS age | Options | 0x84 | 1280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1281 | Link State ID | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | Advertising Router | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | LS sequence number | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | LS checksum | length | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 | 0 |G|E|B|D|S|T|CktType| Circuit Duration (Optional) | 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 | Circuit Duration cont... | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | Circuit Duration cont.. | Circuit Setup time (Optional) | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | Circuit Setup time cont... | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 | Circuit Setup time cont.. |Circuit Teardown time(Optional)| 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 | Circuit Teardown time cont... | 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 | Circuit Teardown time cont.. | No. of TE circuit paths | 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1303 | Circuit-TE ID | 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 | Circuit-TE Data | 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 | Type | 0 | Circuit-TE flags | 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 | Circuit-TE flags (contd.) | Zero or more Circuit-TE TLVs | 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 | Circuit-TE ID | 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | Circuit-TE Data | 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 | ... | 1317 Link State ID 1318 The ID of the far-end router or the far-end Link-ID to which the 1319 TE circuit path(s) is being advertised. 1321 TE-circuit-path(s) flags 1323 Bit G - When set, the flooding scope is set to be AS wide. 1324 Otherwise, the flooding scope is set to be area wide. 1326 Bit E - When set, the advertised Link-State ID is an AS boundary 1327 router (E is for external). The advertising router and 1328 the Link State ID belong to the same area. 1330 Bit B - When set, the advertised Link state ID is an Area border 1331 router (B is for Border) 1333 Bit D - When set, this indicates that the duration of circuit 1334 path validity follows. 1336 Bit S - When set, this indicates that Setup-time of the circuit 1337 path follows. 1339 Bit T - When set, this indicates that teardown-time of the 1340 circuit path follows. 1342 CktType 1343 This 4-bit field specifies the Circuit type of the Forward 1344 Equivalency Class (FC). 1346 0x01 - Origin is Router, Destination is Router. 1347 0x02 - Origin is Link, Destination is Link. 1348 0x04 - Origin is Router, Destination is Link. 1349 0x08 - Origin is Link, Destination is Router. 1351 Circuit Duration (Optional) 1352 This 64-bit number specifies the seconds from the time of the 1353 LSA advertisement for which the pre-engineered circuit path 1354 will be valid. This field is specified only when the D-bit is 1355 set in the TE-circuit-path flags. 1357 Circuit Setup time (Optional) 1358 This 64-bit number specifies the time at which the TE-circuit 1359 path may be set up. This field is specified only when the 1360 S-bit is set in the TE-circuit-path flags. The set-up time is 1361 specified as the number of seconds from the start of January 1362 1 1970 UTC. 1364 Circuit Teardown time (Optional) 1365 This 64-bit number specifies the time at which the TE-circuit 1366 path may be torn down. This field is specified only when the 1367 T-bit is set in the TE-circuit-path flags. The teardown time 1368 is specified as the number of seconds from the start of 1369 January 1 1970 UTC. 1371 No. of TE Circuit paths 1372 This specifies the number of pre-engineered TE circuit paths 1373 between the advertising router and the router specified in the 1374 link state ID. 1376 Circuit-TE ID 1377 This is the ID of the far-end router for a given TE-circuit 1378 path segment. 1380 Circuit-TE Data 1381 This is the virtual link identifier on the near-end router for 1382 a given TE-circuit path segment. This can be a private 1383 interface or handle the near-end router uses to identify the 1384 virtual link. 1386 The sequence of (circuit-TE ID, Circuit-TE Data) list the 1387 end-point nodes and links in the LSA as a series. 1389 Circuit-TE flags 1390 This lists the Zero or more TE-link TLVs that all member 1391 elements of the LSP meet. 1393 8.4. TE-Summary LSAs 1395 TE-Summary-LSAs are the Type 0x83 and 0x84 LSAs. These LSAs are 1396 originated by area border routers. TE-Summary-network-LSA (0x83) 1397 describes the reachability of TE networks in a non-backbone 1398 area, advertised by the Area Border Router. Type 0x84 1399 summary-LSA describes the reachability of Area Border Routers 1400 and AS border routers and their TE capabilities. 1402 One of the benefits of having multiple areas within an AS is 1403 that frequent TE advertisements within the area do not impact 1404 outside the area. Only the TE abstractions befitting the 1405 external areas are advertised. 1407 8.4.1. TE-Summary Network LSA (0x83) 1409 TE-summary network LSA may be used to advertise reachability of 1410 TE-networks accessible to areas external to the originating 1411 area. The content and the flooding scope of a TE-Summary LSA 1412 is different from that of a native summary LSA. 1414 The scope of flooding for a TE-summary network is AS wide, with 1415 the exception of the originating area and the stub areas. The 1416 area border router for each non-backbone area is responsible 1417 for advertising the reachability of backbone networks into the 1418 area. 1420 Unlike a native-summary network LSA, TE-summary network LSA does 1421 not advertise summary costs to reach networks within an area. 1422 This is because TE parameters are not necessarily additive or 1423 comparative. The parameters can be varied in their expression. 1424 For example, a TE-summary network LSA will not summarize a 1425 network whose links do not fall under an SRLG (Shared-Risk Link 1426 Group). This way, the TE-summary LSA merely advertises the 1427 reachability of TE networks within an area. The specific circuit 1428 paths can be computed by the BDRs. Pre-engineered circuit paths 1429 are advertised using TE-Circuit-path LSA (refer section 8.3). 1431 0 1 2 3 1432 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 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 | LS age | Options | 0x83 | 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 | Link State ID (IP Network Number) | 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | Advertising Router (Area Border Router) | 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 | LS sequence number | 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 | LS checksum | length | 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 | Network Mask | 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | Area-ID | 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 8.4.2. TE-Summary router LSA (0x84) 1451 TE-summary router LSA may be used to advertise the availability of 1452 Area Border Routers (ABRs) and AS Border Routers (ASBRs) that are 1453 TE capable. The TE-summary router LSAs are originated by the Area 1454 Border Routers. The scope of flooding for the TE-summary router LSA 1455 is the non-backbone area the advertising ABR belongs to. 1457 0 1 2 3 1458 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 1459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1460 | LS age | Options | 0x84 | 1461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1462 | Link State ID | 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 | Advertising Router (ABR) | 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 | LS sequence number | 1467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 | LS checksum | length | 1469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1470 | 0 |E|B| 0 | No. of Areas | 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 | Area-ID | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 | ... | 1475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1476 | Router-TE flags | 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1478 | Router-TE TLVs | 1479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1480 | .... | 1481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 Link State ID 1484 The ID of the Area border router or the AS border router whose 1485 TE capability is being advertised. 1487 Advertising Router 1488 The ABR that advertises its TE capabilities (and the OSPF areas 1489 it belongs to) or the TE capabilities of an ASBR within one of 1490 the areas the ABR is a border router of. 1492 No. of Areas 1493 Specifies the number of OSPF areas the link state ID belongs to. 1495 Area-ID 1496 Specifies the OSPF area(s) the link state ID belongs to. When 1497 the link state ID is same as the advertising router ID, the 1498 Area-ID lists all the areas the ABR belongs to. In the case 1499 the link state ID is an ASBR, the Area-ID simply lists the 1500 area the ASBR belongs to. The advertising router is assumed to 1501 be the ABR from the same area the ASBR is located in. 1503 Summary-router-TE flags 1505 Bit E - When set, the advertised Link-State ID is an AS boundary 1506 router (E is for external). The advertising router and 1507 the Link State ID belong to the same area. 1509 Bit B - When set, the advertised Link state ID is an Area 1510 border router (B is for Border) 1512 Router-TE flags, 1513 Router-TE TLVs (TE capabilities of the link-state-ID router) 1515 TE Flags and TE TLVs are as applicable to the ABR/ASBR 1516 specified in the link state ID. The semantics is same as 1517 specified in the Router-TE LSA. 1519 8.5. TE-AS-external LSAs (0x85) 1521 TE-AS-external-LSAs are the Type 0x85 LSAs. This is modeled after 1522 AS-external LSA format and flooding scope. TE-AS-external LSAs are 1523 originated by AS boundary routers with TE extensions, and describe 1524 the TE networks and pre-engineered circuit paths external to the 1525 AS. As with AS-external LSA, the flooding scope of the 1526 TE-AS-external LSA is AS wide, with the exception of stub areas. 1528 0 1 2 3 1529 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 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 | LS age | Options | 0x85 | 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 | Link State ID | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 | Advertising Router | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | LS sequence number | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 | LS checksum | length | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | Network Mask | 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 | Forwarding address | 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1545 | External Route Tag | 1546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1547 | # of Virtual TE links | 0 | 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 | Link-TE flags | 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 | Link-TE TLVs | 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 | ... | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 | TE-Forwarding address | 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | External Route TE Tag | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | ... | 1561 Network Mask 1562 The IP address mask for the advertised TE destination. For 1563 example, this can be used to specify access to a specific 1564 TE-node or TE-link with an mask of 0xffffffff. This can also 1565 be used to specify access to an aggregated set of destinations 1566 using a different mask. ex: 0xff000000. 1568 Link-TE flags, 1569 Link-TE TLVs 1570 The TE attributes of this route. These fields are optional and 1571 are provided only when one or more pre-engineered circuits can 1572 be specified with the advertisement. Without these fields, 1573 the LSA will simply state TE reachability info. 1575 Forwarding address 1576 Data traffic for the advertised destination will be forwarded to 1577 this address. If the Forwarding address is set to 0.0.0.0, data 1578 traffic will be forwarded instead to the LSA's originator (i.e., 1579 the responsible AS boundary router). 1581 External Route Tag 1582 A 32-bit field attached to each external route. This is not 1583 used by the OSPF protocol itself. It may be used to communicate 1584 information between AS boundary routers; the precise nature of 1585 such information is outside the scope of this specification. 1587 9. TE LSAs for non-packet network 1589 A non-packet network would use the TE LSAs described in the 1590 previous section for a packet network with some variations. 1591 These variations are described in the following subsections. 1593 Two new LSAs, TE-Positional-ring-network LSA and 1594 TE-Router-Proxy LSA are defined for explicit use in 1595 non-packet TE networks. 1597 Readers may refer to [SONET-SDH] for a detailed description of 1598 the terms used in the context of SONET/SDH TDM networks, 1600 9.1. TE-Router LSA (0x81) 1602 The following fields are used to describe each router link (i.e., 1603 interface). Each router link is typed (see the below Type field). 1604 The Type field indicates the kind of link being described. 1606 Type 1607 A new link type "Positional-Ring Type" (value 5) is defined. 1608 This is essentially a connection to a TDM-Ring. TDM ring network 1609 is different from LAN/NBMA transit network in that nodes on the 1610 TDM ring do not necessarily have a terminating path between 1611 themselves. Secondly, the order of links is important in 1612 determining the circuit path. Third, the protection switching 1613 and the number of fibers from a node going into a ring are 1614 determined by the ring characteristics. I.e., 2-fiber vs 1615 4-fiber ring and UPSR vs BLSR protected ring. 1617 Type Description 1618 __________________________________________________ 1619 1 Point-to-point connection to another router 1620 2 Connection to a transit network 1621 3 Connection to a stub network 1622 4 Virtual link 1623 5 Positional-Ring Type. 1625 Link ID 1626 Identifies the object that this router link connects to. 1627 Value depends on the link's Type. For a positional-ring type, 1628 the Link ID shall be IP Network/Subnet number just as the case 1629 with a broadcast transit network. The following table 1630 summarizes the updated Link ID values. 1632 Type Link ID 1633 ______________________________________ 1634 1 Neighboring router's Router ID 1635 2 IP address of Designated Router 1636 3 IP network/subnet number 1637 4 Neighboring router's Router ID 1638 5 IP network/subnet number 1640 Link Data 1641 This depends on the link's Type field. For type-5 links, this 1642 specifies the router interface's IP address. 1644 9.1.1. Router-TE flags - TE capabilities of the router 1646 Flags specific to non-packet TE-nodes are described below. 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 |L|L|P|T|L|F| |S|S|S|C| 1650 |S|E|S|D|S|S| |T|E|I|S| 1651 |R|R|C|M|C|C| |A|L|G|P| 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1653 |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| 1655 Bit TDM 1656 Indicates the node is TDM circuit switch capable. 1658 Bit LSC 1659 Indicates the node is Lambda switch Capable. 1661 Bit FSC 1662 Indicates the node is Fiber (can also be a non-fiber link 1663 type) switch capable. 1665 9.1.2. Link-TE options - TE capabilities of a TE-link 1667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1668 |T|N|P|T|L|F|D| |S|L|B|C| 1669 |E|T|K|D|S|S|B| |R|U|W|O| 1670 | |E|T|M|C|C|S| |L|G|A|L| 1671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1672 |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| 1673 TDM, LSC, FSC bits 1674 - Same as defined for router TE options. 1676 9.2. TE-Positional-ring-network LSA (0x82) 1678 Network LSA is adequate for packet TE networks. A new 1679 TE-Positional-Ring-network-LSA is defined to represent type-5 1680 link networks, found in non-packet networks such as SONET/SDH 1681 TDM rings. A type-5 ring is a collection of network elements 1682 (NEs) forming a closed loop. Each NE is connected to two 1683 adjacent NEs via a duplex connection to provide redundancy 1684 in the ring. The sequence in which the NEs are placed on the 1685 Ring is pertinent. The NE that provides the OSPF-xTE 1686 functionality is termed the Gateway Network Element (GNE). 1687 The GNE selection criteria is outside the scope of this 1688 document. The GNE is also termed the Designated Router for 1689 the ring. 1691 The TE-Positional-ring-network LSA (0x82) is modeled after the 1692 network LSA and has the same flooding scope as the network-LSA 1693 amongst the OSPF-xTE nodes within the area. Below is the format 1694 of the TE-Positional-ring-network LSA. Unless specified 1695 explicitly otherwise, the fields carry the same meaning as they 1696 do in a network LSA. Only the differences are explained below. 1697 TE-Positional-ring-network-LSA is originated for each 1698 Positional-Ring type network in the area. The tuple of (Link 1699 State ID, Network Mask) below uniquely represents a ring. The 1700 TE option must be set in the Options flag while propagating 1701 the LSA. 1703 0 1 2 3 1704 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 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 | LS age | Options | 0x82 | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 | Link State ID | 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 | Advertising Router | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 | LS sequence number | 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 | LS checksum | length | 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 | Network Mask | 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 | Ring Type | Capacity Unit | Reserved | 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 | Ring capacity | 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 | Network Element Node Id | 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1724 | ... | 1726 Link State ID 1727 This is the IP interface address of the network's Gateway 1728 Network Element, which is also the designated router. 1730 Advertising Router 1731 Router ID of the network's Designated Router. 1733 Ring type 1735 There are 8 types of SONET/SDH rings defined as follows. 1737 1 - A Unidirectional Line Switched 2-fiber ring (2-fiber ULSR) 1738 2 - A bi-directional Line switched 2-fiber ring (2-fiber BLSR) 1739 3 - A Unidirectional Path Switched 2-fiber ring (2-fiber UPSR) 1740 4 - A bi-directional Path switched 2-fiber ring (2-fiber BPSR) 1741 5 - A Unidirectional Line Switched 4-fiber ring (4-fiber ULSR) 1742 6 - A bi-directional Line switched 4-fiber ring (4-fiber BLSR) 1743 7 - A Unidirectional Path Switched 4-fiber ring (4-fiber UPSR) 1744 8 - A bi-directional Path switched 4-fiber ring (4-fiber BPSR) 1746 Capacity unit 1747 Two units are defined at this time as follows. 1748 1 - Synchronous Transport Signal (STS), which is the basic 1749 signal rate for SONET signals. The rate of an STS signal 1750 is 51.84 Mbps 1751 2 - Synchronous Transport Multiplexer(STM), which is the 1752 basic signal rate for SDH signals. The rate of an STM 1753 signal is 155.52 Mbps 1755 Ring capacity 1756 Ring capacity expressed in number of Capacity units. 1758 Network Element Node Id 1760 The Router ID of each of the routers in the positional-ring 1761 network. The list must start with the designated router as 1762 the first element. The Network Elements (NEs) must be listed 1763 in strict clockwise order as they appear on the ring, 1764 starting with the Gateway Network Element (GNE). The number 1765 of NEs in the ring can be deduced from the LSA header's 1766 length field. 1768 9.3. TE-Router-Proxy LSA (0x8e) 1770 This is a variation to the TE-router LSA in that the TE-router LSA 1771 is not advertised by the network element, but rather by a trusted 1772 TE-router Proxy. This is typically the scenario in a non-packet 1773 TE network, where some of the nodes do not have OSPF functionality 1774 and count on a helper node to do the advertisement for them. One 1775 such example would be the SONET/SDH ADM nodes in a TDM ring. The 1776 nodes may principally depend upon the GNE (Gateway Network 1777 Element) to do the advertisement for them. TE-router-Proxy LSA 1778 shall not be used to advertise Area Border Routers and/or AS border 1779 Routers. 1781 0 1 2 3 1782 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 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 | LS age | Options | 0x8e | 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 | Link State ID (Router ID of the TE Network Element) | 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 | Advertising Router | 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 | LS sequence number | 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 | LS checksum | length | 1793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1794 | 0 | Router-TE flags | 1795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 | Router-TE flags (contd.) | Router-TE TLVs | 1797 +---------------------------------------------------------------+ 1798 | .... | 1799 +---------------------------------------------------------------+ 1800 | .... | # of TE links | 1801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1802 | Link ID | 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1804 | Link Data | 1805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1806 | Type | 0 | Link-TE options | 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1808 | Link-TE flags | Zero or more Link-TE TLVs | 1809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1810 | Link ID | 1811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1812 | Link Data | 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 | ... | 1816 10. Abstract topology representation with TE support 1818 Below, we consider a TE network composed of three OSPF areas - 1819 Area-1, Area-2 and Area-3, attached together through the backbone 1820 area. Area-1 an has a single area border router, ABR-A1 and no 1821 ASBRs. Area-2 has an area border router ABR-A2 and an AS border 1822 router ASBR-S1. Area-3 has two area border routers ABR-A2 and 1823 ABR-A3 and an AS border router ASBR-S2. The following network 1824 also assumes a pre-engineered TE circuit path between ABR-A1 1825 and ABR-A2; between ABR-A1 and ABR-A3; between ABR-A2 and 1826 ASBR-S1; and between ABR-A3 and ASBR-S2. 1828 The following figure is an inter-area topology abstraction 1829 from the perspective of routers in Area-1. The abstraction 1830 illustrates reachability of TE networks and nodes within area 1831 to the external areas in the same AS and to the external ASes. 1832 The abstraction also illustrates pre-engineered TE circuit 1833 paths advertised by ABRs and ASBRs. 1835 +-------+ 1836 |Area-1 | 1837 +-------+ 1838 +-------------+ | 1839 |Reachable TE | +--------+ 1840 |networks in |-------| ABR-A1 | 1841 |backbone area| +--------+ 1842 +-------------+ | | | 1843 +--------------+ | +-----------------+ 1844 | | | 1845 +-----------------+ | +-----------------+ 1846 |Pre-engineered TE| +----------+ |Pre-engineered TE| 1847 |circuit path(s) | | Backbone | |circuit path(s) | 1848 |to ABR-A2 | | Area | |to ABR-A3 | 1849 +-----------------+ +----------+ +-----------------+ 1850 | | | | 1851 +----------+ | +--------------+ | 1852 +-----------+ | | | | +-----------+ 1853 |Reachable | +--------+ +--------+ |Reachable | 1854 |TE networks|------| ABR-A2 | | ABR-A3 |--|TE networks| 1855 |in Area A2 | +--------+ +--------+ |in Area A3 | 1856 +-----------+ | | | | | | +-----------+ 1857 +-------------+ | | +-----------------+ | +----------+ 1858 | | +-----------+ | | | 1859 +-----------+ +--------------+ | | | +--------------+ 1860 |Reachable | |Pre-engineered| | | | |Pre-engineered| 1861 |TE networks| |TE Ckt path(s)| +------+ +------+ |TE Ckt path(s)| 1862 |in Area A3 | |to ASBR-S1 | |Area-2| |Area-3| |to ASBR-S2 | 1863 +-----------+ +--------------+ +------+ +------+ +--------------+ 1864 | | | | 1865 | +--------+ | +-----------+ 1866 +-------------+ | | | | 1867 |AS external | +---------+ +---------+ 1868 |TE-network |----| ASBR-S1 | | ASBR-S2 | 1869 |reachability | +---------+ +---------+ 1870 |from ASBR-S1 | | | | 1871 +-------------+ +---+ +-------+ +-----------+ 1872 | | | 1873 +-----------------+ +-------------+ +-----------------+ 1874 |Pre-engineered TE| |AS External | |Pre-engineered TE| 1875 |circuit path(s) | |TE-Network | |circuit path(s) | 1876 |reachable from | |reachability | |reachable from | 1877 |ASBR-S1 | |from ASBR-S2 | |ASBR-S2 | 1878 +-----------------+ +-------------+ +-----------------+ 1880 Figure 9: Inter-Area Abstraction as viewed by Area-1 TE-routers 1882 11. Changes to Data structures in OSPF-xTE nodes 1884 11.1. Changes to Router data structure 1886 An OSPF-xTE router must be able to include the router-TE 1887 capabilities (as specified in section 8.1) in the router data 1888 structure. OSPF-xTE routers providing proxy service to other TE 1889 routers must also track the router and associated interface data 1890 structures for all the TE client nodes for which the proxy 1891 service is being provided. Presumably, the interaction between 1892 the Proxy server and the proxy clients is out-of-band. 1894 11.2. Two sets of Neighbors 1896 Two sets of neighbor data structures are required. TE-neighbors 1897 set is used to advertise TE LSAs. Only the TE-nodes will be 1898 members of the TE-neighbor set. Native neighbors set will be used 1899 to advertise native LSAs. All neighboring nodes supporting 1900 non-TE links are part of the Native neighbors set. 1902 11.3. Changes to Interface data structure 1904 The following new fields are introduced to the interface data 1905 structure. 1907 TePermitted 1908 If the value of the flag is TRUE, the interface may be 1909 advertised as a TE-enabled interface. 1911 NonTePermitted 1912 If the value of the flag is TRUE, the interface permits non-TE 1913 traffic on the interface. Specifically, this is applicable to 1914 packet networks, where data links may permit both TE and IP 1915 packets. For FSC and LSC TE networks, this flag is set to 1916 FALSE. 1918 FloodingPermitted 1919 If the value of the flag is TRUE, the interface may be used 1920 for OSPF and OSPF-xTE packet exchange to synchronize the 1921 LSDB across all adjacent neighbors. This is TRUE by default 1922 to all NonTePermitted interfaces that are enabled for OSPF. 1923 However, it is possible to set this to FALSE 1924 for some of the interfaces. 1926 TE-TLVs 1927 Each interface may define any number of TLVS that describe 1928 the link characteristics. 1930 The following existing fields in Interface data structure will take 1931 on additional values to support TE extensions. 1933 Type 1934 The OSPF interface type can also be of type "Positional-RING". 1935 The Positional-ring type is different from other types (such 1936 as broadcast and NBMA) in that the exact location of the nodes 1937 on the ring is relevant, even though they are all on the same 1938 ring. SONET ADM ring is a good example of this. Complete ring 1939 positional-ring description may be provided by the GNE on a 1940 ring as a TE-network LSA for the ring. 1942 List of Neighbors 1943 The list may be statically defined for an interface without 1944 requiring the use of Hello protocol. 1946 12. IANA Considerations 1948 This document proposes that TE LSA types and TE TLVs be 1949 maintained by the IANA. The document also proposes an OSPFIGP-TE 1950 multicast address be assigned by the IANA for the exchange of 1951 TE database descriptors. 1953 OSPFIGP-TE multicast address is suggested a value of 224.0.0.24 1954 so as not to conflict with the recognized multicast address 1955 definitions, as defined in 1956 http://www.iana.org/assignments/multicast-addresses 1958 The following sub-section explains the criteria to be used by the 1959 IANA to assign TE LSA types and TE TLVs. 1961 12.1. TE LSA type values 1963 LSA type is an 8-bit field required by each LSA. TE LSA types 1964 will have the high bit set to 1. TE LSAs can range from 0x80 1965 through 0xFF. The following values are defined in sections 1966 8.0 and 9.0. The remaining values are available for assignment 1967 by the IANA with IETF Consensus [Ref 11]. 1969 TE LSA Type Value 1970 _________________________________________ 1971 TE-Router LSA 0x81 1972 TE-Positional-ring-network LSA 0x82 1973 TE-Summary Network LSA 0x83 1974 TE-Summary router LSA 0x84 1975 TE-AS-external LSAs 0x85 1976 TE-Circuit-paths LSA 0x8C 1977 TE-incremental-link-Update LSA 0x8d 1978 TE-Router-Proxy LSA 0x8e 1980 12.2. TE TLV tag values 1982 TLV type is a 16-bit field required by each TE TLV. TLV type 1983 shall be unique across the router and link TLVs. A TLV type 1984 can range from 0x0001 through 0xFFFF. TLV type 0 is reserved 1985 and unassigned. The following TLV types are defined in sections 1986 8.0 and 9.0. The remaining values are available for assignment 1987 by the IANA with IETF Consensus [Ref 11]. 1989 TE TLV Tag Reference Value 1990 Section 1991 _________________________________________________________ 1993 TE-LINK-TLV-SRLG Section 8.1.4.1 0x0001 1994 TE-LINK-TLV-BANDWIDTH-MAX Section 8.1.4.2 0x0002 1995 TE-LINK-TLV-BANDWIDTH-MAX-FOR-TE Section 8.1.4.3 0x0003 1996 TE-LINK-TLV-BANDWIDTH-TE Section 8.1.4.4 0x0004 1997 TE-LINK-TLV-LUG Section 8.1.4.5 0x0005 1998 TE-LINK-TLV-COLOR Section 8.1.4.6 0x0006 1999 TE-LINK-TLV-NULL Section 8.1.4.7 0x8888 2000 TE-NODE-TLV-MPLS-SWITCHING Section 8.1.2.1 0x8001 2001 TE-NODE-TLV-MPLS-SIG-PROTOCOLS Section 8.1.2.2 0x8002 2002 TE-NODE-TLV-CSPF-ALG Section 8.1.2.3 0x8003 2003 TE-NODE-TLV-NULL Section 8.1.2.4 0x8888 2005 13. Acknowledgements 2007 The authors wish to specially thank Chitti Babu and his team 2008 for verifying several portions of the specification in a 2009 mixed packet network. The authors also wish to thank Vishwas 2010 Manral, Riyad Hartani and Tricci So for their valuable 2011 comments and feedback on the draft. Lastly, the authors wish 2012 to thank Alex Zinin and Mike Shand for their draft (now 2013 defunct) titled "Flooding optimizations in link state routing 2014 protocols". The draft provided inspiration to the authors to 2015 be sensitive to the high flooding rate, likely in TE networks. 2017 14. Security Considerations 2019 Security considerations for the base OSPF protocol are covered 2020 in [OSPF-v2] and [SEC-OSPF]. This memo does not create any new 2021 security issues for the OSPF protocol. Security measures 2022 applied to the native OSPF (refer [SEC-OSPF]) are directly 2023 applicable to the TE LSAs described in the document. Discussed 2024 below are the security considerations in processing TE LSAs. 2026 Secure communication between OSPF-xTE nodes has a number of 2027 components. Authorization, authentication, integrity and 2028 confidentiality. Authorization refers to whether a particular 2029 OSPF-xTE node is authorized to receive or propagate the TE LSAs 2030 to its neighbors. Failing the authorization process might 2031 indicate a resource theft attempt or unauthorized resource 2032 advertisement. In either case, the OSPF-xTE nodes should take 2033 proper measures to audit/log such attempts so as to alert the 2034 administrator to take necessary action. OSPF-xTE nodes may 2035 refuse to communicate with the neighboring nodes that fail to 2036 prompt the required credentials. 2038 Authentication refers to confirming the identity of an originator 2039 for the datagrams received from the originator. Lack of strong 2040 credentials for authentication of OSPF-xTE LSAs can seriously 2041 jeopardize the TE service rendered by the network. A consequence 2042 of not authenticating a neighbor would be that an attacker could 2043 spoof the identity of a "legitimate" OSPF-xTE node and manipulate 2044 the state, and the TE database including the topology and 2045 metrics collected. This could potentially cause 2046 denial-of-service on the TE network. Another consequence of not 2047 authenticating is that an attacker could pose as OSPF-xTE 2048 neighbor and respond in a manner that would divert TE data to the 2049 attacker. 2051 Integrity is required to ensure that an OSPF-xTE message has not 2052 been accidentally or maliciously altered or destroyed. The result 2053 of a lack of data integrity enforcement in an untrusted environment 2054 could be that an imposter will alter the messages sent by a 2055 legitimate adjacent neighbor and bring the OSPF-xTE on a node and 2056 the whole network to a halt or cause a denial of service for the 2057 TE circuit paths effected by the alteration. 2059 Confidentiality of MIDCOM messages ensure that the TE LSAs are 2060 accessible only to the authorized entities. When OSPF-xTE is 2061 deployed in an untrusted environment, lack of confidentiality will 2062 allow an intruder to perform traffic flow analysis and snoop the 2063 TE control network to monitor the traffic metrics and the rate at 2064 which circuit paths are being setup and torn-down. The intruder 2065 could cannibalize a lesser secure OSPF-xTE node and destroy or 2066 compromise the state and TE-LDSB on the node. Needless to say, the 2067 least secure OSPF-xTE will become the Achilles heel and make the 2068 TE network vulnerable to security attacks. 2070 15. Normative References 2072 [IETF-STD] Bradner, S., "Key words for use in RFCs to indicate 2073 Requirement Levels", BCP 14, RFC 2119, March 1997. 2075 [RFC 1700] J. Reynolds and J. Postel, "Assigned Numbers", 2076 RFC 1700 2078 [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for 2079 writing an IANA Considerations Section in RFCs", 2080 BCP 26, RFC 2434, October 1998. 2082 [MPLS-TE] Awduche, D., et al, "Requirements for Traffic 2083 Engineering Over MPLS," RFC 2702, September 1999. 2085 [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 2087 [SEC-OSPF] Murphy, S., Badger, M., and B. Wellington, "OSPF with 2088 Digital Signatures", RFC 2154, June 1997 2090 16. Informative References 2092 [RSVP-TE] Awduche, D., L. Berger, D. Gan, T. Li, V. Srinivasan, 2093 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2094 Tunnels", RFC3209, IETF, December 2001 2096 [CR-LDP] Jamoussi, B. et al, "Constraint-Based LSP Setup 2097 using LDP", draft-ietf-mpls-cr-ldp-06.txt, 2098 Work in Progress. 2100 [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, 2101 March 1994. 2103 [NSSA] Coltun, R., V. Fuller and P. Murphy, "The OSPF NSSA 2104 Option", draft-ietf-ospf-nssa-update-11.txt, Work in 2105 Progress. 2107 [OPAQUE] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, 2108 July 1998. 2110 [OPQLSA-TE] Katz, D., D. Yeung and K. Kompella, "Traffic 2111 Engineering Extensions to OSPF", work in progress, 2112 2114 [SONET-SDH] Ming-CHwan Chow, "Understanding SONET/SDH Standards 2115 and Applications" - A paperback or bound book, 2116 Published by Andan publisher. 2118 [GMPLS-TE] P.A. Smith et. al, "Generalized MPLS - Signaling 2119 Functional Description", work in progress, 2120 draft-ietf-mpls-generalized-signaling-09.txt 2122 Authors' Addresses 2124 Pyda Srisuresh 2125 Consultant 2126 849 Erie circle 2127 Milpitas, CA 95035 2128 U.S.A. 2129 EMail: srisuresh@yahoo.com 2131 Paul Joseph 2132 Force10 Networks 2133 1440 McCarthy Boulevard 2134 Milpitas, CA 95035 2135 U.S.A. 2136 EMail: pjoseph@Force10Networks.com