Network Working Group
Internet Engineering Task Force (IETF)                            L. Jin
Internet-Draft
Intended status:
Request for Comments: 7140
Category: Standards Track                                      F. Jounay
Expires: July 2, 2014                                     France Telecom
                                                             I.
ISSN: 2070-1721                                                Orange CH
                                                            IJ. Wijnands
                                                      Cisco Systems, Inc
                                                              N. Leymann
                                                     Deutsche Telekom AG
                                                       December 29, 2013
                                                           February 2014

    LDP Extensions for Hub & and Spoke Multipoint Label Switched Path
                    draft-ietf-mpls-mldp-hsmp-06.txt

Abstract

   This draft document introduces a hub & and spoke multipoint (HSMP) Label
   Switched Path (LSP), which allows traffic both from root to leaf through
   point-to-multipoint (P2MP) LSP 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 is travelling 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 is were
   unicast to the root.  Direct communication among the leaf nodes is
   not allowed.

Requirements Language

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

Status of this This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum 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 six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
   This Internet-Draft will expire on July 2, 2014.
   http://www.rfc-editor.org/info/rfc7140.

Copyright Notice

   Copyright (c) 2013 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  . . . . . . . . . . . . . . . . . . . . . . . . .  4   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  4   3
   3.  Setting up Up HSMP LSP with LDP  . . . . . . . . . . . . . . . . .  5   4
     3.1.  Support for HSMP LSP Setup with LDP . . . . . . . . . . .  5   4
     3.2.  HSMP FEC Elements . . . . . . . . . . . . . . . . . . . .  6   5
     3.3.  Using the HSMP FEC Elements . . . . . . . . . . . . . . .  6   5
     3.4.  HSMP LSP Label Map  . . . . . . . . . . . . . . . . . . . .  7   6
       3.4.1.  HSMP LSP Leaf Node Operation  . . . . . . . . . . . . .  8   7
       3.4.2.  HSMP LSP Transit Node Operation . . . . . . . . . . .  8   7
       3.4.3.  HSMP LSP Root Node Operation  . . . . . . . . . . . . .  9   8
     3.5.  HSMP LSP Label Withdraw . . . . . . . . . . . . . . . . . 10   9
       3.5.1.  HSMP Leaf Operation . . . . . . . . . . . . . . . . . 10   9
       3.5.2.  HSMP Transit Node Operation . . . . . . . . . . . . . 10   9
       3.5.3.  HSMP Root Node Operation  . . . . . . . . . . . . . . .  10
     3.6.  HSMP LSP Upstream LSR Change  . . . . . . . . . . . . . . . 11  10
     3.7.  Determining Forwarding Interface  . . . . . . . . . . . . . 11  10
   4.  HSMP LSP on a LAN . . . . . . . . . . . . . . . . . . . . . .  11
   5.  Redundancy Considerations . . . . . . . . . . . . . . . . . . 12  11
   6.  Failure Detection of HSMP LSP . . . . . . . . . . . . . . . . 12  11
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . 13  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13  12
     8.1.  New LDP FEC Element types Types . . . . . . . . . . . . . . . . 13  12
     8.2.  HSMP LSP capability Capability TLV . . . . . . . . . . . . . . . . .  13
     8.3.  New sub-TLVs Sub-TLVs for the Target Stack TLV . . . . . . . . . . 14  13
   9.  Acknowledgement  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 14  13
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . .  14
     10.1.  Normative references . References . . . . . . . . . . . . . . . . . .  14
     10.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15  14

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 draft 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 both 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 is travelling 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 routing protocol
   based the unicast path. 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 some the following terms and acronyms as follows: 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

