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