rfc-7246

Multipoint Label Distribution Protocol In-Band Signaling in a Virtual Routing and Forwarding (VRF) Table Context

IJ. Wijnands (Editor), P. Hitchen, N. Leymann, W. Henderickx, A. Gulko, J. Tantsura

date2014-06 streamIETF areartg wgl3vpn statusPROPOSED STANDARD pages13 canonicalhttps://www.rfc-editor.org/rfc/rfc7246 doi10.17487/RFC7246

An IP Multicast Distribution Tree (MDT) may traverse both label switching (i.e., Multiprotocol Label Switching, or MPLS) and non-label switching regions of a network. Typically, the MDT begins and ends in non-MPLS regions, but travels through an MPLS region. In such cases, it can be useful to begin building the MDT as a pure IP MDT, then convert it to an MPLS Multipoint Label Switched Path (MP-LSP) when it enters an MPLS-enabled region, and then convert it back to a pure IP MDT when it enters a non-MPLS-enabled region. Other documents specify the procedures for building such a hybrid MDT, using Protocol Independent Multicast (PIM) in the non-MPLS region of the network, and using Multipoint Label Distribution Protocol (mLDP) in the MPLS region. This document extends those procedures to handle the case where the link connecting the two regions is a Virtual Routing and Forwarding (VRF) table link, as defined in the "BGP IP/MPLS VPN" specification. However, this document is primarily aimed at particular use cases where VRFs are used to support multicast applications other than multicast VPN.

updated by

rfc-7438 — Multipoint LDP (mLDP) In-Band Signaling with Wildcards

Extracted elements (15)

design-rationale §1

RFC 6826 procedures assume routers doing PIM/mLDP conversion have routes to the source or RPA in their global routing tables, making them inapplicable when the connecting interfaces belong to a VRF. This document extends RFC 6826 to handle the VRF context by encoding the Route Distinguisher into the opaque value.

mpls, multicast

design-rationale §1

This document is primarily aimed at use cases where VRFs are used to support multicast applications other than multicast VPN. When PIM trees map one-to-one to multipoint LSPs (without aggregation), encoding PIM source/group addresses into the mLDP FEC (in-band signaling) is beneficial for troubleshooting purposes.

mpls, multicast

interoperability-note §1

The procedures described in this document do not support non-bidirectional PIM ASM groups, multicast trees other than mLDP multipoint LSPs in the core, or aggregation of multiple PIM trees onto a single multipoint LSP. RFC 6513 and RFC 6514 procedures should be used if those features are needed.

mpls, multicast

normative-requirement §1 MUST

In order to use mLDP in-band signaling procedures for a particular group address in the context of a particular set of VRFs, those VRFs MUST be configured with a range of multicast group addresses for which mLDP in-band signaling is to be enabled.

mpls, multicast

normative-requirement §1 MUST

The mLDP in-band signaling configuration MUST be present in all PE routers that attach to sites containing senders or receivers for the given set of group addresses.

mpls, multicast

protocol-element §1

Source-specific PIM trees are always mapped onto point-to-multipoint (P2MP) LSPs, while bidirectional PIM trees are always mapped onto multipoint-to-multipoint (MP2MP) LSPs, consistent with RFC 6826.

mpls, multicast

protocol-element §2

VRF in-band signaling maps a PIM (S,G) or (*,G) tree to an mLDP multipoint FEC expressed as an ordered pair {root=<Upstream-PE>; opaque_value=<S or RPA, G, Upstream-RD>}. When the UMH and upstream PE share an IP address, the root is set to the upstream PE address.

mpls, multicast

protocol-element §2

When a PE router receives an mLDP message with a P2MP or MP2MP FEC where it is the root node and the opaque value is one of the VRF types defined in Section 3, it uses the RD encoded in the opaque value to determine the VRF context, then follows RFC 6826 procedures in that VRF context.

mpls, multicast

protocol-element §2

When the UMH and upstream PE do not share an IP address, a recursive opaque value is used per RFC 6512: {root=<UMH>; opaque_value=<root=Upstream-PE, opaque_value=<S or RPA, G, Upstream-RD>>}.

mpls, multicast

registry §5

IANA assigned four new code points in the 'LDP MP Opaque Value Element basic type' registry defined by RFC 6388: Transit VPNv4 Source TLV (250), Transit VPNv6 Source TLV (251), Transit VPNv4 Bidir TLV (9), and Transit VPNv6 Bidir TLV (10).

mpls, multicast, registry

security-consideration §4 MUST

The same security considerations apply as for the base LDP specification (RFC 5036) and base mLDP specification (RFC 6388). Operators MUST configure packet filters to ensure this mechanism does not cause non-global-scoped IPv6 multicast packets to be tunneled outside of their intended scope.

mpls, multicast, security

wire-format §3.3

Transit VPNv4 Bidir TLV (Type 9, Length 17) encodes an IPv4 bidirectional multicast tree opaque value with: Mask Len (1 octet), RP IPv4 address (4 octets), Group IPv4 address (4 octets), and RD (8 octets).

mpls, multicast

wire-format §3.1

Transit VPNv4 Source TLV (Type 250, Length 16) encodes an IPv4 source-specific multicast tree opaque value with: Source (4 octets IPv4), Group (4 octets IPv4), and RD/Route Distinguisher (8 octets).

mpls, multicast

wire-format §3.4

Transit VPNv6 Bidir TLV (Type 10, Length 41) encodes an IPv6 bidirectional multicast tree opaque value with: Mask Len (1 octet), RP IPv6 address (16 octets), Group IPv6 address (16 octets), and RD (8 octets).

mpls, multicast

wire-format §3.2

Transit VPNv6 Source TLV (Type 251, Length 40) encodes an IPv6 source-specific multicast tree opaque value with: Source (16 octets IPv6), Group (16 octets IPv6), and RD/Route Distinguisher (8 octets).

mpls, multicast