MPLS Working Group A. Fulignoli Internet Draft Ericsson Intended status: Standard Track Y.Weingarten N.Sprecher Nokia Siemens Networks Expires: September 2009 March 3, 2009 MPLS-TP OAM Alarm Suppression Tools draft-fulignoli-mpls-tp-ais-lock-tool-00.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 Notice 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Fulignoli and al. Expires August 27, 2009 [Page 1] Internet-Draft MPLS-TP Alarm Suppression February 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. Fault Location TLV..........................................4 3. AIS and LOCK Packet.........................................5 4. Security Considerations.....................................7 5. IANA Considerations.........................................7 6. Acknowledgments.............................................7 7. References..................................................7 7.1. Normative References...................................7 7.2. Informative References.................................8 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 Indication 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 Indication (LOCK) Information notify an administrative traffic locking condition. Upon receiving a packet with AIS or LOCK information, a MEP detects an AIS/LOCK defect condition and suppresses loss of continuity alarms associated with all its peer MEPs. Both AIS and LOCK defect contribute to the signal fail condition of the receiving MEPs that may result, in turn, in the transmission of AIS packets to its own client MEPs. Fulignoli and al. Expires August 27, 2009 [Page 2] Internet-Draft MPLS-TP Alarm Suppression February 2009 For the detailed behavior description of the Alarm Indication Signal function and Lock Indication function please refer to [5]. The periodicity of AIS and LOCK packet is fixed to one second. The first packet is sent as soon as the associated event (defect condition or administrative traffic locking) occurs. 1.1. Terminology AIS Alarm Indication Signal LME LSP Maintenance Entity ME Maintenance Entity MEP Maintenance End Point MIP Maintenance Intermediate Point PME PW Maintenance Entity SME Section Maintenance Entity TCME Tandem Connection Maintenance Entity TPME Tandem PW 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]. Fulignoli and al. Expires August 27, 2009 [Page 3] Internet-Draft MPLS-TP Alarm Suppression February 2009 2. Fault Location TLV One or more Fault Location TLV MAY be included, under operator configuration, in the AIS or LOCK packet; the DEFAULT mode is not to include it. When a MEP receives an AIS/LOCK with the Fault Location TLV and it is configured to (re)generate the AIS packet to its client MEP (in the forward direction) the following cases can occur: 1. The MEP is configured to(re)generate AIS messages with no Fault Location TLV 2. The MEP is configured to(re)generate AIS 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 messages with the Fault Location TLV copied from the received AIS/LOCK 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. 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 ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fulignoli and al. Expires August 27, 2009 [Page 4] Internet-Draft MPLS-TP Alarm Suppression February 2009 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 port/node address of the (Server)MEP generating the AIS/LOCK packet. 3. AIS and LOCK Packet The AIS and LOCK packet have both 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1|0 0 0 0|0 0 0 0 0 0 0 0| MPLS-TP AIS(0xHH)or LOCK(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]; Fulignoli and al. Expires August 27, 2009 [Page 5] Internet-Draft MPLS-TP Alarm Suppression February 2009 - G-ACH Channel Type field with two different code point meaning, respectively, "MPLS-TP AIS packet" and "MPLS-TP LOCK 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 2. , is present. 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 2. Fulignoli and al. Expires August 27, 2009 [Page 6] Internet-Draft MPLS-TP Alarm Suppression February 2009 4. Security Considerations Security considerations for the authentication TLV need further study. 5. IANA Considerations 6. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. 7. References 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R., "MPLS Generic Associated Channel ", draft-ietf-mpls-tp-gach- gal-01 (work in progress), January 2009 [3] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements- 00 (work in progress), November 2008 [4] Sprecher, N., Nadeau, T., van Helvoort, H., Weingarten, Y., " MPLS-TP OAM Analysis", draft-sprecher-mpls-tp-oam-analysis-02 (work in progress), September 2008 [5] Busi,I., Niven-Jenkins, B. "MPLS-TP OAM Framework and Overview", draft-busi-mpls-tp-oam-framework-00(work in progress), October 2008 [6] S. Boutros, et. al., "Definition of ACH TLV Structure", draft- bryant-mpls-tp-ach-tlv-00.txt, Work in Progress, January 2009. Fulignoli and al. Expires August 27, 2009 [Page 7] Internet-Draft MPLS-TP Alarm Suppression February 2009 7.2. Informative References 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 August 27, 2009 [Page 8]