Internet DRAFT - draft-rosen-mpls-multicast-encaps
draft-rosen-mpls-multicast-encaps
Network Working Group Toerless Eckert
Internet Draft Eric C. Rosen (editor)
Expiration Date: April 2006 Cisco Systems, Inc.
Updates RFCs 3032 and 4023
Rahul Aggarwal
Yakov Rekhter
Juniper Networks, Inc.
October 2005
MPLS Multicast Encapsulations
draft-rosen-mpls-multicast-encaps-01.txt
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.
Abstract
RFC 3032 established two data link layer codepoints for MPLS: one to
indicate that the data link layer frame is carrying an MPLS unicast
packet, and the other to indicate that the data link layer frame is
carrying an MPLS multicast packet. This specification updates
RFC3032 by redefining the meaning of these two codepoints. The
former "multicast codepoint" is now to be used only on multiaccess
media, and it is to mean "the top label of the following label stack
is an upstream-assigned label". The former "unicast codepoint" is to
Eckert, et al. [Page 1]
Internet Draft draft-rosen-mpls-multicast-encaps-01.txt October 2005
be used in all other cases. Whether the data link layer payload is a
unicast MPLS packet or a multicast MPLS packet is now to be
determined by looking up the top label, rather than by the codepoint.
RFC3032 does not specify the destination address to be placed in the
"MAC DA" field of an ethernet frame which carries an MPLS multicast
packet. This document provides that specification.
This document updates RFC 3032 and RFC 4023.
Contents
1 Introduction ......................................... 2
2 Upstream-Assigned vs. Downstream-Assigned ............ 3
3 Ethernet Codepoints .................................. 5
4 PPP Protocol Field ................................... 6
5 GRE Protocol Type .................................... 6
6 IP Protocol Number ................................... 6
7 Ethernet MAC DA for Multicast MPLS ................... 7
8 IANA Considerations .................................. 7
9 Security Considerations .............................. 7
10 Normative References ................................. 7
11 Informative References ............................... 8
12 Authors' Addresses ................................... 8
13 Full Copyright Statement ............................. 8
14 Intellectual Property ................................ 9
1. Introduction
RFC 3031 defines the "Next Hop Label Forwarding Entry" (NHLFE). The
NHLFE for a particular label maps the label into a next hop (among
other things). When an MPLS packet is received, its top label is
mapped to an NHLFE, and the packet is sent to the next hop specified
by the NHLFE.
We define a particular MPLS label to be a "multicast label" in a
particular context if the NHLFE to which it is mapped in that context
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. Note that this definition accommodates the case
where the set of next hops contains a single member. What makes a
Eckert, et al. [Page 2]
Internet Draft draft-rosen-mpls-multicast-encaps-01.txt October 2005
label a multicast label in a particular context is the semantics
attached to the set, i.e., the intention to replicate the packet and
transmit to all members of the set if the set has more than one
member.
RFC 3032 established two data link layer codepoints for MPLS: one to
indicate that the data link layer frame is carrying an MPLS unicast
packet, and the other to indicate that the data link layer frame is
carrying an MPLS multicast packet. The term "multicast packet" is
not precisely defined in RFC 3032, though one may presume that the
"multicast" codepoint is intended to identify the packet's top label
as a multicast label. However, the multicast codepoint has never
been deployed, and further development of the procedures for MPLS
multicast have shown that, while there is a need for two codepoints,
the use of the two codepoints is not properly captured by RFC3032.
In particular, there is no need for the codepoint to indicate whether
the top MPLS label is a multicast label. When the receiver of an
MPLS packet looks up the top label, the NHLFE will specify whether
the label is a multicast label or not.
This document updates RFC 3032 and RFC 4023 by re-specifying the use
of the codepoints.
While RFC 3032 allows an MPLS packet to be carried in an ethernet
multicast frame, it fails to specify how the Medium Access Layer
Destination Address (MAC DA) field is to be set in that case. This
document provides that specification.
2. Upstream-Assigned vs. Downstream-Assigned
According to RFC 3031, if two MPLS Label Switching Routers (LSRs) are
adjacent in a label switched path (LSP), with respect to that LSP,
one of them may be called the "upstream" LSR and the other the
"downstream" LSR. Call these Ru and Rd respectively. Before Ru can
send an MPLS packet to Rd with label L at the top of the label stack,
Ru and Rd must agree on the Forwarding Equivalence Class (FEC) which
is bound to L. A particular binding of L to FEC F is called a
"downstream-assigned" binding if the binding is first made by Rd and
then advertised to Ru. If the binding is first made by Ru and then
advertised to Rd, it is called an "upstream-assigned" binding.
If Ru and RD are LSP adjacencies, then they transmit a MPLS packet to
each other through one of the following mechanisms:
Eckert, et al. [Page 3]
Internet Draft draft-rosen-mpls-multicast-encaps-01.txt October 2005
1. by putting the MPLS packet in a data link layer frame and
transmitting the frame
2. by transmitting the MPLS packet through an MPLS tunnel, i.e.,
by pushing an additional label (or labels) onto the label
stack, and then invoking mechanism 1,
3. by transmitting the MPLS packet through an IP-based tunnel
(e.g., via RFC 4023), and then invoking mechanisms 1 and/or 2.
In short, an MPLS packet is transmitted either through a data link or
through an MPLS tunnel or through an IP tunnel. In any of those
cases, when the packet emerges through the tunnel, the downstream LSR
must know whether the label that now appears at the top of the label
stack has an upstream-assigned label binding or a downstream-assigned
label binding. For convenience, we will speak of a label with an
upstream-assigned label binding as an "upstream-assigned label".
Unicast labels MUST be downstream-assigned.
Under certain conditions, specified below, multicast labels MAY be
upstream-assigned. The ability to use upstream-assigned labels is an
OPTIONAL feature. Upstream-assigned labels MUST NOT be used unless
it is known that the downstream LSR supports them. How this is known
is outside the scope of this document.
We discuss three different types of data link or tunnel:
- Point-to-Point. A point-to-point data link or tunnel associates
two systems, such that transmissions on that link or tunnel made
by the one are received by the other, and only by the other.
When an MPLS packet is transmitted on a point-to-point data link
or tunnel, its top label (before applying the data link or tunnel
encapsulation) MUST be a downstream-assigned label.
- Point-to-Multipoint. A point-to-multipoint link or tunnel
associates n systems, such that only one of them can transmit
onto the link or tunnel, and the transmissions may be received by
the other n-1 systems.
The top labels (before applying the data link or tunnel
encapsulation) of all MPLS packets which are transmitted on a
particular point-to-multipoint data link or tunnel MUST be of the
same type; either all upstream-assigned or all downstream-
assigned. This means that all the receivers on the MPLS or IP
tunnel must know a priori whether upstream-assigned or
downstream-assigned labels are being used in the tunnel. How
Eckert, et al. [Page 4]
Internet Draft draft-rosen-mpls-multicast-encaps-01.txt October 2005
this is known is outside the scope of this document.
- Multipoint-to-Multipoint. A multipoint-to-multipoint link or
tunnel associates n systems, such that any of them can transmit
on the link or tunnel, and the transmissions may be received by
the other n-1 systems.
If a set of MPLS packets are transmitted on a multipoint-to-
multipoint link, their top labels (before applying the data link
or tunnel encapsulation) MAY be of different types, i.e., there
may be a mixture of upstream-assigned and downstream-assigned top
labels.
However, if upstream-assigned labels are to be used, the data
link or tunnel encapsulation MUST provide a codepoint which
specifies whether the top label of the encapsulated MPLS packet
is upstream-assigned or downstream-assigned. If a particular
type of data link or tunnel does not provide such a codepoint,
then upstream-assigned labels MUST NOT be used.
The remainder of this document specifies procedures for setting the
data link layer codepoints and address fields.
3. Ethernet Codepoints
Ethernet is an example of a multipoint-to-multipoint data link.
Ethertype 0x8847 is used whenever a unicast ethernet frame carries an
MPLS packet.
Ethertype 0x8847 is also used whenever a multicast ethernet frame
carries an MPLS packet, EXCEPT for the case where the top label of
the MPLS packet has been upstream-assigned.
Ethertype 0x8848, formerly known as the "MPLS multicast codepoint",
is to be used only when an MPLS packet whose top label is upstream-
assigned is carried in a multicast ethernet frame.
Eckert, et al. [Page 5]
Internet Draft draft-rosen-mpls-multicast-encaps-01.txt October 2005
4. PPP Protocol Field
PPP is an example of a point-to-point data link. When a PPP frame is
carrying an MPLS packet, the PPP Protocol field is always set to
0x0281.
5. GRE Protocol Type
RFC 4023 is modified as described below.
If the IP destination address of the GRE encapsulation is a unicast
IP address, then the ethertype value 0x8847 MUST be used in all cases
for the MPLS-in-GRE encapsulation.
If the IP destination address of the GRE encapsulation is a multicast
IP address, then:
- if both upstream-assigned and downstream-assigned labels may
appear as the top label of the encapsulated MPLS packets, then
the ethertype value 0x8847 MUST be used when the aforesaid label
is downstream-assigned, and the ethertype value 0x8848 MUST be
used when the aforesaid label is upstream-assigned.
- if all the encapsulated MPLS packets have an upstream-assigned
top label, or if all the encapsulated MPLS packets have a
downstream-assigned top label, then the ethertype value 0x8847
MUST be used.
Which of these two situations applies is determined by means outside
the scope of this specification.
6. IP Protocol Number
RFC 4023 is modified as follows: the IPv4 Protocol Number field or
the IPv6 Next Header field is always set to 137, whether or not the
encapsulated MPLS packet is an MPLS multicast packet.
If the IP destination address of the IP encapsulation is an IP
multicast address, the IP tunnel may be considered to be a point-to-
multipoint tunnel or a multipoint-to-multipoint tunnel. In either
case, either all encapsulated MPLS packets in the particular tunnel
have a downstream-assigned label at the top of the stack, or all
encapsulated MPLS packets in that tunnel have an upstream-assigned
label at the top of the stack. The means by which this is determined
for a particular tunnel is outside the scope of this specification.
Eckert, et al. [Page 6]
Internet Draft draft-rosen-mpls-multicast-encaps-01.txt October 2005
7. Ethernet MAC DA for Multicast MPLS
When a multicast MPLS packet is carried in a multicast ethernet
frame, the Destination MAC Address shall be set to the value 01-00-
5e-8a-bc-de, where abcde is the twenty-bit (4-nibble) value of the
topmost MPLS label of the MPLS packet.
8. IANA Considerations
IANA already owns the set of ethernet multicast addresses in the
range 01-00-5e-00-00-00 to 01-00-5e-ff-ff-ff. Addresses in the range
01-00-5e-00-00-00 to 01-00-5e-7f-ff-ff are reserved for use when an
ethernet multicast frame carries an IP multicast packet. IANA shall
reserve ethernet addresses in the range 01-00-5e-80-00-00 to 01-00-
5e-8f-ff-ff for use when an ethernet multicast frame carries an MPLS
multicast packet.
9. Security Considerations
The security considerations of RFC 3032 and RFC 4023 apply.
Malicious changing of the codepoint may result in loss or misrouting
of packets. However, altering the codepoint without also altering the
label does not result in a predictable effect.
Malicious alteration of the MAC DA on an ethernet can result in
packets being received by a third party, rather than by the intended
recipient.
10. Normative References
[RFC3031] "Multiprotocol Label Switching Architecture", Rosen,
Viswanathan, Callon, January 2001
[RFC3032] "MPLS Label Stack Encoding", Rosen, et. al., January 2001
[RFC4023] "Encapsulating MPLS in IP or GRE", Worster, Rekhter, Rosen,
March 2005
Eckert, et al. [Page 7]
Internet Draft draft-rosen-mpls-multicast-encaps-01.txt October 2005
11. Informative References
12. Authors' Addresses
Toerless Eckert
Cisco Systems, Inc.
170 Tasman Drive
San Jose, CA, 95134
Email: eckert@cisco.com
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
Email: erosen@cisco.com
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: rahul@juniper.net
Yakov Rekhter
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: yakov@juniper.net
13. Full Copyright Statement
Copyright (C) The Internet Society (2005).
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 AND THE INTERNET
Eckert, et al. [Page 8]
Internet Draft draft-rosen-mpls-multicast-encaps-01.txt October 2005
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.
14. 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.
Eckert, et al. [Page 9]