Network Working Group
Internet Engineering Task Force (IETF)                           M. Chen
Internet-Draft
Request for Comments: 7965                                        W. Cao
Intended status:
Category: Standards Track                                         Huawei
Expires: January 22, 2017
ISSN: 2070-1721                                                A. Takacs
                                                                Ericsson
                                                                  P. Pan
                                                           July 21,
                                                             August 2016

                     LDP Extensions for Pseudowire
              Binding to LSP Label Switched Path (LSP) Tunnels
            draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-09.txt

Abstract

   Many transport services require that user traffic, in the form of
   Pseudowires (PW), (PWs), be delivered via either a single co-routed
   bidirectional tunnel or two unidirectional tunnels that share the
   same routes.  This document defines an optional extension to the
   Label Distribution Protocol (LDP) that enables the binding between
   PWs and the underlying Traffic Engineering (TE) tunnels.  The
   extension applies to both single-segment and multi-segment PWs.

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

Status of 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 six months RFC 5741.

   Information about the current status of 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 January 22, 2017.
   http://www.rfc-editor.org/info/rfc7965.

Copyright Notice

   Copyright (c) 2016 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
   3.  LDP Extensions  . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.
     3.1.  PSN Tunnel Binding Tunnel-Binding TLV  . . . . . . . . . . . . . . . . .   5
       2.1.1.
       3.1.1.  PSN Tunnel Sub-TLV  . . . . . . . . . . . . . . . . .   6
   3.
   4.  Theory of Operation . . . . . . . . . . . . . . . . . . . . .   8
   4.
   5.  PSN Binding Operation for SS-PW . . . . . . . . . . . . . . .   9
   5.
   6.  PSN Binding Operation for MS-PW . . . . . . . . . . . . . . .  11
   6.
   7.  PSN Tunnel Select Considerations  . . . . . . . . . . . . . .  13
   7.
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   8.
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     8.1.
     9.1.  LDP TLV Types . . . . . . . . . . . . . . . . . . . . . .  13
       8.1.1.
       9.1.1.  PSN Tunnel Sub-TLVs . . . . . . . . . . . . . . . . .  13
     8.2.  14
     9.2.  LDP Status Codes  . . . . . . . . . . . . . . . . . . . .  14
   9.  Acknowledgements
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
   10.
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     10.2.  Informative References . . . . . . .  14
     10.1.  Normative References . . . . . . . . . .  15
   Acknowledgements  . . . . . . . .  14
     10.2.  Informative References . . . . . . . . . . . . . . . . .  15  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   Pseudo Wire Emulation Edge-to-Edge (PWE3) [RFC3985] is a mechanism to
   emulate layer Layer 2 services, such as Ethernet Point-to-Point circuits.
   Such services are emulated between two Attachment Circuits, and the
   Pseudowire (PW)-encapsulated layer
   Pseudowire-encapsulated Layer 2 service payload is transported via
   Packet Switching Network (PSN) tunnels between Provider Edges (PEs).
   PWE3 typically uses the Label Distribution Protocol (LDP) [RFC5036]
   or Resource ReserVation Protocol-Traffic Reservation Protocol - Traffic Engineering (RSVP-
   TE) (RSVP-TE)
   [RFC3209] LSPs Label Switched Paths (LSPs) as PSN tunnels.  The PEs select
   and bind the Pseudowires to PSN tunnels independently.  Today, there
   is no standardized protocol-based provisioning mechanism to associate
   PWs
   to with PSN tunnels, tunnels; such associations must be managed via
   provisioning or other private methods.

   PW-to-PSN Tunnel binding Binding has become increasingly common and important
   in many deployment scenarios, , as it allows service providers to
   provide offer
   service level agreements to their customers for such traffic
   attributes as bandwidth, latency, and availability.

   The requirements for explicit control of PW-to-LSP mapping has been are
   described in Section 5.3.2 of [RFC6373].  Figure 1 illustrates how
   PWs can be bound to particular LSPs.

                      +------+                  +------+
            ---AC1 ---|..............PWs...............|---AC1---
            ---...----| PE1  |=======LSPs=======| PE2  |---...---
            ---ACn ---|      |-------Links------|      |---ACn---
                      +------+                  +------+

               Figure 1: Explicit PW-to-LSP binding scenario Binding Scenario

   There are two PEs (PE1 and PE2) connected through multiple parallel
   links that may be on different physical fibers.  Each link is managed
   and controlled as a bi-directional bidirectional LSP.  At each PE, there are a large
   number of bi-directional bidirectional user flows from multiple Ethernet interfaces
   (access circuits in the figure).  Each user flow uses utilizes a pair of uni-directional
   unidirectional PWs to carry bi-directional bidirectional traffic.  The operators
   need to make sure that the user flows (that is, the PW-
   pairs) PW-pairs) are
   carried on the same fiber or bidirectional LSP.

   There are a number of reasons behind this requirement.  First, due to
   delay and latency constraints, traffic going over different fibers
   may require a large amount of expensive buffer memory to compensate
   for the differential delay at the headend head-end nodes.  Further, the
   operators may apply different protection mechanisms on different
   parts of the network (e.g., to deloy deploy 1:1 protection in one part and
   1+1 protection in other parts).  As such, operators may prefer to
   have a user's traffic traverse the same fiber.  That implies that
   both forwarding and reserve direction PWs that belong to the same
   user flow need to be mapped to the same co-routed bi-directional bidirectional LSP
   or two LSPs with the same route.

   Figure 2 illustrates a scenario where PW-LSP binding is not applied.

                    +----+   +--+ LSP1 +--+   +----+
         +-----+    | PE1|===|P1|======|P2|===| PE2|    +-----+
         |     |----|    |   +--+      +--+   |    |----|     |
         | CE1 |    |............PW................|    | CE2 |
         |     |----|    |      +--+          |    |----|     |
         +-----+    |    |======|P3|==========|    |    +-----+
                    +----+      +--+ LSP2     +----+

           Figure 2: Inconsistent SS-PW to LSP binding scenario SS-PW-to-LSP Binding Scenario

   LSP1 and LSP2 are two bidirectional connections on diverse paths.
   The operator needs to deliver a bi-directional bidirectional flow between PE1 and
   PE2.  Using existing mechanisms, it's possible that PE1 may select
   LSP1 (PE1-P1-P2-PE2) as the PSN tunnel for traffic from PE1 to PE2,
   while selecting LSP2 (PE2-P3-PE1) as the PSN tunnel for traffic from
   PE2 to PE1.

   Consequently, the user traffic is delivered over two disjoint disjointed LSPs
   that may have very different service attributes in terms of latency
   and protection.  This may not be acceptable as a reliable and
   effective transport service to the customer.

   A similar problem may also exist in multi-segment PWs (MS-PWs), where
   user traffic on a particular PW may hop over different networks on in
   forward and reverse directions.

   One way to solve this problem is by introducing manual provisioning
   at each PE to bind the PWs to the underlying PSN tunnels.  However,
   this is prone to configuration errors and does not scale.

   This document introduces an automatic solution by extending
   Forwarding Equivalence Class (FEC) 128/129 PW based on [RFC4447].

