idnits 2.17.1 draft-ietf-ccamp-lsp-hierarchy-bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 838. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 811. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 818. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 392 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 116 has weird spacing: '...IS) and using...' -- 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 (April 26, 2007) is 6203 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: 3 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Shiomoto (NTT) 3 Internet Draft R. Rabbat (Google) 4 Updates: 3477, 4206 A. Ayyangar (Nuova Systems) 5 Proposed Category: Proposed Standard A. Farrel (Old Dog Consulting) 6 Z. Ali (Cisco Systems, Inc.) 7 Expires: October 2007 April 26, 2007 9 Procedures for Dynamically Signaled Hierarchical Label Switched Paths 10 draft-ietf-ccamp-lsp-hierarchy-bis-02.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that 15 any applicable patent or other IPR claims of which he or she is 16 aware have been or will be disclosed, and any of which he or she 17 becomes aware will be disclosed, in accordance with Section 6 of 18 BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on October 26, 2007. 37 Abstract 39 This document discusses topics related to hierarchical and stitched 40 Generalized Multiprotocol Label Switching (GMPLS) Label Switched 41 Paths (LSPs). It describes extensions to allow an egress to identify 42 that a bi-directional LSP will be used as a dynamically signaled 43 Forwarding Adjacency LSP (FA-LSP) or as a Routing Adjacency (RA). In 44 addition, the document also discusses the issue of how to indicate 45 that an LSP should be advertised as a traffic engineering (TE) link 46 into a different instance of the IGP, and how to identify the 47 instance that should be used. 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in [RFC2119]. 55 Table of Contents 57 1. Introduction and Problem Statement.............................3 58 1.1. LSP Hierarchy.............................................3 59 1.2. LSP advertisement and Usage...............................4 60 1.3. Problem Statement.........................................4 61 1.4. Current Approaches and Shortcomings.......................6 62 1.5. Contents of This Document.................................7 63 2. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00.....7 64 3. Proposed Solution..............................................7 65 3.1. IGP Instance Identification...............................8 66 3.2. LSP advertisement and Usage Identification................9 67 3.3. Bundling..................................................9 68 3.4. LSP_TUNNEL_INTERFACE_ID Object...........................10 69 3.4.1. Unnumbered link.....................................10 70 3.4.2. IPv4 numbered link..................................11 71 3.4.3. IPv6 numbered link..................................12 72 3.4.4. Unnumbered link with target IGP instance identifier.13 73 3.4.5. Message Formats.....................................13 74 3.5. TLVs.....................................................14 75 3.5.1. Unnumbered Component Link Identifier................14 76 3.5.2. IPv4 Numbered Component Link Identifier.............15 77 3.6. LSA advertisement........................................15 78 4. Applicability Statement.......................................16 79 5. Backward Compatibility Considerations.........................16 80 6. Security Considerations.......................................16 81 7. IANA Considerations...........................................17 82 8. Acknowledgement...............................................17 83 9. References....................................................17 84 9.1. Normative References.....................................17 85 9.2. Informative References...................................17 86 Author's Addresses...............................................18 87 Intellectual Property Statement..................................18 88 Copyright Statement..............................................19 90 1. Introduction and Problem Statement 92 1.1. LSP Hierarchy 94 LSP hierarchy has been developed to improve the scalability of 95 Generalized Multi-Protocol Label Switching (GMPLS) by allowing Label 96 Switched Paths (LSPs) to be aggregated into a hierarchy of such LSPs 97 [RFC4206]. An LSP may be advertised as a traffic engineering (TE) 98 link for use within the same instance of the control plane as was 99 used to set up the LSP. This TE link is called a Forwarding Adjacency 100 (FA), and the LSP is known as an FA-LSP. 102 [RFC4206] defines the operation as follows for a numbered FA: 104 1. The ingress signals the LSP using a /31 sender address that it 105 allocates as the source address in the signaling message (tunnel 106 sender address in the Sender Template object of the Path message), 107 and targeting the TE router ID of the egress (destination address 108 in the Sender object of the Path message). 110 2. The egress sets up the LSP using normal procedures and allocating 111 the partner address of the assigned /31 address in the local 112 interface address. 114 3. The ingress then forms a Forwarding Adjacency (FA) out of that LSP 115 by advertising it as a Traffic Engineering (TE) link using the 116 routing protocol (OSPF/ISIS) and using the /31 address to 117 identify the local end of the TE link. 119 4. When the egress receives the TE link advertisement, it checks the 120 Link-ID address of the TE advertisement against its own TE Router 121 ID. If it matches its own TE Router ID, the egress checks the 122 advertising router ID of the TE advertisement against the ingress 123 addresses of all LSPs for which it is the egress and finds the 124 address match with the advertising router ID of the TE 125 advertisement. 127 5. The egress then advertises the FA LSP as a TE link setting the 128 advertising TE Router ID in the Link-ID and the partner address of 129 the assigned /31 address in the local interface address. 131 Nesting of LSPs originated by other LSRs into that LSP can be 132 achieved by using the label stack construct. 134 1.2. LSP advertisement and Usage 136 There are three different ways in which traffic can be forwarded to 137 an LSP. Similarly, the LSP can be advertised into the IP topology, 138 the MPLS TE topology or both, depending on the intended usage. 140 As GMPLS LSPs can be bidirectional, full routing adjacencies can be 141 established over a bidirectional GMPLS LSP. When an LSP is used as an 142 RA, it is advertised into IP network and can optionally be advertised 143 into the MPLS topology. The notion of RA is only applicable to 144 bidirectional LSPs. 146 As mentioned above, there is no IGP adjacency over the LSP, when it 147 is to be used as an FA. FA-LSPs can be advertised into the IP and/ or 148 MPLS topologies. Notion of FA is equally applicable to the 149 unidirectional as well as bidirectional LSPs. 151 There are also scenarios where intent of establishing an LSP is to 152 use it for traffic local to the Ingress/ Egress LSRs. In this case, 153 the LSP is neither advertised into the IP nor in MPLS topologies. In 154 this document, such LSPs are referred as local virtual links. 155 Forwarding treatment for a local virtual link is based on a local 156 decision. 158 1.3. Problem Statement 160 The extensions described in this document are intended for 161 dynamically signaled bi-directional Forwarding Adjacency LSPs (FA- 162 LSPs). In particular this document addresses the following points: 164 (1) How to let the egress node know that this bi-directional LSP 165 needs to be advertised as an FA, or as routing adjacency (RA), 166 or is only for the use of the ingress and egress nodes. 168 (2) How to indicate that a new LSP should be treated as part of a 169 TE link bundle and advertised as part of that bundle. 171 (3) How to identify the routing instance in which such an 172 advertisement should happen. 174 We should note that these aspects are equally applicable to both 175 numbered and unnumbered TE links. 177 In order for the egress of an LSP to be able to advertise the LSP as 178 a TE link it needs to know that such an advertisement is desirable, 179 and it also needs to know the TE Router ID of the ingress LSR. 181 (Please recall that the Router ID of the other end of the link is set 182 in the Link-ID sub-TLV of the Link TLV of the TE Opaque-LSA 183 [RFC3630].) If the LSP is to form part of a TE link bundle, the 184 egress must also know the identity of the bundle. 186 When the mechanism set out in section 1.1 is used for numbered FAs, 187 there is no way to carry the TE Router ID of the ingress LSR in the 188 RSVP signaling message (Path message) and there is no way to indicate 189 that the new LSP is to be used as an FA LSP. Therefore the egress LSR 190 has to wait to receive a routing protocol advertisement of the TE 191 link flooded by the ingress to learn about the new TE link and to 192 deduce that the LSP forms that TE link. The egress must learn the TE 193 Router ID of the ingress node before it can advertise the FA as 194 described in Section 1.2. Note further, that in this approach, the 195 egress LSR must search potentially many LSPs every time it receives 196 an advertisement for a new TE link. 198 [RFC3477] defines a different method for the exchange of information 199 in the signaling protocol during the establishment of LSPs that will 200 be advertised as unnumbered TE links. If the LSP_TUNNEL_INTERFACE_ID 201 object is present, it indicates that the LSP is to be advertised as a 202 TE link, and it contains the TE Router ID of the ingress LSR. This 203 mechanism resolves many of the issues listed above, and provides a 204 solution for unnumbered TE links, however, the 205 LSP_TUNNEL_INTERFACE_ID object cannot be used for numbered FAs as 206 currently defined, and so the problem remains for numbered TE links. 208 Related to the above problem, a few key observations are worth 209 noting: 211 1. The term FA is applicable only when an LSP is created and used as 212 a TE link in the same instance of the IGP. [RFC4206] did not 213 consider scenarios where an LSP is created (and maintained) by one 214 instance of the IGP, and is used as a (TE) link by another 215 instance of IGP. This leaves open the question of advertising a TE 216 link into a different instance of the IGP as is needed in multi- 217 region/multi-layer networks [MLN], and how to identify which 218 instance of the IGP should be used. In addition, the TE link 219 advertised into the different IGP instance may be associated with 220 an IGP neighbor adjacency. We call it a routing adjacency (RA). 221 The decision as to whether the link should be advertised to MPLS 222 TE topology or IP topology or both depends on operator policy. 223 Therefore, a mechanism to indicate the choice to the Egress node 224 is needed. 226 2. [RFC4206] provides a way to exchange numbered identifiers for the 227 TE link, but this does not clearly state that the Ingress node can 228 use presence of the LSP_TUNNEL_INTERFACE_ID object as a trigger 229 for TE link advertisement at the egress node. 231 3. It is important to note that an LSP that is set up in a server 232 GMPLS transport network and advertised as a TE link in a client 233 MPLS data network is NOT an FA-LSP according to the definitions 234 explained in point 1, above. This is the case regardless of 235 whether the GMPLS network is packet- or non-packet-capable. 237 4. When an egress checks the address of the advertised TE link to 238 find the LSP sender (Recall step (4) as described in section 1.1), 239 it must check the Link-ID address of all received TE 240 advertisements against its own TE Router ID. If it matches its 241 own TE Router ID, the egress checks the advertising router ID of 242 the TE advertisement against the ingress addresses of all LSPs for 243 which it is the egress. It is an assertion of the authors that 244 this method is not scalable due to the amount of processing needed 245 for all the TE Link State Advertisements (LSAs). 247 Further, if a set of LSPs are to be bundled into a single TE link 248 [RFC4201] then not only is it necessary to identify to the egress 249 that the LSP will be advertised as part of a TE link, it is also 250 necessary to indicate the identity of the TE link. This identity is 251 distinct from the identity of the component link. Thus, in this case 252 an additional identifier needs to be signaled, but none is currently 253 available. 255 1.4. Current Approaches and Shortcomings 257 [RFC3477] provides a mechanism to exchange unnumbered identifiers for 258 the TE link during FA-LSP establishment, and this can be used as a 259 notification to the egress that the LSP will be used as a TE link. So, 260 for unnumbered TE links, there is a well-defined indication available, 261 and this could be documented and used as a trigger for TE link 262 advertisement by the egress. 264 The use of unnumbered TE links may be arguably more sensible than 265 assigning numbers to FAs, especially in the case of large networks. 266 Some operators though prefer to consistently use numbered TE links 267 for both static and dynamic (that is, FA) TE links in their networks. 268 In the case of numbered TE links, however, there is no available 269 indication to allow the egress to know that an LSP should be 270 advertised as a TE link. 272 In addition, using unnumbered TE links does not address the issue of 273 advertising TE links into a different instance of the IGP. There is 274 no defined mechanism to identify whether it should be advertised as 275 an FA, a full Routing Adjacency (RA), or a static link. 277 The Link Management Protocol (LMP) [RFC4204] could possibly be run on 278 remote adjacencies between the endpoints of an LSP. But LMP peer 279 discovery would be required for dynamic LMP peering and is not 280 currently specified. In addition, the concept of a remote LMP 281 adjacency remains unproven. Lastly, there would be a requirement 282 that all layers/regions in a MLN network run LMP. This may not be 283 the case in existing networks and would put undue burden on the 284 network operator to deploy another protocol. 286 1.5. Contents of This Document 288 This document provides a consolidated way of exchanging TE link 289 identifiers when an LSP is established through signaling. It also 290 provides a mechanism to allow the ingress to control whether, and 291 into which IGP instances, an LSP is advertised as an FA and/ or RA by 292 the egress. The proposed mechanism applies equally to Hierarchical 293 LSPs (H-LSPs) and Stitchable LSPs (S-LSPs). 295 The method described below extends the method described in [RFC3477], 296 which is applied for an FA-LSP represented as an unnumbered TE link. 298 2. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00 300 o Fixed page formatting 302 o Updated author addresses 304 o Readability fixes 306 3. Proposed Solution 308 The following method allows the ingress and egress LSRs to exchange 309 the link addresses or link identifiers (including the node ID) of the 310 ends of a numbered or unnumbered TE link to be formed from an LSP. 311 It is an extension of the procedures defined in [RFC3477] for 312 unnumbered TE links. 314 If an Ingress LSR that originates an LSP, intends to advertise this 315 LSP as a TE link in IS-IS or OSPF [RFC4206], the Ingress LSR MUST 316 allocate an address or identifier to the TE link (just like for any 317 other TE link), and it MUST do this before the LSP setup request is 318 signaled. Moreover, the Path message used for establishing the LSP 319 that will be used to form the TE link MUST contain the 320 LSP_TUNNEL_INTERFACE_ID object (as extended and described below), 321 with the interface address or identifier allocated by the Ingress LSR. 323 If the Path message for the H-LSP/S-LSP contains the 324 LSP_TUNNEL_INTERFACE_ID object, then the Egress LSR (assuming it 325 accepts the LSP request) MUST allocate an address or identifier to 326 the TE link that will be formed (just like for any other numbered or 327 unnumbered TE link). Furthermore, the Resv message for the LSP MUST 328 contain an LSP_TUNNEL_INTERFACE_ID object, with the interface address 329 or identifier allocated by the Egress LSR. 331 In all cases where an LSP is to be advertised as a TE link, the 332 Tunnel Sender Address in the Sender Template Object of the Path 333 message MUST be set to the TE Router ID of the Ingress LSR. We should 334 note that this is a change from the method described in [RFC4206]. 336 Once the Egress LSR has successfully sent a Resv message as described 337 above it SHOULD advertise the LSP as a TE link using the 338 addresses/identifiers exchanged. Once the Resv has been processed by 339 the Ingress LSR and the LSP has been successfully established, the 340 Ingress LSR SHOULD advertise the LSP as a TE link using the 341 addresses/identifiers exchanged. 343 Once the TE link advertisement has been flooded it is available for 344 use in path computation and LSP signaling just like any other TE link. 346 3.1. IGP Instance Identification 348 The mechanism described so far allows an Ingress LSR to indicate that 349 an LSP is to be used as a TE link and allows the Ingress and Egress 350 LSRs to exchange addresses or identifiers for that TE link, during 351 LSP setup. 353 However, it is also necessary to indicate into which instance of the 354 IGP the advertisement should be made. This is only necessary if the 355 LSP is to be advertised as a TE link into a different instance of the 356 IGP, and the default behavior may safely be left with the LSP 357 advertised into the same instance of the IGP (that is, FA behavior). 359 Indication of the IGP in which the advertisement is to be made first 360 requires that a 32-bit identifier be assigned to each of the IGP 361 instances within a network, and that Ingress and Egress LSRs have the 362 same understanding of these numbers. This is a management 363 configuration exercise outside the scope of this document. 365 Once these numbers have been assigned, they MAY be signaled as 366 additional information in the LSP_TUNNEL_INTERFACE_ID object to 367 indicate to which instance of the IGP the object applies. 369 The IGP instance identifier value of 0xffffffff is reserved to 370 indicate that the TE link SHOULD be advertised into the same instance 371 of the IGP as was used to establish the LSP. Similarly, absence of 372 the IGP instance identifier means that an FA is to be established (in 373 the same IGP instance). 375 3.2. LSP advertisement and Usage Identification 377 As mentioned earlier, the Egress node also needs to know if it needs 378 to create a full routing adjacency or forwarding adjacency or just 379 need to treat the LSP as a local virtual link. The extensions defined 380 in the following also specify the LSP advertisement and usage 381 treatment. 383 It is not mutually exclusive whether the LSP has routing adjacency 384 and whether it has forwarding adjacency. The LSP can have both 385 routing and forwarding adjacency. In this case, the LSP can be used 386 to carry both pure IP datagram packets and MPLS labeled packets. If 387 the LSP has only forwarding adjacency, it is used as TE-link to carry 388 only MPLS labeled packets. If the LSP has only routing adjacency, it 389 is used as IP link to carry only pure IP datagram packets. 391 It is mutually exclusive whether the LPS has routing adjacency and 392 whether it is treated as a local virtual link. Likewise, it is 393 mutually exclusive whether the LSP has forwarding adjacency and 394 whether it is treated as a local virtual link. 396 3.3. Bundling 398 It is possible to treat LSPs as component links and to bundle them 399 into a single TE link. However there is currently no way to signal 400 that an LSP will be used as part of a bundle and to identify the 401 bundled link to which the LSP is supposed to belong. 403 Each LSP that is to form a component link is signaled using the 404 LSP_TUNNEL_INTERFACE_ID object to identify the TE link bundle to 405 which the LSP will belong. Thus multiple LSPs may be signaled with 406 the same address/identifier in the LSP_TUNNEL_INTERFACE_ID object. 407 When the LSP is to form a component link, the LSP_TUNNEL_INTERFACE_ID 408 object MUST also contain an additional TLV to identify the component 409 link. This may be a numbered or unnumbered identifier. 411 Multiple LSPs may be signaled with the same address/identifier in the 412 LSP_TUNNEL_INTERFACE_ID object. 414 3.4. LSP_TUNNEL_INTERFACE_ID Object 416 The LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] has a class 417 number of 193, which designates that a node that does not understand 418 the object SHOULD ignore the object but forward it, unexamined and 419 unmodified, in all messages resulting from this message. 421 [RFC3477] defines one class type to indicate an unnumbered interface 422 identifier. This document defines three new class types as follows. 424 C-Type Meaning Reference 425 --------------------------------------------------------------------- 426 1 Unnumbered interface identifier [RFC3477] 427 2 (TBD by IANA) IPv4 interface identifier with target 2.2.2 428 3 (TBD by IANA) IPv6 interface identifier with target 2.2.3 429 4 (TBD by IANA) Unnumbered interface with target 2.2.4 431 Multiple instances of the LSP_TUNNEL_INTERFACE_ID object with C-Type 432 values 2, 3 or 4 MAY appear in any one Path or Resv message, in which 433 case, each MUST have a different value for the Target IGP Instance 434 field. A Path or Resv message MUST NOT contain more than one 435 instance of the LSP_TUNNEL_INTERFACE_ID object with C-Type 1, and if 436 such an object is present, other instances of the object with any 437 other C-Type value MUST NOT have Target IGP Instance set to 438 0xffffffff. 440 3.4.1. Unnumbered link 442 The unnumbered link identifier defined by [RFC3477] is not changed by 443 this document. Its usage also remains the same. That is, when 444 present in a Path message it indicates that the LSP being established 445 SHOULD be advertised by the egress LSR as a TE link, and that 446 unnumbered link identifier is the ingress' identifier for the TE link. 448 Note that since this form of the object does not contain a target IGP 449 instance identifier it cannot identify a specific instance of the IGP 450 into which this TE link should be advertised. Similarly, LSP 451 advertisement and usage treatment also needs to be specified. Thus, 452 when C-Type 1 is used, the TE link SHOULD be advertised only into the 453 same instance of the IGP as was used to create the LSP. That is, the 454 use of C-Type 1 is unchanged from [RFC3477] and is used to create an 455 unnumbered Forwarding Adjacency. 457 This object can appear in either a Path message or a Resv message. 458 In the former case, we call it the "Forward Interface ID" for that 459 LSP; in the latter case, we call it the "Reverse Interface ID" for 460 the LSP. 462 A Path or Resv message MUST have only one instance of this object 463 with C-Type 1. 465 3.4.2. IPv4 numbered link 467 A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is defined 468 to carry an IPv4 numbered interface address and to indicate into 469 which instance of the IGP the consequent TE link should be advertised. 471 The format of the object is as shown below. 473 C-NUM = 193, C-Type = 2(TBD by IANA) 474 0 1 2 3 475 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 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | IPv4 Interface Address (32 bits) | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Target IGP Instance (32 bits) | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 |ACTION | PADDING | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | TLVs | 484 ~ ~ 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 ACTION: This field specifies how the LSP advertisement and usage 488 treatment. It indicates if the egress LSR needs to create a full 489 routing adjacency or forwarding adjacency or just need to treat the 490 LSP as a local virtual link. It takes the following values: 492 "0000": LSP is an FA and is only advertised into the MPLS-TE topology. 493 We should note that it assures the backward compatibility with the 494 method to exchange unnumbered FA information described in [RFC3477]. 496 "0001": LSP is an RA and is only advertised into the IP network. 498 "0010": LSP is an RA and is advertised in both IP and MPLS-TE 499 topologies. 501 "0011": LSP is neither the FA nor RA and is to be used as a local 502 virtual link. In this case the LSP is advertised neither in IP nor 503 MPLS topology. 505 The Padding MUST be set to zero on transmission, SHOULD be ignored 506 and forwarded unchanged, and SHOULD be ignored on receipt. 508 This object can appear in either a Path message or a Resv message. 509 In the former case, we call it the "Forward Interface Address" for 510 that LSP; in the latter case, we call it the "Reverse Interface 511 Address" for the LSP. 513 3.4.3. IPv6 numbered link 515 A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is defined 516 to carry an IPv6 numbered interface address and to indicate into 517 which instance of the IGP the consequent TE link should be advertised. 519 The format of the object is as shown below. 521 C-NUM = 193, C-Type = 3(TBD by IANA) 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | IPv6 Interface Address (128 bits) | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | IPv6 Interface Address (128 bits) | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | IPv6 Interface Address (128 bits) | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | IPv6 Interface Address (128 bits) | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Target IGP Instance (32 bits) | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 |ACTION | PADDING | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | TLVs | 538 ~ ~ 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 This object can optionally appear in either a Path message or a Resv 542 message. In the former case, we call it the "Forward Interface 543 Address" for that LSP; in the latter case, we call it the "Reverse 544 Interface Address" for the LSP. 546 3.4.4. Unnumbered link with target IGP instance identifier 548 A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is defined 549 to carry an unnumbered interface identifier and to indicate into 550 which instance of the IGP the consequent TE link should be advertised. 551 This does not deprecate the use of C-Type 1, but extends its utility. 553 The format of the object is as shown below. 555 C-NUM = 193, C-Type = 4(TBD by IANA) 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | LSR's Router ID | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Interface ID (32 bits) | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Target IGP Instance (32 bits) | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 |ACTION | PADDING | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | TLVs | 568 ~ ~ 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 This object can optionally appear in either a Path message or a Resv 572 message. In the former case, we call it the "Forward Interface ID" 573 for that LSP; in the latter case, we call it the "Reverse Interface 574 ID" for the LSP. 576 3.4.5. Message Formats 578 [RFC3477] does not state where in the Path message or Resv message 579 the LSP_TUNNEL_INTERFACE_ID object should be placed. Since [RFC3209] 580 states that all implementations are to handle all objects received in 581 any order, this is not a problem. However, it is RECOMMENDED that the 582 LSP_TUNNEL_INTERFACE_ID object(s) be placed in the Path message 583 immediately after the SENDER_TSPEC object, and in the Resv message 584 immediately after the FILTER_SPEC object. 586 3.5. TLVs 588 All TLVs of the LSP_TUNNEL_INTERFACE_ID object have the following 589 format. 591 0 1 2 3 592 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 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Type (16 bits) | Length (16 bits) | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Value (variable) | 597 ~ ~ 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 The length field contains the total length of the TLV including the 601 Type and Length fields in bytes A value field whose length is not a 602 multiple of four MUST be zero-padded so that the TLV is four-byte 603 aligned. 605 This document defines two Type values to be used to specify the 606 component link identifier that the sending LSR has assigned to the 607 LSP if it forms part of a TE link bundle. The consequent TLV formats 608 are shown in the next sections. 610 3.5.1. Unnumbered Component Link Identifier 612 0 1 2 3 613 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 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Type = 1 | Length = 8 | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Component Link Identifier (32 bits) | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 This TLV is present if the signaled LSP is to be used as an 621 unnumbered component link of a bundled TE link. In this case, the 622 identifier (numbered or unnumbered) in the main body of the 623 LSP_TUNNEL_INTERFACE_ID object indicates the TE link bundle of which 624 this LSP is a component, and the Component Link Identifier of this 625 TLV specifies the unnumbered identifier that is assigned to this 626 component link within the bundle. 628 This TLV MUST NOT be present in the same instance of the 629 LSP_TUNNEL_INTERFACE_ID object as a TLV with type 2 (numbered 630 component link identifier). 632 3.5.2. IPv4 Numbered Component Link Identifier 634 0 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Type = 2 | Length = 8 | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | IPv4 Address (32 bits) | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 This TLV is present if the signaled LSP is to be used as a numbered 643 component link of a bundled TE link. In this case, the identifier 644 (numbered or unnumbered) in the main body of the 645 LSP_TUNNEL_INTERFACE_ID object indicates the TE link bundle of which 646 this LSP is a component, and the IPv4 Address field of this TLV 647 specifies the numbered identifier that is assigned to this component 648 link within the bundle. 650 This TLV MUST NOT be present in the same instance of the 651 LSP_TUNNEL_INTERFACE_ID object as a TLV with type 1 (unnumbered 652 component link identifier). 654 3.6. LSA advertisement 656 The ingress and egress LSRs MAY advertise link state associated with 657 TE links created as described above. The link state may be 658 advertised in either the same IGP instance as used to compute and 659 signal the path for the LSPs that support the TE links, or another 660 IGP instance. In the former case, the address space for the link 661 state MUST be the same as that used to establish the LSPs. In the 662 latter case, the address space for the link state MAY be different, 663 which means that addresses already allocated in the IGP instance used 664 to establish the LSPs MAY be used by the advertised TE link without 665 any ambiguity. 667 In the IGP the TE Router ID of the ingress LSR is taken from the 668 Tunnel Sender Address in the Sender Template object. It is assumed 669 that the ingress LSR knows the TE Router ID of the egress LSR since 670 it has chosen to establish an LSP to that LSR and plans to use the 671 LSP as a TE link. 673 The link interface addresses or link interface identifiers for the 674 forward and reverse direction links are taken from the 675 LSP_TUNNEL_INTREFACE_ID object on the Path and Resv messages 676 respectively. 678 Address overlap checking for these objects MUST be turned off when 679 the LSA is advertised into a IGP instance different from the one used 680 to establish the LSP because the addresses MAY be allocated in both 681 domains. 683 4. Applicability Statement 685 The method is applicable for both hierarchical LSPs [RFC4206] and LSP 686 stitching [STITCH]. 688 5. Backward Compatibility Considerations 690 The method does not impact the method to exchange unnumbered FA 691 information described in [RFC3477]. That mechanism can be safely 692 used in combination with the new mechanisms described here and is 693 functionally equivalent to using the new C-Type indicating an 694 unnumbered link with target IGP instance identifier with the Target 695 IGP Instance value set to 0xffffffff. 697 This method obsoletes the method to exchange the numbered FA 698 information described in [RFC4206]. This is not believed to be an 699 issue as an informal survey indicated that dynamically signaled 700 numbered FAs had not been deployed. Indeed it was the attempt to 701 implement numbered FAs that gave rise to the work on this document. 703 6. Security Considerations 705 [RFC3477] points out that one can argue that the use of the extra 706 interface identifier that it provides could make an RSVP message 707 harder to spoof. In that respect, the minor extensions to the 708 protocol made in this document do not constitute an additional 709 security risk, but could also be said to improve security. 711 It should be noted that the ability of an ingress LSR to request that 712 an egress LSR advertise an LSP as a TE link MUST be subject to 713 appropriate policy checks at the egress LSR. That is, the egress LSR 714 MUST NOT automatically accept the word of the ingress unless it is 715 configured with such a policy. 717 7. IANA Considerations 719 This document defines three new C-Types for the 720 LSP_TUNNEL_INTERFACE_ID object. The C-Types for this object are 721 managed by IANA, and IANA is requested to assign values to the new C- 722 Types as tabulated in section 2.2 and described in sections 2.2.2, 723 2.2.3 and 2.2.4. 725 8. Acknowledgement 727 The authors would like to thank John Drake and Yakov Rekhter for 728 their valuable discussions and comments. 730 Funding for the RFC Editor function is currently provided by the 731 Internet Society. 733 9. References 735 9.1. Normative References 737 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 738 Requirement Levels", BCP 14, RFC 2119, March 1997. 740 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. 741 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 742 Tunnels", RFC 3209, December 2001. 744 [RFC3477] Kompella, K. and Rekhter, Y., "Signalling Unnumbered Links 745 in Resource ReSerVation Protocol - Traffic Engineering 746 (RSVP-TE)", RFC 3477, January 2003. 748 [RFC4201] Kompella, K., Rekhter, Y., and Berger, L.," Link Bundling 749 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 751 [RFC4206] Kompella, K. and Y. Rekhter, "LSP Hierarchy with 752 Generalized MPLS TE", RFC 4206, October 2005. 754 [STITCH] Ayyangar, A. and J.P. Vasseur, "Label Switched Path 755 Stitching with Generalized MPLS Traffic Engineering", 756 draft-ietf-ccamp-lsp-stitching, (work in progress). 758 9.2. Informative References 760 [RFC3630] Katz, D., Kompella, K. and Yeung, D., "Traffic Engineering 761 (TE) Extensions to OSPF Version 2", RFC 3630, September 762 2003. 764 [RFC4204] Lang, J. (Ed.), "Link Management Protocol (LMP)", RFC 765 4204, October 2005. 767 [MLN] Shiomoto, K., et al, " Requirements for GMPLS-based multi- 768 region and multi-layer networks (MRN/MLN)", draft-ietf- 769 ccamp-gmpls-mln-reqs, (work in progress). 771 Author's Addresses 773 Kohei Shiomoto 774 NTT Network Service Systems Laboratories 775 3-9-11 Midori 776 Musashino, Tokyo 180-8585 777 Japan 778 Phone: +81 422 59 4402 779 Email: shiomoto.kohei@lab.ntt.co.jp 781 Richard Rabbat 782 Google Inc. 783 Email: rabbat@alum.mit.edu 785 Arthi Ayyangar 786 Nuova Systems 787 2600 San Tomas Expressway 788 Santa Clara, CA 95051 789 Email: arthi@nuovasystems.com 791 Adrian Farrel 792 Old Dog Consulting 793 EMail: adrian@olddog.co.uk 795 Zafar Ali 796 Cisco Systems, Inc. 797 2000 Innovation Drive 798 Kanata, Ontario, K2K 3E8 799 Canada. 800 EMail: zali@cisco.com 802 Intellectual Property Statement 804 The IETF takes no position regarding the validity or scope of any 805 Intellectual Property Rights or other rights that might be claimed to 806 pertain to the implementation or use of the technology described in 807 this document or the extent to which any license under such rights 808 might or might not be available; nor does it represent that it has 809 made any independent effort to identify any such rights. Information 810 on the procedures with respect to rights in RFC documents can be 811 found in BCP 78 and BCP 79. 813 Copies of IPR disclosures made to the IETF Secretariat and any 814 assurances of licenses to be made available, or the result of an 815 attempt made to obtain a general license or permission for the use of 816 such proprietary rights by implementers or users of this 817 specification can be obtained from the IETF on-line IPR repository at 818 http://www.ietf.org/ipr. 820 The IETF invites any interested party to bring to its attention any 821 copyrights, patents or patent applications, or other proprietary 822 rights that may cover technology that may be required to implement 823 this standard. Please address the information to the IETF at 824 ietf-ipr@ietf.org 826 Copyright Statement 828 Copyright (C) The IETF Trust (2007). This document is subject to the 829 rights, licenses and restrictions contained in BCP 78, and except as 830 set forth therein, the authors retain all their rights. 832 This document and the information contained herein are provided on an 833 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 834 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 835 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 836 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 837 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 838 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.