diff options
Diffstat (limited to 'doc/rfc/rfc7140.txt')
| -rw-r--r-- | doc/rfc/rfc7140.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc7140.txt b/doc/rfc/rfc7140.txt new file mode 100644 index 0000000..c7ecf85 --- /dev/null +++ b/doc/rfc/rfc7140.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Jin +Request for Comments: 7140 +Category: Standards Track F. Jounay +ISSN: 2070-1721 Orange CH + IJ. Wijnands + Cisco Systems, Inc + N. Leymann + Deutsche Telekom AG + March 2014 + + + LDP Extensions for Hub and Spoke Multipoint Label Switched Path + +Abstract + + 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. + +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 provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7140. + + + + + + + + + + + + +Jin, et al. Standards Track [Page 1] + +RFC 7140 LDP Extensions for HSMP LSP March 2014 + + +Copyright Notice + + 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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe 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 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 + + + + + + +Jin, et al. Standards Track [Page 2] + +RFC 7140 LDP Extensions for HSMP LSP March 2014 + + +1. Introduction + + The point-to-multipoint (P2MP) Label Switched Path (LSP) defined in + [RFC6388] allows traffic to transmit from root to several leaf nodes, + and multipoint-to-multipoint (MP2MP) LSP allows traffic from every + node to transmit to every other node. This document introduces a hub + and spoke multipoint (HSMP) LSP, which has one root node and one or + more leaf nodes. An HSMP LSP allows traffic from root to leaf + through downstream LSP and also leaf to root along the upstream LSP. + That means traffic entering the HSMP LSP at the root node travels + along the downstream LSP, exactly as if it were traveling along a + P2MP LSP, and traffic entering the HSMP LSP at any other leaf nodes + travels along the upstream LSP toward only the root node. The + upstream LSP should be thought of as a unicast LSP to the root node, + except that it follows the reverse direction of the downstream LSP, + rather than the unicast path based on the routing protocol. The + combination of upstream LSPs initiated from all leaf nodes forms 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, allows traffic + from the root to all leaf nodes along the downstream P2MP LSP and + also leaf to root node along the upstream unicast LSP. + + FEC: Forwarding Equivalence Class + + + + + + + +Jin, et al. Standards Track [Page 3] + +RFC 7140 LDP Extensions for HSMP LSP March 2014 + + +3. Setting Up HSMP LSP with LDP + + An HSMP LSP is similar to MP2MP LSP described in [RFC6388], 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. + +3.1. Support for HSMP LSP Setup with LDP + + An HSMP LSP requires the LDP capabilities [RFC5561] 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 | + +-+-+-+-+-+-+-+-+ + + Figure 1: HSMP LSP Capability Parameter Encoding + + + + +Jin, et al. Standards Track [Page 4] + +RFC 7140 LDP Extensions for HSMP LSP March 2014 + + + 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 processed as if the unknown TLV did not 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 sent only in Initialization and Capability messages, which + are not 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 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 [RFC6388]). 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. + +3.2. HSMP FEC Elements + + 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 [RFC6388]. The + difference is that two additional new FEC types are defined: HSMP- + downstream FEC (10) and HSMP-upstream FEC (9). + +3.3. Using the HSMP FEC Elements + + The entries in the list below describe the processing of the HSMP FEC + Elements. Additionally, the entries defined in Section 3.3 of + [RFC6388] are also reused in the following sections. + + 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. + + + + + + + +Jin, et al. Standards Track [Page 5] + +RFC 7140 LDP Extensions for HSMP LSP March 2014 + + + 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 will be used by any downstream node to send traffic + upstream to 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. + + 6. 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. + + 7. 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. + + 8. 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. + + 9. 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. + + 10. 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. + +3.4. HSMP LSP Label Map + + 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 [RFC6388]. + When LDP operates in Ordered Label Distribution Control mode + [RFC5036], 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. + + + +Jin, et al. Standards Track [Page 6] + +RFC 7140 LDP Extensions for HSMP LSP March 2014 + + + 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 [RFC5332] except + those that are assigned using the procedures described in Section 4. + + 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 [RFC6388]. + 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. + +3.4.1. HSMP LSP Leaf Node Operation + + The leaf node operation is much the same as the operation of MP2MP + LSP defined in Section 3.3.1.4 of [RFC6388]. 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 Section 3.3, 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. + +3.4.2. HSMP LSP Transit Node Operation + + 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 [RFC6388]. 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 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 will allocate a label L' and install + + + +Jin, et al. Standards Track [Page 7] + +RFC 7140 LDP Extensions for HSMP LSP March 2014 + + + 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 + Section 3.7. + + 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 Section 3.7. Node Z determines the + downstream HSMP LSR as per Section 3.4 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 [RFC6388], 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. + +3.4.3. HSMP LSP Root Node Operation + + 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 [RFC6388]. 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 + + + +Jin, et al. Standards Track [Page 8] + +RFC 7140 LDP Extensions for HSMP LSP March 2014 + + + determined via the procedures in Section 3.7. 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 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 is able to 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 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. + +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 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 + + + +Jin, et al. Standards Track [Page 9] + +RFC 7140 LDP Extensions for HSMP LSP March 2014 + + + 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. + +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 that for transit nodes, except that the root node will not + propagate the Label Withdraw and Label Release upstream (as it has no + upstream). + +3.6. HSMP LSP Upstream LSR Change + + The procedure for changing the upstream LSR is the same as defined in + Section 2.4.3 of [RFC6388], 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 Section 3.4. Z + will also remove the HSMP LSP <X, Y> to U by applying the procedure + in Section 3.5. + + 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. + +3.7. Determining Forwarding Interface + + 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 [RFC6388] 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. + + + +Jin, et al. Standards Track [Page 10] + +RFC 7140 LDP Extensions for HSMP LSP March 2014 + + + The mechanism to determine the upstream interface is the same as that + used to determine the downstream interface. + +4. HSMP LSP on a LAN + + The procedure to process the downstream HSMP LSP on a LAN is much the + same as for a downstream MP2MP LSP as described in 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 will be + installed in the context-specific forwarding table corresponding to + the upstream LSR label. Packets sent by the upstream LSR can 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 the one on + other kinds of links. That is, 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 by using the label allocated + for the upstream HSMP FEC. + +5. Redundancy Considerations + + In some scenarios, it is necessary to provide two root nodes for + redundancy purposes. One way to implement this is to use two + independent HSMP LSPs acting as active and standby. At a given time, + only one HSMP LSP will be active; the other will be standby. After + detecting the failure of the active HSMP LSP, the root and leaf nodes + will switch the traffic to the standby HSMP LSP, which takes on the + role as active HSMP LSP. The details of the redundancy mechanism are + out of the scope of this document. + +6. Failure Detection of HSMP LSP + + The idea of LSP ping for HSMP LSPs could be expressed as an intention + to test the LSP Ping Echo Request packets that enter at the root + along a particular downstream path of HSMP LSP and that end their + MPLS path on the leaf. The leaf node then sends the LSP Ping Echo + Reply along the upstream path of HSMP LSP, and it ends on the root + that is the (intended) root node. + + + +Jin, et al. Standards Track [Page 11] + +RFC 7140 LDP Extensions for HSMP LSP March 2014 + + + New sub-TLVs have been assigned by IANA in Target FEC Stack TLV and + Reverse-path Target FEC Stack TLV to define the corresponding HSMP- + downstream FEC type and HSMP-upstream FEC type. In order to ensure + that 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] is 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]. + + 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]. + +8. IANA Considerations + +8.1. New LDP FEC Element Types + + Two new LDP FEC Element types have been 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 have been allocated from the "IETF Consensus" [RFC5226] + range (0-127). + + + + + + +Jin, et al. Standards Track [Page 12] + +RFC 7140 LDP Extensions for HSMP LSP March 2014 + + +8.2. HSMP LSP Capability TLV + + One new code point has been allocated for the HSMP LSP capability TLV + from "Label Distribution Protocol (LDP) Parameters" registry, under + "TLV Type Name Space": + + HSMP LSP Capability Parameter - 0x0902 + + The value has been allocated from the"IETF Consensus" range + (0x0901-0x3DFF). + +8.3. New Sub-TLVs for the Target Stack TLV + + Two new sub-TLV types have been 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). + + o the HSMP-upstream LDP FEC Stack - 29 + + o the HSMP-downstream LDP FEC Stack - 30 + + The value has been allocated from the "IETF Standards Action" range + (0-16383) that is used for mandatory and optional sub-TLVs that + requires 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. + + + + + + + + + + + + + + + + + + + + + +Jin, et al. Standards Track [Page 13] + +RFC 7140 LDP Extensions for HSMP LSP March 2014 + + +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. + + + + + +Jin, et al. Standards Track [Page 14] + +RFC 7140 LDP Extensions for HSMP LSP March 2014 + + +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 + + + + + + + + + + + + + + + + + +Jin, et al. Standards Track [Page 15] + |