summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7965.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7965.txt')
-rw-r--r--doc/rfc/rfc7965.txt899
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]
+