draft-ietf-mpls-multicast-encaps-03.txt   draft-ietf-mpls-multicast-encaps-04.txt 
Network Working Group Toerless Eckert Network Working Group Toerless Eckert
Internet Draft Eric C. Rosen (editor) Internet Draft Eric C. Rosen (editor)
Expiration Date: August 2007 Cisco Systems, Inc. Expiration Date: October 2007 Cisco Systems, Inc.
Updates RFCs 3032 and 4023 Updates RFCs 3032 and 4023
Rahul Aggarwal Rahul Aggarwal
Yakov Rekhter Yakov Rekhter
Juniper Networks, Inc. Juniper Networks, Inc.
February 2007
MPLS Multicast Encapsulations MPLS Multicast Encapsulations
draft-ietf-mpls-multicast-encaps-03.txt draft-ietf-mpls-multicast-encaps-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 1, line 44 skipping to change at page 1, line 42
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
RFC 3032 established two data link layer codepoints for MPLS: one to RFC 3032 established two data link layer codepoints for MPLS: one to
indicate that the data link layer frame is carrying an MPLS unicast 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 packet, and the other to indicate that the data link layer frame is
carrying an MPLS multicast packet. This specification updates carrying an MPLS multicast packet. This specification updates RFC
RFC3032 by redefining the meaning of these two codepoints. The 3032 by redefining the meaning of these two codepoints. The former
former "multicast codepoint" is now to be used only on multiaccess "multicast codepoint" is now to be used only on multiaccess media,
media, and it is to mean "the top label of the following label stack and it is to mean "the top label of the following label stack is an
is an upstream-assigned label". The former "unicast codepoint" is to upstream-assigned label". The former "unicast codepoint" is to be
be used in all other cases. Whether the data link layer payload is a 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 unicast MPLS packet or a multicast MPLS packet is now to be
determined by looking up the top label, rather than by the codepoint. determined by looking up the top label, rather than by the codepoint.
RFC3032 does not specify the destination address to be placed in the RFC3032 does not specify the destination address to be placed in the
"MAC DA" field of an ethernet frame which carries an MPLS multicast "MAC DA" field of an ethernet frame which carries an MPLS multicast
packet. This document provides that specification. packet. This document provides that specification.
This document updates RFC 3032 and RFC 4023. This document updates RFC 3032 and RFC 4023.
Contents Contents
1 Introduction ......................................... 2 1 Specification of Requirements ........................ 2
2 Upstream-Assigned vs. Downstream-Assigned ............ 3 2 Introduction ......................................... 3
3 Ethernet Codepoints .................................. 5 3 Upstream-Assigned vs. Downstream-Assigned ............ 4
4 PPP Protocol Field ................................... 6 4 Ethernet Codepoints .................................. 6
5 GRE Protocol Type .................................... 6 5 PPP Protocol Field ................................... 6
6 IP Protocol Number ................................... 6 6 GRE Protocol Type .................................... 6
7 Ethernet MAC DA for Multicast MPLS ................... 7 7 IP Protocol Number ................................... 7
8 IANA Considerations .................................. 7 8 Ethernet MAC DA for Multicast MPLS ................... 7
9 Security Considerations .............................. 7 9 IANA Considerations .................................. 8
10 Normative References ................................. 7 10 Security Considerations .............................. 8
11 Informative References ............................... 8 11 Normative References ................................. 8
12 Authors' Addresses ................................... 8 12 Informative References ............................... 8
13 Full Copyright Statement ............................. 8 13 Authors' Addresses ................................... 9
14 Intellectual Property ................................ 9 14 Full Copyright Statement ............................. 9
15 Intellectual Property ................................ 10
1. Introduction 1. Specification of Requirements
RFC 3031 defines the "Next Hop Label Forwarding Entry" (NHLFE). The The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
NHLFE for a particular label maps the label into a next hop (among "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
other things). When an MPLS packet is received, its top label is document are to be interpreted as described in [RFC2119].
mapped to an NHLFE, and the packet is sent to the next hop specified
by the NHLFE. 2. Introduction
RFC 3031 [RFC3031] 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 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 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 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 to be replicated, and a copy of the packet sent to each of the
specified next hops. Note that this definition accommodates the case specified next hops. Note that this definition accommodates the case
where the set of next hops contains a single member. What makes a where the set of next hops contains a single member. What makes a
label a multicast label in a particular context is the semantics label a multicast label in a particular context is the semantics
attached to the set, i.e., the intention to replicate the packet and 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 transmit to all members of the set if the set has more than one
member. member.
RFC 3032 established two data link layer codepoints for MPLS: one to RFC 3032 [RFC3032] established two data link layer codepoints for
indicate that the data link layer frame is carrying an MPLS unicast MPLS: one to indicate that the data link layer frame is carrying an
packet, and the other to indicate that the data link layer frame is MPLS unicast packet, and the other to indicate that the data link
carrying an MPLS multicast packet. The term "multicast packet" is layer frame is carrying an MPLS multicast packet. The term
not precisely defined in RFC 3032, though one may presume that the "multicast packet" is not precisely defined in RFC 3032, though one
"multicast" codepoint is intended to identify the packet's top label may presume that the "multicast" codepoint is intended to identify
as a multicast label. However, the multicast codepoint has never the packet's top label as a multicast label. However, the multicast
been deployed, and further development of the procedures for MPLS codepoint has never been deployed, and further development of the
multicast have shown that, while there is a need for two codepoints, procedures for MPLS multicast have shown that, while there is a need
the use of the two codepoints is not properly captured by RFC3032. for two codepoints, the use of the two codepoints is not properly
captured by RFC 3032.
In particular, there is no need for the codepoint to indicate whether 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 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 MPLS packet looks up the top label, the NHLFE will specify whether
the label is a multicast label or not. the label is a multicast label or not.
This document updates RFC 3032 and RFC 4023 by re-specifying the use This document updates RFC 3032 and RFC 4023 by re-specifying the use
of the codepoints. of the codepoints.
While RFC 3032 allows an MPLS packet to be carried in an ethernet While RFC 3032 allows an MPLS packet to be carried in an ethernet
multicast frame, it fails to specify how the Medium Access Layer multicast frame, it fails to specify how the Medium Access Layer
Destination Address (MAC DA) field is to be set in that case. This Destination Address (MAC DA) field is to be set in that case. This
document provides that specification. document provides that specification.
2. Upstream-Assigned vs. Downstream-Assigned 3. Upstream-Assigned vs. Downstream-Assigned
According to RFC 3031, if two MPLS Label Switching Routers (LSRs) are According to RFC 3031 [RFC3031], if two MPLS Label Switching Routers
adjacent in a label switched path (LSP), with respect to that LSP, (LSRs) are adjacent in a label switched path (LSP), with respect to
one of them may be called the "upstream" LSR and the other the that LSP, one of them may be called the "upstream" LSR and the other
"downstream" LSR. Call these Ru and Rd respectively. Before Ru can the "downstream" LSR. Call these Ru and Rd respectively. Before Ru
send an MPLS packet to Rd with label L at the top of the label stack, can send an MPLS packet to Rd with label L at the top of the label
Ru and Rd must agree on the Forwarding Equivalence Class (FEC) which stack, Ru and Rd must agree on the Forwarding Equivalence Class (FEC)
is bound to L. A particular binding of L to FEC F is called a 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 "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 then advertised to Ru. If the binding is first made by Ru and then
advertised to Rd, it is called an "upstream-assigned" binding. advertised to Rd, it is called an "upstream-assigned" binding.
If Ru and RD are LSP adjacencies, then they transmit a MPLS packet to If Ru and RD are LSP adjacencies, then they transmit a MPLS packet to
each other through one of the following mechanisms: each other through one of the following mechanisms:
1. by putting the MPLS packet in a data link layer frame and 1. by putting the MPLS packet in a data link layer frame and
transmitting the frame transmitting the frame
2. by transmitting the MPLS packet through an MPLS tunnel, i.e., 2. by transmitting the MPLS packet through an MPLS tunnel, i.e.,
by pushing an additional label (or labels) onto the label by pushing an additional label (or labels) onto the label
stack, and then invoking mechanism 1, stack, and then invoking mechanism 1,
3. by transmitting the MPLS packet through an IP-based tunnel 3. by transmitting the MPLS packet through an IP-based tunnel
(e.g., via RFC 4023), and then invoking mechanisms 1 and/or 2. (e.g., via RFC 4023 [RFC4023]), and then invoking mechanisms 1
and/or 2.
In short, an MPLS packet is transmitted either through a data link or 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 through an MPLS tunnel or through an IP tunnel. In any of those
cases, when the packet emerges through the tunnel, the downstream LSR 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 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 stack has an upstream-assigned label binding or a downstream-assigned
label binding. For convenience, we will speak of a label with an label binding. For convenience, we will speak of a label with an
upstream-assigned label binding as an "upstream-assigned label". upstream-assigned label binding as an "upstream-assigned label".
Unicast labels MUST be downstream-assigned. Unicast labels MUST be downstream-assigned.
skipping to change at page 5, line 37 skipping to change at page 6, line 9
If (and only if) the third scenario applies, the data link or If (and only if) the third scenario applies, the data link or
tunnel encapsulation MUST provide a codepoint which specifies tunnel encapsulation MUST provide a codepoint which specifies
whether the top label of the encapsulated MPLS packet is whether the top label of the encapsulated MPLS packet is
upstream-assigned or downstream-assigned. If a particular type upstream-assigned or downstream-assigned. If a particular type
of data link or tunnel does not provide such a codepoint, then of data link or tunnel does not provide such a codepoint, then
the third scenario MUST NOT be used. the third scenario MUST NOT be used.
The remainder of this document specifies procedures for setting the The remainder of this document specifies procedures for setting the
data link layer codepoints and address fields. data link layer codepoints and address fields.
3. Ethernet Codepoints 4. Ethernet Codepoints
Ethernet is an example of a multipoint-to-multipoint data link. Ethernet is an example of a multipoint-to-multipoint data link.
Ethertype 0x8847 is used whenever a unicast ethernet frame carries an Ethertype 0x8847 is used whenever a unicast ethernet frame carries an
MPLS packet. MPLS packet.
Ethertype 0x8847 is also used whenever a multicast ethernet frame Ethertype 0x8847 is also used whenever a multicast ethernet frame
carries an MPLS packet, EXCEPT for the case where the top label of carries an MPLS packet, EXCEPT for the case where the top label of
the MPLS packet has been upstream-assigned. the MPLS packet has been upstream-assigned.
Ethertype 0x8848, formerly known as the "MPLS multicast codepoint", Ethertype 0x8848, formerly known as the "MPLS multicast codepoint",
is to be used only when an MPLS packet whose top label is upstream- is to be used only when an MPLS packet whose top label is upstream-
assigned is carried in a multicast ethernet frame. assigned is carried in a multicast ethernet frame.
4. PPP Protocol Field 5. PPP Protocol Field
PPP is an example of a point-to-point data link. When a PPP frame is 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 carrying an MPLS packet, the PPP Protocol field is always set to
0x0281. 0x0281.
5. GRE Protocol Type 6. GRE Protocol Type
RFC 4023 is modified as described below. RFC 4023 is modified as described below.
If the IP destination address of the GRE encapsulation is a unicast 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 IP address, then the ethertype value 0x8847 MUST be used in all cases
for the MPLS-in-GRE encapsulation. for the MPLS-in-GRE encapsulation.
If the IP destination address of the GRE encapsulation is a multicast If the IP destination address of the GRE encapsulation is a multicast
IP address, then: IP address, then:
skipping to change at page 6, line 35 skipping to change at page 7, line 9
- the ethertype value 0x8848 MUST be used when the top label of the - the ethertype value 0x8848 MUST be used when the top label of the
encapsulated MPLS packet is upstream-assigned. encapsulated MPLS packet is upstream-assigned.
Through procedures which are outside the scope of this specification, Through procedures which are outside the scope of this specification,
it may be known that if the destination address of a GRE packet is a it may be known that if the destination address of a GRE packet is a
multicast IP address, then the top label of the GRE payload is multicast IP address, then the top label of the GRE payload is
upstream-assigned. In such a case, the occurrence of the 8847 upstream-assigned. In such a case, the occurrence of the 8847
codepoint in a GRE packet with a multicast destination IP address codepoint in a GRE packet with a multicast destination IP address
MUST be considered an error, and the packet MUST be discarded. MUST be considered an error, and the packet MUST be discarded.
6. IP Protocol Number 7. IP Protocol Number
RFC 4023 is modified as follows: the IPv4 Protocol Number field or 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 the IPv6 Next Header field is always set to 137, whether or not the
encapsulated MPLS packet is an MPLS multicast packet. encapsulated MPLS packet is an MPLS multicast packet.
If the IP destination address of the IP encapsulation is an IP 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- multicast address, the IP tunnel may be considered to be a point-to-
multipoint tunnel or a multipoint-to-multipoint tunnel. In either multipoint tunnel or a multipoint-to-multipoint tunnel. In either
case, either all encapsulated MPLS packets in the particular tunnel case, either all encapsulated MPLS packets in the particular tunnel
have a downstream-assigned label at the top of the stack, or all have a downstream-assigned label at the top of the stack, or all
encapsulated MPLS packets in that tunnel have an upstream-assigned encapsulated MPLS packets in that tunnel have an upstream-assigned
label at the top of the stack. The means by which this is determined 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. for a particular tunnel is outside the scope of this specification.
7. Ethernet MAC DA for Multicast MPLS 8. Ethernet MAC DA for Multicast MPLS
When a multicast MPLS packet is carried in a multicast ethernet When an LSR transmits a multicast MPLS packet in a multicast ethernet
frame, the Destination MAC Address shall be set to the value 01-00- frame, it MUST set the Destination MAC Address to the value 01-00-
5e-8a-bc-de, where abcde is the twenty-bit (5-nibble) value of the 5e-8a-bc-de, where abcde MUST, by default, be the twenty-bit (five-
topmost MPLS label of the MPLS packet. nibble) value of the second MPLS label on the packet's label stack.
By "the second label", we mean the label that is in the label stack
entry that immediately follows the topmost label stack entry. The
LSR MAY, if configured to do so, allow a a label other than the
second to be used for this purpose.
8. IANA Considerations It is expected that the LSR will follow the procedures of [UPSTREAM],
pushing on two labels, with the topmost label being a "context label"
that is the same for all MPLS packets being transmitted by the LSR
onto the ethernet, but with the second label being different for
different LSPs. Thus if the MAC DA value is a function of the second
label, more of the LSP-specific information about the packet appears
in the MAC DA field. However, the way in which that information is
used, if any, is outside the scope of this document.
9. IANA Considerations
IANA already owns the set of ethernet multicast addresses in the 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 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 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 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- 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 5e-8f-ff-ff for use when an ethernet multicast frame carries an MPLS
multicast packet. multicast packet.
9. Security Considerations 10. Security Considerations
The security considerations of RFC 3032 and RFC 4023 apply. The security considerations of RFC 3032 and RFC 4023 apply.
Malicious changing of the codepoint may result in loss or misrouting Malicious changing of the codepoint may result in loss or misrouting
of packets. However, altering the codepoint without also altering the of packets. However, altering the codepoint without also altering the
label does not result in a predictable effect. label does not result in a predictable effect.
Malicious alteration of the MAC DA on an ethernet can result in Malicious alteration of the MAC DA on an ethernet can result in
packets being received by a third party, rather than by the intended packets being received by a third party, rather than by the intended
recipient. recipient.
10. Normative References 11. Normative References
[RFC2119] "Key words for use in RFCs to Indicate Requirement
[RFC3031] "Multiprotocol Label Switching Architecture", Rosen, [RFC3031] "Multiprotocol Label Switching Architecture", Rosen,
Viswanathan, Callon, January 2001 Viswanathan, Callon, January 2001
[RFC3032] "MPLS Label Stack Encoding", Rosen, et. al., January 2001 [RFC3032] "MPLS Label Stack Encoding", Rosen, et. al., January 2001
[RFC4023] "Encapsulating MPLS in IP or GRE", Worster, Rekhter, Rosen, [RFC4023] "Encapsulating MPLS in IP or GRE", Worster, Rekhter, Rosen,
11. Informative References 12. Informative References
12. Authors' Addresses [UPSTREAM] "MPLS Upstream Label Assignment and Context Specific Label
Space", Aggarwal, Rekhter, Rosen, draft-ietf-mpls-upstream-label-
02.txt, March 2007.
13. Authors' Addresses
Toerless Eckert Toerless Eckert
Cisco Systems, Inc. Cisco Systems, Inc.
170 Tasman Drive 170 Tasman Drive
San Jose, CA, 95134 San Jose, CA, 95134
Email: eckert@cisco.com Email: eckert@cisco.com
Eric C. Rosen Eric C. Rosen
Cisco Systems, Inc. Cisco Systems, Inc.
1414 Massachusetts Avenue 1414 Massachusetts Avenue
skipping to change at page 8, line 33 skipping to change at page 9, line 31
1194 North Mathilda Ave. 1194 North Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: rahul@juniper.net Email: rahul@juniper.net
Yakov Rekhter Yakov Rekhter
Juniper Networks Juniper Networks
1194 North Mathilda Ave. 1194 North Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
Email: yakov@juniper.net Email: yakov@juniper.net
13. Full Copyright Statement 14. Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
14. Intellectual Property 15. Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 25 change blocks. 
65 lines changed or deleted 90 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/