GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7965

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7965.txt · Last modified: 2016/09/01 01:26 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki