LDP Extensions for Hub and Spoke Multipoint Label Switched Path

An HSMP LSP is similar to MP2MP LSP described in , with the difference being that, when the leaf LSRs send traffic on the LSP, the traffic is first delivered only to the root node and follows the upstream path from the leaf node to the root node. The root node then distributes the traffic on the P2MP tree to all of the leaf nodes. An HSMP LSP consists of a downstream path and upstream path. The downstream path is the same as P2MP LSP, while the upstream path is only from leaf to root node, without communication between the leaf nodes themselves. The transmission of packets from the root node of an HSMP LSP to the receivers (the leaf nodes) is identical to that of a P2MP LSP. Traffic from a leaf node to the root follows the upstream path that is the reverse of the path from the root to the leaf. Unlike an MP2MP LSP, traffic from a leaf node does not branch toward other leaf nodes, but it is sent direct to the root where it is placed on the P2MP path and distributed to all leaf nodes including the original sender. To set up the upstream path of an HSMP LSP, ordered mode MUST be used. Ordered mode can guarantee that a leaf will start sending packets to the root immediately after the upstream path is installed, without being dropped due to an incomplete LSP.

An HSMP LSP requires the LDP capabilities for nodes to indicate that they support setup of HSMP LSPs. An implementation supporting the HSMP LSP procedures specified in this document MUST implement the procedures for Capability Parameters in Initialization messages. Advertisement of the HSMP LSP Capability indicates support of the procedures for HSMP LSP setup. A new Capability Parameter TLV is defined, the HSMP LSP Capability Parameter. Below is the format of the HSMP LSP Capability Parameter.

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| HSMP LSP Cap (0x0902) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | +-+-+-+-+-+-+-+-+ Unknown TLV bit, as described in . The value MUST be 1. The unknown TLV MUST be silently ignored and the rest of the message processed as if the unknown TLV did not exist. Forward unknown TLV bit, as described in . The value of this bit MUST be 0 since a Capability Parameter TLV is sent only in Initialization and Capability messages, which are not forwarded. SHOULD be 1. As defined in Section 3 of . As defined in Section 3 of . 0x0902. If the peer has not advertised the corresponding capability, then label messages using the HSMP Forwarding Equivalence Class (FEC) Element SHOULD NOT be sent to the peer (as described in Section 2.1 of ). Since ordered mode is applied for HSMP LSP signaling, the label message break would ensure that the initiating leaf node is unable to establish the upstream path to root node.

We define two new protocol entities: the HSMP Downstream FEC Element and Upstream FEC Element. If a FEC TLV contains one of the HSMP FEC Elements, the HSMP FEC Element MUST be the only FEC Element in the FEC TLV. The structure, encoding, and error handling for the HSMP-downstream FEC Element and HSMP-upstream FEC Element are the same as for the P2MP FEC Element described in Section 2.2 of . The difference is that two additional new FEC types are defined: HSMP-downstream FEC (10) and HSMP-upstream FEC (9).

The entries in the list below describe the processing of the HSMP FEC Elements. Additionally, the entries defined in Section 3.3 of are also reused in the following sections. HSMP downstream LSP <X, Y> (or simply downstream <X, Y>): an HSMP LSP downstream path with root node address X and opaque value Y. HSMP upstream LSP <X, Y> (or simply upstream <X, Y>): an HSMP LSP upstream path for root node address X and opaque value Y that will be used by any downstream node to send traffic upstream to root node. HSMP-downstream FEC Element <X, Y>: a FEC Element with root node address X and opaque value Y used for a downstream HSMP LSP. HSMP-upstream FEC Element <X, Y>: a FEC Element with root node address X and opaque value Y used for an upstream HSMP LSP. HSMP-D Label Mapping <X, Y, L>: A Label Mapping message with a single HSMP-downstream FEC Element <X, Y> and label TLV with label L. Label L MUST be allocated from the per-platform label space of the LSR sending the Label Mapping Message. HSMP-U Label Mapping <X, Y, Lu>: A Label Mapping message with a single HSMP upstream FEC Element <X, Y> and label TLV with label Lu. Label Lu MUST be allocated from the per-platform label space of the LSR sending the Label Mapping Message. HSMP-D Label Withdraw <X, Y, L>: a Label Withdraw message with a FEC TLV with a single HSMP-downstream FEC Element <X, Y> and label TLV with label L. HSMP-U Label Withdraw <X, Y, Lu>: a Label Withdraw message with a FEC TLV with a single HSMP-upstream FEC Element <X, Y> and label TLV with label Lu. HSMP-D Label Release <X, Y, L>: a Label Release message with a FEC TLV with a single HSMP-downstream FEC Element <X, Y> and Label TLV with label L. HSMP-U Label Release <X, Y, Lu>: a Label Release message with a FEC TLV with a single HSMP-upstream FEC Element <X, Y> and label TLV with label Lu.