3.  Setting up 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 and leaf
   nodes.
   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 to 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.
   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.  Following  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(TBD IANA) Cap (0x0902)     |           Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |S|  Reserved   |
    +-+-+-+-+-+-+-+-+

             Figure 1. 1: HSMP LSP Capability Parameter encoding Encoding
   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.

   The length

   Length: SHOULD be 1, and the S bit and reserved bits are 1.

   S-bit:  As defined in [RFC5561] section 3.

   The Section 3 of [RFC5561].

   Reserved:  As defined in Section 3 of [RFC5561].

   HSMP LSP Capability Parameter type is to be assigned by IANA. type:  0x0902.

   If the peer has not advertised the corresponding capability, then
   label messages using the HSMP Forwarding Equivalence Class (FEC)
   Element SHOULD NOT (as described in [RFC6388] section 2.1) be sent to the peer. peer (as described in Section 2.1
   of [RFC6388]).  Since ordered mode is applied for HSMP LSP signalling, 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

   Similar as MP2MP LSP, we

   We define two new protocol entities, 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 encoding, and error handling for the HSMP Downstream HSMP-
   downstream FEC Element and Upstream HSMP-upstream FEC Element are the same as
   for the P2MP FEC Element described in
   [RFC6388] Section 2.2. 2.2 of [RFC6388].  The
   difference is that two additional new FEC types are defined: HSMP Downstream HSMP-
   downstream FEC (to be assigned by IANA) (10) and
   HSMP Upstream HSMP-upstream FEC (to be assigned by IANA). (9).

3.3.  Using the HSMP FEC Elements

   In order to describe the message processing clearly, the

   The entries in the list below define describe the processing of the HSMP FEC
   Elements.  Additionally, the entries defined in [RFC6388] section 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.

   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 which
        that will be used by any of downstream node to send traffic
        upstream to root node.

   3.  HSMP downstream   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   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 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 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 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 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 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 as 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 which that is allocated by the upstream
   LSR to its downstream LSR hop by hop hop-by-hop from root to leaf node,
   installing the upstream forwarding table by every node along the LSP.

   The detail detailed procedure of setting up upstream HSMP LSP is different with
   than that of upstream MP2MP LSP, and it is specified in below the remainder
   of this section.

   All labels discussed here are downstream-assigned [RFC5332] except
   those which 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 [RFC6388] Section 2.4.1.1. 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 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 a single exactly one upstream LSRs LSR
   for a particular LSP.

   To determining determine one's HSMP downstream LSR, an upstream LDP peer which that
   receives a Label Mapping with HSMP downstream 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 [RFC6388] Section 3.3.1.4. 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 of for processing an HSMP-D Label Mapping message is much
   the same as
   processing that for an MP2MP-D Label Mapping message defined in [RFC6388]
   Section
   3.3.1.5. 3.3.1.5 of [RFC6388].  The processing of an HSMP-U Label
   Mapping message is different
   with 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
   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 4.3.1, 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 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' swap swapped to Lu.

3.4.3.  HSMP LSP Root Node Operation

   The procedure of for an HSMP-D Label Mapping message is much the same as
   processing an MP2MP-D Label Mapping message defined in [RFC6388]
   Section
   3.3.1.6. 3.3.1.6 of [RFC6388].  The processing of an HSMP-U Label
   Mapping message is different
   with 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 a 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 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 LER.  E.g., 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, 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.

   Root

   The root node could also be a leaf node, and it is able to determine
   what traffic to forward on this HSMP LSP which 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>. <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 interface 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.

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
   [RFC6388]
   Section 2.4.3, 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, and the matter.  The recommended default behavior is to remove
   before adding.

