draft-ietf-mpls-multicast-encaps-04.txt   draft-ietf-mpls-multicast-encaps-05.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: October 2007 Cisco Systems, Inc. Expiration Date: December 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.
MPLS Multicast Encapsulations MPLS Multicast Encapsulations
draft-ietf-mpls-multicast-encaps-04.txt draft-ietf-mpls-multicast-encaps-05.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 2, line 16 skipping to change at page 2, line 16
determined by looking up the top label, rather than by the codepoint. 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 ........................ 2
2 Introduction ......................................... 3
3 Upstream-Assigned vs. Downstream-Assigned ............ 4
4 Ethernet Codepoints .................................. 6
5 PPP Protocol Field ................................... 6
6 GRE Protocol Type .................................... 6
7 IP Protocol Number ................................... 7
8 Ethernet MAC DA for Multicast MPLS ................... 7
9 IANA Considerations .................................. 8
10 Security Considerations .............................. 8
11 Normative References ................................. 8
12 Informative References ............................... 8
13 Authors' Addresses ................................... 9
14 Full Copyright Statement ............................. 9
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"
(NHLFE). The NHLFE for a particular label maps the label into a next (NHLFE). The NHLFE for a particular label maps the label into a next
skipping to change at page 5, line 9 skipping to change at page 4, line 30
OPTIONAL feature. Upstream-assigned labels MUST NOT be used unless OPTIONAL feature. Upstream-assigned labels MUST NOT be used unless
it is known that the downstream LSR supports them. How this is known it is known that the downstream LSR supports them. How this is known
is outside the scope of this document. is outside the scope of this document.
We discuss three different types of data link or tunnel: We discuss three different types of data link or tunnel:
- Point-to-Point. A point-to-point data link or tunnel associates - Point-to-Point. A point-to-point data link or tunnel associates
two systems, such that transmissions on that link or tunnel made two systems, such that transmissions on that link or tunnel made
by the one are received by the other, and only by the other. 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 For a given direction of a given point-to-point data link or
or tunnel, its top label (before applying the data link or tunnel tunnel, the following MUST be the case: either every MPLS packet
encapsulation) MUST be a downstream-assigned label. will carry an upstream-assigned label, or else every MPLS packet
will carry a downstream-assigned label. The procedures for
determining whether upstream-assigned or downstream-assigned
labels are being used are outside the scope of this
specification. However, in the absence of any other information,
the use of downstream-assigned labels MUST be presumed by
default.
- Point-to-Multipoint. A point-to-multipoint link or tunnel - Point-to-Multipoint. A point-to-multipoint link or tunnel
associates n systems, such that only one of them can transmit associates n systems, such that only one of them can transmit
onto the link or tunnel, and the transmissions may be received by onto the link or tunnel, and the transmissions may be received by
the other n-1 systems. the other n-1 systems.
The top labels (before applying the data link or tunnel The top labels (before applying the data link or tunnel
encapsulation) of all MPLS packets which are transmitted on a encapsulation) of all MPLS packets which are transmitted on a
particular point-to-multipoint data link or tunnel MUST be of the particular point-to-multipoint data link or tunnel MUST be of the
same type; either all upstream-assigned or all downstream- same type; either all upstream-assigned or all downstream-
skipping to change at page 7, line 27 skipping to change at page 7, line 8
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.
8. Ethernet MAC DA for Multicast MPLS 8. Ethernet MAC DA for Multicast MPLS
When an LSR transmits a multicast MPLS packet in a multicast ethernet When an LSR transmits a multicast MPLS packet in a multicast ethernet
frame, it MUST set the Destination MAC Address to the value 01-00- frame, it MUST set the Destination MAC Address to the value
5e-8a-bc-de, where abcde MUST, by default, be the twenty-bit (five- 01-00-5e-8a-bc-de, where abcde MUST, by default, be the twenty-bit
nibble) value of the second MPLS label on the packet's label stack. (five-nibble) value of the second MPLS label on the packet's label
By "the second label", we mean the label that is in the label stack stack. By "the second label", we mean the label that is in the label
entry that immediately follows the topmost label stack entry. The stack entry that immediately follows the topmost label stack entry.
LSR MAY, if configured to do so, allow a a label other than the The LSR MAY, if configured to do so, allow a a label other than the
second to be used for this purpose. second to be used for this purpose. However, if the MPLS packet has
only one label, the value of that label will be used instead of the
value of the (non-existent) second label.
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. However, the way in which that information is in the MAC DA field. However, the way in which that information is
used, if any, is outside the scope of this document. used, if any, is outside the scope of this document.
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 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
5e-8f-ff-ff for use when an ethernet multicast frame carries an MPLS 01-00-5e-8f-ff-ff for use when an ethernet multicast frame carries an
multicast packet. MPLS multicast packet.
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 8, line 40 skipping to change at page 8, line 18
[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 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-label- Space", Aggarwal, Rekhter, Rosen, draft-ietf-mpls-upstream-
02.txt, March 2007. label-02.txt, March 2007.
13. Authors' Addresses 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
 End of changes. 7 change blocks. 
33 lines changed or deleted 25 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/