RFC 7140

LDP Extensions for Hub and Spoke Multipoint Label Switched Path

📅 published March 2014, from ietf

RFC 7140 💖 LDP Extensions for Hub and Spoke Multipoint Label Switched Path

Okay bestie, here's the title block first 🎀

  • Stream: Internet Engineering Task Force (IETF)
  • RFC number: 7140
  • Category: Standards Track
  • ISSN: 2070-1721
  • Date: March 2014
  • Authors: L. Jin, F. Jounay (Orange CH), IJ. Wijnands (Cisco Systems, Inc), N. Leymann (Deutsche Telekom AG)
  • Obsoletes / Updates: the header doesn't list anything this RFC obsoletes or updates 🤷‍♀️

Abstract ✨

Okay so this doc introduces a hub and spoke multipoint (HSMP) Label Switched Path (LSP) 🦋 It lets traffic go from the root to the leaves through point-to-multipoint (P2MP) LSPs, and it also lets traffic go from the leaves back to the root along the reverse path. When traffic enters the HSMP LSP at the root (from the application or customer sitting there), it heads downstream to every leaf node, exactly like it would if it were riding a P2MP LSP to each leaf. Upstream traffic that enters at any leaf node travels up the tree to the root, as if it were unicast to the root 💅 Direct communication among the leaf nodes is not allowed 🙈

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 give feedback on it can be found at http://www.rfc-editor.org/info/rfc7140 📚

Copyright (c) 2014 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) as they're in effect on the date this document was published. Please read these documents carefully, because they spell out 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 they are provided without warranty as described in the Simplified BSD License 🫶

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Setting Up HSMP LSP with LDP  . . . . . . . . . . . . . . . .   4
     3.1.  Support for HSMP LSP Setup with LDP . . . . . . . . . . .   4
     3.2.  HSMP FEC Elements . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Using the HSMP FEC Elements . . . . . . . . . . . . . . .   5
     3.4.  HSMP LSP Label Map  . . . . . . . . . . . . . . . . . . .   6
       3.4.1.  HSMP LSP Leaf Node Operation  . . . . . . . . . . . .   7
       3.4.2.  HSMP LSP Transit Node Operation . . . . . . . . . . .   7
       3.4.3.  HSMP LSP Root Node Operation  . . . . . . . . . . . .   8
     3.5.  HSMP LSP Label Withdraw . . . . . . . . . . . . . . . . .   9
       3.5.1.  HSMP Leaf Operation . . . . . . . . . . . . . . . . .   9
       3.5.2.  HSMP Transit Node Operation . . . . . . . . . . . . .   9
       3.5.3.  HSMP Root Node Operation  . . . . . . . . . . . . . .  10
     3.6.  HSMP LSP Upstream LSR Change  . . . . . . . . . . . . . .  10
     3.7.  Determining Forwarding Interface  . . . . . . . . . . . .  10
   4.  HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . .  11
   5.  Redundancy Considerations . . . . . . . . . . . . . . . . . .  11
   6.  Failure Detection of HSMP LSP . . . . . . . . . . . . . . . .  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     8.1.  New LDP FEC Element Types . . . . . . . . . . . . . . . .  12
     8.2.  HSMP LSP Capability TLV . . . . . . . . . . . . . . . . .  13
     8.3.  New Sub-TLVs for the Target Stack TLV . . . . . . . . . .  13
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     10.2.  Informative References . . . . . . . . . . . . . . . . .  14

1. Introduction 🧚

Okay so the point-to-multipoint (P2MP) Label Switched Path (LSP) defined in [RFC6388] lets traffic go from a root out to several leaf nodes, and multipoint-to-multipoint (MP2MP) LSP lets traffic go from every node to every other node 👑 This document introduces the hub and spoke multipoint (HSMP) LSP, which has exactly one root node and one or more leaf nodes ✨ An HSMP LSP lets traffic go from root to leaf through a downstream LSP, and also from leaf to root along an upstream LSP 🌈 So when traffic enters the HSMP LSP at the root node, it travels down the downstream LSP, just like it would on a P2MP LSP. When traffic enters the HSMP LSP at any other leaf node, it travels up the upstream LSP, but only toward the root node 💀 The upstream LSP should be thought of as a unicast LSP to the root node. The one twist is that it follows the reverse direction of the downstream LSP, instead of the unicast path that the routing protocol would pick 🦋 When you combine the upstream LSPs started at all the leaf nodes, you get a multipoint-to-point LSP 💜

2. Terminology 🎀

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 [RFC2119].

