draft-ietf-mpls-multicast-encaps-07.txt   draft-ietf-mpls-multicast-encaps-08.txt 
Network Working Group Toerless Eckert Network Working Group Toerless Eckert
Internet Draft Eric C. Rosen (editor) Internet Draft Eric C. Rosen (editor)
Intended Status: Standards Track Cisco Systems, Inc. Intended Status: Standards Track Cisco Systems, Inc.
Expires: May 1, 2008 Expires: October 28, 2008
Updates: RFCs 3032 and 4023 Rahul Aggarwal Updates: RFCs 3032 and 4023 Rahul Aggarwal
Yakov Rekhter Yakov Rekhter
Juniper Networks, Inc. Juniper Networks, Inc.
November 1, 2007 April 28, 2008
MPLS Multicast Encapsulations MPLS Multicast Encapsulations
draft-ietf-mpls-multicast-encaps-07.txt draft-ietf-mpls-multicast-encaps-08.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 41 skipping to change at page 1, line 41
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
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, used to
indicate that the data link layer frame is carrying an MPLS unicast distinguish whether the data link layer frame is carrying an MPLS
packet, and the other to indicate that the data link layer frame is unicast or an MPLS multicast packet. However, this usage was never
carrying an MPLS multicast packet. This specification updates RFC deployed. This specification updates RFC 3032 by redefining the
3032 by redefining the meaning of these two codepoints. The former meaning of these two codepoints. Both codepoints can now be used to
"multicast codepoint" is now to be used only on multiaccess media, carry multicast packets. The second codepoint (formerly the
"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 and it is to mean "the top label of the following label stack is an
upstream-assigned label". The former "unicast codepoint" is to be upstream-assigned label".
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.
RFC 3032 does not specify the destination address to be placed in the RFC 3032 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 Specification of Requirements ........................... 3 1 Specification of Requirements ........................... 2
2 Introduction ............................................ 3 2 Introduction ............................................ 3
3 Upstream-Assigned vs. Downstream-Assigned ............... 4 3 Upstream-Assigned vs. Downstream-Assigned ............... 4
4 Ethernet Codepoints ..................................... 6 4 Ethernet Codepoints ..................................... 6
5 PPP Protocol Field ...................................... 6 5 PPP Protocol Field ...................................... 6
6 GRE Protocol Type ....................................... 6 6 GRE Protocol Type ....................................... 6
7 IP Protocol Number ...................................... 7 7 IP Protocol Number ...................................... 7
8 Ethernet MAC DA for Multicast MPLS ...................... 7 8 Ethernet MAC DA for Multicast MPLS ...................... 7
9 IANA Considerations ..................................... 8 9 IANA Considerations ..................................... 8
10 Security Considerations ................................. 8 10 Security Considerations ................................. 9
11 Normative References .................................... 9 11 Normative References .................................... 9
12 Informative References .................................. 9 12 Authors' Addresses ...................................... 9
13 Authors' Addresses ...................................... 9 13 Full Copyright Statement ................................ 10
14 Full Copyright Statement ................................ 10 14 Intellectual Property ................................... 10
15 Intellectual Property ................................... 10
1. Specification of Requirements 1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
RFC 3031 [RFC3031] defines the "Next Hop Label Forwarding Entry" RFC 3031 [RFC3031] defines the "Next Hop Label Forwarding Entry"
skipping to change at page 3, line 48 skipping to change at page 3, line 42
procedures for MPLS multicast have shown that, while there is a need procedures for MPLS multicast have shown that, while there is a need
for two codepoints, the use of the two codepoints is not properly for two codepoints, the use of the two codepoints is not properly
captured by RFC 3032. 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. Note that an implementation that does MPLS
multicast according to RFC 3032 and/or 4023 will be unable to
interoperate with implementations that do MPLS multicast according to
this document. Any attempt to interoperate two such implementations
will result either in black holes or in misrouted packets. It is
believed though that this does not present a problem in practice.
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.
3. Upstream-Assigned vs. Downstream-Assigned 3. Upstream-Assigned vs. Downstream-Assigned
According to RFC 3031 [RFC3031], if two MPLS Label Switching Routers According to RFC 3031 [RFC3031], if two MPLS Label Switching Routers
(LSRs) are adjacent in a label switched path (LSP), with respect to (LSRs) are adjacent in a label switched path (LSP), with respect to
skipping to change at page 8, line 26 skipping to change at page 8, line 26
It is expected that the LSR will follow the procedures of [UPSTREAM], It is expected that the LSR will follow the procedures of [UPSTREAM],
pushing on two labels, with the topmost label being a "context label" 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 that is the same for all MPLS packets being transmitted by the LSR
onto the ethernet, but with the second label being different for 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 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 label, more of the LSP-specific information about the packet appears
in the MAC DA field. This can be used to filter multicast packets in the MAC DA field. This can be used to filter multicast packets
with "unexpected" non-zero values of vwxyz. Further discussion of with "unexpected" non-zero values of vwxyz. Further discussion of
such filtering or its uses is outside the scope of this document. such filtering or its uses is outside the scope of this document.
The use of ethernet and/or IP broadcast addresses (as distinguished
from multicast addresses) does not fall within the scope of this
specification.
9. IANA Considerations 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 already reserved for use
ethernet multicast frame carries an IP multicast packet. IANA shall when an ethernet multicast frame carries an IP multicast packet.
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 When this document is accepted, IANA shall reserve ethernet addresses
MPLS multicast packet. 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. Addresses
in this range are to be valid when used with ethertype 8847 or 8848.
As this document modifies the usage of ethertypes 8847 and 8848, IANA
shall change the description of these ethertypes as follows.
Ethertype 8847 shall be defined as "MPLS", as defined in RFC 3032 and
in this document. Ethertype 8848 shall be defined as "MPLS with
upstream-assigned label", as defined in this document.
10. 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
skipping to change at page 9, line 14 skipping to change at page 9, line 26
11. Normative References 11. Normative References
[RFC2119] "Key words for use in RFCs to Indicate Requirement [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,
12. Informative References
[UPSTREAM] "MPLS Upstream Label Assignment and Context Specific Label [UPSTREAM] "MPLS Upstream Label Assignment and Context Specific Label
Space", Aggarwal, Rekhter, Rosen, draft-ietf-mpls-upstream- Space", Aggarwal, Rekhter, Rosen, draft-ietf-mpls-upstream-
label-03.txt, November 2007. label-04.txt, February 2008.
13. Authors' Addresses 12. 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 9, line 34 skipping to change at page 10, line 4
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
Boxborough, MA 01719 Boxborough, MA 01719
Email: erosen@cisco.com Email: erosen@cisco.com
Rahul Aggarwal Rahul Aggarwal
Juniper Networks Juniper Networks
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
14. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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.
15. Intellectual Property 14. 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. 19 change blocks. 
34 lines changed or deleted 45 lines changed or added

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