idnits 2.17.1 draft-ietf-mpls-multicast-encaps-01.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 on line 357. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 375. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 381. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 152: '... Unicast labels MUST be downstream-as...' RFC 2119 keyword, line 154: '...ecified below, multicast labels MAY be...' RFC 2119 keyword, line 156: '... OPTIONAL feature. Upstream-assigne...' RFC 2119 keyword, line 168: '... encapsulation) MUST be a downstream-...' RFC 2119 keyword, line 177: '...int data link or tunnel MUST be of the...' (6 more instances...) -- 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 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 (September 2006) is 6425 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) == Unused Reference: 'RFC3031' is defined on line 307, but no explicit reference was found in the text == Unused Reference: 'RFC3032' is defined on line 310, but no explicit reference was found in the text == Unused Reference: 'RFC4023' is defined on line 312, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 5 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: March 2007 Cisco Systems, Inc. 5 Updates RFCs 3032 and 4023 6 Rahul Aggarwal 7 Yakov Rekhter 8 Juniper Networks, Inc. 10 September 2006 12 MPLS Multicast Encapsulations 14 draft-ietf-mpls-multicast-encaps-01.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 44 RFC3032 by redefining the meaning of these two codepoints. The 45 former "multicast codepoint" is now to be used only on multiaccess 46 media, and it is to mean "the top label of the following label stack 47 is an upstream-assigned label". The former "unicast codepoint" is to 48 be 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 RFC3032 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 Introduction ......................................... 2 61 2 Upstream-Assigned vs. Downstream-Assigned ............ 3 62 3 Ethernet Codepoints .................................. 5 63 4 PPP Protocol Field ................................... 6 64 5 GRE Protocol Type .................................... 6 65 6 IP Protocol Number ................................... 6 66 7 Ethernet MAC DA for Multicast MPLS ................... 7 67 8 IANA Considerations .................................. 7 68 9 Security Considerations .............................. 7 69 10 Normative References ................................. 7 70 11 Informative References ............................... 8 71 12 Authors' Addresses ................................... 8 72 13 Full Copyright Statement ............................. 8 73 14 Intellectual Property ................................ 9 75 1. Introduction 77 RFC 3031 defines the "Next Hop Label Forwarding Entry" (NHLFE). The 78 NHLFE for a particular label maps the label into a next hop (among 79 other things). When an MPLS packet is received, its top label is 80 mapped to an NHLFE, and the packet is sent to the next hop specified 81 by the NHLFE. 83 We define a particular MPLS label to be a "multicast label" in a 84 particular context if the NHLFE to which it is mapped in that context 85 specifies a set of next hops, with the semantics that the packet is 86 to be replicated, and a copy of the packet sent to each of the 87 specified next hops. Note that this definition accommodates the case 88 where the set of next hops contains a single member. What makes a 89 label a multicast label in a particular context is the semantics 90 attached to the set, i.e., the intention to replicate the packet and 91 transmit to all members of the set if the set has more than one 92 member. 94 RFC 3032 established two data link layer codepoints for MPLS: one to 95 indicate that the data link layer frame is carrying an MPLS unicast 96 packet, and the other to indicate that the data link layer frame is 97 carrying an MPLS multicast packet. The term "multicast packet" is 98 not precisely defined in RFC 3032, though one may presume that the 99 "multicast" codepoint is intended to identify the packet's top label 100 as a multicast label. However, the multicast codepoint has never 101 been deployed, and further development of the procedures for MPLS 102 multicast have shown that, while there is a need for two codepoints, 103 the use of the two codepoints is not properly captured by RFC3032. 105 In particular, there is no need for the codepoint to indicate whether 106 the top MPLS label is a multicast label. When the receiver of an 107 MPLS packet looks up the top label, the NHLFE will specify whether 108 the label is a multicast label or not. 110 This document updates RFC 3032 and RFC 4023 by re-specifying the use 111 of the codepoints. 113 While RFC 3032 allows an MPLS packet to be carried in an ethernet 114 multicast frame, it fails to specify how the Medium Access Layer 115 Destination Address (MAC DA) field is to be set in that case. This 116 document provides that specification. 118 2. Upstream-Assigned vs. Downstream-Assigned 120 According to RFC 3031, if two MPLS Label Switching Routers (LSRs) are 121 adjacent in a label switched path (LSP), with respect to that LSP, 122 one of them may be called the "upstream" LSR and the other the 123 "downstream" LSR. Call these Ru and Rd respectively. Before Ru can 124 send an MPLS packet to Rd with label L at the top of the label stack, 125 Ru and Rd must agree on the Forwarding Equivalence Class (FEC) which 126 is bound to L. A particular binding of L to FEC F is called a 127 "downstream-assigned" binding if the binding is first made by Rd and 128 then advertised to Ru. If the binding is first made by Ru and then 129 advertised to Rd, it is called an "upstream-assigned" binding. 131 If Ru and RD are LSP adjacencies, then they transmit a MPLS packet to 132 each other through one of the following mechanisms: 134 1. by putting the MPLS packet in a data link layer frame and 135 transmitting the frame 137 2. by transmitting the MPLS packet through an MPLS tunnel, i.e., 138 by pushing an additional label (or labels) onto the label 139 stack, and then invoking mechanism 1, 141 3. by transmitting the MPLS packet through an IP-based tunnel 142 (e.g., via RFC 4023), and then invoking mechanisms 1 and/or 2. 144 In short, an MPLS packet is transmitted either through a data link or 145 through an MPLS tunnel or through an IP tunnel. In any of those 146 cases, when the packet emerges through the tunnel, the downstream LSR 147 must know whether the label that now appears at the top of the label 148 stack has an upstream-assigned label binding or a downstream-assigned 149 label binding. For convenience, we will speak of a label with an 150 upstream-assigned label binding as an "upstream-assigned label". 152 Unicast labels MUST be downstream-assigned. 154 Under certain conditions, specified below, multicast labels MAY be 155 upstream-assigned. The ability to use upstream-assigned labels is an 156 OPTIONAL feature. Upstream-assigned labels MUST NOT be used unless 157 it is known that the downstream LSR supports them. How this is known 158 is outside the scope of this document. 160 We discuss three different types of data link or tunnel: 162 - Point-to-Point. A point-to-point data link or tunnel associates 163 two systems, such that transmissions on that link or tunnel made 164 by the one are received by the other, and only by the other. 166 When an MPLS packet is transmitted on a point-to-point data link 167 or tunnel, its top label (before applying the data link or tunnel 168 encapsulation) MUST be a downstream-assigned label. 170 - Point-to-Multipoint. A point-to-multipoint link or tunnel 171 associates n systems, such that only one of them can transmit 172 onto the link or tunnel, and the transmissions may be received by 173 the other n-1 systems. 175 The top labels (before applying the data link or tunnel 176 encapsulation) of all MPLS packets which are transmitted on a 177 particular point-to-multipoint data link or tunnel MUST be of the 178 same type; either all upstream-assigned or all downstream- 179 assigned. This means that all the receivers on the MPLS or IP 180 tunnel must know a priori whether upstream-assigned or 181 downstream-assigned labels are being used in the tunnel. How 182 this is known is outside the scope of this document. 184 - Multipoint-to-Multipoint. A multipoint-to-multipoint link or 185 tunnel associates n systems, such that any of them can transmit 186 on the link or tunnel, and the transmissions may be received by 187 the other n-1 systems. 189 If MPLS packets are transmitted on a particular multipoint-to- 190 multipoint link or tunnel, one of the following scenarios 191 applies: 193 1. It is known (by methods outside the scope of this document) 194 that the top label of every MPLS packet on the link or 195 tunnel is downstream-assigned 197 2. It is known (by methods outside the scope of this document) 198 that the top label of every MPLS packet on the link or 199 tunnel is upstream-assigned 201 3. Some MPLS packets on the link may have upstream-assigned 202 top labels while some may have downstream-assigned top 203 labels 205 If (and only if) the third scenario applies, the data link or 206 tunnel encapsulation MUST provide a codepoint which specifies 207 whether the top label of the encapsulated MPLS packet is 208 upstream-assigned or downstream-assigned. If a particular type 209 of data link or tunnel does not provide such a codepoint, then 210 the third scenario MUST NOT be used. 212 The remainder of this document specifies procedures for setting the 213 data link layer codepoints and address fields. 215 3. Ethernet Codepoints 217 Ethernet is an example of a multipoint-to-multipoint data link. 219 Ethertype 0x8847 is used whenever a unicast ethernet frame carries an 220 MPLS packet. 222 Ethertype 0x8847 is also used whenever a multicast ethernet frame 223 carries an MPLS packet, EXCEPT for the case where the top label of 224 the MPLS packet has been upstream-assigned. 226 Ethertype 0x8848, formerly known as the "MPLS multicast codepoint", 227 is to be used only when an MPLS packet whose top label is upstream- 228 assigned is carried in a multicast ethernet frame. 230 4. PPP Protocol Field 232 PPP is an example of a point-to-point data link. When a PPP frame is 233 carrying an MPLS packet, the PPP Protocol field is always set to 234 0x0281. 236 5. GRE Protocol Type 238 RFC 4023 is modified as described below. 240 If the IP destination address of the GRE encapsulation is a unicast 241 IP address, then the ethertype value 0x8847 MUST be used in all cases 242 for the MPLS-in-GRE encapsulation. 244 If the IP destination address of the GRE encapsulation is a multicast 245 IP address, then: 247 - if both upstream-assigned and downstream-assigned labels may 248 appear as the top label of the encapsulated MPLS packets, then 249 the ethertype value 0x8847 MUST be used when the aforesaid label 250 is downstream-assigned, and the ethertype value 0x8848 MUST be 251 used when the aforesaid label is upstream-assigned. 253 - if all the encapsulated MPLS packets have an upstream-assigned 254 top label, or if all the encapsulated MPLS packets have a 255 downstream-assigned top label, then the ethertype value 0x8847 256 MUST be used. 258 Which of these two situations applies is determined by means outside 259 the scope of this specification. 261 6. IP Protocol Number 263 RFC 4023 is modified as follows: the IPv4 Protocol Number field or 264 the IPv6 Next Header field is always set to 137, whether or not the 265 encapsulated MPLS packet is an MPLS multicast packet. 267 If the IP destination address of the IP encapsulation is an IP 268 multicast address, the IP tunnel may be considered to be a point-to- 269 multipoint tunnel or a multipoint-to-multipoint tunnel. In either 270 case, either all encapsulated MPLS packets in the particular tunnel 271 have a downstream-assigned label at the top of the stack, or all 272 encapsulated MPLS packets in that tunnel have an upstream-assigned 273 label at the top of the stack. The means by which this is determined 274 for a particular tunnel is outside the scope of this specification. 276 7. Ethernet MAC DA for Multicast MPLS 278 When a multicast MPLS packet is carried in a multicast ethernet 279 frame, the Destination MAC Address shall be set to the value 01-00- 280 5e-8a-bc-de, where abcde is the twenty-bit (5-nibble) value of the 281 topmost MPLS label of the MPLS packet. 283 8. IANA Considerations 285 IANA already owns the set of ethernet multicast addresses in the 286 range 01-00-5e-00-00-00 to 01-00-5e-ff-ff-ff. Addresses in the range 287 01-00-5e-00-00-00 to 01-00-5e-7f-ff-ff are reserved for use when an 288 ethernet multicast frame carries an IP multicast packet. IANA shall 289 reserve ethernet addresses in the range 01-00-5e-80-00-00 to 01-00- 290 5e-8f-ff-ff for use when an ethernet multicast frame carries an MPLS 291 multicast packet. 293 9. Security Considerations 295 The security considerations of RFC 3032 and RFC 4023 apply. 297 Malicious changing of the codepoint may result in loss or misrouting 298 of packets. However, altering the codepoint without also altering the 299 label does not result in a predictable effect. 301 Malicious alteration of the MAC DA on an ethernet can result in 302 packets being received by a third party, rather than by the intended 303 recipient. 305 10. Normative References 307 [RFC3031] "Multiprotocol Label Switching Architecture", Rosen, 308 Viswanathan, Callon, January 2001 310 [RFC3032] "MPLS Label Stack Encoding", Rosen, et. al., January 2001 312 [RFC4023] "Encapsulating MPLS in IP or GRE", Worster, Rekhter, Rosen, 313 March 2005 315 11. Informative References 317 12. Authors' Addresses 319 Toerless Eckert 320 Cisco Systems, Inc. 321 170 Tasman Drive 322 San Jose, CA, 95134 323 Email: eckert@cisco.com 325 Eric C. Rosen 326 Cisco Systems, Inc. 327 1414 Massachusetts Avenue 328 Boxborough, MA 01719 329 Email: erosen@cisco.com 331 Rahul Aggarwal 332 Juniper Networks 333 1194 North Mathilda Ave. 334 Sunnyvale, CA 94089 335 Email: rahul@juniper.net 337 Yakov Rekhter 338 Juniper Networks 339 1194 North Mathilda Ave. 340 Sunnyvale, CA 94089 341 Email: yakov@juniper.net 343 13. Full Copyright Statement 345 Copyright (C) The Internet Society (2006). 347 This document is subject to the rights, licenses and restrictions 348 contained in BCP 78, and except as set forth therein, the authors 349 retain all their rights. 351 This document and the information contained herein are provided on an 352 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 353 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 354 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 355 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 356 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 357 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 359 14. Intellectual Property 361 The IETF takes no position regarding the validity or scope of any 362 Intellectual Property Rights or other rights that might be claimed to 363 pertain to the implementation or use of the technology described in 364 this document or the extent to which any license under such rights 365 might or might not be available; nor does it represent that it has 366 made any independent effort to identify any such rights. Information 367 on the procedures with respect to rights in RFC documents can be 368 found in BCP 78 and BCP 79. 370 Copies of IPR disclosures made to the IETF Secretariat and any 371 assurances of licenses to be made available, or the result of an 372 attempt made to obtain a general license or permission for the use of 373 such proprietary rights by implementers or users of this 374 specification can be obtained from the IETF on-line IPR repository at 375 http://www.ietf.org/ipr. 377 The IETF invites any interested party to bring to its attention any 378 copyrights, patents or patent applications, or other proprietary 379 rights that may cover technology that may be required to implement 380 this standard. Please address the information to the IETF at ietf- 381 ipr@ietf.org.