Network working group W. Cao
Internet Draft M. Chen
Category: Standards Track Huawei Technologies Co.,Ltd
Created: October 25, 2010 A. Takacs
Expires: April 2011 Ericsson
LDP extensions for Explicit Pseudowire to transport LSP mapping
draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-01.txt
Abstract
A bidirectional Pseudowire (PW) service currently uses two
unidirectional PWs each carried over a unidirectional LSP. Each end
point of a PW or segment of multi-segment PW (MS-PW) independently
selects the LSP to use to carry the PW for which it is the head end.
Some transport services may require that bidirectional PW traffic
follows the same paths through the network in both directions.
Therefore, PWs may be required to use LSP with congruent paths.
Bidirectional LSPs or co-routed associated unidirectional LSPs allow
this service to be provided.
This document specifies some extensions to LDP that allow both ends
of a PW (or segment of a MS-PW) to select and bind to the same
bidirectional LSP or use unidirectional LSPs with congruent paths.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
Chen, et al. Expires April 25, 2011 [Page 1]
Internet-Draft PW to LSP Binding October 2010
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 20, 2010.
Copyright Notice
Copyright (c) 2010 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 BSD License.
Conventions used in this document
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].
Table of Contents
1. Introduction ................................................. 3
2. PW to LSP Binding TLV ........................................ 4
3. LDP Extensions ............................................... 6
3.1.1. Active/Active Signaling Procedures ................. 7
3.1.2. Active/Passive Signaling Procedures ................ 8
4. Security Considerations ...................................... 9
5. IANA Considerations .......................................... 9
5.1. LDP TLV Types ........................................... 9
5.2. LDP Status Codes ........................................ 9
6. Acknowledgments ............................................. 10
7. References .................................................. 10
7.1. Normative References ................................... 10
7.2. Informative References ................................. 10
Authors' Addresses ............................................. 11
Chen, et al. Expires April 25, 2011 [Page 2]
Internet-Draft PW to LSP Binding October 2010
1. Introduction
Pseudo Wire (PW) Emulation Edge-to-Edge (PWE3) [RFC3985] is a
mechanism to emulate a number of layer 2 services, such as
Asynchronous Transfer Mode (ATM), Frame Relay or Ethernet. Such
services are emulated between two Attachment Circuits (ACs) and the
PW encapsulated layer 2 service payload is carried through Packet
Switching Network (PSN) tunnels between Provider Edges (PEs). Today
PWE3 generally uses two reverse unidirectional Label Distribution
Protocol (LDP) [RFC5036] or Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) [RFC3209] LSPs as PSN tunnels, and each of the
PEs selects and binds PSN tunnel independently. There is no
protocol-based provision to explicitly associate a PW with a
specific PSN tunnel.
For transport applications it has been identified that some
transport services may require bidirectional traffic to follow
congruent paths. When bidirectional LSPs are used as PSN tunnels,
this requirement can be fulfilled if both PEs of a specific/segment
PW select and bind to the same bidirectional LSPs. In the case of
unidirectional LSPs, LSPs with congruent paths need to be selected
to support the PW. However, current mechanisms cannot guarantee
appropriate mapping of PWs to underlying LSPs. When there are
multiple unidirectional/bidirectional LSPs that may be used to
provide different levels of Quality of Service (QOS) or protection
between the PEs a selection must be made and some form of control is
required to ensure that the correct LSPs are used.
+----+ +--+ LSP1 +--+ +----+
+-----+ | PE1|===|P1|======|P2|===| PE2| +-----+
| |----| | +--+ +--+ | |----| |
| CE1 | |............PW................| | CE2 |
| |----| | +--+ | |----| |
+-----+ | |======|P3|==========| | +-----+
+----+ +--+ LSP2 +----+
Figure 1 SS-PW scenario
Figure 1 shows an example of inconsistent binding in a Single-
Segment PW (SS-PW) scenario. There are two bidirectional LSPs (LSP1
and LSP2, along diverse paths) and a bidirectional PW service
between PE1 and PE2. With the current mechanisms, it's possible that
PE1 may select LSP1 (PE1-P1-P2-PE2) as the PSN tunnel for the PE1-
>PE2 direction of the PW, and PE2 may select LSP2 (PE1-P3-PE2) as
the PSN tunnel for the PE2->PE1 direction of the PW, so the
bidirectional PW service is bound to two separate bidirectional LSPs.
If the service requirement is that the two directions of the PW
Chen, et al. Expires April 25, 2011 [Page 3]
Internet-Draft PW to LSP Binding October 2010
service are routed in the same way through the network, this outcome
will be unacceptable. The problem also exists in Multi-Segment PW
(MS-PW) scenarios.
One possible way to resolve this issue is to bind the PSN tunnel
manually at each PE, but this is prone to configuration errors and
it is difficult to maintain a large number of PWs in such a manner.
To allow for minimal manual intervention and configuration, this
draft discusses an automatic solution by extending FEC 128/129 PW
based on [RFC4447].
2. PW to LSP Binding TLV
In this document two new OPTIONAL TLVs are defined: the IPv4/IPv6 PW
to LSP Binding TLVs. They are used to communicate the selected LSPs
between the two PEs of a PW or segment of MS-PW.
When using LDP to signal the PW, the identifiers of the LSP are
carried in the Label Mapping message utilizing the new TLVs defined
in this document.
The format of the PW to LSP Binding LSP TLVs is as follows, the
value fields are derived from the definition of [I-D.ietf-mpls-tp-
identifiers].
(Editor notes: In I-D.ietf-mpls-tp-identifiers, an LSP is identified
by the combination of Src-Global_ID, Src-Node_ID, Src-Tunnel_Num,
Dst-Global_ID, Dst-Node_ID, Dst-Tunnel_Num, LSP_Num, this is fine
for unidirectional and co-routed bidirectional LSP, but it is not
enough for associated bidirectional LSP that is combined with two
reverse unidirectional LSPs and hence two LSP_Nums are required.)
Chen, et al. Expires April 25, 2011 [Page 4]
Internet-Draft PW to LSP Binding October 2010
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| IPv4 PW to LSP binding TLV| TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Tunnel Number | Source LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Node ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Tunnel Number | Destination LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure2 IPv4 PW to LSP Binding 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| IPv6 PW to LSP Binding TLV| TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Source Node ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Tunnel Number | Source LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Global ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Destination Node ID ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Tunnel Number | Destination LSP Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure3 IPv6 PW to LSP Binding TLV format
As defined in [RFC3209] and [RFC3473], an RSVP-TE LSP is identified
by the combination of LSP ID, Tunnel ID, Tunnel Extended ID, Tunnel
Chen, et al. Expires April 25, 2011 [Page 5]
Internet-Draft PW to LSP Binding October 2010
end point address, Tunnel sender address, and a mapping between
these fields to the fields of IPv4/v6 PW to LSP Binding TLV is
needed. The mapping defined in Section 5.3 of [I-D.ietf-mpls-tp-
identifiers] applies here.
In addition, for co-routed bidirectional LSP, since the Source and
Destination Tunnel/LSP ID is the same, Destination Tunnel Number and
Destination LSP Number MUST be set to the same as the Source Tunnel
Number and Source LSP Number, respectively.
For associated bidirectional LSP, Destination Tunnel Number and
Destination LSP Number MUST be set to the Tunnel ID and LSP ID of
the reverse direction component LSP of the associated bidirectional
LSP, respectively.
For unidirectional LSPs, when the reverse direction tunnel LSP is
determined in advance (e.g., in an active/passive mode, the active
end may explicitly specify the reverse tunnel LSP for a PW),
Destination Tunnel Number and Destination LSP Number SHOULD be set
to the Tunnel ID and LSP ID of the reverse LSP, respectively. If the
reverse direction tunnel LSP can not be determined in advance,
Destination Tunnel Number and Destination LSP Number MUST be set to
zero.
(Editor notes: In I-D.ietf-mpls-tp-identifiers, the
Source/Destination Node ID is defined as a 32-bit ID, but for a
MPLS/GMPLS TE based LSP, the Extended Tunnel ID, Tunnel end point
address, and Tunnel sender address may be IPv6 addresses, so the
current Source/Destination Node ID does not cover this and can not
map to IPv6 based Tunnel Extended ID, Tunnel end point address, and
Tunnel sender address.)
3. LDP Extensions
Before sending a Label Mapping message to set up a PW or PW Segment,
a PE has to select candidate LSPs to act as PSN tunnels. The
selected LSPs are carried by the PW to LSP binding TLV and sent with
the Label Mapping message to the target/switching PE. Therefore,
there may be some collisions of tunnel LSP selection when both PEs
assume the active role and independently signal the PW or PW Segment.
In order to reduce and resolve the collision of tunnel selection,
two types of PEs are identified here:
a) Active PE: the PE which initiates the selection of the tunnel
LSPs and informs the remote PE;
Chen, et al. Expires April 25, 2011 [Page 6]
Internet-Draft PW to LSP Binding October 2010
b) Passive PE: the PE which obeys the active PE's suggestion.
The role of a PE is based on the role that it takes in the signaling
of a specific PW. The active/passive role election is defined in the
Section 7.2.1 of [SEG-PW] and applies here, this document does not
define any new role election procedures. There exist two situations:
Active/Active - Both PEs of a PW or PW Segment assume active roles
(e.g., SS-PW, LDP using FEC 128 MS-PW).
Active/Passive - One PE is Active and the other is passive (e.g.,
LDP using FEC 129 MS-PW).
3.1.1. Active/Active Signaling Procedures
In a bidirectional LSP scenario, both PEs (say PE1 and PE2) send a
Label Mapping message carrying their own selected bidirectional LSP
to each other. If the bidirectional LSP in the received message from
other PE is as same as it was in the Label Mapping message sent by
itself, then the PW signaling has converged on an mutually agreed
tunnel LSP and selection is completed. Otherwise, when the
bidirectional LSP selected by one PE (say PE1) differs from the
bidirectional LSP selected by the other PE (say PE2), PE1 and PE2
have to make a choice between two tunnel LSPs. In this case PE1 and
PE2 can compare the Node ID, and the LSP selected by the node with
numerically higher ID will be determined to carry the PW.
In case of unidirectional LSPs, each PE may select a unidirectional
tunnel LSP that is used for its own forward direction of the PW and
send it with the Label Mapping message to the other PE. It is
possible that the two LSPs are not congruent. The mechanisms to
determine which LSPs are congruent are out of scope, but it is
assumed that each PE is able to look at the paths of LSPs (from
information supplied to or by the control plane, or from information
supplied by the management plane). In addition, each PE may
explicitly specify both the forward and reverse direction tunnel
LSPs of the PW and send them with the Label Mapping message to each
other. If the two PEs of the PW have the same tunnel selection (e.g.,
for a specific PW, the forward direction tunnel LSP selected by one
PE is the same as the reverse direction tunnel LSP selected by the
other PE, and vice versa), then the PW signaling is completed and
has converged on an mutually agreed tunnel LSPs. Otherwise, when the
tunnel LSPs selected by one PE differ from the tunnel LSPs selected
by the other PE, the LSPs selected by the node with numerically
higher Node ID will be determined as the tunnel.
Chen, et al. Expires April 25, 2011 [Page 7]
Internet-Draft PW to LSP Binding October 2010
In case of one PE selects a pair of unidirectional LSPs and the
other PE selects a bidirectional LSP, the LSPs selected by the node
with numerically higher Node ID will be determined as the tunnel.
3.1.2. Active/Passive Signaling Procedures
3.1.2.1. Active PE Signaling Procedure
Before sending the Label Mapping message, the active PE, say PE1,
MUST select the tunnel LSPs for the PW or Segment PW. Then PE1
generates a PW to LSP Binding TLV that identifies the selected LSP
and sends the Label Mapping message containing it to the passive PE,
in this case PE2.
In case of bidirectional LSPs, if PE1 receives a Label Mapping
message in which the bidirectional LSP is the same as the
bidirectional LSP it selected then both directions of the PW or
Segment PW are setup.
In case of unidirectional LSPs, if PE1 specifies both the forward
and reverse direction tunnel LSPs in a previous Label Mapping
message sent by itself, when PE1 receives a Label Mapping message in
which the reverse tunnel LSP is the same as the forward tunnel LSP
and the forward tunnel LSP is the same as the reverse tunnel LSP it
selected, then both directions of the PW or segment PW are setup.
According to the passive PE procedures described in Section 3.1.2.2,
the identified LSPs SHOULD match. If they do not, the active PE MUST
assume that the peer PE is also in active role, and MUST apply the
procedures described in Section 3.1.1.
3.1.2.2. Passive PE Signaling Procedure
When a Label Mapping message carrying a PW to LSP Binding TLV is
received by the passive PE (say PE2) it may decide, based on local
policy and/or success or failure in matching the LSP to accept or
reject it.
If the suggested tunnel LSPs cannot be matched successfully or if
local policy prohibits its acceptance, a Label Release message MUST
be sent, with a "No matched tunnel LSPs" code, and the processing of
the Label Mapping message is complete.
If the tunnel LSPs proposed by PE1 are accepted by PE2 then PE2
attempts setup of the PW in the opposite (PE2->PE1) direction, it
Chen, et al. Expires April 25, 2011 [Page 8]
Internet-Draft PW to LSP Binding October 2010
sends a Label Mapping message to PE1, with a PW to LSP Binding TLV
that identifies the tunnel LSPs, proposed by PE1, that it has
accepted for this PW. That is, for bidirectional LSPs, the PW to LSP
Binding TLV SHOULD identify the same bidirectional LSP proposed by
PE1. In case of unidirectional LSPs, if the received PW to LSP
Binding TLV including both forward and reverse direction tunnel LSPs,
the Source Tunnel Number and LSP Number of the PW to LSP Binding LSP
SHOULD be exchanged for each other. Accordingly, the
Source/Destination Node ID/Global ID of the PW to LSP Binding TLV
SHOULD be exchanged as well.
4. Security Considerations
The ability to control which LSPs are used to carry a PW is a
potential security risk both for denial of service and for
interception of traffic. It is RECOMMENDED that PEs do not accept
the use of LSPs identified in the LSP Binding TLV unless the LSP end
points match the PW or PW segment end points. Furthermore, where
security of the network is believed to be at risk, it is RECOMMENDED
that PEs implement the LDP security mechanisms described in [RFC5306]
and [RFC5920].
5. IANA Considerations
5.1. LDP TLV Types
This document defines two new TLVs [Section 2 of this document] for
inclusion in LDP Label Mapping message. IANA is required to assigned
TLV type values to the new defined TLVs from LDP "TLV Type Name
Space" registry.
IPv4 PW to LSP Binding TLV - 0x0971 (to be confirmed by IANA)
IPv6 PW to LSP Binding TLV - 0x0972 (to be confirmed by IANA)
5.2. LDP Status Codes
This document defines a new LDP status codes, IANA is required to
assigned status codes to these new defined codes from LDP "STATUS
CODE NAME SPACE" registry.
"No matched tunnel LSPs" - 0x0000003B (to be confirmed by IANA)
Chen, et al. Expires April 25, 2011 [Page 9]
Internet-Draft PW to LSP Binding October 2010
6. Acknowledgments
The authors would like to thank Adrian Farrel, Mingming Zhu and Li
Xue for their comments and help in preparing this document. Also
this draft has benefited from discussions with Nabil Bitar, Paul
Doolan, Frederic Journay and Andy Malis.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T.,and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC4447,April 2006.
[I-D.ietf-mpls-tp-identifiers] Bocci, M. and G. Swallow, "MPLS-TP
Identifiers", "draft-ietf-mpls-tp-identifiers-01", work in
progress.
7.2. Informative References
[SEG-PW] Luca Martini, et al., "Segmented Pseudowire", "draft-ietf-
pwe3-segmented-pw-15.txt", work in progress.
[TP-CP-FWK] Loa Andersson, Lou Berger, Luyuan Fang, Nabil Bitar,
"MPLS-TP Control Plane Framework", "draft-ietf-ccamp-mpls-
tp-cp-framework", work in progess.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3473] L. Berger, "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling", RFC 3473, January 2003.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
Chen, et al. Expires April 25, 2011 [Page 10]
Internet-Draft PW to LSP Binding October 2010
Authors' Addresses
Mach(Guoyi) Chen
Huawei Technologies Co., Ltd.
No. 3 Xinxi Road
Shangdi Information Industry Base
Hai-Dian District, Beijing 100085
China
EMail: mach@huawei.com
Wei Cao
Huawei Technologies Co., Ltd.
No. 3 Xinxi Road
Shangdi Information Industry Base
Hai-Dian District, Beijing 100085
China
EMail: caoweigne@huawei.com
Attila Takacs
Ericsson
Laborc u. 1.
Budapest, 1037
Hungary
EMail: attila.takacs@ericsson.com
Chen, et al. Expires April 25, 2011 [Page 11]
