GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7140

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7140.txt · Last modified: 2014/03/02 15:59 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki