idnits 2.17.00 (12 Aug 2021) /tmp/idnits53483/draft-ietf-mpls-multicast-encaps-10.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 445. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 456. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 463. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 469. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- 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 (Using the creation date from RFC3032, updated by this document, for RFC5378 checks: 1997-11-20) -- 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 2, 2008) is 5094 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: draft-ietf-mpls-upstream-label has been published as RFC 5331 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 8 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 Intended Status: Standards Track Cisco Systems, Inc. 5 Expires: December 2, 2008 6 Updates: RFCs 3032 and 4023 Rahul Aggarwal 7 Yakov Rekhter 8 Juniper Networks, Inc. 10 June 2, 2008 12 MPLS Multicast Encapsulations 14 draft-ietf-mpls-multicast-encaps-10.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, used to 41 distinguish whether the data link layer frame is carrying an MPLS 42 unicast or an MPLS multicast packet. However, this usage was never 43 deployed. This specification updates RFC 3032 by redefining the 44 meaning of these two codepoints. Both codepoints can now be used to 45 carry multicast packets. The second codepoint (formerly the 46 "multicast codepoint") is now to be used only on multiaccess media, 47 and it is to mean "the top label of the following label stack is an 48 upstream-assigned label". 50 RFC 3032 does not specify the destination address to be placed in the 51 "MAC DA" field of an ethernet frame which carries an MPLS multicast 52 packet. This document provides that specification. 54 This document updates RFC 3032 and RFC 4023. 56 Contents 58 1 Specification of Requirements ........................... 2 59 2 Introduction ............................................ 3 60 3 Upstream-Assigned vs. Downstream-Assigned ............... 4 61 4 Ethernet Codepoints ..................................... 6 62 5 PPP Protocol Field ...................................... 7 63 6 GRE Protocol Type ....................................... 7 64 7 IP Protocol Number ...................................... 7 65 8 Ethernet MAC DA for Multicast MPLS ...................... 8 66 9 IANA Considerations ..................................... 9 67 10 Security Considerations ................................. 9 68 11 Normative References .................................... 9 69 12 Authors' Addresses ...................................... 10 70 13 Full Copyright Statement ................................ 10 71 14 Intellectual Property ................................... 11 73 1. Specification of Requirements 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 2. Introduction 81 RFC 3031 [RFC3031] defines the "Next Hop Label Forwarding Entry" 82 (NHLFE). The NHLFE for a particular label maps the label into a next 83 hop (among other things). When an MPLS packet is received, its top 84 label is mapped to an NHLFE, and the packet is sent to the next hop 85 specified by the NHLFE. 87 We define a particular MPLS label to be a "multicast label" in a 88 particular context if the NHLFE to which it is mapped in that context 89 specifies a set of next hops, with the semantics that the packet is 90 to be replicated, and a copy of the packet sent to each of the 91 specified next hops. Note that this definition accommodates the case 92 where the set of next hops contains a single member. What makes a 93 label a multicast label in a particular context is the semantics 94 attached to the set, i.e., the intention to replicate the packet and 95 transmit to all members of the set if the set has more than one 96 member. 98 RFC 3032 [RFC3032] established two data link layer codepoints for 99 MPLS: one to indicate that the data link layer frame is carrying an 100 MPLS unicast packet, and the other to indicate that the data link 101 layer frame is carrying an MPLS multicast packet. The term 102 "multicast packet" is not precisely defined in RFC 3032, though one 103 may presume that the "multicast" codepoint is intended to identify 104 the packet's top label as a multicast label. However, the multicast 105 codepoint has never been deployed, and further development of the 106 procedures for MPLS multicast have shown that, while there is a need 107 for two codepoints, the use of the two codepoints is not properly 108 captured by RFC 3032. 110 In particular, there is no need for the codepoint to indicate whether 111 the top MPLS label is a multicast label. When the receiver of an 112 MPLS packet looks up the top label, the NHLFE will specify whether 113 the label is a multicast label or not. 115 This document updates RFC 3032 and RFC 4023 by re-specifying the use 116 of the codepoints. The old use of the "multicast codepoint", as 117 specified in those two RFCs, is hereby deprecated. 119 Note that an implementation that does MPLS multicast according to RFC 120 3032 and/or 4023 will be unable to interoperate with implementations 121 that do MPLS multicast according to this document. There may be some 122 deployed platforms which support the deprecated use of the 123 codepoints, but those platforms do not support the control plane 124 mechanisms to support MPLS multicast. The absence of the control 125 plane will prevent a system that implements the deprecated use of 126 codepoints from attempting to interoperate with a system that uses 127 the codepoints as specified herein. (If an MPLS multicast control 128 plane were to be implemented on a platform that only supports the 129 deprecated codepoint, interoperability problems such as black holes 130 and/or misrouting would arise. This does not seem like a potential 131 problem in practice.) 133 While RFC 3032 allows an MPLS packet to be carried in an ethernet 134 multicast frame, it fails to specify how the Medium Access Layer 135 Destination Address (MAC DA) field is to be set in that case. This 136 document provides that specification. 138 3. Upstream-Assigned vs. Downstream-Assigned 140 Suppose a labeled packet P is sent from LSR R1 to LSR R2, where R1 141 puts label L on the packet's label stack, and R2 has to look up label 142 L in order to determine the corresponding Forwarding Equivalence 143 Class (FEC), call it F. 145 If the binding between L and F was made by R2 and advertised to R1, 146 then the label binding is known as "downstream-assigned". RFC 3031 147 only discusses downstream-assigned label bindings. 149 If the binding between L and F was made by R1 and advertised to R2, 150 then the label binding is known as "upstream-assigned". 152 If the binding between L and F was made by a third party, say R3, and 153 then advertised to both R1 and R2, we also refer to the label binding 154 as "upstream-assigned". 156 Upstream-assigned labels are not required to come from the same 157 "label space" as downstream-assigned labels. See [RFC3031], section 158 3.14, and especially [UPSTREAM] for a discussion of the notion of 159 "label space". The procedures for properly interpreting an upstream- 160 assigned label are given in [UPSTREAM]. 162 If Ru and Rd are LSP adjacencies, then they transmit a MPLS packet to 163 each other through one of the following mechanisms: 165 1. by putting the MPLS packet in a data link layer frame and 166 transmitting the frame, 168 2. by transmitting the MPLS packet through an MPLS tunnel, i.e., 169 by pushing an additional label (or labels) onto the label 170 stack, and then invoking mechanism 1, 172 3. by transmitting the MPLS packet through an IP-based tunnel 173 (e.g., via RFC 4023 [RFC4023]), and then invoking mechanisms 1 174 and/or 2. 176 In short, an MPLS packet is transmitted either through a data link or 177 through an MPLS tunnel or through an IP tunnel. In any of those 178 cases, when the packet emerges through the tunnel, the downstream LSR 179 must know whether the label that now appears at the top of the label 180 stack has an upstream-assigned label binding or a downstream-assigned 181 label binding. For convenience, we will speak of a label with an 182 upstream-assigned label binding as an "upstream-assigned label". 184 Under certain conditions, specified below, multicast labels MAY be 185 upstream-assigned. The ability to use upstream-assigned labels is an 186 OPTIONAL feature. Upstream-assigned labels MUST NOT be used unless 187 it is known that the downstream LSR supports them. How this is known 188 is outside the scope of this document. 190 This document makes no changes to the procedures regarding unicast 191 labels. 193 We discuss three different types of data link or tunnel: 195 - Point-to-Point. A point-to-point data link or tunnel associates 196 two systems, such that transmissions on that link or tunnel made 197 by the one are received by the other, and only by the other. 199 For a given direction of a given point-to-point data link or 200 tunnel, the following MUST be the case: either every MPLS packet 201 will carry an upstream-assigned label, or else every MPLS packet 202 will carry a downstream-assigned label. The procedures for 203 determining whether upstream-assigned or downstream-assigned 204 labels are being used are outside the scope of this 205 specification. However, in the absence of any other information, 206 the use of downstream-assigned labels MUST be presumed by 207 default. 209 - Point-to-Multipoint. A point-to-multipoint link or tunnel 210 associates n systems, such that only one of them can transmit 211 onto the link or tunnel, and the transmissions may be received by 212 the other n-1 systems. 214 The top labels (before applying the data link or tunnel 215 encapsulation) of all MPLS packets which are transmitted on a 216 particular point-to-multipoint data link or tunnel MUST be of the 217 same type; either all upstream-assigned or all downstream- 218 assigned. This means that all the receivers on the MPLS or IP 219 tunnel must know a priori whether upstream-assigned or 220 downstream-assigned labels are being used in the tunnel. How 221 this is known is outside the scope of this document. 223 - Multipoint-to-Multipoint. A multipoint-to-multipoint link or 224 tunnel associates n systems, such that any of them can transmit 225 on the link or tunnel, and the transmissions may be received by 226 the other n-1 systems. 228 If MPLS packets are transmitted on a particular multipoint-to- 229 multipoint link or tunnel, one of the following scenarios 230 applies: 232 1. It is known (by methods outside the scope of this document) 233 that the top label of every MPLS packet on the link or 234 tunnel is downstream-assigned. 236 2. It is known (by methods outside the scope of this document) 237 that the top label of every MPLS packet on the link or 238 tunnel is upstream-assigned. 240 3. Some MPLS packets on the link may have upstream-assigned 241 top labels while some may have downstream-assigned top 242 labels. 244 If (and only if) the third scenario applies, the data link or 245 tunnel encapsulation MUST provide a codepoint which specifies 246 whether the top label of the encapsulated MPLS packet is 247 upstream-assigned or downstream-assigned. If a particular type 248 of data link or tunnel does not provide such a codepoint, then 249 the third scenario MUST NOT be used. 251 The remainder of this document specifies procedures for setting the 252 data link layer codepoints and address fields. 254 4. Ethernet Codepoints 256 Ethernet is an example of a multipoint-to-multipoint data link. 258 Ethertype 0x8847 is used whenever a unicast ethernet frame carries an 259 MPLS packet. 261 Ethertype 0x8847 is also used whenever a multicast ethernet frame 262 carries an MPLS packet, EXCEPT for the case where the top label of 263 the MPLS packet has been upstream-assigned. 265 Ethertype 0x8848, formerly known as the "MPLS multicast codepoint", 266 is to be used only when an MPLS packet whose top label is upstream- 267 assigned is carried in a multicast ethernet frame. 269 5. PPP Protocol Field 271 PPP is an example of a point-to-point data link. When a PPP frame is 272 carrying an MPLS packet, the PPP Protocol field is always set to 273 0x0281. 275 6. GRE Protocol Type 277 RFC 4023 is modified as described below. 279 If the IP destination address of the GRE encapsulation is a unicast 280 IP address, then the ethertype value 0x8847 MUST be used in all cases 281 for the MPLS-in-GRE encapsulation. 283 If the IP destination address of the GRE encapsulation is a multicast 284 IP address, then: 286 - the ethertype value 0x8847 MUST be used when the top label of the 287 encapsulated MPLS packet is downstream-assigned, 289 - the ethertype value 0x8848 MUST be used when the top label of the 290 encapsulated MPLS packet is upstream-assigned. 292 Through procedures which are outside the scope of this specification, 293 it may be known that if the destination address of a GRE packet is a 294 multicast IP address, then the top label of the GRE payload is 295 upstream-assigned. In such a case, the occurrence of the 8847 296 codepoint in a GRE packet with a multicast destination IP address 297 MUST be considered an error, and the packet MUST be discarded. 299 7. IP Protocol Number 301 RFC 4023 is modified as follows: the IPv4 Protocol Number field or 302 the IPv6 Next Header field is always set to 137, whether or not the 303 encapsulated MPLS packet is an MPLS multicast packet. 305 If the IP destination address of the IP encapsulation is an IP 306 multicast address, the IP tunnel may be considered to be a point-to- 307 multipoint tunnel or a multipoint-to-multipoint tunnel. In either 308 case, either all encapsulated MPLS packets in the particular tunnel 309 have a downstream-assigned label at the top of the stack, or all 310 encapsulated MPLS packets in that tunnel have an upstream-assigned 311 label at the top of the stack. The means by which this is determined 312 for a particular tunnel is outside the scope of this specification. 314 8. Ethernet MAC DA for Multicast MPLS 316 When an LSR transmits a multicast MPLS packet in a multicast ethernet 317 frame, it MUST set the Destination MAC Address to the value 318 01-00-5e-8v-wx-yz, where vwxyz is a 20-bit (five-nibble) value set as 319 follows: 321 1. vwxyz MAY be set to 0 323 2. vwxyz MAY be set to the value of one of the MPLS labels on the 324 packet's label stack. 326 Which of these procedures is the default procedure in any particular 327 LSR is implementation-dependent. However, LSRs using the two 328 different procedures MUST interoperate. That is, an LSR MUST NOT 329 filter packets for which vwxyz has been set to zero, and it MUST NOT 330 indiscriminately filter all packets for which vwxyz has not been set 331 to zero. 333 If an LSR follows the procedure of setting vwxyz to the value of one 334 of the MPLS labels on the packet's label stack, and if that label 335 stack contains two or more labels, then by default, vwxyz MUST be set 336 to the value of the second MPLS label on the packet's label stack. 337 By "the second label", we mean the label that is in the label stack 338 entry that immediately follows the topmost label stack entry. The 339 LSR MAY, if configured to do so, allow a a label other than the 340 second to be used for this purpose. If the MPLS packet has only one 341 label, the value of that label will be used instead of the value of 342 the (non-existent) second label. 344 It is expected that the LSR will follow the procedures of [UPSTREAM], 345 pushing on two labels, with the topmost label being a "context label" 346 that is the same for all MPLS packets being transmitted by the LSR 347 onto the ethernet, but with the second label being different for 348 different LSPs. Thus if the MAC DA value is a function of the second 349 label, more of the LSP-specific information about the packet appears 350 in the MAC DA field. This can be used to filter multicast packets 351 with "unexpected" non-zero values of vwxyz. Further discussion of 352 such filtering or its uses is outside the scope of this document. 354 The use of ethernet and/or IP broadcast addresses (as distinguished 355 from multicast addresses) does not fall within the scope of this 356 specification. 358 9. IANA Considerations 360 IANA already owns the set of ethernet multicast addresses in the 361 range 01-00-5e-00-00-00 to 01-00-5e-ff-ff-ff. Addresses in the range 362 01-00-5e-00-00-00 to 01-00-5e-7f-ff-ff are already reserved for use 363 when an ethernet multicast frame carries an IP multicast packet. 365 When this document is accepted, IANA shall reserve ethernet addresses 366 in the range 01-00-5e-80-00-00 to 01-00-5e-8f-ff-ff for use when an 367 ethernet multicast frame carries an MPLS multicast packet. Addresses 368 in this range are to be valid when used with ethertype 8847 or 8848. 370 As this document modifies the usage of ethertypes 8847 and 8848, IANA 371 shall change the description of these ethertypes as follows. 372 Ethertype 8847 shall be defined as "MPLS", as defined in RFC 3032 and 373 in this document. Ethertype 8848 shall be defined as "MPLS with 374 upstream-assigned label", as defined in this document. 376 10. Security Considerations 378 The security considerations of RFC 3032 and RFC 4023 apply. 380 Malicious changing of the codepoint may result in loss or misrouting 381 of packets. However, altering the codepoint without also altering the 382 label does not result in a predictable effect. 384 Malicious alteration of the MAC DA on an ethernet can result in 385 packets being received by a third party, rather than by the intended 386 recipient. 388 11. Normative References 390 [RFC2119] "Key words for use in RFCs to Indicate Requirement 391 Levels.", Bradner, March 1997 393 [RFC3031] "Multiprotocol Label Switching Architecture", Rosen, 394 Viswanathan, Callon, January 2001 396 [RFC3032] "MPLS Label Stack Encoding", Rosen, et. al., January 2001 398 [RFC4023] "Encapsulating MPLS in IP or GRE", Worster, Rekhter, Rosen, 399 March 2005 401 [UPSTREAM] "MPLS Upstream Label Assignment and Context Specific Label 402 Space", Aggarwal, Rekhter, Rosen, draft-ietf-mpls-upstream- 403 label-05.txt, March 2008. 405 12. Authors' Addresses 407 Toerless Eckert 408 Cisco Systems, Inc. 409 170 Tasman Drive 410 San Jose, CA, 95134 411 Email: eckert@cisco.com 413 Eric C. Rosen 414 Cisco Systems, Inc. 415 1414 Massachusetts Avenue 416 Boxborough, MA 01719 417 Email: erosen@cisco.com 419 Rahul Aggarwal 420 Juniper Networks 421 1194 North Mathilda Ave. 422 Sunnyvale, CA 94089 423 Email: rahul@juniper.net 425 Yakov Rekhter 426 Juniper Networks 427 1194 North Mathilda Ave. 428 Sunnyvale, CA 94089 429 Email: yakov@juniper.net 431 13. Full Copyright Statement 433 Copyright (C) The IETF Trust (2008). 435 This document is subject to the rights, licenses and restrictions 436 contained in BCP 78, and except as set forth therein, the authors 437 retain all their rights. 439 This document and the information contained herein are provided on an 440 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 441 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 442 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 443 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 444 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 445 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 447 14. Intellectual Property 449 The IETF takes no position regarding the validity or scope of any 450 Intellectual Property Rights or other rights that might be claimed to 451 pertain to the implementation or use of the technology described in 452 this document or the extent to which any license under such rights 453 might or might not be available; nor does it represent that it has 454 made any independent effort to identify any such rights. Information 455 on the procedures with respect to rights in RFC documents can be 456 found in BCP 78 and BCP 79. 458 Copies of IPR disclosures made to the IETF Secretariat and any 459 assurances of licenses to be made available, or the result of an 460 attempt made to obtain a general license or permission for the use of 461 such proprietary rights by implementers or users of this 462 specification can be obtained from the IETF on-line IPR repository at 463 http://www.ietf.org/ipr. 465 The IETF invites any interested party to bring to its attention any 466 copyrights, patents or patent applications, or other proprietary 467 rights that may cover technology that may be required to implement 468 this standard. Please address the information to the IETF at 469 ietf-ipr@ietf.org.