idnits 2.17.1 draft-srisuresh-ospf-te-04.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 153 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 1357 has weird spacing: '...bes the reach...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 8, 2002) is 7803 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 664, but not defined == Missing Reference: 'MPLS-ARCH' is mentioned on line 195, but not defined == Missing Reference: 'OSPF-NSSA' is mentioned on line 664, but not defined == Missing Reference: 'BGP-OSPF' is mentioned on line 815, but not defined == Missing Reference: 'Ref 11' is mentioned on line 1882, but not defined == Unused Reference: 'RFC 1700' is defined on line 1961, but no explicit reference was found in the text == Unused Reference: 'RFC 2434' is defined on line 1964, 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') -- Possible downref: Non-RFC (?) normative reference: ref. 'FLOOD-OPT' -- Obsolete informational reference (is this intentional?): RFC 2370 (ref. 'OPAQUE') (Obsoleted by RFC 5250) Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Srisuresh 3 INTERNET-DRAFT Kuokoa Networks 4 Expires as of June 8, 2003 P. Joseph 5 Force10 Networks 6 December 8, 2002 8 OSPF-TE: 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-TE, an experimental traffic engineering 35 (TE) extension to the link-state routing protocol OSPF. New TE 36 LSAs are designed 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-TE is 42 also extendible to non-packet networks such as SONET/TDM and 43 optical networks. A transition path is provided for those 44 currently using [OPQLSA-TE] and wish to adapt OSPF-TE. 46 Table of Contents 48 1. Introduction ................................................3 49 2. Principles of traffic engineering ...........................3 50 3. Terminology .................................................5 51 3.1. TE node ................................................5 52 3.2. TE link ................................................5 53 3.3. TE circuit path ........................................5 54 3.4. OSPF-TE node ...........................................6 55 3.5. TE control network .....................................6 56 3.6. TE network (TE topology) ...............................6 57 3.7. Packet-TE network ......................................6 58 3.8. Non-packet-TE network ..................................6 59 3.9. Native (non-TE) node ...................................7 60 3.10. Native (non-TE) link ..................................7 61 3.11. Non-TE network (Non-TE topology) ......................7 62 3.12. Peer network (combination network) ....................7 63 3.13. LSP ...................................................7 64 3.14. LSA ...................................................7 65 3.14. LSDB ..................................................7 66 3.15. CSPF ..................................................7 67 3.16. TLV ...................................................8 68 3.17. Router-TE TLVs ........................................8 69 3.18. Link-TE TLVs ..........................................8 70 4. Motivations behind the design of OSPF-TE ....................8 71 4.1. Scalable design ........................................9 72 4.2. Coexistent design ......................................9 73 4.3. Efficient in flooding reach ............................9 74 4.4. Ability to reserve TE-exclusive links .................10 75 4.5. Extendible design .....................................10 76 4.6. Unified for packet and non-packet networks ............11 77 4.7. Networks benefiting from the OSPF-TE design ...........11 78 5. OSPF-TE solution overview ..................................12 79 5.1. OSPF-TE Solution ......................................12 80 5.2. Assumptions ...........................................13 81 6. Opaque LSAs to OSPF-TE transition strategy .................14 82 7. OSPF-TE router adjacency - TE topology discovery ...........14 83 7.1. The OSPF Options field ................................15 84 7.2. The Hello Protocol ....................................15 85 7.3. Flooding and the Synchronization of Databases .........16 86 7.4. The Designated Router .................................16 87 7.5. The Backup Designated Router ..........................16 88 7.6. The graph of adjacencies ..............................17 89 8. TE LSAs - Packet network ...................................18 90 8.1. TE-Router LSA (0x81) ..................................19 91 8.2. TE-incremental-link-Update LSA (0x8d) .................26 92 8.3. TE-Circuit-paths LSA (0x8C) ...........................27 93 8.4. TE-Summary LSAs .......................................30 94 8.5. TE-AS-external LSAs (0x85) ............................33 95 9. TE LSAs - Non-packet network ...............................34 96 9.1. TE-Router LSA (0x81) ..................................34 97 9.2. Changes to Network LSA ................................36 98 9.3. TE-Router-Proxy LSA (0x8e) ............................36 99 10. Abstract topology representation with TE support ...........37 100 11. Changes to Data structures in OSPF-TE routers ..............40 101 11.1. Changes to Router data structure .....................40 102 11.2. Two set of Neighbors .................................40 103 11.3. Changes to Interface data structure ..................40 104 12. IANA Considerations ........................................41 105 12.1. TE LSA type values ...................................41 106 12.2. TE TLV tag values ....................................42 107 13. Acknowledgements ...........................................42 108 14. Security Considerations ....................................42 109 15. Normative References .......................................44 110 16. Informative References .....................................44 112 1. Introduction 114 This document defines OSPF-TE, an experimental traffic engineering 115 (TE) extension to the link-state routing protocol OSPF. The 116 objective of OSPF-TE is to discover TE network topology and 117 disseminate TE metrics within an autonomous system(AS). A 118 stand-alone TE Link State Database (TE-LSDB), different from 119 the native OSPF LSDB, is created to facilitate computation of TE 120 circuit paths. Algorithms to compute TE circuit paths is however 121 not the objective of this document. 123 OSPF-TE is different from the Opaque-LSA-based design outlined 124 in [OPQLSA-TE]. Section 4 describes the motivations behind the 125 design of OSPF-TE. Section 6 outlines a strategy to transition 126 Opaque-LSA based implementations to adapt OSPF-TE. 128 Those interested in TE extensions for the packet networks only 129 may skip section 9.0. 131 2. Principles of traffic engineering 133 The objective of traffic engineering is to set up circuit 134 path(s) between a pair of nodes or links and to forward traffic 135 of a certain forwarding equivalency class through the circuit 136 path. Only the unicast circuit paths are considered here. 137 Multicast variations are out of scope for this document. 139 A traffic engineered circuit path may be identified by the 140 tuple of (Forwarding Equivalency Class, TE parameters for the 141 circuit, Origin Node/Link, Destination node/Link). 143 Forwarding Equivalency Class (FEC) is a grouping of traffic 144 that is forwarded in the same manner by a node. A FEC may be 145 classified based on a number of criteria as follows. 146 a) Traffic arriving on a specific interface, 147 b) Traffic arriving at a certain time of day, 148 c) Traffic meeting a certain classification criteria 149 (ex: based on a match of the fields in the IP and 150 transport headers), 151 d) Traffic in a certain priority class, 152 e) Traffic arriving on a specific set of TDM (STS) circuits 153 on an interface, 154 f) Traffic arriving on a certain wavelength of an interface 156 Discerning traffic based on the FEC criteria is mandatory for 157 Label Edge Routers (LERs). The intermediate Label Switched Routers 158 (LSRs) are transparent to the traffic content. LSRs are merely 159 responsible for keeping the circuit in-tact for the circuit 160 lifetime. This document will not address defining FEC criteria, 161 or the mapping of a FEC to circuit, or the associated signaling to 162 set up circuits. [MPLS-TE] and [GMPLS-TE] address the FEC criteria. 163 [RSVP-TE] and [CR-LDP] address signaling protocols to set up 164 circuits. 166 This document is concerned with the collection of TE metrics for 167 all the TE enforceable nodes and links within an autonomous system. 168 TE metrics for a node may include the following. 169 a) Ability to perform traffic prioritization, 170 b) Ability to provision bandwidth on interfaces, 171 c) Support for Constrained Shortest Path First (CSPF) 172 algorithms, 173 d) Support for certain TE-Circuit switch type, 174 e) Support for a certain type of automatic protection 175 switching 177 TE metrics for a link may include the following. 178 a) Available bandwidth, 179 b) Reliability of the link, 180 c) Color assigned to the link, 181 d) Cost of bandwidth usage on the link, 182 e) Membership to a Shared Risk Link Group (SRLG) 184 A number of CSPF algorithms may be used to dynamically set up 185 TE circuit paths in a TE network. 187 As for origin node/link and destination node/link, the originating 188 and the terminating entities of a TE circuit path are identifiable 189 by their IP addresses. 191 3. Terminology 193 Definitions of terms used in the context of the OSPF protocol may be 194 found in [OSPF-V2]. MPLS and traffic engineering terms may be found 195 in [MPLS-ARCH]. RSVP-TE and CR-LDP signaling specific terms may be 196 found in [RSVP-TE] and [CR-LDP] respectively. 198 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT", 199 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 200 this document are to be interpreted as described in [IETF-STD]. 202 Below are definitions for the terms used within this document. 204 3.1. TE node 206 TE-Node is a node in the traffic engineered (TE) network. A 207 TE-node has a minimum of one TE-link attached to it. Associated 208 with each TE node is a set of supported TE metrics. A TE node 209 may also participate in a native IP network. 211 In a SONET/TDM or photonic cross-connect network, a TE node is 212 not required to be an OSPF-TE router. An external OSPF-TE router 213 may act as proxy for the TE nodes that cannot be routers 214 themselves. 216 3.2. TE link 218 TE Link is a network attachment point to a TE-node and is 219 intended for traffic engineering use. Associated with each 220 TE link is a set of supported TE metrics. A TE link may also 221 optionally carry native IP traffic. 223 Of the various links attached to a TE-node, only the links that 224 take part in a traffic engineered network are called the TE 225 links. 227 3.3. TE circuit path 229 A TE circuit path is a uni-directional data path, defined by a 230 list of TE nodes connected to each other through TE links. A 231 TE circuit path is also often referred merely as a circuit path 232 or a circuit. 234 For the purposes of OSPF-TE, the originating and terminating 235 entities of a TE circuit path must be identifiable by their 236 IP addresses. As a general rule, all nodes and links party to a 237 Traffic Engineered network should be uniquely identifiable by an 238 IP address. 240 3.4. OSPF-TE node 242 An OSPF-TE node is a TE node that runs the OSPF routing protocol 243 and the OSPF-TE extensions described in this document. 245 An autonomous system (AS) may be constituted of a combination of 246 native and OSPF-TE nodes. 248 3.5. TE Control network 250 The IP network used by the OSPF-TE nodes for OSPF-TE 251 communication is referred as the TE control network or simply 252 the control network. The control network can be independent of 253 the TE data network. 255 3.6. TE network (TE topology) 257 A TE network is a network of connected TE-nodes and TE-links 258 for the purpose of setting up one or more TE circuit paths. 259 The terms TE network, TE data network and TE topology are 260 used synonymously throughout the document. 262 3.7. Packet-TE network 264 A packet-TE network is a TE network in which the nodes switch 265 MPLS packets. An MPLS packet is defined in [MPLS-TE] as a 266 packet with an MPLS header, followed by data octets. The 267 intermediary node(s) of a circuit path in a packet-TE network 268 perform MPLS label swapping to emulate the circuit. 270 Unless specified otherwise, the term packet network is used 271 throughout the document to refer a packet-TE network. 273 3.8. Non-packet-TE network 275 A non-packet-TE network is TE-network in which the nodes 276 switch non-packet entities such as an STS time slot, a Lambda 277 wavelength or simply an interface. 279 SONET/TDM and Fiber cross-connect networks are examples of 280 non-packet-TE networks. Circuit emulation in these networks 281 is accomplished by the switch fabric in the intermediary 282 nodes (based on TDM time slot, fiber interface or Lambda). 284 Unless specified otherwise, the term non-packet network is 285 used throughout the document to refer a non-packet-TE 286 network. 288 3.9. Native (non-TE) node 290 A native or non-TE node is an OSPF router capable of IP packet 291 forwarding and does not take part in a TE network. A native 292 OSPF node forwards IP traffic using the shortest-path 293 forwarding algorithm and does not run the OSPF-TE extensions. 295 3.10. Native (non-TE) link 297 A native (or non-TE) link is a network attachment to a TE or 298 non-TE node used for IP packet traversal. 300 3.11. non-TE network (Non-TE topology) 302 A non-TE network refers to an OSPF network that does not 303 support TE. Non-TE network, native-OSPF network and non-TE 304 topology are used synonymously throughout the document. 306 3.12. Peer network (combination network) 308 A peer network is a network that is constituted of packet 309 and non-packet networks combined. In a peer network, a TE 310 node could potentially support TE links for the packet as 311 well as non-packet data. 313 OSPF-TE is usable within a packet network or a non-packet 314 network or a peer network, which is a combination of the two. 316 3.13. LSP 318 LSP stands for "Label Switched Path". LSP is a TE circuit path 319 in a packet network. The terms LSP and TE circuit path are 320 used synonymously in the context of packet networks. 322 3.14. LSA 324 LSA stands for OSPF "Link State Advertisement". 326 3.15. LSDB 328 LSDB stands for "LSA Database". LSDB is a representation of the 329 topology of a network. A native LSDB, constituted of native OSPF 330 LSAs, represents the topology of a native IP network. TE-LSDB, on 331 the other hand, is constituted of TE LSAs and is a representation 332 of the TE network topology. 334 3.16. CSPF 336 CSPF stands for "Constrained Shortest Path First". Given a TE 337 LSDB and a set of constraints that must be satisfied to form a 338 circuit path, there may be several CSPF algorithms to obtain a 339 TE circuit path that meets the criteria. 341 3.17. TLV 343 A TLV stands for an object in the form of Tag-Length-Value. All 344 TLVs are assumed to be of the following format, unless specified 345 otherwise. The Tag and length are 16 bits wide each. The length 346 includes the 4 octets required for Tag and Length specification. 347 All TLVs described in this document are padded to 32-bit 348 alignment. Any padding required for alignment will not be a part 349 of the length field, however. TLVs are used to describe traffic 350 engineering characteristics of the TE nodes, TE links and TE circuit 351 paths. 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Tag | Length (4 or more) | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Value .... | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | .... | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 3.18. Router-TE TLVs 365 TLVs used to describe the TE capabilities of a TE-node. 367 3.19. Link-TE TLVs 369 TLVs used to describe the TE capabilities of a TE-link. 371 4. Motivations behind the design of OSPF-TE 373 There are several motivations that lead to the design of OSPF-TE. 374 OSPF-TE is scalable, coexistent and efficient in flooding reach. 375 The motivations are explained in detail in the following 376 subsections. Also listed in the last subsection are network 377 scenarios that benefit from the OSPF-TE design. 379 4.1. Scalable design 381 Area level abstraction provides the scaling necessary for a large 382 autonomous system (AS). OSPF-TE allows for independent area 383 abstractions for the TE and native topologies. The TE and native 384 area border routers will advertise different summary LSAs to TE 385 and non-TE routers. Readers may refer section 10 for a 386 topological view of the AS from an OSPF-TE node in an area. 388 4.2. Coexistent design 390 OSPF-TE regards an AS as constituted of a TE and non-TE networks 391 coexisting within the same bounds. OSPF-TE dynamically discovers 392 TE topology and the associated TE metrics of the nodes and links 393 within, just as the native OSPF does in a non-TE network. An 394 independent TE-LSDB, representative of the TE topology is 395 generated as a result. A stand-alone TE-LSDB allows for speedy 396 searches through the database. 398 In [OPQLSA-TE], the TE-LSDB is derived from the combination of 399 opaque LSAs and native LSDB. The TE-LSDB derived has no 400 knowledge of the TE capabilities of the routers in the network. 402 4.3. Efficient in flooding reach 404 OSPF-TE is capable of identifying the boundaries of a TE topology 405 and limits the flooding of TE LSAs to only the TE-nodes. Non-TE 406 nodes are not bombarded with TE LSAs. This is a useful 407 characteristic for networks supporting native and TE traffic in 408 the same connected network. 410 A subset of the TE metrics may be prone to rapid change, while 411 others remain largely unchanged. Changes in TE metrics must be 412 communicated at the earliest throughout the network to ensure 413 that the TE-LSDB is up-to-date within the network. As a general 414 rule, a TE network is likely to generate significantly more 415 control traffic than a native OSPF network. The excess traffic 416 is almost directly proportional to the rate at which TE circuits 417 are set up and torn down within the TE network. The TE database 418 synchronization should occur much quicker compared to the 419 aggregate circuit set up and tear-down rates. 420 TE-Incremental-Link-update LSA (section 8.2) permits advertising 421 a subset of the link metrics. 423 The more frequent and wider the flooding frequency, the larger 424 the number of retransmissions and acknowledgements. The same 425 information (needed or not) may reach a router through multiple 426 links. Even if the router did not forward the information past 427 the node, it would still have to send acknowledgements across 428 all the various links on which the LSAs tried to converge. 429 It is undesirable to flood non-TE nodes with TE information. 431 [OPQLSA-TE] uses Opaque LSAs for advertising TE information. 432 Opaque LSAs reach all nodes within the network - TE-nodes and 433 non-TE nodes alike. [OPQLSA-TE] also does not have provision 434 to advertise just the TLVs that changed. A change in any TLV 435 of a TE-link will mandate the entire LSA to be transmitted. 437 4.4. Ability to reserve TE-exclusive links 439 OSPF-TE is designed to draw distinction between TE-links and 440 non-TE links. A TE link, configured to support TE traffic 441 alone, will not permit best-effort IP traffic on the link. 442 This permits TE enforceability on the TE links. 444 When links of a TE-topology do not overlap the links of a 445 native IP network, OSPF-TE allows for virtual isolation of 446 the two networks. Best-effort IP transit network and 447 constraint based TE network often have different service 448 requirements. Keeping the two networks physically isolated 449 will enable SLA enforceability, but can be expensive. Combining 450 the two networks into a single physically connected network 451 will bring economies of scale, if the service enforceability 452 can be retained. 454 [OPQLSA-TE] does not support the ability to isolate best- 455 effort IP traffic from TE traffic on a link. All links are 456 subject to best-effort IP traffic. An OSPF router could 457 potentially select a TE link to be its least cost link and 458 inundate the link with best-effort IP traffic, thereby 459 rendering the link unusable for TE purposes. 461 4.5. Extendible design 463 OSPF-TE design is based on the tried and tested OSPF paradigm, 464 and inherits all the benefits of the OSPF, present and future. 465 TE-LSAs are extendible, just as the native OSPF on which OSPF-TE 466 is founded. 468 [OPQLSA-TE], on the other hand, is constrained by the semantics 469 of the Opaque LSA on which it is founded. The content within an 470 Opaque LSA is restricted to being in the form of TLVs and 471 sub-TLVs, some of which are mandatory and some of which are 472 positionally dependent in the TLV sequence for proper 473 interpretation. Opaque LSAs are also restrictive when the flooding 474 scope for the content is required to be different from the scope 475 of the opaque LSA itself. 477 4.6. Unified for packet and non-packet networks 479 OSPF-TE is usable within a packet network or a non-packet 480 network or a combination peer network. 482 Signaling protocols such as RSVP and LDP work the same across 483 packet and non-packet networks. Signaling protocols merely need 484 the TE characteristics of nodes and links so they can signal the 485 nodes to formulate TE circuit paths. In a peer network, the 486 underlying control protocol must be capable of providing a 487 unified LSDB for all TE nodes (nodes with packet-TE links as well 488 as non-packet-TE links) in the network. OSPF-TE meets this 489 requirement. 491 [OPQLSA-TE] is limited in scope for packet networks. An 492 independent [OPQLSA-GMPLS] is required to support GMPLS links in 493 a non-packet network. Neither of the Opaque LSA based extensions 494 have provision to distinguish between node types. 496 4.7. Networks benefiting from the OSPF-TE design 498 Many real-world networks are better served by the new-TE-LSAs 499 scheme. Here are a few examples. 501 4.7.1. IP providers transitioning to provide TE services 503 Providers needing to support MPLS based TE in their IP network 504 may choose to transition gradually. Perhaps, add new TE links 505 or convert existing links into TE links within an area first 506 and progressively advance to offer in the entire AS. 508 Not all routers will support TE extensions at the same time 509 during the migration process. Use of TE specific LSAs and their 510 flooding to OSPF-TE only nodes will allow the vendor to 511 introduce MPLS TE without destabilizing the existing network. 512 The native OSPF-LSDB will remain undisturbed while newer TE 513 links are added to the network. 515 4.7.2. Providers offering Best-effort-IP & TE services 517 Providers choosing to offer both best-effort-IP and TE based 518 packet services simultaneously on the same physically connected 519 network will benefit from the OSPF-TE design. By maintaining 520 independent LSDBs for each type of service, TE links are not 521 cannibalized. 523 4.7.3. Large TE networks 525 The OSPF-TE design is advantageous in large TE networks that 526 require the AS to be sub-divided into multiple areas. 528 4.7.4. Non-packet networks and Peer networks 530 OSPF-TE is also the right choice for vendors opting for a 531 stable, well-founded protocol for their non-IP TE networks. 532 OSPF-TE is uniquely qualified to support the following network 533 attachments in non-Packet TE networks. 534 (a) "Positional-Ring" type network LSA and 535 (b) Router Proxying - allowing a router to advertise on behalf 536 of other nodes (that are not Packet/OSPF capable). 538 5. OSPF-TE solution overview 540 5.1. OSPF-TE Solution 542 A new TE flag is introduced within the OSPF options field to 543 to enable discovery of TE topology. Section 8.0 describes the 544 semantics of the TE flag. TE LSAs are designed for use by the 545 OSPF-TE nodes. Section 9.0 describes the TE LSAs in detail. 546 Changes required of the OSPF data structures to support 547 OSPF-TE are described in section 11.0. A new TE-neighbors data 548 structure will be used to flood TE LSAs along TE-topology. 550 An OSPF-TE node will have the native LSDB and the TE-LSDB, 551 A native OSPF node will have just the native LSDB. 552 Consider the following OSPF area constituted of OSPF-TE and 553 native OSPF routers. Nodes RT1, RT2, RT3 and RT6 are OSPF-TE 554 routers with TE and non-TE link attachments. Nodes RT4 and RT5 555 are native OSPF routers with no TE links. When the LSA database 556 is synchronized, all nodes will share the same native LSDB 557 OSPF-TE nodes alone will have the additional TE-LSDB. 559 +---+ 560 | |--------------------------------------+ 561 |RT6|\\ | 562 +---+ \\ | 563 || \\ | 564 || \\ | 565 || \\ | 566 || +---+ | 567 || | |----------------+ | 568 || |RT1|\\ | | 569 || +---+ \\ | | 570 || //| \\ | | 571 || // | \\ | | 572 || // | \\ | | 573 +---+ // | \\ +---+ | 574 |RT2|// | \\|RT3|------+ 575 | |----------|----------------| | 576 +---+ | +---+ 577 | | 578 | | 579 | | 580 +---+ +---+ 581 |RT5|--------------|RT4| 582 +---+ +---+ 583 Legend: 584 -- Native(non-TE) network link 585 | Native(non-TE) network link 586 \\ TE network link 587 || TE network link 589 Figure 6: A (TE + native) OSPF network topology 591 5.2. Assumptions 593 OSPF-TE is an extension to the native OSPF protocol and does not 594 mandate changes to the existing OSPF. OSPF-TE design makes the 595 following assumptions. 597 1. An OSPF-TE node will need to establish router adjacency with 598 at least one other OSPF-TE node in the area in order for the 599 router's TE-database to be synchronized within the area. 600 Failing this, the OSPF router will not be in the TE 601 calculations of other TE routers in the area. 603 It is the responsibility of the network administrator(s) to 604 ensure connectedness of the TE network. Otherwise, there can 605 be disjoint TE topologies within a network. 607 2. OSPF-TE nodes must advertise the link state of its TE-links. 608 TE-links are not obligated to support native IP traffic. 609 Hence, an OSPF-TE node cannot be required to synchronize 610 its link-state database with neighbors on all its links. 611 The only requirement is to have the TE LSDB synchronized 612 across all OSPF-TE nodes in the area. Refer [FLOOD-OPT] for 613 flooding optimizations. 615 3. A link in a packet network may be designated as a TE-link or 616 a native-IP link or both. For example, a link may be used for 617 both TE and non-TE traffic, so long as the link is 618 under-subscribed in bandwidth for TE traffic - say, 50% of 619 the link capacity is set aside for TE traffic. 621 4. Non-packet TE sub-topologies MUST have a minimum of one node 622 running OSPF-TE protocol. For example, a SONET/SDH TDM ring 623 must have a minimum of one Gateway Network Element(GNE) 624 running OSPF-TE. The OSPF-TE node will advertise on behalf 625 of all the in the ring. 627 6. Opaque LSAs to OSPF-TE transition strategy 629 Below is a strategy to transition implementations using opaque 630 LSAs to adapt the OSPF-TE scheme in a gradual fashion. 632 1. Restrict the use of Opaque-LSAs to within an area. 634 2. Fold in the TE option flag to construct the TE topologies 635 area-wise. By doing this, the TE topology for the AS will 636 be available at area level abstraction. 638 3. Use TE-Summary LSAs and TE-AS-external-LSAs for inter-area 639 Communication. Make use of the TE-topology within an area to 640 summarize the TE networks in the area and advertise the same 641 to all TE-routers in the backbone. The TE-ABRs on the backbone 642 area will in-turn advertise these summaries within their 643 connected areas. 645 7. OSPF-TE router adjacency - TE topology discovery 647 OSPF creates adjacencies between neighboring routers for the purpose 648 of exchanging routing information. In the following subsections, we 649 describe modifications to the OSPF options field and the use of 650 Hello protocol to establish TE capability compliance between 651 neighboring routers in an area. The capability is used as the basis 652 to build TE topology. 654 7.1. The OSPF Options field 656 A new TE flag is introduced within the options field by this draft 657 to identify TE extensions to the OSPF. This bit will be used to 658 distinguish routers that support OSPF-TE. The OSPF options field 659 is present in OSPF Hello packets, Database Description packets, 660 and all link state advertisements. The TE bit, however, is a 661 requirement only for the Hello packets. Use of TE-bit is optional 662 in Database Description packets or LSAs. 664 Below is a description of the TE-Bit. Refer [OSPF-V2], [OSPF-NSSA] 665 and [OPAQUE] for a description of the remaining bits in the 666 options field. 668 -------------------------------------- 669 |TE | O | DC | EA | N/P | MC | E | * | 670 -------------------------------------- 671 The OSPF options field - TE support 673 TE-Bit: This bit is set to indicate support for traffic engineering 674 extensions to the OSPF. The Hello protocol which is used for 675 establishing router adjacency will use the TE-bit to 676 establish OSPF-TE adjacency. Two routers will not become 677 TE-neighbors unless they agree on the state of the TE-bit. 678 TE-compliant OSPF extensions are advertised only to the 679 TE-compliant routers. All other routers may simply ignore 680 the advertisements. 682 There is however a caveat with the above use of the last remaining 683 reserved bit in the options field. OSPF v2 will have no more 684 reserved bits left for future option extensions. If deemed 685 necessary to leave this bit as is, the OPAQUE-9 LSA (local scope) 686 can be used on each interface to communicate the support for 687 OSPF-TE. 689 7.2. The Hello Protocol 691 The Hello Protocol is primarily responsible for dynamically 692 establishing and maintaining neighbor adjacencies. In a TE network, 693 it is not required for all links and neighbors to establish 694 adjacency using this protocol. The Hello protocol will use the 695 TE-bit to establish traffic engineering capability between two 696 OSPF routers. 698 For NBMA and broadcast networks, this protocol is responsible for 699 electing the Designated Router and the Backup Designated Router. 701 For a TDM ring network, the designated and backup designated 702 routers may either be preselected (ex: GNE, backup-GNE) or 703 determined via the same Hello protocol. In any case, routers 704 supporting the TE option shall be given a higher precedence for 705 becoming a designated router over those that do not support TE. 707 If deemed necessary to leave the TE-bit unused in the options 708 field, the OSPF-TE routers could use OPAQUE-9 LSA (local scope) 709 to communicate TE capability between two OSPF routers. 711 7.3. The Designated Router 713 The Designated Router is elected by the Hello Protocol on broadcast 714 and NBMA networks. In general, when a router's non-TE link first 715 becomes functional, it checks to see whether there is currently a 716 Designated Router for the network. If there is one, it accepts that 717 Designated Router, regardless of its Router Priority, so long as 718 the current designated router is TE compliant. Otherwise, 719 the router itself becomes Designated Router if it has the highest 720 Router Priority on the network and is TE compliant. 722 TE-compliance (I.e., OSPF-TE) must be implemented on the most robust 723 routers, as they become likely candidates to take on the role as 724 designated router. 726 Alternatively, there can be two sets of designated routers, one for 727 the TE compliant routers and another for the native OSPF routers 728 (non-TE compliant). 730 7.4. The Backup Designated Router 732 The Backup Designated Router is also elected by the Hello 733 Protocol. Each Hello Packet has a field that specifies the 734 Backup Designated Router for the network. Once again, TE-compliance 735 must be weighed in conjunction with router priority in electing 736 the backup designated router. 738 Alternatively, there can be two sets of backup designated routers, 739 one for the TE compliant routers and another for the native OSPF 740 routers (non-TE compliant). 742 7.5. Flooding and the Synchronization of Databases 744 In OSPF, adjacent routers within an area must synchronize their 745 databases. However, as observed in [FLOOD-OPT], a more concise 746 requirement of OSPF is that all routers in an area must converge 747 on the same link state database. It is sufficient to send a 748 single copy of the LSAs to the neighboring routers in an area 749 than send one copy on each connected interface. [FLOOD-OPT] 750 describes in detail how to minimize flooding (Initial LSDB 751 synchronization as well as the asynchronous LSA updates) within 752 an area. 754 In the case where some of the neighbors are TE compliant and 755 others are not, the designated OSPF-TE router will exchange 756 different sets of LSAs with its neighbors. TE LSAs are 757 exchanged only with the TE neighbors. Native LSAs are 758 exchanged with all neighbors (TE and non-TE alike). 760 A new OSPFIGP-TE multicast address 224.0.0.24 may be used for 761 the exchange of TE compliant database descriptors. Flooding 762 optimization in a TE network is essential as the control 763 traffic for a TE network is likely to be higher than that of a 764 non-TE network. Flooding optimization will help minimize LSA 765 announcements and the associated retransmissions and 766 acknowledgements on the network. 768 7.6. The graph of adjacencies 770 If two routers have multiple networks in common, they may have 771 multiple adjacencies between them. The adjacency may be one of 772 two types - native OSPF adjacency and TE adjacency. OSPF-TE 773 routers will form both types of adjacency. 775 Two types of adjacency graphs are possible depending on whether 776 a Designated Router is elected for the network. On physical 777 point-to-point networks, Point-to-Multipoint networks and 778 Virtual links, neighboring routers become adjacent whenever they 779 can communicate directly. The adjacency can be one of 780 (a) TE-compliant or (b) native. In contrast, on broadcast and 781 NBMA networks the designated router and the backup designated 782 router may maintain two sets of adjacency. The remaining routers 783 will form either TE-compliant or native adjacency. In the 784 Broadcast network below, routers RT7 and RT3 are chosen as the 785 designated and backup routers respectively. Routers RT3, RT4 786 and RT7 are TE-compliant. RT5 and RT6 are not. So, RT4 will 787 have TE and native adjacencies with the designated and backup 788 routers. RT5 and RT6 will only have native adjacency with the 789 designated and backup routers. 791 +---+ +---+ 792 |RT1|------------|RT2| o---------------o 793 +---+ N1 +---+ RT1 RT2 795 RT7 796 o:::::::::: 797 +---+ +---+ +---+ /|: : 798 |RT7| |RT3| |RT4| / | : : 799 +---+ +---+ +---+ / | : : 800 | | | / | : : 801 +-----------------------+ RT5o RT6o oRT4 : 802 | | N2 * * ; : 803 +---+ +---+ * * ; : 804 |RT5| |RT6| * * ; : 805 +---+ +---+ **; : 806 o:::::::::: 807 RT3 809 Figure 6: The graph of adjacencies with TE-compliant routers. 811 8. TE LSAs - Packet network 813 The OSPFv2 protocol, as of now, has a total of 11 LSA types. 814 LSA types 1 through 5 are defined in [OSPF-v2]. LSA types 6, 7 815 and 8 are defined in [MOSPF], [NSSA] and [BGP-OSPF] respectively. 816 LSA types 9 through 11 are defined in [OPAQUE]. 818 Each LSA type has a unique flooding scope. Opaque LSA types 819 9 through 11 are general purpose LSAs, with flooding 820 scope set to link-local, area-local and AS-wide (except stub 821 areas) respectively. 823 In the following subsections, we define new LSAs for traffic 824 engineering (TE) use. The Values for the new TE LSA types are 825 assigned such that the high bit of the LSA-type octet is set 826 to 1. The new TE LSAs are largely modeled after the existing 827 LSAs for content format and have a unique flooding scope. 829 TE-router LSA is defined to advertise TE characteristics of 830 an OSPF-TE router and all the TE-links attached to the 831 router. TE-incremental-Link-Update LSA is defined to 832 advertise incremental updates to the metrics of a TE link. 833 Flooding scope for both these LSAs is restricted to the 834 TE nodes in the area. 836 TE-Summary network and router LSAs are defined to advertise 837 the reachability of area-specific TE networks and Area Border 838 Routers (along with router TE characteristics) to external 839 areas. Flooding Scope of the TE-Summary LSAs is the TE topology 840 in the entire AS less the non-backbone area for which the 841 the advertising router is an ABR. Just as with native OSPF 842 summary LSAs, the TE-summary LSAs do not reveal the topological 843 details of an area to external areas. 845 TE-AS-external LSA and TE-Circuit-Path LSA are defined to 846 advertise AS external network reachability and pre-engineered 847 TE circuits respectively. While flooding scope for both these 848 LSAs can be the entire AS, flooding scope for the 849 pre-engineered TE circuit LSA may optionally be restricted to 850 just the TE topology within an area. 852 8.1. TE-Router LSA (0x81) 854 The TE-router LSA (0x81) is modeled after the router LSA and has the 855 same flooding scope as the router-LSA. However, the scope is 856 restricted to only the OSPF-TE nodes within the area. The TE-router 857 LSA describes the TE metrics of the router as well as the TE-links 858 attached to the router. Below is the format of the TE-router LSA. 859 Unless specified explicitly otherwise, the fields carry the same 860 meaning as they do in a router LSA. Only the differences are 861 explained below. Router-TE flags, Router-TE TLVs, Link-TE options, 862 and Link-TE TLVs are each described in the following sub-sections. 864 0 1 2 3 865 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 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 | LS age | Options | 0x81 | 868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 | Link State ID | 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Advertising Router | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | LS sequence number | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | LS checksum | length | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | 0 |V|E|B| 0 | Router-TE flags | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Router-TE flags (contd.) | Router-TE TLVs | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | .... | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | .... | # of TE links | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 | Link ID | 886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 | Link Data | 888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 889 | Type | 0 | Link-TE flags | 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | Link-TE flags (contd.) | Zero or more Link-TE TLVs | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | Link ID | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | Link Data | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | ... | 899 Option 900 In TE-capable router nodes, the TE-bit may be set to 1. 902 8.1.1. Router-TE flags - TE capabilities of the router 904 The following flags are used to describe the TE capabilities of an 905 OSPF-TE router. The remaining bits of the 32-bit word are reserved 906 for future use. 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 |L|L|P| | | | |L|S|C| 910 |S|E|S| | | | |S|I|S| 911 |R|R|C| | | | |P|G|P| 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| 915 Bit LSR 916 When set, the router is considered to have LSR capability. 918 Bit LER 919 When set, the router is considered to have LER capability. 920 All MPLS border routers will be required to have the LER 921 capability. When the E bit is also set, that indicates an 922 AS Boundary router with LER capability. When the B bit is 923 also set, that indicates an area border router with LER 924 capability. 926 Bit PSC 928 Indicates the node is Packet Switch Capable. 930 Bit LSP 931 MPLS Label switch TLV TE-NODE-TLV-MPLS-SWITCHING follows. 932 This is applicable only when the PSC flag is set. 934 Bit SIG 935 MPLS Signaling protocol support TLV 936 TE-NODE-TLV-MPLS-SIG-PROTOCOLS follows. 938 BIT CSPF 939 CSPF algorithm support TLV TE-NODE-TLV-CSPF-ALG follows. 941 8.1.2. Router-TE TLVs 943 The following Router-TE TLVs are defined. 945 8.1.2.4. TE-NODE-TLV-MPLS-SWITCHING 947 MPLS switching TLV is applicable only for packet switched nodes. The 948 TLV specifies the MPLS packet switching capabilities of the TE 949 node. 951 0 1 2 3 952 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 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | Tag = 0x8001 | Length = 6 | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Label depth | QOS | | 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 'Label depth' is the depth of label stack the node is capable of 960 processing on its ingress interfaces. An octet is used to represent 961 label depth. A default value of 1 is assumed when the TLV is not 962 listed. 964 'QOS' is a single octet field that may be assigned '1' or '0'. Nodes 965 supporting QOS are able to interpret the EXP bits in the MPLS header 966 to prioritize multiple classes of traffic through the same LSP. 968 8.1.2.2. TE-NODE-TLV-MPLS-SIG-PROTOCOLS 970 MPLS signaling protocols TLV lists all the signaling protocol 971 supported by the node. An octet is used to list each signaling 972 protocol supported. 974 0 1 2 3 975 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 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | Tag = 0x8002 | Length = 5, 6 or 7 | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | Protocol-1 | ... | .... | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 RSVP-TE protocol is represented as 1, CR-LDP as 2 and LDP as 3. 983 These are the only permitted signaling protocols at this time. 985 8.1.2.3. TE-NODE-TLV-CSPF-ALGORITHMS 987 The CSPF algorithms TLV lists all the CSPF algorithm codes 988 supported. Support for CSPF algorithms makes the node eligible to 989 compute complete or partial circuit paths. Support for CSPF 990 algorithms can also be beneficial in knowing whether or not a node 991 is capable of expanding loose routes (in an MPLS signaling request) 992 into a detailed circuit path. 994 Two octets are used to list each CSPF algorithm code. The algorithm 995 codes may be vendor defined and unique within an Autonomous System. 996 If the node supports 'n' CSPF algorithms, the Length would be 997 (4 + 4 * ((n+1)/2)) octets. 999 0 1 2 3 1000 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 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | Tag = 0x8003 | Length = 4(1 + (n+1)/2) | 1003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1004 | CSPF-1 | .... | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | CSPF-n | | 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 8.1.3. Link-TE flags - TE capabilities of a link 1011 The following flags are used to describe the TE capabilities of a 1012 link. The remaining bits of the 32-bit word are reserved for 1013 future use. 1015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 |T|N|P| | | |D| |S|L|B|C| 1017 |E|T|K| | | |B| |R|U|W|O| 1018 | |E|T| | | |S| |L|G| |L| 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| 1022 TE - Indicates whether TE is permitted on the link. A link 1023 can be denied for TE use by setting the flag to 0. 1025 NTE - Indicates whether non-TE traffic is permitted on the 1026 TE link. This flag is relevant only when the TE 1027 flag is set. 1029 PKT - Indicates whether or not the link is capable of IP 1030 packet processing. 1032 DBS - Indicates whether or not Database synchronization 1033 is permitted on this link. 1035 SRLG Bit - Shared Risk Link Group TLV TE-LINK-TLV-SRLG follows. 1037 LUG bit - Link usage cost metric TLV TE-LINK-TLV-LUG follows. 1039 BW bit - Link bandwidth TLV TE-LINK-TLV-BANDWIDTH follows. 1041 COL bit - Link Color TLV TE-LINK-TLV-COLOR follows. 1043 8.1.4. Link-TE TLVs 1045 8.1.4.1. TE-LINK-TLV-SRLG 1047 The SRLG describes the list of Shared Risk Link Groups (SRLG) the 1048 link belongs to. Two octets are used to list each SRLG. If the link 1049 belongs to 'n' SRLGs, the Length would be (4 + 4 * ((n+1)/2)) octets. 1051 0 1 2 3 1052 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 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | Tag = 0x0001 | Length = 4(1 + (n+1)/2) | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | SRLG-1 | .... | 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | SRLG-n | | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 8.1.4.2. TE-LINK-TLV-BANDWIDTH 1063 The bandwidth TLV specifies maximum bandwidth, bandwidth available 1064 for TE use and reserved bandwidth as follows. 1066 0 1 2 3 1067 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 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Tag = 0x0002 | Length = 16 | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | Maximum Bandwidth | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | Bandwidth available for TE use | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | Reserved Bandwidth | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 Bandwidth is expressed in units of 32 bytes/sec (256 bits/sec). 1079 A 32-bit field for bandwidth would permit specification not exceeding 1080 1 tera-bits/sec. 1082 'Maximum bandwidth' is be the maximum link capacity expressed in 1083 bandwidth units. 1085 'Bandwidth available for TE use' is the maximum reservable bandwidth 1086 on the link for use by all the TE circuit paths traversing the link. 1087 The link is oversubscribed when this field is more than the 1088 'Maximum Bandwidth'. When the field is less than the 1089 'Maximum Bandwidth', the remaining bandwidth on the link may likely 1090 be used for non-TE traffic. 1092 'Reserved Bandwidth' is the bandwidth that is currently subscribed 1093 from of the link. 'Reserved Bandwidth' must be less than the 1094 'Bandwidth available for TE use'. New TE circuit paths are able to 1095 claim no more than the difference between the two bandwidths for 1096 reservation. 1098 8.1.4.3. TE-LINK-TLV-LUG 1100 The link usage cost TLV specifies Bandwidth unit usage cost, 1101 TE circuit set-up cost, and any time constraints for setup and 1102 teardown of TE circuits on the link. 1104 0 1 2 3 1105 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 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | Tag = 0x0003 | Length = 28 | 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1109 | Bandwidth unit usage cost | 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | TE circuit set-up cost | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | TE circuit set-up time constraint | 1114 | | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | TE circuit tear-down time constraint | 1117 | | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 Circuit Setup time constraint 1121 This 64-bit number specifies the time at or after which a 1122 TE-circuit path may be set up on the link. The set-up time 1123 constraint is specified as the number of seconds from the start 1124 of January 1, 1970 UTC. A reserved value of 0 implies no circuit 1125 setup time constraint. 1127 Circuit Teardown time constraint 1128 This 64-bit number specifies the time at or before which all 1129 TE-circuit paths using the link must be torn down. The teardown 1130 time constraint is specified as the number of seconds from the 1131 start of January 1 1970 UTC. A reserved value of 0 implies no 1132 circuit teardown time constraint. 1134 No. of TE Circuit paths 1135 This specifies the number of pre-engineered TE circuit paths 1136 between the advertising router and the router specified in the 1137 link state ID. 1139 8.1.4.4. TE-LINK-TLV-COLOR 1141 The color TLV is similar to the SRLG TLV, in that an Autonomous 1142 System may choose to issue colors to a TE-link meeting certain 1143 criteria. The color TLV can be used to specify one or more colors 1144 assigned to the link as follows. Two octets are used to list each 1145 color. If the link belongs to 'n' number of colors, the Length 1146 would be (4 + 4 * ((n+1)/2)) octets. 1148 0 1 2 3 1149 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | Tag = 0x0004 | Length = 4(1 + (n+1)/2) | 1152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1153 | Color-1 | .... | 1154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1155 | Color-n | | 1156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1158 8.2. TE-incremental-link-Update LSA (0x8d) 1160 A significant difference between a non-TE OSPF network and a TE OSPF 1161 network is that the latter may be subject to frequent real-time 1162 circuit pinning and is likely to undergo TE-state updates. Some 1163 links might undergo changes more frequently than others. Flooding 1164 the network with TE-router LSAs at the aggregated speed of all 1165 link metric changes is simply not desirable. A smaller in size, 1166 TE-incremental-link-update LSA is designed to advertise only the 1167 incremental link updates. 1169 TE-incremental-link-Update LSA will be advertised as frequently 1170 as the link state is changed. The TE-link sequence is largely the 1171 advertisement of a sub-portion of router LSA. The sequence number on 1172 this will be incremented with the TE-router LSA's sequence as the 1173 basis. When an updated TE-router LSA is advertised within 30 minutes 1174 of the previous advertisement, the updated TE-router LSA will assume 1175 a sequence no. that is larger than the most frequently updated of 1176 its links. 1178 Below is the format of the TE-incremental-link-update LSA. 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 | LS age | Options | 0x8d | 1184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1185 | Link State ID (same as Link ID) | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | Advertising Router | 1188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1189 | LS sequence number | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | LS checksum | length | 1192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 | Link Data | 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 | Type | 0 | Link-TE options | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 | Link-TE options | Zero or more Link-TE TLVs | 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 | # TOS | metric | 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 | ... | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | TOS | 0 | TOS metric | 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1206 Link State ID 1207 This would be exactly the same as would have been specified as 1208 as Link ID for a link within the router-LSA. 1210 Link Data 1211 This specifies the router ID the link belongs to. In majority of 1212 cases, this would be same as the advertising router. This choice 1213 for Link Data is primarily to facilitate proxy advertisement for 1214 incremental link updates. 1216 Say, a router-proxy-LSA was used to advertise the TE-router-LSA 1217 of a SONET/TDM node. Say, the proxy router is now required to 1218 advertise incremental-link-update for the same SONET/TDM node. 1219 Specifying the actual router-ID the link in the 1220 incremental-link-update-LSA belongs to helps receiving nodes in 1221 finding the exact match for the LSA in their database. 1223 The tuple of (LS Type, LSA ID, Advertising router) uniquely identify 1224 the LSA and replace LSAs of the same tuple with an older sequence 1225 number. However, there is an exception to this rule in the context 1226 of TE-link-update LSA. TE-Link update LSA will initially assume the 1227 sequence number of the TE-router LSA it belongs to. Further, when a 1228 new TE-router LSA update with a larger sequence number is advertised, 1229 the newer sequence number is assumed by al the link LSAs. 1231 8.3. TE-Circuit-path LSA (0x8C) 1233 TE-Circuit-path LSA may be used to advertise the availability of 1234 pre-engineered TE circuit path(s) originating from any router 1235 in the network. The flooding scope may be Area wide or AS wide. 1237 0 1 2 3 1238 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 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | LS age | Options | 0x84 | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 | Link State ID | 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 | Advertising Router | 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 | LS sequence number | 1247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1248 | LS checksum | length | 1249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1250 | 0 |G|E|B|D|S|T|CktType| Circuit Duration (Optional) | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1252 | Circuit Duration cont... | 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 | Circuit Duration cont.. | Circuit Setup time (Optional) | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 | Circuit Setup time cont... | 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 | Circuit Setup time cont.. |Circuit Teardown time(Optional)| 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | Circuit Teardown time cont... | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | Circuit Teardown time cont.. | No. of TE circuit paths | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 | Circuit-TE ID | 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | Circuit-TE Data | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | Type | 0 | Circuit-TE flags | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Circuit-TE flags (contd.) | Zero or more Circuit-TE TLVs | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | Circuit-TE ID | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 | Circuit-TE Data | 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 | ... | 1278 Link State ID 1279 The ID of the far-end router or the far-end Link-ID to which the 1280 TE circuit path(s) is being advertised. 1282 TE-circuit-path(s) flags 1284 Bit G - When set, the flooding scope is set to be AS wide. 1285 Otherwise, the flooding scope is set to be area wide. 1287 Bit E - When set, the advertised Link-State ID is an AS boundary 1288 router (E is for external). The advertising router and 1289 the Link State ID belong to the same area. 1291 Bit B - When set, the advertised Link state ID is an Area border 1292 router (B is for Border) 1294 Bit D - When set, this indicates that the duration of circuit 1295 path validity follows. 1297 Bit S - When set, this indicates that Setup-time of the circuit 1298 path follows. 1300 Bit T - When set, this indicates that teardown-time of the 1301 circuit path follows. 1303 CktType 1304 This 4-bit field specifies the Circuit type of the Forward 1305 Equivalency Class (FC). 1306 0x01 - Origin is Router, Destination is Router. 1307 0x02 - Origin is Link, Destination is Link. 1308 0x04 - Origin is Router, Destination is Link. 1309 0x08 - Origin is Link, Destination is Router. 1311 Circuit Duration (Optional) 1312 This 64-bit number specifies the seconds from the time of the 1313 LSA advertisement for which the pre-engineered circuit path 1314 will be valid. This field is specified only when the D-bit is 1315 set in the TE-circuit-path flags. 1317 Circuit Setup time (Optional) 1318 This 64-bit number specifies the time at which the TE-circuit 1319 path may be set up. This field is specified only when the 1320 S-bit is set in the TE-circuit-path flags. The set-up time is 1321 specified as the number of seconds from the start of January 1322 1 1970 UTC. 1324 Circuit Teardown time (Optional) 1325 This 64-bit number specifies the time at which the TE-circuit 1326 path may be torn down. This field is specified only when the 1327 T-bit is set in the TE-circuit-path flags. The teardown time 1328 is specified as the number of seconds from the start of 1329 January 1 1970 UTC. 1331 No. of TE Circuit paths 1332 This specifies the number of pre-engineered TE circuit paths 1333 between the advertising router and the router specified in the 1334 link state ID. 1336 Circuit-TE ID 1337 This is the ID of the far-end router for a given TE-circuit 1338 path segment. 1340 Circuit-TE Data 1341 This is the virtual link identifier on the near-end router for 1342 a given TE-circuit path segment. This can be a private 1343 interface or handle the near-end router uses to identify the 1344 virtual link. 1346 The sequence of (circuit-TE ID, Circuit-TE Data) list the 1347 end-point nodes and links in the LSA as a series. 1349 Circuit-TE flags 1350 This lists the Zero or more TE-link TLVs that all member 1351 elements of the LSP meet. 1353 8.4. TE-Summary LSAs 1355 TE-Summary-LSAs are the Type 0x83 and 0x84 LSAs. These LSAs are 1356 originated by area border routers. TE-Summary-network-LSA (0x83) 1357 describes the reachability of TE networks in a non-backbone 1358 area, advertised by the Area Border Router. Type 0x84 1359 summary-LSA describes the reachability of Area Border Routers 1360 and AS border routers and their TE capabilities. 1362 One of the benefits of having multiple areas within an AS is 1363 that frequent TE advertisements within the area do not impact 1364 outside the area. Only the TE abstractions befitting the 1365 external areas are advertised. 1367 8.4.1. TE-Summary Network LSA (0x83) 1369 TE-summary network LSA may be used to advertise reachability of 1370 TE-networks accessible to areas external to the originating 1371 area. The content and the flooding scope of a TE-Summary LSA 1372 is different from that of a native summary LSA. 1374 The scope of flooding for a TE-summary network is AS wide, with 1375 the exception of the originating area and the stub areas. The 1376 area border router for each non-backbone area is responsible 1377 for advertising the reachability of backbone networks into the 1378 area. 1380 Unlike a native-summary network LSA, TE-summary network LSA does 1381 not advertise summary costs to reach networks within an area. 1382 This is because TE parameters are not necessarily additive or 1383 comparative. The parameters can be varied in their expression. 1384 For example, a TE-summary network LSA will not summarize a 1385 network whose links do not fall under an SRLG (Shared-Risk Link 1386 Group). This way, the TE-summary LSA merely advertises the 1387 reachability of TE networks within an area. The specific circuit 1388 paths can be computed by the BDRs. Pre-engineered circuit paths 1389 are advertised using TE-Circuit-path LSA (refer section 8.3). 1391 0 1 2 3 1392 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 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 | LS age | Options | 0x83 | 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 | Link State ID (IP Network Number) | 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | Advertising Router (Area Border Router) | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | LS sequence number | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1402 | LS checksum | length | 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 | Network Mask | 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 | Area-ID | 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 8.4.2. TE-Summary router LSA (0x84) 1411 TE-summary router LSA may be used to advertise the availability of 1412 Area Border Routers (ABRs) and AS Border Routers (ASBRs) that are 1413 TE capable. The TE-summary router LSAs are originated by the Area 1414 Border Routers. The scope of flooding for the TE-summary router LSA 1415 is the non-backbone area the advertising ABR belongs to. 1417 0 1 2 3 1418 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 1419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1420 | LS age | Options | 0x84 | 1421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 | Link State ID | 1423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1424 | Advertising Router (ABR) | 1425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 | LS sequence number | 1427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1428 | LS checksum | length | 1429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1430 | 0 |E|B| 0 | No. of Areas | 1431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 | Area-ID | 1433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1434 | ... | 1435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 | Router-TE flags | 1437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 | Router-TE TLVs | 1439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1440 | .... | 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 Link State ID 1444 The ID of the Area border router or the AS border router whose 1445 TE capability is being advertised. 1447 Advertising Router 1448 The ABR that advertises its TE capabilities (and the OSPF areas 1449 it belongs to) or the TE capabilities of an ASBR within one of 1450 the areas the ABR is a border router of. 1452 No. of Areas 1453 Specifies the number of OSPF areas the link state ID belongs to. 1455 Area-ID 1456 Specifies the OSPF area(s) the link state ID belongs to. When 1457 the link state ID is same as the advertising router ID, the 1458 Area-ID lists all the areas the ABR belongs to. In the case 1459 the link state ID is an ASBR, the Area-ID simply lists the 1460 area the ASBR belongs to. The advertising router is assumed to 1461 be the ABR from the same area the ASBR is located in. 1463 Summary-router-TE flags 1465 Bit E - When set, the advertised Link-State ID is an AS boundary 1466 router (E is for external). The advertising router and 1467 the Link State ID belong to the same area. 1469 Bit B - When set, the advertised Link state ID is an Area 1470 border router (B is for Border) 1472 Router-TE flags, 1473 Router-TE TLVs (TE capabilities of the link-state-ID router) 1475 TE Flags and TE TLVs are as applicable to the ABR/ASBR 1476 specified in the link state ID. The semantics is same as 1477 specified in the Router-TE LSA. 1479 8.5. TE-AS-external LSAs (0x85) 1481 TE-AS-external-LSAs are the Type 0x85 LSAs. This is modeled after 1482 AS-external LSA format and flooding scope. TE-AS-external LSAs are 1483 originated by AS boundary routers with TE extensions, and describe 1484 the TE networks and pre-engineered circuit paths external to the 1485 AS. As with AS-external LSA, the flooding scope of the 1486 TE-AS-external LSA is AS wide, with the exception of stub areas. 1488 0 1 2 3 1489 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 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | LS age | Options | 0x85 | 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1493 | Link State ID | 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 | Advertising Router | 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 | LS sequence number | 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 | LS checksum | length | 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 | Network Mask | 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | Forwarding address | 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 | External Route Tag | 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 | # of Virtual TE links | 0 | 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 | Link-TE flags | 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | Link-TE TLVs | 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | ... | 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 | TE-Forwarding address | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | External Route TE Tag | 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 | ... | 1521 Network Mask 1522 The IP address mask for the advertised TE destination. For 1523 example, this can be used to specify access to a specific 1524 TE-node or TE-link with an mask of 0xffffffff. This can also 1525 be used to specify access to an aggregated set of destinations 1526 using a different mask. ex: 0xff000000. 1528 Link-TE flags, 1529 Link-TE TLVs 1530 The TE attributes of this route. These fields are optional and 1531 are provided only when one or more pre-engineered circuits can 1532 be specified with the advertisement. Without these fields, 1533 the LSA will simply state TE reachability info. 1535 Forwarding address 1536 Data traffic for the advertised destination will be forwarded to 1537 this address. If the Forwarding address is set to 0.0.0.0, data 1538 traffic will be forwarded instead to the LSA's originator (i.e., 1539 the responsible AS boundary router). 1541 External Route Tag 1542 A 32-bit field attached to each external route. This is not 1543 used by the OSPF protocol itself. It may be used to communicate 1544 information between AS boundary routers; the precise nature of 1545 such information is outside the scope of this specification. 1547 9. TE LSAs - Non-packet network 1549 A non-packet network would use all the TE LSAs described in the 1550 previous section for a packet network, albeit with some variations. 1551 These variations are described in the following subsections. 1553 TE-Router-Proxy LSA is defined to allow proxy advertisement for 1554 non-packet TE-nodes by an OSPF-TE router. 1556 9.1. TE-Router LSA (0x81) 1558 The following fields are used to describe each router link (i.e., 1559 interface). Each router link is typed (see the below Type field). 1560 The Type field indicates the kind of link being described. 1562 Type 1563 A new link type "Positional-Ring Type" (value 5) is defined. 1564 This is essentially a connection to a TDM-Ring. TDM ring network 1565 is different from LAN/NBMA transit network in that nodes on the 1566 TDM ring do not necessarily have a terminating path between 1567 themselves. Secondly, the order of links is important in 1568 determining the circuit path. Third, the protection switching 1569 and the number of fibers from a node going into a ring are 1570 determined by the ring characteristics. I.e., 2-fiber vs 1571 4-fiber ring and UPSR vs BLSR protected ring. 1573 Type Description 1574 __________________________________________________ 1575 1 Point-to-point connection to another router 1576 2 Connection to a transit network 1577 3 Connection to a stub network 1578 4 Virtual link 1579 5 Positional-Ring Type. 1581 Link ID 1582 Identifies the object that this router link connects to. 1583 Value depends on the link's Type. For a positional-ring type, 1584 the Link ID shall be IP Network/Subnet number just as the case 1585 with a broadcast transit network. The following table 1586 summarizes the updated Link ID values. 1588 Type Link ID 1589 ______________________________________ 1590 1 Neighboring router's Router ID 1591 2 IP address of Designated Router 1592 3 IP network/subnet number 1593 4 Neighboring router's Router ID 1594 5 IP network/subnet number 1596 Link Data 1597 This depends on the link's Type field. For type-5 links, this 1598 specifies the router interface's IP address. 1600 9.1.1. Router-TE flags - TE capabilities of the router 1602 Flags specific to non-packet TE-nodes are described below. 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 |L|L|P|T|L|F| |S|S|S|C| 1606 |S|E|S|D|S|S| |T|E|I|S| 1607 |R|R|C|M|C|C| |A|L|G|P| 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| 1611 Bit TDM 1612 Indicates the node is TDM circuit switch capable. 1614 Bit LSC 1615 Indicates the node is Lambda switch Capable. 1617 Bit FSC 1619 Indicates the node is Fiber (can also be a non-fiber link 1620 type) switch capable. 1622 9.1.2. Link-TE options - TE capabilities of a TE-link 1624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1625 |T|N|P|T|L|F|D| |S|L|B|C| 1626 |E|T|K|D|S|S|B| |R|U|W|O| 1627 | |E|T|M|C|C|S| |L|G|A|L| 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 |<---- Boolean TE flags ------->|<- TE flags pointing to TLVs ->| 1631 TDM, LSC, FSC bits 1632 - Same as defined for router TE options. 1634 9.2. Changes to Network LSA 1636 Network-LSA is the Type 2 LSA. With the exception of the following, 1637 no additional changes will be required to this LSA for TE 1638 compatibility. The LSA format and flooding scope remains unchanged. 1640 A network-LSA is originated for each broadcast, NBMA and 1641 Positional-Ring type network in the area which supports two or 1642 more routers. The TE option is also required to be set while 1643 propagating the TDM network LSA. 1645 9.2.1. Positional-Ring type network LSA - New Network type for TDM-ring. 1646 - Ring ID: (Network Address/Mask) 1647 - No. of elements in the ring (a.k.a. ring neighbors) 1648 - Ring Bandwidth 1649 - Ring Protection (UPSR/BLSR) 1650 - ID of individual nodes (Interface IP address) 1651 - Ring type (2-Fiber vs. 4-Fiber, SONET vs. SDH) 1653 Network LSA is required for SONET RING. Unlike the broadcast 1654 type, the sequence in which the Network Elements (NEs) are 1655 placed on a RING-network is pertinent. The nodes in the ring 1656 must be described clock wise, assuming the Gateway Network 1657 Element (GNE) as the starting element. 1659 9.3. TE-Router-Proxy LSA (0x8e) 1661 This is a variation to the TE-router LSA in that the TE-router LSA 1662 is not advertised by the network element, but rather by a trusted 1663 TE-router Proxy. This is typically the scenario in a non-packet 1664 TE network, where some of the nodes do not have OSPF functionality 1665 and count on a helper node to do the advertisement for them. One 1666 such example would be the SONET/SDH ADM nodes in a TDM ring. The 1667 nodes may principally depend upon the GNE (Gateway Network Element) 1668 to do the advertisement for them. TE-router-Proxy LSA shall not be 1669 used to advertise Area Border Routers and/or AS border Routers. 1671 0 1 2 3 1672 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 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1674 | LS age | Options | 0x8e | 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1676 | Link State ID (Router ID of the TE Network Element) | 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 | Advertising Router | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 | LS sequence number | 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1682 | LS checksum | length | 1683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1684 | 0 | Router-TE flags | 1685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1686 | Router-TE flags (contd.) | Router-TE TLVs | 1687 +---------------------------------------------------------------+ 1688 | .... | 1689 +---------------------------------------------------------------+ 1690 | .... | # of TE links | 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | Link ID | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 | Link Data | 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 | Type | 0 | Link-TE options | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | Link-TE flags | Zero or more Link-TE TLVs | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | Link ID | 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 | Link Data | 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 | ... | 1706 10. Abstract topology representation with TE support 1708 Below, we consider a TE network composed of three OSPF areas - 1709 Area-1, Area-2 and Area-3, attached together through the backbone 1710 area. Area-1 an has a single area border router, ABR-A1 and no 1711 ASBRs. Area-2 has an area border router ABR-A2 and an AS border 1712 router ASBR-S1. Area-3 has two area border routers ABR-A2 and 1713 ABR-A3 and an AS border router ASBR-S2. The following network 1714 also assumes a pre-engineered TE circuit path between ABR-A1 1715 and ABR-A2; between ABR-A1 and ABR-A3; between ABR-A2 and 1716 ASBR-S1; and between ABR-A3 and ASBR-S2. 1718 The following figure is an inter-area topology abstraction 1719 from the perspective of routers in Area-1. The abstraction 1720 illustrates reachability of TE networks and nodes within area 1721 to the external areas in the same AS and to the external ASes. 1722 The abstraction also illustrates pre-engineered TE circuit 1723 paths advertised by ABRs and ASBRs. 1725 +-------+ 1726 |Area-1 | 1727 +-------+ 1728 +-------------+ | 1729 |Reachable TE | +--------+ 1730 |networks in |-------| ABR-A1 | 1731 |backbone area| +--------+ 1732 +-------------+ | | | 1733 +--------------+ | +-----------------+ 1734 | | | 1735 +-----------------+ | +-----------------+ 1736 |Pre-engineered TE| +----------+ |Pre-engineered TE| 1737 |circuit path(s) | | Backbone | |circuit path(s) | 1738 |to ABR-A2 | | Area | |to ABR-A3 | 1739 +-----------------+ +----------+ +-----------------+ 1740 | | | | 1741 +----------+ | +--------------+ | 1742 +-----------+ | | | | +-----------+ 1743 |Reachable | +--------+ +--------+ |Reachable | 1744 |TE networks|------| ABR-A2 | | ABR-A3 |--|TE networks| 1745 |in Area A2 | +--------+ +--------+ |in Area A3 | 1746 +-----------+ | | | | | | +-----------+ 1747 +-------------+ | | +-----------------+ | +----------+ 1748 | | +-----------+ | | | 1749 +-----------+ +--------------+ | | | +--------------+ 1750 |Reachable | |Pre-engineered| | | | |Pre-engineered| 1751 |TE networks| |TE Ckt path(s)| +------+ +------+ |TE Ckt path(s)| 1752 |in Area A3 | |to ASBR-S1 | |Area-2| |Area-3| |to ASBR-S2 | 1753 +-----------+ +--------------+ +------+ +------+ +--------------+ 1754 | | | | 1755 | +--------+ | +-----------+ 1756 +-------------+ | | | | 1757 |AS external | +---------+ +---------+ 1758 |TE-network |----| ASBR-S1 | | ASBR-S2 | 1759 |reachability | +---------+ +---------+ 1760 |from ASBR-S1 | | | | 1761 +-------------+ +---+ +-------+ +-----------+ 1762 | | | 1763 +-----------------+ +-------------+ +-----------------+ 1764 |Pre-engineered TE| |AS External | |Pre-engineered TE| 1765 |circuit path(s) | |TE-Network | |circuit path(s) | 1766 |reachable from | |reachability | |reachable from | 1767 |ASBR-S1 | |from ASBR-S2 | |ASBR-S2 | 1768 +-----------------+ +-------------+ +-----------------+ 1770 Figure 9: Inter-Area Abstraction as viewed by Area-1 TE-routers 1772 11. Changes to Data structures in OSPF-TE nodes 1774 11.1. Changes to Router data structure 1776 The router with TE extensions must be able to include all the 1777 TE capabilities (as specified in section 7.1) in the router data 1778 structure. Further, routers providing proxy service to other TE 1779 routers must also track the router and associated interface data 1780 structures for all the TE client nodes for which the proxy 1781 service is being provided. Presumably, the interaction between 1782 the Proxy server and the proxy clients is out-of-band. 1784 11.2. Two sets of Neighbors 1786 Two sets of neighbor data structures are required. TE-neighbors 1787 set is used to advertise TE LSAs. Only the TE-nodes will be 1788 members of the TE-neighbor set. Native neighbors set will be used 1789 to advertise native LSAs. All neighboring nodes supporting 1790 non-TE links are part of this set. As for flooding optimizations 1791 based on neighbors set, readers may refer [FLOOD-OPT]. 1793 11.3. Changes to Interface data structure 1795 The following new fields are introduced to the interface data 1796 structure. These changes are in addition to the changes specified 1797 in [FLOOD-OPT]. 1799 TePermitted 1800 If the value of the flag is TRUE, the interface may be 1801 advertised as a TE-enabled interface. 1803 NonTePermitted 1804 If the value of the flag is TRUE, the interface permits non-TE 1805 traffic on the interface. Specifically, this is applicable to 1806 packet networks, where data links may permit both TE and IP 1807 packets. For FSC and LSC TE networks, this flag is set to 1808 FALSE. 1810 IpTerminated 1811 If the value of the flag is TRUE, the interface processes IP 1812 Packet data and hence may be used for OSPF data exchange. 1814 AdjacencySychRequired 1815 If the value of the flag is TRUE, the interface may be used to 1816 synchronize the LSDB across all adjacent neighbors. This is 1817 TRUE by default to all IpTerminated interfaces that are 1818 enabled for OSPF. However, it is possible to set this to FALSE 1819 for some of the interfaces. 1821 TE-TLVs 1822 Each interface may potentially have a maximum of 16 TLVS that 1823 describe the link characteristics. 1825 The following existing fields in Interface data structure will take 1826 on additional values to support TE extensions. 1828 Type 1829 The OSPF interface type can also be of type "Positional-RING". 1830 The Positional-ring type is different from other types (such 1831 as broadcast and NBMA) in that the exact location of the nodes 1832 on the ring is relevant, even though they are all on the same 1833 ring. SONET ADM ring is a good example of this. Complete ring 1834 positional-ring description may be provided by the GNE on a 1835 ring as a TE-network LSA for the ring. 1837 List of Neighbors 1838 The list may be statically defined for an interface without 1839 requiring the use of Hello protocol. 1841 12. IANA Considerations 1843 This document proposes that TE LSA types and TE TLVs be 1844 maintained by the IANA. The document also proposes an OSPFIGP-TE 1845 multicast address be assigned by the IANA for the exchange of 1846 TE database descriptors. 1848 OSPFIGP-TE multicast address is suggested a value of 224.0.0.24 1849 so as not to conflict with the recognized multicast address 1850 definitions, as defined in 1851 http://www.iana.org/assignments/multicast-addresses 1853 The following sub-section explains the criteria to be used by the 1854 IANA to assign TE LSA types and TE TLVs. 1856 12.1. TE LSA type values 1858 LSA type is an 8-bit field required by each LSA. TE LSA types 1859 will have the high bit set to 1. TE LSAs can range from 0x80 1860 through 0xFF. The following values are defined in sections 1861 8.0 and 9.0. The remaining values are available for assignment 1862 by the IANA with IETF Consensus [Ref 11]. 1864 TE LSA Type Value 1865 _________________________________________ 1867 TE-Router LSA 0x81 1868 TE-Summary Network LSA 0x83 1869 TE-Summary router LSA 0x84 1870 TE-AS-external LSAs 0x85 1871 TE-Circuit-paths LSA 0x8C 1872 TE-incremental-link-Update LSA 0x8d 1873 TE-Router-Proxy LSA 0x8e 1875 12.2. TE TLV tag values 1877 TLV type is a 16-bit field required by each TE TLV. TLV type 1878 shall be unique across the router and link TLVs. A TLV type 1879 can range from 0x0001 through 0xFFFF. TLV type 0 is reserved 1880 and unassigned. The following TLV types are defined in sections 1881 8.0 and 9.0. The remaining values are available for assignment 1882 by the IANA with IETF Consensus [Ref 11]. 1884 TE TLV Tag Reference Value 1885 Section 1886 _________________________________________________________ 1888 TE-LINK-TLV-SRLG Section 8.1.4.1 0x0001 1889 TE-LINK-TLV-BWA Section 8.1.4.2 0x0002 1890 TE-LINK-TLV-LUG Section 8.1.4.3 0x0003 1891 TE-LINK-TLV-COLOR Section 8.1.4.4 0x0004 1892 TE-NODE-TLV-MPLS-SWITCHING Section 8.1.2.1 0x8001 1893 TE-NODE-TLV-MPLS-SIG-PROTOCOLS Section 8.1.2.2 0x8002 1894 TE-NODE-TLV-CSPF-ALG Section 8.1.2.3 0x8003 1896 13. Acknowledgements 1898 The authors wish to specially thank Chitti Babu and his team 1899 for verifying portions of the specification for a packet 1900 network. The authors also wish to thank Vishwas Manral, Riyad 1901 Hartani and Tricci So for their valuable comments and feedback 1902 on the draft. 1904 14. Security Considerations 1906 Security considerations for the base OSPF protocol are covered 1907 in [OSPF-v2] and [SEC-OSPF]. This memo does not create any new 1908 security issues for the OSPF protocol. Security measures 1909 applied to the native OSPF (refer [SEC-OSPF]) are directly 1910 applicable to the TE LSAs described in the document. Discussed 1911 below are the security considerations in processing TE LSAs. 1913 Secure communication between OSPF-TE nodes has a number of 1914 components. Authorization, authentication, integrity and 1915 confidentiality. Authorization refers to whether a particular 1916 OSPF-TE node is authorized to receive or propagate the TE LSAs 1917 to its neighbors. Failing the authorization process might 1918 indicate a resource theft attempt or unauthorized resource 1919 advertisement. In either case, the OSPF-TE nodes should take 1920 proper measures to audit/log such attempts so as to alert the 1921 administrator to take necessary action. OSPF-TE nodes may refuse 1922 to communicate with the neighboring nodes that fail to prompt 1923 the required credentials. 1925 Authentication refers to confirming the identity of an originator 1926 for the datagrams received from the originator. Lack of strong 1927 credentials for authentication of OSPF-TE LSAs can seriously 1928 jeopardize the TE service rendered by the network. A consequence 1929 of not authenticating a neighbor would be that an attacker could 1930 spoof the identity of a "legitimate" OSPF-TE node and manipulate 1931 the state, and the TE database including the topology and 1932 metrics collected. This could potentially lead to 1933 denial-of-service on the TE network. Another consequence of not 1934 authenticating is that an attacker could pose as OSPF-TE neighbor 1935 and respond in a manner that would divert TE data to the attacker. 1937 Integrity is required to ensure that an OSPF-TE message has not 1938 been accidentally or maliciously altered or destroyed. The result 1939 of a lack of data integrity enforcement in an untrusted environment 1940 could be that an imposter will alter the messages sent by a 1941 legitimate adjacent neighbor and bring the OSPF-TE on a node and 1942 the whole network to a halt or cause a denial of service for the 1943 TE circuit paths effected by the alteration. 1945 Confidentiality of MIDCOM messages ensure that the TE LSAs are 1946 accessible only to the authorized entities. When OSPF-TE is 1947 deployed in an untrusted environment, lack of confidentiality will 1948 allow an intruder to perform traffic flow analysis and snoop the 1949 TE control network to monitor the traffic metrics and the rate at 1950 which circuit paths are being setup and torn-down. The intruder 1951 could cannibalize a lesser secure OSPF-TE node and destroy or 1952 compromise the state and TE-LDSB on the node. Needless to say, the 1953 least secure OSPF-TE will become the achilles heel and make the TE 1954 network vulnerable to security attacks. 1956 15. Normative References 1958 [IETF-STD] Bradner, S., "Key words for use in RFCs to indicate 1959 Requirement Levels", BCP 14, RFC 2119, March 1997. 1961 [RFC 1700] J. Reynolds and J. Postel, "Assigned Numbers", 1962 RFC 1700 1964 [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for 1965 writing an IANA Considerations Section in RFCs", 1966 BCP 26, RFC 2434, October 1998. 1968 [MPLS-TE] Awduche, D., et al, "Requirements for Traffic 1969 Engineering Over MPLS," RFC 2702, September 1999. 1971 [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. 1973 [SEC-OSPF] Murphy, S., Badger, M., and B. Wellington, "OSPF with 1974 Digital Signatures", RFC 2154, June 1997 1976 [FLOOD-OPT] Zinin, A. and M. Shand, "Flooding Optimizations in 1977 link-state routing protocols", work in progress, 1978 1980 15. Informative References 1982 [GMPLS-TE] P.A. Smith et. al, "Generalized MPLS - Signaling 1983 Functional Description", work in progress, 1984 draft-ietf-mpls-generalized-signaling-09.txt 1986 [RSVP-TE] Awduche, D., L. Berger, D. Gan, T. Li, V. Srinivasan, 1987 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1988 Tunnels", RFC3209, IETF, December 2001 1990 [CR-LDP] Jamoussi, B. et al, "Constraint-Based LSP Setup 1991 using LDP", draft-ietf-mpls-cr-ldp-06.txt, 1992 Work in Progress. 1994 [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, 1995 March 1994. 1997 [NSSA] Coltun, R., V. Fuller and P. Murphy, "The OSPF NSSA 1998 Option", draft-ietf-ospf-nssa-update-11.txt, Work in 1999 Progress. 2001 [OPAQUE] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, 2002 July 1998. 2004 [OPQLSA-TE] Katz, D., D. Yeung and K. Kompella, "Traffic 2005 Engineering Extensions to OSPF", work in progress, 2006 2008 [OPQLSA-GMPLS] Kompella, K., Y. Rekhter, A. Banerjee, J. Drake, 2009 G. Bernstein, D. Fedyk, E. Mannie, D. Saha and 2010 V. Sharma, "OSPF Extensions in Support of Generalized 2011 MPLS", , 2012 work in progress. 2014 Authors' Addresses 2016 Pyda Srisuresh 2017 Kuokoa Networks, Inc. 2018 475 Potrero Avenue 2019 Sunnyvale, CA 94085 2020 U.S.A. 2021 EMail: srisuresh@yahoo.com 2023 Paul Joseph 2024 Force10 Networks 2025 1440 McCarthy Boulevard 2026 Milpitas, CA 95035 2027 U.S.A. 2028 EMail: pjoseph@Force10Networks.com