idnits 2.17.1 draft-ietf-ccamp-lsp-hierarchy-bis-03.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 983. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 954. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 961. ** 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 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 125 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 (February 22, 2008) is 5901 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 58, but not defined == Missing Reference: 'MLN-REQ' is mentioned on line 300, but not defined == Missing Reference: 'RFC4726' is mentioned on line 182, but not defined == Missing Reference: 'RFC4105' is mentioned on line 227, but not defined == Missing Reference: 'RFC3630' is mentioned on line 263, but not defined == Missing Reference: 'RFC3477' is mentioned on line 831, but not defined == Missing Reference: 'RFC4201' is mentioned on line 333, but not defined == Missing Reference: 'RFC4204' is mentioned on line 364, but not defined == Missing Reference: 'RFC3209' is mentioned on line 704, but not defined Summary: 2 errors (**), 0 flaws (~~), 12 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 (Juniper Networks) 5 Proposed Category: Proposed Standard A. Farrel (Old Dog Consulting) 6 Z. Ali (Cisco Systems, Inc.) 7 Expires: August 2008 February 22, 2008 9 Procedures for Dynamically Signaled 10 Hierarchical Label Switched Paths 11 draft-ietf-ccamp-lsp-hierarchy-bis-03.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that 16 any applicable patent or other IPR claims of which he or she is 17 aware have been or will be disclosed, and any of which he or she 18 becomes aware will be disclosed, in accordance with Section 6 of 19 BCP 79. 21 Internet-Drafts are working documents of the Internet 22 Engineering Task Force (IETF), its areas, and its working groups. 23 Note that other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other 28 documents at any time. It is inappropriate to use Internet- 29 Drafts as reference material or to cite them other than as "work 30 in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on August 22,2008. 40 Abstract 42 This document discusses topics related to hierarchical and 43 stitched Generalized Multiprotocol Label Switching (GMPLS) Label 44 Switched Paths (LSPs). It describes extensions to allow an 45 egress to identify that a bi-directional LSP will be used as a 46 dynamically signaled Forwarding Adjacency LSP (FA-LSP) or as a 47 Routing Adjacency (RA). In addition, the document also discusses 48 the issue of how to indicate that an LSP should be advertised as 49 a traffic engineering (TE) link into a different instance of the 50 IGP, and how to identify the instance that should be used. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 55 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 56 "OPTIONAL" in this document are to be interpreted as described 57 in [RFC2119]. 59 Table of Contents 61 1. Introduction and Problem Statement..........................3 62 1.1. LSP Hierarchy............................................3 63 1.2. LSP advertisement and Usage...............................4 64 1.3. Problem Statement........................................6 65 1.4. Current Approaches and Shortcomings.......................8 66 1.5. Contents of This Document.................................9 67 2. Revision history...........................................9 68 2.1. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00.9 69 2.2. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-01.9 70 2.3. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-02.10 71 3. Proposed Solution..........................................10 72 3.1. IGP Instance Identification...............................11 73 3.2. LSP advertisement and Usage Identification................11 74 3.3. Bundling.................................................12 75 3.4. LSP_TUNNEL_INTERFACE_ID Object............................12 76 3.4.1. Unnumbered link.........................................13 77 3.4.2. IPv4 numbered link......................................14 78 3.4.3. IPv6 numbered link......................................15 79 3.4.4. Unnumbered link with target IGP instance identifier......16 80 3.4.5. Message Formats........................................16 81 3.5. TLVs.....................................................17 82 3.5.1. Unnumbered Component Link Identifier....................17 83 3.5.2. IPv4 Numbered Component Link Identifier.................18 84 3.6. LSA advertisement........................................18 85 4. Applicability Statement.....................................19 86 5. Backward Compatibility Considerations.......................19 87 6. Security Considerations.....................................19 88 7. IANA Considerations........................................20 89 8. Acknowledgement............................................20 90 9. References.................................................20 91 9.1. Normative References.....................................20 92 9.2. Informative References....................................20 93 Author's Addresses............................................21 94 Intellectual Property Statement................................22 95 Copyright Statement...........................................23 97 1. Introduction and Problem Statement 99 1.1. LSP Hierarchy 101 LSP hierarchy has been developed to improve the scalability of 102 Generalized Multi-Protocol Label Switching (GMPLS) by allowing 103 Label Switched Paths (LSPs) to be aggregated into a hierarchy of 104 such LSPs [RFC4206]. An LSP may be advertised as a traffic 105 engineering (TE) link for use within the same instance of the 106 control plane as was used to set up the LSP. This TE link is 107 called a Forwarding Adjacency (FA), and the LSP is known as an 108 FA-LSP. 110 [RFC4206] defines the operation as follows for a numbered FA: 112 1. The ingress signals the LSP using a /31 sender address that it 113 allocates as the source address in the signaling message 114 (tunnel sender address in the Sender Template object of the 115 Path message), and targeting the TE router ID of the egress 116 (destination address in the Sender object of the Path 117 message). 119 2. The egress sets up the LSP using normal procedures and 120 allocating the partner address of the assigned /31 address in 121 the local interface address. 123 3. The ingress then forms a Forwarding Adjacency (FA) out of that 124 LSP by advertising it as a Traffic Engineering (TE) link using 125 the routing protocol (OSPF/ISIS) and using the /31 address to 126 identify the local end of the TE link. 128 4. When the egress receives the TE link advertisement, it checks 129 the Link-ID address of the TE advertisement against its own TE 130 Router ID. If it matches its own TE Router ID, the egress 131 checks the advertising router ID of the TE advertisement 132 against the ingress addresses of all LSPs for which it is the 133 egress and finds the address match with the advertising router 134 ID of the TE advertisement. 136 5. The egress then advertises the FA LSP as a TE link setting the 137 advertising TE Router ID in the Link-ID and the partner 138 address of the assigned /31 address in the local interface 139 address. 141 Nesting of LSPs originated by other LSRs into that LSP can be 142 achieved by using the label stack construct. 144 1.2. LSP advertisement and Usage 146 There are three different ways in which traffic can be forwarded 147 to 149 There are different ways in which an LSP can be used to carry 150 traffic and potentially advertised as a link by a routing 151 protocol. 153 First, the LSP can be used either as a link inside or outside 154 the network that was used to form the LSP. In the former case, 155 the LSP can carry traffic that could have been routed down the 156 TE links that are navigated by the LSP. In the latter case, it 157 is used by a client network, which is provided on top of the 158 network [MLN-REQ]. It can provide a new, virtual, point-to-point 159 link in a client network. The former case can only be achieved 160 in packet networks as they are the only type of network that 161 supports nesting of LSPs within the same technology LSP, but the 162 latter case is applicable to all client/server network 163 relationships such as IP over MPLS, or packet over optical. 165 Second, the link formed by the LSP can be advertised by the 166 routing protocol as available to carry traffic, or can be kept 167 as a private link known only to the head and tail end LSRs. 169 These two options give rise to four possible combinations as 170 follows. 172 1. The LSP is created and advertised as a TE link in the same 173 instance of the routing protocol as was used to advertise the 174 links that it traverses. This is a Forwarding Adjacency as 175 described in [RFC4206]. Note that no routing adjacency is formed 176 over the LSP. 178 2. The LSP is created and made available to carry traffic in the 179 same network as the links that it traverses, but it is not 180 advertised. The availability of the LSP is private to the end 181 points. This is a hierarchical LSP, but not an FA. It might be 182 used for inter-domain traffic engineering [RFC4726]. 184 3. The LSP is created as before, but is advertised as a link in 185 another instance of the routing protocol. This method of 186 operation is particular to client/server networks and especially 187 multi-layer networks [MLN-REQ], [PCE-INTER-LAYER-REQ]. 189 4. An LSP can be created and used by a client network without 190 being advertised in the client network routing protocol. Just as 191 in case 2, the existence of the LSP as a protocol tunnel is 192 known only to the tunnel LSP points which are nodes in the 193 client network. 195 Notes: 197 a. Case 1 includes the multi-layer traffic engineering scenario 198 where a single instance of the routing protocol is used across 199 both layers. This situation was particularly envisaged in 200 [RFC4206]. 202 b. The example cited in case 2 is special because the 203 hierarchical LSP is edge-to-edge within a particular domain and 204 no TE links are advertised outside of the domain (by definition 205 of the domain). The purpose of the TE link is to carry traffic 206 across the domain and not to carry intra-domain traffic. 207 Advertising the TE link within the domain might cause internal 208 traffic to take longer paths as it seeks to use the hierarchical 209 LSP. 211 c. Case 3 is not the only option for the multi-layer network as 212 explained in Note a. 214 d. The client network in case 3 may be a different technology TE 215 network (such as a GMPLS TDM network that operates over a GMPLS 216 WDM network, or an MPLS-TE network operating over a GMPLS 217 optical network), a same-technology TE network where LSP nesting 218 is allowed (for example, an MPLS-TE network operating over 219 another MPLS-TE network), or a non-TE network (such as an IP 220 network operating over an MPLS-TE or GMPLS network of any 221 technology). Thus, the link advertised may be a TE link, or a 222 routing link. In the second instance, the LSP is used to form a 223 virtual adjacency between two non-neighboring IP routers (a 224 Routing Adjacency - RA) forming IGP shortcuts. 226 e. IGP shortcuts are precluded when the LSP end-points reside 227 within different IGP areas [RFC4105]. 229 f. IGP shortcuts should be treated with extreme caution when 230 they are created and used in the same IP/MPLS network. Thus, it 231 may be more common to use them as described in case 4 and even 232 in this case, only when the egress of the LSP is the final 233 destination of the traffic carried. 235 g. It would be unusual although not impossible to use a 236 hierarchical LSP as an IGP shortcut within the control plane. 238 1.3. Problem Statement 240 The extensions described in this document are intended for 241 dynamically signaled bi-directional Forwarding Adjacency LSPs 242 (FA-LSPs). In particular this document addresses the following 243 points: 245 (1) How to let the egress node know that this bi-directional 246 LSP needs to be advertised as an FA, or as an RA, or as an 247 FA and RA or is a local virtual link only for the use of 248 the ingress and egress nodes. 250 (2) How to indicate that a new LSP should be treated as part of 251 a TE link bundle and advertised as part of that bundle. 253 (3) How to identify the routing instance in which such an 254 advertisement should happen. 256 We should note that these aspects are equally applicable to both 257 numbered and unnumbered TE links. 258 In order for the egress of an LSP to be able to advertise the 259 LSP as a TE link it needs to know that such an advertisement is 260 desirable, and it also needs to know the TE Router ID of the 261 ingress LSR. (Please recall that the Router ID of the other end 262 of the link is set in the Link-ID sub-TLV of the Link TLV of the 263 TE Opaque-LSA [RFC3630].) If the LSP is to form part of a TE 264 link bundle, the egress must also know the identity of the 265 bundle. 267 When the mechanism set out in section 1.1 is used for numbered 268 FAs, there is no way to carry the TE Router ID of the ingress 269 LSR in the RSVP signaling message (Path message) and there is no 270 way to indicate that the new LSP is to be used as an FA LSP. 271 Therefore the egress LSR has to wait to receive a routing 272 protocol advertisement of the TE link flooded by the ingress to 273 learn about the new TE link and to deduce that the LSP forms 274 that TE link. The egress must learn the TE Router ID of the 275 ingress node before it can advertise the FA as described in 276 Section 1.2. Note further, that in this approach, the egress LSR 277 must search potentially many LSPs every time it receives an 278 advertisement for a new TE link. 280 [RFC3477] defines a different method for the exchange of 281 information in the signaling protocol during the establishment 282 of LSPs that will be advertised as unnumbered TE links. If the 283 LSP_TUNNEL_INTERFACE_ID object is present, it indicates that the 284 LSP is to be advertised as a TE link, and it contains the TE 285 Router ID of the ingress LSR. This mechanism resolves many of 286 the issues listed above, and provides a solution for unnumbered 287 TE links, however, the LSP_TUNNEL_INTERFACE_ID object cannot be 288 used for numbered FAs as currently defined, and so the problem 289 remains for numbered TE links. 291 Related to the above problem, a few key observations are worth 292 noting: 294 6. The term FA is applicable only when an LSP is created and used 295 as a TE link in the same instance of the IGP. [RFC4206] did 296 not consider scenarios where an LSP is created (and 297 maintained) by one instance of the IGP, and is used as a (TE) 298 link by another instance of IGP. This leaves open the question 299 of advertising a TE link into a different instance of the IGP 300 as is needed in multi-region/multi-layer networks [MLN-REQ], 301 and how to identify which instance of the IGP should be used. 302 In addition, the TE link advertised into the different IGP 303 instance may be associated with an IGP neighbor adjacency. We 304 call it a routing adjacency (RA). The decision as to whether 305 the link should be advertised to MPLS TE topology or IP 306 topology or both depends on operator policy. Therefore, a 307 mechanism to indicate the choice to the Egress node is needed. 309 7. [RFC4206] provides a way to exchange numbered identifiers for 310 the TE link, but this does not clearly state that the Ingress 311 node can use presence of the LSP_TUNNEL_INTERFACE_ID object as 312 a trigger for TE link advertisement at the egress node. 314 8. It is important to note that an LSP that is set up in a server 315 GMPLS transport network and advertised as a TE link in a 316 client MPLS data network is NOT an FA-LSP according to the 317 definitions explained in point 1, above. This is the case 318 regardless of whether the GMPLS network is packet- or non- 319 packet-capable. 321 9. When an egress checks the address of the advertised TE link to 322 find the LSP sender (Recall step (4) as described in section 323 1.1), it must check the Link-ID address of all received TE 324 advertisements against its own TE Router ID. If it matches 325 its own TE Router ID, the egress checks the advertising router 326 ID of the TE advertisement against the ingress addresses of 327 all LSPs for which it is the egress. It is an assertion of 328 the authors that this method is not scalable due to the amount 329 of processing needed for all the TE Link State Advertisements 330 (LSAs). 332 10.Further, if a set of LSPs are to be bundled into a single TE 333 link [RFC4201] then not only is it necessary to identify to the 334 egress that the LSP will be advertised as part of a TE link, it 335 is also necessary to indicate the identity of the TE link. This 336 identity is distinct from the identity of the component link. 337 Thus, in this case an additional identifier needs to be signaled, 338 but none is currently available. 340 1.4. Current Approaches and Shortcomings 342 [RFC3477] provides a mechanism to exchange unnumbered 343 identifiers for the TE link during FA-LSP establishment, and 344 this can be used as a notification to the egress that the LSP 345 will be used as a TE link. So, for unnumbered TE links, there is 346 a well-defined indication available, and this could be 347 documented and used as a trigger for TE link advertisement by 348 the egress. 350 The use of unnumbered TE links may be arguably more sensible 351 than assigning numbers to FAs, especially in the case of large 352 networks. Some operators though prefer to consistently use 353 numbered TE links for both static and dynamic (that is, FA) TE 354 links in their networks. In the case of numbered TE links, 355 however, there is no available indication to allow the egress to 356 know that an LSP should be advertised as a TE link. 358 In addition, using unnumbered TE links does not address the 359 issue of advertising TE links into a different instance of the 360 IGP. There is no defined mechanism to identify whether it should 361 be advertised as an FA, a full Routing Adjacency (RA), or it 362 should be used as a local virtual link. 364 The Link Management Protocol (LMP) [RFC4204] could possibly be 365 run on remote adjacencies between the endpoints of an LSP. But 366 LMP peer discovery would be required for dynamic LMP peering and 367 is not currently specified. In addition, the concept of a 368 remote LMP adjacency remains unproven. Lastly, there would be a 369 requirement that all layers/regions in a MLN network run LMP. 370 This may not be the case in existing networks and would put 371 undue burden on the network operator to deploy another protocol. 373 1.5. Contents of This Document 375 This document provides a consolidated way of exchanging TE link 376 identifiers when an LSP is established through signaling. It 377 also provides a mechanism to allow the ingress to control 378 whether, and into which IGP instances, an LSP is advertised as 379 an FA and/ or RA by the egress. The proposed mechanism applies 380 equally to Hierarchical LSPs (H-LSPs) and Stitchable LSPs (S- 381 LSPs). 383 The method described below extends the method described in 384 [RFC3477], which is applied for an FA-LSP represented as an 385 unnumbered TE link. 387 2. Revision history 389 2.1. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00 391 o Fixed page formatting 393 o Updated author addresses 395 o Readability fixes 397 2.2. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-01 399 o Added indication of bundled link 401 o Added "ACTION" field, which obsoletes R and F bits 403 o Readability fixes 405 2.3. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-02 407 o Rewrite Section 1.2 408 o Updated author addresses 409 o Readability fixes 411 3. Proposed Solution 413 The following method allows the ingress and egress LSRs to 414 exchange the link addresses or link identifiers (including the 415 node ID) of the ends of a numbered or unnumbered TE link to be 416 formed from an LSP. It is an extension of the procedures 417 defined in [RFC3477] for unnumbered TE links. 419 If an ingress LSR that originates an LSP, intends to advertise 420 this LSP as a TE link in IS-IS or OSPF [RFC4206], the ingress 421 LSR MUST allocate an address or identifier to the TE link (just 422 like for any other TE link), and it MUST do this before the LSP 423 setup request is signaled. Moreover, the Path message used for 424 establishing the LSP that will be used to form the TE link MUST 425 contain the LSP_TUNNEL_INTERFACE_ID object (as extended and 426 described below), with the interface address or identifier 427 allocated by the ingress LSR. 429 If the Path message for the H-LSP/S-LSP contains the 430 LSP_TUNNEL_INTERFACE_ID object, then the egress LSR (assuming it 431 accepts the LSP request) MUST allocate an address or identifier 432 to the TE link that will be formed (just like for any other 433 numbered or unnumbered TE link). Furthermore, the Resv message 434 for the LSP MUST contain an LSP_TUNNEL_INTERFACE_ID object, with 435 the interface address or identifier allocated by the egress LSR. 437 In all cases where an LSP is to be advertised as a TE link, the 438 Tunnel Sender Address in the Sender Template Object of the Path 439 message MUST be set to the TE Router ID of the ingress LSR. We 440 should note that this is a change from the method described in 441 [RFC4206]. 443 Once the egress LSR has successfully sent a Resv message as 444 described above it SHOULD advertise the LSP as a TE link using 445 the addresses/identifiers exchanged. Once the Resv has been 446 processed by the ingress LSR and the LSP has been successfully 447 established, the ingress LSR SHOULD advertise the LSP as a TE 448 link using the addresses/identifiers exchanged. 450 Once the TE link advertisement has been flooded it is available 451 for use in path computation and LSP signaling just like any 452 other TE link. 454 3.1. IGP Instance Identification 456 The mechanism described so far allows an ingress LSR to indicate 457 that an LSP is to be used as a TE link and allows the ingress 458 and egress LSRs to exchange addresses or identifiers for that TE 459 link, during LSP setup. 461 However, it is also necessary to indicate into which instance of 462 the IGP the advertisement should be made. This is only 463 necessary if the LSP is to be advertised as a TE link into a 464 different instance of the IGP, and the default behavior may 465 safely be left with the LSP advertised into the same instance of 466 the IGP. 468 Indication of the IGP in which the advertisement is to be made 469 first requires that a 32-bit identifier be assigned to each of 470 the IGP instances within a network, and that ingress and egress 471 LSRs have the same understanding of these numbers. This is a 472 management configuration exercise outside the scope of this 473 document. 475 Once these numbers have been assigned, they MAY be signaled as 476 additional information in the LSP_TUNNEL_INTERFACE_ID object to 477 indicate to which instance of the IGP the object applies. 479 The IGP instance identifier value of 0xffffffff is reserved to 480 indicate that the TE link SHOULD be advertised into the same 481 instance of the IGP as was used to establish the LSP. Similarly, 482 absence of the IGP instance identifier means that an FA is to be 483 established (in the same IGP instance). 485 3.2. LSP advertisement and Usage Identification 487 As mentioned earlier, the egress node also needs to know if it 488 needs to create a full routing adjacency or forwarding adjacency 489 or just need to treat the LSP as a local virtual link. The 490 extensions defined in the following also specify the LSP 491 advertisement and usage treatment. 493 It is not mutually exclusive whether the LSP has routing 494 adjacency and whether it has forwarding adjacency. The LSP can 495 have both routing and forwarding adjacency. In this case, the LSP 496 can be used to carry both pure IP datagram packets and MPLS 497 labeled packets. If the LSP has only forwarding adjacency, it is 498 used as TE-link to carry only MPLS labeled packets. If the LSP 499 has only routing adjacency, it is used as IP link to carry only 500 pure IP datagram packets. 501 Note that the LSP which has only forwarding adjacency is useful 502 to improve the scalability. Suppose that distant PSC domains are 503 connected by a set of lower-layer LSPs created in the optical 504 domain (TDM, LSC, or FSC). We do not require routing adjacency on 505 all such lower-layer LSPs as long as we have control plane 506 connectivity through a subset of lower-layer LSPs which have 507 routing adjacency. We reduce the amount of overhead of IGP 508 protocol processing on the LSPs which do not have routing 509 adjacency. 510 It is mutually exclusive whether the LPS has routing adjacency 511 and whether it is treated as a local virtual link. Likewise, it 512 is mutually exclusive whether the LSP has forwarding adjacency 513 and whether it is treated as a local virtual link. 515 3.3. Bundling 517 It is possible to treat LSPs as component links and to bundle 518 them into a single TE link. However there is currently no way to 519 signal that an LSP will be used as part of a bundle and to 520 identify the bundled link to which the LSP is supposed to belong. 522 Each LSP that is to form a component link is signaled using the 523 LSP_TUNNEL_INTERFACE_ID object to identify the TE link bundle to 524 which the LSP will belong. Thus multiple LSPs may be signaled 525 with the same address/identifier in the LSP_TUNNEL_INTERFACE_ID 526 object. When the LSP is to form a component link, the 527 LSP_TUNNEL_INTERFACE_ID object MUST also contain an additional 528 TLV to identify the component link. This may be a numbered or 529 unnumbered identifier. 531 Multiple LSPs may be signaled with the same address/identifier 532 in the LSP_TUNNEL_INTERFACE_ID object. 534 3.4. LSP_TUNNEL_INTERFACE_ID Object 536 The LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] has a 537 class number of 193, which designates that a node that does not 538 understand the object SHOULD ignore the object but forward it, 539 unexamined and unmodified, in all messages resulting from this 540 message. 542 [RFC3477] defines one class type to indicate an unnumbered 543 interface identifier. This document defines three new class 544 types as follows. 546 C-Type Meaning 547 Reference 548 ---------------------------------------------------------------- 549 1 Unnumbered interface identifier [RFC3477] 550 2 (TBD by IANA) IPv4 interface identifier with target 2.2.2 551 3 (TBD by IANA) IPv6 interface identifier with target 2.2.3 552 4 (TBD by IANA) Unnumbered interface with target 2.2.4 554 Multiple instances of the LSP_TUNNEL_INTERFACE_ID object with C- 555 Type values 2, 3 or 4 MAY appear in any one Path or Resv message, 556 in which case, each MUST have a different value for the Target 557 IGP Instance field. A Path or Resv message MUST NOT contain 558 more than one instance of the LSP_TUNNEL_INTERFACE_ID object 559 with C-Type 1, and if such an object is present, other instances 560 of the object with any other C-Type value MUST NOT have Target 561 IGP Instance set to 0xffffffff. 563 3.4.1. Unnumbered link 565 The unnumbered link identifier defined by [RFC3477] is not 566 changed by this document. Its usage also remains the same. 567 That is, when present in a Path message it indicates that the 568 LSP being established SHOULD be advertised by the egress LSR as 569 a TE link, and that unnumbered link identifier is the ingress' 570 identifier for the TE link. 572 Note that since this form of the object does not contain a 573 target IGP instance identifier it cannot identify a specific 574 instance of the IGP into which this TE link should be advertised. 575 Similarly, LSP advertisement and usage treatment also needs to 576 be specified. Thus, when C-Type 1 is used, the TE link SHOULD be 577 advertised only into the same instance of the IGP as was used to 578 create the LSP. That is, the use of C-Type 1 is unchanged from 579 [RFC3477] and is used to create an unnumbered Forwarding 580 Adjacency. 582 This object can appear in either a Path message or a Resv 583 message. In the former case, we call it the "Forward Interface 584 ID" for that LSP; in the latter case, we call it the "Reverse 585 Interface ID" for the LSP. 587 A Path or Resv message MUST have only one instance of this 588 object with C-Type 1. 590 3.4.2. IPv4 numbered link 592 A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is 593 defined to carry an IPv4 numbered interface address and to 594 indicate into which instance of the IGP the consequent TE link 595 should be advertised. 597 The format of the object is as shown below. 599 C-NUM = 193, C-Type = 2(TBD by IANA) 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | IPv4 Interface Address (32 bits) | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Target IGP Instance (32 bits) | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 |ACTION | PADDING | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | TLVs | 610 ~ ~ 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 ACTION: This field specifies how the LSP advertisement and usage 614 treatment. It indicates if the egress LSR needs to create a full 615 routing adjacency or forwarding adjacency or just need to treat 616 the LSP as a local virtual link. It takes the following values: 618 "0000": LSP is an FA and is only advertised into the MPLS-TE 619 topology. We should note that it assures the backward 620 compatibility with the method to exchange unnumbered FA 621 information described in [RFC3477]. 623 "0001": LSP is an RA and is only advertised into the IP network. 624 "0010": LSP is an RA and FA and is advertised in both IP and 625 MPLS-TE topologies. 626 "0011": LSP is neither the FA nor RA and is to be used as a local 627 virtual link. In this case the LSP is advertised neither in IP 628 nor MPLS topology. 629 The Padding MUST be set to zero on transmission, SHOULD be 630 ignored and forwarded unchanged, and SHOULD be ignored on 631 receipt. 632 This object can appear in either a Path message or a Resv 633 message. In the former case, we call it the "Forward Interface 634 Address" for that LSP; in the latter case, we call it the 635 "Reverse Interface Address" for the LSP. 637 3.4.3. IPv6 numbered link 639 A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is 640 defined to carry an IPv6 numbered interface address and to 641 indicate into which instance of the IGP the consequent TE link 642 should be advertised. 644 The format of the object is as shown below. 645 C-NUM = 193, C-Type = 3(TBD by IANA) 646 0 1 2 3 647 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 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | IPv6 Interface Address (128 bits) | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | IPv6 Interface Address (128 bits) | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | IPv6 Interface Address (128 bits) | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | IPv6 Interface Address (128 bits) | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Target IGP Instance (32 bits) | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 |ACTION | PADDING | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | TLVs | 662 ~ ~ 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 This object can optionally appear in either a Path message or a 666 Resv message. In the former case, we call it the "Forward 667 Interface Address" for that LSP; in the latter case, we call it 668 the "Reverse Interface Address" for the LSP. 670 3.4.4. Unnumbered link with target IGP instance identifier 672 A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is 673 defined to carry an unnumbered interface identifier and to 674 indicate into which instance of the IGP the consequent TE link 675 should be advertised. This does not deprecate the use of C-Type 676 1, but extends its utility. 678 The format of the object is as shown below. 679 C-NUM = 193, C-Type = 4(TBD by IANA) 680 0 1 2 3 681 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 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | LSR's Router ID | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Interface ID (32 bits) | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Target IGP Instance (32 bits) | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 |ACTION | PADDING | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | TLVs | 692 ~ ~ 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 This object can optionally appear in either a Path message or a 696 Resv message. In the former case, we call it the "Forward 697 Interface ID" for that LSP; in the latter case, we call it the 698 "Reverse Interface ID" for the LSP. 700 3.4.5. Message Formats 702 [RFC3477] does not state where in the Path message or Resv 703 message the LSP_TUNNEL_INTERFACE_ID object should be placed. 704 Since [RFC3209] states that all implementations are to handle 705 all objects received in any order, this is not a problem. 706 However, it is RECOMMENDED that the LSP_TUNNEL_INTERFACE_ID 707 object(s) be placed in the Path message immediately after the 708 SENDER_TSPEC object, and in the Resv message immediately after 709 the FILTER_SPEC object. 711 3.5. TLVs 713 All TLVs of the LSP_TUNNEL_INTERFACE_ID object have the 714 following format. 716 0 1 2 3 717 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 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Type (16 bits) | Length (16 bits) | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Value (variable) | 722 ~ ~ 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 The length field contains the total length of the TLV including 726 the Type and Length fields in bytes A value field whose length 727 is not a multiple of four MUST be zero-padded so that the TLV is 728 four-byte aligned. 730 This document defines two Type values to be used to specify the 731 component link identifier that the sending LSR has assigned to 732 the LSP if it forms part of a TE link bundle. The consequent 733 TLV formats are shown in the next sections. 735 3.5.1. Unnumbered Component Link Identifier 737 0 1 2 3 738 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 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Type = 1 | Length = 8 | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Component Link Identifier (32 bits) | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 This TLV is present if the signaled LSP is to be used as an 746 unnumbered component link of a bundled TE link. In this case, 747 the identifier (numbered or unnumbered) in the main body of the 748 LSP_TUNNEL_INTERFACE_ID object indicates the TE link bundle of 749 which this LSP is a component, and the Component Link Identifier 750 of this TLV specifies the unnumbered identifier that is assigned 751 to this component link within the bundle. 753 This TLV MUST NOT be present in the same instance of the 754 LSP_TUNNEL_INTERFACE_ID object as a TLV with type 2 (numbered 755 component link identifier). 757 3.5.2. IPv4 Numbered Component Link Identifier 759 0 1 2 3 760 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 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Type = 2 | Length = 8 | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | IPv4 Address (32 bits) | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 This TLV is present if the signaled LSP is to be used as a 768 numbered component link of a bundled TE link. In this case, the 769 identifier (numbered or unnumbered) in the main body of the 770 LSP_TUNNEL_INTERFACE_ID object indicates the TE link bundle of 771 which this LSP is a component, and the IPv4 Address field of 772 this TLV specifies the numbered identifier that is assigned to 773 this component link within the bundle. 775 This TLV MUST NOT be present in the same instance of the 776 LSP_TUNNEL_INTERFACE_ID object as a TLV with type 1 (unnumbered 777 component link identifier). 779 3.6. LSA advertisement 781 The ingress and egress LSRs MAY advertise link state associated 782 with TE links created as described above. The link state may be 783 advertised in either the same IGP instance as used to compute 784 and signal the path for the LSPs that support the TE links, or 785 another IGP instance. In the former case, the address space for 786 the link state MUST be the same as that used to establish the 787 LSPs. In the latter case, the address space for the link state 788 MAY be different, which means that addresses already allocated 789 in the IGP instance used to establish the LSPs MAY be used by 790 the advertised TE link without any ambiguity. 792 In the IGP the TE Router ID of the ingress LSR is taken from the 793 Tunnel Sender Address in the Sender Template object. It is 794 assumed that the ingress LSR knows the TE Router ID of the 795 egress LSR since it has chosen to establish an LSP to that LSR 796 and plans to use the LSP as a TE link. 798 The link interface addresses or link interface identifiers for 799 the forward and reverse direction links are taken from the 800 LSP_TUNNEL_INTREFACE_ID object on the Path and Resv messages 801 respectively. 803 Address overlap checking for these objects MUST be turned off 804 when the LSA is advertised into a IGP instance different from 805 the one used to establish the LSP because the addresses MAY be 806 allocated in both domains. 808 4. Applicability Statement 810 The method is applicable for both hierarchical LSPs [RFC4206] 811 and LSP stitching [STITCH]. 813 5. Backward Compatibility Considerations 815 The method does not impact the method to exchange unnumbered FA 816 information described in [RFC3477]. That mechanism can be 817 safely used in combination with the new mechanisms described 818 here and is functionally equivalent to using the new C-Type 819 indicating an unnumbered link with target IGP instance 820 identifier with the Target IGP Instance value set to 0xffffffff. 822 This method obsoletes the method to exchange the numbered FA 823 information described in [RFC4206]. This is not believed to be 824 an issue as an informal survey indicated that dynamically 825 signaled numbered FAs had not been deployed. Indeed it was the 826 attempt to implement numbered FAs that gave rise to the work on 827 this document. 829 6. Security Considerations 831 [RFC3477] points out that one can argue that the use of the 832 extra interface identifier that it provides could make an RSVP 833 message harder to spoof. In that respect, the minor extensions 834 to the protocol made in this document do not constitute an 835 additional security risk, but could also be said to improve 836 security. 838 It should be noted that the ability of an ingress LSR to request 839 that an egress LSR advertise an LSP as a TE link MUST be subject 840 to appropriate policy checks at the egress LSR. That is, the 841 egress LSR MUST NOT automatically accept the word of the ingress 842 unless it is configured with such a policy. 844 7. IANA Considerations 846 This document defines three new C-Types for the 847 LSP_TUNNEL_INTERFACE_ID object. The C-Types for this object are 848 managed by IANA, and IANA is requested to assign values to the 849 new C-Types as tabulated in section 2.2 and described in 850 sections 2.2.2, 2.2.3 and 2.2.4. 852 8. Acknowledgement 854 The authors would like to thank John Drake and Yakov Rekhter for 855 their valuable discussions and comments. 856 Funding for the RFC Editor function is currently provided by the 857 Internet Society. 859 9. References 861 9.1. Normative References 863 [RFC2119]Bradner, S., "Key words for use in RFCs to Indicate 864 Requirement Levels", BCP 14, RFC 2119, March 1997. 866 [RFC3209]Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. 867 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 868 Tunnels", RFC 3209, December 2001. 870 [RFC3477]Kompella, K. and Rekhter, Y., "Signalling Unnumbered 871 Links in Resource ReSerVation Protocol - Traffic 872 Engineering (RSVP-TE)", RFC 3477, January 2003. 874 [RFC4201]Kompella, K., Rekhter, Y., and Berger, L.," Link 875 Bundling in MPLS Traffic Engineering (TE)", RFC 4201, 876 October 2005. 878 [RFC4206] Kompella, K. and Y. Rekhter, "LSP Hierarchy with 879 Generalized MPLS TE", RFC 4206, October 2005. 881 [STITCH] Ayyangar, A. and J.P. Vasseur, "Label Switched Path 882 Stitching with Generalized MPLS Traffic Engineering", 883 draft-ietf-ccamp-lsp-stitching, (work in progress). 885 9.2. Informative References 887 [RFC3630]Katz, D., Kompella, K. and Yeung, D., "Traffic 888 Engineering (TE) Extensions to OSPF Version 2", RFC 889 3630, September 2003. 891 [RFC4105]Le Roux, J.-L., Vassuer, J.-P., and Boyle, J. (Eds.), 892 "Requirements for Inter-Area MPLS Traffic Engineering", 893 RFC 4105, June 2005. 895 [RFC4204]Lang, J. (Ed.), "Link Management Protocol (LMP)", 896 RFC 4204, October 2005. 898 [RFC4726]Farrel, A., Vasseur, J.-P., and Ayyangar, A., " A 899 Framework for Inter-Domain Multiprotocol Label 900 Switching Traffic Engineering ", RFC 4726, November 901 2006. 903 [MLN-REQ]Shiomoto, K., et al, "Requirements for GMPLS-based 904 multi-region and multi-layer networks (MRN/MLN)", 905 draft-ietf-ccamp-gmpls-mln-reqs, (work in progress). 907 [PCE-INTER-LAYER-REQ] Oki, E. (Ed.), " PCC-PCE Communication 908 and PCE Discovery Requirements for Inter-Layer Traffic 909 Engineering ", draft-ietf-pce-inter-layer-req, (work in 910 progress). 912 Author's Addresses 914 Kohei Shiomoto 915 NTT Network Service Systems Laboratories 916 3-9-11 Midori 917 Musashino, Tokyo 180-8585 918 Japan 919 Phone: +81 422 59 4402 920 Email: shiomoto.kohei@lab.ntt.co.jp 921 Richard Rabbat 922 Google Inc. 923 Email: rabbat@alum.mit.edu 925 Arthi Ayyangar 926 Juniper Networks 927 1194 N. Mathilda Ave. 928 Sunnyvale, CA 94089 929 United States of America 930 Phone: 931 Email: arthi@juniper.net 933 Adrian Farrel 934 Old Dog Consulting 935 EMail: adrian@olddog.co.uk 937 Zafar Ali 938 Cisco Systems, Inc. 939 2000 Innovation Drive 940 Kanata, Ontario, K2K 3E8 941 Canada. 942 EMail: zali@cisco.com 944 Intellectual Property Statement 946 The IETF takes no position regarding the validity or scope of 947 any Intellectual Property Rights or other rights that might be 948 claimed to pertain to the implementation or use of the 949 technology described in this document or the extent to which any 950 license under such rights might or might not be available; nor 951 does it represent that it has made any independent effort to 952 identify any such rights. Information on the procedures with 953 respect to rights in RFC documents can be found in BCP 78 and 954 BCP 79. 956 Copies of IPR disclosures made to the IETF Secretariat and any 957 assurances of licenses to be made available, or the result of an 958 attempt made to obtain a general license or permission for the 959 use of such proprietary rights by implementers or users of this 960 specification can be obtained from the IETF on-line IPR 961 repository at http://www.ietf.org/ipr. 963 The IETF invites any interested party to bring to its attention 964 any copyrights, patents or patent applications, or other 965 proprietary rights that may cover technology that may be 966 required to implement this standard. Please address the 967 information to the IETF at ietf-ipr@ietf.org 969 Copyright Statement 971 Copyright (C) The IETF Trust (2008). This document is subject 972 to the rights, licenses and restrictions contained in BCP 78, 973 and except as set forth therein, the authors retain all their 974 rights. 976 This document and the information contained herein are provided 977 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 978 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 979 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 980 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 981 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 982 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 983 OR FITNESS FOR A PARTICULAR PURPOSE.