Network Working Group T. Morin Internet-Draft France Telecom - Orange Labs Intended status: Experimental W. Henderickx Expires: May 7, 2009 P. Muley S. Sinha Alcatel-Lucent November 3, 2008 Ethernet MAC Destination Address for Multicast MPLS draft-morin-mpls-mcast-ethernet-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 7, 2009. Abstract This document identifies a set of required clarifications to make it explicit what Ethernet MAC destination address is to be used for multicast MPLS packets, and intends to provide an update to RFC5332. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Morin, et al. Expires May 7, 2009 [Page 1] Internet-Draft Multicast MPLS Ethernet MAC DA November 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Multicast MPLS packet . . . . . . . . . . . . . . . . . . . . . 3 3. Choice of Ethernet MAC destination address . . . . . . . . . . 4 4. MPLS Label used to build a multicast Ethernet MAC destination address . . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Intellectual Property and Copyright Statements . . . . . . . . . . 7 Morin, et al. Expires May 7, 2009 [Page 2] Internet-Draft Multicast MPLS Ethernet MAC DA November 2008 1. Introduction [RFC5332] already defines how a multicast Ethernet MAC Destination Address (DA) is formed when used for a multicast MPLS packets, but doesn't say when a multicast Ethernet MAC is to be used as destination address. Moreover, this specification defines only implicitly what is a "multicast MPLS packet". It seems useful, to ensure proper interoperability when multicast MPLS is used on Ethernet interfaces, to provide additional clarifications to [RFC5332], on the following points: o when a multicast router should use a multicast Ethernet MAC DA for a packet that it sends, and respectively when it should use a unicast Ethernet MAC DA o when a router should accept unicast Ethernet MAC DA and multicast Ethernet MAC DA o when a packet is considered a "multicast MPLS packet" o the conditions in which the label used to build a multicast Ethernet MAC Destination Address is not the second label of the frame The intent is to propose this document as an update of RFC5332. 2. Multicast MPLS packet [RFC5332] defines a multicast label as being a label "[mapped to an NHLFE which] specifies a set of next hops, with the semantics that the packet is to be replicated and a copy of the packet sent to each of the specified next hops". We can define an Multicast MPLS packet as an MPLS packet for which the topmost label is a multicast label (or if the second label is a multicast label if the topmost label is a Context Label[RFC5331]). Note well that an MPLS packet that result from the encapsulation of a multicast MPLS packet is not necessarily a "multicast MPLS packet". For instance, when an MPLS multicast packet of a P2MP LSP signalled with [RFC4875] or [I-D.ietf-mpls-ldp-p2mp] is encapsulated into a P2P backup LSP, the resulting packet is *not* a multicast MPLS packet, since the topmost label in the resulting packet is not a multicast label. Morin, et al. Expires May 7, 2009 [Page 3] Internet-Draft Multicast MPLS Ethernet MAC DA November 2008 3. Choice of Ethernet MAC destination address This section is applicable when the data link layer is Ethernet. A router MUST use a multicast Ethernet MAC destination address (formed in conformance to [RFC5332] ) to send an Ethernet frame containing a multicast MPLS packet for which the topmost label is a Context Label [RFC5331] and the second label is Upstream assigned. A router MUST use a unicast Ethernet MAC DA as the Ethernet MAC destination address of a multicast MPLS packet for which the topmost label is downstream assigned, to ensure that a multicast MPLS packet will be processed only by the LSR that has assigned the label. A router MUST be able to process a multicast MPLS packet for which an Upstream Assigned Label is used along with a context label, whether it carries a unicast or multicast Ethernet MAC destination address. Though unicast MPLS is out of the scope of this document, it is noted that the use of unicast Ethernet MAC destination addresses is expected for unicast MPLS packets (i.e. non-multicast) MPLS packet. As explained inSection 2, this would be the case when an multicast MPLS packet is encapsulated into a P2P LSP. 4. MPLS Label used to build a multicast Ethernet MAC destination address [RFC5332] says that "When an LSR transmits a multicast MPLS packet in a multicast Ethernet frame, it MUST set the MAC Destination Address to the value 01-00-5e-8v-wx-yz, where [...] vwxyz MAY be set to 0 [or..] MAY be set to the value of one of the MPLS labels on the packet's label stack." There does not seem to be any use case where 'vwxyz' would be set to the value of an MPLS label of the stack which is not the topmost label or the second label. Thus, routers MUST use the second label of the MPLS stack to built the Ethernet MAC destination address when a Context Label is used as the topmost label and the second label is an Upstream Assigned label[RFC5331]. 5. IANA Considerations his document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. Morin, et al. Expires May 7, 2009 [Page 4] Internet-Draft Multicast MPLS Ethernet MAC DA November 2008 6. Security Considerations 7. Acknowledgements The authors want to thank Yakov Rekhter, Eric Rosen and Toerless Eckert for providing feedback on this document. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, August 2008. [RFC5332] Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008. 8.2. Informative References [I-D.ietf-mpls-ldp-p2mp] Minei, I., "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp-05 (work in progress), June 2008. [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007. Authors' Addresses Thomas Morin France Telecom - Orange Labs 2 avenue Pierre Marzin Lannion 22307 France Email: thomas.morin@orange-ftgroup.com Morin, et al. Expires May 7, 2009 [Page 5] Internet-Draft Multicast MPLS Ethernet MAC DA November 2008 Wim Henderickx Alcatel-Lucent Copernicuslaan 50 Antwerp 2018 Belgium Email: wim.henderickx@alcatel-lucent.com Praveen Muley Alcatel-Lucent 701 East Middlefield Rd Mountain View, CA 94043 U.S.A. Email: praveen.muley@alcatel-lucent.com Satyam Sinha Alcatel-Lucent 701 East Middlefield Rd Mountain View, CA 94043 U.S.A. Email: satyam.sinha@alcatel-lucent.com Morin, et al. Expires May 7, 2009 [Page 6] Internet-Draft Multicast MPLS Ethernet MAC DA November 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Morin, et al. Expires May 7, 2009 [Page 7]