Internet DRAFT - draft-ietf-pals-mpls-tp-pw-over-bidir-lsp
draft-ietf-pals-mpls-tp-pw-over-bidir-lsp
Network Working Group M. Chen
Internet-Draft W. Cao
Intended status: Standards Track Huawei
Expires: December 4, 2016 A. Takacs
Ericsson
P. Pan
June 2, 2016
LDP Extensions for Pseudowire Binding to LSP Tunnels
draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-08.txt
Abstract
Many transport services require that user traffic, in the form of
Pseudowires (PW), 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 LDP that
enables the binding between PWs and the underlying TE tunnels. The
extension applies to both single-segment and multi-segment PWs.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 4, 2016.
Chen, et al. Expires December 4, 2016 [Page 1]
Internet-Draft Explicit PW to LSP Tunnels Binding June 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. LDP Extensions . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. PSN Tunnel Binding TLV . . . . . . . . . . . . . . . . . 5
2.1.1. PSN Tunnel Sub-TLV . . . . . . . . . . . . . . . . . 6
3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 8
4. PSN Binding Operation for SS-PW . . . . . . . . . . . . . . . 9
5. PSN Binding Operation for MS-PW . . . . . . . . . . . . . . . 11
6. PSN Tunnel Select Considerations . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.1. LDP TLV Types . . . . . . . . . . . . . . . . . . . . . . 13
8.1.1. PSN Tunnel Sub-TLVs . . . . . . . . . . . . . . . . . 13
8.2. LDP Status Codes . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
Pseudo Wire Emulation Edge-to-Edge (PWE3) [RFC3985] is a mechanism to
emulate layer 2 services, such as Ethernet Point-to-Point (P2P)
circuits. Such services are emulated between two Attachment Circuits
(ACs), and the Pseudowire (PW)-encapsulated layer 2 service payload
is transported via Packet Switching Network (PSN) tunnels between
Provider Edges (PEs). PWE3 typically uses Label Distribution
Protocol (LDP) [RFC5036] or Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) [RFC3209] 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
Chen, et al. Expires December 4, 2016 [Page 2]
Internet-Draft Explicit PW to LSP Tunnels Binding June 2016
PWs to 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
provide service level agreements to their customers for such traffic
attributes as bandwidth, latency, and availability.
The requirements for explicit control of PW-to-LSP mapping has been
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 bi-directional LSP. At each PE, there are a
large number of bi-directional user flows from multiple Ethernet
interfaces (access circuits in the figure). Each user flow uses a
pair of uni-directional PWs to carry bi-directional 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 headend nodes. Further, the
operators may apply different protection mechanisms on different
parts of the network. As such, for optimal traffic management,
traffic belonging to a particular user should traverse over the same
fiber. That implies that both forwarding and reserve direction PWs
that belong to the same user flow need to be mapped to the same co-
routed bi-directional LSP or two LSPs with the same route.
Figure 2 illustrates a scenario where PW-LSP binding is not applied.
Chen, et al. Expires December 4, 2016 [Page 3]
Internet-Draft Explicit PW to LSP Tunnels Binding June 2016
+----+ +--+ 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 bi-directional flow between PE1 and
PE2. Using existing mechanisms, it's possible that PE1 may select
LSP1 (PE1-P1-P2-PE2) as the PSN tunnel for traffic from PE1 to PE2,
while selecting LSP2 (PE2-P3-PE1) as the PSN tunnel for traffic from
PE2 to PE1.
Consequently, the user traffic is delivered over two disjoint LSPs
that may have very different service attributes in terms of latency
and protection. This may not be acceptable as a reliable and
effective transport service to the customer.
A similar problem may also exist in multi-segment PWs (MS-PWs), where
user traffic on a particular PW may hop over different networks on
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 FEC
128/129 PW based on [RFC4447].
2. LDP Extensions
This document defines a new optional TLV, PSN Tunnel Binding TLV, to
communicate tunnel/LSPs 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
Chen, et al. Expires December 4, 2016 [Page 4]
Internet-Draft Explicit PW to LSP Tunnels Binding June 2016
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. On receive, the remote PE has the option to
use the suggested LSP, or reply the information for an
alternative.
In this document, the terminology of "tunnel" is identical to the "TE
Tunnel" defined in Section 2.1 of [RFC3209], which is uniquely
identified by a SESSION object that includes Tunnel end point
address, Tunnel ID and Extended Tunnel ID. The terminology "LSP" is
identical to the "LSP tunnel" defined in Section 2.1 of [RFC3209],
which is uniquely identified by the SESSION object together with
SENDER_TEMPLATE (or FILTER_SPEC) object that consists of LSP ID and
Tunnel endpoint address.
2.1. PSN Tunnel Binding TLV
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 (TBD1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|S|T| MUST be zero | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ PSN Tunnel Sub-TLV ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PSN Tunnel Binding TLV
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 TBD1.
The Length field is 2 octets in length. It defines the length in
octets of the value field (including Flags, Reserved, sub-TLV
fields).
Chen, et al. Expires December 4, 2016 [Page 5]
Internet-Draft Explicit PW to LSP Tunnels Binding June 2016
The Flag field is 2 octets in length, three flags are defined in this
document. The rest unallocated flags MUST be set to zero when
sending, and MUST be ignored when received.
C (Co-routed path) bit: This informs the remote T-PE/S-PEs about the
properties of the underlying LSPs. When set, the remote T-PE/S-PEs
need to select 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 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.
T (Tunnel Representation) bit: This 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 2.1.1) MUST be set to zero. Otherwise, both 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.
C-bit and S-bit are mutually exclusive from each other, and cannot be
set in the same message. Otherwise, a Label Release message with
status code set to "The C-bit and S-bit can not both be set" (TBD5)
MUST be replied, and the PW will not be established.
2.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.
Chen, et al. Expires December 4, 2016 [Page 6]
Internet-Draft Explicit PW to LSP Tunnels Binding June 2016
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type(TBD2) | 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(TBD3) | 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
The definition of Source and Destination Global/Node IDs and Tunnel/
LSP Numbers are derived from [RFC6370]. This is to describe 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.
Chen, et al. Expires December 4, 2016 [Page 7]
Internet-Draft Explicit PW to LSP Tunnels Binding June 2016
As defined in Section 4.6.1.2 and Section 4.6.2.2 of [RFC3209], the
"Tunnel endpoint address" is mapped to Destination Node ID, and
"Extended Tunnel ID" is mapped to Source Node ID. Both IDs can be
IPv4 or IPv6 addresses. The Node IDs are routable addresses of the
ingress LSR and egress LSR of the Tunnel/LSP.
A PSN Tunnel sub-TLV could be used to either identify a tunnel or a
specific LSP. The T-bit in the Flag field defines the distinction as
such that, when the T-bit is set, the Source/Destination LSP Number
fields MUST be zero and ignored during processing. Otherwise, both
Source/Destination LSP Number fields MUST have the actual LSP IDs of
specific LSPs.
Each PSN Tunnel Binding TLV can only have one such sub-TLV.
3. Theory of Operation
During PW setup, the PEs may choose to select 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 none is available
or satisfies 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 may request PSN binding to the same PW or
PW segment over different tunnels/LSPs at the same time. There may
cause collisions of tunnel/LSPs selection as both PEs assume the
active role.
As defined in (Section 7.2.1, [RFC6073]), each PE may be categorized
into active and passive roles:
1. Active PE: the PE which initiates the selection of the tunnel/
LSPs and informs the remote PE;
2. Passive PE: the PE which obeys the active PE's suggestion.
Chen, et al. Expires December 4, 2016 [Page 8]
Internet-Draft Explicit PW to LSP Tunnels Binding June 2016
In the remaining of this document, we will elaborate the operation
for SS-PW and MS-PW:
1. SS-PW: In this scenario, both PEs for a particular PW may assume
the active roles.
2. MS-PW: One PE is active, while the other is passive. The PWs are
setup using FEC 129.
4. PSN Binding Operation for SS-PW
As illustrated in Figure-5, both PEs (say, 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 contains 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 request: co-
routed and strict.
In strict binding, a PE (e.g., PE1) will mandate the other PE (e.g.,
PE2) to 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.
On receive, 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.
If the receiving PE (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 is the same as it has been sent in the Label
Mapping message by PE2, then the signaling has converged on a
mutually agreed 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
Chen, et al. Expires December 4, 2016 [Page 9]
Internet-Draft Explicit PW to LSP Tunnels Binding June 2016
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 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
appropriated PSN tunnel/LSP for the reverse direction of the PW, so
long as the forwarding and reverse PSNs share the same route (links
and nodes).
Initially, a PE (PE1) sends a Label Mapping message to the remote PE
(PE2) with the PSN Tunnel Binding 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 the Label Mapping message.
On receive, 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 with 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 with
status code set to "Reject - unable to use the suggested tunnel/LSPs"
(TBD4) and the received PSN Tunnel Binding TLV.
In both strict and co-routed bindings, if 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
Chen, et al. Expires December 4, 2016 [Page 10]
Internet-Draft Explicit PW to LSP Tunnels Binding June 2016
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.
5. PSN Binding Operation for MS-PW
MS-PW uses FEC 129 for PW setup. We refer the operation to Figure-6.
+-----+ 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
When an active PE (that is, T-PE1) starts to signal a 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's.
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, S-PE1 needs to
determine if the signaling is for forward or reverse direction, as
defined in Section 6.2.3 of [RFC7267].
Chen, et al. Expires December 4, 2016 [Page 11]
Internet-Draft Explicit PW to LSP Tunnels Binding June 2016
If the Label Mapping message is for 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 Status Code set
to "Reject - unable to use the suggested tunnel/LSPs" (TBD4).
Otherwise, S-PE1 relays the Label Mapping message to the next S-PE
(that is, S-PE2), with the PSN Tunnel sub-TLV carrying the
information of the new PSN tunnel/LSPs selected by S-PE1. S-PE2 and
subsequent S-PEs will repeat the same operation until the Label
Mapping message reaches to the remote T-PE (that is, T-PE2).
If T-PE2 agrees with the requested tunnel/LSPs, it will reply with a
Label Mapping message to initiate to the binding process on 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 to 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 Status Code set to "Reject - unable to use the
suggested tunnel/LSPs" (TBD4).
For co-routed binding, the initiating PE (T-PE1) MUST set the C-bit,
reset the S-bit and indicates the suggested tunnel/LSP in PSN Tunnel
sub-TLV to the next-hop S-PE (S-PE1).
During the MS-PW setup, the PEs have the option of ignoring the
suggested tunnel/LSP, and to select another tunnel/LSP for the
segment PW between itself and its upstream PE in reverse direction
only if the tunnel/LSP is co-routed with the forward one. Otherwise,
the procedure is the same as the strict binding.
The tunnel/LSPs may change after a MS-PW being 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.
Chen, et al. Expires December 4, 2016 [Page 12]
Internet-Draft Explicit PW to LSP Tunnels Binding June 2016
6. PSN Tunnel Select Considerations
As stated in Section 1 of this document, the PSN tunnel that is used
for binding can be either a co-routed bi-directional LSP or two LSPs
with the same route. The co-routed bi-directional 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 bi-directional LSPs,
it is RECOMMENDED that a co-routed bi-directional LSP should be used;
otherwise, two LSPs with same route may be used.
7. Security Considerations
The ability to control which LSP is used to carry traffic from a PW
can be a potential security risk both for denial of service and
traffic interception. It is RECOMMENDED that PEs do not accept the
use of LSPs identified in the PSN Tunnel Binding TLV unless the LSP
end points match the PW or PW segment end points. Furthermore, it is
RECOMMENDED that PEs implement the LDP security mechanisms described
in [RFC5036] and [RFC5920].
8. IANA Considerations
8.1. LDP TLV Types
This document defines a new TLV [Section 2.1 of this document] for
inclusion in LDP Label Mapping message. IANA is requested to assign
TLV type value (TBD1) to the new defined TLVs from LDP "TLV Type Name
Space" registry.
8.1.1. PSN Tunnel Sub-TLVs
This document defines two sub-TLVs [Section 2.1.1 of this document]
for PSN Tunnel Binding TLV. IANA is required to create a new PWE3
registry ("PSN Tunnel Sub-TLV Name Space") for PSN Tunnel sub-TLVs
and to assign Sub-TLV type values to the following sub-TLVs:
IPv4 PSN Tunnel sub-TLV - TBD2
IPv6 PSN Tunnel sub-TLV - TBD3
In addition, the values 0 and 255 in this new registry should be
reserved, and values 1-254 will be allocated by IETF Review.
Chen, et al. Expires December 4, 2016 [Page 13]
Internet-Draft Explicit PW to LSP Tunnels Binding June 2016
8.2. LDP Status Codes
This document defines two new LDP status codes, IANA is requested to
assigned status codes to these new defined codes from the LDP "STATUS
CODE NAME SPACE" registry.
"Reject - unable to use the suggested tunnel/LSPs" - TBD4
"The C and S bit can not be both set" -TBD5
The E bit is set to one for both new codes.
9. 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 draft 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 Byant.
We would especially like to acknowledge Ping Pan, a co-author on the
early 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.
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>.
Chen, et al. Expires December 4, 2016 [Page 14]
Internet-Draft Explicit PW to LSP Tunnels Binding June 2016
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370,
DOI 10.17487/RFC6370, September 2011,
<http://www.rfc-editor.org/info/rfc6370>.
10.2. Informative References
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC3985] Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
Edge-to-Edge (PWE3) Architecture", RFC 3985,
DOI 10.17487/RFC3985, March 2005,
<http://www.rfc-editor.org/info/rfc3985>.
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005,
<http://www.rfc-editor.org/info/rfc4090>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[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. Expires December 4, 2016 [Page 15]
Internet-Draft Explicit PW to LSP Tunnels Binding June 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>.
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. Expires December 4, 2016 [Page 16]
