idnits 2.17.1 draft-liu-pwe3-mpls-tp-p2mp-pw-protection-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 09, 2013) is 3971 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 187 == Missing Reference: 'MPLS-TP-22' is mentioned on line 251, but not defined == Unused Reference: 'RFC5654' is defined on line 236, but no explicit reference was found in the text == Unused Reference: 'RFC5921' is defined on line 239, but no explicit reference was found in the text == Unused Reference: 'RFC6478' is defined on line 241, but no explicit reference was found in the text == Unused Reference: 'RFC6718' is defined on line 244, but no explicit reference was found in the text == Unused Reference: 'RFC6870' is defined on line 246, but no explicit reference was found in the text -- Duplicate reference: RFC5654, mentioned in 'RFC5921', was also mentioned in 'RFC5654'. Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PWE3 Working Group G. Liu 3 Internet-Draft ZTE Corporation 4 Intended status: Informational June 09, 2013 5 Expires: December 11, 2013 7 p2mp pw protection for MPLS-TP network 8 draft-liu-pwe3-mpls-tp-p2mp-pw-protection-03 10 Abstract 12 The requirements of MPLS-TP in RFC 5654 include a requirement(R63) 13 that requires MPLS-TP MUST be possible to provide protection for 14 MPLS-TP data plane without any IP forwarding capability and control 15 plane.If applying 1:1 protection mechanism for the p2mp traffic in 16 rfc6718 , it must have a return path to coordinate switch state to 17 select the same path to receive and send traffic packet.For the above 18 problem,this document describes a kind of protection solution to 19 recovery and protect the p2mp traffic under the failure condition. 21 This document is a product of a joint Internet Task Force(IETF) / 22 International Telecommunications Union Telecommunications 23 Standardization Sector (ITU-T) effort to include an MPLS Transport 24 Profile within the IETF MPLS and PWE3 architectures to support the 25 capabilities and functionalities of a packet transport network as 26 defined by the ITU-T. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 11, 2013. 45 Copyright Notice 47 Copyright (c) 2013 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 Simplified BSD License. 60 This document may not be modified, and derivative works of it may not 61 be created, and it may not be published except as an Internet-Draft. 63 Table of Contents 65 1. Problem statement . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Conventions used in this document . . . . . . . . . . . . . . 3 67 3. Protection Mechanism . . . . . . . . . . . . . . . . . . . . 3 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 73 7.2. URL References . . . . . . . . . . . . . . . . . . . . . 6 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 76 1. Problem statement 78 According to MPLS-TP requirement(RFC 5654), It requires that MPLS-TP 79 data plane is independent of control plane and IP forwarding 80 capability. So it means that MPLS-TP data plane can still work 81 without control plane and any IP forwarding capability.It must be 82 essential for unidiretional path including p2p or p2mp path to set up 83 a return path between any two end nodes . So it costs more 84 configuration and maintenece . While this document provides a 85 protection mechanism for p2mp traffic without return path, IP 86 forwarding capability and control plane. 88 2. Conventions used in this document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC-2119. 94 OAM: Operation, Administration, Maintenance 96 LSP: Label Switched Path. 98 PW: Pseudowire 100 P2MP:Point to Multi-Point 102 P2P:Point to Point 104 PSC:Protection Switching Coordination 106 CE:Customer Equipment 108 LER:Label Edge Router 110 LSR:Label Switch Router 112 IP: Interenet Protocol 114 MPLS-TP:Multi-Protocol Label Switching Transport Profile 116 ME: Maintenance Entity 118 MEP:MEG End Point 120 CE: Customer Equipment 122 3. Protection Mechanism 124 This section will describe a protection mechanism for p2mp pw 125 path,which regards a leaf node as protector node of another leaf node 126 on the p2mp pw path.The two leaf nodes protect each other.in addtion, 127 In order to be easy to access to CE node, It should select LER as 128 backup node which will connect protector node and CE node. If the 129 backup node is still a leaf node of the p2mp pw path ,in a result, 130 the protector node and the backup node are the same node. in addtion, 131 A bidirectional p2p pw should be configurated between the protected 132 node and the backup node or the protector node , and between the 133 protector node and the backup node .Just as the following figure 1: 135 ___ ___ ___ 136 */LSR\ ********* /LER\########## /CE1\ 137 * \ A / \_1_/ # \___/ 138 __ * - - + # 139 /LER\* . _+_ # 140 /LER\# 141 \_O_/* . \_2_/# 142 * . + # 143 * ___ _+_ # ___ 144 * /LSR\ /LER\ # /CE2\ 145 * \ B / ********** \_3_/########### \___/ 146 - - 147 ***** working pw 148 +++++ protection pw 149 ##### access link 151 Figure 1: p2mp pw protection configuration topology figure 153 LER0 is root node of a p2mp pw, LER1 and LER3 are leaf nodes of the 154 p2mp pw. LER2 is a backup node for LER1 and LER3. When the 155 protected node LER1 or LER3 has a failure, its backup node LER2 will 156 replace of the protected node LER1 or LER3 to transmit the protected 157 p2mp traffic to CE1 or CE2. 159 If LER1 has a failure, LER2 MUST detect the failure by PW OAM. Then 160 LER2 will notify its protector node LER3 of the failure by pw status 161 message[1]. When LER3 receives the failure status message, it will 162 begin to duplicate the p2mp traffic to send to LER2 by pre-configured 163 p2p protection pw. Then LER2 sends the p2mp traffic to CE1 by its 164 access link(LER2-CE1) ,Just as the following figure 2. 166 ___ _X_ ___ 167 */LSR\ ********* /LER\########## /CE1\ 168 * \ A / \_1_/ # \___/ 169 __ * - - + # 170 /LER\* . _+_ # 171 /LER\# 172 \_O_/* . \_2_/# 173 * . + # 174 * ___ _+_ # ___ 175 * /LSR\ /LER\ # /CE2\ 176 * \ B / ********** \_3_/########### \___/ 177 - - 178 ***** working pw 179 +++++ protection pw 180 ##### access link 181 X failure 183 Figure 2: node failure 185 When a leaf node detects a failure on its working pw , it will notify 186 the failure of its backup node or protector node by pw status 187 message[1]. So its backup node or protector node will transmit the 188 protected p2mp traffic to the protected node.Just as the following 189 figure 3. 191 ___ ___ ___ 192 */LSR\ *****X**** /LER\######### /CE1\ 193 * \ A / \_1_/ # \___/ 194 __ * - - + # 195 /LER\* . _+_ # 196 /LER\# 197 \_O_/* . \_2_/# 198 * . + # 199 * ___ _+_ # ___ 200 * /LSR\ /LER\ # /CE2\ 201 * \ B / ********** \_3_/########### \___/ 202 - - 203 ***** working pw 204 +++++ protection pw 205 ##### access link 206 X failure 208 Figure 3: working pw failure 210 When a failure happens on the branch working pw path(LER0-LSRA-LER1), 211 the protected node LER1 will detect the failure and inform the 212 failure of its backup node LER2 and protector node LER3. Then LER2 213 and LER3 receive the failure message from LER1 ,LER3 will duplicate 214 the protected p2mp traffic to send to the backup node LER2 firstly by 215 its protection pw between LER2 and LER3. Then LER2 sends the traffic 216 to the protected node LER1 by the protection pw between LER1 and 217 LER2. At last CE1 will receive the traffic by its access 218 link(LER1-CE1) 220 4. Security Considerations 222 TBD 224 5. IANA Considerations 226 TBD. 228 6. Acknowledgments 230 TBD . 232 7. References 234 7.1. Normative References 236 [RFC5654] IETF, "IETF RFC5654(MPLS-TP requirement) ", September 237 2009. 239 [RFC5921] IETF, "IETF RFC5654(MPLS-TP framework) ", July 2010. 241 [RFC6478] IETF, "IETF RFC6478(Pseudowire Status for Static 242 Pseudowires) ", May 2012. 244 [RFC6718] IETF, "IETF RFC6718(Pseudowire Redundancy) ", August 2012. 246 [RFC6870] IETF, "IETF RFC6870(Pseudowire Preferential Forwarding 247 Status Bit) ", February 2013. 249 7.2. URL References 251 [MPLS-TP-22] 252 IETF - ITU-T Joint Working Team, 2008, 253 . 255 Author's Address 256 Guoman Liu 257 ZTE Corporation 258 No.50, Ruanjian Road, Yuhuatai District 259 Nanjing 210012 260 P.R.China 262 Phone: +86 025 88014227 263 Email: liu.guoman@zte.com.cn