idnits 2.17.1 draft-ietf-mpls-multicast-encaps-06.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 417. 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 abstract seems to indicate that this document updates RFC3032, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC4023, but the header doesn't have an 'Updates:' line to match this. 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 (June 2007) is 6159 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) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-upstream-label-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Toerless Eckert 3 Internet Draft Eric C. Rosen (editor) 4 Expiration Date: December 2007 Cisco Systems, Inc. 5 Updates RFCs 3032 and 4023 6 Rahul Aggarwal 7 Yakov Rekhter 8 Juniper Networks, Inc. 10 June 2007 12 MPLS Multicast Encapsulations 14 draft-ietf-mpls-multicast-encaps-06.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 Abstract 40 RFC 3032 established two data link layer codepoints for MPLS: one to 41 indicate that the data link layer frame is carrying an MPLS unicast 42 packet, and the other to indicate that the data link layer frame is 43 carrying an MPLS multicast packet. This specification updates RFC 44 3032 by redefining the meaning of these two codepoints. The former 45 "multicast codepoint" is now to be used only on multiaccess media, 46 and it is to mean "the top label of the following label stack is an 47 upstream-assigned label". The former "unicast codepoint" is to be 48 used in all other cases. Whether the data link layer payload is a 49 unicast MPLS packet or a multicast MPLS packet is now to be 50 determined by looking up the top label, rather than by the codepoint. 52 RFC 3032 does not specify the destination address to be placed in the 53 "MAC DA" field of an ethernet frame which carries an MPLS multicast 54 packet. This document provides that specification. 56 This document updates RFC 3032 and RFC 4023. 58 Contents 60 1 Specification of Requirements ........................... 2 61 2 Introduction ............................................ 3 62 3 Upstream-Assigned vs. Downstream-Assigned ............... 4 63 4 Ethernet Codepoints ..................................... 6 64 5 PPP Protocol Field ...................................... 6 65 6 GRE Protocol Type ....................................... 6 66 7 IP Protocol Number ...................................... 7 67 8 Ethernet MAC DA for Multicast MPLS ...................... 7 68 9 IANA Considerations ..................................... 8 69 10 Security Considerations ................................. 8 70 11 Normative References .................................... 8 71 12 Informative References .................................. 9 72 13 Authors' Addresses ...................................... 9 73 14 Full Copyright Statement ................................ 10 74 15 Intellectual Property ................................... 10 76 1. Specification of Requirements 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 2. Introduction 84 RFC 3031 [RFC3031] defines the "Next Hop Label Forwarding Entry" 85 (NHLFE). The NHLFE for a particular label maps the label into a next 86 hop (among other things). When an MPLS packet is received, its top 87 label is mapped to an NHLFE, and the packet is sent to the next hop 88 specified by the NHLFE. 90 We define a particular MPLS label to be a "multicast label" in a 91 particular context if the NHLFE to which it is mapped in that context 92 specifies a set of next hops, with the semantics that the packet is 93 to be replicated, and a copy of the packet sent to each of the 94 specified next hops. Note that this definition accommodates the case 95 where the set of next hops contains a single member. What makes a 96 label a multicast label in a particular context is the semantics 97 attached to the set, i.e., the intention to replicate the packet and 98 transmit to all members of the set if the set has more than one 99 member. 101 RFC 3032 [RFC3032] established two data link layer codepoints for 102 MPLS: one to indicate that the data link layer frame is carrying an 103 MPLS unicast packet, and the other to indicate that the data link 104 layer frame is carrying an MPLS multicast packet. The term 105 "multicast packet" is not precisely defined in RFC 3032, though one 106 may presume that the "multicast" codepoint is intended to identify 107 the packet's top label as a multicast label. However, the multicast 108 codepoint has never been deployed, and further development of the 109 procedures for MPLS multicast have shown that, while there is a need 110 for two codepoints, the use of the two codepoints is not properly 111 captured by RFC 3032. 113 In particular, there is no need for the codepoint to indicate whether 114 the top MPLS label is a multicast label. When the receiver of an 115 MPLS packet looks up the top label, the NHLFE will specify whether 116 the label is a multicast label or not. 118 This document updates RFC 3032 and RFC 4023 by re-specifying the use 119 of the codepoints. 121 While RFC 3032 allows an MPLS packet to be carried in an ethernet 122 multicast frame, it fails to specify how the Medium Access Layer 123 Destination Address (MAC DA) field is to be set in that case. This 124 document provides that specification. 126 3. Upstream-Assigned vs. Downstream-Assigned 128 According to RFC 3031 [RFC3031], if two MPLS Label Switching Routers 129 (LSRs) are adjacent in a label switched path (LSP), with respect to 130 that LSP, one of them may be called the "upstream" LSR and the other 131 the "downstream" LSR. Call these Ru and Rd respectively. Before Ru 132 can send an MPLS packet to Rd with label L at the top of the label 133 stack, Ru and Rd must agree on the Forwarding Equivalence Class (FEC) 134 which is bound to L. A particular binding of L to FEC F is called a 135 "downstream-assigned" binding if the binding is first made by Rd and 136 then advertised to Ru. If the binding is first made by Ru and then 137 advertised to Rd, it is called an "upstream-assigned" binding. 139 If Ru and RD are LSP adjacencies, then they transmit a MPLS packet to 140 each other through one of the following mechanisms: 142 1. by putting the MPLS packet in a data link layer frame and 143 transmitting the frame 145 2. by transmitting the MPLS packet through an MPLS tunnel, i.e., 146 by pushing an additional label (or labels) onto the label 147 stack, and then invoking mechanism 1, 149 3. by transmitting the MPLS packet through an IP-based tunnel 150 (e.g., via RFC 4023 [RFC4023]), and then invoking mechanisms 1 151 and/or 2. 153 In short, an MPLS packet is transmitted either through a data link or 154 through an MPLS tunnel or through an IP tunnel. In any of those 155 cases, when the packet emerges through the tunnel, the downstream LSR 156 must know whether the label that now appears at the top of the label 157 stack has an upstream-assigned label binding or a downstream-assigned 158 label binding. For convenience, we will speak of a label with an 159 upstream-assigned label binding as an "upstream-assigned label". 161 Unicast labels MUST be downstream-assigned. 163 Under certain conditions, specified below, multicast labels MAY be 164 upstream-assigned. The ability to use upstream-assigned labels is an 165 OPTIONAL feature. Upstream-assigned labels MUST NOT be used unless 166 it is known that the downstream LSR supports them. How this is known 167 is outside the scope of this document. 169 We discuss three different types of data link or tunnel: 171 - Point-to-Point. A point-to-point data link or tunnel associates 172 two systems, such that transmissions on that link or tunnel made 173 by the one are received by the other, and only by the other. 175 For a given direction of a given point-to-point data link or 176 tunnel, the following MUST be the case: either every MPLS packet 177 will carry an upstream-assigned label, or else every MPLS packet 178 will carry a downstream-assigned label. The procedures for 179 determining whether upstream-assigned or downstream-assigned 180 labels are being used are outside the scope of this 181 specification. However, in the absence of any other information, 182 the use of downstream-assigned labels MUST be presumed by 183 default. 185 - Point-to-Multipoint. A point-to-multipoint link or tunnel 186 associates n systems, such that only one of them can transmit 187 onto the link or tunnel, and the transmissions may be received by 188 the other n-1 systems. 190 The top labels (before applying the data link or tunnel 191 encapsulation) of all MPLS packets which are transmitted on a 192 particular point-to-multipoint data link or tunnel MUST be of the 193 same type; either all upstream-assigned or all downstream- 194 assigned. This means that all the receivers on the MPLS or IP 195 tunnel must know a priori whether upstream-assigned or 196 downstream-assigned labels are being used in the tunnel. How 197 this is known is outside the scope of this document. 199 - Multipoint-to-Multipoint. A multipoint-to-multipoint link or 200 tunnel associates n systems, such that any of them can transmit 201 on the link or tunnel, and the transmissions may be received by 202 the other n-1 systems. 204 If MPLS packets are transmitted on a particular multipoint-to- 205 multipoint link or tunnel, one of the following scenarios 206 applies: 208 1. It is known (by methods outside the scope of this document) 209 that the top label of every MPLS packet on the link or 210 tunnel is downstream-assigned 212 2. It is known (by methods outside the scope of this document) 213 that the top label of every MPLS packet on the link or 214 tunnel is upstream-assigned 216 3. Some MPLS packets on the link may have upstream-assigned 217 top labels while some may have downstream-assigned top 218 labels 220 If (and only if) the third scenario applies, the data link or 221 tunnel encapsulation MUST provide a codepoint which specifies 222 whether the top label of the encapsulated MPLS packet is 223 upstream-assigned or downstream-assigned. If a particular type 224 of data link or tunnel does not provide such a codepoint, then 225 the third scenario MUST NOT be used. 227 The remainder of this document specifies procedures for setting the 228 data link layer codepoints and address fields. 230 4. Ethernet Codepoints 232 Ethernet is an example of a multipoint-to-multipoint data link. 234 Ethertype 0x8847 is used whenever a unicast ethernet frame carries an 235 MPLS packet. 237 Ethertype 0x8847 is also used whenever a multicast ethernet frame 238 carries an MPLS packet, EXCEPT for the case where the top label of 239 the MPLS packet has been upstream-assigned. 241 Ethertype 0x8848, formerly known as the "MPLS multicast codepoint", 242 is to be used only when an MPLS packet whose top label is upstream- 243 assigned is carried in a multicast ethernet frame. 245 5. PPP Protocol Field 247 PPP is an example of a point-to-point data link. When a PPP frame is 248 carrying an MPLS packet, the PPP Protocol field is always set to 249 0x0281. 251 6. GRE Protocol Type 253 RFC 4023 is modified as described below. 255 If the IP destination address of the GRE encapsulation is a unicast 256 IP address, then the ethertype value 0x8847 MUST be used in all cases 257 for the MPLS-in-GRE encapsulation. 259 If the IP destination address of the GRE encapsulation is a multicast 260 IP address, then: 262 - the ethertype value 0x8847 MUST be used when the top label of the 263 encapsulated MPLS packet is downstream-assigned, 265 - the ethertype value 0x8848 MUST be used when the top label of the 266 encapsulated MPLS packet is upstream-assigned. 268 Through procedures which are outside the scope of this specification, 269 it may be known that if the destination address of a GRE packet is a 270 multicast IP address, then the top label of the GRE payload is 271 upstream-assigned. In such a case, the occurrence of the 8847 272 codepoint in a GRE packet with a multicast destination IP address 273 MUST be considered an error, and the packet MUST be discarded. 275 7. IP Protocol Number 277 RFC 4023 is modified as follows: the IPv4 Protocol Number field or 278 the IPv6 Next Header field is always set to 137, whether or not the 279 encapsulated MPLS packet is an MPLS multicast packet. 281 If the IP destination address of the IP encapsulation is an IP 282 multicast address, the IP tunnel may be considered to be a point-to- 283 multipoint tunnel or a multipoint-to-multipoint tunnel. In either 284 case, either all encapsulated MPLS packets in the particular tunnel 285 have a downstream-assigned label at the top of the stack, or all 286 encapsulated MPLS packets in that tunnel have an upstream-assigned 287 label at the top of the stack. The means by which this is determined 288 for a particular tunnel is outside the scope of this specification. 290 8. Ethernet MAC DA for Multicast MPLS 292 When an LSR transmits a multicast MPLS packet in a multicast ethernet 293 frame, it MUST set the Destination MAC Address to the value 294 01-00-5e-8a-bc-de, where abcde MUST, by default, be the twenty-bit 295 (five-nibble) value of the second MPLS label on the packet's label 296 stack. By "the second label", we mean the label that is in the label 297 stack entry that immediately follows the topmost label stack entry. 298 The LSR MAY, if configured to do so, allow a a label other than the 299 second to be used for this purpose. However, if the MPLS packet has 300 only one label, the value of that label will be used instead of the 301 value of the (non-existent) second label. 303 It is expected that the LSR will follow the procedures of [UPSTREAM], 304 pushing on two labels, with the topmost label being a "context label" 305 that is the same for all MPLS packets being transmitted by the LSR 306 onto the ethernet, but with the second label being different for 307 different LSPs. Thus if the MAC DA value is a function of the second 308 label, more of the LSP-specific information about the packet appears 309 in the MAC DA field. However, the way in which that information is 310 used, if any, is outside the scope of this document. 312 9. IANA Considerations 314 IANA already owns the set of ethernet multicast addresses in the 315 range 01-00-5e-00-00-00 to 01-00-5e-ff-ff-ff. Addresses in the range 316 01-00-5e-00-00-00 to 01-00-5e-7f-ff-ff are reserved for use when an 317 ethernet multicast frame carries an IP multicast packet. IANA shall 318 reserve ethernet addresses in the range 01-00-5e-80-00-00 to 319 01-00-5e-8f-ff-ff for use when an ethernet multicast frame carries an 320 MPLS multicast packet. 322 10. Security Considerations 324 The security considerations of RFC 3032 and RFC 4023 apply. 326 Malicious changing of the codepoint may result in loss or misrouting 327 of packets. However, altering the codepoint without also altering the 328 label does not result in a predictable effect. 330 Malicious alteration of the MAC DA on an ethernet can result in 331 packets being received by a third party, rather than by the intended 332 recipient. 334 11. Normative References 336 [RFC2119] "Key words for use in RFCs to Indicate Requirement 337 Levels.", Bradner, March 1997 339 [RFC3031] "Multiprotocol Label Switching Architecture", Rosen, 340 Viswanathan, Callon, January 2001 342 [RFC3032] "MPLS Label Stack Encoding", Rosen, et. al., January 2001 344 [RFC4023] "Encapsulating MPLS in IP or GRE", Worster, Rekhter, Rosen, 345 March 2005 347 12. Informative References 349 [UPSTREAM] "MPLS Upstream Label Assignment and Context Specific Label 350 Space", Aggarwal, Rekhter, Rosen, draft-ietf-mpls-upstream- 351 label-02.txt, March 2007. 353 13. Authors' Addresses 355 Toerless Eckert 356 Cisco Systems, Inc. 357 170 Tasman Drive 358 San Jose, CA, 95134 359 Email: eckert@cisco.com 361 Eric C. Rosen 362 Cisco Systems, Inc. 363 1414 Massachusetts Avenue 364 Boxborough, MA 01719 365 Email: erosen@cisco.com 367 Rahul Aggarwal 368 Juniper Networks 369 1194 North Mathilda Ave. 370 Sunnyvale, CA 94089 371 Email: rahul@juniper.net 373 Yakov Rekhter 374 Juniper Networks 375 1194 North Mathilda Ave. 376 Sunnyvale, CA 94089 377 Email: yakov@juniper.net 379 14. Full Copyright Statement 381 Copyright (C) The IETF Trust (2007). 383 This document is subject to the rights, licenses and restrictions 384 contained in BCP 78, and except as set forth therein, the authors 385 retain all their rights. 387 This document and the information contained herein are provided on an 388 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 389 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 390 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 391 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 392 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 393 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 395 15. Intellectual Property 397 The IETF takes no position regarding the validity or scope of any 398 Intellectual Property Rights or other rights that might be claimed to 399 pertain to the implementation or use of the technology described in 400 this document or the extent to which any license under such rights 401 might or might not be available; nor does it represent that it has 402 made any independent effort to identify any such rights. Information 403 on the procedures with respect to rights in RFC documents can be 404 found in BCP 78 and BCP 79. 406 Copies of IPR disclosures made to the IETF Secretariat and any 407 assurances of licenses to be made available, or the result of an 408 attempt made to obtain a general license or permission for the use of 409 such proprietary rights by implementers or users of this 410 specification can be obtained from the IETF on-line IPR repository at 411 http://www.ietf.org/ipr. 413 The IETF invites any interested party to bring to its attention any 414 copyrights, patents or patent applications, or other proprietary 415 rights that may cover technology that may be required to implement 416 this standard. Please address the information to the IETF at ietf- 417 ipr@ietf.org.