2.  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].

3.  LDP Extensions

   This document defines a new optional TLV, the PSN Tunnel Binding Tunnel-Binding TLV,
   to communicate tunnel/LSPs tunnel/LSP selection and binding requests between PEs.
   The TLV carries a PW's binding profile and provides explicit or
   implicit information for the underlying PSN tunnel binding Tunnel-Binding operation.

   The binding operation applies in both single-segment (SS) and multi-
   segment (MS) scenarios.

   The extension supports two types of binding requests:

   1.  Strict binding: the The requesting PE will choose and explicitly
       indicate the LSP information in the requests; the receiving PE
       MUST obey the requests, requests; otherwise, the PW will not be
       established.

   2.  Co-routed binding: the The requesting PE will suggest an underlying
       LSP to a remote PE.  On receive,  Upon receipt, the remote PE has the option
       to use the suggested LSP, LSP or reply to the information for an
       alternative.

   In this document, the terminology of term "tunnel" is identical to the "TE Tunnel"
   defined in Section 2.1 of [RFC3209], which is uniquely identified by
   a SESSION object that includes the Tunnel end point endpoint address, the
   Tunnel ID ID, and the Extended Tunnel ID.  The terminology term "LSP" is identical
   to the "LSP tunnel" defined in Section 2.1 of [RFC3209], which is
   uniquely identified by the SESSION object together with the
   SENDER_TEMPLATE (or FILTER_SPEC) object that consists of the LSP ID
   and the Tunnel endpoint address.

