rfc-6826

Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths

IJ. Wijnands (Editor), T. Eckert, N. Leymann, M. Napierala
date2013-01 streamIETF areartg wgmpls statusPROPOSED STANDARD pages12 canonicalhttps://www.rfc-editor.org/rfc/rfc6826 doi10.17487/RFC6826
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. [STANDARDS-TRACK]

updated by

Extracted elements (17)

design-rationale §2.2

For PIM-SM in ASM mode to work with in-band signaling, active sources must be discovered by some means other than a shared tree across the MPLS domain (e.g., MSDP or BGP Source Active auto-discovery routes); this document does not specify source discovery and therefore does not fully specify ASM support.

mpls, multicast, routing

design-rationale §2.3

For sender-only branches of a bidirectional tree, a MP2MP LSP is created; other branches receive the packets but drop them since they have no receivers. If this packet waste is undesirable, an alternative transport (e.g., a multipoint-to-point LSP or unicast to root) must be used.

mpls, multicast, routing

design-rationale §1

In-band signaling carries the multicast tree identity ((S,G) or (*,G)) in the 'opaque value' field of the mLDP FEC Element, avoiding a separate out-of-band mapping protocol. PIM control messages are sent periodically outside the MPLS domain, but mLDP messages are not repeated periodically.

mpls, multicast, routing

design-rationale §2.1

Transiting PIM shared trees (ASM *,G) across a transit LSP is out of scope because it is not possible to prune individual sources from the shared tree without an additional out-of-band protocol such as PIM or BGP.

mpls, multicast, routing

interoperability-note §2

If the root LSR does not recognize the opaque value type in a received FEC Element, the MP LSP will still be established, but the root node will not send any multicast data packets on it.

mpls, multicast, routing

interoperability-note §2

Source or RP addresses reachable only in a VPN context, and multicast groups operating in PIM Dense-Mode, are explicitly outside the scope of this document.

mpls, multicast, routing

normative-requirement §2.3 MUST

A bidirectional IP multicast tree (BIDIR-PIM) that must be transported over an MPLS network using in-band signaling MUST be transported using an MP2MP LSP.

mpls, multicast, routing

normative-requirement §2 MUST NOT

An ingress LSR MUST NOT use a particular opaque value type in an mLDP FEC Element unless it knows (through provisioning or other out-of-band means) that the root LSR supports the root-node procedures for that opaque value type.

mpls, multicast, routing

protocol-element §2.3

Bidirectional multicast produces two states: group-specific state (PIM Join received, subnet mask /32 for IPv4 or /128 for IPv6) and RP state (static RP mapping, variable subnet mask). Each state results in a separate MP2MP LSP; PIM on the root LSR merges the two LSPs by treating each LSP as a PIM-enabled interface.

mpls, multicast, routing

protocol-element §1

Each IP multicast tree is mapped one-to-one to a P2MP or MP2MP LSP in the MPLS network. Operators should expect as many LSPs as there are IP multicast trees, and must monitor scalability of both PIM and mLDP state.

mpls, multicast, routing

registry §5

IANA allocated four values in 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, Transit IPv6 Bidir TLV type=6.

mpls, multicast, registry

security-consideration §4

The security considerations for this document are the same as those for the base LDP specification (RFC 5036); no additional security mechanisms are introduced or required by the in-band signaling procedures.

mpls, security

state-machine §2

At the root LSR: on receiving a label mapping whose FEC contains a recognized transit opaque value, the multicast source and group are extracted and the downstream LDP neighbor is added to the olist of the (S,G) or (*,G) state (creating state if absent). On receiving a label withdraw, the downstream LDP neighbor is removed from the olist. Normal PIM processing follows in both cases.

mpls, multicast, routing

wire-format §3.3

Transit IPv4 Bidir TLV (Type=5, Length=9): encodes a 1-octet Mask Length (max 32), a 4-octet IPv4 RP address, and a 4-octet IPv4 multicast group address for bidirectional trees in the mLDP FEC opaque value field.

mpls, multicast, routing

wire-format §3.1

Transit IPv4 Source TLV (Type=3, Length=8): encodes a 4-octet IPv4 multicast source address followed by a 4-octet IPv4 multicast group address in the mLDP FEC opaque value field.

mpls, multicast, routing

wire-format §3.4

Transit IPv6 Bidir TLV (Type=6, Length=33): encodes a 1-octet Mask Length (max 128), a 16-octet IPv6 RP address, and a 16-octet IPv6 multicast group address for bidirectional trees in the mLDP FEC opaque value field.

mpls, multicast, routing

wire-format §3.2

Transit IPv6 Source TLV (Type=4, Length=32): encodes a 16-octet IPv6 multicast source address followed by a 16-octet IPv6 multicast group address in the mLDP FEC opaque value field.

mpls, multicast, routing