This document uses the following terms and acronyms 📖

  • mLDP: Multipoint extensions for Label Distribution Protocol (LDP), defined in [RFC6388].
  • P2MP LSP: point-to-multipoint Label Switched Path. An LSP that has one Ingress Label Switching Router (LSR) and one or more Egress LSRs.
  • MP2MP LSP: multipoint-to-multipoint Label Switched Path. An LSP that connects a set of nodes, such that traffic sent by any node in the LSP is delivered to all others.
  • HSMP LSP: hub and spoke multipoint Label Switched Path. An LSP that has one root node and one or more leaf nodes. It allows traffic from the root to all leaf nodes along the downstream P2MP LSP, and also allows leaf-to-root traffic along the upstream unicast LSP.
  • FEC: Forwarding Equivalence Class

3. Setting Up HSMP LSP with LDP 🌸

An HSMP LSP is kind of like an MP2MP LSP described in [RFC6388], with one big difference 💅 When the leaf LSRs send traffic on the LSP, that traffic is first delivered only to the root node, travelling along the upstream path from the leaf to the root. Then the root node pushes the traffic out on the P2MP tree to all of the leaf nodes.

An HSMP LSP has a downstream path and an upstream path. The downstream path is the same as a P2MP LSP. The upstream path only goes from a leaf to the root node, and there's no communication between the leaf nodes themselves 🙈 Sending packets from the root node of an HSMP LSP to the receivers (the leaf nodes) works exactly the same as it does for a P2MP LSP ✨ Traffic from a leaf node to the root follows the upstream path, which is the reverse of the path from the root to that leaf. Unlike an MP2MP LSP, traffic from a leaf node does not branch off toward other leaf nodes. It goes straight to the root, where it's 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 guarantees that a leaf will start sending packets to the root right after the upstream path is installed, so those packets won't get dropped because the LSP is still incomplete 🍓

3.1. Support for HSMP LSP Setup with LDP 🧁

An HSMP LSP requires the LDP capabilities [RFC5561] so that nodes can say they support HSMP LSP setup 💖 An implementation that supports the HSMP LSP procedures in this document MUST implement the procedures for Capability Parameters in Initialization messages. Advertising the HSMP LSP Capability means the node supports the procedures for HSMP LSP setup 🌈

There's a brand new Capability Parameter TLV, the HSMP LSP Capability Parameter 🎀 Here's what its format looks like:

    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   |
    +-+-+-+-+-+-+-+-+

Figure 1: HSMP LSP Capability Parameter Encoding

Here's the breakdown 🔍

  • U-bit: Unknown TLV bit, as described in [RFC5036]. The value MUST be 1. The unknown TLV MUST be silently ignored, and the rest of the message gets processed as if that unknown TLV didn't exist 🙃
  • F-bit: Forward unknown TLV bit, as described in [RFC5036]. The value of this bit MUST be 0, since a Capability Parameter TLV is only sent in Initialization and Capability messages, and those aren't forwarded 🚫
  • Length: SHOULD be 1.
  • S-bit: As defined in Section 3 of [RFC5561].
  • Reserved: As defined in Section 3 of [RFC5561].
  • HSMP LSP Capability Parameter type: 0x0902.
If the peer hasn't advertised the matching capability, then label messages that use the HSMP Forwarding Equivalence Class (FEC) Element SHOULD NOT be sent to that peer (as described in Section 2.1 of [RFC6388]). Ordered mode is applied for HSMP LSP signaling, so that label message break means the initiating leaf node can't set up the upstream path to the root node 😭

3.2. HSMP FEC Elements 🦋

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

3.3. Using the HSMP FEC Elements ✨

okay so this list is basically the cheat sheet for every HSMP FEC Element and message 🧚 the entries below describe how the HSMP FEC Elements get processed. bestie, the entries defined in Section 3.3 of [RFC6388] are also reused in the following sections, so keep that in mind 💜

  1. HSMP downstream LSP <X, Y> (or simply downstream <X, Y>): an HSMP LSP downstream path with root node address X and opaque value Y 🌸
  2. 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 any downstream node will use to send traffic upstream to the root node 🦋
  3. HSMP-downstream FEC Element <X, Y>: a FEC Element with root node address X and opaque value Y, used for a downstream HSMP LSP 🎀
  4. HSMP-upstream FEC Element <X, Y>: a FEC Element with root node address X and opaque value Y, used for an upstream HSMP LSP 🎀
  5. 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. 🔥

