ietf-corpus

rfc-7140

LDP Extensions for Hub and Spoke Multipoint Label Switched Path

L. Jin, F. Jounay, IJ. Wijnands, N. Leymann
date2014-03 streamIETF areartg wgmpls statusPROPOSED STANDARD pages15 canonicalhttps://www.rfc-editor.org/rfc/rfc7140 doi10.17487/RFC7140
This document introduces a hub and spoke multipoint (HSMP) Label Switched Path (LSP), which allows traffic from root to leaf through point-to-multipoint (P2MP) LSPs and also leaf to root along the reverse path. That means traffic entering the HSMP LSP from the application/customer at the root node travels downstream to each leaf node, exactly as if it were traveling downstream along a P2MP LSP to each leaf node. Upstream traffic entering the HSMP LSP at any leaf node travels upstream along the tree to the root, as if it were unicast to the root. Direct communication among the leaf nodes is not allowed.

updated by

Extracted elements (23)

design-rationale §3.4.2

On HSMP LSPs, a transit node distributes the same upstream label Lu' to all downstream nodes, whereas MP2MP LSPs require a distinct label per downstream node. This simplification is valid because upstream packets from any downstream node are forwarded only toward the root, not branched to other downstream nodes.

mpls, routing

design-rationale §5

Redundancy for HSMP LSPs can be achieved by provisioning two independent HSMP LSPs in active/standby configuration. Upon failure of the active LSP, root and leaf nodes switch traffic to the standby. The detailed redundancy mechanism is out of scope for this document.

mpls, routing

design-rationale §3

Unlike MP2MP LSPs where leaf traffic branches to all other leaf nodes, in an HSMP LSP traffic from a leaf is sent only to the root, which then redistributes it on the P2MP downstream path to all leaves including the original sender. This hub-and-spoke topology prevents direct leaf-to-leaf communication by design.

mpls, routing

interoperability-note §4

On a LAN, the downstream HSMP LSP uses an upstream LSR context label (RFC 5331) as the top label and the LSP label as the second label, enabling context-specific forwarding table lookup. The upstream path on a LAN uses only the label allocated for the upstream HSMP FEC, identical to non-LAN upstream operation.

mpls, routing

normative-requirement §3.5.1 SHOULD

A leaf node that no longer needs to be an Egress LSR SHOULD send an HSMP-D Label Withdraw <X,Y,L> to its upstream LSR U and an unsolicited HSMP-U Label Release <X,Y,Lu> to indicate the upstream path is no longer used.

mpls, routing

normative-requirement §3.1 MUST

An implementation supporting HSMP LSP MUST implement LDP Capability Parameters in Initialization messages (per RFC 5561). If the peer has not advertised the HSMP LSP Capability, label messages using the HSMP FEC Element SHOULD NOT be sent to that peer.

mpls, routing

normative-requirement §3.4.2 MUST NOT

At a transit node Z, when LSR D (sender of HSMP-D Label Mapping) equals LSR U (upstream LSR for <X,Y>), updating the label forwarding table with that mapping MUST NOT be done. Similarly, if D equals the installed upstream LSR, the Label Mapping MUST be retained and MUST NOT update the forwarding table.

mpls, routing

normative-requirement §6 MUST

For LSP Ping of an HSMP LSP, the root node sending an Echo Request MUST attach the Target FEC Stack TLV with the HSMP-downstream FEC type and MUST set the R flag (Validate Reverse Path) to '1' in the Global Flags field. When the leaf node receives the Echo Request, it MUST send the Echo Reply along the associated HSMP upstream path.

mpls, routing

normative-requirement §3.3 MUST

Labels L and Lu in HSMP-D and HSMP-U Label Mapping messages MUST be allocated from the per-platform label space of the LSR sending the Label Mapping message, consistent with downstream-assigned label allocation.

mpls, routing

normative-requirement §6 SHOULD

The Reverse-path Target FEC Stack TLV attached by the leaf node in the LSP Ping Echo Reply SHOULD contain the sub-TLV of the associated HSMP-upstream FEC, enabling the root to verify the reverse path.

mpls, routing

normative-requirement §3.7 MUST

