doc: Add RFC documents

1 files changed, 899 insertions, 0 deletions

diff --git a/doc/rfc/rfc7965.txt b/doc/rfc/rfc7965.txt
new file mode 100644
index 0000000..be767a9
--- /dev/null
+++ b/doc/rfc/rfc7965.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                           M. Chen
+Request for Comments: 7965                                        W. Cao
+Category: Standards Track                                         Huawei
+ISSN: 2070-1721                                                A. Takacs
+                                                                Ericsson
+                                                                  P. Pan
+                                                             August 2016
+
+
+                     LDP Extensions for Pseudowire
+              Binding to Label Switched Path (LSP) Tunnels
+
+Abstract
+
+   Many transport services require that user traffic, in the form of
+   Pseudowires (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.
+
+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 7841.
+
+   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/rfc7965.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chen, et al.                 Standards Track                    [Page 1]
+
+RFC 7965           Explicit PW-to-LSP Tunnels Binding        August 2016
+
+
+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  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   4
+   3.  LDP Extensions  . . . . . . . . . . . . . . . . . . . . . . .   5
+     3.1.  PSN Tunnel Binding TLV  . . . . . . . . . . . . . . . . .   5
+       3.1.1.  PSN Tunnel Sub-TLV  . . . . . . . . . . . . . . . . .   7
+   4.  Theory of Operation . . . . . . . . . . . . . . . . . . . . .   8
+   5.  PSN Binding Operation for SS-PW . . . . . . . . . . . . . . .   9
+   6.  PSN Binding Operation for MS-PW . . . . . . . . . . . . . . .  11
+   7.  PSN Tunnel Select Considerations  . . . . . . . . . . . . . .  13
+   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
+   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
+     9.1.  LDP TLV Types . . . . . . . . . . . . . . . . . . . . . .  13
+       9.1.1.  PSN Tunnel Sub-TLVs . . . . . . . . . . . . . . . . .  14
+     9.2.  LDP Status Codes  . . . . . . . . . . . . . . . . . . . .  14
+   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
+     10.1.  Normative References . . . . . . . . . . . . . . . . . .  14
+     10.2.  Informative References . . . . . . . . . . . . . . . . .  15
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  16
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chen, et al.                 Standards Track                    [Page 2]
+
+RFC 7965           Explicit PW-to-LSP Tunnels Binding        August 2016
+
+
+1.  Introduction
+
+   Pseudo Wire Emulation Edge-to-Edge (PWE3) [RFC3985] is a mechanism to
+   emulate Layer 2 services, such as Ethernet Point-to-Point circuits.
+   Such services are emulated between two Attachment Circuits, and the
+   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 Engineering (RSVP-TE)
+   [RFC3209] 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 with PSN tunnels; such associations must be managed via
+   provisioning or other private methods.
+
+   PW-to-PSN Tunnel Binding has become increasingly common and important
+   in many deployment scenarios, as it allows service providers to 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 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
+
+   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 bidirectional LSP.  At each PE, there are a large
+   number of bidirectional user flows from multiple Ethernet interfaces
+   (access circuits in the figure).  Each user flow utilizes a pair of
+   unidirectional PWs to carry bidirectional traffic.  The operators
+   need to make sure that the user flows (that is, the 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 head-end nodes.  Further, the
+   operators may apply different protection mechanisms on different
+   parts of the network (e.g., to deploy 1:1 protection in one part and
+   1+1 protection in other parts).  As such, operators may prefer to
+
+
+
+Chen, et al.                 Standards Track                    [Page 3]
+
+RFC 7965           Explicit PW-to-LSP Tunnels Binding        August 2016
+
+
+   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 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
+
+   LSP1 and LSP2 are two bidirectional connections on diverse paths.
+   The operator needs to deliver a 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 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 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].
+
+
+
+
+
+
+Chen, et al.                 Standards Track                    [Page 4]
+
+RFC 7965           Explicit PW-to-LSP Tunnels Binding        August 2016
+
+
+3.  LDP Extensions
+
+   This document defines a new optional TLV, the PSN Tunnel Binding TLV,
+   to communicate 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 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 requesting PE will choose and explicitly
+       indicate the LSP information in the requests; the receiving PE
+       MUST obey the requests; otherwise, the PW will not be
+       established.
+
+   2.  Co-routed binding: The requesting PE will suggest an underlying
+       LSP to a remote PE.  Upon receipt, the remote PE has the option
+       to use the suggested LSP or reply to the information for an
+       alternative.
+
+   In this document, the 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 endpoint address, the
+   Tunnel ID, and the Extended Tunnel ID.  The 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.
+
+3.1.  PSN Tunnel Binding TLV
+
+   The PSN Tunnel Binding TLV is an optional TLV and MUST be carried in
+   the LDP Label Mapping message [RFC5036] if 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(0x0973)|             Length            |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |C|S|T|    Unallocated flags    |            Reserved           |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    ~                       PSN Tunnel Sub-TLV                      ~
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                     Figure 3: PSN Tunnel Binding TLV
+
+
+
+Chen, et al.                 Standards Track                    [Page 5]
+
+RFC 7965           Explicit PW-to-LSP Tunnels Binding        August 2016
+
+
+   The U-bit and F-bit are defined in Section 3.3 [RFC5036].  Since the
+   PSN 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 TLV type is 0x0973.
+
+   The Length field is 2 octets long.  It defines the length in octets
+   of the value field (including Flags, Reserved, and sub-TLV fields).
+
+   The Flags field is 2 octets in length and three flags are defined in
+   this document.  The rest of the unallocated flags MUST be set to zero
+   when sending and MUST be ignored when received.
+
+      C (Co-routed path) bit: This bit informs the remote T-PE/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 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 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" is received,
+         a Label Release message with the status code set to "The C-bit
+         or S-bit unknown" (0x0000003C) MUST be 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 (Section 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.
+
+
+
+Chen, et al.                 Standards Track                    [Page 6]
+
+RFC 7965           Explicit PW-to-LSP Tunnels Binding        August 2016
+
+
+3.1.1.  PSN Tunnel Sub-TLV
+
+   PSN Tunnel Sub-TLVs are designed for inclusion in the PSN Tunnel
+   Binding TLV to specify the tunnel/LSPs to which a PW is required to
+   bind.
+
+   Two sub-TLVs are defined: 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 (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
+
+       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 (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
+
+
+
+Chen, et al.                 Standards Track                    [Page 7]
+
+RFC 7965           Explicit PW-to-LSP Tunnels Binding        August 2016
+
+
+   The definition of the Source and Destination Global/Node IDs and
+   Tunnel/LSP Numbers are derived from [RFC6370].  This 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 Sections 4.6.1.1 and 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 identify either a tunnel or a
+   specific LSP.  The T-bit in the Flags 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 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.
+
+4.  Theory of Operation
+
+   During PW setup, the PEs may choose to select the desired forwarding
+   tunnels/LSPs and inform the remote T-PE/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 no candidate is
+   available or 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 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 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 TLV.
+
+   It is possible that two PEs request PSN Binding to the same PW or PW
+   segment over different tunnels/LSPs at the same time.  This may cause
+   collisions of tunnel/LSPs selection as both PEs assume the active
+   role.
+
+
+
+
+Chen, et al.                 Standards Track                    [Page 8]
+
+RFC 7965           Explicit PW-to-LSP Tunnels Binding        August 2016
+
+
+   As defined in (Section 7.2.1, [RFC6073]), each PE may be categorized
+   into active and passive roles:
+
+   1.  Active PE: The PE that initiates the selection of the tunnel/LSPs
+       and informs the remote PE;
+
+   2.  Passive PE: The PE that obeys the active PE's suggestion.
+
+   In the 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
+       set up using FEC 129.
+
+5.  PSN Binding Operation for SS-PW
+
+   As illustrated in Figure 6, both PEs (e.g., PE1 and PE2) of a PW may
+   independently initiate the setup.  To perform PSN Binding, the Label
+   Mapping messages MUST carry a PSN Tunnel Binding TLV, and the PSN
+   Tunnel sub-TLV MUST contain the desired tunnel/LSPs of the sender.
+
+                    +----+        LSP1        +----+
+         +-----+    | PE1|====================| PE2|    +-----+
+         |     |----|    |                    |    |----|     |
+         | CE1 |    |............PW................|    | CE2 |
+         |     |----|    |                    |    |----|     |
+         +-----+    |    |====================|    |    +-----+
+                    +----+       LSP2         +----+
+
+           Figure 6: PSN Binding Operation in SS-PW Environment
+
+   As outlined previously, there are two types of binding requests:
+   co-routed and strict.
+
+   In strict binding, a PE (e.g., PE1) will mandate that the other PE
+   (e.g., PE2) use a specified tunnel/LSP (e.g., LSP1) as the PSN tunnel
+   on the reverse direction.  In the PSN 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.
+
+   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., PE2) needs to determine whether to accept the
+   indicated tunnel/LSP in PSN Tunnel Sub-TLV.
+
+
+
+
+Chen, et al.                 Standards Track                    [Page 9]
+
+RFC 7965           Explicit PW-to-LSP Tunnels Binding        August 2016
+
+
+   The receiving PE (PE2) may also be an active PE, and it may have
+   initiated the PSN Binding requests to the other PE (PE1); if the
+   received PSN tunnel/LSP is the same as 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 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 TLV, it MUST reply with a Label
+   Release message with the status code set to "Reject - unable to use
+   the suggested tunnel/LSPs", and the received PSN Tunnel Binding TLV,
+   and the PW will not be established.
+
+   To support co-routed binding, the receiving PE can select the
+   appropriate 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 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 TLV may only contain the
+   Source IDs/Numbers; the Destination IDs/Numbers are set to zero and
+   left for PE2 to complete when responding to the Label Mapping
+   message.
+
+   Upon receipt, since PE2 is also an active PE, and may have initiated
+   the PSN 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 that has
+   a PSN Binding TLV that contains the Source and Destination 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 TLV, it MUST reply with a Label Release
+   message that has a status code set to "Reject - unable to use the
+
+
+
+Chen, et al.                 Standards Track                   [Page 10]
+
+RFC 7965           Explicit PW-to-LSP Tunnels Binding        August 2016
+
+
+   suggested tunnel/LSPs" (0x0000003B) and the received PSN Tunnel
+   Binding TLV.
+
+   In addition, if the received PSN tunnel/LSP endpoints do not match
+   the PW endpoints, PE2 MUST reply with a Label Release message with
+   the status code set to "Reject - unable to use the suggested
+   tunnel/LSPs" (0x0000003B) and the received PSN 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, 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 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 TLV, it declares the removal of any co-routed/strict
+   constraints.  The current independent 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 until the completion of the
+   underlying PSN tunnel/LSP changes.
+
+6.  PSN Binding Operation for MS-PW
+
+   MS-PW uses FEC 129 for PW setup.  We refer to 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 in MS-PW Environment
+
+
+
+Chen, et al.                 Standards Track                   [Page 11]
+
+RFC 7965           Explicit PW-to-LSP Tunnels Binding        August 2016
+
+
+   When an active PE (that is, T-PE1) starts to signal an MS-PW, a PSN
+   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
+   TLV includes the PSN Tunnel sub-TLV that carries the desired
+   tunnel/LSP of T-PE1.
+
+   For strict binding, the initiating PE MUST set the S-bit, clear the
+   C-bit, and indicate the binding tunnel/LSP to the next-hop S-PE.
+
+   When S-PE1 receives the Label Mapping message, it needs to determine
+   if the signaling is for the forward or reverse direction, as defined
+   in Section 4.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 request is not acceptable, S-PE1 MUST reply with a
+   Label Release Message to the upstream PE (T-PE1) with the status code
+   set to "Reject - unable to use the suggested tunnel/LSPs"
+   (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 the binding process in the reverse
+   direction.  The Label Mapping message contains the received PSN
+   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 T-PE1 to complete the PSN
+   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 the status code set to "Reject - unable to use the
+   suggested tunnel/LSPs" (0x0000003B).  In addition, if the received
+   PSN tunnel/LSP endpoints do not match the PW Segment 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"
+   (0x0000003B) and the received PSN Tunnel Binding TLV MUST also be
+   carried.
+
+
+
+Chen, et al.                 Standards Track                   [Page 12]
+
+RFC 7965           Explicit PW-to-LSP Tunnels Binding        August 2016
+
+
+   For co-routed binding, the initiating PE (T-PE1) MUST set the C-bit,
+   reset the S-bit, and 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 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.
+
+7.  PSN Tunnel Select Considerations
+
+   As stated in Section 1, the PSN tunnel that is used for binding can
+   be either a co-routed bidirectional LSP or two LSPs with the same
+   route.  The co-routed bidirectional LSP has the characteristics that
+   both directions not only cross the same nodes and 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 bidirectional LSPs, it is RECOMMENDED that
+   a co-routed bidirectional LSP should be used; otherwise, two LSPs
+   with the same route may be used.
+
+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 not accept the use
+   of LSPs identified in the PSN Tunnel Binding TLV unless the LSP
+   endpoints match the PW or PW segment endpoints.  Furthermore, it is
+   RECOMMENDED that PEs implement the LDP security mechanisms described
+   in [RFC5036] and [RFC5920].
+
+9.  IANA Considerations
+
+9.1.  LDP TLV Types
+
+   This document defines a new TLV (Section 3.1) for inclusion in the
+   LDP Label Mapping message.  IANA has assigned TLV type value 0x0973
+   from the "LDP TLV Type Name Space" registry.
+
+
+
+
+Chen, et al.                 Standards Track                   [Page 13]
+
+RFC 7965           Explicit PW-to-LSP Tunnels Binding        August 2016
+
+
+9.1.1.  PSN Tunnel Sub-TLVs
+
+   This document defines two sub-TLVs (Section 3.1.1) for the PSN Tunnel
+   Binding TLV.  IANA has created a new PWE3 subregistry titled "PSN
+   Tunnel Sub-TLV Name Space" for PSN Tunnel sub-TLVs and has assigned
+   Sub-TLV type values to the following sub-TLVs:
+
+   IPv4 PSN Tunnel sub-TLV - 1
+
+   IPv6 PSN Tunnel sub-TLV - 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
+   [RFC5226].
+
+9.2.  LDP Status Codes
+
+   This document defines two new LDP status codes, IANA has assigned
+   status codes to these new defined codes from the "LDP Status Code
+   Name Space" registry.
+
+   "Reject - unable to use the suggested tunnel/LSPs" - 0x0000003B
+
+   "The C-bit or S-bit unknown" - 0x0000003C
+
+   The E bit is set to 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>.
+
+
+
+
+
+Chen, et al.                 Standards Track                   [Page 14]
+
+RFC 7965           Explicit PW-to-LSP Tunnels Binding        August 2016
+
+
+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>.
+
+
+
+
+
+
+Chen, et al.                 Standards Track                   [Page 15]
+
+RFC 7965           Explicit PW-to-LSP Tunnels Binding        August 2016
+
+
+   [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>.
+
+Acknowledgements
+
+   The authors would like to thank Adrian Farrel, Kamran Raza, Xinchun
+   Guo, Mingming Zhu, and Li Xue for their comments and help in
+   preparing this document.  Also this 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, and Stewart Bryant.
+
+   We would especially like to acknowledge Ping Pan, a 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 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
+
+
+
+
+Chen, et al.                 Standards Track                   [Page 16]
+