MPLS Working Group A. Fulignoli Internet Draft Ericsson Intended status: Standard Track Y.Weingarten N.Sprecher Nokia Siemens Networks Expires: January 2010 July 9, 2009 MPLS-TP OAM Alarm Suppression Tools draft-fulignoli-mpls-tp-ais-lock-tool-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. Internet-Drafts are draft documents valid for a maximum of six months 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 Copyright Statement Copyright (c) 2009 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. Fulignoli and al. Expires January 9, 2010 [Page 1] Internet-Draft MPLS-TP Alarm Suppression July 2009 Abstract The aim of this draft is to define an MPLS-TP OAM mechanism to meet the requirements for Alarm Suppression functionality as required in [3]. One packet format with two different function codes is here defined in order to distinguish among packets with Alarm Indication information and packets with Lock Indication Information. Table of Contents 1. Introduction...................................................2 1.1. Terminology...............................................3 2. Alarm Indication Signal function (AIS).........................3 3. Lock Reporting.................................................4 4. Defect conditions..............................................4 5. Fault Location TLV.............................................5 6. AIS and LCK Packet.............................................6 7. Security Considerations........................................8 8. IANA Considerations............................................8 9. Acknowledgments................................................8 10. References....................................................9 10.1. Normative References.....................................9 10.2. Informative References...................................9 1. Introduction The aim of this draft is to define an MPLS-TP OAM mechanism to meet the requirements for Alarm Suppression functionality as required in [3]. One packet format, with two different function codes, is here defined in order to distinguish among packets with Alarm Indication information and packets with Lock Reporting information. Packets with Alarm Indication (AIS) information enable a server (sub-)layer MEP to notify a failure condition to its client (sub-)layer MEPs, while packets with Lock Reporting (LCK) information notify an administrative traffic locking condition. Fulignoli and al. Expires January 9, 2010 [Page 2] Internet-Draft MPLS-TP Alarm Suppression July 2009 1.1. Terminology AIS Alarm Indication Signal LME LSP Maintenance Entity LTCME LSP Tandem Connection Maintenance Entity ME Maintenance Entity MEP Maintenance End Point MIP Maintenance Intermediate Point PME PW Maintenance Entity PTCME PW Tandem Connection Maintenance Entity SME Section Maintenance Entity TLV Type Length Value Conventions used in this document 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 RFC-2119 [1]. 2. Alarm Indication Signal function (AIS) A MEP, upon detecting a signal fail condition, can transmit AIS packets in a direction opposite to its peer MEP to notify the fault condition to its client (syb-)layer MEPs. The periodicity of AIS packet transmission is fixed to 1 second. The first AIS packet must always be transmitted immediately following the detection of the signal fail condition. Upon receiving a packet with AIS information, a MEP detects an AIS defect condition and suppresses loss of continuity alarms associated with its peer MEP. Fulignoli and al. Expires January 9, 2010 [Page 3] Internet-Draft MPLS-TP Alarm Suppression July 2009 AIS defect contributes to the signal fail condition of the receiving MEPs that may result, in turn, in the transmission of AIS packets to its own MPLS-TP client MEPs or it needs to be mapped into an equivalent AIS signal for whatever client layer is then being carried, for example into ETH AIS frames in case of Ethernet client MEPs . 3. Lock Reporting A MEP, when administratively locked, transmits LCK packets in the direction opposite to its peer MEP to notify the administrative locking condition to its client (sub-)layer MEP. The periodicity of LCK packets transmission is fixed to one second. The first LCK packet must always be transmitted immediately following the administrative /diagnostic action. [Editor's note - Requirements and procedure for Lock Reporting are still under discussion in draft-ietf-mpls-tp-oam-requirement and draft-ietf-mpls-tp-oam-framework. This section will be aligned according to the final decision Upon receiving a packet with LCK information, a MEP detects a LCK defect condition and suppresses loss of continuity alarms associated with its peer MEP. A MEP that detects a LCK defect can transmit LCK packet to its MPLS-TP client MEPs or map it into an equivalent LCK signal for whatever client layer is then being carried, for example into ETH LCK frames in case of Ethernet client MEPs. 4. Defect conditions Defect triggered at the MPLS-TP layer by the AIS and LCK tools are reported in the following table. Fulignoli and al. Expires January 9, 2010 [Page 4] Internet-Draft MPLS-TP Alarm Suppression July 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Defect | Raising Condition | Clearing Condition | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dAIS | Rx AIS Packet |#AIS ==0 (K* AIS_Period) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dLCK | Rx LCK Packet |#LCK ==0 (K*LCK_Period) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Table 1: Table of Raising Clearing Defect Conditions In Table 1, K is protocol constant to be defined; the AISPeriod and LCKPeriond are both fixed to 1 second. 5. Fault Location TLV One or more Fault Location TLV MAY be included, under operator configuration, in the AIS or LCK packet; the DEFAULT mode is not to include it. When a MEP receives an AIS/LCK with the Fault Location TLV and it is configured to (re)generate the AIS/LCK packet to its client MEPs (in the forward direction) the following cases can occur: 1. The MEP is configured to(re)generate AIS/LCK messages with no Fault Location TLV 2. The MEP is configured to(re)generate AIS/LCK messages with the Fault TLV carrying its own identifier; this can occur when the server and client MEs are under different administrative domains such that the client ME needs to know that the failure is located within that specific server ME (i.e. it is not under its responsibility to recover the failure) but not exactly where, within the server ME, the failure is located 3. The MEP is configured to(re)generates AIS/LCK messages with the Fault Location TLV copied from the received AIS/LCK message; this is useful when both the server and client MEs are under the same administrative domain so the administrator can quickly identify where is the failure to fix The mechanism is applicable to TCM as well as to different hierarchical (sub-)layer. This section will be completed in the next version of the draft. Fulignoli and al. Expires January 9, 2010 [Page 5] Internet-Draft MPLS-TP Alarm Suppression July 2009 The Fault Location TLV has the following format: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Fault Location ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 octet field; it identifies the specific format of the Fault Location TLV, value = TBD; Length 2 octets field; it identifies the length in octets of the TLV Section that follows the length field. Set to 4 (octets) in case of IPv4 Address; set to 16 (octets) in case of IPv6 Address; set to 6 (octets) in case of MAC Address Fault Location Set to the IPv4/IPv6/MAC node/port address of the (Server)MEP generating the AIS/LCK packet. 6. AIS and LCK Packet The AIS and LCK packet have both the following format: Fulignoli and al. Expires January 9, 2010 [Page 6] Internet-Draft MPLS-TP Alarm Suppression July 2009 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| MPLS-TP AIS(0xHH)or LCK(0xYY) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Res1 | Flags |S| Res2 | Per | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Fault Location TLV(s) + : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first four bytes represent the G-ACH ([2]): - first nibble: set to 0001b to indicate a channel associated with a PW, a LSP or a Section; - G-ACH Version and Reserved fields are set to 0, as specified in [2]; - G-ACH Channel Type field with two different code point meaning, respectively, "MPLS-TP AIS packet" and "MPLS-TP LCK packet". Both value MUST be assigned. Version (Vers) 4 bit field, version number of the protocol; this document defines protocol version 0; Reserved (Res1) 4 bit field, reserved for future use; they MUST be set to all ZEROes in transmission and ignored in reception; Flags 7 bit field; reserved for future use; they MUST be set to all ZEROes in transmission and ignored in reception; Fault Location TLV present(S) 1 bit field; if set, the Fault Location TLV, as detailed in section 5. , is present. Fulignoli and al. Expires January 9, 2010 [Page 7] Internet-Draft MPLS-TP Alarm Suppression July 2009 Reserved (Res2) 5 bit field reserved for future use; they MUST be set to all ZEROes in transmission and ignored in reception; Period (Per) 3 bit field MUST be fixed to the ''100'' value indicating the transmission period of 1 second. Length 1 octet field; it is the total packet length in octet, excluded the G-ACH header; Fault Location TLV Optional and variable length field containing one ore more Fault Location TLV as detailed in section 5. 7. Security Considerations Security considerations for the authentication TLV need further study. 8. IANA Considerations 9. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Fulignoli and al. Expires January 9, 2010 [Page 8] Internet-Draft MPLS-TP Alarm Suppression July 2009 10. References 10.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Bocci, et al., " MPLS Generic Associated Channel ", RFC 5586 , June 2009 [3] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in MPLS Transport Networks", draft-ietf-mpls-tp-oam- requirements-02 (work in progress), June 2009 [4] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, Y., " MPLS-TP OAM Analysis", draft-sprecher-mpls-tp-oam- analysis-04 (work in progress), May 2009 [5] Busi,I., Niven-Jenkins, B. "MPLS-TP OAM Framework and Overview", draft-ietf-mpls-tp-oam-framework-00(work in progress), March 2009 [6] S. Boutros, et. al., "Definition of ACH TLV Structure", draft-ietf-mpls-tp-ach-tlv-00.txt, Work in Progress, June 2009. 10.2. Informative References Fulignoli and al. Expires January 9, 2010 [Page 9] Internet-Draft MPLS-TP Alarm Suppression July 2009 Authors' Addresses Annamaria Fulignoli Ericsson Email: annamaria.fulignoli@ericsson.com Nurit Sprecher Nokia Siemens Networks Email: nurit.sprecher@nsn.com Yaacov Weingarten Nokia Siemens Networks Email: yaacov.weingarten@nsn.com Fulignoli and al. Expires January 9, 2010 [Page 10]