idnits 2.17.1 draft-ietf-mpls-tp-csf-02.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 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) No issues found here. 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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC5860]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 160 has weird spacing: '...ication provi...' -- The document date (September 13, 2011) is 4607 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC5860' is mentioned on line 54, but not defined == Missing Reference: 'RFC 4447' is mentioned on line 113, but not defined ** Obsolete undefined reference: RFC 4447 (Obsoleted by RFC 8077) == Missing Reference: 'RFC 4446' is mentioned on line 113, but not defined == Missing Reference: 'RFC 2119' is mentioned on line 124, but not defined == Missing Reference: 'RFC 5586' is mentioned on line 292, but not defined == Unused Reference: 'RFC2119' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'RFC4446' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'RFC4447' is defined on line 390, but no explicit reference was found in the text == Unused Reference: 'RFC5586' is defined on line 394, but no explicit reference was found in the text == Unused Reference: 'RFC 5654' is defined on line 401, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) ** Downref: Normative reference to an Informational RFC: RFC 5921 Summary: 5 errors (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J.He 2 Internet Draft Huawei Technologies 3 Intended status: Standard Track 4 H.Li 5 China Mobile 7 E. Bellagamba 8 Ericsson 10 Expires: March 2012 September 13, 2011 12 Indication of Client Failure in MPLS-TP 13 draft-ietf-mpls-tp-csf-02.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on March 13, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 This document describes a Multi-Protocol Label Switching Transport 51 Profile (MPLS-TP) Operations, Administration and Maintenance (OAM) 52 protocol to propagate a client failure indication across an MPLS-TP 53 network in the case that propagation of failure status in the client 54 layer is not supported as required in [RFC5860]. 56 Table of Contents 58 1. Introduction ................................................ 2 59 2. Conventions used in this document............................ 3 60 2.1. Terminology ............................................ 3 61 3. Mechanisms of CSF ........................................... 4 62 3.1. General ................................................ 4 63 3.2. Transmission of CSF..................................... 5 64 3.3. Reception of CSF........................................ 6 65 3.4. Configuration of CSF.................................... 6 66 4. Frame format of CSF ......................................... 7 67 5. Consequent actions .......................................... 8 68 6. Security Considerations...................................... 9 69 7. IANA Considerations ......................................... 9 70 8. Acknowledgments ............................................. 9 71 9. References .................................................. 9 72 9.1. Normative References.................................... 9 73 9.2. Informative References................................. 10 74 10. Authors' Addresses ........................................ 10 76 1. Introduction 78 In transport networks, OAM functions are important and fundamental to 79 ease operational complexity, enhance network availability and meet 80 service performance objectives. This is achieved through automatic 81 detection, handling, diagnosis, appropriate reporting of defects and 82 performance monitoring. 84 As defined in [RFC 5860] MPLS-TP OAM MUST provide a function to 85 enable the propagation, from edge to edge of an MPLS-TP network, of 86 information pertaining to a client (i.e., external to the MPLS-TP 87 network) defect or fault condition detected at an End Point of a PW 88 or LSP, if the client layer OAM functionality does not provide an 89 alarm notification/propagation functionality (e.g. not needed in the 90 original application of the client signal, or the signal was 91 originally at the bottom of the layer stack and it was not expected 92 to be transported over a server layer), while such an indication is 93 needed by the downstream. 95 This document defines a Client Signal Fail (CSF) indication protocol 96 in order to propagate client failures and their clearance across a 97 MPLS-TP domain. 99 According to [RFC 5921], MPLS-TP supports two native service 100 adaptation mechanisms via: 102 1) a Pseudowire, to emulate certain services, for example, Ethernet, 103 Frame Relay, or PPP / High-Level Data Link Control (HDLC). 105 2) an LSP, to provide adaptation for any native service traffic type 106 supported by [RFC3031] and [RFC3032]. Examples of such traffic 107 types include IP packets and MPLS-labeled packets (i.e.: PW over 108 LSP, or IP over LSP). 110 As to the first adaptation mechanism via a PW, the mechanism of CSF 111 function to support propagation of client failure indication follows 112 [static-pw-status]. The PW status relevant to CSF function is AC 113 fault as defined in [RFC 4447] and [RFC 4446]. 115 As to the second adaptation mechanism via LSP, the mechanism is 116 detailed in this draft and is used in case the client of MPLS-TP can 117 not provide itself with such failure notification/propagation. 119 2. Conventions used in this document 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC 2119]. 125 2.1. Terminology 127 The reader is assumed to be familiar with the terminology in MPLS-TP. 128 The relationship between ITU-T and IETF terminologies on MPLS-TP can 129 be found in [Rosetta stone]. 131 ACH: Associated Channel Header 133 AIS: Alarm Indication Signal 135 CSF: Client Signal Fail indication 136 FDI: Forward Defect Indication 138 G-ACh: Generic Associated Channel 140 GAL: G-ACh Label 142 LSR: Label Switching Router 144 MEP: Maintenance Entity Group End Point 146 MIP: Maintenance Entity Group Intermediate Point 148 OAM: Operations, Administration, and Maintenance 150 MPLS-TP: MPLS Transport Profile 152 PW: Pseudowire 154 RDI: Remote Defect Indication 156 3. Mechanisms of CSF 158 3.1. General 160 Client Signal Fail(CSF) indication provides a function to enable a 161 MEP to propagate a client failure indication to its peer MEP across a 162 MPLS-TP network in case the client service itself does not support 163 propagation of its failure status. A MIP is not intended to generate 164 or process CSF information. 166 Packets with CSF information can be issued by a MEP, upon receiving 167 failure information from its client service. Detection rules for 168 client failure events are client-specific and are therefore outside 169 the scope of this document. 171 +---+ +---+ +---+ +---+ 172 | | | |-->CSF | | | | 173 | A |--X--| B |-----------------| C |------| D | 174 +---+ +---+ +---+ +---+ 175 |<--MPLS-TP domain-->| 177 Figure 1 Use case of CSF 179 Figure 1 depicts a typical connection scenario between two client 180 network elements (Node A and Node D) interconnected through MPLS-TP 181 transport network. Client Node A connects to MPLS-TP Node B and 182 Client Node D connects to MPLS-TP Node C. Node B and C support MPLS- 183 TP MEP function. 185 If a failure is detected between Node A and Node B and is taken as a 186 native client failure condition, the MEP function in Node B will 187 initiate CSF signal and it will be sent to Node C through MPLS-TP 188 network. CSF signal will be extracted at Node C as an indication of 189 client signal failure. Further, this may be mapped back into native 190 client failure indication and regenerated towards client Node D. 192 Node B learns the failure between A and B either by direct detection 193 of signal fail (e.g. loss of signal) or by some fault indications 194 between A and B (e.g. RDI, AIS/FDI). 196 If the connection between Node A and B recovers, Node B may stop 197 sending CSF signals to Node C (implicit failure clearance mechanism) 198 or explicitly send failure clearance indication (e.g. by flags in CSF 199 PDU format) to Node C to help expedite clearance of native client 200 failure conditions. 202 Accordingly, Node C will clear client failure condition when a valid 203 client data frame is received and no CSF is received (implicit 204 failure clearance mechanism) or upon receiving explicit failure 205 clearance indication. 207 3.2. Transmission of CSF 209 When CSF function is enabled, upon learning signal failure condition 210 of its client-layer, the MEP can immediately start transmitting 211 periodic packets with CSF information to its peer MEP. A MEP 212 continues to transmit periodic packets with CSF information until the 213 client-layer signal failure condition is cleared. 215 The clearance of CSF condition can be communicated to the peer MEP 216 via: 218 - Stopping of the transmission of CSF signal but forwarding client 219 data frames, or 220 - Forwarding CSF PDUs with a clearance indication. 222 Transmission of packets with CSF information can be enabled or 223 disabled on a MEP (e.g. through management plane). 225 Detection and clearance rules for CSF events are client and 226 application specific and outside the scope of this draft. 228 The period of CSF transmission is client and application specific. 229 Examples are as follows: 231 - 3.33ms: for protection switching application. 232 - 1s: for fault management application. 234 However, the value 0 is invalid. 236 3.3. Reception of CSF 238 Upon receiving a packet with CSF information a MEP either declares or 239 clears a client-layer signal fail condition according to the received 240 CSF information and propagates this as a signal fail indication to 241 its client-layer. 243 CSF condition is cleared when the receiving MEP 245 - does not receive CSF signal within an interval of N times the CSF 246 transmission period (Suggested value of N is 3.5), or 247 - receives a valid client data frame, or 248 - receives CSF PDU with CSF-Clear information 250 3.4. Configuration of CSF 252 Specific configuration information required by a MEP to support CSF 253 transmission is the following: 255 CSF transmission period - this is application dependent. Examples are 256 3.3 ms and 1s. 258 PHB - identifies the per-hop behavior of packet with CSF information. 260 A MIP is transparent to packets with CSF information and therefore 261 does not require any information to support CSF functionality. 263 4. Frame format of CSF 265 Figure 2 depicts the frame format of CSF. CSF PDUs are encapsulated 266 using the ACH, according to [RFC 5586]. GAL is used as an alert based 267 exception mechanism to differentiate CSF packets (with ACH as G-ACh 268 packets) from user-plane packets as defined in [RFC 5586]. 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| MPLS-TP CSF(0xXX) | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Version | Reserved 1 | Flags | Reserved 2 | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Total TLV Len | ~ 278 +-+-+-+-+-+-+-+-+ TLVs ~ 279 ~ | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Figure 2 Frame format of CSF 284 The first four bytes represent the Generic ACH ([RFC 5586]): 286 - first nibble: set to 0001b to indicate a control channel 287 associated with a PW, a LSP or a Section; 289 - ACH Version(bits 4 to 7): set to 0, as specified in [RFC 5586] 291 - ACH Reserved (bits 8 to 15): set to 0 and ignored on reception, 292 as specified in [RFC 5586]; 294 - ACH Channel Type (Bits 16 to 31): value 0xXX identifies the 295 payload as CSF PDU. To be assigned by IANA. 297 - CSF Version (Bits 32 to 39): Set to 0; 299 - CSF Reserved 1 (Bits 40 to 47): This field MUST be set to zero 300 on transmission and ignored on receipt; 302 - CSF Reserved 2 (Bits 56 to 63): This field MUST be set to zero 303 on transmission and ignored on receipt; 305 - Total TLV Length: Total of all included TLVs. No TLVs are 306 defined currently. The value is 0. 308 - TLVs: No TLVs are defined currently. 310 0 1 2 3 4 5 6 7 311 +---+---+---+---+---+---+---+---+ 312 | Res | Type | Period | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Figure 3 Format of Flags in CSF PDU 317 Figure 3 depicts the format of Flags in CSF PDU. 319 - Flag Reserved (Bits 48 to 49): Set to 0; 321 - Type (Bits 50 to 52): Set to the following values to indicate 322 CSF types 324 Value Type 326 111 Client Signal Fail - Loss of Signal (CSF-LOS) 328 001 Client Signal Fail - Forward Defect Indication (CSF-FDI) 330 010 Client Signal Fail - Reverse Defect Indication (CSF-RDI) 332 000 Clearance of Client Signal Fail - (CSF-Clear) 334 - Period (Bits 53 to 55): CSF transmission period and can be 335 configured. 337 5. Consequent actions 339 The primary intention of CSF is to transport a client signal fail 340 condition at the input of the MPLS-TP network to the output port of 341 the MPLS-TP network for clients that do not have alarm 342 notification/propagation mechanism defined. 344 Further, CSF allows creating a condition at the output port of the 345 MPLS-TP network such that the customer input port is able to detect 346 and alarm that there is no data arriving i.e. the connection is 347 interrupted. In this case, customers may choose another transport 348 network or another port to continue communication. 350 6. Security Considerations 352 Malicious insertion of spurious CSF signals (e.g. DoS) is not quite 353 likely in a transport network since transport networks are usually 354 self-managed by operators and providers. 356 7. IANA Considerations 358 MPLS-TP CSF function requires a new Associated Channel Type to be 359 assigned by IANA from the Pseudowire Associated Channel Types 360 Registry. 362 Registry: 363 Value Description 364 ----- ----------------------- 365 0xXX MPLS-TP Client Signal Fail indication (CSF) 367 8. Acknowledgments 369 The authors would like to thank Haiyan Zhang, Adrian Farrel, Loa 370 Andersson, Matthew Bocci, Andy Malis and Thomas D. Nadeau for their 371 guidance and input to this work. 373 9. References 375 9.1. Normative References 377 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 378 Requirement Levels", BCP 14, RFC 2119, March 1997. 380 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 381 Label Switching Architecture", RFC 3031, January 2001. 383 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, 384 D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 385 3032, January 2001. 387 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 388 Emulation (PWE3)", RFC4446, April 2006 390 [RFC4447] Martini, L., et al., "Pseudowire Setup and Maintenance 391 Using the Label Distribution Protocol (LDP)", RFC4447, 392 April 2006. 394 [RFC5586] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., and R. 395 Aggarwal, "MPLS Generic Associated Channel", RFC5586, June 396 2009 398 [ITU-T Recommendation G.7041] "Generic framing procedure (GFP)", ITU- 399 T G.7041, October 2008 401 [RFC 5654] Niven-Jenkins, B., Brungard, D., and M. Betts, 402 "Requirements of an MPLS Transport Profile", RFC 5654, 403 September 2009 405 [RFC 5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 406 OAM in MPLS Transport Networks", RFC5860, May 2010 408 [RFC 5921] Bocci, M., Bryant, S., and D. Frost, "A Framework for MPLS 409 in Transport Networks", RFC 5921, July 2010 411 [static-pw-status] Martini, L., Swallow, G., Heron, G., and M. Bocci, 412 "Pseudowire Status for Static Pseudowires", draft-ietf- 413 pwe3-static-pw-status-06 (work in progress), July 2011 415 9.2. Informative References 417 [MPLS-TP OAM Frmk] Busi,I., and D. Allan, "MPLS-TP OAM Framework and 418 Overview", draft-ietf-mpls-tp-oam-framework-11(work in 419 progress), February 2011 421 [Rosetta stone] Van Helvoort, H., Andersson, L., Sprecher, N., "A 422 Thesaurus for the Terminology used in Multiprotocol Label 423 Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU- 424 T's Transport Network Recommendations", draft-ietf-mpls-tp- 425 rosetta-stone-04 (work in progress), June 2011 427 10. Authors' Addresses 429 Jia He 430 Huawei Technologies Co., Ltd. 432 Email: hejia@huawei.com 433 Han Li 434 China Mobile Communications Corporation 436 Email: lihan@chinamobile.com 438 Elisa Bellagamba 439 Ericsson 441 Email: elisa.bellagamba@ericsson.com 443 Intellectual Property 445 The IETF Trust takes no position regarding the validity or scope of 446 any Intellectual Property Rights or other rights that might be 447 claimed to pertain to the implementation or use of the technology 448 described in any IETF Document or the extent to which any license 449 under such rights might or might not be available; nor does it 450 represent that it has made any independent effort to identify any 451 such rights. 453 Copies of Intellectual Property disclosures made to the IETF 454 Secretariat and any assurances of licenses to be made available, or 455 the result of an attempt made to obtain a general license or 456 permission for the use of such proprietary rights by implementers or 457 users of this specification can be obtained from the IETF on-line IPR 458 repository at http://www.ietf.org/ipr 460 The IETF invites any interested party to bring to its attention any 461 copyrights, patents or patent applications, or other proprietary 462 rights that may cover technology that may be required to implement 463 any standard or specification contained in an IETF Document. Please 464 address the information to the IETF at ietf-ipr@ietf.org. 466 The definitive version of an IETF Document is that published by, or 467 under the auspices of, the IETF. Versions of IETF Documents that are 468 published by third parties, including those that are translated into 469 other languages, should not be considered to be definitive versions 470 of IETF Documents. The definitive version of these Legal Provisions 471 is that published by, or under the auspices of, the IETF. Versions of 472 these Legal Provisions that are published by third parties, including 473 those that are translated into other languages, should not be 474 considered to be definitive versions of these Legal Provisions. 476 For the avoidance of doubt, each Contributor to the IETF Standards 477 Process licenses each Contribution that he or she makes as part of 478 the IETF Standards Process to the IETF Trust pursuant to the 479 provisions of RFC 5378. No language to the contrary, or terms, 480 conditions or rights that differ from or are inconsistent with the 481 rights and licenses granted under RFC 5378, shall have any effect and 482 shall be null and void, whether published or posted by such 483 Contributor, or included with or in such Contribution. 485 Disclaimer of Validity 487 All IETF Documents and the information contained therein are provided 488 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 489 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 490 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 491 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 492 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 493 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 494 FOR A PARTICULAR PURPOSE. 496 Copyright Notice 498 Copyright (c) 2010 IETF Trust and the persons identified as the 499 document authors. All rights reserved. 501 This document is subject to BCP 78 and the IETF Trust's Legal 502 Provisions Relating to IETF Documents 503 (http://trustee.ietf.org/license-info) in effect on the date of 504 publication of this document. Please review these documents 505 carefully, as they describe your rights and restrictions with respect 506 to this document. Code Components extracted from this document must 507 include Simplified BSD License text as described in Section 4.e of 508 the Trust Legal Provisions and are provided without warranty as 509 described in the Simplified BSD License.