idnits 2.17.1 draft-ietf-ccamp-lsp-hierarchy-bis-00.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.3 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 711. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 695. ** The document has an RFC 3978 Section 5.3 Publication Limitation clause. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** 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 330 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 114 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 19, 2006) is 6554 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: 6 errors (**), 0 flaws (~~), 3 warnings (==), 7 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(Fujitsu) 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: October 2006 April 19, 2006 9 Procedures for Dynamically Signaled Hierarchical Label Switched Paths 10 draft-ietf-ccamp-lsp-hierarchy-bis-00.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 This document may only be posted in an Internet-Draft. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on October 19, 2006. 39 Abstract 41 This document addresses topics related to hierarchical and stitched 42 Generalized Multiprotocol Label Switching (GMPLS) Label Switched 43 Paths (LSPs). It describes extensions to allow an egress to identify 44 that a bi-directional LSP will be used as a dynamically signaled 45 Forwarding Adjacency LSP (FA-LSP) or Routing Adjacency (RA). In 46 addition, the document also addresses the issue of how to indicate 47 that an LSP should be advertised as a traffic engineering (TE) link 48 into a different instance of the IGP and how to identify the instance 49 that should be used. 51 Conventions used in this document 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in [RFC2119]. 57 Table of Contents 59 1. Introduction and Problem Statement.............................3 60 1.1. LSP Hierarchy.............................................3 61 1.2. LSP advertisement and Usage...............................4 62 1.3. Problem Statement.........................................4 63 1.4. Current Approaches and Shortcomings.......................6 64 1.5. Contents of This Document.................................6 65 2. Proposed Solution..............................................7 66 2.1. IGP Instance Identification...............................8 67 2.2. LSP advertisement and Usage Identification................8 68 2.3. LSP_TUNNEL_INTERFACE_ID Object............................8 69 2.3.1. Unnumbered link......................................9 70 2.3.2. IPv4 numbered link...................................9 71 2.3.3. IPv6 numbered link..................................11 72 2.3.4. Unnumbered link with target IGP instance identifier.11 73 2.3.5. Message Formats.....................................12 74 2.4. LSA advertisement........................................12 75 3. Applicability Statement.......................................13 76 4. Backward Compatibility Considerations.........................13 77 5. Security Considerations.......................................13 78 6. IANA Considerations...........................................14 79 7. Acknowledgement...............................................14 80 8. References....................................................14 81 8.1. Normative References.....................................14 82 8.2. Informative References...................................15 83 Author's Addresses...............................................15 84 Intellectual Property Statement..................................16 85 Disclaimer of Validity...........................................16 86 Copyright Statement..............................................17 88 1. Introduction and Problem Statement 90 1.1. LSP Hierarchy 92 LSP hierarchy has been developed to improve the scalability of 93 Generalized Multi-Protocol Label Switching (GMPLS) by allowing Label 94 Switched Paths (LSPs) to be aggregated into a hierarchy of such LSPs 95 [RFC4206]. An LSP may be advertised as a traffic engineering (TE) 96 link for use within the same instance of the control plane as was 97 used to set up the LSP. This TE link is called a Forwarding Adjacency 98 (FA), and the LSP is known as an FA-LSP. 100 [RFC4206] defines the operation as follows for a numbered FA: 102 1. The ingress signals the LSP using a /31 sender address that it 103 allocates as the source address in the signaling message (tunnel 104 sender address in the Sender Template object of the Path message), 105 and targeting the TE router ID of the egress (destination address 106 in the Sender object of the Path message). 108 2. The egress sets up the LSP using normal procedures and allocating 109 the partner address of the assigned /31 address in the local 110 interface address. 112 3. The ingress then forms a Forwarding Adjacency (FA) out of that LSP 113 by advertising it as a Traffic Engineering (TE) link using the 114 routing protocol (OSPF/ISIS) and using the /31 address to 115 identify the local end of the TE link. 117 4. When the egress receives the TE link advertisement, it checks the 118 Link-ID address of the TE advertisement against its own TE Router 119 ID. If it matches its own TE Router ID, the egress checks the 120 advertising router ID of the TE advertisement against the ingress 121 addresses of all LSPs for which it is the egress and finds the 122 address match with the advertising router ID of the TE 123 advertisement. 125 5. The egress then advertises the FA LSP as a TE link setting the 126 advertising TE Router ID in the Link-ID and the partner address of 127 the assigned /31 address in the local interface address. 129 Nesting of LSPs originated by other LSRs into that LSP can be 130 achieved by using the label stack construct. 132 1.2. LSP advertisement and Usage 134 There are three different ways in which traffic can be forwarded to 135 an LSP. Similarly, the LSP can be advertised into the IP topology, 136 the MPLS TE topology or both, depending on the intended usage. 138 As GMPLS LSPs can be bidirectional, full routing adjacencies can be 139 established over a bidirectional GMPLS LSP. When an LSP is used as an 140 RA, it is advertised into IP network and can optionally be advertised 141 into the MPLS topology. The notion of RA is only applicable to 142 bidirectional LSPs. 144 As mentioned above, there is no IGP adjacency over the LSP, when it 145 is to be used as an FA. FA-LSPs can be advertised into the IP and/ or 146 MPLS topologies. Notion of FA is equally applicable to the 147 unidirectional as well as bidirectional LSPs. 149 There are also scenarios where intent of establishing an LSP is to 150 use it for traffic local to the Ingress/ Egress LSRs. In this case, 151 the LSP is neither advertised into the IP nor in MPLS topologies. In 152 this document, such LSPs are referred as local virtual links. 153 Forwarding treatment for a local virtual link is based on a local 154 decision. 156 1.3. Problem Statement 158 The extensions described in this document are intended for 159 dynamically signaled bi-directional Forwarding Adjacency LSPs (FA- 160 LSPs). In particular this document addresses the following points: 162 (1) How to let the egress node know that this bi-directional LSP 163 needs to be advertised as an FA, or as routing adjacency (RA), 164 or its only to be used at the Ingress and Egress nodes. 166 (2) How to identify the routing instance in which such an 167 advertisement should happen. 169 We should note that these aspects are equally applicable to both 170 numbered and unnumbered TE links. 172 In order for the egress of an LSP to be able to advertise the LSP as 173 a TE link it needs to know that such an advertisement is desirable, 174 and it also needs to know the TE Router ID of the ingress LSR. 175 (Please recall that the Router ID of the other end of the link is set 176 in the Link-ID sub-TLV of the Link TLV of the TE Opaque-LSA 177 [RFC3630].) 178 The mechanism set out in section 1.1 is used for numbered FAs because 179 there is no way to carry the TE Router ID of the ingress LSR in the 180 RSVP signaling message (Path message) and there is no way to indicate 181 that the new LSP is to be used as an FA LSP. Therefore the egress LSR 182 has to wait to receive the ingress' advertisement of the TE link to 183 learn that the LSP is to form a TE link and to learn the TE Router ID 184 of the ingress node before it can advertise the FA as described in 185 Section 1.2. Note further, that in this approach, the egress LSR must 186 search potentially many LSPs every time it receives an advertisement 187 for a new TE link. 189 [RFC3477] defines a different method for the exchange of information 190 in the signaling protocol during the establishment of LSPs that will 191 be advertised as unnumbered TE links. If the LSP_TUNNEL_INTERFACE_ID 192 object is present, it indicates that the LSP is to be advertised as a 193 TE link, and it contains the TE Router ID of the ingress LSR. 194 However, the LSP_TUNNEL_INTERFACE_ID object cannot be used for 195 numbered FAs as currently defined. 197 Related to the above problem, a few key observations are worth 198 noting: 200 1. The term FA is applicable only when an LSP is created and used as 201 a TE link in the same instance of the IGP. [RFC4206] did not 202 consider scenarios where an LSP is created (and maintained) by one 203 instance of the IGP, and is used as a (TE) link by another 204 instance of IGP. This leaves open the question of advertising a TE 205 link into a different instance of the IGP as is needed in multi- 206 region/multi-layer networks [MLN], and how to identify which 207 instance of the IGP should be used. In addition, the TE link 208 advertised into the different IGP instance may be associated with 209 an IGP neighbor adjacency. We call it a routing adjacency (RA). 210 The decision as to whether the link should be advertised to MPLS 211 TE topology or IP topology or both depends on operator policy. 212 Therefore, a mechanism to indicate the choice to the Egress node 213 is needed. 215 2. [RFC4206] provides a way to exchange numbered identifiers for the 216 TE link, but this does not clearly state that the Ingress node can 217 use presence of the LSP_TUNNEL_INTERFACE_ID object as a trigger 218 for TE link advertisement at the egress node. 220 3. It is important to note that an LSP that is set up in a server 221 GMPLS transport network and advertised as a TE link in a client 222 MPLS data network is NOT an FA-LSP according to the definitions 223 explained in point 1, above. This is the case regardless of 224 whether the GMPLS network is packet- or non-packet-capable. 226 4. When an egress checks the address of the advertised TE link to 227 find the LSP sender (Recall step (4) as described in section 1.1), 228 it must check the Link-ID address of all received TE 229 advertisements against its own TE Router ID. If it matches its 230 own TE Router ID, the egress checks the advertising router ID of 231 the TE advertisement against the ingress addresses of all LSPs for 232 which it is the egress. It is an assertion of the authors that 233 this method is not scalable due to the amount of processing needed 234 for all the TE Link State Advertisements (LSAs). 236 1.4. Current Approaches and Shortcomings 238 [RFC3477] provides a mechanism to exchange unnumbered identifiers for 239 the TE link during FA-LSP establishment, and this can be used as a 240 notification to the egress that the LSP will be used as a TE link. So, 241 for unnumbered TE links, there is a well-defined indication available, 242 and this could be documented and used as a trigger for TE link 243 advertisement by the egress. 245 The use of unnumbered TE links may be arguably more sensible than 246 assigning numbers to FAs, especially in the case of large networks. 247 Some operators though prefer to consistently use numbered TE links 248 for both static and dynamic (that is, FA) TE links in their networks. 249 In the case of numbered TE links, however, there is no available 250 indication to allow the egress to know that an LSP should be 251 advertised as a TE link. 253 In addition, using unnumbered TE links does not address the issue of 254 advertising TE links into a different instance of the IGP. There is 255 no defined mechanism to identify whether it should be advertised as 256 an FA, a full Routing Adjacency (RA), or a static link. 258 The Link Management Protocol (LMP) [RFC4204] could possibly be run on 259 remote adjacencies between the endpoints of an LSP. But LMP peer 260 discovery would be required for dynamic LMP peering and is not 261 currently specified. In addition, the concept of a remote LMP 262 adjacency remains unproven. Lastly, there would be a requirement 263 that all layers/regions in a MLN network run LMP. This may not be 264 the case in existing networks and would put undue burden on the 265 network operator to deploy another protocol. 267 1.5. Contents of This Document 269 This document provides a consolidated way of exchanging TE link 270 identifiers when an LSP is established through signaling. It also 271 provides a mechanism to allow the ingress to control whether, and 272 into which IGP instances, an LSP is advertised as an FA and/ or RA by 273 the egress. The proposed mechanism applies equally to Hierarchical 274 LSPs (H-LSPs) and Stitchable LSPs (S-LSPs). 276 The method described below extends the method described in [RFC3477], 277 which is applied for an FA-LSP represented as an unnumbered TE link. 279 2. Proposed Solution 281 The following method allows the ingress and egress LSRs to exchange 282 the link addresses or link identifiers (including the node ID) of the 283 ends of a numbered or unnumbered TE link to be formed from an LSP. 284 It is an extension of the procedures defined in [RFC3477] for 285 unnumbered TE links. 287 If an Ingress LSR, that originates an LSP, intends to advertise this 288 LSP as a TE link in IS-IS or OSPF [RFC4206], the Ingress LSR MUST 289 allocate an address or identifier to the TE link (just like for any 290 other TE link), and it MUST do this before the LSP setup request is 291 signaled. Moreover, the Path message used for establishing the LSP 292 that will be used to form the TE link MUST contain the 293 LSP_TUNNEL_INTERFACE_ID object (as extended and described below), 294 with the interface address or identifier allocated by the Ingress LSR. 296 If the Path message for the H-LSP/S-LSP contains the 297 LSP_TUNNEL_INTERFACE_ID object, then the Egress LSR (assuming it 298 accepts the LSP request) MUST allocate an address or identifier to 299 the TE link that will be formed (just like for any other numbered or 300 unnumbered TE link). Furthermore, the Resv message for the LSP MUST 301 contain an LSP_TUNNEL_INTERFACE_ID object, with the interface address 302 or identifier allocated by the Egress LSR. 304 In all cases where an LSP is to be advertised as a TE link, the 305 Tunnel Sender Address in the Sender Template Object of the Path 306 message MUST be set to the TE Router ID of the Ingress LSR. We should 307 note that this is a change from the method described in [RFC4206]. 309 Once the Egress LSR has successfully sent a Resv message as described 310 above it SHOULD advertise the LSP as a TE link using the 311 addresses/identifiers exchanged. Once the Resv has been processed by 312 the Ingress LSR and the LSP has been successfully established, the 313 Ingress LSR SHOULD advertise the LSP as a TE link using the 314 addresses/identifiers exchanged. 316 Once the TE link advertisement has been flooded it is available for 317 use in path computation and LSP signaling just like any other TE link. 319 2.1. IGP Instance Identification 321 The mechanism described so far allows an Ingress LSR to indicate that 322 an LSP is to be used as a TE link and allows the Ingress and Egress 323 LSRs to exchange addresses or identifiers for that TE link, during 324 LSP setup. 326 However, it is also necessary to indicate into which instance of the 327 IGP the advertisement should be made. This is only necessary if the 328 LSP is to be advertised as a TE link into a different instance of the 329 IGP, and the default behavior may safely be left with the LSP 330 advertised into the same instance of the IGP (that is, FA behavior). 332 Indication of the IGP in which the advertisement is to be made first 333 requires that a 32-bit identifier be assigned to each of the IGP 334 instances within a network, and that Ingress and Egress LSRs have the 335 same understanding of these numbers. This is a management 336 configuration exercise outside the scope of this document. 338 Once these numbers have been assigned, they MAY be signaled as 339 additional information in the LSP_TUNNEL_INTERFACE_ID object to 340 indicate to which instance of the IGP the object applies. 342 The IGP instance identifier value of 0xffffffff is reserved to 343 indicate that the TE link SHOULD be advertised into the same instance 344 of the IGP as was used to establish the LSP. Similarly, absence of 345 the IGP instance identifier means that an FA is to be established (in 346 the same IGP instance). 348 2.2. LSP advertisement and Usage Identification 350 As mentioned earlier, the Egress node also needs to know if it needs 351 to create a full routing adjacency or forwarding adjacency or just 352 need to treat the LSP as a local virtual link. The extensions defined 353 in the following also specify the LSP advertisement and usage 354 treatment. 356 2.3. LSP_TUNNEL_INTERFACE_ID Object 358 The LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] has a class 359 number of 193, which designates that a node that does not understand 360 the object SHOULD ignore the object but forward it, unexamined and 361 unmodified, in all messages resulting from this message. 363 [RFC3477] defines one class type to indicate an unnumbered interface 364 identifier. This document defines three new class types as follows. 366 C-Type Meaning Reference 367 --------------------------------------------------------------------- 368 1 Unnumbered interface identifier [RFC3477] 369 2 (TBD by IANA) IPv4 interface identifier with target 2.2.2 370 3 (TBD by IANA) IPv6 interface identifier with target 2.2.3 371 4 (TBD by IANA) Unnumbered interface with target 2.2.4 373 Multiple instances of the LSP_TUNNEL_INTERFACE_ID object with C-Type 374 values 2, 3 or 4 MAY appear in any one Path or Resv message, in which 375 case, each MUST have a different value for the Target IGP Instance 376 field. A Path or Resv message MUST NOT contain more than one 377 instance of the LSP_TUNNEL_INTERFACE_ID object with C-Type 1, and if 378 such an object is present, other instances of the object with any 379 other C-Type value MUST NOT have Target IGP Instance set to 380 0xffffffff. 382 2.3.1. Unnumbered link 384 The unnumbered link identifier defined by [RFC3477] is not changed by 385 this document. Its usage also remains the same. That is, when 386 present in a Path message it indicates that the LSP being established 387 SHOULD be advertised by the egress LSR as a TE link, and that 388 unnumbered link identifier is the ingress' identifier for the TE link. 390 Note that since this form of the object does not contain a target IGP 391 instance identifier it cannot identify a specific instance of the IGP 392 into which this TE link should be advertised. Similarly, LSP 393 advertisement and usage treatment also needs to be specified. Thus, 394 when C-Type 1 is used, the TE link SHOULD be advertised only into the 395 same instance of the IGP as was used to create the LSP. That is, the 396 use of C-Type 1 is unchanged from [RFC3477] and is used to create an 397 unnumbered Forwarding Adjacency. 399 This object can appear in either a Path message or a Resv message. 400 In the former case, we call it the "Forward Interface ID" for that 401 LSP; in the latter case, we call it the "Reverse Interface ID" for 402 the LSP. 404 Only one instance of this object with C-Type 1 may be present on a 405 Path or Resv message. 407 2.3.2. IPv4 numbered link 409 A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is defined 410 to carry an IPv4 numbered interface address and to indicate into 411 which instance of the IGP the consequent TE link should be advertised. 413 The format of the object is as shown below. 415 C-NUM = 193, C-Type = 2(TBD by IANA) 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | IPv4 Interface Address (32 bits) | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Target IGP Instance (32 bits) | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 |R|F| PADDING | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | TLVs | 426 ~ ~ 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 R: The R bit is set to indicate the Egress LSR to establish a full 430 routing adjacency over this bidirectional LSP. When R bit is set, the 431 bidirectional LSP is advertised into the IP topology. 433 F: The F bit is set to indicate the Egress LSR to advertise this LSP 434 into MPLS TE topology. 436 It is important to note that R and F bits can be set independent of 437 each other. That is, 439 R = 1, F = 0: LSP is an RA and is only advertised into the IP network. 441 R = 1, F = 1: LSP is an RA and is advertised in both IP and MPLS-TE 442 topologies. 444 R = 0, F = 1: LSP is an FA and is only advertised into the MPLS-TE 445 topology. 447 R = 0, F = 0: LSP is neither the FA nor RA and is to be used as a 448 local virtual link. In this case the LSP is advertised neither in IP 449 nor MPLS topology. 451 The Padding MUST be set to zero on transmission, SHOULD be ignored 452 and forwarded unchanged, and SHOULD be ignored on receipt. 454 This object can appear in either a Path message or a Resv message. 455 In the former case, we call it the "Forward Interface Address" for 456 that LSP; in the latter case, we call it the "Reverse Interface 457 Address" for the LSP. 459 2.3.3. IPv6 numbered link 461 A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is defined 462 to carry an IPv6 numbered interface address and to indicate into 463 which instance of the IGP the consequent TE link should be advertised. 465 The format of the object is as shown below. 467 C-NUM = 193, C-Type = 3(TBD by IANA) 468 0 1 2 3 469 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 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | IPv6 Interface Address (128 bits) | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | IPv6 Interface Address (128 bits) | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | IPv6 Interface Address (128 bits) | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | IPv6 Interface Address (128 bits) | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Target IGP Instance (32 bits) | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 |R|F| PADDING | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | TLVs | 484 ~ ~ 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 This object can optionally appear in either a Path message or a Resv 488 message. In the former case, we call it the "Forward Interface 489 Address" for that LSP; in the latter case, we call it the "Reverse 490 Interface Address" for the LSP. 492 2.3.4. Unnumbered link with target IGP instance identifier 494 A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is defined 495 to carry an unnumbered interface identifier and to indicate into 496 which instance of the IGP the consequent TE link should be advertised. 497 This does not deprecate the use of C-Type 1, but extends its utility. 499 The format of the object is as shown below. 501 C-NUM = 193, C-Type = 4(TBD by IANA) 502 0 1 2 3 503 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 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | LSR's Router ID | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Interface ID (32 bits) | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Target IGP Instance (32 bits) | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 |R|F| PADDING | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | TLVs | 514 ~ ~ 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 This object can optionally appear in either a Path message or a Resv 518 message. In the former case, we call it the "Forward Interface ID" 519 for that LSP; in the latter case, we call it the "Reverse Interface 520 ID" for the LSP. 522 2.3.5. Message Formats 524 [RFC3477] does not state where in the Path message or Resv message 525 the LSP_TUNNEL_INTERFACE_ID object should be placed. Since [RFC3209] 526 states that all implementations are to handle all objects received in 527 any order, this is not a problem. However, it is RECOMMENDED that the 528 LSP_TUNNEL_INTERFACE_ID object(s) be placed in the Path message 529 immediately after the SENDER_TSPEC object, and in the Resv message 530 immediately after the FILTER_SPEC object. 532 2.4. LSA advertisement 534 The ingress and egress LSRs MAY advertise link state associated with 535 TE links created as described above. The link state may be 536 advertised in either the same IGP instance as used to compute and 537 signal the path for the LSPs that support the TE links, or another 538 IGP instance. In the former case, the address space for the link 539 state MUST be the same as that used to establish the LSPs. In the 540 latter case, the address space for the link state MAY be different, 541 which means that addresses already allocated in the IGP instance used 542 to establish the LSPs MAY be used by the advertised TE link without 543 any ambiguity. 545 In the IGP the TE Router ID of the ingress LSR is taken from the 546 Tunnel Sender Address in the Sender Template object. It is assumed 547 that the ingress LSR knows the TE Router ID of the egress LSR since 548 it has chosen to establish an LSP to that LSR and plans to use the 549 LSP as a TE link. 551 The link interface addresses or link interface identifiers for the 552 forward and reverse direction links are taken from the 553 LSP_TUNNEL_INTREFACE_ID object on the Path and Resv messages 554 respectively. 556 Address overlap checking for these objects MUST be turned off when 557 the LSA is advertised into a IGP instance different from the one used 558 to establish the LSP because the addresses MAY be allocated in both 559 domains. 561 3. Applicability Statement 563 The method is applicable for both hierarchical LSPs [RFC4206] and LSP 564 stitching [STITCH]. 566 4. Backward Compatibility Considerations 568 The method does not impact the method to exchange unnumbered FA 569 information described in [RFC3477]. That mechanism can be safely 570 used in combination with the new mechanisms described here and is 571 functionally equivalent to using the new C-Type indicating an 572 unnumbered link with target IGP instance identifier with the Target 573 IGP Instance value set to 0xffffffff. 575 This method obsoletes the method to exchange the numbered FA 576 information described in [RFC4206]. This is not believed to be an 577 issue as an informal survey indicated that dynamically signaled 578 numbered FAs had not been deployed. Indeed it was the attempt to 579 implement numbered FAs that gave rise to the work on this document. 581 5. Security Considerations 583 [RFC3477] points out that one can argue that the use of the extra 584 interface identifier that it provides could make an RSVP message 585 harder to spoof. In that respect, the minor extensions to the 586 protocol made in this document do not constitute an additional 587 security risk, but could also be said to improve security. 589 It should be noted that the ability of an ingress LSR to request that 590 an egress LSR advertise an LSP as a TE link MUST be subject to 591 appropriate policy checks at the egress LSR. That is, the egress LSR 592 MUST NOT automatically accept the word of the ingress unless it is 593 configured with such a policy. 595 6. IANA Considerations 597 This document defines three new C-Types for the 598 LSP_TUNNEL_INTERFACE_ID object. The C-Types for this object are 599 managed by IANA, and IANA is requested to assign values to the new C- 600 Types as tabulated in section 2.2 and described in sections 2.2.2, 601 2.2.3 and 2.2.4. 603 7. Acknowledgement 605 The authors would like to thank John Drake for valuable discussions 606 and comments. 608 Funding for the RFC Editor function is currently provided by the 609 Internet Society. 611 8. References 613 8.1. Normative References 615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 616 Requirement Levels", BCP 14, RFC 2119, March 1997. 618 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. 619 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 620 Tunnels", RFC 3209, December 2001. 622 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 623 in Resource ReSerVation Protocol - Traffic Engineering 624 (RSVP-TE)", RFC 3477, January 2003. 626 [RFC4206] Kompella, K. and Y. Rekhter, "LSP Hierarchy with 627 Generalized MPLS TE", RFC 4206, October 2005. 629 [STITCH] Ayyangar, A. and J.P. Vasseur, "Label Switched Path 630 Stitching with Generalized MPLS Traffic Engineering", 631 draft-ietf-ccamp-lsp-stitching, (work in progress). 633 8.2. Informative References 635 [RFC3630] Katz, D., Kompella, K. and Yeung, D., "Traffic Engineering 636 (TE) Extensions to OSPF Version 2", RFC 3630, September 637 2003. 639 [RFC4204] Lang, J. (Ed.), "Link Management Protocol (LMP)", RFC 640 4204, October 2005. 642 [MLN] Shiomoto, K., et al, " Requirements for GMPLS-based multi- 643 region and multi-layer networks (MRN/MLN)", draft-ietf- 644 ccamp-gmpls-mln-reqs, (work in progress). 646 Author's Addresses 648 Kohei Shiomoto 649 NTT Network Service Systems Laboratories 650 3-9-11 Midori 651 Musashino, Tokyo 180-8585 652 Japan 653 Phone: +81 422 59 4402 654 Email: shiomoto.kohei@lab.ntt.co.jp 656 Richard Rabbat 657 Fujitsu Laboratories of America 658 1240 East Arques Ave, MS 345 659 Sunnyvale, CA 94085 660 United States of America 661 Phone: +1 408-530-4537 662 Email: richard@us.fujitsu.com 663 Arthi Ayyangar 664 Juniper Networks 665 1194 N. Mathilda Ave. 666 Sunnyvale, CA 94089 667 United States of America 668 Phone: 669 Email: arthi@juniper.net 671 Adrian Farrel 672 Old Dog Consulting 673 EMail: adrian@olddog.co.uk 675 Zafar Alli 676 Cisco Systems, Inc. 677 EMail: zali@cisco.com 679 Intellectual Property Statement 681 The IETF takes no position regarding the validity or scope of any 682 Intellectual Property Rights or other rights that might be claimed to 683 pertain to the implementation or use of the technology described in 684 this document or the extent to which any license under such rights 685 might or might not be available; nor does it represent that it has 686 made any independent effort to identify any such rights. Information 687 on the procedures with respect to rights in RFC documents can be 688 found in BCP 78 and BCP 79. 690 Copies of IPR disclosures made to the IETF Secretariat and any 691 assurances of licenses to be made available, or the result of an 692 attempt made to obtain a general license or permission for the use of 693 such proprietary rights by implementers or users of this 694 specification can be obtained from the IETF on-line IPR repository at 695 http://www.ietf.org/ipr. 697 The IETF invites any interested party to bring to its attention any 698 copyrights, patents or patent applications, or other proprietary 699 rights that may cover technology that may be required to implement 700 this standard. Please address the information to the IETF at 701 ietf-ipr@ietf.org 703 Disclaimer of Validity 705 This document and the information contained herein are provided on an 706 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 707 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 708 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 709 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 710 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 711 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 713 Copyright Statement 715 Copyright (C) The Internet Society (2006). 717 This document is subject to the rights, licenses and restrictions 718 contained in BCP 78, and except as set forth therein, the authors 719 retain all their rights.