Network Working Group T. Eckert
Request for Comments: 5332 E. Rosen, Ed.
Category: Standards Track Cisco Systems, Inc.
Updates: 3032, 4023 R. Aggarwal
Y. Rekhter
Juniper Networks, Inc.
August 2008
MPLS Multicast Encapsulations
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
RFC 3032 established two data link layer codepoints for MPLS, used to
distinguish whether the data link layer frame is carrying an MPLS
unicast or an MPLS multicast packet. However, this usage was never
deployed. This specification updates RFC 3032 by redefining the
meaning of these two codepoints. Both codepoints can now be used to
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
upstream-assigned label".
RFC 3032 does not specify the destination address to be placed in the
"MAC DA" (Medium Access Layer Destination Address) field of an
ethernet frame that carries an MPLS multicast packet. This document
provides that specification.
This document updates RFC 3032 and RFC 4023.
Eckert, et al. Standards Track [Page 1]RFC 5332 MPLS Multicast Encapsulations August 2008Table of Contents
1. Introduction ....................................................2
2. Specification of Requirements ...................................3
3. Upstream-Assigned vs. Downstream-Assigned .......................3
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 ...........................................9
1. 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
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 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 [RFC3032] 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 RFC 3032.
Eckert, et al. Standards Track [Page 2]RFC 5332 MPLS Multicast Encapsulations August 2008
In particular, there is no need for the codepoint to indicate whether
datatracker.ietf.org