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]