idnits 2.17.1 draft-ietf-ccamp-lsp-hierarchy-bis-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 directly say this. It does mention RFC4206 though, so this could be OK. -- 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 and authors 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 19, 2009) is 5301 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 (==), 4 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 19, 2009 6 Expires: April 19, 2010 8 Procedures for Dynamically Signaled 9 Hierarchical Label Switched Paths 11 draft-ietf-ccamp-lsp-hierarchy-bis-07.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 Label Switched Paths (LSPs) set up in Multiprotocol Label Switching 37 (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links 38 to carry traffic in those networks or in other (client) networks. 40 Protocol mechanisms already exist to facilitate the establishment of 41 such LSPs and to bundle TE links to reduce the load on routing 42 protocols. This document defines extensions to those mechanisms to 43 support identifying the use to which such LSPs are to be put and to 44 enable the TE link endpoints to be assigned addresses or unnumbered 45 identifiers during the signaling process. 47 The mechanisms defined in this document deprecates the technique 48 for the signaling of LSPs that are to be used as numbered TE links 49 described in RFC 4206. 51 Conventions used in this document 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in [RFC2119]. 57 Table of Contents 59 1. Introduction and Problem Statement ............................. 3 60 1.1. Background ................................................... 4 61 1.1.1. Hierarchical LSPs .......................................... 4 62 1.1.2. LSP Stitching Segments ..................................... 4 63 1.1.3. Private Links .............................................. 5 64 1.1.4. Routing Adjacencies ........................................ 5 65 1.1.5. Forwarding Adjacencies ..................................... 5 66 1.1.6. Client/Server Networks ..................................... 5 67 1.1.7. Link Bundles ............................................... 6 68 1.2. Desired Function ............................................. 6 69 1.3. Existing Mechanisms .......................................... 6 70 1.3.1. LSP Setup .................................................. 6 71 1.3.2. Routing Adjacency Establishment and Link State Advertisement 6 72 1.3.3. TE Link Advertisement ...................................... 7 73 1.3.4. Configuration and Management Techniques .................... 7 74 1.3.5. Signaled Unnumbered FAs .................................... 7 75 1.3.6. Establishing Numbered FAs Through Signaling and Routing .... 8 76 1.4. Overview of Required Extensions .............................. 9 77 1.4.1. Efficient Signaling of Numbered FAs ........................ 9 78 1.4.2. LSPs for Use as Private Links .............................. 9 79 1.4.3. Signaling an LSP For use in Another Network ............... 10 80 1.4.4. Signaling an LSP for Use in a Link Bundle ................. 10 81 1.4.5. Support for IPv4 and IPv6 ................................. 10 82 1.4.6. Backward Compatibility .................................... 10 83 2. Overview of Solution .......................................... 10 84 2.1. Common Approach for Numbered and Unnumbered Links ........... 10 85 2.2. LSP Usage Indication ........................................ 11 86 2.3. IGP Instance Identification ................................. 11 87 2.4. Link Bundle Identification .................................. 11 88 2.5. Backward Compatibility ...................................... 11 89 3. Mechanisms and Protocol Extensions ............................ 11 90 3.1. LSP_TUNNEL_INTERFACE_ID Object .............................. 12 91 3.1.1. Existing Definition and Usage ............................. 12 92 3.1.2. Unnumbered Links with Action Identification ............... 12 93 3.1.3. IPv4 Numbered Links with Action Identification ............ 15 94 3.1.4. IPv6 Numbered Links with Action Identification ............ 15 95 3.2. Target IGP Identification TLV ............................... 16 96 3.3. Component Link Identification TLV ........................... 17 97 3.3.1. Unnumbered Component Link Identification .................. 18 98 3.3.2. IPv4 Numbered Component Link Identification ............... 18 99 3.3.3. IPv6 Numbered Component Link Identification ............... 19 100 3.4. Link State Advertisement .................................... 19 101 3.5. Message Formats ............................................. 20 102 3.6. Error Cases and Non-Acceptance .............................. 20 103 3.7. Backward Compatibility ...................................... 22 104 4. Security Considerations ....................................... 23 105 5. IANA Considerations ........................................... 23 106 5.1. New Class Types ............................................. 23 107 5.2. Hierarchy Actions ........................................... 23 108 5.3. New Error Codes and Error Values ............................ 24 109 6. Acknowledgements .............................................. 25 110 7. References .................................................... 25 111 7.1. Normative References ........................................ 25 112 7.2. Informative References ...................................... 25 113 8. Editors' Addresses ............................................ 27 114 9. Authors' Addresses ............................................ 27 116 1. Introduction and Problem Statement 118 Traffic Engineering (TE) links in a Multiprotocol Label Switching 119 (MPLS) or a Generalized MPLS (GMPLS) network may be constructed from 120 Label Switched Paths (LSPs) [RFC4206]. Such LSPs are known as 121 hierarchical LSPs (H-LSPs). 123 The LSPs established in one network may be used as TE links in 124 another network, and this is particularly useful when a server layer 125 network (for example, an optical network) provides LSPs for use as TE 126 links in a client network (for example, a packet network). This 127 enables the construction of a multilayer networks (MLN) [RFC5212]. 129 When the number of TE links (created from LSPs or otherwise) between 130 a pair of nodes grows large, it is inefficient to advertise them 131 individually. This may cause scaling issues in configuration and in 132 the routing protocols used to carry the advertisements. The solution 133 (described in [RFC4201]) is to collect the TE links together and to 134 advertise them as a single TE link called a link bundle. 136 These various mechanisms have proved to be very powerful in building 137 dynamically provisioned networks, but, as set out later in this 138 document, several issues have been identified during deployment with 139 how LSPs are established and made available for use as H-LSPs or as 140 components of a link bundle, and with how these links are advertised 141 appropriately in an interior gateway protocol (IGP). These issues 142 relate to coordinating between the LSP's end points the use to which 143 the LSP is put, and the allocation of the identifiers of the end 144 points. 146 This document provides solutions to the issues by defining mechanisms 147 so that the ends of signaled LSPs can exchange information about: 149 - Whether the LSP is an ordinary LSP or an H-LSP. 150 - In which IGP instances the LSP should be advertised as a link. 151 - How the client networks should make use of the new links. 152 - Whether the link should form part of a bundle (and if so, which). 153 - How the link end points should be identified when advertised. 155 This document deprecates one of the mechanisms defined in [RFC4206] 156 for the signaling of LSPs that are to be used as numbered TE links 157 (see Sections 1.3.6 and 1.4.6 for more details), and provides 158 extensions to the other mechanisms defined in [RFC4206] so that the 159 use to which the new LSP is to be put may be indicated during 160 signaling. It also extends the mechanisms defined in [RFC3477] for 161 signaling unnumbered TE links. 163 1.1. Background 165 1.1.1. Hierarchical LSPs 167 [RFC3031] describes how Multiprotocol Label Switching (MPLS) labels 168 may be stacked so that LSPs may be nested with one LSP running 169 through another. This concept of H-LSPs is formalized in [RFC4206] 170 with a set of protocol mechanisms for the establishment of an H-LSP 171 that can carry one or more other LSPs. 173 [RFC4206] goes on to explain that an H-LSP may carry other LSPs only 174 according to their switching types. This is a function of the way 175 labels are carried. In a packet switch capable (PSC) network, the 176 H-LSP can carry other PSC LSPs using the MPLS label stack. In non- 177 packet networks where the label is implicit, label stacks are not 178 possible and rely on the ability to nest switching technologies. 179 Thus, for example, a lambda switch capable (LSC) LSP can carry a time 180 division multiplexing (TDM) LSP, but cannot carry another LSC LSP. 182 Signaling mechanisms defined in [RFC4206] allow an H-LSP to be 183 treated as a single hop in the path of another LSP (i.e., one hop of 184 the LSP carried by the H-LSP). This mechanism is known as "non- 185 adjacent signaling." 187 1.1.2. LSP Stitching Segments 189 LSP stitching is defined in [RFC5150]. It enables LSPs of the same 190 switching type to be included (stitched) as hops in an end-to-end 191 LSP. The stitching LSP (S-LSP) is used in the control plane in the 192 same way as an H-LSP, but in the data plane the LSPs are stitched so 193 that there is no label stacking or nesting of technologies. Thus, an 194 S-LSP must be of the same switching technology as the end-to-end LSP 195 that it facilitates. 197 1.1.3. Private Links 199 An H-LSP or S-LSP can be used as a private link. Such links are known 200 by their end-points, but are not more widely known and are not 201 advertised by routing protocols. They can be used to carry traffic 202 between the end-points, but are not usually used to carry traffic 203 that is going beyond the egress of the LSP. 205 1.1.4. Routing Adjacencies 207 A routing adjacency is formed between two IGP-speakers that are 208 logically adjacent. In this sense, 'logically adjacent' means that 209 the routers have a protocol tunnel between them through which they 210 can exchange routing protocol messages. The tunnel is also usually 211 available for carrying IP data although a distinction should be made 212 in GMPLS networks between data plane traffic and control plane 213 traffic. 215 Routing adjacencies for forwarding data traffic are only relevant in 216 PSC networks (i.e., IP/MPLS networks). 218 1.1.5. Forwarding Adjacencies 220 A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link 221 created from an LSP and advertised in the same instance of the 222 control plane that advertises the TE links from which the LSP is 223 constructed. The LSP itself is called an FA-LSP. 225 Thus, an H-LSP or S-LSP may form an FA such that it is advertised as 226 a TE link in the same instance of the routing protocol as was used to 227 advertise the TE links that the LSP traverses. 229 As observed in [RFC4206] the nodes at the ends of an FA would not 230 usually have a routing adjacency. 232 1.1.6. Client/Server Networks 234 An LSP may be created in one network and used as a link (sometimes 235 called a virtual link) in another networks [RFC5212]. In this case 236 the networks are often referred to as server and client networks 237 respectively. 239 The server network LSP is used as an H-LSP or an S-LSP as described 240 above, but does not form an FA because the client and server networks 241 run separate instances of the control plane routing protocols. 243 The virtual link may be used in the client network as a private link 244 or may be advertised in the client network IGP. Additionally, the 245 link may be used in the client network to form a routing adjacency 246 and/or as a TE link. 248 1.1.7. Link Bundles 250 [RFC4201] recognizes that a pair of adjacent routers may have a large 251 number of TE links that run between them. This can be a considerable 252 burden to the operator who may need to configure them, and to the IGP 253 that must distribute information about each of them. A TE link bundle 254 is defined by [RFC4201] as a TE link that is advertised as an 255 aggregate of multiple TE links that could have been advertised in 256 their own right. All TE links that are collected into a TE link 257 bundle have the same TE properties. 259 Thus, a link bundle is a shorthand that improves the scaling 260 properties of the network. 262 Since a TE link may, itself, be an LSP (either an FA or a virtual 263 link), a link bundle may be constructed from FA-LSPs or virtual 264 links. 266 1.2. Desired Function 268 It should be possible to signal an LSP and automatically coordinate 269 its use and advertisement in any of the ways described in Section 1.3 270 with minimum involvement from an operator. The mechanisms used should 271 be applicable to numbered and unnumbered links, and should not 272 require implementation complexities. 274 1.3. Existing Mechanisms 276 This section briefly introduces existing protocol mechanisms used to 277 satisfy the desired function described in Section 1.2. 279 1.3.1. LSP Setup 281 Both unidirectional LSPs and bidirectional LSPs are signaled from the 282 ingress label switching router (LSR) to the egress LSR. That is, the 283 ingress LSR is the initiator, and the egress learns about the LSP 284 through the signaling protocol [RFC3209], [RFC3473]. 286 1.3.2. Routing Adjacency Establishment and Link State Advertisement 288 Although hosts can discover routers (for example through ICMP 289 [RFC1256]), routing adjacencies are usually configured at both ends 290 of the adjacency. This requires that each router know the identity 291 of the router at the other end of the link connecting the routers, 292 and know that the IGP is to be run on this link. 294 Once a routing adjacency has been established, a pair of routers may 295 use the IGP to share information about the links available for 296 carrying IP traffic in the network. 298 Suitable routing protocols are OSPF version 2 [RFC2328], OSPF version 299 3 [RFC5340], and IS-IS [RFC1195]. 301 1.3.3. TE Link Advertisement 303 Extensions have been made to IGPs to advertise TE link properties 304 ([RFC3630], [RFC5329], [RFC5305], [RFC5308], and [ISIS-IPV6-TE]) and 305 also to advertise link properties in GMPLS networks ([RFC4202], 306 [RFC4203], and [RFC5307]). 308 TE link advertisement can be performed by the same instance of the 309 IGP as is used for normal link state advertisement, or can use a 310 separate instance. Furthermore, the ends of a TE link advertised in 311 an IGP do not need to form a routing adjacency. This is particularly 312 the case with FAs as described in Section 1.1.5. 314 1.3.4. Configuration and Management Techniques 316 LSPs are usually created as the result of a management action. This 317 is true even when a control plane is used: the management action is a 318 request to the control plane to signal the LSP. 320 If the LSP is to be used as an H-LSP or S-LSP, management commands 321 can be used to install the LSP as a link. The link must be defined, 322 interface identifiers allocated, and the end points configured to 323 know about (and advertise, if necessary) the new link. 325 If the LSP is to be used as part of a link bundle, the operator must 326 decide which bundle it forms part of and ensure that information is 327 configured at the ingress and egress, along with the necessary 328 interface identifiers. 330 These mechanisms are perfectly functional and quite common in MLNs, 331 but require configuration coordination and additional management. 332 They are open to user error and misconfiguration that might result in 333 the LSP not being used (a waste of resources) or the LSP being made 334 available in the wrong way with some impact on traffic engineering. 336 1.3.5. Signaled Unnumbered FAs 338 [RFC3477] describes how to establish an LSP and to make it available 339 automatically as a TE link in the same instance of the routing 340 protocol as advertises the TE links it traverses, using IPv4-based 341 unnumbered identifiers to identify the new TE link. That is, 342 [RFC3477] describes how to create an unnumbered FA. 344 The mechanism, as defined in Section 3 of [RFC3477], is briefly as 345 follows: 347 - The ingress of the LSP signals the LSP as normal using a Path 348 message, and includes an LSP_TUNNEL_INTERFACE_ID object. The 349 LSP_TUNNEL_INTERFACE_ID object identifies: 350 - The sender's LSR Router ID 351 - The sender's interface ID for the TE link being created 353 - The egress of the LSP responds as normal to accept the LSP and set 354 it up, and includes an LSP_TUNNEL_INTERFACE_ID object. The 355 LSP_TUNNEL_INTERFACE_ID object identifies: 356 - The egress's LSR Router ID 357 - The egress's interface ID for the TE link being created. 359 - Following the exchange of the Path and Resv messages, both the 360 ingress and the egress know that the LSP is to be advertised as a 361 TE link in the same instance of the routing protocol as was used to 362 advertise the TE links that it traverses, and also know the 363 unnumbered interface identifiers to use in the advertisement. 365 [RFC3477] does not include mechanisms to support IPv6-based 366 unnumbered identifiers, nor IPv4 or IPv6 numbered identifiers. 368 1.3.6. Establishing Numbered FAs Through Signaling and Routing 370 [RFC4206] describes procedures to establish an LSP and to make it 371 available automatically as a TE link that is identified using IPv4 372 addresses in the same instance of the routing protocol as advertised 373 the TE links it traverses (that is, as a numbered FA). 375 The mechanism, as defined in [RFC4206], is briefly as follows: 377 - The ingress of the LSP signals the LSP as normal using a Path 378 message, and sets the IPv4 tunnel sender address to the IP address 379 it will use to identify its interface for the TE link being 380 created. This is one address from a /31 pair. 382 - The egress of the LSP responds as normal to accept the LSP and set 383 it up. It infers the address that it must assign to identify its 384 interface for the TE link being created as the partner address of 385 the /31 pair. 387 - The ingress decides whether the LSP is to be advertised as a TE 388 link (i.e., as an FA). If so, it advertises the link in the IGP 389 in the usual way. 391 - If the link is unidirectional, nothing more needs to be done. If 392 the link is bidirectional, the egress must also advertise the link, 393 but it does not know that advertisement is required as there is no 394 indication in the signaling messages. 396 - When the ingress's advertisement of the link is received by the 397 egress it must check to see whether it is the egress of the LSP 398 that formed the link. Typically this means: 399 - Check to see if the link advertisement is new 400 - Check to see if the Link-ID address in the received advertisement 401 matches its own TE Router ID 402 - Checks the advertising router ID from the advertisement against 403 the ingress address of each LSPs for which it is the egress 404 - Deduce the LSP that has been advertised as a TE link and issue 405 the corresponding advertisement for the reverse direction. 407 It is possible that some reduction in processing can be achieved by 408 mapping based on the /31 pairing, but nevertheless, there is a fair 409 amount of processing required, and this does not scale well in large 410 networks. 412 Note that this document deprecates this procedure as explained in 413 Section 1.4.6. 415 No explanation is provided in [RFC4206] of how to create numbered 416 IPv6 FAs. 418 1.4. Overview of Required Extensions 420 This section provides a brief outline of the required protocol 421 extensions. 423 1.4.1. Efficient Signaling of Numbered FAs 425 The mechanism described in Section 1.3.6. is inefficient. The egress 426 must wait until it receives an advertisement from the ingress before 427 it knows that the LSP is to be installed as a TE link and advertised 428 as an FA. Further, it must parse all received advertisements to 429 determine if any is the trigger for it to advertise an FA. 431 An efficient signaling mechanism is required so that the egress is 432 informed by the ingress during LSP establishment. 434 1.4.2. LSPs for Use as Private Links 436 There is currently no mechanism by which an ingress can indicate that 437 an LSP is set up for use as a private link. Any attempt to make it 438 a link would currently cause it to be advertised as an FA. 440 A signaling mechanism is needed to identify the use to which an LSP 441 is to be put. 443 1.4.3. Signaling an LSP For use in Another Network 445 The existing signaling/routing mechanisms are designed for use in the 446 creation of FAs. That is, the TE link created is advertised in the 447 single IGP instance. 449 The numbered TE link mechanism (Section 1.3.6) could, in theory, be 450 used in an MLN with multiple IGP instances if the addressing model is 451 kept consistent across the networks, and if the egress searches all 452 advertisements in all IGP instances. But this is complex and does not 453 work for unnumbered interfaces. 455 A signaling mechanism is required to indicate in which IGP instance 456 the TE link should be advertised. 458 1.4.4. Signaling an LSP for Use in a Link Bundle 460 A signaling mechanism is required to indicate that an LSP is intended 461 to form a component link of a link bundle, and to identify the 462 bundle and the IGP instance in which the bundle is advertised. 464 1.4.5. Support for IPv4 and IPv6 466 The protocol mechanisms must support IPv4 and IPv6 numbered and 467 unnumbered TE links. 469 1.4.6. Backward Compatibility 471 The existing protocol mechanisms for unnumbered FAs as defined in 472 [RFC4206] and [RFC3477] must continue to be supported, and new 473 mechanisms must be devised such that their introduction will not 474 break existing implementations or deployments. 476 Note that an informal survey in the CCAMP working group established 477 that there are no significant deployments of numbered FAs established 478 using the technique described in [RFC4206] and set out in Section 479 1.3.6. Therefore, this document deprecates this procedure. 481 2. Overview of Solution 483 This section provides an overview of the mechanisms and protocol 484 extensions defined in this document. Details are presented in Section 485 3. 487 2.1. Common Approach for Numbered and Unnumbered Links 489 The LSP_TUNNEL_INTERFACE_ID object [RFC3477] is extended for use for 490 all H-LSPs and S-LSPs whether they form numbered or unnumbered, IPv4 491 or IPv6 links. Different class-types of the object identify the 492 address type for which it applies. 494 2.2. LSP Usage Indication 496 The LSP_TUNNEL_INTERFACE_ID object is given flags in a new Actions 497 field to say how the LSP is to be used. The following categories are 498 supported: 499 - LSP is used as an advertised TE link 500 - LSP is used to form a routing adjacency 501 - LSP is used to form an advertised TE link and a routing adjacency 502 - LSP forms a private link and is not advertised 503 - The LSP is used as part of a link bundle 504 - The LSP is used as a hierarchical LSP or a stitching segment 506 2.3. IGP Instance Identification 508 An optional TLV is added to the LSP_TUNNEL_INTERFACE_ID object to 509 identify the IGP instance into which the link formed by the LSP is to 510 be advertised. If the TLV is absent and the link is to be advertised 511 as indicated by the Actions field, the link is advertised in the same 512 instance of the IGP as was used to advertise the TE links it 513 traverses. 515 2.4. Link Bundle Identification 517 When an LSP is to be used as a component link of a link bundle, the 518 LSP_TUNNEL_INTERFACE_ID object refers to the bundle indicating how 519 the bundle is addressed and used, and a new TLV indicates the 520 component link identifier for the link that the LSP creates. 522 2.5. Backward Compatibility 524 Backward compatibility has three aspects. 526 - Existing mechanisms for unnumbered FAs described in [RFC3477] and 527 [RFC4206] must continue to work, so that ingress nodes do not have 528 to be updated when egresses are updated. 530 - Existing mechanisms for establishing numbered FAs described in 531 [RFC4206] are safely deprecated by this document as they are not 532 significantly deployed. 534 - New mechanisms must be gracefully rejected by existing egress 535 implementations so that egress nodes do not have to be updated when 536 ingresses are updated. 538 3. Mechanisms and Protocol Extensions 540 This section defines protocol mechanisms and extensions to achieve 541 the function described in the previous section. 543 3.1. LSP_TUNNEL_INTERFACE_ID Object 545 The principal signaling protocol element used to achieve all of the 546 required functions is the LSP_TUNNEL_INTERFACE_ID object defined in 547 [RFC3477]. The existing definition and usage continues to be 548 supported as described in the next section. Subsequent sections 549 describe new variants of the object (denoted by new Class Types), and 550 additional information carried in the object by means of extensions. 552 3.1.1. Existing Definition and Usage 554 This document does not deprecate the mechanisms defined in [RFC3477] 555 and [RFC4206]. Those procedures must continue to operate as described 556 in Section 3.7. 558 That means that the LSP_TUNNEL_INTERFACE_ID object with Class Type 1 559 remains unchanged, and can be used to establish an LSP that will be 560 advertised as an unnumbered TE link in the same instance of the IGP 561 as was used to advertise the TE links that the LSP traverses. That 562 is, as an FA. The procedure is unchanged and operates as summarized 563 in Section 1.3.5. 564 [RFC3477] does not make any suggestions about where in Path or Resv 565 messages the LSP_TUNNEL_INTERFACE_ID object should be placed. See 566 Section 3.5 for recommended placement of this object in new 567 implementations. 569 3.1.2. Unnumbered Links with Action Identification 571 A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined 572 to carry an unnumbered interface identifier and to indicate into 573 which instance of the IGP the consequent TE link should be 574 advertised. This does not deprecate the use of C-Type 1. 576 The format of the object is as shown below. 578 C-NUM = 193, C-Type = 4 (TBD by IANA) 580 0 1 2 3 581 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 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | LSR's Router ID | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Interface ID (32 bits) | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Actions | Reserved | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 ~ TLVs ~ 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 LSR's Router ID 594 Unchanged from the definition in [RFC3477]. 596 Interface ID 598 Unchanged from the definition in [RFC3477]. 600 Actions 602 This field specifies how the LSP that is being set up is to be 603 treated. 605 The field has meaning only on a Path message. On a Resv message 606 the field SHOULD be set to reflect the value received on the 607 corresponding Path message, and MUST be ignored on receipt. 609 The field is composed of bit flags as follows: 611 -+-+-+-+-+-+-+- 612 | | | |H|B|R|T|P| 613 -+-+-+-+-+-+-+- 615 P-flag (Private) 616 0 means that the LSP is to be advertised as a link according 617 to the settings of the other flags. 618 1 means the LSP is to form a private link and is not to be 619 advertised in the IGP, but is to be used according to the 620 settings of the other flags. 622 T-flag (TE link) 623 0 means that the LSP is to be used as a TE link. 624 1 means that the LSP is not to be used as a TE link. It may 625 still be used as an IP link providing a routing adjacency as 626 defined by the R-flag. 628 R-flag (routing adjacency) 629 0 means that the link is not to be used as a routing 630 adjacency. 631 1 means that the link is to be used to form a routing 632 adjacency. 634 B-flag (bundle) 635 0 means that the LSP will not form part of a link bundle. 636 1 means that the LSP will form part of a bundle. See Section 637 3.3 for more details. 639 H-flag (hierarchy/stitching) 640 The use of an LSP as an H-LSP or as an S-LSP is usually 641 implicit from the network technologies of the networks and the 642 LSP, but this is not always the case (for example, in PSC 643 networks). 644 0 means LSP to be used as a hierarchical LSP. 645 1 means LSP to be used as a stitching segment. 647 Other bits are reserved for future use. They MUST be set to zero 648 on transmission and SHOULD be ignored on receipt. 650 Note that all defined bit flags have meaning at the same time. 651 An LSP that is to form an FA would carry the Actions field set 652 to 0x00. That is: 653 P=0 (advertised) 654 T=0 (TE link) 655 R=0 (not a routing adjacency) 656 B=0 (not a bundle) 657 H=0 (hierarchical LSP) 659 Reserved 661 The Reserved bits MUST be set to zero on transmission and SHOULD 662 be ignored on receipt. 664 TLVs 666 Zero, one, or more TLVs may be present. Each TLV is encoded as 667 follows: 669 Type (16 bits) 671 The identifier of the TLV. Two type values are defined in 672 this document: 674 1 IGP Instance Identifier TLV 675 2 Component Link Identifier TLV 677 Length (16 bits) 679 Indicates the total length of the TLV in octets. I.e., 680 4 + the length of the value field in octets. A value field 681 whose length is not a multiple of four MUST be zero-padded 682 so that the TLV is four-octet aligned. 684 Value 686 The data for the TLV padded as described above. 688 If this object is carried in a Path message it is known as the 689 "Forward Interface ID" for the LSP that is being set up. On a Resv 690 message the object is known as the "Reverse Interface ID" for the 691 LSP. 693 3.1.3. IPv4 Numbered Links with Action Identification 695 A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined 696 to carry an IPv4 numbered interface address. 698 The format of the object is as shown below. 700 C-NUM = 193, C-Type = 2 (TBD by IANA) 702 0 1 2 3 703 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 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | IPv4 Interface Address | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Actions | Reserved | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 ~ TLVs ~ 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 IPv4 Interface Address 714 The address assigned to the interface the sender applies to 715 this LSP. 717 Actions 719 See Section 3.1.2. 721 Reserved 723 See Section 3.1.2. 725 TLVs 727 See Section 3.1.2. 729 If this object is carried in a Path message it is known as the 730 "Forward Interface ID" for the LSP that is being set up. On a Resv 731 message the object is known as the "Reverse Interface ID" for the 732 LSP. 734 3.1.4. IPv6 Numbered Links with Action Identification 736 A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined 737 to carry an IPv6 numbered interface address. 739 The format of the object is as shown below. 741 C-NUM = 193, C-Type = 3 (TBD by IANA) 742 0 1 2 3 743 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 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | IPv6 Interface Address (128 bits) | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | IPv6 Interface Address (continued) | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | IPv6 Interface Address (continued) | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | IPv6 Interface Address (continued) | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Actions | Reserved | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 ~ TLVs ~ 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 IPv6 Interface Address 760 The address assigned to the interface the sender applies to 761 this LSP. 763 Actions 765 See Section 3.1.2. 767 Reserved 769 See Section 3.1.2. 771 TLVs 773 See Section 3.1.2. 775 If this object is carried in a Path message it is known as the 776 "Forward Interface ID" for the LSP that is being set up. On a Resv 777 message the object is known as the "Reverse Interface ID" for the 778 LSP. 780 3.2. Target IGP Identification TLV 782 If the LSP being set up is to be advertised as a link, the egress 783 needs to know which instance of the IGP it should use to make the 784 advertisement. The default in [RFC4206] and [RFC3477] is that the LSP 785 is advertised as an FA, that is, in the same instance of the IGP as 786 was used to advertise the TE links that the LSP traverses. 788 In order to facilitate an indication from the ingress to the egress 789 of which IGP instance to use, the IGP Identification TLV is defined 790 for inclusion in the new variants of the LSP_TUNNEL_INTERFACE_ID 791 object defined in this document. 793 The TLV has meaning only in a Path message. It SHOULD NOT be included 794 in the LSP_TUNNEL_INTERFACE_ID object in a Resv message and MUST be 795 ignored if found. 797 If the P-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID 798 object in a Path message is clear (i.e., zero), this TLV indicates 799 the IGP instance to use for the advertisement. If the TLV is absent, 800 the same instance of the IGP should be used as is used to advertise 801 the TE links that the LSP traverses. Thus, for an FA, the TLV can be 802 omitted; alternatively, the IGP Instance TLV may be present 803 identifying the IGP instance or carrying the reserved value 804 0xffffffff. 806 If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID 807 object in a Resv message is set (i.e., one) indicating that the LSP 808 is not to be advertised as a link, this TLV SHOULD NOT be present and 809 MUST be ignored if encountered. 811 The TLV is formatted as described in Section 3.1.2. The Type field 812 has the value 1, and the Value field has the following content: 814 0 1 2 3 815 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 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | IGP Instance Identifier | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 IGP Instance Identifier 822 A 32-bit identifier be assigned to each of the IGP instances 823 within a network, such that ingress and egress LSRs have the same 824 understanding of these numbers. This is a management 825 configuration exercise outside the scope of this document. 827 Note that the IGP Instance Identifier might be mapped from an 828 instance identifier used in the IGP itself (such as section 2.4 829 of [RFC5340] for OSPFv3, or [OSPFv2-MI] for OSPFv2) as a matter 830 of network policy. See [OSPF-TI] for further discussion of this 831 topic in OSPF, and [ISIS-GENAP] for IS-IS. 833 The value 0xffffffff is reserved to mean that the LSP is to be 834 advertised in the same instance of the IGP as was used to 835 advertise the TE links that the LSP traverses. 837 3.3. Component Link Identification TLV 839 If the LSP that is being set up is to be used as a component link in 840 a link bundle [RFC4201], it is necessary to indicate both the 841 identity of the component link and the identity of the link bundle. 842 Furthermore, it is necessary to indicate how the link bundle (that 843 may be automatically created by the establishment of this LSP) is 844 to be used and advertised. 846 If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID 847 object is set, the other fields of the object apply to the link 848 bundle itself. That is, the interface identifiers (numbered or 849 unnumbered) and the other flags in the Actions field apply to the 850 link bundle and not to the component link that the LSP will form. 852 Furthermore, the IGP Instance Identifier TLV (if present) also 853 applies to the link bundle and not to the component link. 855 In order to exchange the identity of the component link, the 856 Component Link Identifier TLVs are introduced as set out in the 857 next sections. If the B-flag is set in the Actions field of the 858 LSP_TUNNEL_INTERFACE_ID object in the Path message, exactly one of 859 these TLVs MUST be present in the LSP_TUNNEL_INTERFACE_ID object in 860 both the Path and Resv objects. 862 3.3.1. Unnumbered Component Link Identification 864 If the component link is to be unnumbered, the Unnumbered Component 865 Link Identifier TLV is used. The TLV is formatted as described in 866 Section 3.1.2. The Type field has the value 2, and the Value field 867 has the following content: 869 0 1 2 3 870 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 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Component Link Identifier | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 Component Link Identifier 877 Unnumbered identifier that is assigned to this component link 878 within the bundle [RFC4201]. 880 3.3.2. IPv4 Numbered Component Link Identification 882 If the component link is identified with an IPv4 address, the IPv4 883 Numbered Component Link Identifier TLV is used. The TLV is formatted 884 as described in Section 3.1.2. The Type field has the value 3, and 885 the Value field has the following content: 887 0 1 2 3 888 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 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | IPv4 Address | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 IPv4 Address 895 The IPv4 address that is assigned to this component link within 896 the bundle. 898 3.3.3. IPv6 Numbered Component Link Identification 900 If the component link is identified with an IPv6 address, the IPv6 901 Numbered Component Link Identifier TLV is used. The TLV is formatted 902 as described in Section 3.1.2. The Type field has the value 4, and 903 the Value field has the following content: 905 0 1 2 3 906 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 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | IPv6 Address | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | IPv6 Address (continued) | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | IPv6 Address (continued) | 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | IPv6 Address (continued) | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 IPv6 Address 919 The IPv6 address that is assigned to this component link within 920 the bundle. 922 3.4. Link State Advertisement 924 The ingress and egress of an LSP that is set up using the 925 LSP_TUNNEL_INTERFACE_ID object MUST advertise the LSP as agreed in 926 the parameters of the object. 928 Where a TE link is created from the LSP, the TE link SHOULD inherit 929 the TE properties of the LSP as described in [RFC5212] but this 930 process is subject to local and network-wide policy. 932 It is possible that an LSP will be used to offer capacity and 933 connectivity to multiple other networks. In this case, multiple 934 instances of the LSP_TUNNEL_INTERFACE_ID object are permitted in 935 the same Path and Resv messages. Each instance MUST have a different 936 IGP Instance Identifier. 938 Note, however, that a Path or Resv message MUST NOT contain more than 939 one instance of the LSP_TUNNEL_INTERFACE_ID object with C-Type 1, and 940 if such an object is present, all other instances of the 941 LSP_TUNNEL_INTERFACE_ID object MUST include an IGP Instance 942 Identifier TLV with IGP Instance Identifier set to a value that 943 identifies some other IGP instance (in particular, not the value 944 0xffffffff). 946 If the link created from an LSP is advertised in the same IGP 947 instance as was used to advertise the TE links that the LSP 948 traverses, the addresses for the new link and that for the links it 949 is built from MUST come from the same address space. 951 If the link is advertised into another IGP instance the addresses 952 MAY be drawn from overlapping address spaces such that some addresses 953 have different meanings in each IGP instance. 955 In the IGP the TE Router ID of the ingress LSR is taken from the 956 Tunnel Sender Address in the Sender Template object signaled in the 957 Path message. It is assumed that the ingress LSR knows the TE Router 958 ID of the egress LSR since it has chosen to establish an LSP to that 959 LSR and plans to use the LSP as a TE link. 961 The link interface addresses or link interface identifiers for the 962 forward and reverse direction links are taken from the 963 LSP_TUNNEL_INTREFACE_ID object on the Path and Resv messages 964 respectively. 966 When an LSP is torn down through explicit action (a PathTear message 967 or a PathErr message with the Path_State_Removed flag set) the 968 ingress and egress LSRs SHOULD withdraw the advertisement of any link 969 that the LSP created and that was previously advertised. The link 970 state advertisement MAY be retained as a virtual link in another 971 layer network according to network-wide policy [PCE-LAYER]. 973 3.5. Message Formats 975 [RFC3477] does not state where in the Path message or Resv message 976 the LSP_TUNNEL_INTERFACE_ID object should be placed. 978 It is RECOMMENDED that new implementations place the 979 LSP_TUNNEL_INTERFACE_ID objects in the Path message immediately after 980 the SENDER_TSPEC object, and in the Resv message immediately after 981 the FILTER_SPEC object. 983 All implementations SHOULD be able to handle received messages with 984 objects in any order as described in [RFC3209]. 986 3.6. Error Cases and Non-Acceptance 988 Error cases and non-acceptance of new object variants caused by back- 989 level implementations are discussed in Section 3.7. 991 An egress LSR that receives an LSP_TUNNEL_INTERFACE_ID object may 992 have cause to reject the parameters carried in the object for a 993 number of reasons as set out below. In all cases, the egress SHOULD 994 respond with a PathErr message with the error code as indicated in 995 the list below. In most cases the error will arise during LSP setup, 996 no Resv state will exist, and the PathErr will cause Path state to be 997 removed. Where the error arises after the LSP has been successfully 998 set up, the PathErr SHOULD be sent with the Path_State_Removed flag 999 [RFC3473] clear so that the LSP remains operational. 1001 The error cases identified are as follows and are reported using the 1002 new error code 'LSP Hierarchy Issue' (code 34 TBD by IANA) and the 1003 error values listed below. 1005 Error | Error | Error-case 1006 code | value | 1007 ------+-------+------------------------------------------------------ 1008 34 1 Link advertisement not supported 1009 34 2 Link advertisement not allowed by policy 1010 34 3 TE link creation not supported 1011 34 4 TE link creation not allowed by policy 1012 34 5 Routing adjacency creation not supported 1013 34 6 Routing adjacency creation not allowed by policy 1014 34 7 Bundle creation not supported 1015 34 8 Bundle creation not allowed by policy 1016 34 9 Hierarchical LSP not supported 1017 34 10 LSP stitching not supported 1018 34 11 Link address type or family not supported 1019 34 12 IGP instance unknown 1020 34 13 IGP instance advertisement not allowed by policy 1021 34 14 Component link identifier not valid 1022 34 15 Unsupported component link identifier address family 1024 When an ingress LSR receives an LSP_TUNNEL_INTERFACE_ID object on a 1025 Resv message it may need to reject it because of the setting of 1026 certain parameters in the object. Since these reasons all represent 1027 errors rather than negotiable parameter-mismatches, the ingress 1028 SHOULD respond with a PathTear to remove the LSP. The ingress MAY use 1029 a ResvErr with one of the following error codes, allowing the egress 1030 the option to correct the error in a new Resv message, or to tear the 1031 LSP with a PathErr with Path_State_Removed flag set. An ingress that 1032 uses the ResvErr MUST take precautions against a protocol loop where 1033 the egress responds with the same LSP_TUNNEL_INTERFACE_ID object with 1034 the same or different) issues. 1036 Error | Error | Error-case 1037 code | value | 1038 ------+-------+------------------------------------------------------ 1039 34 11 Link address type or family not supported 1040 34 14 Component link identifier not valid 1041 34 15 Unsupported component link identifier address family 1042 34 16 Component link identifier missing 1044 3.7. Backward Compatibility 1046 The LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] has a class 1047 number of 193. According to [RFC2205], this means that a node that 1048 does not understand the object SHOULD ignore the object but forward 1049 it, unexamined and unmodified. Thus there are no issues with transit 1050 LSRs supporting the pre-existing or new Class Types of this object. 1052 A back-level ingress node will behave as follows: 1054 - It will not issue Path messages containing LSP_TUNNEL_INTERFACE_ID 1055 objects with the new Class Types defined in this document. 1057 - It will reject Resv messages containing LSP_TUNNEL_INTERFACE_ID 1058 objects with the new Class Types defined in this document as 1059 described in [RFC2205]. In any case, such a situation would 1060 represent an error by the egress. 1062 - It will continue to use the LSP_TUNNEL_INTERFACE_ID object with 1063 Class Type 1 as defined in [RFC3477]. This behavior is supported by 1064 back-level egresses and by egresses conforming to this document. 1066 - According to an informal survey, there is no significant deployment 1067 of numbered FA establishment following the procedures defined in 1068 [RFC4206] and set out in Section 1.3.6 of this document. It is 1069 therefore safe to assume that back-level ingress LSRs will not use 1070 this mechanism. 1072 A back-level egress node will behave as follows: 1074 - It will continue to support the LSP_TUNNEL_INTERFACE_ID object with 1075 Class Type 1 as defined in [RFC3477] if issued by an ingress. 1077 - It will reject a Path message that carries an 1078 LSP_TUNNEL_INTERFACE_ID object with any of the new Class Types 1079 defined in this document using the procedures of [RFC2205]. This 1080 will inform the ingress that the egress is a back-level LSR. 1082 - It will not expect to use the procedures for numbered FA 1083 establishment defined in [RFC4206] and set out in Section 1.3.6 of 1084 this document. 1086 In summary, the new mechanisms defined in this document do not impact 1087 the method to exchange unnumbered FA information described in 1088 [RFC3477]. That mechanism can be safely used in combination with the 1089 new mechanisms described here and is functionally equivalent to using 1090 the new C-Type indicating an unnumbered link with target IGP instance 1091 identifier with the Target IGP Instance value set to 0xffffffff. 1093 The mechanisms in this document obsolete the method to exchange the 1094 numbered FA information described in [RFC4206] as described in 1095 Section 1.4.6. 1097 4. Security Considerations 1099 [RFC3477] points out that one can argue that the use of the extra 1100 interface identifier that it provides could make an RSVP message 1101 harder to spoof. In that respect, the minor extensions to the 1102 protocol made in this document do not constitute an additional 1103 security risk, but could also be said to improve security. 1105 It should be noted that the ability of an ingress LSR to request that 1106 an egress LSR advertise an LSP as a TE link MUST be subject to 1107 appropriate policy checks at the egress LSR. That is, the egress LSR 1108 MUST NOT automatically accept the word of the ingress unless it is 1109 configured with such a policy. 1111 Further details of security for MPLS-TE and GMPLS can be found in 1112 [GMPLS-SEC]. 1114 5. IANA Considerations 1116 5.1. New Class Types 1118 IANA maintains a registry of RSVP parameters called "Resource 1119 Reservation Protocol (RSVP) Parameters" with a sub-registry called 1120 "Class Names, Class Numbers, and Class Types." There is an entry in 1121 this registry for the LSP_TUNNEL_INTERFACE_ID object defined in 1122 [RFC3477] with one Class Type defined. 1124 IANA is requested to allocate three new Class Types for this object 1125 as defined in Sections 3.1.2, 3.1.3, and 3.1.4 as follows: 1127 C-Type Meaning Reference 1128 --------------------------------------------------------------- 1129 2 IPv4 interface identifier with target [This.doc] 1130 3 IPv6 interface identifier with target [This.doc] 1131 4 Unnumbered interface with target [This.doc] 1133 5.2. Hierarchy Actions 1135 Section 3.1.2 defines an 8-bit flags field in the 1136 LSP_TUNNEL_INTERFACE_ID object. IANA is requested to create a new 1137 sub-registry of the "Generalized Multi-Protocol Label Switching 1138 (GMPLS) Signaling Parameters" registry called the "Hierarchy Actions" 1139 sub-registry as follows: 1141 Registry Name: Hierarchy Actions 1142 Reference: [This.doc] 1143 Registration Procedures: IETF Standards Action RFC 1144 Registry: 1145 Bit Number Hex Value Name Reference 1146 ---------- ----------- ----------------------- --------- 1147 0-2 Unassigned 1148 3 0x10 Hierarchy/stitching (H) [This.doc] 1149 4 0x08 Bundle (B) [This.doc] 1150 5 0x04 Routing adjacency(R) [This.doc] 1151 6 0x02 TE link (T) [This.doc] 1152 7 0x01 Private (P) [This.doc] 1154 5.3. New Error Codes and Error Values 1156 IANA maintains a registry of RSVP error codes and error values as the 1157 "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry 1158 of the "Resource Reservation Protocol (RSVP) Parameters" registry. 1160 IANA is requested to define a new error code with suggested value 34 1161 as below (see also Section 3.6). 1163 Error Code Meaning 1165 34 LSP Hierarchy Issue [This.doc] 1167 IANA is requested to list the following error values for this error 1168 code (see also Section 3.6). 1170 This Error Code has the following globally-defined Error 1171 Value sub-codes: 1173 1 = Link advertisement not supported [This.doc] 1174 2 = Link advertisement not allowed by policy [This.doc] 1175 3 = TE link creation not supported [This.doc] 1176 4 = TE link creation not allowed by policy [This.doc] 1177 5 = Routing adjacency creation not supported [This.doc] 1178 6 = Routing adjacency creation not allowed by policy [This.doc] 1179 7 = Bundle creation not supported [This.doc] 1180 8 = Bundle creation not allowed by policy [This.doc] 1181 9 = Hierarchical LSP not supported [This.doc] 1182 10 = LSP stitching not supported [This.doc] 1183 11 = Link address type or family not supported [This.doc] 1184 12 = IGP instance unknown [This.doc] 1185 13 = IGP instance advertisement not allowed by policy [This.doc] 1186 14 = Component link identifier not valid [This.doc] 1187 15 = Unsupported component link identifier address [This.doc] 1188 family 1189 16 = Component link identifier missing [This.doc] 1191 6. Acknowledgements 1193 The authors would like to thank Lou Berger, Deborah Brungard, John 1194 Drake, Yakov Rekhter, Igor Bryskin, and Lucy Yong for their valuable 1195 discussions and comments. 1197 7. References 1199 7.1. Normative References 1201 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1202 Requirement Levels", BCP 14, RFC 2119, March 1997. 1204 [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. 1205 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 1206 Functional Specification", RFC 2205, September 1997. 1208 [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol 1209 Label Switching Architecture", RFC 3031, January 2001. 1211 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. 1212 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1213 Tunnels", RFC 3209, December 2001. 1215 [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label 1216 Switching (MPLS) Signaling Resource ReserVation Protocol 1217 Traffic Engineering (RSVP-TE) Extensions", RFC 3473, 1218 January 2003. 1220 [RFC3477] Kompella, K. and Rekhter, Y., "Signalling Unnumbered Links 1221 in Resource ReSerVation Protocol - Traffic Engineering 1222 (RSVP-TE)", RFC 3477, January 2003. 1224 [RFC4201] Kompella, K., Rekhter, Y., and Berger, L.," Link Bundling 1225 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 1227 [RFC4206] Kompella, K. and Y. Rekhter, "LSP Hierarchy with 1228 Generalized MPLS TE", RFC 4206, October 2005. 1230 [RFC5150] Ayyangar, A., Vasseur, J.P, and Farrel, A., "Label Switched 1231 Path Stitching with Generalized Multiprotocol Label 1232 Switching Traffic Engineering (GMPLS TE)", RFC 5150, 1233 February 2008. 1235 7.2. Informative References 1237 [RFC1195] Callon, R.W., "Use of OSI IS-IS for routing in TCP/IP and 1238 dual environments", RFC 1195, December 1990 1240 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 1241 September 1991. 1243 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1245 [RFC3630] Katz, D., Kompella, K. and Yeung, D., "Traffic Engineering 1246 (TE) Extensions to OSPF Version 2", RFC 3630, September 1247 2003. 1249 [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing Extensions 1250 in Support of Generalized Multi-Protocol Label Switching 1251 (GMPLS)", RFC 4202, October 2005. 1253 [RFC4203] Kompella, K. Ed. and Y. Rekhter, Ed., "OSPF Extensions in 1254 Support of Generalized Multi-Protocol Label Switching 1255 (GMPLS)", RFC 4203, October 2005. 1257 [RFC5212] Shiomoto, K., et al, "Requirements for GMPLS-Based Multi- 1258 Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 1259 2008 1261 [RFC5305] Smit, H. and T. Li, "Intermediate System to Intermediate 1262 System (IS-IS) Extensions for Traffic Engineering (TE)", 1263 RFC 5305, October 2008. 1265 [RFC5307] Kompella, K. Ed. and Y. Rekhter, Ed., "Intermediate System 1266 to Intermediate System (IS-IS) Extensions in Support of 1267 Generalized Multi-Protocol Label Switching (GMPLS)", RFC 1268 5307, October 2008. 1270 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 1271 2008. 1273 [RFC5329] Ishiguro, K., Manral, V., Davey, A., and Lindem, A., 1274 (Ed.), "Traffic Engineering Extensions to OSPF version 3", 1275 RFC 5329, September 2008. 1277 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for 1278 IPv6", RFC 5340, July 2008. 1280 [GMPLS-SEC] Fang, L., et al., "Security Framework for MPLS and GMPLS 1281 Networks", draft-ietf-mpls-mpls-and-gmpls-security- 1282 framework, work in progress. 1284 [ISIS-GENAP] Ginsberg, L., Previdi, S., and Shand, M., "Advertising 1285 Generic Information in IS-IS", draft-ietf-isis-genapp, work 1286 in progress. 1288 [ISIS-IPV6-TE] Harrison, J., Berger, J., and Bartlett, M., "IPv6 1289 Traffic Engineering in IS-IS", draft-ietf-isis-ipv6-te, 1290 work in progress. 1292 [OSPF-TI] Lindem, A., Roy, A., and Mirtorabi, S., "OSPF Transport 1293 Instance Extensions", draft-acee-ospf-transport-instance, 1294 work in progress. 1296 [OSPFv2-MI] Lindem, A., Roy, A., and Mirtorabi, S., "OSPF Multi- 1297 Instance Extensions", draft-acee-ospf-multi-instance, work 1298 in progress. 1300 [PCE-LAYER] Oki, E. (Ed.), "PCC-PCE Communication and PCE Discovery 1301 Requirements for Inter-Layer Traffic Engineering", 1302 draft-ietf-pce-inter-layer-req, work in progress. 1304 8. Editors' Addresses 1306 Kohei Shiomoto 1307 NTT Network Service Systems Laboratories 1308 3-9-11 Midori 1309 Musashino, Tokyo 180-8585 1310 Japan 1311 Phone: +81 422 59 4402 1312 Email: shiomoto.kohei@lab.ntt.co.jp 1314 Adrian Farrel 1315 Old Dog Consulting 1316 EMail: adrian@olddog.co.uk 1318 9. Authors' Addresses 1320 Richard Rabbat 1321 Google Inc. 1322 1600 Amphitheatre Pkwy 1323 Mountain View, CA 94043 1324 Email: rabbat@alum.mit.edu 1326 Arthi Ayyangar 1327 Juniper Networks 1328 1194 N. Mathilda Ave. 1329 Sunnyvale, CA 94089 1330 United States of America 1331 Email: arthi@juniper.net 1332 Zafar Ali 1333 Cisco Systems, Inc. 1334 2000 Innovation Drive 1335 Kanata, Ontario, K2K 3E8 1336 Canada. 1337 EMail: zali@cisco.com 1339 Full Copyright Statement 1341 Copyright (c) 2009 IETF Trust and the persons identified as the 1342 document authors. All rights reserved. 1344 This document is subject to BCP 78 and the IETF Trust's Legal 1345 Provisions Relating to IETF Documents in effect on the date of 1346 publication of this document (http://trustee.ietf.org/license-info). 1347 Please review these documents carefully, as they describe your rights 1348 and restrictions with respect to this document.