2.1.

3.1.  PSN Tunnel Binding Tunnel-Binding TLV

   The PSN Tunnel Binding Tunnel-Binding TLV is an optional TLV and MUST be carried in
   the LDP Label Mapping message [RFC5036] if PW to LSP PW-to-LSP binding is
   required.  The format is as follows:

     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| PSN Tunnel Binding (TBD1) | Binding(0x0973)|             Length            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |C|S|T|    Unallocated flags    |            Reserved           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ~                       PSN Tunnel Sub-TLV                      ~
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 3: PSN Tunnel Binding Tunnel-Binding TLV

   The U-bit and F-bit are defined in Section 3.3 [RFC5036].  Since the
   PSN Tunnel Binding Tunnel-Binding TLV is an optional TLV, the U-bit MUST be set to 1
   so that a receiver MUST silently ignore this TLV if unknown to it,
   and continue processing the rest of the message.

   A receiver of this TLV is not allowed to forward the TLV further when
   it does not know the TLV.  So, the F-bit MUST be set to 0.

   The PSN Tunnel Binding Tunnel-Binding TLV type is TBD1. 0x0973.

   The Length field is 2 octets in length. long.  It defines the length in octets
   of the value field (including Flags, Reserved, and sub-TLV fields).

   The Flag field is 2 octets in length, length and three flags are defined in
   this document.  The rest of the unallocated flags MUST be set to zero
   when
   sending, sending and MUST be ignored when received.

      C (Co-routed path) bit: This bit informs the remote T-PE/S-PEs T-PEs/S-PEs
      about the properties of the underlying LSPs.  When set, the remote
      T-PE/S-PEs SHOULD select the co-routed LSP (as the forwarding
      tunnel) as the reverse PSN tunnel.  If there is no such tunnel
      available, it may trigger the remote T-PE/S-PEs T-PEs/S-PEs to establish a
      new LSP.

      S (Strict) bit: This bit instructs the PEs with respect to the
      handling of the underlying LSPs.  When set, the remote PE MUST use
      the tunnel/
   LSP tunnel/LSP specified in the PSN Tunnel Sub-TLV as the PSN
      tunnel on the reverse direction of the PW, or the PW will fail to
      be established.

         Either the C-bit or the S-bit MUST be set.  The C-bit and S-bit
         are mutually exclusive from each other, and they cannot be set
         in the same message.  If a status code set to "both C-bit and
         S-bit are set" or "both C-bit and S-bit are clear" are is received,
         a Label Release message with the status code set to "The C-bit
         or S-bit unknown" (TBD5) (0x0000003C) MUST be replied, the reply, and the PW
         will not be established.

      T (Tunnel Representation) bit: This bit indicates the format of
      the LSP tunnels.  When the bit is set, the tunnel uses the tunnel
      information to identify itself, and the LSP Number fields in the
      PSN Tunnel sub-
   TLV sub-TLV (Section 2.1.1) 3.1.1) MUST be set to zero.
      Otherwise, both the tunnel and LSP information of the PSN tunnel
      are required.  The default is set.  The motivation for the T-bit
      is to support the MPLS protection operation where the LSP Number
      fields may be ignored.

   The Reserved field is 2 octets in length and is left for future use.

2.1.1.