To co-route upstream and downstream LSPs, LSR U MUST look up the unicast routing table to find the best interface and next hop to reach LSR D for determining the downstream interface; if the next hop and interface are also advertised by LSR D via LDP, that interface SHOULD be used. This procedure is applicable when symmetric IGP cost is configured.

mpls, routing

normative-requirement §3 MUST

To set up the upstream path of an HSMP LSP, ordered mode MUST be used. Ordered mode guarantees that a leaf will start sending packets to the root immediately after the upstream path is installed, without packets being dropped due to an incomplete LSP.

mpls, routing

normative-requirement §3.6 SHOULD

When changing upstream LSR from U to U', the recommended default behavior is to remove the HSMP LSP to U before setting up to U'. Whether to add before or after removing is a local matter; procedures for FEC processing differ from RFC 6388 Section 2.4.3.

mpls, routing

protocol-element §1

An HSMP LSP has one root node and one or more leaf nodes. The downstream path is identical to a P2MP LSP (root to all leaves), while the upstream path carries traffic from any leaf node to the root only, following the reverse of the downstream path. Direct leaf-to-leaf communication is not permitted.

mpls, routing

protocol-element §3.2

Two new FEC element types are defined: HSMP-downstream FEC Element (type 10) and HSMP-upstream FEC Element (type 9). Structure, encoding, and error handling follow the P2MP FEC Element of RFC 6388. If an HSMP FEC Element is present in a FEC TLV, it MUST be the only FEC Element in that TLV.

mpls, routing, registry

registry §8.2

One new TLV type allocated from the LDP Parameters registry under 'TLV Type Name Space': HSMP LSP Capability Parameter with code point 0x0902, allocated from the IETF Consensus range (0x0901–0x3DFF).

registry, mpls

registry §8.1

Two new LDP FEC Element types allocated from the LDP Parameters registry under 'Forwarding Equivalence Class (FEC) Type Name Space': HSMP-upstream FEC type (9) and HSMP-downstream FEC type (10), both from the IETF Consensus range (0–127).

registry, mpls

registry §8.3

Two new sub-TLV types allocated for the LSP Ping Target FEC Stack TLV (type 1), Reverse-path Target FEC Stack TLV (type 16), and Reply Path TLV (type 21): HSMP-upstream LDP FEC Stack (29) and HSMP-downstream LDP FEC Stack (30), from the IETF Standards Action range (0–16383).

registry, mpls

security-consideration §7

The security considerations for HSMP LSP are the same as those for MP2MP LSP described in RFC 6388 and RFC 6425. The new FEC Elements and procedures introduced by this document do not bring any new security issues beyond those already addressed in those references.

security, mpls

state-machine §3.4.1

Leaf node Z allocates label L and sends HSMP-D Label Mapping <X,Y,L> to upstream LSR U, then waits for HSMP-U Label Mapping <X,Y,Lu> from U. Upon receipt, if no forwarding state exists for upstream <X,Y>, Z creates state to push label Lu onto traffic to be forwarded over the HSMP LSP.

mpls, routing

state-machine §3.4.3

Root node Z receiving HSMP-D Label Mapping <X,Y,L> from D installs outgoing label L. For upstream <X,Y>, Z creates forwarding state marking itself as HSMP LSP egress LER (e.g., pop label and deliver to application), then sends HSMP-U Label Map <X,Y,Lu'> to D. Root never sends HSMP-D Label Map or receives HSMP-U Label Mapping.

mpls, routing

state-machine §3.5.2

When a transit node receives an HSMP-D Label Withdraw, it deletes the label from downstream forwarding state, sends a Label Release to the withdrawing node, and if no state remains for <X,Y>, propagates the Label Withdraw upstream. If all downstream nodes are released and no incoming interface remains, it sends an HSMP-U Label Release upstream.

mpls, routing

wire-format §3.1

The HSMP LSP Capability Parameter TLV is a 32-bit+ structure with type 0x0902. The U-bit MUST be 1 (silently ignore unknown), the F-bit MUST be 0 (not forwarded), Length SHOULD be 1, followed by the S-bit and Reserved fields as defined in RFC 5561.

mpls, routing