This section specifies the procedures for originating HSMP Label Mapping messages and processing received HSMP Label Mapping messages for a particular HSMP LSP. The procedure of a downstream HSMP LSP is similar to that of a downstream MP2MP LSP described in . When LDP operates in Ordered Label Distribution Control mode , the upstream LSP will be set up by sending an HSMP LSP LDP Label Mapping message with a label that is allocated by the upstream LSR to its downstream LSR hop-by-hop from root to leaf node, installing the upstream forwarding table by every node along the LSP. The detailed procedure of setting up upstream HSMP LSP is different than that of upstream MP2MP LSP, and it is specified in the remainder of this section. All labels discussed here are downstream-assigned except those that are assigned using the procedures described in . Determining the upstream LSR for the HSMP LSP <X, Y> follows the procedure for a P2MP LSP described in Section 2.4.1.1 of . That is, a node Z that wants to join an HSMP LSP <X, Y> determines the LDP peer U that is Z's next hop on the best path from Z to the root node X. If there are multiple upstream LSRs, a local algorithm should be applied to ensure that there is exactly one upstream LSR for a particular LSP. To determine one's HSMP downstream LSR, an upstream LDP peer that receives a Label Mapping with the HSMP-downstream FEC Element from an LDP peer D will treat D as HSMP downstream LDP peer.

The leaf node operation is much the same as the operation of MP2MP LSP defined in Section 3.3.1.4 of . The only difference is the FEC elements as specified below. A leaf node Z of an HSMP LSP <X, Y> determines its upstream LSR U for <X, Y> as per , allocates a label L, and sends an HSMP-D Label Mapping <X, Y, L> to U. Leaf node Z expects an HSMP-U Label Mapping <X, Y, Lu> from node U and checks whether it already has forwarding state for upstream <X, Y>. If not, Z creates forwarding state to push label Lu onto the traffic that Z wants to forward over the HSMP LSP. How it determines what traffic to forward on this HSMP LSP is outside the scope of this document.

The procedure for processing an HSMP-D Label Mapping message is much the same as that for an MP2MP-D Label Mapping message defined in Section 3.3.1.5 of . The processing of an HSMP-U Label Mapping message is different from that of an MP2MP-U Label Mapping message as specified below. Suppose node Z receives an HSMP-D Label Mapping <X, Y, L> from LSR D. Z checks whether it has forwarding state for downstream <X, Y>. If not, Z determines its upstream LSR U for <X, Y> as per . Using this Label Mapping to update the label forwarding table MUST NOT be done as long as LSR D is equal to LSR U. If LSR U is different from LSR D, Z will allocate a label L' and install downstream forwarding state to swap label L' with label L over interface I associated with LSR D and send an HSMP-D Label Mapping <X, Y, L'> to U. Interface I is determined via the procedures in . If Z already has forwarding state for downstream <X, Y>, all that Z needs to do in this case is check that LSR D is not equal to the upstream LSR of <X, Y> and update its forwarding state. Assuming its old forwarding state was L'-> {<I1, L1> <I2, L2> ..., <In, Ln>}, its new forwarding state becomes L'-> {<I1, L1> <I2, L2> ..., <In, Ln>, <I, L>}. If the LSR D is equal to the installed upstream LSR, the Label Mapping from LSR D MUST be retained and MUST NOT update the label forwarding table. Node Z checks if the upstream LSR U already has assigned a label Lu to upstream <X, Y>. If not, transit node Z waits until it receives an HSMP-U Label Mapping <X, Y, Lu> from LSR U. Once the HSMP-U Label Mapping is received from LSR U, node Z checks whether it already has forwarding state upstream <X, Y> with incoming label Lu' and outgoing label Lu. If it does not, it allocates a label Lu' and creates a new label swap for Lu' with Label Lu over interface Iu. Interface Iu is determined via the procedures in . Node Z determines the downstream HSMP LSR as per and sends an HSMP-U Label Mapping <X, Y, Lu'> to node D. Since a packet from any downstream node is forwarded only to the upstream node, the same label (representing the upstream path) SHOULD be distributed to all downstream nodes. This differs from the procedures for MP2MP LSPs , where a distinct label must be distributed to each downstream node. The forwarding state upstream <X, Y> on node Z will be like this: {<Lu'>, <Iu Lu>}. Iu means the upstream interface over which Z receives HSMP-U Label Map <X, Y, Lu> from LSR U. Packets from any downstream interface over which Z sends HSMP-U Label Map <X, Y, Lu'> with label Lu' will be forwarded to Iu with label Lu' swapped to Lu.

