idnits 2.17.1 draft-ietf-mpls-upstream-label-02.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 436. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 409. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 416. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 422. 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 == Line 104 has weird spacing: '...ces. In gener...' == Line 108 has weird spacing: '...mple of a con...' == Line 109 has weird spacing: '...l space discu...' == Line 113 has weird spacing: '...packets recei...' == Line 114 has weird spacing: '... need to h...' == (5 more instances...) -- 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 2007) is 6245 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: 'RFC3353' is mentioned on line 87, but not defined == Missing Reference: 'RFC 3032' is mentioned on line 323, but not defined -- No information found for draft-ietf-mpls-codepoint - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MPLS-MCAST-ENCAPS' -- No information found for draft-ietf-l3vn-2547bis-mcast - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 10 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 2007 5 Y. Rekhter 6 Juniper Networks 8 E. Rosen 9 Cisco Systems, Inc. 11 March 2007 13 MPLS Upstream Label Assignment and Context Specific Label Space 15 draft-ietf-mpls-upstream-label-02.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 RFC 3031 limits the MPLS architecture to downstream assigned MPLS 43 labels. This document introduces the notion of upstream assigned 44 MPLS labels. It describes the procedures for upstream MPLS label 45 assignment and introduces the concept of a "Context-Specific Label 46 Space". 48 Table of Contents 50 1 Specification of requirements ......................... 2 51 2 Introduction .......................................... 2 52 3 Context-Specific Label Space .......................... 3 53 4 Upstream Label Assignment ............................. 4 54 4.1 Upstream Assigned and Downstream Assigned Labels ...... 4 55 5 Assigning Upstream Assigned Labels .................... 5 56 6 Distributing Upstream Assigned Labels ................. 5 57 7 Upstream Neighbor Label Space and Tunnel Label Space .. 6 58 8 Context Label on LANs ................................. 7 59 9 Usage of Upstream Assigned Labels ..................... 8 60 10 Acknowledgements ...................................... 8 61 11 References ............................................ 9 62 11.1 Normative References .................................. 9 63 11.2 Informative References ................................ 9 64 12 Author Information .................................... 9 65 13 Intellectual Property Statement ....................... 10 66 14 Full Copyright Statement .............................. 10 68 1. Specification of requirements 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in [RFC2119]. 74 2. Introduction 76 RFC 3031 [RFC3031] limits the MPLS architecture to downstream 77 assigned MPLS labels. To quote from RFC 3031: 79 "In the MPLS architecture, the decision to bind a particular label L 80 to a particular FEC F is made by the LSR which is DOWNSTREAM with 81 respect to that binding. The downstream LSR then informs the 82 upstream LSR of the binding. Thus labels are "downstream-assigned", 83 and label bindings are distributed in the "downstream to upstream" 84 direction." 86 MPLS upstream label assignment has been discussed and mentioned 87 before [RFC3353, MVPN]. However the architecture for MPLS upstream 88 label assignment and the associated procedures have not been 89 described. This document introduces the notion of upstream assigned 90 MPLS labels to the MPLS architecture. The procedures for upstream 91 MPLS label assignment are described. 93 RFC 3031 describes per-platform and per-interface label space. This 94 document generalizes the latter to a "Context-Specific Label Space" 95 and describes a "Neighbor Label Space" as an example of this. 96 Upstream assigned labels are always looked up in a context-specific 97 label space. 99 3. Context-Specific Label Space 101 RFC 3031 describes per-platform and per-interface label spaces. This 102 document introduces the more general concept of a "Context-Specific 103 Label Space". A LSR may contain one or more context-specific label 104 spaces. In general, labels are looked up in the per-platform label 105 space unless something about the context determines that a label be 106 looked up in a particular context-specific label space. 108 One example of a context-specific label space is the per-interface 109 label space discussed in RFC 3031. When a MPLS packet is received 110 over a particular interface the top label of the packet may need to 111 be looked up in the receiving interface's per-interface label space. 112 In this case the receiving interface determines the context of the 113 packet. Whether MPLS packets received over a particular interface 114 need to have their top labels looked up in a per-interface 115 label space depends on some characteristic or configuration of the 116 interface. 118 There may be more than one kind of context-specific label space. 119 Context-specific label spaces can be used for downstream assigned 120 labels or upstream assigned labels. Per-interface label space 121 [RFC3031] is an example of a context-specific label space used for 122 downstream assigned labels. 124 When MPLS labels are upstream assigned the context of a MPLS label L 125 is provided by the LSR that assigns the label and binds the label to 126 a FEC F for a LSP LSP1. The LSR that assigns the label distributes 127 the binding and context to a LSR Lr that then receives MPLS packets 128 on LSP1 with label L. When Lr receives a MPLS packet on LSP1 it MUST 129 be able to determine the context of this packet. 131 An example of such a context is a Tunnel over which MPLS packets on 132 LSP1 may be received and in this case the top label of the MPLS 133 packet is looked up in a "Tunnel Specific Label Space". This does 134 imply that Lr be able to determine the tunnel over which the packet 135 was received. If the tunnel is a MPLS tunnel, penultimate-hop-popping 136 (PHP) must be disabled for the tunnel. Another example of such a 137 context is the neighbor from which MPLS packets on LSP1 may be 138 received and in this case the top label of the MPLS packet is looked 139 up in a "Neighbor Specific Label Space". These are further described 140 in section 7. 142 There may be other sorts of contexts as well. For instance, we define 143 the notion of a MPLS label being used to establish a context, i.e. 144 identify a label space. 146 4. Upstream Label Assignment 148 When two MPLS LSRs are adjacent in a MPLS label switched path (LSP) 149 one of them can be termed an "upstream LSR" and the other a 150 "downstream LSR" [RFC3031]. Consider two LSRs, Ru and Rd that have 151 agreed to bind Label L to a Forwarding Equivalence Class (FEC), F, 152 for packets sent from Ru to Rd. Then with respect to this binding, 153 Ru is the "upstream LSR", and Rd is the "downstream LSR"." 155 When the label binding for F is first made by Rd and distributed by 156 Rd to Ru, the binding is said to be "downstream assigned". When 157 the label binding for F is first made by Ru and distributed by Ru 158 to Rd, the binding is said to be "upstream assigned". 160 An important observation is that the downstream LSR Rd that receives 161 MPLS packets with a top label L is not the LSR that assigns and 162 distributes label L. Rd must use a context-specific label space to 163 lookup label L as described in section 7. 165 4.1. Upstream Assigned and Downstream Assigned Labels 167 It is possible that some LSRs on a LSP for FEC F, distribute 168 downstream assigned label bindings for FEC F, while other LSRs 169 distribute upstream assigned label bindings. It is possible for a LSR 170 to distribute a downstream assigned label binding for FEC F to its 171 upstream adjacent LSR AND distribute an upstream assigned label 172 binding for FEC F to its downstream adjacent LSR. Two adjacent LSRs 173 for a LSP that is bound to FEC F, MUST use either downstream assigned 174 label distribution or upstream assigned label distribution, for FEC 175 F, but NOT both. How these LSRs will determine which of the two is to 176 be used is outside the scope of this document. 178 5. Assigning Upstream Assigned Labels 180 The only requirement on an upstream LSR assigning upstream assigned 181 labels is that an upstream assigned label must be unambiguous in the 182 context-specific label space in which the downstream LSR will look it 183 up. An upstream LSR which is the head end of multiple tunnels SHOULD 184 by default assign the upstream-assigned labels from a single label 185 space which is common to all those tunnels. Further an upstream LSR 186 which is the head of multiple tunnels SHOULD use the same IP address 187 as the head identifier of these tunnels, provided that the head 188 identifier of these tunnels is an IP address. The LSR could assign 189 the same label value to both a downstream-assigned and an upstream- 190 assigned label. The downstream LSR always looks up upstream assigned 191 MPLS labels in a context-specific label space as described in section 192 7. 194 An entry for the upstream assigned labels is not created in the 195 Incoming Label Map (ILM) [RFC3031] at the upstream LSR as these 196 labels are not incoming labels. Instead an upstream label is an 197 outgoing label, with respect to the upstream LSR, for MPLS packets 198 transmitted on the MPLS LSP in which the upstream LSR is adjacent to 199 the downstream LSR. Hence an upstream label is part of a Next Hop 200 Label Forwarding Entry (NHLFE) at the upstream LSR. 202 When Ru advertises a binding of label L for FEC F to Rd, it creates a 203 NHLFE entry corresponding to L. This NHLFE entry results in imposing 204 the label L on the MPLS label stack of the packet forwarded using the 205 NHLFE entry. If Ru is a transit router on the LSP for FEC F, it 206 binds the ILM for the LSP to this NHLFE. If Ru is an ingress router 207 on the LSP for FEC F, it binds the FEC to the NHLFE entry. 209 6. Distributing Upstream Assigned Labels 211 Upstream-assigned label bindings MUST NOT be used unless it is known 212 that the downstream LSR supports them. How this is known is outside 213 the scope of this document. 215 MPLS upstream label assignment requires a label distribution protocol 216 to distribute the binding from the upstream LSR to the downstream 217 LSR. Considerations that pertain to a label distribution protocol 218 that are described in [RFC3031] apply. 220 The distribution of the upstream-assigned labels is similar to either 221 the ordered LSP control or independent LSP control of the downstream- 222 assigned labels. In the former case a LSR distributes an upstream- 223 assigned label binding for a FEC F if it is either (a) the ingress 224 LSR for FEC F, or (b) if it has already received an upstream label 225 binding for that FEC from its adjacent upstream LSR for FEC F, or (c) 226 if it has received a request for a downstream label binding from its 227 upstream adjacent LSR. In the latter case each LSR, upon noting that 228 it recognizes a particular FEC, makes an independent decision to bind 229 an upstream-assigned label to that FEC and to distribute that binding 230 to its label distribution peers. 232 7. Upstream Neighbor Label Space and Tunnel Label Space 234 If the top label of a MPLS packet being processed by LSR Rd is 235 upstream assigned, the label is looked up in a context-specific 236 label space, not in a per-platform label space. 238 Rd uses a context-specific label space that it maintains for Ru to 239 "reserve" MPLS labels assigned by Ru. Hence if Ru distributes an 240 upstream assigned label binding L for FEC F to Rd, then Rd reserves L 241 in the separate ILM for Ru's context-specific label space. This is 242 the ILM that Rd uses to lookup a MPLS label which is upstream 243 assigned by Ru. This label may be the top label on the label stack of 244 a packet received from Ru or it may be exposed as the top label on 245 the label stack as a result of Rd processing such a packet. 247 This implies that Rd MUST be able to determine whether the top label 248 of a MPLS packet being processed is upstream assigned and if yes, the 249 "context" of this packet. How this determination is made depends on 250 the mechanism that is used by Ru to transmit the MPLS packet with an 251 upstream assigned top label L, to Rd. 253 If Ru transmits this packet by encapsulating it in an IP or MPLS 254 tunnel, then the fact that L is upstream assigned is determined by Rd 255 by the tunnel on which the packet is received. A given tunnel can be 256 used for transmitting either downstream assigned MPLS packets or 257 upstream assigned MPLS packets, or both. There must be a mechanism 258 for Ru to inform Rd that a particular tunnel from Ru to Rd will be 259 used by Ru for transmitting MPLS packets with upstream assigned MPLS 260 labels. The description of such a mechanism is outside the scope of 261 this document. When Rd receives MPLS packets with a top label L on 262 such a tunnel, it determines the "context" of this packet based on 263 the tunnel that the packet is received on. 265 Rd may maintain a separate "Tunnel Label Space" for the tunnel or it 266 may maintain an Upstream Neighbor Label Space" for all tunnels that 267 have the same root. If Rd uses the "Upstream Neighbor Label Space" 268 for upstream assigned MPLS packets transmitted by Ru to Rd, over IP 269 or MPLS tunnels, then Rd MUST be able to determine the root of these 270 IP/MPLS tunnels. Rd would then use a separate label space for each 271 unique root. 273 If the tunnel on which Rd receives MPLS packets with a top label L is 274 a MPLS tunnel, then Rd determines a) That L is upstream assigned and 275 b) The context for L, from the labels above L in the label stack. 276 Note that one or more of these labels may also be upstream assigned 277 labels. 279 If the tunnel on which Rd receives MPLS packets with a top label L is 280 an IP/GRE tunnel then Rd determines a) That L is upstream assigned 281 [MPLS-MCAST-ENCAPS] and b) The context for L, from the source address 282 in the IP header. 284 When Ru and Rd are adjacent to each other on a multi-access data link 285 media, if Ru would transmit the packet, with top label L, by 286 encapsulating it in a data link frame, then whether L is upstream 287 assigned or downstream assigned can be determined by Rd as described 288 in [MPLS-MCAST-ENCAPS]. This is because if L is upstream assigned 289 then [MPLS-MCAST-ENCAPS] uses a different ether type in the data link 290 frame. However this is not sufficient for Rd to determine the context 291 of this packet. In order for Rd to determine the context of this 292 packet, Ru encapsulates the packet, in a one hop MPLS tunnel. This 293 tunnel uses an MPLS context label that is assigned by Ru. Section 8 294 describes how the context label is assigned. Rd maintains a separate 295 "Upstream Neighbor Label Space" for Ru. The "context" of this packet, 296 i.e. Ru's upstream neighbor label space, in which L was reserved, is 297 determined by Rd from the top context label and the interface on 298 which the packet is received. The ether type in the data link frame 299 is set to indicate that the top label is upstream assigned. The 300 second label in the stack is L. 302 8. Context Label on LANs 304 The procedure described below applies to LSRs using IPv4 and does not 305 apply to LSRs only using IPv6. A solution for IPv6 LSRs is outside 306 the scope of this document. 308 For a labeled packet with an ether type of 'upstream label 309 assignment' the top label is used as the context. The context label 310 value is assigned by the upstream LSR and advertised to the 311 downstream LSRs. Mechanisms for advertising the context label are 312 outside the scope of this document. 314 The context label assigned by a LSR on a LAN interface MUST be unique 315 across all the context labels assigned by other LSRs on the same LAN. 316 Each LAN interface is normally configured with a primary IPv4 address 317 that is unique on that LAN. The host part of the IPv4 address, 318 identified by the network mask, is unique. If the IPv4 network mask 319 is greater then 12 bits, it is possible to map the remaining 20 bits 320 into an unique context label value. This enables the LSRs on the LAN 321 to assign an unique context label without the need for additional 322 configuration. To avoid assigning context label values that fall into 323 the reserved label space range [RFC 3032], the value of the host is 324 offset with 0x10 if the host is not greater then 0xFFFEF. Host values 325 greater then 0xFFFEF are not allowed to be used as the context label. 327 Consider LSRs Rm (middle) connected to Ru (upstream) on a LAN 328 interface and to Rd (downstream) on a different LAN interface. Rm 329 could receive a context label value derived from the LAN interface 330 from Rd and from Ru. It is possible that the context label values 331 used by Ru and Rd are the same. This would occur if the LAN 332 interfaces of both Ru and Rd are configured with a primary IPv4 333 address where the lowest 20 bits are equal. To avoid these conflicts 334 the context label MUST be looked up in the context of the LAN 335 interface identifier on which the packet is received. A receiving LSR 336 that receives a packet with a context label of Lc over LAN interface 337 identified by X, MUST use the label space specific to X to lookup Lc. 338 This determines the context to lookup the label below Lc on the label 339 stack. 341 9. Usage of Upstream Assigned Labels 343 A typical usage of upstream assigned labels is when an upstream LSR 344 Ru is adjacent to more than downstream LSRs in a LSP LSP1 345 AND Ru is connected to via a multi-access media or tunnel 346 AND Ru wants to transmit a single copy of a MPLS packet on the LSP to 347 . In this case Ru can distribute an upstream assigned 348 label L that is bound to the FEC for LSP1, to and transmit 349 a MPLS packet, the top label of which is L, on the multi-access media 350 or tunnel. Each of will then interpret this MPLS packet in 351 the context of Ru and forward it appropriately. This implies that 352 MUST all be able to support an Upstream Neighbor Label 353 Space for Ru and Ru MUST be able to determine this. The mechanisms 354 for determining this are specific to the application that is using 355 upstream assigned labels and is outside the scope of this document. 357 10. Acknowledgements 359 Thanks to IJsbrand Wijnands's contribution, specifically for the text 360 on which section 8 is based. 362 11. References 364 11.1. Normative References 366 [RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon, 367 RFC 3031. 369 [RFC2119] "Key words for use in RFCs to Indicate Requirement 370 Levels.", Bradner, March 1997 372 [MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, 373 draft-ietf-mpls-codepoint-01.txt 375 11.2. Informative References 377 [MVPN] E. Rosen, R. Aggarwal [Editors], Multicast in BGP/MPLS VPNs", 378 draft-ietf-l3vn-2547bis-mcast-02.txt 380 12. Author Information 382 Rahul Aggarwal 383 Juniper Networks 384 1194 North Mathilda Ave. 385 Sunnyvale, CA 94089 386 Email: rahul@juniper.net 388 Yakov Rekhter 389 Juniper Networks 390 1194 North Mathilda Ave. 391 Sunnyvale, CA 94089 392 Email: yakov@juniper.net 394 Eric C. Rosen 395 Cisco Systems, Inc. 396 1414 Massachusetts Avenue 397 Boxborough, MA 01719 398 Email: erosen@cisco.com 400 13. Intellectual Property Statement 402 The IETF takes no position regarding the validity or scope of any 403 Intellectual Property Rights or other rights that might be claimed to 404 pertain to the implementation or use of the technology described in 405 this document or the extent to which any license under such rights 406 might or might not be available; nor does it represent that it has 407 made any independent effort to identify any such rights. Information 408 on the procedures with respect to rights in RFC documents can be 409 found in BCP 78 and BCP 79. 411 Copies of IPR disclosures made to the IETF Secretariat and any 412 assurances of licenses to be made available, or the result of an 413 attempt made to obtain a general license or permission for the use of 414 such proprietary rights by implementers or users of this 415 specification can be obtained from the IETF on-line IPR repository at 416 http://www.ietf.org/ipr. 418 The IETF invites any interested party to bring to its attention any 419 copyrights, patents or patent applications, or other proprietary 420 rights that may cover technology that may be required to implement 421 this standard. Please address the information to the IETF at ietf- 422 ipr@ietf.org. 424 14. Full Copyright Statement 426 Copyright (C) The IETF Trust (2007). This document is subject to the 427 rights, licenses and restrictions contained in BCP 78, and except as 428 set forth therein, the authors retain all their rights. 430 This document and the information contained herein are provided on an 431 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 432 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 433 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 434 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 435 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 436 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.