Network working group W. Cao
Internet Draft M. Chen
Category: Standards Track Huawei Technologies Co.,Ltd
Created: July 5, 2010 A. Takacs
Expires: January 2011 Ericsson
LDP extensions for Explicit Pseudowire to transport LSP mapping
draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp-00.txt
Abstract
Currently a Pseudowire (PW) uses two reverse unidirectional LSPs as
Packet Switching Network (PSN) tunnels, and each PE of a PW or
segment of MS-PW selects PSN tunnels independently. In contrast
MPLS-TP requires support for both bidirectional and unidirectional
LSPs. In addition some transport services may require bidirectional
traffic follows with congruent paths. Therefore, PWs may be required
to use PSN tunnels with congruent paths.
This document specifies some extensions to LDP that ensures both
ends of a PW (or segment PW) 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.
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.
Chen, et al. Expires January 5, 2011 [Page 1]
Internet-Draft PW to LSP Binding July 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.................................................2
2. PW to LSP Binding TLV........................................4
3. LDP Extensions...............................................6
3.1.1. Active/Active Signaling Procedures.................6
3.1.2. Active/Passive Signaling Procedures................7
4. Security Considerations......................................8
5. IANA Considerations..........................................8
5.1. LDP TLV Types...........................................8
5.2. LDP Status Codes........................................9
6. Acknowledgments..............................................9
7. References...................................................9
7.1. Normative References....................................9
7.2. Informative References..................................9
Authors' Addresses.............................................10
1. Introduction
Pseudo Wire (PW) Emulation Edge-to-Edge (PWE3) is a mechanism to
emulate a number of layer 2 services, such as Asynchronous Transfer
Mode (ATM), Frame Relay or Ethernet, etc. Such services are emulated
between two Attachment Circuits (ACs) and the PW encapsulated layer
2 service payload is carried through Packet Switching Network (PSN)
Chen, et al. Expires January 5, 2011 [Page 2]
Internet-Draft PW to LSP Binding July 2010
tunnels between Provider Edges (PEs). Today PWE3 generally uses two
reverse unidirectional Label Distribution Protocol (LDP) or Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE) LSPs as PSN
tunnels, and each of the PEs selects and binds PSN tunnel
independently. Today there is no architectural provision as there
has been no requirement to explicitly associate a PW with a 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 LSP(s). 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 underling LSPs. This is especially
true 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.
+----+ +--+ LSP1 +--+ +----+
+-----+ | PE1|===|P1|======|P2|===| PE2| +-----+
| |----| | +--+ +--+ | |----| |
| CE1 | |............PW1...............| | CE2 |
| |----| | +--+ | |----| |
+-----+ | |======|P3|==========| | +-----+
+----+ +--+ LSP2 +----+
Figure 1 SS-PW scenario
Above figure (Figure 1) is an example of this inconsistent binding
in Single-Segment PW (SS-PW) scenario. There are two bidirectional
LSPs (LSP1 and LSP2, along diverse paths) and a PW (PW1) 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 direction of
PE1->PE2 of PW1, and PE2 may select LSP2 (PE1-P3-PE2) as the PSN
tunnel for the direction of PE2->PE1 of PW1, so a PW is bound to two
separate bidirectional LSPs, this may not be desired in MPLS-TP
network. It still has the same problems in Multi-Segment PW (MS-PW)
scenario.
One possible method is binding 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].
Chen, et al. Expires January 5, 2011 [Page 3]
Internet-Draft PW to LSP Binding July 2010
2. PW to LSP Binding TLV
In this document two new OPTIONAL TLVs are defined: IPv4/IPv6 PW to
LSP Binding TLV. 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.
And the PW to LSP Binding TLV MAY be carried in an in-band MPLS-TP
OAM message that is identified by a new dedicated GACh channel type
when LDP is not used. This is for future study.
The proposed 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, a 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.)
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
Chen, et al. Expires January 5, 2011 [Page 4]
Internet-Draft PW to LSP Binding July 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| 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
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,
Chen, et al. Expires January 5, 2011 [Page 5]
Internet-Draft PW to LSP Binding July 2010
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 is defined as a 32-bits ID, but for a
MPLS/GMPLS TE based LSP, the Tunnel Extended 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 setup a PW or Segment PW,
a PE has to select candidate LSPs for PSN tunnel. The selected LSPs
are carried by the PW to LSP binding TLV and then sent with the
Label Mapping message to the target/switching PE. Therefore, there
may be some collisions of tunnel LSP selection when both PEs of the
PW or Segment PW assume active role and independently signal the PW
or Segment PW. 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;
b) Passive PE: the PE which obeys the active PE's suggestion.
The role of a PE is based on the role that it acts in the signaling
of the PW. There exist two situations:
Active/Active - Both PEs of a PW or Segment PW assume active (e.g.,
SS-PW, LDP using FEC 128 MS-PW).
Active/Passive - One PE is Active and the others are passive (e.g.,
LDP using FEC 129 MS-PW).
3.1.1. Active/Active Signaling Procedures
In 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 is completed. Otherwise, when the bidirectional LSP
selected by one PE (say PE1) differ from the bidirectional LSP
selected by the other PE (say PE2), PE1 and PE2 have to make a
Chen, et al. Expires January 5, 2011 [Page 6]
Internet-Draft PW to LSP Binding July 2010
choice between two tunnel LSPs. In this case PE1 and PE2 can compare
the Node ID and the LSP selected by the node with higher ID will be
determined to carry the PW.
In case of unidirectional LSPs, each PE may select an unidirectional
tunnel LSP that is used for its own forward direction of the PW and
send it with the Label Mapping message to each other, hence to help
the PEs to select two congruent unidirectional LSPs. The mechanisms
to determine which LSPs are used are out of scope. 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 higher Node ID will be determined as the tunnel.
3.1.2. Active/Passive Signaling Procedures
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.
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.
Chen, et al. Expires January 5, 2011 [Page 7]
Internet-Draft PW to LSP Binding July 2010
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
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 draft does not introduce any new security issues.
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 - TBD
IPv6 PW to LSP Binding TLV - TBD
Chen, et al. Expires January 5, 2011 [Page 8]
Internet-Draft PW to LSP Binding July 2010
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" - TBD
6. Acknowledgments
The authors would like to thank 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.
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.
[I-D.ietf-mpls-tp-identifiers] Bocci, M. and G. Swallow, "MPLS-TP
Identifiers", "draft-ietf-mpls-tp-identifiers-01", work in
progress.
Chen, et al. Expires January 5, 2011 [Page 9]
Internet-Draft PW to LSP Binding July 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 January 5, 2011 [Page 10]