3.1.1.  PSN Tunnel Sub-TLV

   PSN Tunnel Sub-TLVs are designed for inclusion in the PSN Tunnel Tunnel-
   Binding TLV to specify the tunnel/LSPs to which a PW is required to
   bind.

   Two sub-TLVs are defined: the The IPv4 and IPv6 Tunnel sub-TLVs.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type(TBD2)   Type (1)    |    Length     |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Source Global ID                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Source Node ID                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Source Tunnel Number     |     Source LSP Number         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Destination Global ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Destination Node ID                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Destination Tunnel Number   |    Destination LSP Number     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       0                   1                   2                   3

                 Figure 4: IPv4 PSN Tunnel sub-TLV format Sub-TLV Format

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Type(TBD3)   Type (2)    |    Length     |           Reserved            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Source Global ID                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                       Source Node ID                          ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Source Tunnel Number     |       Source LSP Number       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Destination Global ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                     Destination Node ID                       ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Destination Tunnel Number   |    Destination LSP Number     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 5: IPv6 PSN Tunnel sub-TLV format Sub-TLV Format

   The definition of the Source and Destination Global/Node IDs and Tunnel/
   LSP
   Tunnel/LSP Numbers are derived from [RFC6370].  This is to describe describes the
   underlying LSPs.  Note that the LSPs in this notation are globally
   unique.  The ITU-T style identifiers [RFC6923] are not used in this
   document.

   As defined in Section 4.6.1.2 Sections 4.6.1.1 and Section 4.6.2.2 4.6.1.2 of [RFC3209], the "Tunnel
   endpoint address" is mapped to the Destination Node ID, and the
   "Extended Tunnel ID" is mapped to the Source Node ID.  Both IDs can
   be either IPv4 or IPv6 addresses.  The Node IDs are routable
   addresses of the ingress LSR and egress LSR of the Tunnel/LSP.

   A PSN Tunnel sub-TLV could be used to either identify either a tunnel or a
   specific LSP.  The T-bit in the Flag field defines the distinction as
   such that, when the T-bit is set, the Source/Destination LSP Number
   fields MUST be zero and ignored during processing.  Otherwise, both
   Source/Destination LSP Number fields MUST have the actual LSP IDs of
   specific LSPs.

   Each PSN Tunnel Binding Tunnel-Binding TLV MUST only have one such sub-TLV.  When
   sending, only one sub-TLV MUST be carried.  When received, if there
   are more than one sub-TLVs carried, only the first sub-TLV MUST be
   used, the rest of the sub-TLVs MUST be ignored.

3.

4.  Theory of Operation

   During PW setup, the PEs may choose to select the desired forwarding
   tunnels/LSPs,
   tunnels/LSPs and inform the remote T-PE/S-PEs T-PEs/S-PEs about the desired
   reverse tunnels/LSPs.

   Specifically, to set up a PW (or PW Segment), a PE may select a
   candidate tunnel/LSP to act as the PSN tunnel.  If none no candidate is
   available or satisfies none satisfy the constraints, the PE will trigger and
   establish a new tunnel/LSP.  The selected tunnel/LSP information is
   carried in the PSN Tunnel Binding Tunnel-Binding TLV and sent with the Label Mapping
   message to the target PE.

   Upon the reception of the Label Mapping message, the receiving PE
   will process the PSN Tunnel Binding Tunnel-Binding TLV, determine whether it can
   accept the suggested tunnel/LSP or to find the reverse tunnel/LSP
   that meets the request, and respond with a Label Mapping message,
   which contains the corresponding PSN Tunnel Binding Tunnel-Binding TLV.

   It is possible that two PEs may request PSN binding Binding to the same PW or PW
   segment over different tunnels/LSPs at the same time.  There  This may cause
   collisions of tunnel/LSPs selection as both PEs assume the active
   role.

   As defined in (Section 7.2.1, [RFC6073]), each PE may be categorized
   into active and passive roles:

   1.  Active PE: the The PE which that initiates the selection of the tunnel/
       LSPs tunnel/LSPs
       and informs the remote PE;
   2.  Passive PE: the The PE which that obeys the active PE's suggestion.

   In the remaining rest of this document, we will elaborate upon the operation
   for SS-PW and MS-PW:

   1.  SS-PW: In this scenario, both PEs for a particular PW may assume
       the active roles.

   2.  MS-PW: One PE is active, while the other is passive.  The PWs are
       setup
       set up using FEC 129.

4.

