mLDP In-Band Signaling: Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths
How a PIM multicast tree can cross an MPLS network by hiding its source and group inside the mLDP label request itself.
Wijnands, IJ., Ed., Eckert, T., Leymann, N., and M. Napierala, "Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", RFC 6826, DOI 10.17487/RFC6826, January 2013, <https://www.rfc-editor.org/info/rfc6826>.
@misc{rfc6826,
series = {Request for Comments},
number = 6826,
howpublished = {RFC 6826},
publisher = {RFC Editor},
doi = {10.17487/RFC6826},
url = {https://www.rfc-editor.org/info/rfc6826},
author = {IJ. Wijnands and T. Eckert and N. Leymann and M. Napierala},
title = {{Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths}},
pagetotal = 12,
year = 2013,
month = jan,
} RFC text
Contents
Internet Engineering Task Force (IETF) IJ. Wijnands, Ed.
Request for Comments: 6826 T. Eckert
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 N. Leymann
Deutsche Telekom
M. Napierala
AT&T Labs
January 2013
Multipoint LDP In-Band Signaling for
Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths
Abstract
Consider an IP multicast tree, constructed by Protocol Independent
Multicast (PIM), that needs to pass through an MPLS domain in which
Multipoint LDP (mLDP) point-to-multipoint and/or multipoint-to-
multipoint Labels Switched Paths (LSPs) can be created. The part of
the IP multicast tree that traverses the MPLS domain can be
instantiated as a multipoint LSP. When a PIM Join message is
received at the border of the MPLS domain, information from that
message is encoded into mLDP messages. When the mLDP messages reach
the border of the next IP domain, the encoded information is used to
generate PIM messages that can be sent through the IP domain. The
result is an IP multicast tree consisting of a set of IP multicast
sub-trees that are spliced together with a multipoint LSP. This
document describes procedures regarding how IP multicast trees are
spliced together with multipoint LSPs.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6826.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. In-Band Signaling for MP LSPs . . . . . . . . . . . . . . . . 4
2.1. Transiting Unidirectional IP Multicast Shared Trees . . . 6
2.2. Transiting IP Multicast Source Trees . . . . . . . . . . . 6
2.3. Transiting IP Multicast Bidirectional Trees . . . . . . . 7
3. LSP Opaque Encodings . . . . . . . . . . . . . . . . . . . . . 8
3.1. Transit IPv4 Source TLV . . . . . . . . . . . . . . . . . 8
3.2. Transit IPv6 Source TLV . . . . . . . . . . . . . . . . . 8
3.3. Transit IPv4 Bidir TLV . . . . . . . . . . . . . . . . . . 9
3.4. Transit IPv6 Bidir TLV . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
The mLDP (Multipoint LDP) [RFC6388] specification describes
mechanisms for creating point-to-multipoint (P2MP) and multipoint-to-
multipoint (MP2MP) LSPs (Label Switched Paths). These LSPs are
typically used for transporting end-user multicast packets. However,
the mLDP specification does not provide any rules for associating
particular end-user multicast packets with any particular LSP. Other
documents, like [RFC6513], describe applications in which out-of-band
signaling protocols, such as PIM and BGP, are used to establish the
mapping between an LSP and the multicast packets that need to be
forwarded over the LSP.
This document describes an application in which the information
needed to establish the mapping between an LSP and the set of
multicast packets to be forwarded over it is carried in the "opaque
value" field of an mLDP FEC (Forwarding Equivalence Class) element.
When an IP multicast tree (either a source-specific tree or a
bidirectional tree) enters the MPLS network, the (S,G) or (*,G)
information from the IP multicast control-plane state is carried in
the opaque value field of the mLDP FEC message. As the tree leaves
the MPLS network, this information is extracted from the FEC Element
and used to build the IP multicast control plane. PIM messages can
be sent outside the MPLS domain. Note that although the PIM control
messages are sent periodically, the mLDP messages are not.
Each IP multicast tree is mapped one-to-one to a P2MP or MP2MP LSP in
the MPLS network. A network operator should expect to see as many
LSPs in the MPLS network as there are IP multicast trees. A network
operator should be aware how IP multicast state is created in the
network to ensure that it does not exceed the scalability numbers of
the protocol, either PIM or mLDP.
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Terminology
ASM: PIM Any Source Multicast
Egress LSR: One of potentially many destinations of an LSP; also
referred to as leaf node in the case of P2MP and MP2MP LSPs.
In-band signaling: Using the opaque value of an mLDP FEC Element to
carry the (S,G) or (*,G) identifying a particular IP multicast
tree.
Ingress LSR: Source of the P2MP LSP; also referred to as a root
node.
IP multicast tree: An IP multicast distribution tree identified by
an IP multicast Group address and, optionally, by a Source IP
address, also referred to as (S,G) and (*,G).
LSR: Label Switching Router
LSP: Labels Switched Path
mLDP: Multipoint LDP
MP2MP LSP: An LSP that connects a set of leaf nodes that may each
independently act as ingress or egress.
MP LSP: A multipoint LSP, either a P2MP or an MP2MP LSP.
P2MP LSP: An LSP that has one Ingress Label Switching Router (LSR)
and one or more Egress LSRs.
RP: PIM Rendezvous Point
SSM: PIM Source-Specific Multicast
Transit LSP: A P2MP or MP2MP LSP whose FEC Element contains the
(S,G) or (*,G) identifying a particular IP multicast distribution
tree.
Transit LSR: An LSR that has one or more directly connected
downstream LSRs.
2. In-Band Signaling for MP LSPs
Consider the following topology:
|--- IPM ---|--- MPLS --|--- IPM ---|
S/RP -- (A) - (U) - (C) - (D) -- (B) -- R
Figure 1
Nodes A and B are IP-multicast-capable routers and connect to a
Source/RP and a Receiver, respectively. Nodes U, C, and D are MPLS
Label Switched Routers (LSRs).
LSR D is attached to a network that is capable of MPLS multicast and
IP multicast (see figure 1), and D is required to create a IP
multicast tree due to a certain IP multicast event, like a PIM Join,
MSDP Source Announcement (SA) [RFC3618], BGP Source Active auto-
discovery route [SM-MLDP], or Rendezvous Point (RP) discovery.
Suppose that D can determine that the IP multicast tree needs to
travel through the MPLS network until it reaches LSR U. For
instance, when D looks up the route to the Source or RP [RFC4601] of
the IP multicast tree, it may discover that the route is a BGP route
with U as the BGP next hop. Then D may choose to set up a P2MP or an
MP2MP LSP, with U as root, and to make that LSP become part of the IP
multicast distribution tree. Note that other methods are possible to
determine that an IP multicast tree is to be transported across an
MPLS network using P2MP or MP2MP LSPs. However, these methods are
outside the scope of this document.
In order to establish a multicast tree via a P2MP or MP2MP LSP using
"in-band signaling", LSR D encodes a P2MP or MP2MP FEC Element, with
the IP address of LSR U as the "Root Node Address" and with the
source and the group encoded into the "opaque value" ([RFC6388],
Sections 2.2 and 3.2). Several different opaque value types are
defined in this document. LSR D MUST NOT use a particular opaque
value type unless it knows (through provisioning or through some
other means outside the scope of this document) that LSR U supports
the root node procedures for that opaque value type.
The particular type of FEC Element and opaque value used depends on
the IP address family being used, and on whether the multicast tree
being established is a source-specific or a bidirectional multicast
tree.
When an LSR receives a label mapping or withdraw whose FEC Element
contains one of the opaque value types defined in this document, and
that LSR is not the one identified by the "Root Node Address" field
of that FEC Element, the LSR follows the procedures provided in RFC
6388.
When an LSR receives a label mapping or withdraw whose FEC Element
contains one of the opaque value types defined in this document, and
that LSR is the one identified by the Root Node Address field of that
FEC Element, then the following procedure is executed. The multicast
source and group are extracted and passed to the multicast code. If
a label mapping is being processed, the multicast code will add the
downstream LDP neighbor to the olist of the corresponding (S,G) or
(*,G) state, creating such state if it does not already exist. If a
label withdraw is being processed, the multicast code will remove the
downstream LDP neighbor from the olist of the corresponding (S,G) or
(*,G) state. From this point on, normal PIM processing will occur.
Note that if the LSR identified by the Root Node Address field does
not recognize the opaque value type, the MP LSP will be established,
but the root node will not send any multicast data packets on it.
Source or RP addresses that are reachable in a VPN context are
outside the scope of this document.
Multicast groups that operate in PIM Dense-Mode are outside the scope
of this document.
2.1. Transiting Unidirectional IP Multicast Shared Trees
Nothing prevents PIM shared trees, used by PIM-SM in the ASM service
model, from being transported across an MPLS core. However, it is
not possible to prune individual sources from the shared tree without
the use of an additional out-of-band signaling protocol, like PIM or
BGP [SM-MLDP]. For this reason, transiting shared trees across a
transit LSP is outside the scope of this document.
2.2. Transiting IP Multicast Source Trees
IP multicast source trees can be created via PIM operating in either
SSM mode [RFC4607] or ASM mode [RFC4601]. When PIM-SM is used in ASM
mode, the usual means of discovering active sources is to join a
sparse-mode shared tree. However, this document does not provide any
method of establishing a sparse-mode shared tree across an MPLS
network. To apply the technique of this document to PIM-SM in ASM
mode, there must be some other means of discovering the active
sources. One possible means is the use of MSDP [RFC3618]. Another
possible means is to use BGP Source Active auto-discovery routes, as
documented in [SM-MLDP]. However, the method of discovering the
active sources is outside the scope of this document; as a result,
this document does not specify everything that is needed to support
the ASM service model using in-band signaling.
The source and group addresses are encoded into the a transit TLV as
specified in Sections 3.1 and 3.2.
2.3. Transiting IP Multicast Bidirectional Trees
If a bidirectional IP multicast tree [RFC5015] has to be transported
over an MPLS network using in-band signaling, as described in this
document, it MUST be transported using an MP2MP LSPs. A
bidirectional tree does not have a specific source address; the group
address, subnet mask, and RP are relevant for multicast forwarding.
This document does not provide procedures to discover RP-to-group
mappings dynamically across an MPLS network and assumes the RP is
statically defined. Support of dynamic RP mappings in combination
with in-band signaling is outside the scope of this document.
The RP for the group is used to select the ingress LSR and the root
of the LSP. The group address is encoded according to the rules of
Sections 3.3 or 3.4, depending on the IP version. The subnet mask
associated with the bidirectional group is encoded in the Transit
TLV. There are two types of bidirectional states in IP multicast,
the group specific state and the RP state. The first type is
typically created when a PIM Join has been received and has a subnet
mask of 32 for IPv4 and 128 for IPv6. The RP state is typically
created via the static RP mapping and has a variable subnet mask.
The RP state is used to build a tree to the RP and is used for
sender-only branches. Each state (group specific and RP state) will
result in a separate MP2MP LSP. The merging of the two MP2MP LSPs
will be done by PIM on the root LSR. No special procedures are
necessary for PIM to merge the two LSPs. Each LSP is effectively
treated as a PIM-enabled interface. Please see [RFC5015] for more
details.
For transporting the packets of a sender-only branch, we create a
MP2MP LSP. Other sender-only branches will receive these packets and
will not forward them because there are no receivers. These packets
will be dropped. If that effect is undesirable, some other means of
transport has to be established to forward packets to the root of the
tree, for example, a multipoint-to-point LSP for example. A
technique to unicast packets to the root of a P2MP or MP2MP LSP is
documented in Section 3.2.2.1 of [MVPN-MSPMSI].
3. LSP Opaque Encodings
This section documents the different transit opaque encodings.
3.1. Transit IPv4 Source TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 3
Length: 8 (octet size of Source and Group fields)
Source: IPv4 multicast source address, 4 octets
Group: IPv4 multicast group address, 4 octets
3.2. Transit IPv6 Source TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Source ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ | Group ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 4
Length: 32 (octet size of Source and Group fields)
Source: IPv6 multicast source address, 16 octets
Group: IPv6 multicast group address, 16 octets.
3.3. Transit IPv4 Bidir TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 5
Length: 9 (octet size of Mask Len, RP, and Group fields)
Mask Len: The number of contiguous one bits that are left-justified
and used as a mask, 1 octet. Maximum value allowed is 32.
RP: Rendezvous Point (RP) IPv4 address used for the encoded Group, 4
octets.
Group: IPv4 multicast group address, 4 octets.
3.4. Transit IPv6 Bidir TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Mask Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RP ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 6
Length: 33 (octet size of Mask Len, RP and Group fields)
Mask Len: The number of contiguous one bits that are left-justified
and used as a mask, 1 octet. Maximum value allowed is 128.
RP: Rendezvous Point (RP) IPv6 address used for encoded group, 16
octets.
Group: IPv6 multicast group address, 16 octets.
4. Security Considerations
The same security considerations apply as for the base LDP
specification, as described in [RFC5036].
5. IANA Considerations
IANA has allocated the following values from the "LDP MP Opaque Value
Element basic type" registry: are:
Transit IPv4 Source TLV type - 3
Transit IPv6 Source TLV type - 4
Transit IPv4 Bidir TLV type - 5
Transit IPv6 Bidir TLV type - 6
6. References
6.1. Normative References
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, October 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for Point-
to-Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011.
6.2. Informative References
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
"Bidirectional Protocol Independent Multicast (BIDIR-
PIM)", RFC 5015, October 2007.
[RFC3618] Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source
Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC6513] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in
MPLS/BGP IP VPNs", RFC 6513, February 2012.
[SM-MLDP] Rekhter, Y., Aggarwal, R., and N. Leymann, "Carrying PIM-
SM in ASM mode Trees over P2MP mLDP LSPs", Work in
Progress, August 2011.
[MVPN-MSPMSI]
Cai, Y., Rosen, E., Ed., Napierala, M., and A. Boers,
MVPN: Optimized use of PIM via MS-PMSIs", February 2012.
7. Acknowledgments
Thanks to Eric Rosen for his valuable comments on this document.
Also thanks to Yakov Rekhter, Adrian Farrel, Uwe Joorde, Loa
Andersson and Arkadiy Gulko for providing comments on this document.
Authors' Addresses
IJsbrand Wijnands (editor)
Cisco Systems, Inc.
De kleetlaan 6a
Diegem 1831
Belgium
EMail: ice@cisco.com
Toerless Eckert
Cisco Systems, Inc.
170 Tasman Drive
San Jose CA, 95134
USA
EMail: eckert@cisco.com
Nicolai Leymann
Deutsche Telekom
Winterfeldtstrasse 21
Berlin 10781
Germany
EMail: n.leymann@telekom.de
Maria Napierala
AT&T Labs
200 Laurel Avenue
Middletown NJ 07748
USA
EMail: mnapierala@att.com
ISO Plain Language
On this page
§1The Missing Piece in Multipoint LDP
Multipoint LDP (mLDP) can build label switched paths (LSPs) that fan out to many destinations, and those paths are normally used to carry end-user multicast packets. What mLDP does not do is provide any rule for associating particular multicast packets with a particular LSP. Other documents, such as RFC 6513, describe deployments where an out-of-band signaling protocol like PIM or BGP establishes the mapping between an LSP and the multicast packets that should be forwarded over it.
This RFC removes that second protocol from the picture for one case. The information needed to establish the mapping is carried in the opaque value field of an mLDP FEC (Forwarding Equivalence Class) element. When an IP multicast tree enters the MPLS network, the (S,G) or (*,G) information from the IP multicast control plane is placed in that field. As the tree leaves the network, the information is extracted again and used to build the IP multicast control plane, and PIM messages can then be sent outside the MPLS domain.
The result is an IP multicast tree made of IP multicast sub-trees spliced together with a multipoint LSP. The RFC notes one asymmetry between the two protocols: PIM control messages are sent periodically, while the mLDP messages are not.
There is a cost to this design. Each IP multicast tree maps one to one to a P2MP or MP2MP LSP, so an operator should expect to see as many LSPs in the MPLS network as there are IP multicast trees, and should understand how IP multicast state is created so that it does not exceed the scalability numbers of the protocol, whether that is PIM or mLDP.
Multipoint LDP builds the paths for multicast traffic but does not say what should travel on them. This RFC writes the multicast tree's address into the path message, so no second protocol is needed to tie the two together. The trade-off is one path per multicast tree.
§1.2Terminology
Section 1.2 gives the document its vocabulary. A label switched path is a path through an MPLS network, set up by a label distribution protocol. A multipoint LSP, written MP LSP, is one of two kinds. A P2MP LSP has one ingress label switching router and one or more egress label switching routers. An MP2MP LSP connects a set of leaf nodes that may each independently act as an ingress or an egress.
An LSP is called a transit LSP when its FEC element contains the (S,G) or (*,G) that identifies a particular IP multicast distribution tree. The router at the source end is the ingress LSR, also called the root node; the routers at the far end are egress LSRs, also called leaf nodes. A transit LSR is a router with one or more directly connected downstream LSRs.
An IP multicast tree is identified by a multicast group address and, optionally, a source IP address. The pair is written (S,G) when the source is known and (*,G) when any source may be used. Two service models appear in the document. ASM is PIM Any Source Multicast, and SSM is PIM Source-Specific Multicast, where the receiver names the source it wants. A PIM Rendezvous Point (RP) is the router where receivers and sources meet in the PIM-SM model. In-band signaling, in this document, means using the opaque value of an mLDP FEC element to carry the (S,G) or (*,G) that identifies the tree.
The RFC names its parts: the path that fans out, the router that starts it, the routers that end it, and the pair of addresses that identifies a multicast tree. A tree with a known source is written (S,G); a tree that accepts any source is written (*,G).
§2In-Band Signaling for Multipoint LSPs
The worked example has IP-multicast-capable routers A and B on either side of an MPLS domain that contains label switching routers U, C and D. Router D is attached to a network that can do both MPLS multicast and IP multicast, and D is the router that has to create an IP multicast tree, because a PIM Join, an MSDP Source Announcement, a BGP Source Active auto-discovery route, or a Rendezvous Point discovery has told it that one is needed.
Suppose D can work out that the tree has to travel through the MPLS network until it reaches LSR U. Looking up the route to the source or the RP may show that the route is a BGP route whose next hop is U. D can then choose to set up a P2MP or an MP2MP LSP with U as the root, and make that LSP part of the IP multicast distribution tree.
To do that, D encodes a P2MP or MP2MP FEC element with the IP address of LSR U as the Root Node Address, and with the source and the group encoded into the opaque value. The RFC is strict about one point here: D MUST NOT use a particular opaque value type unless it knows, through provisioning or some other means outside the scope of this document, that U supports the root node procedures for that opaque value type. Which FEC element and opaque value are used depends on the IP address family, and on whether the tree is source-specific or bidirectional.
The handling rule is simple. An LSR that receives a label mapping or withdraw whose FEC element contains one of these opaque value types, and that is not the router named by the Root Node Address, follows the ordinary procedures of RFC 6388. The LSR that is the root extracts the multicast source and group and passes them to the multicast code. Processing a label mapping adds the downstream LDP neighbor to the outgoing list of the matching (S,G) or (*,G) state, creating that state if it does not already exist; processing a label withdraw removes the downstream LDP neighbor from that list. From that point on, normal PIM processing occurs.
One edge case is spelled out. If the LSR identified by the Root Node Address does not recognize the opaque value type, the multipoint LSP is still established, but the root will not send any multicast data packets on it.
The edge router that notices a new multicast tree builds a path across the MPLS network and writes the tree's address into the label message. The router at the far end pulls the address back out and tells its multicast code to treat the new neighbour as a normal PIM branch. Everything after that is ordinary PIM.
- PIM JoinA join arrives at the border of the MPLS domain.
- mLDP label mappingThe FEC opaque value carries the source and the group.
- PIM messagesAt the next IP domain the tree is rebuilt and PIM resumes.
§2.1What the Document Leaves Out
Several common cases are deliberately outside this document. A PIM shared tree, used by PIM-SM in the ASM service model, cannot be carried this way, because pruning an individual source from the shared tree would need an additional out-of-band signaling protocol such as PIM or BGP. Multicast groups that operate in PIM Dense-Mode are excluded, and so are source or RP addresses that are reachable in a VPN context.
The ASM service model is only partly covered. When PIM-SM runs in ASM mode, the usual way to discover active sources is to join a sparse-mode shared tree, and this document provides no method for establishing a sparse-mode shared tree across an MPLS network. Some other means of discovering the active sources is needed, and the RFC names two candidates: MSDP, and BGP Source Active auto-discovery routes. The choice is outside the scope of this document, and the RFC says so plainly: the document does not specify everything that is needed to support the ASM service model using in-band signaling.
For bidirectional trees the RFC assumes the RP is statically defined. It provides no procedures to discover RP-to-group mappings dynamically across an MPLS network, and puts dynamic RP mappings in combination with in-band signaling outside its scope.
Some multicast setups are left out: shared trees that any source can feed, dense mode, and addresses inside VPNs. For the any-source case the RFC needs another way to find the active sources first, and it does not supply one.
§2.2Source Trees and Bidirectional Trees
IP multicast source trees can be created by PIM running in either SSM mode or ASM mode. In SSM mode the source is known, so the tree is (S,G). In ASM mode the tree is (*,G) until a source is discovered, and the RFC requires some other mechanism, such as MSDP or BGP Source Active auto-discovery routes, to find active sources. Either way, the source and group addresses are encoded into a transit TLV.
A bidirectional IP multicast tree has no specific source address, so it MUST be transported using an MP2MP LSP. For a bidirectional tree the group address, the subnet mask and the RP are the parts that matter for multicast forwarding. The RP for the group is used to select the ingress LSR and the root of the LSP, and the group address is encoded according to the rules for the IP version in use.
There are two kinds of bidirectional state. The group-specific state is typically created when a PIM Join has been received, and it has a subnet mask of 32 for IPv4 and 128 for IPv6. The RP state is typically created through the static RP mapping and has a variable subnet mask; it is used to build a tree to the RP and is used for sender-only branches. Each state, group-specific or RP, results in a separate MP2MP LSP, and the merging of the two LSPs is done by PIM on the root LSR. No special procedures are necessary for that merge, because each LSP is effectively treated as a PIM-enabled interface.
Sender-only branches carry a warning. Packets for such a branch travel over an MP2MP LSP, and the other sender-only branches receive those packets as well. They will not forward them, because there are no receivers there, so the packets are dropped. If that effect is undesirable, some other means of transport has to be established to forward packets to the root of the tree, for example a multipoint-to-point LSP; the RFC points at a technique for unicasting packets to the root of a P2MP or MP2MP LSP.
A tree with one known source is carried over a path that fans out from one router. A bidirectional tree has no single source, so it uses a path where any leaf can be the source. That path needs two of its own, one for the group and one for the rendezvous point, and the router joins them up with its normal multicast code.
§3The Four Transit TLV Encodings
The opaque value is not free-form. Four encodings are defined, one for each combination of IP version and tree type.
The Transit IPv4 Source TLV has type 3 and a length of 8 octets, holding an IPv4 multicast source address of 4 octets and an IPv4 multicast group address of 4 octets. The Transit IPv6 Source TLV has type 4 and a length of 32 octets, holding an IPv6 multicast source address of 16 octets and an IPv6 multicast group address of 16 octets.
The bidirectional variants carry the RP instead of a source. The Transit IPv4 Bidir TLV has type 5 and a length of 9 octets: one octet for the mask length, 4 octets for the IPv4 address of the RP used for the encoded group, and 4 octets for the group address. The mask length is the number of contiguous one bits that are left-justified and used as a mask, and its maximum allowed value is 32. The Transit IPv6 Bidir TLV has type 6 and a length of 33 octets, with the same three fields for IPv6: one octet of mask length whose maximum is 128, a 16-octet RP address, and a 16-octet group address.
The address pair is packed into a fixed format with a type number. An IPv4 pair takes 8 bytes and an IPv6 pair takes 32. The bidirectional versions swap the source address for the address of the rendezvous point and add one byte for the network mask length.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
SOURCE | Source | 4 bytes | IPv4 multicast source address, 4 octets. | |
GROUP | Group | 4 bytes | IPv4 multicast group address, 4 octets. |
| Transit TLV | Type | Length in octets |
|---|---|---|
| Transit IPv4 Source TLV | 3 | 8 |
| Transit IPv6 Source TLV | 4 | 32 |
| Transit IPv4 Bidir TLV | 5 | 9 |
| Transit IPv6 Bidir TLV | 6 | 33 |
§4Security Considerations
The RFC has one sentence here. The same security considerations apply as for the base LDP specification, as described in RFC 5036.
The RFC adds no security rules of its own. It points at the rules that already apply to the Label Distribution Protocol.
§5IANA Considerations
Four values are allocated from the "LDP MP Opaque Value Element basic type" registry: Transit IPv4 Source TLV type 3, Transit IPv6 Source TLV type 4, Transit IPv4 Bidir TLV type 5, and Transit IPv6 Bidir TLV type 6.
IANA keeps the list of recognised opaque value formats. This RFC adds the four formats it defines to that list, numbered 3, 4, 5 and 6.