--- 1/draft-ietf-mpls-tp-csf-00.txt 2011-03-14 16:14:19.000000000 +0100 +++ 2/draft-ietf-mpls-tp-csf-01.txt 2011-03-14 16:14:19.000000000 +0100 @@ -1,23 +1,23 @@ Network Working Group J.He Internet Draft Huawei Technologies Intended status: Standard Track H.Li China Mobile E. Bellagamba Ericsson -Expires: August 2011 February 10, 2011 +Expires: September 2011 March 14, 2011 Indication of Client Failure in MPLS-TP - draft-ietf-mpls-tp-csf-00.txt + draft-ietf-mpls-tp-csf-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. @@ -25,94 +25,94 @@ 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html - This Internet-Draft will expire on August 10, 2011. + This Internet-Draft will expire on September 14, 2011. Copyright Notice Copyright (c) 2011 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes a Multi-Protocol Label Switching Transport Profile (MPLS-TP) Operations, Administration and Maintenance (OAM) - tool to propagate a client failure indication across an MPLS-TP - network in case the propagation of failure status in the client layer - is not supported as required in [RFC5860]. + protocol to propagate a client failure indication across an MPLS-TP + network in the case that propagation of failure status in the client + layer is not supported as required in [RFC5860]. Table of Contents - 1. Introduction................................................. 2 + 1. Introduction ................................................ 2 2. Conventions used in this document............................ 3 - 2.1. Terminology............................................. 3 - 3. Mechanisms of CSF............................................ 4 - 3.1. General................................................. 4 + 2.1. Terminology ............................................ 3 + 3. Mechanisms of CSF ........................................... 4 + 3.1. General ................................................ 4 3.2. Transmission of CSF..................................... 5 3.3. Reception of CSF........................................ 6 3.4. Configuration of CSF.................................... 6 - 4. Frame format of CSF.......................................... 6 - 5. Consequent actions........................................... 8 - 6. Security Considerations...................................... 8 - 7. IANA Considerations.......................................... 8 - 8. Acknowledgments.............................................. 8 - 9. References................................................... 8 - 9.1. Normative References.................................... 8 - 9.2. Informative References.................................. 9 - 10. Authors' Addresses ......................................... 9 + 4. Frame format of CSF ......................................... 7 + 5. Consequent actions .......................................... 8 + 6. Security Considerations...................................... 9 + 7. IANA Considerations ......................................... 9 + 8. Acknowledgments ............................................. 9 + 9. References .................................................. 9 + 9.1. Normative References.................................... 9 + 9.2. Informative References................................. 10 + 10. Authors' Addresses ........................................ 10 1. Introduction - In transport network OAM functionalities are important and - fundamental to ease operational complexity, enhance network - availability and meet service performance objectives by efficient and - automatic detection, handling, diagnosis and appropriate reporting of - defects and performance monitoring. + In transport networks, OAM functions are important and fundamental to + ease operational complexity, enhance network availability and meet + service performance objectives. This is achieved through automatic + detection, handling, diagnosis, appropriate reporting of defects and + performance monitoring. As defined in [RFC 5860] MPLS-TP OAM MUST provide a function to enable the propagation, from edge to edge of an MPLS-TP network, of information pertaining to a client (i.e., external to the MPLS-TP network) defect or fault condition detected at an End Point of a PW or LSP, if the client layer OAM functionality does not provide an alarm notification/propagation functionality (e.g. not needed in the original application of the client signal, or the signal was originally at the bottom of the layer stack and it was not expected to be transported over a server layer), while such an indication is needed by the downstream. - This document defines such a MPLS-TP OAM tool as Client Signal Fail - indication (CSF) to propagate client failures and their clearance - across a MPLS-TP domain. + This document defines a Client Signal Fail (CSF) indication protocol + in order to propagate client failures and their clearance across a + MPLS-TP domain. According to [RFC 5921], MPLS-TP supports two native service adaptation mechanisms via: - 1) a PW, to emulate certain services, for example, Ethernet, Frame - Relay, or PPP / High-Level Data Link Control (HDLC). + 1) a Pseudowire, to emulate certain services, for example, Ethernet, + Frame Relay, or PPP / High-Level Data Link Control (HDLC). 2) an LSP, to provide adaptation for any native service traffic type supported by [RFC3031] and [RFC3032]. Examples of such traffic - types include IP packets and MPLS-labeled packets (PW over LSP, or - IP over LSP). + types include IP packets and MPLS-labeled packets (i.e.: PW over + LSP, or IP over LSP). As to the first adaptation mechanism via a PW, the mechanism of CSF function to support propagation of client failure indication follows [static-pw-status]. The PW status relevant to CSF function is AC fault as defined in [RFC 4447] and [RFC 4446]. As to the second adaptation mechanism via LSP, the mechanism is detailed in this draft and is used in case the client of MPLS-TP can not provide itself with such failure notification/propagation. @@ -142,30 +142,33 @@ LSR: Label Switching Router MEP: Maintenance Entity Group End Point MIP: Maintenance Entity Group Intermediate Point OAM: Operations, Administration, and Maintenance MPLS-TP: MPLS Transport Profile + PW: Pseudowire + RDI: Remote Defect Indication 3. Mechanisms of CSF 3.1. General - Client Signal Fail indication (CSF) provides a function to enable a + Client Signal Fail(CSF) indication provides a function to enable a MEP to propagate a client failure indication to its peer MEP across a MPLS-TP network in case the client service itself does not support - propagation of its failure status. + propagation of its failure status. A MIP is not intended to generate + or process CSF information. Packets with CSF information can be issued by a MEP, upon receiving failure information from its client service. Detection rules for client failure events are client-specific and are therefore outside the scope of this document. +---+ +---+ +---+ +---+ | | | |-->CSF | | | | | A |--X--| B |-----------------| C |------| D | +---+ +---+ +---+ +---+ @@ -196,55 +199,68 @@ PDU format) to Node C to help expedite clearance of native client failure conditions. Accordingly, Node C will clear client failure condition when a valid client data frame is received and no CSF is received (implicit failure clearance mechanism) or upon receiving explicit failure clearance indication. 3.2. Transmission of CSF - Upon learning signal failure condition of its client-layer the MEP - can immediately start transmitting periodic packets with CSF - information. A MEP continues to transmit periodic packets with CSF - information until the client-layer signal failure condition is - cleared. + When CSF function is enabled, upon learning signal failure condition + of its client-layer, the MEP can immediately start transmitting + periodic packets with CSF information to its peer MEP. A MEP + continues to transmit periodic packets with CSF information until the + client-layer signal failure condition is cleared. The clearance of CSF condition can be communicated to the peer MEP via: - - Stopping transmission of CSF signal but forwarding client data - frames, or - - Forwarding CSF PDU with clearance indication. + - Stopping of the transmission of CSF signal but forwarding client + data frames, or + - Forwarding CSF PDUs with a clearance indication. Transmission of packets with CSF information can be enabled or - disabled on a MEP. + disabled on a MEP (e.g. through management plane). Detection and clearance rules for CSF events are client and application specific and outside the scope of this draft. - The period of CSF generation is client and application specific and - outside the scope of this draft. + The period of CSF transmission is client and application specific. + Examples are as follows: + + - 3.33ms: for protection switching application. + - 1s: for fault management application. + + However, the value 0 is invalid. 3.3. Reception of CSF Upon receiving a packet with CSF information a MEP either declares or clears a client-layer signal fail condition according to the received CSF information and propagates this as a signal fail indication to its client-layer. + CSF condition is cleared when the receiving MEP + + - does not receive CSF signal within an interval of N times the CSF + transmission period (Suggested value of N is 3.5), or + - receives a valid client data frame, or + - receives CSF PDU with CSF-Clear information + 3.4. Configuration of CSF Specific configuration information required by a MEP to support CSF transmission is the following: - CSF transmission period - this is application dependent. + CSF transmission period - this is application dependent. Examples are + 3.3 ms and 1s. PHB - identifies the per-hop behavior of packet with CSF information. A MIP is transparent to packets with CSF information and therefore does not require any information to support CSF functionality. 4. Frame format of CSF Figure 2 depicts the frame format of CSF. CSF PDUs are encapsulated using the ACH, according to [RFC 5586]. GAL is used as an alert based @@ -282,20 +298,22 @@ - CSF Reserved 1 (Bits 40 to 47): This field MUST be set to zero on transmission and ignored on receipt; - CSF Reserved 2 (Bits 56 to 63): This field MUST be set to zero on transmission and ignored on receipt; - Total TLV Length: Total of all included TLVs. No TLVs are defined currently. The value is 0. + - TLVs: No TLVs are defined currently. + 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | Res | Type | Period | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 Format of Flags in CSF PDU Figure 3 depicts the format of Flags in CSF PDU. - Flag Reserved (Bits 48 to 49): Set to 0; @@ -330,28 +348,34 @@ network or another port to continue communication. 6. Security Considerations Malicious insertion of spurious CSF signals (e.g. DoS) is not quite likely in a transport network since transport networks are usually self-managed by operators and providers. 7. IANA Considerations - This document requests that IANA allocates a new Associated Channel - Type for CSF function to be used in MPLS-TP OAM. + MPLS-TP CSF function requires a new Associated Channel Type to be + assigned by IANA from the Pseudowire Associated Channel Types + Registry. + + Registry: + Value Description + ----- ----------------------- + 0xXX MPLS-TP Client Signal Fail indication (CSF) 8. Acknowledgments The authors would like to thank Haiyan Zhang, Adrian Farrel, Loa - Andersson, Matthew Bocci and Andy Malis for their guidance to this - work. + Andersson, Matthew Bocci, Andy Malis and Thomas D. Nadeau for their + guidance and input to this work. 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. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. @@ -379,33 +403,33 @@ September 2009 [RFC 5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for OAM in MPLS Transport Networks", RFC5860, May 2010 [RFC 5921] Bocci, M., Bryant, S., and D. Frost, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010 [static-pw-status] Martini, L., Swallow, G., Heron, G., and M. Bocci, "Pseudowire Status for Static Pseudowires", draft-ietf- - pwe3-static-pw-status-01 (work in progress), October 2010 + pwe3-static-pw-status-02 (work in progress), March 2011 9.2. Informative References [MPLS-TP OAM Frmk] Busi,I., and D. Allan, "MPLS-TP OAM Framework and - Overview", draft-ietf-mpls-tp-oam-framework-09(work in - progress), October 2010 + Overview", draft-ietf-mpls-tp-oam-framework-11(work in + progress), February 2011 [Rosetta stone] Van Helvoort, H., Andersson, L., Sprecher, N., "A Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU- T's Transport Network Recommendations", draft-ietf-mpls-tp- - rosetta-stone-02 (work in progress), May 2010 + rosetta-stone-03 (work in progress), November 2010 10. Authors' Addresses Jia He Huawei Technologies Co., Ltd. Email: hejia@huawei.com Han Li China Mobile Communications Corporation