One document matched: draft-fuxh-mpls-tp-transfer-framework-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-fuxh-mpls-tp-transfer-framework-00" ipr="trust200902">
<front>
<title abbrev="Framework for MPLS-TP Ownership Transfer">Framework for MPLS-TP Ownership Transfer Between Management Plane and Control Plane</title>
<author fullname="Xihua Fu" initials="X" surname="Fu">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District</street>
<city>Xi An</city>
<code>710065</code>
<country>P.R.China</country>
</postal>
<phone>+8613798412242</phone>
<email>fu.xihua@zte.com.cn</email>
<uri>http://wwwen.zte.com.cn/</uri>
</address>
</author>
<author fullname="Yuanlin Bao" initials="Y" surname="Bao">
<organization>ZTE Corporation</organization>
<address>
<postal>
<street>5F,R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road</street>
<city>Nanshan District,Shenzhen</city>
<code>518055</code>
<country>P.R.China</country>
</postal>
<phone>+86 755 26773731</phone>
<email>bao.yuanlin@zte.com.cn</email>
<uri>http://wwwen.zte.com.cn/</uri>
</address>
</author>
<date year="2010"/>
<area>Routing</area>
<workgroup>Network Working Group</workgroup>
<keyword>Ownership Transfer</keyword>
<keyword>MPLS-TP</keyword>
<abstract>
<t>In MPLS-TP architecture, LSP and PW provisioning can be done either by Control Plane (CP) or Management Plane (MP). The MPLS-TP control plane must provide a mechanism for dynamic ownership transfer of the control of MPLS-TP transport paths from MP to CP and vice versa. [draft-bao-mpls-tp-path-transfer-reqs-00] defines requirement for MPLS-TP paths ownership transfer from MP to CP and vice versa.</t>
<t>This document provides a framework to allow the development of protocol extensions to support the MPLS-TP paths ownership transfer between MP and CP and vice versa.</t>
</abstract>
<note title="Conventions Used In This Document">
<t>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 <xref target="RFC2119">RFC 2119</xref>.
</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>In terms of MPLS-TP requirement, 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 (MP) to the Control Plane (CP) and vice versa. In MPLS-TP architecture, LSP and PW provisioning can be done either by Control Plane or Management Plane.</t>
<t>The MPLS-TP control plane must support unidirectional, associated bidirectional and co-routed bidirectional point-to-point transport paths. [RFC5493] defines the specific requirements for an LSP ownership transfer procedure. [PC-SPC] describes an extension to GMPLS RSVP-TE signaling that enables the LSP ownership transfer between the Management Plane and the Control Plane.</t>
<t>Ownership transfers of the forward and the backward directions belonging to the same associated bidirectional transport path can't be done in the same signaling procedure. Edge nodes (i.e., ingress, egress and intermediate) must be aware about the pairing relationship of the forward and the backward directions belonging to the same associated bidirectional transport path. Ownership transfer procedures of the forward and the backward directions must be associated. This document describes the ownership transfer related procedures for associated LSP.</t>
<t>[draft-bao-mpls-tp-path-transfer-reqs-00] defines the requirements for ownership transfer of existing PWs provisioned by NMS from the MP to the CP without disrupting user traffic flowing on them. This document describes the ownership transfer related procedures for PWs.</t>
</section>
<section title="Ownership Transfer Procedures">
<t>The ownership transfer of unidirectional and co-routed bidirectional LSPs is based on the [RFC5493] and [PC-SPC]</t>
<section title="Ownership Transfer Procedure for Associated LSP">
<section title="Associated LSP Ownership Transfer From MP to CP">
<t>Forward and backward paths belonging to the same associated LSP are signalled/routed independently in MPLS-TP networks. So ownership transfers from MP to CP of the forward and the backward directions belonging to the same associated bidirectional transport path can't be done in the same signaling procedure. But ownership transfer of each direction should be based on [RFC5493] and [PC-SPC].</t>
<t>In order to make edge nodes (i.e., ingress, egress and intermediate) be aware about the pairing relationship of the forward and the backward directions belonging to the same associated bidirectional transport path, ownership transfer procedures of the forward and the backward directions must be associated.</t>
<t>The ASSOCIATION object, as defined in RFC 4872 and RFC 4873 respectively, is used to provide end-to-end and segment recovery. Furthermore, draft-berger-ccamp-assoc-info-00.txt described how to utilize it in detail.</t>
<t>[draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-00] defines a mechanism to associated the forward and the backward direction LSPs to be an associated LSP. It extends the ASSOCIATION Object and defines a new Association Type. An ASSOCIATION object with an Association Type set to the value "Association" is used to bind two reverse unidirectional LSP to be an associated bidirectional LSP.</t>
<t>Any node originating the forward or backward direction LSP MUST insert an ASSOCIATION object with an Association Type set to the value "Association". The Association ID MUST be set to a value that uniquely identifies the reverse direction LSP. Egress or intermediate nodes MUST use ASSOCIATION object(s) with the Association Type set to the value "Association" to bind the two reverse unidirectional LSPs together.</t>
</section>
<section title="Associated LSP Ownership Transfer From CP to MP">
<t>Ownership transfers from CP to MP of the forward and the backward directions belonging to the same associated bidirectional transport path also can't be done in the same signaling procedure. But ownership transfer from CP to MP of each direction should be based on [RFC5493] and [PC-SPC].</t>
</section>
</section>
<section title="Ownership Transfer Procedures for PW">
<section title="PW Ownership Transfer From MP to CP">
<section title="SS-PW Ownership Transfer From MP to CP">
<t>SS-PW in MPLS-TP network signaling control plane is based on LDP with specific procedures defined in [RFC4447]. [Segmented-PW] and [MS-PW] allow for static switching of multi-segment pseudowires whereby signaling is still based on Targeted LDP (T-LDP). The ownership transfer procedure from MP to CP for PW (SS-PW and MS-PW) MUST create LDP sessions along the path which is transfered.</t>
<t>The ownership transfer procedure for SS-PW must create an LDP session between PE1 and PE2. The ownership transfer procecure for SS-PW MUST NOT cause any disruption of user traffic flowing over the PW whose control is being transferred. If the ownership transfer fails, the data plane MUST not be affected.</t>
<t>The operator can synchronously instruct PE1 and PE2 to transfer control of the PW from the MP to the CP. PE1 initiates the ownership transfer by sending a Label Mapping Message to the ingress PE (PE2). PE2 also initiates the ownership transfer by sending a Label Mapping Message to the ingress PE (PE1). The Label Mapping message contains an FEC TLV, a Label TLV, and optional parameter TLVs. The signaling procedure must be based on [RFC4447].</t>
<t>The Status TLV defined in [RFC3337] is transported to the remote PW peer via the LDP Notification message. [draft-bao-pw3-pw-transfer-ldp-ext-00] defines an LDP extension by adding a PW Ownership Handover TLV to provide a mechanism to identify the LDP message of ownership transfer. The Egress node originating the LDP Mapping message of ownership transfer must insert a PW Ownership Handover TLV with a flag set to the value "Handover". The ingress that receives a LDP message must use the flag set to the value "Handover" to identify ownership transfer. It should not do the FEC and Label Mapping anymore.</t>
<figure>
<artwork align="left">
<![CDATA[
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudowire ------->| |
| | | |
|Attachment| |<-- PSN Tunnel -->| |Attachment|
| Circuit V V V V Circuit |
V (AC) +----+ +----+ (AC) V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
native service native service
Figure 1: SS-PWE Reference Model]]>
</artwork>
</figure>
</section>
<section title="MS-PW Ownership Transfer From MP to CP">
<t>The ownership transfer procedure for MS-PW must also create LDP sessions between T-PE1 and S-PE1, S-PE1 and S-PE2, and the other one between S-PE2 and T-PE2.</t>
<t>The operator instructs T-PE1 to transfer control of the PW from the MP to the CP. In order to creat LDP sessions along the path of MS-PW, operator must give full information about the explicit route of MS-PW including the S-PEs (S-PE1 and S-PE2) traversed by PW.</t>
<t>The ownership transfer procedure of each PW segment is based on the section 2.2.1.1, but the Label Mapping message must carry the explicit route of MS-PW including S-PE1 and S-PE2 encoded in S-PE TLV. After S-PE1 receive the Label Mapping message, it needs to get the next S-PEs (S-PE2) from the S-PE TLV and create the LDP session between S-PE1 and S-PE2.</t>
<t>The node originating the LDP Mapping message of ownership transfer must insert a PW Ownership Handover TLV with a flag set to the value "Handover" defined in [draft-bao-pw3-pw-transfer-ldp-ext-00]. The ingress that receives a LDP Mapping message must use the flag set to the value "Handover" to identify ownership transfer. It should not do the FEC and Label Mapping anymore.</t>
<figure>
<artwork align="left">
<![CDATA[
Native |<---------------------- MS-PW ---------------------->| Native
Service | |<-PSN1-->| |<--PSN2->| |<--PSN3->| | Service
(AC) V V V V V V V V (AC)
| +-----+ +-----+ +-----+ +-----+
+----+ | |T-PE1| |S-PE1| |S-PE2| |T-PE2| | +----+
| | | | |=========| |=========| |=========| | | | |
| |------|......PW.Seg't1.......PW Seg't3.......PW Seg't5......|-----| |
| CE1| | | | | | | | | | | |CE2 |
| |------|......PW.Seg't2......|PW Seg't4......|PW Seg't6......|-----| |
| | | | |=========| |=========| |=========| | | | |
+----+ +-----+ +-----+ +-----+ +-----+ +----+
^ ^
| |
| |
|<----------------------- Emulated Service ----------------------->|
Figure 2: MS-PW switching Reference Model]]>
</artwork>
</figure>
</section>
</section>
<section title="PW Ownership Transfer From CP to MP">
<t>The CP has the ownership and control of the PW. The CP to MP transfer procedure MUST delete the existing LDP session information and MUST NOT affect the cross-connected resources, but just move their ownership to the MP.</t>
<section title="SS-PW Ownership Transfer From MP to CP">
<t>The ownership transfer procedure for SS-PW must delete the existing LDP session between PE1 and PE2. .</t>
<t>The operator can synchronously instruct PE1 and PE2 to transfer control of the PW from the CP to the MP. PE1 initiates the ownership transfer by sending a Label Withdraw message to the ingress PE (PE2). PE2 also initiates the ownership transfer by sending a Label Withdraw message to the ingress PE (PE1). The signaling procedure must be based on [RFC4447].</t>
<t>[draft-bao-pw3-pw-transfer-ldp-ext-00] defines an LDP extension by adding a PW Ownership Handover TLV to provide a mechanism to identify the LDP message of ownership transfer. The Egress node originating the Label Withdraw message of ownership transfer must insert a PW Ownership Handover TLV with a flag set to the value "Handover". The ingress that receives a Label Withdraw message must use the flag set to the value "Handover" to identify ownership transfer. There is no any action is taken over the Data Plane anymore.</t>
</section>
<section title="MS-PW Ownership Transfer From MP to CP">
<t>The ownership transfer procedure for MS-PW must also delete LDP sessions between T-PE1 and S-PE1, S-PE1 and S-PE2, and the other one between S-PE2 and T-PE2.</t>
<t>The operator instructs T-PE1 to transfer control of the PW from the CP to the MP. In order to delete LDP sessions along the path of MS-PW, the CP must give full information about the explicit route of MS-PW including the S-PEs (S-PE1 and S-PE2) traversed by PW.</t>
<t>The ownership transfer procedure of each PW segment is based on the section 2.2.2.1, but the Label Withdraw message must carry the explicit route of MS-PW including S-PE1 and S-PE2 encoded in S-PE TLV. After S-PE1 receive the Label Withdraw message, it needs to get the next S-PEs (S-PE2) from the S-PE TLV and delete the LDP session between S-PE1 and S-PE2.</t>
<t>The node originating the LDP Withdraw message of ownership transfer must insert a PW Ownership Handover TLV with a flag set to the value "Handover" defined in [draft-bao-pw3-pw-transfer-ldp-ext-00]. The ingress that receives a LDP Withdraw message must use the flag set to the value "Handover" to identify ownership transfer. There is no any action is taken over the Data Plane anymore.</t>
</section>
</section>
</section>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>TBD</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.3036'?>
<?rfc include='reference.RFC.5036'?>
<?rfc include='reference.RFC.4447'?>
<?rfc include='reference.RFC.5493'?>
<?rfc include='reference.RFC.5654'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.draft-ietf-ccamp-pc-spc-rsvpte-ext-07'?>
<?rfc include='reference.I-D.draft-ietf-pwe3-ms-pw-arch-07'?>
<?rfc include='reference.I-D.draft-abfb-mpls-tp-control-plane-framework-02'?>
<?rfc include='reference.I-D.draft-ietf-mpls-tp-framework-10'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:10:55 |