idnits 2.17.1 draft-ietf-mpls-rsvp-upstream-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 19. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 313. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 326. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 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 (March 2006) is 6616 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 255, but no explicit reference was found in the text == Unused Reference: 'MVPN' is defined on line 284, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-mpls-upstream-label-00 -- 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 Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 7 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: September 2006 5 J. L. Le Roux 6 France Telecom 8 March 2006 10 MPLS Upstream Label Assignment for RSVP-TE 12 draft-ietf-mpls-rsvp-upstream-00.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 ............. 5 54 7 Acknowledgements ...................................... 6 55 8 References ............................................ 6 56 8.1 Normative References .................................. 6 57 8.2 Informative References ................................ 7 58 9 Author Information .................................... 7 59 10 Intellectual Property Statement ....................... 8 60 11 Full Copyright Statement .............................. 8 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 avoid- 83 ing branch LSR [RSVP-P2MP] traffic replication on a LAN for RSVP-TE 84 P2MP TE LSPs [RSVP-TE-P2MP] 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 adver- 91 tise to its RSVP-TE neighbor LSR(s) its support of upstream-assigned 92 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 sup- 97 port for RecoveryPath Srefresh. This document defines a new flag, the 98 U flag, to signal a LSR's support of upstream label assignment to its 99 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 adver- 153 tised the CAPABILITY object with the U bit set in its RSVP-TE Hello 154 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 Two new TLVs are introduced in the IF_ID RSVP_HOP object [RFC3471] to 191 support RSVP-TE P2MP LSPs and IP Multicast Tunnels. The TLV value 192 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 [RSVP-TE-P2MP]. 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. 208 6. RSVP-TE Point-to-Multipoint LSPs on a LAN 210 This section describes one application of upstream label assignment 211 using RSVP-TE. Further applications are to be described in separate 212 documents. 214 [RSVP-TE-P2MP] describes how to setup RSVP-TE P2MP LSPs. On a LAN the 215 solution described in [RSVP-TE-P2MP] relies on "ingress replication". 216 A LSR on a LAN, that is a branch LSR for a P2MP LSP, (say Ru) sends a 217 separate copy of a packet that it receives on the P2MP LSP to each of 218 the downstream LSRs on the LAN (say that are adjacent to 219 it in the P2MP LSP. 221 In order to increase efficiency of bandwidth utilization, it is 222 desirable for Ru to send a single copy of the packet for the P2MP LSP 223 on the LAN, when there are multiple downstream routers on the LAN 224 that are adjacent in that P2MP LSP. This requires that each of 225 must be able to associate the label L, used by Ru to 226 transmit packets for the P2MP LSP on the LAN, with that P2MP LSP. It 227 is possible to achieve this using RSVP-TE upstream-assigned labels 228 with the following procedures. Assume that Ru and support 229 upstream label assignment. 231 Ru sends a Path message for the P2MP LSP to each of that 232 is adjacent on the P2MP LSP, with the same UPSTREAM_ASSIGNED_LABEL 233 object. This object carries an upstream assigned label, L. 234 "reserve" the upstream assigned label in the separate 235 Upstream Neighbor Label Space that they maintain for Ru [MPLS- 236 UPSTREAM]. Ru can then transmit a single packet for the P2MP LSP to 237 with a top label L using procedures defined in [MPLS- 238 UPSTREAM] and [MPLS-MCAST-ENCAPS]. 240 If a subset of does not support upstream label assignment 241 these procedures can still be used between Ru and the remaining sub- 242 set of . Ingress replication and downstream label assign- 243 ment will continue to be used for LSRs that do not support upstream 244 label assignment. 246 7. Acknowledgements 248 Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and 249 Thomas Morin for their comments. 251 8. References 253 8.1. Normative References 255 [RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon, 256 RFC 3031. 258 [MPLS-UPSTREAM] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream 259 Label Assignment and Context Specific Label Space", draft-ietf-mpls- 260 upstream-label-00.txt 262 [MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, 263 draft-ietf-mpls-codepoint-00.txt 265 [RFC3209] Awduche et. al." "RSVP-TE: Extensions to RSVP for LSP Tun- 266 nels", RFC 3209, December 2001. 268 [RFC2119] "Key words for use in RFCs to Indicate Requirement Lev- 269 els.", Bradner, March 1997 271 [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label 272 Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic 273 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 275 [RFC3471] Berger, L. Editor, "Generalized Multi-Protocol Label 276 Switching (GMPLS) Signaling Functional Description", RFC 3471 January 277 2003. 279 [RSVP-RESTART] A. Satyanarayana et. al., "Extensions to GMPLS RSVP 280 Graceful Restart", draft-ietf-ccamp-rsvp-restart-ext-02.txt 282 8.2. Informative References 284 [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs" 286 [RSVP-TE-P2MP] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors], 287 "Extensions to RSVP-TE for Point to Multipoint TE LSPs" 289 9. Author Information 291 Rahul Aggarwal 292 Juniper Networks 293 1194 North Mathilda Ave. 294 Sunnyvale, CA 94089 295 Email: rahul@juniper.net 297 Jean-Louis Le Roux 298 France Telecom 299 2, avenue Pierre-Marzin 300 22307 Lannion Cedex 301 France 302 E-mail: jeanlouis.leroux@francetelecom.com 304 10. Intellectual Property Statement 306 The IETF takes no position regarding the validity or scope of any 307 Intellectual Property Rights or other rights that might be claimed to 308 pertain to the implementation or use of the technology described in 309 this document or the extent to which any license under such rights 310 might or might not be available; nor does it represent that it has 311 made any independent effort to identify any such rights. Information 312 on the procedures with respect to rights in RFC documents can be 313 found in BCP 78 and BCP 79. 315 Copies of IPR disclosures made to the IETF Secretariat and any assur- 316 ances of licenses to be made available, or the result of an attempt 317 made to obtain a general license or permission for the use of such 318 proprietary rights by implementers or users of this specification can 319 be obtained from the IETF on-line IPR repository at 320 http://www.ietf.org/ipr. 322 The IETF invites any interested party to bring to its attention any 323 copyrights, patents or patent applications, or other proprietary 324 rights that may cover technology that may be required to implement 325 this standard. Please address the information to the IETF at ietf- 326 ipr@ietf.org. 328 11. Full Copyright Statement 330 Copyright (C) The Internet Society (2006). This document is subject 331 to the rights, licenses and restrictions contained in BCP 78, and 332 except as set forth therein, the authors retain all their rights. 334 This document and the information contained herein are provided on an 335 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 336 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 337 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 338 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 339 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 340 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.