The procedure for an HSMP-D Label Mapping message is much the same as processing an MP2MP-D Label Mapping message defined in Section 3.3.1.6 of . The processing of an HSMP-U Label Mapping message is different from that of an MP2MP-U Label Mapping message as specified below. Suppose the root node Z receives an HSMP-D Label Mapping <X, Y, L> from node D. Z checks whether it already has forwarding state for downstream <X, Y>. If not, Z creates downstream forwarding state and installs an outgoing label L over interface I. Interface I is determined via the procedures in . If Z already has forwarding state for downstream <X, Y>, then Z will add label L over interface I to the existing state. Node Z checks if it has forwarding state for upstream <X, Y>. If not, Z creates a forwarding state for incoming label Lu' that indicates that Z is the HSMP LSP egress Label Edge Router (LER). For example, the forwarding state might specify that the label stack is popped and the packet passed to some specific application. Node Z determines the downstream HSMP LSR as per and sends an HSMP-U Label Map <X, Y, Lu'> to node D. Since Z is the root of the tree, Z will not send an HSMP-D Label Map and will not receive an HSMP-U Label Mapping. The root node could also be a leaf node, and it is able to determine what traffic to forward on this HSMP LSP; that determination is outside the scope of this document.

If a leaf node Z discovers that it has no need to be an Egress LSR for that LSP (by means outside the scope of this document), then it SHOULD send an HSMP-D Label Withdraw <X, Y, L> to its upstream LSR U for <X, Y>, where L is the label it had previously advertised to U for <X, Y>. Leaf node Z will also send an unsolicited HSMP-U Label Release <X, Y, Lu> to U to indicate that the upstream path is no longer used and that label Lu can be removed. Leaf node Z expects the upstream router U to respond by sending a downstream Label Release for L.

If a transit node Z receives an HSMP-D Label Withdraw message <X, Y, L> from node D, it deletes label L from its forwarding state downstream <X, Y>. Node Z sends an HSMP-D Label Release message with label L to D. There is no need to send an HSMP-U Label Withdraw <X, Y, Lu> to D because node D already removed Lu and sent a label release for Lu to Z. If deleting L from Z's forwarding state for downstream <X, Y> results in no state remaining for <X, Y>, then Z propagates the HSMP-D Label Withdraw <X, Y, L> to its upstream node U for <X, Y>. Z should also check if there are any incoming interfaces in forwarding state upstream <X, Y>. If all downstream nodes are released and there is no incoming interface, Z should delete the forwarding state upstream <X, Y> and send an HSMP-U Label Release message to its upstream node. Otherwise, no HSMP-U Label Release message will be sent to the upstream node.

When the root node of an HSMP LSP receives an HSMP-D Label Withdraw message and an HSMP-U Label Release message, the procedure is the same as that for transit nodes, except that the root node will not propagate the Label Withdraw and Label Release upstream (as it has no upstream).

The procedure for changing the upstream LSR is the same as defined in Section 2.4.3 of , only with different processing of the FEC Element. When the upstream LSR changes from U to U', node Z should set up the HSMP LSP <X, Y> to U' by applying the procedures in . Z will also remove the HSMP LSP <X, Y> to U by applying the procedure in . To set up an HSMP LSP to U' before/after removing the HSMP LSP to U is a local matter. The recommended default behavior is to remove before adding.

The upstream and downstream LSPs can be co-routed by applying the procedures below. Both LSR U and LSR D would ensure that the same interface sends traffic by applying some procedures. For a network with symmetric IGP cost configuration, the following procedure MAY be used. To determine the downstream interface, LSR U MUST do a lookup in the unicast routing table to find the best interface and next hop to reach LSR D. If the next hop and interface are also advertised by LSR D via the LDP session, it should be used to transmit the packet to LSR D. The mechanism to determine the upstream interface is the same as that used to determine the downstream interface except the roles of LSR U and LSR D are switched. If symmetric IGP cost could not be ensured, static route configuration on LSR U and D could also be a way to ensure a co-routed path. If a co-routed path is not required for the HSMP LSP, the procedure defined in Section 2.4.1.2 of could be applied. LSR U is free to transmit the packet on any of the interfaces to LSR D. The algorithm it uses to choose a particular interface is a local matter. The mechanism to determine the upstream interface is the same as that used to determine the downstream interface.