5.  PSN Binding Operation for SS-PW

   As illustrated in Figure-5, Figure 6, both PEs (say, (e.g., PE1 and PE2) of a PW may
   independently initiate the setup.  To perform PSN binding, Binding, the Label
   Mapping messages MUST carry a PSN Tunnel Binding Tunnel-Binding TLV, and the PSN
   Tunnel sub-TLV MUST contains contain the desired tunnel/LSPs of the sender.

                    +----+        LSP1        +----+
         +-----+    | PE1|====================| PE2|    +-----+
         |     |----|    |                    |    |----|     |
         | CE1 |    |............PW................|    | CE2 |
         |     |----|    |                    |    |----|     |
         +-----+    |    |====================|    |    +-----+
                    +----+       LSP2         +----+

           Figure 6: PSN binding operation Binding Operation in SS-PW environment Environment

   As outlined previously, there are two types of binding request: requests: co-
   routed and strict.

   In strict binding, a PE (e.g., PE1) will mandate that the other PE
   (e.g., PE2) to use a specified tunnel/LSP (e.g. (e.g., LSP1) as the PSN tunnel
   on the reverse direction.  In the PSN Tunnel Binding Tunnel-Binding TLV, the S-bit
   MUST be set, the C-bit MUST be cleared, and the Source and
   Destination IDs/Numbers MUST be filled.

   On receive,

   Upon receipt, if the S-bit is set, as well as following the
   processing procedure defined in Section 5.3.3 of [RFC4447], the
   receiving PE
   (i.e. (i.e., PE2) needs to determine whether to accept the
   indicated tunnel/LSP in PSN Tunnel Sub-TLV.

   If the receiving PE (PE2) is also an active PE, and may have
   initiated the PSN binding Binding requests to the other PE (PE1), if the
   received PSN tunnel/LSP is the same as it has been was sent in the Label Mapping
   message by PE2, then the signaling has converged on a mutually agreed
   upon Tunnel/LSP.  The binding operation is completed.

   Otherwise, the receiving PE (PE2) MUST compare its own Node ID
   against the received Source Node ID as unsigned integers.  If the
   received Source Node ID is larger, the PE (PE2) will reply with a
   Label Mapping message to complete the PW setup and confirm the
   binding request.  The PSN Tunnel Binding Tunnel-Binding TLV in the message MUST
   contain the same Source and Destination IDs/Numbers as in the
   received binding request, in the appropriate order (where the source
   is PE2 and PE1 becomes the destination).  On the other hand, if the
   receiving PE (PE2) has a Node ID that is larger than the Source Node
   ID carried in the PSN Tunnel Binding Tunnel-Binding TLV, it MUST reply with a Label
   Release message with the status code set to "Reject - unable to use
   the suggested tunnel/LSPs" tunnel/LSPs", and the received PSN Tunnel Binding Tunnel-Binding TLV,
   and the PW will not be established.

   To support co-routed binding, the receiving PE can select the
   appropriated PSN tunnel/LSP for the reverse direction of the PW, so
   long as the forwarding and reverse PSNs share the same route (links
   and nodes).

   Initially, a PE (PE1) sends a Label Mapping message to the remote PE
   (PE2) with the PSN Tunnel Binding Tunnel-Binding TLV, with C-bit set, S-bit cleared,
   and the appropriate Source and Destination IDs/Numbers.  In case of
   unidirectional LSPs, the PSN Tunnel Binding Tunnel-Binding TLV may only contain the
   Source IDs/Numbers, IDs/Numbers; the Destination IDs/Numbers are set to zero and
   left for PE2 to complete when responding to the Label Mapping
   message.

   On receive,

   Upon receipt, since PE2 is also an active PE, and may have initiated
   the PSN binding Binding requests to the other PE (PE1), if the received PSN
   tunnel/LSP has the same route as the one that has been sent in the
   Label Mapping message to PE1, then the signaling has converged.  The
   binding operation is completed.

   Otherwise, PE2 needs to compare its own Node ID against the received
   Source Node ID as unsigned integers.  If the received Source Node ID
   is larger, PE2 needs to find/establish a tunnel/LSP that meets the
   co-routed constraint, and reply with a Label Mapping message with that has
   a PSN Binding TLV that contains the Source and Destination IDs/Numbers IDs/
   Numbers of the tunnel/LSP.  On the other hand, if the receiving PE
   (PE2) has a Node ID that is larger than the Source Node ID carried in
   the PSN
   Tunnel Binding Tunnel-Binding TLV, it MUST reply with a Label Release
   message with that has a status code set to "Reject - unable to use the
   suggested tunnel/LSPs"
   (TBD4) (0x0000003B) and the received PSN Tunnel Tunnel-
   Binding TLV.

   In addition, if the received PSN tunnel/LSP end points endpoints do not match
   the PW end points, endpoints, PE2 MUST reply with a Label Release message with
   the status code set to "Reject - unable to use the suggested tunnel/LSPs"
   (TBD4) tunnel/
   LSPs" (0x0000003B) and the received PSN Tunnel Binding Tunnel-Binding TLV MUST also
   be carried.

   In both strict and co-routed bindings, if the T-bit is set, the LSP
   Number field MUST be set to zero.  Otherwise, the field MUST contain
   the actual LSP number for the related PSN LSP.

   After a PW is established, the operators may choose to move the PWs
   from the current tunnel/LSPs to other tunnel/LSPs.  Also  Also, the
   underlying PSN tunnel may break due to a network failure.  When
   either of these scenarios occur, a new Label Mapping message MUST be
   sent to notify the remote PE of the changes.  Note that when the
   T-bit is set, the working LSP broken will not provide this update if
   there are protection LSPs in place.

   The message may carry a new PSN Tunnel Binding Tunnel-Binding TLV, which contains
   the new Source and Destination Numbers/IDs.  The handling of the new
   message should be identical to what has been described in this
   section.

   However, if the new Label Mapping message does not contain the PSN
   Tunnel Binding
   Tunnel-Binding TLV, it declares the removal of any co-routed/strict
   constraints.  The current independent PW to PSN binding PW-to-PSN Binding will be used.

   Further, as an implementation option, the PEs may choose not to
   remove the traffic from an operational PW, PW until the completion of the
   underlying PSN tunnel/LSP changes.

5.

6.  PSN Binding Operation for MS-PW

   MS-PW uses FEC 129 for PW setup.  We refer the operation to Figure-6. Figure 7 for this
   operation.

             +-----+ LSP1 +-----+ LSP2 +-----+ LSP3 +-----+
     +---+   |T-PE1|======|S-PE1|======|S-PE2|======|T-PE2|   +---+
     |   |---|     |      |     |      |     |      |     |---|   |
     |CE1|   |......................PW....................|   |CE2|
     |   |---|     |      |     |      |     |      |     |---|   |
     +---+   |     |======|     |======|     |======|     |   +---+
             +-----+ LSP4 +-----+ LSP5 +-----+ LSP6 +-----+

           Figure 7: PSN binding operation Binding Operation in MS-PW environment Environment

   When an active PE (that is, T-PE1) starts to signal a an MS-PW, a PSN
   Tunnel Binding
   Tunnel-Binding TLV MUST be carried in the Label Mapping message and
   sent to the adjacent S-PE (that is, S-PE1).  The PSN Tunnel Binding Tunnel-Binding
   TLV includes the PSN Tunnel sub-TLV that carries the desired tunnel/
   LSP of T-PE1's. T-PE1s.

   For strict binding, the initiating PE MUST set the S-bit, clear the
   C-bit
   C-bit, and indicate the binding tunnel/LSP to the next-hop S-PE.

   When S-PE1 receives the Label Mapping message, S-PE1 it needs to determine
   if the signaling is for the forward or reverse direction, as defined
   in Section 6.2.3 of [RFC7267].

   If the Label Mapping message is for the forward direction, and S-PE1
   accepts the requested tunnel/LSPs from T-PE1, S-PE1 MUST save the
   tunnel/LSP information for reverse-direction processing later on.  If
   the PSN binding Binding request is not acceptable, S-PE1 MUST reply with a
   Label Release Message to the upstream PE (T-PE1) with Status Code the status code
   set to "Reject - unable to use the suggested tunnel/LSPs" (TBD4).
   (0x0000003B).

   Otherwise, S-PE1 relays the Label Mapping message to the next S-PE
   (that is, S-PE2), with the PSN Tunnel sub-TLV carrying the
   information of the new PSN tunnel/LSPs selected by S-PE1.  S-PE2 and
   subsequent S-PEs will repeat the same operation until the Label
   Mapping message reaches to the remote T-PE (that is, T-PE2).

   If T-PE2 agrees with the requested tunnel/LSPs, it will reply with a
   Label Mapping message to initiate to the binding process on in the reverse
   direction.  The Label Mapping message contains the received PSN Tunnel Binding
   Tunnel-Binding TLV for confirmation purposes.

   When its upstream S-PE (S-PE2) receives the Label Mapping message,
   the S-PE relays the Label Mapping message to its upstream adjacent
   S-PE (S-PE1), with the previously saved PSN tunnel/LSP information in
   the PSN Tunnel sub-TLV.  The same procedure will be applied on
   subsequent S-PEs, until the message reaches to T-PE1 to complete the PSN binding
   Binding setup.

   During the binding process, if any PE does not agree to the requested
   tunnel/LSPs, it can send a Label Release Message to its upstream
   adjacent PE with Status Code the status code set to "Reject - unable to use the
   suggested tunnel/LSPs" (TBD4). (0x0000003B).  In addition, if the received
   PSN tunnel/LSP end points endpoints do not match the PW Segment end points, endpoints, the
   receiving PE MUST reply with a Label Release message with the status
   code set to "Reject - unable to use the suggested tunnel/LSPs" (TBD4)
   (0x0000003B) and the received PSN Tunnel Binding Tunnel-Binding TLV MUST also be
   carried.

   For co-routed binding, the initiating PE (T-PE1) MUST set the C-bit,
   reset the S-bit S-bit, and indicates indicate the suggested tunnel/LSP in the PSN
   Tunnel sub-TLV to the next-hop S-PE (S-PE1).

   During the MS-PW setup, the PEs have the option of ignoring the
   suggested tunnel/LSP, and to select another tunnel/LSP for the
   segment PW between itself and its upstream PE in reverse direction
   only if the tunnel/LSP is co-routed with the forward one.  Otherwise,
   the procedure is the same as the strict binding.

   The tunnel/LSPs may change after a MS-PW being has been established.  When
   a tunnel/LSP has changed, the PE that detects the change SHOULD
   select an alternative tunnel/LSP for temporary use while negotiating
   with other PEs following the procedure described in this section.

6.

7.  PSN Tunnel Select Considerations

   As stated in Section 1 of this document, 1, the PSN tunnel that is used for binding can
   be either a co-routed bi-directional bidirectional LSP or two LSPs with the same
   route.  The co-routed bi-directional bidirectional LSP has the characteristics that
   both directions not only cross the same nodes and links links, but have the
   same life span.  But for the two LSPs case, even if they have the
   same route at the beginning, it cannot be guaranteed that they will
   always have the same route all the time.  For example, when Fast
   ReRoute (FRR) [RFC4090] is deployed for the LSPs, link or node
   failure may make the two LSPs use different routes.  So, if the
   network supports co-routed bi-directional bidirectional LSPs, it is RECOMMENDED that
   a co-routed bi-directional bidirectional LSP should be used; otherwise, two LSPs
   with the same route may be used.

7.

8.  Security Considerations

   The ability to control which LSP is used to carry traffic from a PW
   can be a potential security risk both for denial of service and
   traffic interception.  It is RECOMMENDED that PEs do not accept the use
   of LSPs identified in the PSN Tunnel Binding Tunnel-Binding TLV unless the LSP
   end points
   endpoints match the PW or PW segment end points. endpoints.  Furthermore, it is
   RECOMMENDED that PEs implement the LDP security mechanisms described
   in [RFC5036] and [RFC5920].

8.

9.  IANA Considerations

8.1.

9.1.  LDP TLV Types

   This document defines a new TLV [Section 2.1 of this document] (Section 3.1) for inclusion in the
   LDP Label Mapping message.  IANA is requested to assign has assigned TLV type value (TBD1) to the new defined TLVs 0x0973
   from LDP "TLV the "LDP TLV Type Name Space" registry.

8.1.1.

9.1.1.  PSN Tunnel Sub-TLVs

   This document defines two sub-TLVs [Section 2.1.1 of this document] (Section 3.1.1) for the PSN Tunnel Binding
   Tunnel-Binding TLV.  IANA is required to create has created a new PWE3
   registry ("PSN subregistry titled
   "PSN Tunnel Sub-TLV Name Space") Space" for PSN Tunnel sub-TLVs and to assign has
   assigned Sub-TLV type values to the following sub-TLVs:

   IPv4 PSN Tunnel sub-TLV - TBD2 1

   IPv6 PSN Tunnel sub-TLV - TBD3 2

   In addition, the values 0 and 255 in this new registry should be
   reserved, and values 1-254 will be allocated by IETF Review.

8.2. Review
   [RFC5226].

9.2.  LDP Status Codes

   This document defines two new LDP status codes, IANA is requested to has assigned
   status codes to these new defined codes from the LDP "STATUS
   CODE NAME SPACE" "LDP Status Code
   Name Space" registry.

   "Reject - unable to use the suggested tunnel/LSPs" - TBD4 0x0000003B

   "The C-bit or S-bit unknown" -TBD5 - 0x0000003C

   The E bit is set to one 1 for both new codes.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4447]  Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
              G. Heron, "Pseudowire Setup and Maintenance Using the
              Label Distribution Protocol (LDP)", RFC 4447,
              DOI 10.17487/RFC4447, April 2006,
              <http://www.rfc-editor.org/info/rfc4447>.

   [RFC6370]  Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
              Profile (MPLS-TP) Identifiers", RFC 6370,
              DOI 10.17487/RFC6370, September 2011,
              <http://www.rfc-editor.org/info/rfc6370>.

10.2.  Informative References

   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
              <http://www.rfc-editor.org/info/rfc3209>.

   [RFC3985]  Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
              Edge-to-Edge (PWE3) Architecture", RFC 3985,
              DOI 10.17487/RFC3985, March 2005,
              <http://www.rfc-editor.org/info/rfc3985>.

   [RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
              Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              DOI 10.17487/RFC4090, May 2005,
              <http://www.rfc-editor.org/info/rfc4090>.

   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
              "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
              October 2007, <http://www.rfc-editor.org/info/rfc5036>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
              <http://www.rfc-editor.org/info/rfc5920>.

   [RFC6073]  Martini, L., Metz, C., Nadeau, T., Bocci, M., and M.
              Aissaoui, "Segmented Pseudowire", RFC 6073,
              DOI 10.17487/RFC6073, January 2011,
              <http://www.rfc-editor.org/info/rfc6073>.

   [RFC6373]  Andersson, L., Ed., Berger, L., Ed., Fang, L., Ed., Bitar,
              N., Ed., and E. Gray, Ed., "MPLS Transport Profile (MPLS-
              TP) Control Plane Framework", RFC 6373,
              DOI 10.17487/RFC6373, September 2011,
              <http://www.rfc-editor.org/info/rfc6373>.

   [RFC6923]  Winter, R., Gray, E., van Helvoort, H., and M. Betts,
              "MPLS Transport Profile (MPLS-TP) Identifiers Following
              ITU-T Conventions", RFC 6923, DOI 10.17487/RFC6923, May
              2013, <http://www.rfc-editor.org/info/rfc6923>.

   [RFC7267]  Martini, L., Ed., Bocci, M., Ed., and F. Balus, Ed.,
              "Dynamic Placement of Multi-Segment Pseudowires",
              RFC 7267, DOI 10.17487/RFC7267, June 2014,
              <http://www.rfc-editor.org/info/rfc7267>.

9.

Acknowledgements

   The authors would like to thank Adrian Farrel, Kamran Raza, Xinchun
   Guo, Mingming Zhu Zhu, and Li Xue for their comments and help in
   preparing this document.  Also this draft document benefits from the
   discussions with Nabil Bitar, Paul Doolan, Frederic Journay, Andy
   Malis, Curtis Villamizar, Luca Martini, Alexander Vainshtein, Huub
   van Helvoort, Daniele Ceccarelli Ceccarelli, and Stewart Byant. Bryant.

   We would especially like to acknowledge Ping Pan, a co-author coauthor on the
   early draft versions of this document.  It was a privilege to have
   known him.

   The coauthors of this document, the working group chairs, the
   responsible AD, and the PALS Working Group working group wish to dedicate this RFC
   to the memory of our friend and colleague Ping Pan, in recognition
   for his devotion and hard work at the IETF.

Authors' Addresses

   Mach(Guoyi) Chen
   Huawei

   Email: mach.chen@huawei.com

   Wei Cao
   Huawei

   Email: wayne.caowei@huawei.com

   Attila Takacs
   Ericsson
   Laborc u. 1.
   Budapest  1037
   Hungary

   Email: attila.takacs@ericsson.com

   Ping Pan