idnits 2.17.1 draft-ietf-ccamp-lsp-hierarchy-bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1359. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1332. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1345. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4206, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3477, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3477, updated by this document, for RFC5378 checks: 2000-11-08) (Using the creation date from RFC4206, updated by this document, for RFC5378 checks: 2000-07-10) -- 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 (October 15, 2008) is 5665 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Shiomoto (Ed.) 2 Internet Draft NTT 3 Updates: 3477, 4206 A. Farrel (Ed.) 4 Proposed Category: Proposed Standard Old Dog Consulting 5 Created: October 15, 2008 6 Expires: April 15, 2008 8 Procedures for Dynamically Signaled 9 Hierarchical Label Switched Paths 11 draft-ietf-ccamp-lsp-hierarchy-bis-04.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Abstract 38 Label Switched Paths (LSPs) set up in Multiprotocol Label Switching 39 (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links 40 for carrying traffic in those networks or in other (client) networks. 42 Protocol extensions already exist to facilitate the establishment of 43 an LSP as a numbered traffic engineering (TE) link within the same 44 instance of the routing as is used to advertise the links that it 45 traverses creating a Forwarding Adjacency (FA). This document extends 46 those mechanisms to support unnumbered FAs. 48 This document also defines how to indicate that an LSP should be 49 advertised as a link in another instance of the routing protocol (for 50 instance in a client network) and which instance to use. Furthermore, 51 mechanisms are defined to indicate when an LSP is to be used as a 52 component link of a TE link bundle and to identify the bundle. 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in [RFC2119]. 60 Table of Contents 62 1. Introduction and Problem Statement ............................. 1 63 1.1. Background ................................................... 64 1.1.1. Hierarchical LSPs .......................................... 65 1.1.2. LSP Stitching Segments ..................................... 66 1.1.3. Private Links .............................................. 67 1.1.4. Routing Adjacencies ........................................ 68 1.1.5. Forwarding Adjacencies ..................................... 69 1.1.5. Client/Server Networks ..................................... 70 1.1.6. Link Bundles ............................................... 71 1.2. Desired Function ............................................. 72 1.3. Existing Mechanisms .......................................... 73 1.3.1. LSP Setup .................................................. 74 1.3.2. Routing Adjacency Establishment and Link State Advertisement 75 1.3.3. TE Link Advertisement ...................................... 76 1.3.4. Configuration and Management Techniques .................... 77 1.3.5. Signaled Unnumbered FAs .................................... 78 1.3.6. Establishing Numbered FAs Through Signaling and Routing .... 79 1.4. Overview of Required Extensions .............................. 80 1.4.1. Efficient Signaling of Numbered FAs ........................ 81 1.4.2. LSPs for Use as Private Links .............................. 82 1.4.3. Signaling an LSP For use in Another Network ................ 83 1.4.4. Signaling an LSP for Use in a Link Bundle .................. 84 1.4.5. Support for IPv4 and IPv6 .................................. 85 1.4.6. Backward Compatibility ..................................... 86 2. Overview of Solution ........................................... 87 2.1. Common Approach for Numbered and Unnumbered Links ............ 88 2.2. LSP Usage Indication ......................................... 89 2.3. IGP Instance Identification .................................. 90 2.4. Link Bundle Identification ................................... 91 2.5. Backward Compatibility ....................................... 92 3. Mechanisms and Protocol Extensions ............................. 93 3.1. LSP_TUNNEL_INTERFACE_ID Object ............................... 94 3.1.1. Existing Definition and Usage .............................. 95 3.1.2. Unnumbered Links with Action Identification ................ 96 3.1.3. IPv4 Numbered Links with Action Identification ............. 97 3.1.4. IPv6 Numbered Links with Action Identification ............. 98 3.2. Target IGP Identification TLV ................................ 99 3.3. Component Link Identification TLV ............................ 100 3.3.1. Unnumbered Component Link Identification ................... 101 3.3.2. Numbered Component Link Identification ..................... 103 3.4. Link State Advertisement ..................................... 104 3.5. Message Formats .............................................. 105 3.6. Error Cases and Non-Acceptance ............................... 106 3.7. Backward Compatibility ....................................... 107 4. Security Considerations ........................................ 108 5. IANA Considerations ............................................ 109 5.1. New Class Types .............................................. 110 5.2. Hierarchy Actions ............................................ 111 5.3. New Error Codes and Error Values ............................. 112 6. Acknowledgements ............................................... 113 7. References ..................................................... 114 7.1. Normative References ......................................... 115 7.2. Informative References ....................................... 116 8. Editors' Addresses ............................................. 117 9. Authors' Addresses ............................................. 119 1. Introduction and Problem Statement 121 [RFC4206] defines how to set up Label Switched Paths (LSPs) in 122 Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering 123 (TE) networks to be used as hierarchical Label Switched Paths 124 (H-LSPs). 126 [RFC4201] describes how to collect together TE links between the same 127 pair of nodes and advertise them as a single TE link called a link 128 bundle. 130 [RFC5212] presents a framework and requirements for multilayer 131 networks (MLNs). This includes the establishment of an LSP in a 132 server network that is used as a link in a client network. 134 As set out later in this document, issues have been identified during 135 deployment with how LSPs are established and made available for use 136 as H-LSPs or as components of a link bundle and advertised 137 appropriately in an interior gateway protocol (IGP). These issues 138 relate to coordinating between the LSP's end points the use to which 139 the LSP is put. 141 This document gives some basic background, describes the 142 requirements, sets out the mechanisms that already exist, and 143 enumerates the protocols extensions and mechanisms that are needed. 144 The document goes on to present the necessary additions to the GMPLS 145 protocols. 147 1.1. Background 149 1.1.1. Hierarchical LSPs 151 [RFC3031] describes how Multiprotocol Label Switching (MPLS) labels 152 may be stacked so that LSPs may be nested with one LSP running 153 through another. This concept of H-LSPs is formalized in [RFC4206] 154 with a set of protocol mechanisms for the establishment of an H-LSP 155 that can carry one or more other LSPs. 157 [RFC4206] goes on to explain that an H-LSP may carry other LSPs only 158 according to their switching types. This is a function of the way 159 labels are carried. In a packet switch capable (PSC) network, the 160 H-LSP can carry other PSC LSPs using the MPLS label stack. In non- 161 packet networks where the label is implicit, label stacks are not 162 possible and rely on the ability to nest switching technologies. 163 Thus, for example, a lambda switch capable (LSC) LSP can carry a time 164 division multiplexing (TDM) LSP, but cannot carry another LSC LSP. 166 Signaling mechanisms defined in [RFC4206] allow an H-LSP to be 167 treated as a single hop in the path of another LSP (i.e., one hop of 168 the LSP carried by the H-LSP). This mechanism is known as "non- 169 adjacent signaling." 171 1.1.2. LSP Stitching Segments 173 LSP stitching is defined in [RFC5150]. It enables LSPs of the same 174 switching type to be included (stitched) as hops in an end-to-end 175 LSP. The stitching LSP (S-LSP) is used in the control plane in the 176 same way as an H-LSP, but in the data plane the LSPs are stitched so 177 that there is no label stacking or nesting of technologies. Thus, an 178 S-LSP must be of the same switching technology as the end-to-end LSP 179 that it facilitates. 181 1.1.3. Private Links 183 An H-LSP or S-LSP can be used as a private link. Such links are known 184 by their end-points, but are not more widely known. They can be used 185 to carry traffic between the end-points, but are not usually used to 186 carry traffic that is going beyond the egress of the LSP. 188 1.1.4. Routing Adjacencies 190 A routing adjacency is formed between two IGP-speakers that are 191 logically adjacent. In this sense, 'logically adjacent' means that 192 the routers have a protocol tunnel between them through which they 193 can exchange routing protocol messages. The tunnel is also usually 194 available for carrying IP data although a distinction should be made 195 in GMPLS networks between data plane traffic and control plane 196 traffic. 198 Routing adjacencies for forwarding data traffic are only relevant in 199 PSC networks (i.e., IP/MPLS networks). 201 1.1.5. Forwarding Adjacencies 203 A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link 204 created from an LSP and advertised in the same instance of the 205 control plane that advertises the TE links from which the LSP is 206 constructed. The LSP itself is called an FA-LSP. 208 Thus, an H-LSP or S-LSP may form an FA such that it is advertised as 209 a TE link in the same instance of the routing protocol as was used to 210 advertise the TE links that the LSP traverses. 212 As observed in [RFC4206] the nodes at the ends of an FA would not 213 usually have a routing adjacency. 215 1.1.5. Client/Server Networks 217 An LSP may be created in one network and used as a link (sometimes 218 called a virtual link) in another networks [RFC5212]. In this case 219 the networks are often referred to as server and client networks 220 respectively. 222 The server network LSP is used as an H-LSP or an S-LSP as described 223 above, but does not form an FA because the client and server networks 224 run separate instances of the control plane routing protocols. 226 The virtual link may be used in the client network as a private link 227 or may be advertised in the client network IGP. Additionally, the 228 link may be used in the client network to form a routing adjacency 229 and/or as a TE link. 231 1.1.6. Link Bundles 233 [RFC4201] recognizes that a pair of adjacent routers may have a large 234 number of TE links that run between them. This can be a considerable 235 burden to the operator who may need to configure them, and to the IGP 236 that must distribute information about each of them. A TE link bundle 237 is defined by [RFC4201] as a TE link that is advertised as an 238 aggregate of multiple TE links that could have been advertised in 239 their own right. All TE links that are collected into a TE link 240 bundle have the same TE properties. 242 Thus, a link bundle is a shorthand that improves the scaling 243 properties of the network. 245 Since a TE link may, itself, be an LSP (either an FA or a virtual 246 link), a link bundle may be constructed from FA-LSPs or virtual 247 links. 249 1.2. Desired Function 251 It should be possible to signal an LSP and automatically coordinate 252 its use and advertisement in any of the ways described in Section 1.3 253 with minimum involvement from an operator. The mechanisms used should 254 be applicable to numbered and unnumbered links, and should not 255 require implementation complexities. 257 1.3. Existing Mechanisms 259 This section briefly introduces existing protocol mechanisms used to 260 satisfy the desired function described in Section 1.2. 262 1.3.1. LSP Setup 264 Both unidirectional LSPs and bidirectional LSPs are signaled from the 265 ingress label switching router (LSR) to the egress LSR. That is, the 266 ingress LSR is the initiator, and the egress learns about the LSP 267 through the signaling protocol [RFC3209], [RFC3473]. 269 1.3.2. Routing Adjacency Establishment and Link State Advertisement 271 Although hosts can discover routers (for example through ICMP 272 [RFC1256]), routing adjacencies are usually configured at both ends 273 of the adjacency. This requires that each router know the identity 274 of the router at the other end of the link connecting the routers, 275 and know that the IGP is to be run on this link. 277 Once a routing adjacency has been established, a pair of routers may 278 use the IGP to share information about the links available for 279 carrying IP traffic in the network. 281 Suitable routing protocols are OSPF version 2 [RFC2328], OSPF version 282 3 [RFC5340], and IS-IS [RFC1195]. 284 1.3.3. TE Link Advertisement 286 Extensions have been made to IGPs to advertise TE link properties 287 ([RFC3630], [RFC5329], [RFC5305], [RFC5308], and [ISIS-IPV6-TE]) and 288 also to advertise link properties in GMPLS networks ([RFC4202], 289 [RFC4203], and [RFC5307]). 291 TE link advertisement can be performed by the same instance of the 292 IGP as is used for normal link state advertisement, or can use a 293 separate instance. Furthermore, the ends of a TE link advertised in 294 an IGP do not need to form a routing adjacency. This is particularly 295 the case with FAs as described in Section 1.1.5. 297 1.3.4. Configuration and Management Techniques 299 LSPs are usually created as the result of a management action. This 300 is true even when a control plane is used ? the management action is 301 a request to the control plane to signal the LSP. 303 If the LSP is to be used as an H-LSP or S-LSP, management commands 304 can be used to install the LSP as a link. The link must be defined, 305 interface identifiers allocated, and the end points configured to 306 know about (and advertise, if necessary) the new link. 308 If the LSP is to be used as part of a link bundle, the operator must 309 decide which bundle it forms part of and ensure that that information 310 is configured at the ingress and egress, along with the necessary 311 interface identifiers. 313 These mechanisms are perfectly functional and quite common in MLNs, 314 but require configuration coordination and additional management. 315 They are open to user error and misconfiguration that might result in 316 the LSP not being used (a waste of resources) or the LSP being made 317 available in the wrong way with some impact on traffic engineering. 319 1.3.5. Signaled Unnumbered FAs 321 [RFC3477] describes how to establish an LSP and to make it available 322 automatically as a TE link in the same instance of the routing 323 protocol as advertises the TE links it traverses, using IPv4-based 324 unnumbered identifiers to identify the new TE link. That is, 325 [RFC3477] describes how to create an unnumbered FA. 327 The mechanism, as defined in Section 3 of [RFC3477], is briefly as 328 follows: 330 - The ingress of the LSP signals the LSP as normal using a Path 331 message, and includes an LSP_TUNNEL_INTERFACE_ID object. The 332 LSP_TUNNEL_INTERFACE_ID object identifies: 333 - The sender's LSR Router ID 334 - The sender's interface ID for the TE link being created 336 - The egress of the LSP responds as normal to accept the LSP and set 337 it up, and includes an LSP_TUNNEL_INTERFACE_ID object. The 338 LSP_TUNNEL_INTERFACE_ID object identifies: 339 - The egress's LSR Router ID 340 - The egress's interface ID for the TE link being created. 342 - Following the exchange of the Path and Resv messages, both the 343 ingress and the egress know that the LSP is to be advertised as a 344 TE link in the same instance of the routing protocol as was used to 345 advertise the TE links that it traverses, and also know the 346 unnumbered interface identifiers to use in the advertisement. 348 [RFC3477] does not include mechanisms to support IPv6-based 349 unnumbered identifiers, nor IPv4 or IPv6 numbered identifiers. 351 1.3.6. Establishing Numbered FAs Through Signaling and Routing 353 [RFC4206] describes procedures to establish an LSP and to make it 354 available automatically as a TE link that is identified using IPv4 355 addresses in the same instance of the routing protocol as advertised 356 the TE links it traverses (that is, as a numbered FA). 358 The mechanism, as defined in [RFC4206], is briefly as follows: 360 - The ingress of the LSP signals the LSP as normal using a Path 361 message, and sets the IPv4 tunnel sender address to the IP address 362 it will use to identify its interface for the TE link being 363 created. This is one address from a /31 pair. 365 - The egress of the LSP responds as normal to accept the LSP and set 366 it up. It infers the address that it must assign to identify its 367 interface for the TE link being created as the partner address of 368 the /31 pair. 370 - The ingress decides whether the LSP is to be advertised as a TE 371 link (i.e., as an FA). If so, it advertises the link in the IGP 372 in the usual way. 374 - If the link is unidirectional, nothing more needs to be done. If 375 the link is bidirectional, the egress must also advertise the link, 376 but it does not know that advertisement is required as there is no 377 indication in the signaling messages. 379 - When the ingress's advertisement of the link is received by the 380 egress it must check to see whether it is the egress of the LSP 381 that formed the link. Typically this means: 382 - Check to see if the link advertisement is new 383 - Check to see if the Link-ID address in the received advertisement 384 matches its own TE Router ID 385 - Checks the advertising router ID from the advertisement against 386 the ingress address of each LSPs for which it is the egress 387 - Deduce the LSP that has been advertised as a TE link and issue 388 the corresponding advertisement for the reverse direction. 390 It is possible that some reduction in processing can be achieved by 391 mapping based on the /31 pairing, but nevertheless, there is a fair 392 amount of processing required, and this does not scale well in large 393 networks. 395 No explanation is provided in [RFC4206] of how to create numbered 396 IPv6 FAs. 398 Note that this document deprecates this procedure as explained in 399 Section 1.4.6. 401 1.4. Overview of Required Extensions 403 This section provides a brief outline of the required protocol 404 extensions. 406 1.4.1. Efficient Signaling of Numbered FAs 408 The mechanism described in Section 1.3.6. is inefficient. The egress 409 must wait until it receives an advertisement from the ingress before 410 it knows that the LSP is to be installed as a TE link and advertised 411 as an FA. Further, it must parse all received advertisements to 412 determine if any is the trigger for it to advertise an FA. 414 An efficient signaling mechanism is required so that the egress is 415 informed by the ingress during LSP establishment. 417 1.4.2. LSPs for Use as Private Links 419 There is currently no mechanism by which an ingress can indicate that 420 an LSP is set up for use as a private link. Any attempt to make it 421 a link would currently cause it to be advertised as an FA. 423 A signaling mechanism is needed to identify the use to which an LSP 424 is to be put. 426 1.4.3. Signaling an LSP For use in Another Network 428 The existing signaling/routing mechanisms are designed for use in the 429 creation of FAs. That is, the TE link created is advertised in the 430 single IGP instance. 432 The numbered TE link mechanism (Section 1.3.6) could, in theory, be 433 used in an MLN with multiple IGP instances if the addressing model is 434 kept consistent across the networks, and if the egress searches all 435 advertisements in all IGP instances. But this is complex and does not 436 work for unnumbered interfaces. 438 A signaling mechanism is required to indicate in which IGP instance 439 the TE link should be advertised. 441 1.4.4. Signaling an LSP for Use in a Link Bundle 443 A signaling mechanism is required to indicate that an LSP is intended 444 to form a component link of a link bundle, and to identify the 445 bundle and the IGP instance in which the bundle is advertised. 447 1.4.5. Support for IPv4 and IPv6 449 The protocol mechanisms must support IPv4 and IPv6 numbered and 450 unnumbered TE links. 452 1.4.6. Backward Compatibility 454 The existing protocol mechanisms for unnumbered FAs as defined in 455 [RFC4206] and [RFC3477] must continue to be supported, and new 456 mechanisms must be devised such that their introduction will not 457 break existing implementations or deployments. 459 Note that an informal survey in the CCAMP working group established 460 that there are no significant deployments of numbered FAs established 461 using the technique described in [RFC4206] and set out in Section 462 1.3.6. Therefore, this document deprecates this procedure. 464 2. Overview of Solution 466 This section provides an overview of the mechanisms and protocol 467 extensions defined in this document. Details are presented in Section 468 3. 470 2.1. Common Approach for Numbered and Unnumbered Links 472 The LSP_TUNNEL_INTERFACE_ID object [RFC3477] is extended for use for 473 all H-LSPs and S-LSPs whether they form numbered or unnumbered, IPv4 474 or IPv6 links. Different class-types of the object identify the 475 address type for which it applies. 477 2.2. LSP Usage Indication 479 The LSP_TUNNEL_INTERFACE_ID object is given flags in a new Actions 480 field to say how the LSP is to be used. The following categories are 481 supported: 482 - LSP is used as an advertised TE link 483 - LSP is used to form a routing adjacency 484 - LSP is used to form an advertised TE link and a routing adjacency 485 - LSP forms a private link and is not advertised 487 2.3. IGP Instance Identification 489 An optional TLV is added to the LSP_TUNNEL_INTERFACE_ID object to 490 identify the IGP instance into which the link formed by the LSP is to 491 be advertised. If the TLV is absent and the link is to be advertised 492 as indicated by the Actions field, the link is advertised in the same 493 instance of the IGP as was used to advertise the TE links it 494 traverses. 496 2.4. Link Bundle Identification 498 When an LSP is to be used as a component link of a link bundle, the 499 LSP_TUNNEL_INTERFACE_ID object refers to the bundle indicating how 500 the bundle is addressed and used, and a new TLV indicates the 501 component link identifier for the link that the LSP creates. 503 2.5. Backward Compatibility 505 Backward compatibility has three aspects. 507 - Existing mechanisms for unnumbered FAs described in [RFC3477] and 508 [RFC4206] must continue to work, so that ingress nodes do not have 509 to be updated when egresses are updated. 511 - Existing mechanisms for establishing numbered FAs described in 512 [RFC4206] are safely deprecated by this document as they are not 513 significantly deployed. 515 - New mechanisms must be gracefully rejected by existing egress 516 implementations so that egress nodes do not have to be updated when 517 ingresses are updated. 519 3. Mechanisms and Protocol Extensions 521 This section defines protocol mechanisms and extensions to achieve 522 the function described in the previous section. 524 3.1. LSP_TUNNEL_INTERFACE_ID Object 526 The principal signaling protocol element used to achieve all of the 527 required functions is the LSP_TUNNEL_INTERFACE_ID object defined in 528 [RFC3477]. The existing definition and usage continues to be 529 supported as described in the next section. Subsequent sections 530 describe new variants of the object (denoted by new Class Types), and 531 additional information carried in the object by means of extensions. 533 3.1.1. Existing Definition and Usage 535 This document does not deprecate the mechanisms defined in [RFC3477] 536 and [RFC4206]. Those procedures must continue to operate as described 537 in Section 3.7. 539 That means that the LSP_TUNNEL_INTERFACE_ID object with Class Type 1 540 remains unchanged, and can be used to establish an LSP that will be 541 advertised as an unnumbered TE link in the same instance of the IGP 542 as was used to advertise the TE links that the LSP traverses. That 543 is, as an FA. The procedure is unchanged and operates as summarized 544 in Section 1.3.5. 546 [RFC3477] does not make any suggestions about where in Path or Resv 547 messages the LSP_TUNNEL_INTERFACE_ID object should be placed. See 548 Section 3.5 for recommended placement of this object in new 549 implementations. 551 3.1.2. Unnumbered Links with Action Identification 553 A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined 554 to carry an unnumbered interface identifier and to indicate into 555 which instance of the IGP the consequent TE link should be 556 advertised. This does not deprecate the use of C-Type 1. 558 The format of the object is as shown below. 560 C-NUM = 193, C-Type = 4 (TBD by IANA) 562 0 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | LSR's Router ID | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Interface ID (32 bits) | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Actions | Reserved | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 ~ TLVs ~ 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 LSR's Router ID 576 Unchanged from the definition in [RFC3477]. 578 Interface ID 580 Unchanged from the definition in [RFC3477]. 582 Actions 584 This field specifies how the LSP that is being set up is to be 585 treated. 587 The field has meaning only on a Path message. On a Resv message 588 the field SHOULD be set to reflect the value received on the 589 corresponding Path message, and MUST be ignored on receipt. 591 The field is composed of bit flags as follows: 593 -+-+-+-+-+-+-+- 594 | | | |H|B|R|T|P| 595 -+-+-+-+-+-+-+- 597 P-flag (Private) 598 0 means that the LSP is to be advertised as a link according 599 to the settings of the other flags. 600 1 means the LSP is to form a private link and is not to be 601 advertised in the IGP, but is to be used according to the 602 settings of the other flags. 604 T-flag (TE link) 605 0 means that the LSP is to be used as a TE link. 606 1 means that the LSP is not to be used as a TE link. It may 607 still be used as an IP link providing a routing adjacency as 608 defined by the R-flag. 610 R-flag (routing adjacency) 611 0 means that the link is not to be used as a routing 612 adjacency. 613 1 means that the link is to be used to form a routing 614 adjacency. 616 B-flag (bundle) 617 0 means that the LSP will not form part of a link bundle. 618 1 means that the LSP will form part of a bundle. See Section 619 3.3 for more details. 621 H-flag (hierarchy/stitching) 622 The use of an LSP as an H-LSP or as an S-LSP is usually 623 implicit from the network technologies of the networks and the 624 LSP, but this is not always the case (for example, in PSC 625 networks). 626 0 means LSP to be used as a hierarchical LSP. 627 1 means LSP to be used as a stitching segment. 629 Other bits are reserved for future use. They MUST be set to zero 630 on transmission and SHOULD be ignored on receipt. 632 Note that all defined bit flags have meaning at the same time. 633 An LSP that is to form an FA would carry the Actions field set 634 to 0x00. That is: 635 P=0 (advertised) 636 T=0 (TE link) 637 R=0 (not a routing adjacency) 638 B=0 (not a bundle) 639 H=0 (hierarchical LSP) 641 Reserved 643 The Reserved bits MUST be set to zero on transmission and SHOULD 644 be ignored on receipt. 646 TLVs 648 Zero, one, or more TLVs may be present. Each TLV is encoded as 649 follows: 651 Type (16 bits) 653 The identifier of the TLV. Two type values are defined in 654 this document: 656 1 IGP Instance Identifier TLV 657 2 Component Link Identifier TLV 659 Length (16 bits) 661 Indicates the total length of the TLV in octets. I.e., 662 4 + the length of the value field in octets. A value field 663 whose length is not a multiple of four MUST be zero-padded 664 so that the TLV is four-octet aligned. 666 Value 668 The data for the TLV padded as described above. 670 If this object is carried in a Path message it is known as the 671 "Forward Interface ID" for the LSP that is being set up. On a Resv 672 message the object is known as the "Reverse Interface ID" for the 673 LSP. 675 3.1.3. IPv4 Numbered Links with Action Identification 677 A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined 678 to carry an IPv4 numbered interface address. 680 The format of the object is as shown below. 682 C-NUM = 193, C-Type = 2 (TBD by IANA) 684 0 1 2 3 685 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 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | IPv4 Interface Address | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Actions | Reserved | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 ~ TLVs ~ 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 IPv4 Interface Address 696 The address assigned to the interface the sender applies to 697 this LSP. 699 Actions 701 See Section 3.1.2. 703 Reserved 705 See Section 3.1.2. 707 TLVs 709 See Section 3.1.2. 711 If this object is carried in a Path message it is known as the 712 "Forward Interface ID" for the LSP that is being set up. On a Resv 713 message the object is known as the "Reverse Interface ID" for the 714 LSP. 716 3.1.4. IPv6 Numbered Links with Action Identification 718 A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined 719 to carry an IPv6 numbered interface address. 721 The format of the object is as shown below. 723 C-NUM = 193, C-Type = 3 (TBD by IANA) 725 0 1 2 3 726 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 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | IPv6 Interface Address (128 bits) | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | IPv6 Interface Address (continued) | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 | IPv6 Interface Address (continued) | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | IPv6 Interface Address (continued) | 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 | Actions | Reserved | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 ~ TLVs ~ 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 IPv6 Interface Address 743 The address assigned to the interface the sender applies to 744 this LSP. 746 Actions 748 See Section 3.1.2. 750 Reserved 752 See Section 3.1.2. 754 TLVs 756 See Section 3.1.2. 758 If this object is carried in a Path message it is known as the 759 "Forward Interface ID" for the LSP that is being set up. On a Resv 760 message the object is known as the "Reverse Interface ID" for the 761 LSP. 763 3.2. Target IGP Identification TLV 765 If the LSP being set up is to be advertised as a link, the egress 766 needs to know which instance of the IGP it should use to make the 767 advertisement. The default in [RFC4206] and [RFC3477] is that the LSP 768 is advertised as an FA, that is, in the same instance of the IGP as 769 was used to advertise the TE links that the LSP traverses. 771 In order to facilitate an indication from the ingress to the egress 772 of which IGP instance to use, the IGP Identification TLV is defined 773 for inclusion in the new variants of the LSP_TUNNEL_INTERFACE_ID 774 object defined in this document. 776 The TLV has meaning only in a Path message. It SHOULD NOT be included 777 in the LSP_TUNNEL_INTERFACE_ID object in a Resv message and MUST be 778 ignored if found. 780 If the P-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID 781 object in a Path message is clear (i.e., zero), this TLV indicates 782 the IGP instance to use for the advertisement. If the TLV is absent, 783 the same instance of the IGP should be used as is used to advertise 784 the TE links that the LSP traverses. Thus, for an FA, the TLV can be 785 omitted; alternatively, the IGP Instance TLV may be present 786 identifying the IGP instance or carrying the reserved value 787 0xffffffff. 789 If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID 790 object in a Resv message is set (i.e., one) indicating that the LSP 791 is not to be advertised as a link, this TLV SHOULD NOT be present and 792 MUST be ignored if encountered. 794 The TLV is formatted as described in Section 3.1.2. The Type field 795 has the value 1, and the Value field has the following content: 797 0 1 2 3 798 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 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | IGP Instance Identifier | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 IGP Instance Identifier 805 A 32-bit identifier be assigned to each of the IGP instances 806 within a network, such that ingress and egress LSRs have the same 807 understanding of these numbers. This is a management 808 configuration exercise outside the scope of this document. 810 Note that the IGP Instance Identifier might be mapped from an 811 instance identifier used in the IGP itself (such as section 2.4 812 of [RFC5340] for OSPFv3, or [OSPFv2-MI] for OSPFv2) as a matter 813 of network policy. See [OSPF-TI] for further discussion of this 814 topic in OSPF, and [ISIS-GENAP] for IS-IS. 816 The value 0xffffffff is reserved to mean that the LSP is to be 817 advertised in the same instance of the IGP as was used to 818 advertise the TE links that the LSP traverses. 820 3.3. Component Link Identification TLV 822 If the LSP that is being set up is to be used as a component link in 823 a link bundle [RFC4201], it is necessary to indicate both the 824 identity of the component link and the identity of the link bundle. 825 Furthermore, it is necessary to indicate how the link bundle (that 826 may be automatically created by the establishment of this LSP) is 827 to be used and advertised. 829 If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID 830 object is set, the other fields of the object apply to the link 831 bundle itself. That is, the interface identifiers (numbered or 832 unnumbered) and the other flags in the Actions field apply to the 833 link bundle and not to the component link that the LSP will form. 835 Furthermore, the IGP Instance Identifier TLV (if present) also 836 applies to the link bundle and not to the component link. 838 In order to exchange the identity of the component link, the 839 Component Link Identifier TLVs are introduced as set out in the 840 next sections. If the B-flag is set in the Actions field of the 841 LSP_TUNNEL_INTERFACE_ID object in the Path message, exactly one of 842 these TLVs MUST be present in the LSP_TUNNEL_INTERFACE_ID object in 843 both the Path and Resv objects. 845 3.3.1. Unnumbered Component Link Identification 847 If the component link is to be unnumbered, the Unnumbered Component 848 Link Identifier TLV is used. The TLV is formatted as described in 849 Section 3.1.2. The Type field has the value 2, and the Value field 850 has the following content: 852 0 1 2 3 853 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 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Component Link Identifier | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 Component Link Identifier 860 Unnumbered identifier that is assigned to this component link 861 within the bundle [RFC4201]. 863 3.3.2. IPv4 Numbered Component Link Identification 865 If the component link is identified with an IPv4 address, the IPv4 866 Numbered Component Link Identifier TLV is used. The TLV is formatted 867 as described in Section 3.1.2. The Type field has the value 3, and 868 the Value field has the following content: 870 0 1 2 3 871 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 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | IPv4 Address | 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 IPv4 Address 878 The IPv4 address that is assigned to this component link within 879 the bundle. 881 3.3.2. IPv6 Numbered Component Link Identification 883 If the component link is identified with an IPv6 address, the IPv6 884 Numbered Component Link Identifier TLV is used. The TLV is formatted 885 as described in Section 3.1.2. The Type field has the value 4, and 886 the Value field has the following content: 888 0 1 2 3 889 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 890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 | IPv6 Address | 892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 | IPv6 Address (continued) | 894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 | IPv6 Address (continued) | 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 | IPv6 Address (continued) | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 IPv6 Address 902 The IPv6 address that is assigned to this component link within 903 the bundle. 905 3.4. Link State Advertisement 907 The ingress and egress of an LSP that is set up using the 908 LSP_TUNNEL_INTERFACE_ID object MUST advertise the LSP as agreed in 909 the parameters of the object. 911 Where a TE link is created from the LSP, the TE link SHOULD inherit 912 the TE properties of the LSP as described in [RFC5212] but this 913 process is subject to local and network-wide policy. 915 It is possible that an LSP will be used to offer capacity and 916 connectivity to multiple other networks. In this case, multiple 917 instances of the LSP_TUNNEL_INTERFACE_ID object are permitted in 918 the same Path and Resv messages. Each instance MUST have a different 919 IGP Instance Identifier. 921 Note, however, that a Path or Resv message MUST NOT contain more than 922 one instance of the LSP_TUNNEL_INTERFACE_ID object with C-Type 1, and 923 if such an object is present, all other instances of the 924 LSP_TUNNEL_INTERFACE_ID object MUST include an IGP Instance 925 Identifier TLV with IGP Instance Identifier set to a value that 926 identifies some other IGP instance (in particular, not the value 927 0xffffffff). 929 If the link created from an LSP is advertised in the same IGP 930 instance as was used to advertise the TE links that the LSP 931 traverses, the addresses for the new link and that for the links it 932 is built from MUST come from the same address space. 934 If the link is advertised into another IGP instance the addresses 935 MAY be drawn from overlapping address spaces such that some addresses 936 have different meanings in each IGP instance. 938 In the IGP the TE Router ID of the ingress LSR is taken from the 939 Tunnel Sender Address in the Sender Template object signaled in the 940 Path message. It is assumed that the ingress LSR knows the TE Router 941 ID of the egress LSR since it has chosen to establish an LSP to that 942 LSR and plans to use the LSP as a TE link. 944 The link interface addresses or link interface identifiers for the 945 forward and reverse direction links are taken from the 946 LSP_TUNNEL_INTREFACE_ID object on the Path and Resv messages 947 respectively. 949 When an LSP is torn down through explicit action (a PathTear message 950 or a PathErr message with the Path_State_Removed flag set) the 951 ingress and egress LSRs SHOULD withdraw the advertisement of any link 952 that the LSP created and that was previously advertised. The link 953 state advertisement MAY be retained as a virtual link in another 954 layer network according to network-wide policy [PCE-LAYER]. 956 3.5. Message Formats 958 [RFC3477] does not state where in the Path message or Resv message 959 the LSP_TUNNEL_INTERFACE_ID object should be placed. 961 It is RECOMMENDED that new implementations place the 962 LSP_TUNNEL_INTERFACE_ID objects in the Path message immediately after 963 the SENDER_TSPEC object, and in the Resv message immediately after 964 the FILTER_SPEC object. 966 All implementations SHOULD be able to handle received messages with 967 objects in any order as described in [RFC3209]. 969 3.6. Error Cases and Non-Acceptance 971 Error cases and non-acceptance of new object variants caused by back- 972 level implementations are discussed in Section 3.7. 974 An egress LSR that receives an LSP_TUNNEL_INTERFACE_ID object may 975 have cause to reject the parameters carried in the object for a 976 number of reasons as set out below. In all cases, the egress SHOULD 977 respond with a PathErr message with the error code as indicated in 978 the list below. In most cases the error will arise during LSP setup, 979 no Resv state will exist, and the PathErr will cause Path state to be 980 removed. Where the error arises after the LSP has been successfully 981 set up, the PathErr SHOULD be sent with the Path_State_Removed flag 982 [RFC3473] clear so that the LSP remains operational. 984 The error cases identified are as follows and are reported using the 985 new error code 'LSP Hierarchy Issue' (code 34 TBD by IANA) and the 986 error values listed below. 988 Error | Error | Error-case 989 code | value | 990 ------+-------+------------------------------------------------------ 991 34 1 Link advertisement not supported 992 34 2 Link advertisement not allowed by policy 993 34 3 TE link creation not supported 994 34 4 TE link creation not allowed by policy 995 34 5 Routing adjacency creation not supported 996 34 6 Routing adjacency creation not allowed by policy 997 34 7 Bundle creation not supported 998 34 8 Bundle creation not allowed by policy 999 34 9 Hierarchical LSP not supported 1000 34 10 LSP stitching not supported 1001 34 11 Link address type or family not supported 1002 34 12 IGP instance unknown 1003 34 13 IGP instance advertisement not allowed by policy 1004 34 14 Component link identifier not valid 1005 34 15 Unsupported component link identifier address family 1007 When an ingress LSR receives an LSP_TUNNEL_INTERFACE_ID object on a 1008 Resv message it may need to reject it because of the setting of 1009 certain parameters in the object. Since these reasons all represent 1010 errors rather than negotiable parameter-mismatches, the ingress 1011 SHOULD respond with a PathTear to remove the LSP. The ingress MAY use 1012 a ResvErr with one of the following error codes, allowing the egress 1013 the option to correct the error in a new Resv message, or to tear the 1014 LSP with a PathErr with Path_State_Removed flag set. An ingress that 1015 uses the ResvErr MUST take precautions against a protocol loop where 1016 the egress responds with the same LSP_TUNNEL_INTERFACE_ID object with 1017 the same or different) issues. 1019 Error | Error | Error-case 1020 code | value | 1021 ------+-------+------------------------------------------------------ 1022 34 11 Link address type or family not supported 1023 34 14 Component link identifier not valid 1024 34 15 Unsupported component link identifier address family 1025 34 16 Component link identifier missing 1027 3.7. Backward Compatibility 1029 The LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] has a class 1030 number of 193. According to [RFC2205], this means that a node that 1031 does not understand the object SHOULD ignore the object but forward 1032 it, unexamined and unmodified. Thus there are no issues with transit 1033 LSRs supporting the pre-existing or new Class Types of this object. 1035 A back-level ingress node will behave as follows: 1037 - It will not issue Path messages containing LSP_TUNNEL_INTERFACE_ID 1038 objects with the new Class Types defined in this document. 1040 - It will reject Resv messages containing LSP_TUNNEL_INTERFACE_ID 1041 objects with the new Class Types defined in this document as 1042 described in [RFC2205]. In any case, such a situation would 1043 represent an error by the egress. 1045 - It will continue to use the LSP_TUNNEL_INTERFACE_ID object with 1046 Class Type 1 as defined in [RFC3477]. This behavior is supported by 1047 back-level egresses and by egresses conforming to this document. 1049 - According to an informal survey, there is no significant deployment 1050 of numbered FA establishment following the procedures defined in 1051 [RFC4206] and set out in Section 1.3.6 of this document. It is 1052 therefore safe to assume that back-level ingress LSRs will not use 1053 this mechanism. 1055 A back-level egress node will behave as follows: 1057 - It will continue to support the LSP_TUNNEL_INTERFACE_ID object with 1058 Class Type 1 as defined in [RFC3477] if issued by an ingress. 1060 - It will reject a Path message that carries an 1061 LSP_TUNNEL_INTERFACE_ID object with any of the new Class Types 1062 defined in this document using the procedures of [RFC2205]. This 1063 will inform the ingress that the egress is a back-level LSR. 1065 - It will not expect to use the procedures for numbered FA 1066 establishment defined in [RFC4206] and set out in Section 1.3.6 of 1067 this document. 1069 In summary, the new mechanisms defined in this document do not impact 1070 the method to exchange unnumbered FA information described in 1071 [RFC3477]. That mechanism can be safely used in combination with the 1072 new mechanisms described here and is functionally equivalent to using 1073 the new C-Type indicating an unnumbered link with target IGP instance 1074 identifier with the Target IGP Instance value set to 0xffffffff. 1076 The mechanisms in this document obsolete the method to exchange the 1077 numbered FA information described in [RFC4206] as described in 1078 Section 1.4.6. 1080 4. Security Considerations 1082 [RFC3477] points out that one can argue that the use of the extra 1083 interface identifier that it provides could make an RSVP message 1084 harder to spoof. In that respect, the minor extensions to the 1085 protocol made in this document do not constitute an additional 1086 security risk, but could also be said to improve security. 1088 It should be noted that the ability of an ingress LSR to request that 1089 an egress LSR advertise an LSP as a TE link MUST be subject to 1090 appropriate policy checks at the egress LSR. That is, the egress LSR 1091 MUST NOT automatically accept the word of the ingress unless it is 1092 configured with such a policy. 1094 Further details of security for MPLS-TE and GMPLS can be found in 1095 [GMPLS-SEC]. 1097 5. IANA Considerations 1099 5.1. New Class Types 1101 IANA maintains a registry of RSVP parameters called "Resource 1102 Reservation Protocol (RSVP) Parameters" with a sub-registry called 1103 "Class Names, Class Numbers, and Class Types." There is an entry in 1104 this registry for the LSP_TUNNEL_INTERFACE_ID object defined in 1105 [RFC3477] with one Class Type defined. 1107 IANA is requested to allocate three new Class Types for this object 1108 as defined in Sections 3.1.2, 3.1.3, and 3.1.4 as follows: 1110 C-Type Meaning Reference 1111 --------------------------------------------------------------- 1112 2 IPv4 interface identifier with target [This.doc] 1113 3 IPv6 interface identifier with target [This.doc] 1114 4 Unnumbered interface with target [This.doc] 1116 5.2. Hierarchy Actions 1118 Section 3.1.2 defines an 8-bit flags field in the 1119 LSP_TUNNEL_INTERFACE_ID object. IANA is requested to create a new 1120 sub-registry of the "Generalized Multi-Protocol Label Switching 1121 (GMPLS) Signaling Parameters" registry called the "Hierarchy Actions" 1122 sub-registry as follows: 1124 Registry Name: Hierarchy Actions 1125 Reference: [This.doc] 1126 Registration Procedures: IETF Standards Action RFC 1128 Registry: 1129 Bit Number Hex Value Name Reference 1130 ---------- ----------- ----------------------- --------- 1131 0-2 Unassigned 1132 3 0x10 Hierarchy/stitching (H) [This.doc] 1133 4 0x08 Bundle (B) [This.doc] 1134 5 0x04 Routing adjacency(R) [This.doc] 1135 6 0x02 TE link (T) [This.doc] 1136 7 0x01 Private (P) [This.doc] 1138 5.3. New Error Codes and Error Values 1140 IANA maintains a registry of RSVP error codes and error values as the 1141 "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry 1142 of the "Resource Reservation Protocol (RSVP) Parameters" registry. 1144 IANA is requested to define a new error code with suggested value 34 1145 as below (see also Section 3.6). 1147 Error Code Meaning 1149 34 LSP Hierarchy Issue [This.doc] 1151 IANA is requested to list the following error values for this error 1152 code (see also Section 3.6). 1154 This Error Code has the following globally-defined Error 1155 Value sub-codes: 1157 1 = Link advertisement not supported [This.doc] 1158 2 = Link advertisement not allowed by policy [This.doc] 1159 3 = TE link creation not supported [This.doc] 1160 4 = TE link creation not allowed by policy [This.doc] 1161 5 = Routing adjacency creation not supported [This.doc] 1162 6 = Routing adjacency creation not allowed by policy [This.doc] 1163 7 = Bundle creation not supported [This.doc] 1164 8 = Bundle creation not allowed by policy [This.doc] 1165 9 = Hierarchical LSP not supported [This.doc] 1166 10 = LSP stitching not supported [This.doc] 1167 11 = Link address type or family not supported [This.doc] 1168 12 = IGP instance unknown [This.doc] 1169 13 = IGP instance advertisement not allowed by policy [This.doc] 1170 14 = Component link identifier not valid [This.doc] 1171 15 = Unsupported component link identifier address [This.doc] 1172 family 1173 16 = Component link identifier missing [This.doc] 1175 6. Acknowledgements 1177 The authors would like to thank John Drake, Yakov Rekhter, and Igor 1178 Bryskin for their valuable discussions and comments. 1180 7. References 1182 7.1. Normative References 1184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1185 Requirement Levels", BCP 14, RFC 2119, March 1997. 1187 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 1188 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1189 Functional Specification", RFC 2205, September 1997. 1191 [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol 1192 Label Switching Architecture", RFC 3031, January 2001. 1194 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. 1195 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1196 Tunnels", RFC 3209, December 2001. 1198 [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label 1199 Switching (MPLS) Signaling Resource ReserVation Protocol 1200 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1201 January 2003. 1203 [RFC3477] Kompella, K. and Rekhter, Y., "Signalling Unnumbered Links 1204 in Resource ReSerVation Protocol - Traffic Engineering 1205 (RSVP-TE)", RFC 3477, January 2003. 1207 [RFC4201] Kompella, K., Rekhter, Y., and Berger, L.," Link Bundling 1208 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 1210 [RFC4206] Kompella, K. and Y. Rekhter, "LSP Hierarchy with 1211 Generalized MPLS TE", RFC 4206, October 2005. 1213 [RFC5150] Ayyangar, A., Vasseur, J.P, and Farrel, A., "Label Switched 1214 Path Stitching with Generalized Multiprotocol Label 1215 Switching Traffic Engineering (GMPLS TE)", RFC 5150, 1216 February 2008. 1218 7.2. Informative References 1220 [RFC1195] Callon, R.W., "Use of OSI IS-IS for routing in TCP/IP and 1221 dual environments", RFC 1195, December 1990 1223 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 1224 September 1991. 1226 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1228 [RFC3630] Katz, D., Kompella, K. and Yeung, D., "Traffic Engineering 1229 (TE) Extensions to OSPF Version 2", RFC 3630, September 1230 2003. 1232 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions 1233 in Support of Generalized Multi-Protocol Label Switching 1234 (GMPLS)", RFC 4202, October 2005. 1236 [RFC4203] Kompella, K. Ed. and Y. Rekhter, Ed., "OSPF Extensions in 1237 Support of Generalized Multi-Protocol Label Switching 1238 (GMPLS)", RFC 4203, October 2005. 1240 [RFC5212] Shiomoto, K., et al, "Requirements for GMPLS-Based Multi- 1241 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 1242 2008 1244 [RFC5305] Smit, H. and T. Li, "Intermediate System to Intermediate 1245 System (IS-IS) Extensions for Traffic Engineering (TE)", 1246 RFC 5305, October 2008. 1248 [RFC5307] Kompella, K. Ed. and Y. Rekhter, Ed., "Intermediate System 1249 to Intermediate System (IS-IS) Extensions in Support of 1250 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 1251 5307, October 2008. 1253 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 1254 2008. 1256 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and Lindem, A., 1257 (Ed.), "Traffic Engineering Extensions to OSPF version 3", 1258 RFC 5329, September 2008. 1260 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for 1261 IPv6", RFC 5340, July 2008. 1263 [GMPLS-SEC] Fang, L., et al., "Security Framework for MPLS and GMPLS 1264 Networks", draft-ietf-mpls-mpls-and-gmpls-security- 1265 framework, work in progress. 1267 [ISIS-GENAP] Ginsberg, L., Previdi, S., and Shand, M., "Advertising 1268 Generic Information in IS-IS", draft-ietf-isis-genapp, work 1269 in progress. 1271 [ISIS-IPV6-TE] Harrison, J., Berger, J., and Bartlett, M., "IPv6 1272 Traffic Engineering in IS-IS", draft-ietf-isis-ipv6-te, 1273 work in progress. 1275 [OSPF-TI] Lindem, A., Roy, A., and Mirtorabi, S., "OSPF Transport 1276 Instance Extensions", draft-acee-ospf-transport-instance, 1277 work in progress. 1279 [OSPFv2-MI] Lindem, A., Roy, A., and Mirtorabi, S., "OSPF Multi- 1280 Instance Extensions", draft-acee-ospf-multi-instance, work 1281 in progress. 1283 [PCE-LAYER] Oki, E. (Ed.), "PCC-PCE Communication and PCE Discovery 1284 Requirements for Inter-Layer Traffic Engineering", draft- 1285 ietf-pce-inter-layer-req, (work in progress). 1287 8. Editors' Addresses 1289 Kohei Shiomoto 1290 NTT Network Service Systems Laboratories 1291 3-9-11 Midori 1292 Musashino, Tokyo 180-8585 1293 Japan 1294 Phone: +81 422 59 4402 1295 Email: shiomoto.kohei@lab.ntt.co.jp 1297 Adrian Farrel 1298 Old Dog Consulting 1299 EMail: adrian@olddog.co.uk 1301 9. Authors' Addresses 1303 Richard Rabbat 1304 Google Inc. 1305 1600 Amphitheatre Pkwy 1306 Mountain View, CA 94043 1307 Email: rabbat@alum.mit.edu 1309 Arthi Ayyangar 1310 Juniper Networks 1311 1194 N. Mathilda Ave. 1312 Sunnyvale, CA 94089 1313 United States of America 1314 Email: arthi@juniper.net 1316 Zafar Ali 1317 Cisco Systems, Inc. 1318 2000 Innovation Drive 1319 Kanata, Ontario, K2K 3E8 1320 Canada. 1321 EMail: zali@cisco.com 1323 Intellectual Property Statement 1325 The IETF takes no position regarding the validity or scope of any 1326 Intellectual Property Rights or other rights that might be claimed to 1327 pertain to the implementation or use of the technology described in 1328 this document or the extent to which any license under such rights 1329 might or might not be available; nor does it represent that it has 1330 made any independent effort to identify any such rights. Information 1331 on the procedures with respect to rights in RFC documents can be 1332 found in BCP 78 and BCP 79. 1334 Copies of IPR disclosures made to the IETF Secretariat and any 1335 assurances of licenses to be made available, or the result of an 1336 attempt made to obtain a general license or permission for the use of 1337 such proprietary rights by implementers or users of this 1338 specification can be obtained from the IETF on-line IPR repository at 1339 http://www.ietf.org/ipr. 1341 The IETF invites any interested party to bring to its attention any 1342 copyrights, patents or patent applications, or other proprietary 1343 rights that may cover technology that may be required to implement 1344 this standard. Please address the information to the IETF at 1345 ietf-ipr@ietf.org. 1347 Copyright Statement 1349 Copyright (C) The IETF Trust (2008). This document is subject to the 1350 rights, licenses and restrictions contained in BCP 78, and except as 1351 set forth therein, the authors retain all their rights. 1353 This document and the information contained herein are provided on an 1354 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1355 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1356 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1357 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1358 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1359 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.