idnits 2.17.1 draft-ietf-mpls-rsvp-upstream-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 375. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 361. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (July 8, 2008) is 5763 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: 'RSVP-P2MP' is mentioned on line 83, but not defined == Missing Reference: 'LSP-HIER' is mentioned on line 203, but not defined == Unused Reference: 'RFC3031' is defined on line 288, but no explicit reference was found in the text == Unused Reference: 'MVPN' is defined on line 317, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-mpls-upstream-label-05 -- No information found for draft-ietf-mpls-codepoint - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MPLS-MCAST-ENCAPS' == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-rsvp-restart-ext-02 == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-06 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Aggarwal 3 Internet Draft Juniper Networks 4 Expiration Date: January 2009 5 J. L. Le Roux 6 France Telecom 8 July 8, 2008 10 MPLS Upstream Label Assignment for RSVP-TE 12 draft-ietf-mpls-rsvp-upstream-03.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 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 Abstract 39 This document describes procedures for distributing upstream-assigned 40 labels for Resource Reservation Protocol - Traffic Engineering (RSVP- 41 TE). It also describes how these procedures can be used for avoiding 42 branch LSR traffic replication on a LAN for RSVP-TE point-to- 43 multipoint (P2MP)LSPs. 45 Table of Contents 47 1 Specification of requirements ......................... 2 48 2 Introduction .......................................... 2 49 3 RSVP-TE Upstream Label Assignment Capability .......... 3 50 4 Distributing Upstream-Assigned Labels in RSVP-TE ...... 4 51 4.1 Procedures ............................................ 4 52 5 RSVP-TE Tunnel Identifier Exchange .................... 5 53 6 RSVP-TE Point-to-Multipoint LSPs on a LAN ............. 6 54 7 Acknowledgements ...................................... 7 55 8 References ............................................ 7 56 8.1 Normative References .................................. 7 57 8.2 Informative References ................................ 8 58 9 Author's Address ...................................... 8 59 10 Intellectual Property Statement ....................... 8 60 11 Full Copyright Statement .............................. 9 62 1. Specification of requirements 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in [RFC2119]. 68 2. Introduction 70 This document describes procedures for distributing upstream-assigned 71 labels [MPLS-UPSTREAM] for Resource Reservation Protocol with Traffic 72 Engineering (RSVP-TE). These procedures follow the architecture for 73 MPLS Upstream Label Assignment described in [MPLS-UPSTREAM]. 75 This document describes extensions to RSVP-TE that a LSR can use to 76 advertise to its neighboring LSRs whether the LSR supports upstream 77 label assignment. 79 This document also describes extensions to RSVP-TE to distribute 80 upstream-assigned labels. 82 The usage of MPLS upstream label assignment using RSVP-TE for 83 avoiding branch LSR [RSVP-P2MP] traffic replication on a LAN for 84 RSVP-TE P2MP TE LSPs [RFC4875] is also described. 86 3. RSVP-TE Upstream Label Assignment Capability 88 According to [MPLS-UPSTREAM], upstream-assigned label bindings MUST 89 NOT be used unless it is known that a downstream LSR supports them. 90 This implies that there MUST be a mechanism to enable a LSR to 91 advertise to its RSVP-TE neighbor LSR(s) its support of upstream- 92 assigned labels. 94 [RSVP-RESTART] defines a CAPABILITY object to be carried within Hello 95 messages, and used to indicate the set of capabilities supported by a 96 node. Currently one flag is defined, the R flag indicating the 97 support for RecoveryPath Srefresh. This document defines a new flag, 98 the U flag, to signal a LSR's support of upstream label assignment to 99 its RSVP-TE neighbors. 101 The format of a Capability object is: 103 0 1 2 3 104 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 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 | Length | Class-Num(TBA)| C-Type (1) | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 | Reserved |U|R| 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 Recovery Path Srefresh Capable (R): 1 bit, defined in [RSVP-RESTART]. 113 Upstream Label Assignement Capable (U): 1 bit When set this means 114 that the LSR is capable of both distributing upstream-assigned label 115 bindings and receiving upstream-assigned label bindings 117 Reserved bits MUST be set to zero on transmission and MUST be ignored 118 on receipt. 120 The usage of RSVP-TE Hello messages for exchanging upstream label 121 assignment capability implies that a LSR MAY exchange RSVP-TE Hellos 122 with a neighbor before sending/receiving any other RSVP-TE messages 123 to/from that neighbor. 125 4. Distributing Upstream-Assigned Labels in RSVP-TE 127 An optional RSVP-TE object, the UPSTREAM_ASSIGNED_LABEL object is 128 introduced to signal an upstream-assigned label. The Class-Num for 129 this object comes from the 0bbbbbbb space and is to be determined by 130 IANA. 132 UPSTREAM_ASSIGNED_LABEL C-Num = TBD 134 0 1 2 3 135 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 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Reserved | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Label | 140 | .... | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 The label can be encoded as in [RFC3209] when the C-Type is 1 or as a 144 Generalized Label [RFC3473] when the C-Type is 2 or 3. 146 4.1. Procedures 148 A RSVP-TE LSR that assigns Upstream-Assigned Labels, distributes them 149 to the downstream LSRs by including them in RSVP-TE Path messages. 151 A RSVP-TE LSR MUST NOT distribute the UPSTREAM_ASSIGNED_LABEL Object 152 to a downstream LSR if the downstream LSR had not previously 153 advertised the CAPABILITY object with the U bit set in its RSVP-TE 154 Hello messages. 156 If a downstream RSVP-TE LSR receives a Path message that carries an 157 UPSTREAM_ASSIGNED_LABEL Object and the LSR does not support the 158 object C-Num/C-Type it will return an "Unknown Object C-Num/C-Type" 159 error. If the LSR does support the object, but is unable to process 160 the upstream-assigned label as described in [MPLS-UPSTREAM] it SHOULD 161 send a PathErr with the error code "Routing problem" and the error 162 value "MPLS Upstream Assigned Label Processing Failure". If the LSR 163 successfully processes the Path message and the upstream-assigned 164 label it MUST send a Resv message upstream as per [RFC3209] but it 165 MUST NOT include the LABEL object with a downstream assigned label in 166 the Resv Message. This is because as described in [MPLS-UPSTREAM] two 167 LSRs Ru and Rd for a LSP that is bound to FEC F, MUST use either 168 downstream-assigned label distribution or upstream-assigned label 169 distribution,for FEC F, but NOT both, for packets that are to be 170 transmitted on the LSP from Ru to Rd. 172 5. RSVP-TE Tunnel Identifier Exchange 174 As described in [MPLS-UPSTREAM] an upstream LSR Ru MAY transmit a 175 MPLS packet, the top label of which (L) is upstream-assigned, to a 176 downstream LSR Rd, by encapsulating it in an IP or MPLS tunnel. In 177 this case the fact that L is upstream-assigned is determined by Rd by 178 the tunnel on which the packet is received. There must be a mechanism 179 for Ru to inform Rd that a particular tunnel from Ru to Rd will be 180 used by Ru for transmitting MPLS packets with upstream-assigned MPLS 181 labels. 183 When RSVP-TE is used for upstream label assignment, the IF_ID 184 RSVP_HOP object is used for signaling the Tunnel Identifier. If Ru 185 uses an IP or MPLS tunnel to transmit MPLS packets with upstream 186 assigned labels to Rd, Ru MUST include the IF_ID RSVP_HOP object 187 [RFC3473] in Path messages along with the UPSTREAM_ASSIGNED_LABEL 188 Object. 190 Three new TLVs are introduced in the IF_ID RSVP_HOP object [RFC3471] 191 to support RSVP-TE P2MP LSPs, IP Multicast Tunnels and context 192 labels. The TLV value acts as the tunnel identifier. 194 1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is the RSVP-TE 195 P2MP Session Object and optionally the P2MP Sender Template Object 196 [RFC4875]. The TLV value identifies the RSVP-TE P2MP LSP. This 197 mechanism extends RSVP-TE P2P Hierarchy [LSP-HIER] to RSVP-TE P2MP 198 Hierarchy. It allows Ru to tunnel an "inner" P2MP LSP, the label for 199 which is upstream assigned, over an "outer" P2MP LSP that has leaves 200 . The P2MP LSP IF_ID TLV allows Ru to signal to 201 the binding of the inner P2MP LSP to the outer P2MP LSP. 202 The control plane signaling between Ru and for the inner 203 P2MP LSP uses directed RSVP-TE signaling messages as in [LSP-HIER]. 205 2. IP Multicast Tunnel TLV. Type = TBD. In this case the TLV value is 206 a tuple. Source Address is 207 the IP address of the root of the tunnel i.e. Ru, and Multicast Group 208 Address is the Multicast Group Address used by the tunnel. 210 3. MPLS Context Label TLV. Type = TBD. In this case the TLV value is 211 a tuple. The Source Address 212 belongs to Ru and the MPLS Context Label is an upstream assigned 213 label, assigned by Ru. This allows Ru to tunnel an "inner" RSVP-TE 214 P2MP LSP, the label of which is upstream assigned, over an "outer" 215 MPLS LSP, where the outer LSP has the following property: 217 + The label pushed by Ru for the outer MPLS LSP is an upstream 218 assigned context label, assigned by Ru. When perform 219 a MPLS label lookup on this label a combination of this label and 220 the incoming interface MUST be sufficient for to 221 uniquely determine Ru's context specific label space to lookup 222 the next label on the stack in. MUST receive the data 223 sent by Ru with the context specific label assigned by Ru being 224 the top label on the label stack. 226 Currently the usage of the context label TLV is limited only to RSVP- 227 TE P2MP LSPs on a LAN as specified in the next section. The context 228 label TLV MUST NOT be used for any other purposes. 230 6. RSVP-TE Point-to-Multipoint LSPs on a LAN 232 This section describes one application of upstream label assignment 233 using RSVP-TE. Further applications are to be described in separate 234 documents. 236 [RFC4875] describes how to setup RSVP-TE P2MP LSPs. On a LAN the 237 solution described in [RFC4875] relies on "ingress replication". A 238 LSR on a LAN (say Il), that is a branch LSR for a P2MP LSP, (say Ru) 239 sends a separate copy of a packet that it receives on the P2MP LSP to 240 each of the downstream LSRs on the LAN (say that are 241 adjacent to it in the P2MP LSP. 243 In order to increase efficiency of bandwidth utilization, it is 244 desirable for Ru to send a single copy of the packet for the P2MP LSP 245 on the LAN, when there are multiple downstream routers on the LAN 246 that are adjacent in that P2MP LSP. This requires that each of 247 must be able to associate the label L, used by Ru to 248 transmit packets for the P2MP LSP on the LAN, with that P2MP LSP. It 249 is possible to achieve this using RSVP-TE upstream-assigned labels 250 with the following procedures. Assume that Ru and support 251 upstream label assignment. 253 Ru sends a Path message for the P2MP LSP to each of that 254 is adjacent on the P2MP LSP, with the same UPSTREAM_ASSIGNED_LABEL 255 object. This object carries an upstream assigned label, L. This 256 message also carries a MPLS Context Label TLV, as described in the 257 previous section, with the value of the MPLS label set to a value 258 assigned by Ru on inteface I1 as specified in [MPLS-UPSTREAM]. 259 "reserve" the upstream assigned label in the separate 260 Upstream Neighbor Label Space that they maintain for Ru [MPLS- 261 UPSTREAM]. 263 Ru can then transmit a single packet for the P2MP LSP to 264 with a top label L using procedures defined in [MPLS-UPSTREAM] and 265 [MPLS-MCAST-ENCAPS]. The MPLS packet transmitted by Ru contains as 266 the top label the context label assigned by Ru on the LAN interface, 267 I1. The bottom label is the upstream label assigned by Ru to the 268 RSVP-TE P2MP LSP. The top label is looked up in the context of the 269 LAN interface, I1, [MPLS-UPSTREAM] by a downstream LSR on the LAN. 270 This lookup enables the downstream LSR to determine the context 271 specific label space to lookup the inner label in. 273 If a subset of do not support upstream label assignment 274 these procedures can still be used between Ru and the remaining 275 subset of . Ingress replication and downstream label 276 assignment will continue to be used for LSRs that do not support 277 upstream label assignment. 279 7. Acknowledgements 281 Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and 282 Thomas Morin for their comments. 284 8. References 286 8.1. Normative References 288 [RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon, 289 RFC 3031. 291 [MPLS-UPSTREAM] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream 292 Label Assignment and Context Specific Label Space", draft-ietf-mpls- 293 upstream-label-05.txt 295 [MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, 296 draft-ietf-mpls-codepoint-08.txt 298 [RFC3209] Awduche et. al." "RSVP-TE: Extensions to RSVP for LSP 299 Tunnels", RFC 3209, December 2001. 301 [RFC2119] "Key words for use in RFCs to Indicate Requirement 302 Levels.", Bradner, March 1997 304 [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label 305 Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic 306 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 308 [RFC3471] Berger, L. Editor, "Generalized Multi-Protocol Label 309 Switching (GMPLS) Signaling Functional Description", RFC 3471 January 310 2003. 312 [RSVP-RESTART] A. Satyanarayana et. al., "Extensions to GMPLS RSVP 313 Graceful Restart", draft-ietf-ccamp-rsvp-restart-ext-02.txt 315 8.2. Informative References 317 [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs", 318 draft-ietf-l3vpn-2547bis-mcast-06.txt 320 [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors], 321 "Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875 323 9. Author's Address 325 Rahul Aggarwal 326 Juniper Networks 327 1194 North Mathilda Ave. 328 Sunnyvale, CA 94089 329 Phone: +1-408-936-2720 330 Email: rahul@juniper.net 332 Jean-Louis Le Roux 333 France Telecom 334 2, avenue Pierre-Marzin 335 22307 Lannion Cedex 336 France 337 E-mail: jeanlouis.leroux@orange-ftgroup.com 339 10. Intellectual Property Statement 341 The IETF takes no position regarding the validity or scope of any 342 Intellectual Property Rights or other rights that might be claimed to 343 pertain to the implementation or use of the technology described in 344 this document or the extent to which any license under such rights 345 might or might not be available; nor does it represent that it has 346 made any independent effort to identify any such rights. Information 347 on the procedures with respect to rights in RFC documents can be 348 found in BCP 78 and BCP 79. 350 Copies of IPR disclosures made to the IETF Secretariat and any 351 assurances of licenses to be made available, or the result of an 352 attempt made to obtain a general license or permission for the use of 353 such proprietary rights by implementers or users of this 354 specification can be obtained from the IETF on-line IPR repository at 355 http://www.ietf.org/ipr. 357 The IETF invites any interested party to bring to its attention any 358 copyrights, patents or patent applications, or other proprietary 359 rights that may cover technology that may be required to implement 360 this standard. Please address the information to the IETF at ietf- 361 ipr@ietf.org. 363 11. Full Copyright Statement 365 Copyright (C) The IETF Trust (2008). This document is subject to the 366 rights, licenses and restrictions contained in BCP 78, and except as 367 set forth therein, the authors retain all their rights. 369 This document and the information contained herein are provided on an 370 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 371 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 372 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 373 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 374 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 375 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.