draft-ietf-mpls-multicast-encaps-09.txt   draft-ietf-mpls-multicast-encaps-10.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: November 1, 2008 Expires: December 2, 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.
May 1, 2008 June 2, 2008
MPLS Multicast Encapsulations MPLS Multicast Encapsulations
draft-ietf-mpls-multicast-encaps-09.txt draft-ietf-mpls-multicast-encaps-10.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 19 skipping to change at page 2, line 19
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 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 ...................................... 7
6 GRE Protocol Type ....................................... 6 6 GRE Protocol Type ....................................... 7
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 ...................... 8
9 IANA Considerations ..................................... 8 9 IANA Considerations ..................................... 9
10 Security Considerations ................................. 9 10 Security Considerations ................................. 9
11 Normative References .................................... 9 11 Normative References .................................... 9
12 Authors' Addresses ...................................... 9 12 Authors' Addresses ...................................... 10
13 Full Copyright Statement ................................ 10 13 Full Copyright Statement ................................ 10
14 Intellectual Property ................................... 10 14 Intellectual Property ................................... 11
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 42 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. Note that an implementation that does MPLS of the codepoints. The old use of the "multicast codepoint", as
multicast according to RFC 3032 and/or 4023 will be unable to specified in those two RFCs, is hereby deprecated.
interoperate with implementations that do MPLS multicast according to
this document. Any attempt to interoperate two such implementations Note that an implementation that does MPLS multicast according to RFC
will result either in black holes or in misrouted packets. However, 3032 and/or 4023 will be unable to interoperate with implementations
since to the best of our knowledge MPLS multicast done according to that do MPLS multicast according to this document. There may be some
RFC 3032 has never been deployed, it is believed though that this deployed platforms which support the deprecated use of the
does not present a problem in practice. This document specifically codepoints, but those platforms do not support the control plane
deprecates the multicast data plane as specified in RFC 3032. mechanisms to support MPLS multicast. The absence of the control
plane will prevent a system that implements the deprecated use of
codepoints from attempting to interoperate with a system that uses
the codepoints as specified herein. (If an MPLS multicast control
plane were to be implemented on a platform that only supports the
deprecated codepoint, interoperability problems such as black holes
and/or misrouting would arise. This does not seem like a potential
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 Suppose a labeled packet P is sent from LSR R1 to LSR R2, where R1
(LSRs) are adjacent in a label switched path (LSP), with respect to puts label L on the packet's label stack, and R2 has to look up label
that LSP, one of them may be called the "upstream" LSR and the other L in order to determine the corresponding Forwarding Equivalence
the "downstream" LSR. Call these Ru and Rd respectively. Before Ru Class (FEC), call it F.
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 If the binding between L and F was made by R2 and advertised to R1,
then the label binding is known as "downstream-assigned". RFC 3031
only discusses downstream-assigned label bindings.
If the binding between L and F was made by R1 and advertised to R2,
then the label binding is known as "upstream-assigned".
If the binding between L and F was made by a third party, say R3, and
then advertised to both R1 and R2, we also refer to the label binding
as "upstream-assigned".
Upstream-assigned labels are not required to come from the same
"label space" as downstream-assigned labels. See [RFC3031], section
3.14, and especially [UPSTREAM] for a discussion of the notion of
"label space". The procedures for properly interpreting an upstream-
assigned label are given in [UPSTREAM].
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 [RFC4023]), and then invoking mechanisms 1 (e.g., via RFC 4023 [RFC4023]), and then invoking mechanisms 1
and/or 2. 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
skipping to change at page 4, line 43 skipping to change at page 5, line 16
and/or 2. 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.
Under certain conditions, specified below, multicast labels MAY be Under certain conditions, specified below, multicast labels MAY be
upstream-assigned. The ability to use upstream-assigned labels is an upstream-assigned. The ability to use upstream-assigned labels is an
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.
This document makes no changes to the procedures regarding unicast
labels.
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.
For a given direction of a given point-to-point data link or For a given direction of a given point-to-point data link or
tunnel, the following MUST be the case: either every MPLS packet tunnel, the following MUST be the case: either every MPLS packet
will carry an upstream-assigned label, or else every MPLS packet will carry an upstream-assigned label, or else every MPLS packet
will carry a downstream-assigned label. The procedures for will carry a downstream-assigned label. The procedures for
skipping to change at page 5, line 46 skipping to change at page 6, line 18
tunnel associates n systems, such that any of them can transmit tunnel associates n systems, such that any of them can transmit
on the link or tunnel, and the transmissions may be received by on the link or tunnel, and the transmissions may be received by
the other n-1 systems. the other n-1 systems.
If MPLS packets are transmitted on a particular multipoint-to- If MPLS packets are transmitted on a particular multipoint-to-
multipoint link or tunnel, one of the following scenarios multipoint link or tunnel, one of the following scenarios
applies: applies:
1. It is known (by methods outside the scope of this document) 1. It is known (by methods outside the scope of this document)
that the top label of every MPLS packet on the link or that the top label of every MPLS packet on the link or
tunnel is downstream-assigned tunnel is downstream-assigned.
2. It is known (by methods outside the scope of this document) 2. It is known (by methods outside the scope of this document)
that the top label of every MPLS packet on the link or that the top label of every MPLS packet on the link or
tunnel is upstream-assigned tunnel is upstream-assigned.
3. Some MPLS packets on the link may have upstream-assigned 3. Some MPLS packets on the link may have upstream-assigned
top labels while some may have downstream-assigned top top labels while some may have downstream-assigned top
labels labels.
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.
 End of changes. 17 change blocks. 
36 lines changed or deleted 55 lines changed or added

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