Wait, I need to be careful here. The capitalised key word is MUST, and it has to appear in capitals exactly as the original states. So the correct line is:

  1. 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. 🔥
  2. 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. 🔥
  3. HSMP-D Label Withdraw <X, Y, L>: a Label Withdraw message with a FEC TLV containing a single HSMP-downstream FEC Element <X, Y> and label TLV with label L. 🍓
  4. HSMP-U Label Withdraw <X, Y, Lu>: a Label Withdraw message with a FEC TLV containing a single HSMP-upstream FEC Element <X, Y> and label TLV with label Lu. 🍓
  5. HSMP-D Label Release <X, Y, L>: a Label Release message with a FEC TLV containing a single HSMP-downstream FEC Element <X, Y> and Label TLV with label L. 💜
  6. HSMP-U Label Release <X, Y, Lu>: a Label Release message with a FEC TLV containing a single HSMP-upstream FEC Element <X, Y> and label TLV with label Lu. 💜

3.4. HSMP LSP Label Map 🌈

this section is the procedures bit: how you originate HSMP Label Mapping messages and how you process the ones you receive for a particular HSMP LSP 🫶 the downstream HSMP LSP procedure is pretty similar to the downstream MP2MP LSP one in [RFC6388]. when LDP runs in Ordered Label Distribution Control mode [RFC5036], the upstream LSP gets set up by sending an HSMP LSP LDP Label Mapping message carrying a label that the upstream LSR allocates for its downstream LSR hop-by-hop, from root to leaf node. every node along the LSP installs the upstream forwarding table as it goes 🦋

the detailed procedure for setting up an upstream HSMP LSP is different from the upstream MP2MP LSP one, and it's spelled out in the rest of this section 💅

all labels discussed here are downstream-assigned [RFC5332], except the ones assigned using the procedures described in Section 4. 🧚

determining the upstream LSR for the HSMP LSP <X, Y> follows the P2MP LSP procedure in Section 2.4.1.1 of [RFC6388]. so a node Z that wants to join an HSMP LSP <X, Y> figures out 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 make sure there's exactly one upstream LSR for a particular LSP. 🌸

to figure out 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 treats D as its HSMP downstream LDP peer. 🎀

3.4.1. HSMP LSP Leaf Node Operation 🍓

the leaf node operation is basically the same as the MP2MP LSP operation in Section 3.3.1.4 of [RFC6388]. the only difference is the FEC elements, as described below 💖

a leaf node Z of an HSMP LSP <X, Y> determines its upstream LSR U for <X, Y> as per Section 3.3, allocates a label L, and sends an HSMP-D Label Mapping <X, Y, L> to U. Leaf node Z then 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 it doesn't, Z creates forwarding state to push label Lu onto the traffic that Z wants to forward over the HSMP LSP. how Z decides which traffic goes over this HSMP LSP is outside the scope of this document 🤷‍♀️

3.4.2. HSMP LSP Transit Node Operation 🦋

processing an HSMP-D Label Mapping message is much the same as processing an MP2MP-D Label Mapping message, as defined in Section 3.3.1.5 of [RFC6388]. processing an HSMP-U Label Mapping message is different from 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 Section 3.3. 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 allocates a label L' and installs downstream forwarding state to swap label L' with label L over interface I associated with LSR D, then sends an HSMP-D Label Mapping <X, Y, L'> to U. interface I is determined via the procedures in Section 3.7. 💜

if Z already has forwarding state for downstream <X, Y>, all Z needs to do here 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 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 whether the upstream LSR U has already 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 Z gets that HSMP-U Label Mapping from LSR U, it checks whether it already has forwarding state upstream <X, Y> with incoming label Lu' and outgoing label Lu. if it doesn't, 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 Section 3.7. node Z then determines the downstream HSMP LSR as per Section 3.4, and sends an HSMP-U Label Mapping <X, Y, Lu'> to node D. 🎀

