Internet DRAFT - draft-fulignoli-mpls-tp-ais-lock-tool
draft-fulignoli-mpls-tp-ais-lock-tool
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
<Add any IANA considerations>
9. Acknowledgments
<Add any acknowledgements>
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]
