PWE3 Working Group Wei, Cao
Internet Draft Huawei Technologies
Expires: April 2009 October 27, 2008
Setup of Pseudowires over bi-directional LSP
draft-cao-pwe3-setup-over-bidir-lsp-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is
aware have been or will be disclosed, and any of which he or she
becomes aware will be disclosed, in accordance with Section 6 of
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
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 27, 2009.
Abstract
In MPLS and MPLS-TE environments pseudo wires use two unidirectional
LSPs as PSN tunnels, the two PEs select LSP tunnels independently. In
contrast the MPLS-TP environment supports both bidirectional and
unidirectional LSPs and PWE may, therefore, use bidirectional LSPs as
PSN tunnels.
In order to use MPLS-TP bidirectional LSPs as a PSN tunnels for
pseudo wires some modification of the pseudowire signaling procedures
Wei Cao Expires April 27, 2009 [Page 1]
Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008
is required. This draft specifies an extension to LDP that ensures
pseudo-wires are correctly constructed over bi-directional LSPs.
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.
Table of Contents
1. Introduction................................................3
1.1. Motivations and scenarios...............................3
1.2. Scope of this document..................................4
2. Applicability Statement......................................4
2.1. SS-PW architecture......................................4
2.2. MS-PW architecture......................................5
3. LDP Extensions..............................................6
3.1. Bi-directional LSP TLV..................................6
4. SS-PW Signaling Procedures...................................8
4.1. Active/Passive PE Signaling Procedure...................9
4.1.1. Active PE Signaling Procedure......................9
4.1.2. Passive PE Signaling Procedure.....................9
4.2. Active/Active PE Signaling Procedure....................9
5. Security Considerations.....................................10
6. IANA Considerations........................................10
7. Acknowledgments............................................10
8. References.................................................10
8.1. Normative References...................................10
8.2. Informative References.................................10
Author's Addresses............................................11
Intellectual Property Statement................................11
Disclaimer of Validity........................................12
Copyright Statement...........................................12
Acknowledgment................................................12
Wei Cao Expires April 27, 2009 [Page 2]
Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008
1. Introduction
The requirements for Transport Network have been discussed in ITU-T
for a number of years and a set of T-MPLS documents has been
published. With the progress of the IETF and ITU-T Join Work Team
(JWT), IETF will design a series of protocol based on current MPLS
technology to meet T-MPLS requirement. The solution is called MPLS-TP.
One significant change brought about by MPLS-TP is that LSPs may be
bi-directional. Bi-directional LSPs have many advantages compared to
traditional unidirectional LSP particularly since most of the upper
layer services that will use them are bi-directional. Because most of
the current application protocols are designed to use unidirectional
LSPs, some adaptations are required when bi-directional LSPs are
introduced. Pseudo wire is the most important application for MPLS-TP.
This draft describes the necessary LDP extensions and signaling
procedures to allow migration of PW service from traditional MPLS
network to MPLS-TP enabled transport network.
1.1. Motivations and scenarios
Pseudo Wire Emulation Edge-to-Edge (PWE3) is a mechanism to emulate a
number of layer 2 services, such as ATM, Frame Relay or Ethernet, etc.
Such services are emulated between two ACs and the PW encapsulated
layer 2 service payload is carried by PSN tunnels between PEs. Today
PWE3 generally uses two reverse unidirectional LDP/RSVP-TE LSPs as
PSN tunnels. The possibility of asymmetric routing of the reverse
LSPs and the lack of effective OAM mechanisms make it hard for
unidirectional LSPs to meet the high QOS requirement of emulated
layer 2 services. MPLS-TP is designed for transport networks and
provides bi-directional LSPs which guarantee symmetric routing of
both directions of the LSP. PWE3 is believed to be one of the most
important applications for MPLS-TP.
In the current architecture the two PW PEs select LSPs independently,
the only requirement being that the LSP selected terminates on the
'other' PE. There is no architectural provision or requirement to
associate a pseudowire with a PSN tunnel. In contrast, when bi-
directional MPLS-TP LSPs are available and we want to run a PW over
one of them, the PEs must make sure they select the same LSP for the
PW; this is especially true when there are multiple bi-directional
LSPs between the two PEs One possible method is binding the PSN
tunnel manually at each PE but this is prone to configuration
mistakes 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 based on [RFC4447].
Wei Cao Expires April 27, 2009 [Page 3]
Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008
1.2. Scope of this document
This document discusses LDP extensions to allow automatic signaling
support for deployment of a large number of PWs. Static configuration
is operator/vendor specific and is not discussed here.
There are two types of PW defined in IETF: single segment PW and
multi-segment PW. This document will cover both types of PW.
As previously stated the original motivation for this work was a
recognition that the MPLS-TP bi-directional LSP is essentially
unusable by PWE application without extensions to the signaling
mechanisms. We now believe that the LSP selection mechanism described
here may be useful in existing MPLS networks and for other
applications in addition to PWE. We will address these scenarios in a
future version of this document.
The method proposed in this draft is based on [RFC4447] and does not
modify existing pseudowire or LSP constructs.
2. Applicability Statement
Migration from existing MPLS PWE3 networks to MPLS-TP enabled
networks will occur over an extended period and it is important to
keep the new solution as compatible as possible with existing
solutions. In keeping with PW architecture, we wish to minimize the
modification of or extensions to current protocols.
2.1. SS-PW architecture
Figure 1 illustrates the reference model derived from [RFC3985] which
supports single segment PW emulated services. PEs (PE1 and PE2)
provide one or more PWs for their CEs (CE1 and CE2) to enable the
client CEs to communicate over the PSN. The PSN network uses Bi-
directional MPLS-TP LSP to provide a data path for the PW service.
In this model both PE1 and PE2 both support bi-directional LSPs. It
is important for higher layer services to be able choose the same bi-
directional LSP at both PEs. This is a problem when one or more LSP
exist between them; multiple LSPs may be used to provide different
levels of QOS or provide protection.
As an example, when PE1 expects to setup the PW on a bi-directional
LSP; it chooses a bi-directional LSP for the PW, and then sends a
Label Mapping message to PE2. Because there is currently no mechanism
for PE2 to learn the bi-directional LSP information (or indeed any
Wei Cao Expires April 27, 2009 [Page 4]
Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008
unidirectional LSP information), from the mapping message, it may
choose another bi-directional LSP for the same PW. With this
restriction different bi-directional LSPs could be selected for one
PW by the two PEs. Similar problem can occur if unidirectional LSP
coexists with MPLS-TP bi-directional LSP.
|<----------- Emulated Service ------------->|
| |
| |<------- Pseudowire ------->| |
| | | |
| | |<-Bi-directional->| | |
| V V LSP Tunnel V V |
V +----+ +----+ V
+-----+ | PE1|==================| PE2| +-----+
| |-------|............PW1.............|-------| |
| CE1 | | | | | | CE2 |
| |-------|............PW2.............|-------| |
+-----+ | |==================| | +-----+
+----+ +----+
Figure 1: SS-PW Reference Model
2.2. MS-PW architecture
Figure 2 extends the SS-PW architecture to show a multi-segment case.
The PEs that provide PW to CE1 and CE2 are Terminating-PE1 (T-PE1)
and Terminating-PE2 (T-PE2) respectively. The PE that joints PW
segment 1 and segment 2 is called Switching-PE1 (SPE1). It is assumed
that TPE1 and TPE2 need to setup PW segments on bi-directional LSPs.
For PW segment 1, S-PE1 does not know which bi-directional LSP is
selected by T-PE1. As a consequence S-PE1 may select another bi-
directional LSP or a unidirectional LSP for the reverse path to T-PE1.
For PW segment 2, the similar issues arise between SPE-1 and TPE-2.
Wei Cao Expires April 27, 2009 [Page 5]
Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008
|<------Multi-Segment Pseudowire------>|
| Bi-dir. Bi-dir. |
| |<-LSP 1->| |<-LSP 2 ->| |
V V V V V V
+----+ +-----+ +----+
+----+ |TPE1|===========|SPE1 |==========|TPE2| +----+
| |------| | | | | |-------| |
| CE1| |..... PW.Seg't1.........PW.Seg't2.....| |CE2 |
| |------| | | | | |-------| |
+----+ | |===========| |==========| | +----+
^ +----+ +-----+ +----+ ^
| Provider Edge 1 Provider Edge 2 |
| |
|<------------------ Emulated Service --------------->|
Figure 2: MS-PW Reference Model
The key point of our solution is to eliminate the problems
illustrated above, we do this by enabling the target PE to learn the
bi-directional LSP selected by the Mapping sender.
3. LDP Extensions
Before sending a Label Mapping message to setup a PW, PE has selects
a bi-directional LSP for the PW. We introduce a bi-directional LSP
TLV to allow the identity of this bi-directional LSP to be
communicated to the target PE.
3.1. Bi-directional LSP TLV
The bi-directional LSP TLV specifies a bi-directional LSP which is
selected by the sending PE. This TLV is contained in a Generalized PW
FEC (FEC129) or PW ID FEC (FEC128) and sent to the target PE in the
Label Mapping message. Note that sending the bi-directional LSP TLV
is OPTIONAL, but the target PE must process the TLV upon reception.
The proposed format of the bi-directional LSP TLV is as follows:
Wei Cao Expires April 27, 2009 [Page 6]
Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008
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| bi-dir. LSP TLV (TBD) | bi-dir. LSP TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel Extended ID (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure3 IPv4 bi-directional LSP 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| bi-dir. LSP TLV (TBD) | bi-dir. LSP TLV Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 Extended Tunnel ID (optional) |
+ +
| (16bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel end point address |
+ +
| (16bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel sender address |
+ +
| (16bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure4 Ipv6 bi-directional LSP TLV format
- Bi-directional LSP TLV Length
Wei Cao Expires April 27, 2009 [Page 7]
Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008
Specifies the total length of the bi-directional LSP TLV fields in
octets
- Variable Length Value
In an MPLS-TP network, a bi-directional LSP established by RSVP-TE
signaling can be identified using a SESSION object and a
SENDER_TEMPLATE object, see [RFC3209]. The SESSION object carries the
tunnel destination IP address and the tunnel ID to identify a tunnel.
The SENDER_TEMPLATE object carries the source IP address of the
tunnel and the LSP ID to identify a LSP. This document specifies the
following Variables to be included in LSP TLV; their meanings are
same in SESSION object and SENDER_TEMPLATE object:
- LSP ID
- Tunnel ID
- IPv4/IPv6 tunnel Extended ID (optional)
- IPv4/IPv6 tunnel end point address
- IPv4/IPv6 tunnel sender address
To identify an IPv4 tunnel, following Variables should be included in
the bi-directional LSP TLV: < LSP ID, Tunnel ID, IPv4 tunnel end
point address, IPv4 tunnel sender address >. In order to indicate a
globally unique tunnel, IPv4 Extended Tunnel ID may also be used.
To identify an IPv6 tunnel, following variables should be included in
the bi-directional LSP TLV: < LSP ID, Tunnel ID, IPv6 tunnel end
point address, IPv6 tunnel sender address>. In order to indicate a
globally unique tunnel, IPv6 Extended Tunnel ID may also be used.
4. SS-PW Signaling Procedures
PE1 and PE2, known as "LDP Peers", use Label Mapping messages to
exchange PW information with each other. Depending on the role they
play in the selection of a bi-directional LSP, we identify two types
of PEs:
a) Active PE: the PE which initiates the selection of a bi-
directional LSP and informs the remote PE;
b) Passive PE: the PE which obeys the active PE's suggestion
If the two PEs both assume the active role in signaling an LSP for
the same PWE then competition (a signaling collision) occurs. In this
Wei Cao Expires April 27, 2009 [Page 8]
Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008
case, the two PEs should obey a predefined rule to decide which bi-
directional LSP will be used,
4.1. Active/Passive PE Signaling Procedure
4.1.1. Active PE Signaling Procedure
Before sending the Mapping Message, the active PE, say PE1, must
select a bi-directional LSP for the PW. This indicates that PW will
be carried through the selected bi-directional LSP tunnel. PE1
generates a "bi-directional LSP TLV" that identifies the selected LSP
and sends a Mapping message containing it to the passive PE, in this
case PE2.
4.1.2. Passive PE Signaling Procedure
When a Label Mapping message carrying a bi-directional LSP TLV is
received by PE2 it may decide, based on local policy and/or success
or failure in matching the LSP to accept or reject it.
If the bi-directional LSP cannot be matched successfully or if local
policy prohibits its acceptance, a Label Release message must be sent,
with an "Unassigned/Unrecognized bi-directional LSP" code, and the
processing of the Label Mapping message is complete.
If the bi-directional LSP proposed by PE1 is accepted by PE2 then PE2
attempts setup of the PW in the opposite (PE2->PE1) direction. If PE2
has not already signaled for the opposite direction, it sends a Label
Mapping message to PE1, with a "bi-directional LSP TLV" that
identifies the same bi-directional LSP, proposed by PE1, that it has
accepted for this PW.
If PE1 receives a Label Mapping message in which "bi-directional LSP"
is equal to the bi-directional LSP it selected then both directions
of the PW are setup.
4.2. Active/Active PE Signaling Procedure
Sometimes, before PE2 receives the Label Mapping message, it has
already sent a Label Mapping message to PE1. If the bi-directional
LSP in the received message from PE1 is as same as it was in the
message sent by PE2 then the signaling has converged on an mutually
agreed LSP and is completed. Otherwise, when the bi-directional LSP
selected by PE1 differs from the LSP selected by PE2, PE1 and PE2
have to make a choice between two LSPs. In this case both PE1 and PE2
have assumed 'active' roles and they must have the capability to
resolve this contention. In this case PE1 and PE2 will compare the
node ID in the received mapping messages with their own node ID. ,
Wei Cao Expires April 27, 2009 [Page 9]
Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008
The LSP selected by the node with higher ID will be determined to
carry PW.
MS_PW signaling procedures - TBD.
5. Security Considerations
TBD
6. IANA Considerations
TBD
7. Acknowledgments
Many thanks to my colleague 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.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[RFC5036] Andersson, L., Ina Minei and Thomas, B., "LDP Specification",
RFC5036, October 2007.
[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.
8.2. Informative References
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3)
Architecture", RFC 3985, March 2005.
[MS-PW-ARCH] Matthew Bocci and Stewart Bryant, "An Architecture for Multi-Segment
Pseudowire Emulation Edge-to-Edge "
Wei Cao Expires April 27, 2009 [Page 10]
Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008
[MPLS-TP] ITU-T - IETF Joint Working Team, Dave Ward and Malcolm Betts,"MPLS
Architectural Considerations for a Transport Profile", "http://www.ietf.org/MPLS-
TP_overview-22.pdf", April 2008
[MPLS-TP-FWK] Matthew Bocci,et al., "A Framework for MPLS in Transport Networks",
"draft-bld-mpls-tp-framework", July 2008.
Author's Addresses
Wei Cao
Huawei Technologies Co., Ltd.
Huawei Building., No.3 Xinxi Rd.
Shang-Di Information Industry Base
Hai-Dian Distinct, Beijing 100085
China
Email: caowayne@huawei.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Wei Cao Expires April 27, 2009 [Page 11]
Internet-Draft Setup of Pseudowires over bi-dir LSP October 2008
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Wei Cao Expires April 27, 2009 [Page 12]