3.7.  Determining Forwarding Interface

   The co-routed path between upstream and downstream LSP would LSPs can be
   achieved for HSMP LSP. co-routed by applying the
   procedures below.  Both LSR U and LSR D would ensure that the same
   interface to send 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 next hop
   to reach LSR D.  If the next-hop 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. Determine  The mechanism to determine the upstream interface mechanism is the
   same as
   determining that used to determine the downstream interface by exchanging except the role
   roles of LSR U and LSR D. D are switched.  If symmetric IGP cost could
   not be ensured, static route configuration on LSR U and D could also
   be a possible way to ensure a co-routed path.

   If a co-routed path is not required for the HSMP LSP, the procedure
   defined in
   [RFC6388] 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.
   Determine

   The mechanism to determine the upstream interface mechanism is the same as determining 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 [RFC6388] section 6.1.1. 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", 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 kind 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 travelling 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 purpose. purposes.  One way to implement this is to use two
   independent HSMP LSPs acting as active/standby. active and standby.  At one a given time,
   only one HSMP LSP will be active, and 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 LSP, which takes on the
   role as active HSMP LSP.  The detail details of the redundancy mechanism is are
   out of the scope. 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, 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 end it ends on the root
   that are is the (intended) root node.

   New sub-TLVs are required to be have been assigned by IANA in Target FEC Stack TLV and
   Reverse-path Target FEC Stack TLV to define the corresponding
   HSMP-downstream HSMP-
   downstream FEC type and HSMP-upstream FEC type.  In order to ensure
   that the leaf node to send sends the LSP Ping Echo Reply along the HSMP
   upstream path, the R bit flag (Validate Reverse Path) in the Global Flags
   Field
   field defined in [RFC6426] is reused here.

   The node processing node-processing mechanism of LSP Ping Echo Request and Echo Reply
   for the HSMP LSP is inherited from [RFC6425] and [RFC6426] Section 3.4, 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 HSMP the HSMP-
       downstream FEC, FEC type, and set the R bit flag to '1' in the Global
       Flags Field. field.

   2.  When the leaf node receiving 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 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
   compared to
   beyond those in [RFC6388] and [RFC6425].

8.  IANA Considerations

8.1.  New LDP FEC Element types

   This document requires allocation of two Types

   Two new LDP FEC Element types have been allocated from the "Label
   Distribution Protocol (LDP) Parameters registry" the Parameters" registry, under "Forwarding
   Equivalence Class (FEC) Type Name Space":

   1.  the HSMP-upstream FEC type - requested value TBD 9

   2.  the HSMP-downstream FEC type - requested value TBD 10

   The values should be have been allocated using the lowest free values from the "IETF Consensus"-range Consensus" [RFC5226]
   range (0-127).

8.2.  HSMP LSP capability Capability TLV

   This document requires allocation of one

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

   HSMP LSP Capability Parameter - requested value TBD 0x0902

   The value should be has been allocated from the the"IETF Consensus" range 0x0901-0x3DFF (IETF
   Consensus) using the first free value within this range.
   (0x0901-0x3DFF).

8.3.  New sub-TLVs Sub-TLVs for the Target Stack TLV

   This document requires allocation of two

   Two new sub-TLV types have been allocated for inclusion within the
   LSP ping [RFC4379] Target FEC Stack TLV (TLV type 1) and 1), Reverse-path
   Target FEC Stack TLV (TLV type 16).

   1. 16), and Reply Path TLV (TLV type 21).

   o  the HSMP-upstream LDP FEC Stack - requested value TBD

   2. 29

   o  the HSMP-downstream LDP FEC Stack - requested value TBD 30

   The value should be has been allocated from the IETF "IETF Standards Action Action" range
   (0-16383) that is used for mandatory and optional sub-TLVs that
   requires a response if not understood.  The value should be allocated
   using the lowest free value within this range.

9.  Acknowledgement  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.

10.  References

10.1.  Normative references 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,
   Shanghai
   China

   Email:

   EMail: lizho.jin@gmail.com

   Frederic Jounay
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex, FRANCE

   Email:
   Orange CH
   4 rue du Caudray
   1007 Lausanne
   Switzerland

   EMail: frederic.jounay@orange.ch

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

   Email:

   EMail: ice@cisco.com

   Nicolai Leymann
   Deutsche Telekom AG
   Winterfeldtstrasse 21
   Berlin  10781

   Email:
   Germany

   EMail: N.Leymann@telekom.de