idnits 2.17.1 draft-shiomoto-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 607. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 591. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 611), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. -- The document has an RFC 3978 Section 5.3 Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. ** 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 284 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 -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 17, 2005) is 6766 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: 'RFC3630' is mentioned on line 136, but not defined == Missing Reference: 'LSP-HIER' is mentioned on line 232, but not defined == Missing Reference: 'HIER' is mentioned on line 250, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-lsp-stitching-01 == Outdated reference: A later version (-03) exists of draft-shiomoto-ccamp-gmpls-mrn-reqs-02 Summary: 6 errors (**), 0 flaws (~~), 7 warnings (==), 8 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: MPLS-HIER, 3477 A. Ayyangaer(Juniper Networks) 5 Proposed Category: Proposed Standard A. Farrel(Old Dog Consulting) 7 Expires: April 2006 October 17, 2005 9 Advertisement of hierarchical and stitchable LSPs as TE Links 10 draft-shiomoto-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 April 17, . 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). All Rights Reserved. 43 Abstract 45 This document addresses topics related to hierarchical and stitched 46 Label Switched Paths (LSPs). It describes extensions to allow an 47 egress to identify that an LSP will be used as a dynamically signaled 48 Forwarding Adjacency LSP (FA-LSP) in the case of numbered FA's. In 49 addition, the document addresses the issue of how to indicate that an 50 LSP should be advertised as a TE link into a different instance of 51 the control plane and how to identify the instance that should be 52 used. 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in [RFC2119]. 60 Table of Contents 62 1. Introduction and Problem Statement.............................3 63 1.1. LSP Hierarchy.............................................3 64 1.2. Problem Statement.........................................3 65 1.3. Current Approaches and Shortcomings.......................5 66 1.4. Contents of This Document.................................5 67 2. Proposed Solution..............................................6 68 2.1. Control Plane Instance Identification.....................6 69 2.2. LSP_TUNNEL_INTERFACE_ID Object............................7 70 2.2.1. Unnumbered link......................................7 71 2.2.2. IPv4 numbered link...................................8 72 2.2.3. IPv6 numbered link...................................9 73 2.2.4. Unnumbered link with target control plane instance 74 identifier..................................................9 75 2.3. TLVs.....................................................10 76 2.4. LSA advertisement........................................10 77 3. Applicability Statement.......................................11 78 4. Backward Compatibility Considerations.........................11 79 5. Security Considerations.......................................12 80 6. IANA Considerations...........................................12 81 7. References....................................................12 82 7.1. Normative References.....................................12 83 7.2. Informative References...................................13 84 Author's Addresses...............................................13 85 Intellectual Property Statement..................................14 86 Disclaimer of Validity...........................................14 87 Copyright Statement..............................................15 88 Acknowledgment...................................................15 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 aggregating 96 LSPs into a hierarchy of such LSPs [HIERAR]. 98 The operation is as follows for a numbered Forwarding Adjacency: 100 1. The ingress signals the LSP using a /31 sender address that it 101 allocates. 103 2. The egress sets up the LSP. 105 3. The ingress then forms a Forwarding Adjacency (FA) out of that LSP 106 by advertising it as a Traffic Engineering (TE) link; toward that 107 end, it uses the routing protocol (OSPF/ISIS) to advertise the TE 108 link using the /31 address. The head-end address of the FA-LSP is 109 specified in the IPv4 tunnel sender address in the Sender Template 110 Object of the FA LSP. 112 4. When the egress receives the advertised TE link information, it 113 checks the Link-ID address of the TE advertisement against its own 114 TE Router ID. If it matches its own TE Router ID, the egress 115 checks the advertising router ID of the TE advertisement against 116 the ingress addresses of LSPs for which it is the egress and finds 117 the address match with the advertising router ID of the TE 118 advertisement. 120 5. The egress then advertises the TE information setting the 121 advertising TE Router ID in the Link-ID and the assigned /31 122 address in the local interface address. 124 Nesting of LSPs originated by other LSRs into that LSP can be 125 achieved by using the label stack construct. 127 1.2. Problem Statement 129 The extensions described in this document are intended for 130 dynamically signaled bi-directional Forwarding Adjacency LSP (FA-LSP). 132 In order that the egress of an LSP can advertise the LSP as a TE link 133 it needs to know that such an advertisement is desirable, and it also 134 needs to know the TE Router ID of the ingress LSR (Please recall that 135 the Router ID of the other end of the link is set in the Link-ID sub- 136 TLV of the Link TLV of TE Opaque-LSA [RFC3630]). For the numbered FA, 137 there is no place in the RSVP signaling messages of FA LSP to carry 138 the TE Router ID of the ingress LSR. Therefore the egress LSR has to 139 wait to receive the TE advertisement by the ingress LSR to learn the 140 TE Router ID of the ingress node until it advertises the FA as 141 described in Section 1.2. 143 Different methods for the exchange of both numbered and unnumbered 144 endpoints are defined in [HIERAR] and [RFC3477] respectively. For 145 unnumbered TE links this information is available using the 146 mechanisms in [RFC3477]. If the LSP_TUNNEL_INTERFACE_ID object is 147 present, it indicates that the LSP is to be advertised as a TE link, 148 and it contains the TE Router ID of the ingress LSR. However, for 149 numbered TE links, the mechanism in [HIERAR] does not provide this 150 information. Since the LSP_TUNNEL_INTERFACE_ID object is not used 151 there is no trigger for TE link advertisement on the egress. 153 Related to the above problem, a few key observations are worth 154 noting: 156 1. The concept of an FA is applicable only when an LSP is both 157 created and used as a TE link by exactly the same instance of the 158 GMPLS control plane. [HIERAR] did not consider scenarios where an 159 LSP is created (and maintained) by one instance of the GMPLS 160 control plane, and is used as a (TE) link by another instance of 161 the GMPLS control plane. This leaves open the question of 162 advertising a TE link into a different instance of the control 163 plane as is needed in multi-region/multi-layer networks [MRN]. 164 [HIERAR] also does not address how to identify which instance of 165 the control plane should be used. 167 2. [HIERAR] provides a way to exchange numbered identifiers for the 168 TE link, but this does not serve as a trigger for TE link 169 advertisement. 171 3. It is important to note that an LSP that is set up in a GMPLS 172 transport network then advertised as a TE link in the MPLS data 173 network is NOT an FA-LSP. 175 4. When an egress checks the address of the advertised TE link to 176 find the LSP sender (Recall step (4) as described in section 1.1), 177 it must check the Link-ID address of all received TE 178 advertisements against its own TE Router ID. If it matches its 179 own TE Router ID, the egress checks the advertising router ID of 180 the TE advertisement against the ingress addresses of all LSPs for 181 which it is the egress. It is an assertion of the authors that 182 this method is not scalable due to the amount of processing needed 183 for all the TE Link State Advertisements (LSAs). 185 1.3. Current Approaches and Shortcomings 187 [RFC3477] provides a mechanism to exchange unnumbered identifiers for 188 the TE link during H-LSP establishment, and this can be used as a 189 notification to the egress that the LSP will be used as a TE link. 191 So for unnumbered TE links, there is a well-defined trigger available. 192 The use of unnumbered TE links may be arguably more sensible, 193 especially in the case of large networks. Some operators though 194 prefer to consistently use numbered TE links for both static and 195 dynamic TE links in their networks. In case of numbered TE links, 196 however, there is no such available trigger for the egress to know 197 that an H-LSP should be advertised as a TE link. 199 In addition, using unnumbered TE links still does not address the 200 issue of advertising TE links into different layers, nor is it 201 sufficient for dynamic bundling. 203 The Link Management Protocol (LMP) [LMP] could possibly be run on 204 remote adjacencies between the endpoints of the LSP. LMP peer 205 discovery is required for dynamic LMP peering. In addition, remote 206 LMP adjacency remains unproven. Last, it would require that all 207 layers/regions in an MRN network to run LMP. This may not be the 208 case and would put undue burden on the network operator to deploy 209 fully a new protocol. 211 1.4. Contents of This Document 213 This document provides a consolidated way of exchanging TE link 214 identifiers when an LSP is established through signaling. It also 215 provides a mechanism to allow the ingress to control whether, and 216 into which control plane instances, an LSP is advertised as a TE link 217 by the egress. The proposed mechanism applies equally to Hierarchical 218 LSPs (H-LSPs) and Stitchable LSPs (S-LSPs). 220 The method described below extends the method described in [RFC3477], 221 which is applied for an unnumbered TE link represented as an FA. 223 2. Proposed Solution 225 The following method allows the ingress and egress LSR to exchange 226 the link address or link identifier (including the node ID) of the 227 other end of a TE link for numbered and unnumbered TE link. It is an 228 extension of the procedures defined in [RFC3477] for unnumbered TE 229 links. 231 If a head-end LSR that originates an LSP intends to advertise this 232 LSP as a TE link in IS-IS or OSPF [LSP-HIER], the head-end LSR MUST 233 allocate an address or identifier to the TE link (just like for any 234 other TE link). Moreover, the Path message used for establishing the 235 LSP that will be used to form the TE link MUST contain the 236 LSP_TUNNEL_INTERFACE_ID object (as extended and described below), 237 with the interface address or identifier allocated by the head-end 238 LSR. 240 If the Path message for the H-LSP/S-LSP contains the 241 LSP_TUNNEL_INTERFACE_ID object, then the tail-end LSR MUST allocate 242 an address or identifier to that TE link (just like for any other 243 numbered or unnumbered TE link). Furthermore, the Resv message for 244 the LSP MUST contain an LSP_TUNNEL_INTERFACE_ID object, with the 245 interface address or identifier allocated by the tail-end LSR 247 In all cases where an LSP is to be advertised as a TE link the Tunnel 248 Sender Address in the Sender Template Object MUST be set to the TE 249 Router ID of the head-end LSR. We should note that this is a change 250 from the method described in [HIER]. 252 Once the addresses or identifiers for the LSP have been exchanged 253 using these signaling extensions, and once the LSP has been 254 successfully established the head-end and tail end SHOULD advertise 255 the LSP as a TE link using the addresses/identifiers exchanged. Once 256 the TE link advertisement has been flooded it is available for use in 257 path computation and LSP signaling just like any other TE link. 259 2.1. Control Plane Instance Identification 261 The mechanism described so far allows a head-end LSR to indicate that 262 an LSP is to be used as a TE link and allows the head-end and tail- 263 end LSRs to exchange addresses or identifiers for that TE link, 264 during LSP setup. 266 However, it is also necessary to indicate into which instance of the 267 control plane the advertisement should be made. This first requires 268 that a 32-bit identifier is assigned to each of the various control 269 plane instances within a network, and that head-end and tail-end LSRs 270 have the same understanding of these numbers. This is a management 271 configuration exercise outside the scope of this document. 273 Once these numbers have been assigned, they MAY be signaled as 274 additional information in the LSP_TUNNEL_INTERFACE_ID object to 275 indicate to which instance of the control plane the object applies. 277 The control plane instance identifier value of zero is reserved to 278 mean indicate that the TE link SHOULD be advertised into the same 279 instance of the control plane as was used to establish the LSP. That 280 is, a value of zero means that an FA is to be established. 282 2.2. LSP_TUNNEL_INTERFACE_ID Object 284 The LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] has a class 285 number of 193, which designates that a node that does not understand 286 the object SHOULD ignore the object but forward it, unexamined and 287 unmodified, in all messages resulting from this message. 289 [RFC3477] defines one class type to indicate an unnumbered interface 290 identifier. This document defines three new class types as follows. 292 C-Type Meaning Reference 293 --------------------------------------------------------------------- 294 1 Unnumbered interface identifier [RFC3477] 295 2 (TBD by IANA) IPv4 interface identifier with target 2.3.2 296 3 (TBD by IANA) IPv6 interface identifier with target 2.3.3 297 4 (TBD by IANA) Unnumbered interface with target 2.3.4 299 Multiple instances of the LSP_TUNNEL_INTERFACE_ID object with C-Type 300 values 2, 3 or 4 MAY appear in any one Path or Resv message, in which 301 case, each MUST have a different value for the Target Control Plane 302 Instance field. A Path or Resv message MUST NOT contain more than 303 one instance of the LSP_TUNNEL_INTERFACE_ID object with C-Type 1, and 304 if such an object is present, other instances of the object with any 305 other C-Type value MUST NOT have Target Control Plane Instance set to 306 zero. 308 2.2.1. Unnumbered link 310 The unnumbered link identifier defined by [RFC3477] is not changed by 311 this document. Its usage also remains the same. That is, when 312 present in a Path message it indicates that the LSP being established 313 SHOULD be advertised by the egress LSR as a TE link, and that 314 unnumbered link identifier is the ingresses identifier for the TE 315 link. 317 Note that since this form of the object does not contain a target 318 instance identifier it cannot identify a specific instance of the 319 control plane into which this TE link should be advertised. Thus, 320 when C-Type 1 is used, the TE link SHOULD be advertised only into the 321 same instance of the control plane as was used to create the LSP. 322 That is, the use of C-Type 1 is unchanged from [RFC3477] and is used 323 to create an unnumbered Forwarding Adjacency. 325 This object can optionally appear in either a Path message or a Resv 326 message. In the former case, we call it the "Forward Interface ID" 327 for that LSP; in the latter case, we call it the "Reverse Interface 328 ID" for the LSP. 330 Only one instance of this object with C-Type 1 may be present on a 331 Path or Resv message. 333 2.2.2. IPv4 numbered link 335 A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is defined 336 to carry an IPv4 numbered interface address and to indicate into 337 which instance of the control plane the consequent TE link should be 338 advertised. 340 The format of the object is as shown below. 342 C-NUM = 193, C-Type = 2(TBD by IANA) 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | IPv4 Interface Address (32 bits) | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Target Control Plane Instance (32 bits) | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | TLVs | 351 ~ ~ 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 This object can optionally appear in either a Path message or a Resv 355 message. In the former case, we call it the "Forward Interface 356 Address" for that LSP; in the latter case, we call it the "Reverse 357 Interface Address" for the LSP. 359 2.2.3. IPv6 numbered link 361 A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is defined 362 to carry an IPv6 numbered interface address and to indicate into 363 which instance of the control plane the consequent TE link should be 364 advertised. 366 The format of the object is as shown below. 368 C-NUM = 193, C-Type = 3(TBD by IANA) 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | IPv6 Interface Address (128 bits) | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | IPv6 Interface Address (128 bits) | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | IPv6 Interface Address (128 bits) | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | IPv6 Interface Address (128 bits) | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Target Control Plane Instance (32 bits) | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | TLVs | 383 ~ ~ 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 This object can optionally appear in either a Path message or a Resv 387 message. In the former case, we call it the "Forward Interface 388 Address" for that LSP; in the latter case, we call it the "Reverse 389 Interface Address" for the LSP. 391 2.2.4. Unnumbered link with target control plane instance identifier 393 A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is defined 394 to carry an unnumbered interface identifier and to indicate into 395 which instance of the control plane the consequent TE link should be 396 advertised. This does not deprecate the use of C-Type 1, but extends 397 its utility. 399 The format of the object is as shown below. 401 C-NUM = 193, C-Type = 4(TBD by IANA) 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | LSR's Router ID | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Interface ID (32 bits) | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Target Control Plane Instance (32 bits) | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | TLVs | 412 ~ ~ 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 This object can optionally appear in either a Path message or a Resv 416 message. In the former case, we call it the "Forward Interface ID" 417 for that LSP; in the latter case, we call it the "Reverse Interface 418 ID" for the LSP. 420 2.3. TLVs 422 All TLVs of the LSP_TUNNEL_INTERFACE_ID object have the following 423 format. 425 0 1 2 3 426 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 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Type (16 bits) | Length (16 bits) | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Value (variable) | 431 ~ ~ 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 The length field contains the total length of the TLV including the 435 Type and Length fields in bytes. A value field whose length is not a 436 multiple of four MUST be zero-padded so that the TLV is four-byte 437 aligned. 439 2.4. LSA advertisement 441 The ingress and egress LSRs MAY advertise link state associated with 442 TE links created as described above. The link state may be 443 advertised in either the same control plane instance as used to 444 compute and signal the path for the LSPs that support the TE links, 445 or another control plane instance. In the former case, the address 446 space for the link state MUST be the same as that used to establish 447 the LSPs. In the latter case, the address space for the link state 448 MAY be different, which means that addresses already allocated in the 449 control plane instance used to establish the LSPs MAY be used by the 450 advertised TE link without any ambiguity. 452 In the routing protocol the TE Router ID of the ingress LSR is taken 453 from the Tunnel Sender Address in the Sender Template object. It is 454 assumed that the ingress LSR knows the TE Router ID of the egress LSR 455 since it has chosen to establish an LSP to that LSR and plans to use 456 the LSP as a TE link. 458 The link interface addresses or link interface identifiers for the 459 forward and reverse direction links are taken from the 460 LSP_TUNNEL_INTREFACE_ID object on the Path and Resv messages 461 respectively. 463 Address overlap checking for these objects MUST be turned off in case 464 that the LSA is advertised into a control plane instance different 465 from the one used to establish the LSP because the addresses MAY be 466 allocated in both domains. 468 3. Applicability Statement 470 The method is applicable for both hierarchical LSP [HIERAR] and LSP 471 stitching [STITCH]. 473 The method is applicable for bundled links. 475 4. Backward Compatibility Considerations 477 The method does not impact the method to exchange unnumbered FA 478 information described in [RFC3477]. This mechanism can be safely 479 used in combination with the new mechanisms described here and is 480 functionally equivalent to using the new C-Type indicating an 481 unnumbered link with target control plane instance identifier with 482 the Target Control Plane Instance value set to zero. 484 The method obsoletes the method to exchange the numbered FA 485 information described in [HIERAR]. This is not believed to be an 486 issue as an informal survey indicated that dynamically signalled 487 numbered FAs had not been deployed. Indeed it was the attempt to 488 implement numbered FAs that gave rise to the work on this document. 490 5. Security Considerations 492 [RFC3477] points out that one can argue that the use of the extra 493 interface identify that it provides could make an RSVP message harder 494 to spoof. In that respect, the minor extensions to the protocol made 495 in this document do not constitute an additional security risk, but 496 could also be said to improve security. 498 It should be noted that the ability of an ingress LSR to request that 499 an egress LSR advertise an LSP as a TE link MUST be subject to 500 appropriate policy checks at the egress LSR. That is, the egress LSR 501 MUST NOT automatically accept the word of the ingress unless it is 502 configured with such a policy. 504 6. IANA Considerations 506 This document defines three new C-Types for the 507 LSP_TUNNEL_INTERFACE_ID object. The C-Types for this object are 508 managed by IANA, and IANA is requested to assign values to the new C- 509 Types as tabulated in section 2.3 and described in sections 2.3.2, 510 2.3.3 and 2.3.4. 512 7. Acknowledgement 514 The authors would like to thank John Drake for valuable discussiond 515 and comments. 517 8. References 519 8.1. Normative References 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, March 1997. 524 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 525 in Resource ReSerVation Protocol - Traffic Engineering 526 (RSVP-TE)", RFC 3477, January 2003. 528 [HIERAR] Kompella, K. and Y. Rekhter, "LSP Hierarchy with 529 Generalized MPLS TE", draft-ietf-mpls-lsp-hierarchy-08 530 (work in progress), September 2002. 532 [STITCH] Ayyangar, A. and J.P. Vasseur, "Label Switched Path 533 Stitching with Generalized MPLS Traffic Engineering", 534 draft-ietf-ccamp-lsp-stitching-01, (work in progress), 535 July 2005. 537 8.2. Informative References 539 [LMP] Lang, J. (Ed.), "Link Management Protocol (LMP)", 540 draft-ietf-ccamp-lmp-10, (work in progress), October 2003. 542 [MRN] Shiomoto, K., et al, " Requirements for GMPLS-based multi- 543 region and multi-layer networks (MRN/MLN)", draft-shiomoto- 544 ccamp-gmpls-mrn-reqs-02, (work in progress), July 2005. 546 Author's Addresses 548 Kohei Shiomoto 549 NTT Network Service Systems Laboratories 550 3-9-11 Midori 551 Musashino, Tokyo 180-8585 552 Japan 553 Phone: +81 422 59 4402 554 Email: shiomoto.kohei@lab.ntt.co.jp 556 Richard Rabbat 557 Fujitsu Laboratories of America 558 1240 East Arques Ave, MS 345 559 Sunnyvale, CA 94085 560 United States of America 561 Phone: +1 408-530-4537 562 Email: richard@us.fujitsu.com 563 Arthi Ayyangar 564 Juniper Networks 565 1194 N. Mathilda Ave. 566 Sunnyvale, CA 94089 567 United States of America 568 Phone: 569 Email: arthi@juniper.net 571 Adrian Farrel 572 Old Dog Consulting 573 EMail: adrian@olddog.co.uk 575 Intellectual Property Statement 577 The IETF takes no position regarding the validity or scope of any 578 Intellectual Property Rights or other rights that might be claimed to 579 pertain to the implementation or use of the technology described in 580 this document or the extent to which any license under such rights 581 might or might not be available; nor does it represent that it has 582 made any independent effort to identify any such rights. Information 583 on the procedures with respect to rights in RFC documents can be 584 found in BCP 78 and BCP 79. 586 Copies of IPR disclosures made to the IETF Secretariat and any 587 assurances of licenses to be made available, or the result of an 588 attempt made to obtain a general license or permission for the use of 589 such proprietary rights by implementers or users of this 590 specification can be obtained from the IETF on-line IPR repository at 591 http://www.ietf.org/ipr. 593 The IETF invites any interested party to bring to its attention any 594 copyrights, patents or patent applications, or other proprietary 595 rights that may cover technology that may be required to implement 596 this standard. Please address the information to the IETF at 597 ietf-ipr@ietf.org 599 Disclaimer of Validity 601 This document and the information contained herein are provided on an 602 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 603 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 604 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 605 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 606 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 607 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 609 Copyright Statement 611 Copyright (C) The Internet Society (2005). 613 This document is subject to the rights, licenses and restrictions 614 contained in BCP 78, and except as set forth therein, the authors 615 retain all their rights. 617 Acknowledgment 619 Funding for the RFC Editor function is currently provided by the 620 Internet Society.