because a packet from any downstream node is only forwarded to the upstream node, the same label (representing the upstream path) SHOULD be distributed to all downstream nodes. this is different from MP2MP LSPs [RFC6388], where a distinct label must be distributed to each downstream node 🧠 the forwarding state upstream <X, Y> on node Z will look like this: {<Lu'>, <Iu Lu>}. Iu means the upstream interface over which Z receives the HSMP-U Label Map <X, Y, Lu> from LSR U. packets from any downstream interface over which Z sends the HSMP-U Label Map <X, Y, Lu'> with label Lu' get forwarded to Iu, with label Lu' swapped to Lu. ✨

3.4.3. HSMP LSP Root Node Operation 👑

processing an HSMP-D Label Mapping message is much the same as processing an MP2MP-D Label Mapping message, as defined in Section 3.3.1.6 of [RFC6388]. processing an HSMP-U Label Mapping message is different from 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 Section 3.7. if Z already has forwarding state for downstream <X, Y>, then Z adds label L over interface I to the existing state. 🦋

node Z checks whether it has forwarding state for upstream <X, Y>. if not, Z creates forwarding state for incoming label Lu' that indicates 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 is passed to some specific application. node Z determines the downstream HSMP LSR as per Section 3.3, 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 can determine what traffic to forward on this HSMP LSP. that determination is outside the scope of this document. 🧚

3.5. HSMP LSP Label Withdraw 🍓

3.5.1. HSMP Leaf Operation 🙈

if a leaf node Z discovers 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 say the upstream path is no longer used and label Lu can be removed. 💔

leaf node Z expects the upstream router U to respond by sending a downstream Label Release for L. 🫶

3.5.2. HSMP Transit Node Operation 🦋

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's 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> leaves no state at all 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 whether there are any incoming interfaces in the 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 gets sent to the upstream node. 💅

3.5.3. HSMP Root Node Operation 👑

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 for transit nodes, except that the root node won't propagate the Label Withdraw and Label Release upstream (since it has no upstream) 🌟

3.6. HSMP LSP Upstream LSR Change 🦋

the procedure for changing the upstream LSR is the same as the one defined in Section 2.4.3 of [RFC6388], just 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 Section 3.4. Z will also remove the HSMP LSP <X, Y> to U by applying the procedure in Section 3.5. 🔥

setting up an HSMP LSP to U' before or after removing the HSMP LSP to U is a local matter. the recommended default behavior is to remove before adding. 🌸

3.7. Determining Forwarding Interface ✨

okay so this bit is all about making sure LSR U and LSR D send traffic out the same interface, aka co-routed 🦋 The upstream and downstream LSPs can be co-routed by applying the procedures below, and both LSR U and LSR D have to use some procedures to make sure the same interface is doing the sending 💅 For a network with symmetric IGP cost configuration, the following procedure MAY be used. To figure out 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 that 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 upstream interface is found the same way as the downstream one, except the roles of LSR U and LSR D are switched 🔄 If symmetric IGP cost couldn't 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 [RFC6388] could be applied. LSR U is free to transmit the packet on any of the interfaces to LSR D, and the algorithm it uses to pick one is a local matter 🫶

The mechanism to determine the upstream interface is the same as that used to determine the downstream interface. (yes, we're saying it twice, it's important 😭)

4. HSMP LSP on a LAN 🌈

bestie, the way the downstream HSMP LSP gets processed on a LAN is basically the same as a downstream MP2MP LSP, see Section 6.1.1 of [RFC6388] 💜

When establishing the downstream path of an HSMP LSP, as defined in [RFC6389], a Label Request message for an LSP label is sent to the upstream LSR. The upstream LSR should send a Label Mapping message that contains the LSP label for the downstream HSMP FEC and the upstream LSR context label defined in [RFC5331]. When the LSR forwards a packet downstream on one of those LSPs, the packet's top label must be the "upstream LSR context label" and the packet's second label is the "LSP label" ✨ The HSMP downstream path gets installed in the context-specific forwarding table that corresponds to the upstream LSR label. Packets sent by the upstream LSR can then be forwarded downstream using this forwarding state, based on a two-label lookup 🧚

The upstream path of an HSMP LSP on a LAN is the same as on other kinds of links. That means the upstream LSR must send a Label Mapping message that contains the LSP label for the upstream HSMP FEC to the downstream node. Packets traveling upstream need to be forwarded in the direction of the root, using the label allocated for the upstream HSMP FEC 🍓

5. Redundancy Considerations 👑

in some scenarios you need two root nodes for redundancy, and one way to do that is two independent HSMP LSPs acting as active and standby 🎀 Only one HSMP LSP is active at a given time, and the other one is standby. After the active HSMP LSP fails, the root and leaf nodes switch the traffic over to the standby HSMP LSP, which takes on the role of active HSMP LSP 🔥 The details of the redundancy mechanism are out of scope for this document, so that's a whole other story 🙈

6. Failure Detection of HSMP LSP 💀

the idea behind LSP ping for HSMP LSPs is basically a test: LSP Ping Echo Request packets enter at the root, go down a particular downstream path of the HSMP LSP, and end their MPLS path on the leaf. The leaf node then sends the LSP Ping Echo Reply back along the upstream path of the HSMP LSP, and it ends on the root, which is the (intended) root node 🦋

IANA has assigned new sub-TLVs in the Target FEC Stack TLV and the Reverse-path Target FEC Stack TLV, to define the matching HSMP-downstream FEC type and HSMP-upstream FEC type. To make sure the leaf node sends the LSP Ping Echo Reply along the HSMP upstream path, the R flag (Validate Reverse Path) in the Global Flags field defined in [RFC6426] gets reused here 🧠

The node-processing mechanism of LSP Ping Echo Request and Echo Reply for the HSMP LSP is inherited from [RFC6425] and Section 3.4 of [RFC6426], except for the following:

  1. The root node sending the LSP Ping Echo Request message for the HSMP LSP MUST attach the Target FEC Stack TLV with the HSMP-downstream FEC type, and set the R flag to '1' in the Global Flags field.
  2. When the leaf node receives the LSP Ping Echo Request, it MUST send the LSP Ping Echo Reply to the associated HSMP upstream path. The Reverse-path Target FEC Stack TLV attached by the leaf node in the Echo Reply message SHOULD contain the sub-TLV of the associated HSMP-upstream FEC 💖

7. Security Considerations 🔐

the same security considerations apply as for the MP2MP LSP described in [RFC6388] and [RFC6425], so no sneaky new vibes here 😌

Although this document introduces new FEC Elements and corresponding procedures, the protocol does not bring any new security issues beyond those in [RFC6388] and [RFC6425]. ngl that's a relief 🫶

8. IANA Considerations 📋

8.1. New LDP FEC Element Types

two new LDP FEC Element types were allocated from the "Label Distribution Protocol (LDP) Parameters" registry, under "Forwarding Equivalence Class (FEC) Type Name Space" 💜

  1. the HSMP-upstream FEC type - 9
  2. the HSMP-downstream FEC type - 10

the values were allocated from the "IETF Consensus" [RFC5226] range (0-127) ✨

8.2. HSMP LSP Capability TLV

one new code point was allocated for the HSMP LSP capability TLV from the "Label Distribution Protocol (LDP) Parameters" registry, under "TLV Type Name Space":

HSMP LSP Capability Parameter - 0x0902

the value was allocated from the "IETF Consensus" range (0x0901-0x3DFF) 🎀

8.3. New Sub-TLVs for the Target Stack TLV

two new sub-TLV types were allocated for inclusion within the LSP ping [RFC4379] Target FEC Stack TLV (TLV type 1), Reverse-path Target FEC Stack TLV (TLV type 16), and Reply Path TLV (TLV type 21) 🦋

  • the HSMP-upstream LDP FEC Stack - 29
  • the HSMP-downstream LDP FEC Stack - 30

the value was allocated from the "IETF Standards Action" range (0-16383), which is used for mandatory and optional sub-TLVs that require a response if not understood 🌈

9. Acknowledgements 🫶

the author would like to thank Eric Rosen, Sebastien Jobert, Fei Su, Edward, Mach Chen, Thomas Morin, and Loa Andersson for their valuable comments. the whole squad 👑

10. References 📚

10.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC5331]  Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
           Label Assignment and Context-Specific Label Space", RFC
           5331, August 2008.

