Internet DRAFT - draft-bao-ccamp-pw-transfer
draft-bao-ccamp-pw-transfer
Network Working Group Yuanlin Bao
Internet-Draft Lizhong Jin
Intended status: Informational ZTE Corporation
Expires: January 13, 2011 Ruiquan Jing
Xiaoli Huo
China Telecom
Jul 12, 2010
LDP Extensions for Pseudo Wire (PW) Transfer in an MPLS-TP Network
draft-bao-ccamp-pw-transfer-01.txt
Abstract
As defined in [RFC5654] MPLS-TP transport path includes LSP and PW.
And the possibility of transferring the ownership and control of an
existing and in-use path between the management plane and the control
plane, without actually affecting data plane traffic being carried
over it, is a valuable option for carrier. [RFC5493] and [RFC5852]
describe the LSP transfer. This memo gives the requirement and LDP
extensions for PW transfer in an MPLS-TP network.
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 January 13, 2011.
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
Yuanlin Bao, et al. Expires January 13, 2011 [Page 1]
Internet-Draft LDP Extension for PW Transfer Jul 2010
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Comparison with Make-before-Break . . . . . . . . . . . . 3
1.2. Conventions used in this document . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of the PW Transfer . . . . . . . . . . . . . . . . . 5
4. Requirements for PW Transfer . . . . . . . . . . . . . . . . . 5
5. LDP Extension for PW Transfer . . . . . . . . . . . . . . . . 6
5.1. LDP Extension . . . . . . . . . . . . . . . . . . . . . . 6
5.1.1. Support PW Transfer with LDP . . . . . . . . . . . . . 6
5.1.2. PW Ownership Transfer TLV . . . . . . . . . . . . . . 7
5.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2.1. PW Ownership Transfer from MP to CP . . . . . . . . . 7
5.2.1.1. MP2CP PW Transfer Failure . . . . . . . . . . . . 8
5.2.2. PW Ownership Transfer from CP to MP . . . . . . . . . 9
5.2.2.1. CP2MP PW Transfer Failure . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Yuanlin Bao, et al. Expires January 13, 2011 [Page 2]
Internet-Draft LDP Extension for PW Transfer Jul 2010
1. Introduction
As defined in [RFC5654], MPLS-TP transport path corresponds to an LSP
or a PW which is beared in an LSP. And LSP includes unidirectional
LSP, co-routed bidirectional LSP and associated bidirectional LSP,
while PW includes Single-Segment Pseudowire (SS-PW) and Multi-Segment
Pseudowire (MS-PW).
For MPLS-TP LSP, it can be created/deleted via GMPLS signaling, see
[RFC3945]. However, the creation/deletion of PW can be completed by
LDP, and [RFC4447] gives these procedures of SS-PW while [SEG-PW] and
[DYNAMIC-MS-PW] decribes the ones of MS-PW.
Nowdays, some service providers have deployed MPLS-TP network for
mobile backhaul. But, most of the MPLS-TP paths are statically
configured by management plane in the first stage. So, it is
desirable for provider to transfer the control of paths from the
management plane (MP) to control plane (CP) in future. In addition,
the control transfer in the opposite direction, from CP to MP should
be possible as well.
Both the requirement 55 in [RFC5654] and requirement 47 in [MPLS-TP-
CP-FWK] state that an MPLS-TP control plane MUST provide a mechanism
for dynamic ownership transfer of the control of MPLS-TP transport
paths from the management plane to the control plane and vice versa.
Furthermore, section 5.3.3 of [MPLS-TP-CP-FWK] describes the
requirement for PW transfer. So, this memo considers the detailed
requirements for PW transfer, and the corresponding LDP extensions is
also described.
1.1. Comparison with Make-before-Break
The Make-Before-Break (MBB) technology is an alternative method for
PW transfer which has three steps. Firstly, a new PW (has the same
parameters with the one to be transferred) will be created; then the
PW will be switched from old PW to the new one; and after the PW
switching completed successfully the old PW will be deleted. From
this process, we can find there're many drawbacks with MBB.
The creation and swithing steps of MBB will lead to instant
interruption;. Although, it is acceptable if the instant
interruption can be controlled within 50ms, but this has a strict
requirement for equipment. Furthermore, extra resource is need, in
the circumstance that the network is almost saturate, there maybe not
enough resource for the new PWs, so MBB will be unavailable.
Otherwise, MBB will lead to label modification which will make the
bundling relationship between PW and LSP must modified at the same
time. This will triggre many problems, and a new detection mechanism
Yuanlin Bao, et al. Expires January 13, 2011 [Page 3]
Internet-Draft LDP Extension for PW Transfer Jul 2010
needs to be defined which may be very complex. In addition, since
control plane is used to create the new PW while management plane is
responsible for the deletion of the old PW. Thus batch operation
cann't be used for this process. If there're a large number PWs
needed to be transfered, the operator's time will be engaged by this
tedious operation which is inefficiency. However, the PW transfer
method described in this document will not affect the data plane, the
traffic and it's configuration. So it's preference for PW transfer.
However, the PW transfer method described in this document will not
affect the data plane, the traffic and it's configuration. So it's
preference for PW transfer.
1.2. 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 [RFC2119].
2. Terminology
o Transport Path: A network connection as defined in G.805
[ITU.G805.2000]. In an MPLS-TP environment, a transport path
corresponds to an LSP or a PW (see [RFC5654]).
o Single-Segment Pseudowire (SS-PW): A PW setup directly between two
T-PE devices. Each PW in one direction of a SS-PW traverses one
PSN tunnel that connects the two T-PEs.
o Multi-Segment Pseudowire (MS-PW): A static or dynamically
configured set of two or more contiguous PW segments that behave
and function as a single point-to-point PW. Each end of a MS-PW
by definition MUST terminate on a T-PE.
o PW Segment: A part of a single-segment or multi-segment PW, which
traverses one PSN tunnel in each direction between two PE devices,
T-PEs and/or S-PEs.
o Resource Ownership: A resource used by an MPLS-TP path is said to
be 'owned' by the plane that was used to set up the MPLS-TP path
through that part of the network. So, a resource owned by the
management/control plane means the resource was used to set up the
MPLS-TP path through the management/control plane. See [RFC5493]
for detailed description.
Yuanlin Bao, et al. Expires January 13, 2011 [Page 4]
Internet-Draft LDP Extension for PW Transfer Jul 2010
3. Overview of the PW Transfer
The PW transfer includes two reverse procedures. One is the MP to CP
(MP2CP) transfer procedure, another is the CP to MP (CP2MP) transfer
procedure.
For MP2CP transfer procedure, a PW set up and owned by MP needs to be
transferred to CP control. To conduct this transfer, the T-LDP
session will be created in CP for PW. After this transfer procedure,
the resource ownership must be transferred, that is the resource
owned by MP will be transferred to CP.
The CP2MP transfer procedure is the reverse one compared to MP2CP
procedure. However, since a LDP session may be shared by multi PWs,
the T-LDP session may be retained after one PW transferring from CP
to MP, if there're still another PWs remain untransferred. So, the
CP2MP procedure needs to check whether this signaling session should
be retained or not.
As an requirement listed in [RFC5493], during both MP2P and CP2MP
transfer procedures, if PW is carrying traffic, its control transfer
has to be done without any disruption to the data plane traffic.
Furthermore, both MP2CP and CP2MP transfer procedures can be
conducted in a batch manner, that is, multiple LSPs or PWs can be
transferred all at one time. For example, all PWs on a node can be
transferred at one time. However, this transfer manner is out of
this document.
4. Requirements for PW Transfer
[RFC5493] describes the requirements for the conversion between
permanent connection (PC) and switched connection (SC) in a GMPLS
network. The terminologies "PC" and "SPC" come from ITU-T standard
[G.8081], Because associated bidirectional LSP isn't defined in ITU-T
standard. So, both PC and SPC can only be considered as
unidirectional LSP and co-routed bidirectional LSP. Therefore, these
requirements fully apply to unidirectional LSP and co-routed
bidirectional LSP in a MPLS-TP network. Although, some requirements
defined in [RFC5493] apply to PW, but other new requirements also
need to be explored.
This section lists the special requirements for PW transfer.
Yuanlin Bao, et al. Expires January 13, 2011 [Page 5]
Internet-Draft LDP Extension for PW Transfer Jul 2010
1) PW attributes MUST not be changed
The PW attributes, such as bandwith, PWid , PW type, Control
Word, VCCV, Interface Parameter, MUST not be changed during and
after the PW transfer.
2) PW transfer MUST be independent of LSP
The PW transfer SHOULD not depend on whether the LSP (bearing
this PW) is controlled by MP or CP. Since PW transfer procedure
will not impact the data plane path, so PW transfer MUST leave
LSP alone. The relationship between PW and LSP MUST NOT be
changed.
3) Support partial MS-PW segments transfer
Since a MS-PW transit multi domains and these domains may belong
to different providers. In this scenario, if some providers have
deployed control plane while others not, the PW segments in these
domains that control plane are deployed SHOULD be allowed to
transfer between MP and CP while other PW segments keep their
original states.
5. LDP Extension for PW Transfer
5.1. LDP Extension
5.1.1. Support PW Transfer with LDP
A new Capability Parameter TLV is defined, the PW Transfer
Capability. Following is the format of the PW Transfer Capability
Parameter.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|PW Transfer Capability(TBD)| Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Reserved |
+-+-+-+-+-+-+-+-+
Figure 1: PW Transfer Capability
The PW Transfer Capability TLV MUST be supported in the LDP
Initialization Message([RFC5561]). Advertisement of the PW Transfer
Capability indicates support of the procedures for PW transfer
between MP and CP detailed in this document. If the peer has not
Yuanlin Bao, et al. Expires January 13, 2011 [Page 6]
Internet-Draft LDP Extension for PW Transfer Jul 2010
advertised the corresponding capability, then no PW transfer label
messages should be sent to the peer.
5.1.2. PW Ownership Transfer TLV
To ensure the PW ownership transfer between MP and CP automatically,
T-PE/S-PE SHOULD has the knowledge of the PW transfer signaling
message. So, the PW path and PW transfer indication MUST be carried
in the LDP Label Mapping message.
Since [SEG-PW] has defined PW switching point TLV (S-PE TLV) and Sub-
TLV to the switching points that the PW traverses, so these TLV and
Sub-TLV can be used to carry the PW path. Therefore, this section
only defines a new LDP TLV - Transfer TLV - which can be used to
indicate a PW transfer signaling procedure.
The PW Ownership Transfer TLV (PW-OH TLV), is defined as follows (TLV
type needs to be assigned by IANA):
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| PW Transfer (0x0105) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|POT| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: PW Ownership Transfer TLV
POT (2 bits): PW Ownership Transfer. PE MUST carry this TLV in
LDP Label Mapping and Notification message defined in [RFC5036]
when transferring from MP to CP, or CP to MP. The value of POT
is following:
1 - PW ownership transfer from management plane to control plane
2 - PW ownership transfer from control plane to management plane
Reserved(30 bits): This field MUST be set to zero on transmission
and MUST be ignored on receipt.
5.2. Procedures
5.2.1. PW Ownership Transfer from MP to CP
Before transferring from MP to CP, there MUST be a T-LDP session
between two T-PE for SS-PW, or T-PE and S-PE for MS-PW. During the
LDP initialization stage, the LDP speaker MUST announce it's PW
Yuanlin Bao, et al. Expires January 13, 2011 [Page 7]
Internet-Draft LDP Extension for PW Transfer Jul 2010
transfer capability according to [RFC5561] by sending the peer a
Capability message carrying the PW transfer capability TLV.
To conduct the MP2CP PW transfer, operator sends the MP2CP PW
transfer command to the source and destination T-PEs which will
inform MP and CP to initiate the MP2CP PW transfer process. When CP
gets all the information of the PW to be transferred , the CP of
source and destination nodes will build the LDP mapping message based
on the procedures described in [RFC4447], and send the mapping
message to its peer T-PE or S-PE.
The differences between the normal and the MP2CP PW transfer Label
Mapping message are:
1. PW-OH TLV with POT value equals 1 will be encoded into the
"Optional Parameters" of the Mapping message for both SS-PW and
MS-PW MP2CP transfer.
2. For MS-PW, the PW path will be encoded into S-PE TLVs and Sub-
TLVs with local S-PE address according to [SEG-PW].
When the Label Mapping message is build up, it will be send to
source/destination T-PE for SS-PW and to S-PE for MS-PW.
For SS-PW, when the source/destination T-PE receives the MP2CP PW
transfer Label Mapping message, and also send MP2CP PW transfer Label
Mapping message to its peer, it will transfer the PW control from MP
to CP.
For MS-PW, when the S-PE receives the MP2CP PW transfer Label Mapping
message, it will decode the next hop S-PE from local IP address Sub-
TLVs in S-PE TLVs then forward this Label Mapping message to the next
hop S-PE. Only when S-PE receive the MP2CP PW transfer label mapping
message from the reverse direction of PW, it will transfer the PW
control from MP to CP. When the source/destination T-PE receives the
MP2CP PW transfer Label Mapping message, it will deal with it in the
same way as SS-PW described above.
5.2.1.1. MP2CP PW Transfer Failure
If T-PEs or S-PE fail to PW transfer capability negotiation, the
procedures in [RFC5561] SHOULD be performed.
Since T-LDP runs over TCP, and there is only one hop between T-PEs in
SS-PW, if the T-LDP sesseion is created successfully, the PW transfer
Label Mapping can be sent and received reliably.
For MS-PW, if one of the PW segment fails to transfer from MP to CP,
Yuanlin Bao, et al. Expires January 13, 2011 [Page 8]
Internet-Draft LDP Extension for PW Transfer Jul 2010
a Notification message SHOULD be sent to source/destionation T-PE to
report the failure. And the PW segments successfully transferred
SHOULD be remained.
5.2.2. PW Ownership Transfer from CP to MP
Since multiple PWs can share a single T-LDP session, when a PW
transferred from CP to MP, the LDP session may be retained for other
PWs. So when a PW transfers from CP to MP, a Notification message
carring the corresponding PW FEC and PW-OH TLV with the POT value
equals 2 SHOULD be send out. All the other S-PEs along the PW
received this Notification message, SHOULD send the notification
message to next hop S-PE. Only when S-PE receives notification
message from reverse direction of PW, it will transfer the PW control
from CP to MP and remain the corresponding LDP session. When there
is no PW, the session MAY be still remained for the future use.
Thus, whether to delete the LDP session depends on the provider's
policy. If the provider want to delete the LDP session in which
there is no PW, the procedures in [RFC5036] can be conducted.
5.2.2.1. CP2MP PW Transfer Failure
Since the PW transfer capability is negotiated before T-LDP session
set up, and the T-LDP runs over TCP, CP2MP PW transfer can be
performed reliably.
For MS-PW, if one PW segment fails to transfer from CP to MP, a
Notification message SHOULD be sent to source/destionation T-PE to
report the failure.
6. Security Considerations
[RFC5036] and [RFC4447] describe the security considerations that
apply to the T-LDP specification. The same security framework and
considerations apply to the capability mechanism described in this
document.
7. IANA considerations
TBD.
8. Acknowledgements
The authors would like to thank Weilian Jiang, and Kan Hu for their
useful comments.
Yuanlin Bao, et al. Expires January 13, 2011 [Page 9]
Internet-Draft LDP Extension for PW Transfer Jul 2010
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5493] Caviglia, D., Bramanti, D., Li, D., and D. McDysan,
"Requirements for the Conversion between Permanent
Connections and Switched Connections in a Generalized
Multiprotocol Label Switching (GMPLS) Network", RFC 5493,
April 2009.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
Le Roux, "LDP Capabilities", RFC 5561, July 2009.
[RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N.,
and S. Ueno, "Requirements of an MPLS Transport Profile",
RFC 5654, September 2009.
9.2. Informative References
[DYNAMIC-MS-PW]
Luca Martini, Matthew Bocci, and Florin Balus, "Dynamic
Placement of Multi Segment Pseudo Wires",
draft-ietf-pwe3-dynamic-ms-pw-10.txt .
[G.8081] International Telecommunications Union, "Terms and
definitions for Automatically Switched Optical Networks
(ASON)", Recommendation G.8081/Y.1353, June 2004 .
[MPLS-TP-FWK]
M. Bocci and S. Bryant etc., "A Framework for MPLS in
Transport Networks", draft-ietf-mpls-tp-framework-11.txt .
Yuanlin Bao, et al. Expires January 13, 2011 [Page 10]
Internet-Draft LDP Extension for PW Transfer Jul 2010
[SEG-PW] Luca Martini and Chris Metz, "Segmented Pseudowire",
draft-ietf-pwe3-segmented-pw-13.txt .
[TP-CP-FWK]
Loa Andersson, Lou Berger, and Luyuan Fang, "MPLS-TP
Control Plane Framework",
draft-ietf-ccamp-mpls-tp-cp-framework-02.txt .
Authors' Addresses
Yuanlin Bao
ZTE Corporation
5F, R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road,
Nanshan District, Shenzhen 518055
P.R.China
Phone: +86 755 26773731
Email: bao.yuanlin@zte.com.cn
URI: http://www.zte.com.cn/
Lizhong Jin
ZTE Corporation
889, Bibo Road, Pudong District
Shanghai 201203
P.R.China
Email: lizhong.jin@zte.com.cn
URI: http://www.zte.com.cn/
Ruiquan Jing
China Telecom
Email: jingrq@ctbri.com.cn
Xiaoli Huo
China Telecom
Email: huoxl@ctbri.com.cn
Yuanlin Bao, et al. Expires January 13, 2011 [Page 11]
