idnits 2.17.1 draft-bao-pwe3-pw-transfer-ldp-ext-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The source/destination T-PE completes the LDP initialization as the procedure described in [RFC5036] and [RFC4447]. After the LDP initialization, the source T-PE SHOULD sends a Label Mapping message with PW Ownership Transfer TLV in Optional Parameters to it's LDP peer the destination T-PE, and vis versa. When destination/source T-PE receives this PW transfer Label Mapping message, it only creates the LDP signaling state on the control plane, and any action for data plane MUST not be triggered. -- The document date (February 28, 2010) is 5170 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5659' is defined on line 247, but no explicit reference was found in the text == Unused Reference: 'MPLS-TP-CP' is defined on line 258, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-22) exists of draft-ietf-pwe3-dynamic-ms-pw-10 == Outdated reference: A later version (-02) exists of draft-abfb-mpls-tp-control-plane-framework-01 == Outdated reference: A later version (-18) exists of draft-ietf-pwe3-segmented-pw-13 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Yuanlin Bao 3 Internet-Draft Xihua Fu 4 Intended status: Informational Fei Zhang 5 Expires: September 1, 2010 ZTE Corporation 6 February 28, 2010 8 LDP Signaling Extension For Management Plane To Control Plane PW 9 Ownership Transfer In A MPLS-TP Network 10 draft-bao-pwe3-pw-transfer-ldp-ext-00.txt 12 Abstract 14 This memo describes an extension to LDP signaling that enables the PW 15 ownership transfer between the Management Plane and the Control 16 Plane. This document defines all PW transfer related procedures. 17 This includes the handling of failure conditions and subsequent 18 reversion to original state. A basic premise of the extension is 19 that the transfer procedures must never impact an already established 20 Data plane connection. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on September 1, 2010. 45 Copyright Notice 47 Copyright (c) 2010 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Conventions used in this document . . . . . . . . . . . . . 3 64 2. LDP Extension . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. PW Ownership Transfer TLV . . . . . . . . . . . . . . . . . 4 66 3. PW Transfer Procedure . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. PW Ownership Transfer from MP to CP . . . . . . . . . . . . 4 68 3.1.1. MS-PW specification . . . . . . . . . . . . . . . . . . 5 69 3.1.2. Failure Handling . . . . . . . . . . . . . . . . . . . 5 70 3.2. PW Ownership Transfer from CP to MP . . . . . . . . . . . . 5 71 3.2.1. Failure Handling . . . . . . . . . . . . . . . . . . . 5 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 73 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 77 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 80 1. Introduction 82 As defined in [RFC3985] PWE3 is a mechanism that emulates the 83 essential attributes of a telecommunications service (such as a T1 84 leased line or Frame Relay) over a PSN. Traditionally, pseudowir 85 (PW) are controlled by means of a Network Management System (NMS) 86 operating within the Management Plane (MP). NMS/MP is the owner of 87 PW, being responsible of it's set up, tear down and maintenance. 89 The adoption of a PW Control Plane ([RFC4447] and [DYNAMIC-MS-PW]) in 90 a network that is already in service - controlled by NMS at MP level 91 - introduces the need for a procedure able to coordinate a control 92 transfer of PW from MP to CP. 94 In addition, the control transfer in the opposite direction, from CP 95 to MP should be possible as well. The procedures described in this 96 memo can be applied to a PW in any DP switching technology and any 97 network architecture. 99 This memo describes an extension to LDP Protocol [RFC4447], [RFC5036] 100 signaling that enables the transfer of PW ownership between the 101 Management and the Control Planes. All transfer related procedures 102 are defined below. This includes the handling of failure conditions 103 and subsequent reversion to original state. A basic premise of the 104 extension is that the transfer procedures must never impact the 105 exchange of user data on PWs that are already established in the data 106 plane. 108 1.1. Conventions used in this document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 2. LDP Extension 116 To ensure the PW ownership transfer between MP and CP automatically, 117 T-PE/S-PE SHOULD has the knowledge that it is the PW transfer 118 signaling message. Furthermore, for MS-PW transfer T-PE/S-PE SHOULD 119 know the next hop, so, the PW path MUST be carried in the LDP Label 120 Mapping message. Since [SEG-PW] has defined PW switching point TLV 121 (S-PE TLV) and Sub-TLV to the switching points that the PW traverses, 122 so S-PE TLV and Sub-TLV can be used to carry the PW path. Therefore, 123 this section only defines a new LDP TLV - Transfer TLV - which can be 124 used to indicate a PW transfer signaling procedure. 126 2.1. PW Ownership Transfer TLV 128 The PW Ownership Transfer TLV (PW-OH TLV) is defined as following: 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 |0|0| PW Transfer (0x0xxxx) | Length | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 |POT| 136 +-+-+ 138 Figure 1: PW Ownership Transfer TLV 140 POT (2 bits): PW Ownership Transfer. This TLV is optional and 141 carried in Optional Parameters of LDP Label Mapping and Label 142 Withdraw message defined in [RFC5036]. 144 01 - PW ownership transfer from management plane to control plane 146 11 - PW ownership transfer from control plane to management plane 148 3. PW Transfer Procedure 150 3.1. PW Ownership Transfer from MP to CP 152 The MP to CP PW transfer procedure MUST create a LDP session along 153 the path of the PW to be transfer from MP to CP, associat the LDP 154 session to the existing FEC-Label mapping owned by the MP and at the 155 same time transfer PW ownership to the CP. 157 The operator instructs the source/destinational T-PE to transfer 158 control of the PW from the MP to the CP. For MS-PW operator MUST 159 also supply the exact path of the MS-PW and FEC-Label mapping 160 information. 162 The source/destinational T-PE MUST check that no corresponding LDP 163 state exists and that corresponding Data Plane state does exist. If 164 there is an error, this MUST be reported to the operator and further 165 protocol action MUST NOT be taken. 167 The source/destination T-PE completes the LDP initialization as the 168 procedure described in [RFC5036] and [RFC4447]. After the LDP 169 initialization, the source T-PE SHOULD sends a Label Mapping message 170 with PW Ownership Transfer TLV in Optional Parameters to it's LDP 171 peer the destination T-PE, and vis versa. When destination/source 172 T-PE receives this PW transfer Label Mapping message, it only creates 173 the LDP signaling state on the control plane, and any action for data 174 plane MUST not be triggered. 176 3.1.1. MS-PW specification 178 o The behaviour of T-PE 180 The source/destination T-PE of PW transfering from MP to CP, 181 SHOULD encond the PW path into S-PE TLV and Sub-TLV and set the Ho 182 of PW-OH TLV to 01, then encond these TLVs into Label Mapping 183 message. After source/destination T-PE completes the Label 184 Message enconding, it sends the message to the downstream node, 185 i.e. S-PE. 187 o The behaviour of S-PE 189 When S-PE receives the PW transfer Label Mapping message, it 190 SHOULD create the PW signaling state in the control plane, and get 191 the next hop from the S-PE TLV and Sub-TLV. After S-PE creates 192 the PW signaling state in the control plane, it sends the PW 193 transfer LDP Label Mapping message to the next hop. 195 3.1.2. Failure Handling 197 This section is to be studied in the next version. 199 3.2. PW Ownership Transfer from CP to MP 201 The CP to MP transfer procedure MUST delete the existing LDP session 202 information and MUST NOT affect the cross-connected resources, but 203 just move their ownership to the MP. That is, after PW ownership 204 transfer from CP to MP, the PW is no longer under control of LDP. 206 The source/destination T-PE node MUST send a Label Withdraw message 207 in the downstream direction with the Ho of PW-OH TLV set to 11 208 carried in Optional Parameters. No action is taken over the DP. For 209 MS-PW, S-PE must forward such message towards the source or 210 destination node for forward and reverse direction respectively. 211 Downstream nodes processing a Label Withdraw message MUST NOT remove 212 any associated data plane state. 214 3.2.1. Failure Handling 216 This section is to be studied in the next version. 218 4. Security Considerations 220 TBD. 222 5. IANA Considerations 224 TBD. 226 6. Acknowledgements 228 The RFC text was produced using Marshall Rose's xml2rfc tool. 230 7. References 232 7.1. Normative References 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, March 1997. 237 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 238 Edge (PWE3) Architecture", RFC 3985, March 2005. 240 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 241 Heron, "Pseudowire Setup and Maintenance Using the Label 242 Distribution Protocol (LDP)", RFC 4447, April 2006. 244 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 245 Specification", RFC 5036, October 2007. 247 [RFC5659] Bocci, M. and S. Bryant, "An Architecture for Multi- 248 Segment Pseudowire Emulation Edge-to-Edge", RFC 5659, 249 October 2009. 251 7.2. Informative References 253 [DYNAMIC-MS-PW] 254 Luca Martini, Matthew Bocci, and Florin Balus, "Dynamic 255 Placement of Multi Segment Pseudo Wires", 256 draft-ietf-pwe3-dynamic-ms-pw-10.txt Working in progress. 258 [MPLS-TP-CP] 259 Loa Andersson, Lou Berger, and Luyuan Fang, "MPLS-TP 260 Control Plane Framework", 261 draft-abfb-mpls-tp-control-plane-framework-01.txt Working 262 in progress. 264 [SEG-PW] Luca Martini and Chris Metz, "Segmented Pseudowire", 265 draft-ietf-pwe3-segmented-pw-13.txt Working in progress. 267 Authors' Addresses 269 Yuanlin Bao 270 ZTE Corporation 271 5F, R&D Building 3, ZTE Industrial Park, XiLi LiuXian Road 272 Nanshan District, Shenzhen 518055 273 P.R.China 275 Phone: +86 755 26773731 276 Email: bao.yuanlin@zte.com.cn 277 URI: http://www.zte.com.cn/ 279 Xihua Fu 280 ZTE Corporation 281 West District,ZTE Plaza,No.10,Tangyan South Road,Gaoxin District 282 Xi An 710065 283 P.R.China 285 Phone: +86 13798412242 286 Email: fu.xihua@zte.com.cn 287 URI: http://www.zte.com.cn/ 289 Fei Zhang 290 ZTE Corporation 291 NO.68, Zijinhua Road, Yuhuatai District 292 Nanjing 210000 293 P.R.China 295 Phone: +86 25 52877612 296 Email: zhang.fei3@zte.com.cn