[RFC5332]  Eckert, T., Rosen, E., Aggarwal, R., and Y. Rekhter, "MPLS
           Multicast Encapsulations", RFC 5332, August 2008.

[RFC5561]  Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
           Le Roux, "LDP Capabilities", RFC 5561, July 2009.

[RFC6388]  Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
           "Label Distribution Protocol Extensions for Point-to-
           Multipoint and Multipoint-to-Multipoint Label Switched
           Paths", RFC 6388, November 2011.

[RFC6389]  Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label
           Assignment for LDP", RFC 6389, November 2011.

[RFC6425]  Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa,
           S., and T. Nadeau, "Detecting Data-Plane Failures in
           Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC
           6425, November 2011.

[RFC6426]  Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
           On-Demand Connectivity Verification and Route Tracing",
           RFC 6426, November 2011.

10.2. Informative References

[RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
           Label Switched (MPLS) Data Plane Failures", RFC 4379,
           February 2006.

[RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
           Specification", RFC 5036, October 2007.

[RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
           IANA Considerations Section in RFCs", BCP 26, RFC 5226,
           May 2008.

Authors' Addresses 💌

Lizhong Jin
Shanghai
China

EMail: lizho.jin@gmail.com


Frederic Jounay
Orange CH
4 rue du Caudray
1007 Lausanne
Switzerland

EMail: frederic.jounay@orange.ch


IJsbrand Wijnands
Cisco Systems, Inc
De kleetlaan 6a
Diegem  1831
Belgium

EMail: ice@cisco.com


Nicolai Leymann
Deutsche Telekom AG
Winterfeldtstrasse 21
Berlin  10781
Germany

EMail: N.Leymann@telekom.de
📦 where this page comes from