Internet DRAFT - draft-bhh-mpls-tp-oam-y1731
draft-bhh-mpls-tp-oam-y1731
MPLS Working Group I. Busi (Ed)
Internet Draft Alcatel-Lucent
Intended status: Standard Track H. van Helvoort (Ed)
J. He (Ed)
Huawei
Expires: July 2012 January 11, 2012
MPLS-TP OAM based on Y.1731
draft-bhh-mpls-tp-oam-y1731-08.txt
Abstract
This document describes methods to leverage Y.1731 [2] Protocol Data
Units (PDU) and procedures (state machines) to provide a set of
Operation, Administration, and Maintenance (OAM) mechanisms that
meets the MPLS Transport Profile (MPLS-TP) OAM requirements as
defined in [8].
In particular, this document describes the MPLS-TP technology
specific encapsulation mechanisms to carry these OAM PDUs within
MPLS-TP packets to provide MPLS-TP OAM capabilities in MPLS-TP
networks.
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
Busi and al. Expires July 11, 2012 [Page 1]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
Copyright Notice
Copyright (c) 2012 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.
Busi and al. Expires July 11, 2012 [Page 2]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
Table of Contents
1. Introduction.................................................4
1.1. Contributing Authors....................................5
2. Conventions used in this document............................5
2.1. Terminology.............................................6
3. Encapsulation of OAM PDU in MPLS-TP..........................6
4. MPLS-TP OAM Packet Formats...................................7
4.1. Continuity Check Message (CCM)..........................8
4.1.1. MEG ID Formats.....................................9
4.2. OAM Loopback (LBM/LBR)..................................9
4.2.1. Format of MEP and MIP ID TLVs.....................12
4.3. Alarm Indication Signal (AIS)..........................16
4.4. Lock Reporting (LCK)...................................16
4.5. Test (TST).............................................17
4.6. Loss Measurement (LMM/LMR).............................17
4.7. One-way delay measurement (1DM)........................17
4.8. Two-way delay Measurement Message/Reply (DM)...........17
4.9. Client Signal Fail (CSF)...............................18
5. MPLS-TP OAM Procedures......................................18
5.1. Continuity Check Message (MT-CCM) procedures...........18
5.2. OAM Loopback (MT-LBM/LBR) procedures...................20
5.3. Alarm Indication Signal (MT-AIS) procedures............21
5.4. Lock Reporting (LCK)...................................22
5.5. Test (TST).............................................23
5.6. Loss Measurement (LMM/LMR).............................23
5.7. One-way delay measurement (1DM)........................23
5.8. Two-way delay Measurement Message/Reply (DM)...........23
5.9. Client Signal Fail (CSF)...............................23
6. Security Considerations.....................................23
7. IANA Considerations.........................................23
8. Acknowledgments.............................................23
9. References..................................................25
9.1. Normative References...................................25
9.2. Informative References.................................25
Busi and al. Expires July 11, 2012 [Page 3]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
1. Introduction
This document describes the method for leveraging Y.1731 [2] Protocol
Data Units (PDUs) and procedures to provide a set of Operation,
Administration, and Maintenance (OAM) mechanisms that meet the MPLS
Transport Profile (MPLS-TP) OAM requirements as defined in [8].
This version of the draft does not introduce any technical change to
the -06 version of this draft.
ITU-T Recommendation Y.1731 [2] specifies:
o OAM PDUs and procedures that meet the transport networks
requirements for OAM
o Encapsulation mechanisms to carry these OAM PDUs within Ethernet
frames to provide Ethernet OAM capabilities in Ethernet networks
Although Y.1731 is focused on Ethernet OAM, the definition of OAM
PDUs and procedures are technology independent and can also be used
in other packet technologies (e.g., MPLS-TP) provided that the
technology specific encapsulation is defined.
The OAM toolset defined in Y.1731 [2] serves as a benchmark for a
high performance, comprehensive suite of packet transport OAM
capabilities. It can be provided by lightweight protocol design and
supports operational simplicity by providing commonality with the
established operation models utilized in other transport network
technologies (e.g., SDH/SONET and OTN).
This document describes mechanisms for MPLS-TP OAM that reuse the
same OAM PDUs and procedures defined in Y.1731 [2], together with the
necessary MPLS-TP technology specific encapsulation mechanisms.
The advantages offered by this toolset are summarized below:
o Simplify the operations for the network operators and service
providers that have to test and maintain a single general OAM
protocol set when operating LSP, PW and VPLS networks.
o Accelerate the market adoption of MPLS-TP since Y.1731 is already
mature, supported, and deployed.
o Reduce the complexity and increase the reuse of code for
implementation in packet transport devices that may support both
Busi and al. Expires July 11, 2012 [Page 4]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
Ethernet and MPLS-TP capabilities, e.g. VPLS and H-VPLS
applications.
It is worth noting that multi-vendor interoperable implementations of
the OAM mechanisms described in this document already exist to meet
the essential OAM requirements for MPLS-TP deployments in PTN
applications as described in [9].
Ethernet OAM is also defined by IEEE 802.1ag [14]. IEEE 802.1ag and
ITU-T Y.1731 have been developed in cooperation by IEEE and ITU. They
support a common subset of OAM functions. ITU-T Y.1731 further
extends this common subset with additional OAM mechanisms that are
important for the transport network (e.g. AIS, DM, LM).
This document does not deprecate existing MPLS and PW OAM mechanisms
nor preclude definition of other MPLS-TP OAM tools.
The mechanisms described in this document, when used to provide
MPLS-TP PW OAM functions, are open to support the OAM message mapping
procedures defined in [10]. In order to support those procedures, the
PEs MUST map the states of the procedures defined in Y.1731 to the PW
defect states defined in [10].
The mapping procedures are outside the scope of this document.
In the rest of this document the term "OAM PDU" is used to indicate
an OAM PDU whose format and associated procedures are defined in
Y.1731 [2] and that this document proposes to be used to provide
MPLS-TP OAM functions.
1.1. Contributing Authors
Italo Busi, Huub van Helvoort, Jia He, Christian Addeo, Alessandro
D'Alessandro, Simon Delord, John Hoffmans, Ruiquan Jing, Kam Lam,
Wang Lei, Han Li, Vishwas Manral, Masahiko Mizutani, Manuel Paul,
Josef Roese, Vincenzo Sestito, Yuji Tochio, Munefumi Tsurusawa,
Maarten Vissers, Rolf Winter
2. 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].
Busi and al. Expires July 11, 2012 [Page 5]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
2.1. Terminology
ACH Associated Channel Header
G-ACh Generic Associated Channel
GAL G-ACh Label
ME Maintenance Entity
MEL MEG Level
MEG Maintenance Entity Group
MEP Maintenance End Point
MIP Maintenance Intermediate Point
PTN Packet Transport Network
TLV Type Length Value
3. Encapsulation of OAM PDU in MPLS-TP
Although Y.1731 is focused on Ethernet OAM, the definition of OAM
PDUs and procedures are technology independent.
When used to provide Ethernet OAM capabilities, these PDUs are
encapsulated into an Ethernet frame where an Ethernet header is
prepended to the OAM PDUs.
The MAC DA is used to identify the MEPs and MIPs where the OAM PDU
needs to be processed. The EtherType is used to distinguish OAM
frames from user data frames.
Within MPLS-TP OAM Framework [6], OAM packets are distinguished from
user data packets using the GAL and ACH [5] construct and they are
addressed to MEPs or MIPs using existing MPLS forwarding mechanisms
(i.e. label stacking and TTL expiration). It is therefore possible to
reuse the OAM PDUs defined in [2] within MPLS-TP and encapsulate them
within ACH.
A single ACH Channel Type (0xXXXX) is required to identify the
presence of Y.1731 OAM PDU. Within the OAM PDU, the OpCode field,
defined in [2], allows identifying the specific OAM PDU.
Busi and al. Expires July 11, 2012 [Page 6]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
OAM PDUs are encapsulated using the ACH, according to [5], as
described in Figure 1 below.
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| Y.1731 Channel Type (0xXXXX) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MEL | Version | OpCode | Flags | TLV Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| OAM function specific fields |
| (Y.1731 based) |
+ +
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 G-ACh Packet carrying a Y.1731 PDU
Moreover, MPLS-TP relies upon a different mechanism for supporting
tandem connection monitoring (i.e. label stacking) than the fixed MEL
(Maintenance Entity Group Level) field used in Ethernet.
Therefore in MPLS-TP the MEL field is allowed not to be used for
supporting tandem connection monitoring.
When OAM PDUs are used in MPLS-TP, the MEL field MUST be set on
transmission and checked at reception for compliancy with Y.1731 [2].
The MEL value to set and check MUST be configurable. The DEFAULT
value MUST be "111". With co-routed bidirectional transport paths,
the configured MEL MUST be the same in both directions.
The OpCode field identifies the type of the OAM PDU.
The setting of the Version, Flags and TLV Offset is OpCode specific
and described in Y.1731 [2].
4. MPLS-TP OAM Packet Formats
This section describes the OAM functions that can be supported
reusing the OAM PDUs and procedures defined in Y.1731 [2] to meet
MPLS-TP OAM Requirements, as defined in [8].
Busi and al. Expires July 11, 2012 [Page 7]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
This document is proposing not to use the Y.1731 MCC OAM PDU in
MPLS-TP. The solution proposed in [7], where MCC PDU is directly
encapsulated within an ACH with a PID, SHOULD be used instead.
The LTM/LTR OAM PDUs, as currently defined Y.1731 [2], are tracing
the path for a specific MAC address: this tool is therefore
addressing a different requirement than the "Route Tracing"
functional requirement described in section 2.2.4 of RFC 5860 [8].
Their purpose is to test the MAC Address Forwarding tables. Due to
the fact that MPLS-TP forwarding is not based on the MAC Address
Forwarding tables, these tools are not applicable to MPLS-TP as
currently defined.
Procedures for supporting the route tracing MPLS-TP OAM functional
requirement (section 2.2.4 of RFC 5860 [8]) are outside the scope of
this document.
4.1. Continuity Check Message (CCM)
The CCM PDU is defined in Y.1731 [2]. When encapsulated within MPLS-
TP as described in section 3, it can be used to support the following
MPLS-TP OAM functional requirements:
o Pro-active continuity check (section 2.2.2 of RFC 5860 [8]);
o Pro-active connectivity verification (section 2.2.3 of RFC 5860
[8]);
o Pro-active remote defect indication (section 2.2.9 of RFC 5860
[8]);
o Pro-active packet loss measurement (section 2.2.11 of RFC 5860
[8]).
Procedures for transmitting and receiving CCM PDUs are defined in
Y.1731 [2] and described in section 5.1.
It is worth noting that the use of CCM does not require any
additional status information other than the configuration parameters
and defect states.
The transmission period of the CCM MUST always be the configured
period and MUST not change unless the operator reconfigures it. This
is a fundamental requirement to allow deterministic and predictable
Busi and al. Expires July 11, 2012 [Page 8]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
protocol behavior: in transport networks the operator configures and
fully controls the repetition rate of pro-active CC-V.
In order to perform pro-active Connectivity Verification, the CCM
packet contains a globally unique identifier of the source MEP, as
described in [6].
The source MEP for LSPs, PWs and Sections is identified by combining
a globally unique MEG ID (see section 4.1.1) with a MEP ID that is
unique within the scope of the Maintenance Entity Group.
4.1.1. MEG ID Formats
The generic format for MEG ID is defined in Figure A-1 of Y.1731 [2].
Different formats of MEG ID are allowed: the MEG ID format type is
identified by the MEG ID Format field.
The format of the ICC-based MEG ID is defined in Annex A of Y.1731
[2]. This format is applicable to MPLS-TP Sections, LSPs and PWs.
MPLS-TP supports also IP-based format for MEG ID. These formats are
still under definition in [12] and therefore outside the scope of
this document.
4.2. OAM Loopback (LBM/LBR)
The LBM/LBR PDUs, defined in Y.1731 [2]. When encapsulated within
MPLS-TP, as described in section 3, they can be used to support the
following MPLS-TP OAM functional requirements:
o On-demand bidirectional connectivity verification (section 2.2.3
of RFC 5860 [8]);
o Bidirectional in-service or out-of-service diagnostic test (section
2.2.5 of RFC 5860 [8]).
Procedures for transmitting and receiving LBM/LBR PDUs are defined in
Y.1731 [2] and described in section 5.2.
It is worth noticing that these OAM PDUs cover different functions
than those defined in [11].
When the LBM/LBR is used for out-of-service diagnostic test, it is
REQUIRED that the transport path is locked on both MEPs before the
diagnostic test is performed. In transport networks, the transport
Busi and al. Expires July 11, 2012 [Page 9]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
path is locked on both sides by network management operations.
However, single-ended procedures as defined in [11] MAY be used.
In order to allow proper identification of the target MEP/MIP the LBM
is addressed to, the LBM PDU MUST include the Target MEP/MIP ID TLV:
this TLV MUST be present in an LBM PDU and MUST be located at the top
of the TLVs (i.e., it MUST start at the offset indicated by the TLV
Offset field).
A LBM packet with the Target MIP/MEP ID equal to the ID of receiving
MIP or MEP is considered to be a valid LBM packet. Every field in the
LBM packet is copied to the LBR packet, only the OpCode field is
changed from LBM to LBR.
To allow proper identification of the actual MEP/MIP that has replied
to an LBM PDU, the LBR PDU MUST include the Replying MEP/MIP ID TLV:
this TLV MUST be present in an LBR PDU and it MUST be located at the
top of the TLVs (i.e., it MUST start at the offset indicated by the
TLV Offset field).
In order to simplify hardware based implementations, these TLVs have
been defined to have a fixed position (as indicated by the TLV Offset
field) and a fixed length (see clause 4.2.1).
It is worth noting that the MEP/MIP identifiers used in the Target
MEP/MIP ID and in the Replying MEP/MIP ID TLVs SHOULD be unique
within the scope of the MEG. When LBM/LBR OAM is used for
connectivity verification purposes, there are some misconnectivity
cases that could not be easily located by simply relying upon these
TLVs. In order to locate these misconnectivity configurations, the
LBM PDU SHOULD carry a Requesting MEP ID TLV that provides a globally
unique identification of the MEP that has originated the LBM PDU.
When the Requesting MEP ID TLV is present in the LBM PDU, the
replying MIP/MEP MUST check that the received requesting MEP
identifier matches with the expected requesting MEP identifier before
replying. In this case, the LBR PDU MUST carry the Requesting MEP ID
TLV confirming to the MEP the LBR PDU is sent to that the Requesting
MEP ID TLV in the LBM PDU has been checked before replying.
When LBM/LBR OAM is used for bidirectional diagnostic tests, the
Requesting MEP ID TLVs MUST NOT be included.
The format of the LBM and LBR PDUs are shown in Figure 2 and in
Figure 3.
Busi and al. Expires July 11, 2012 [Page 10]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
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| Y.1731 Channel Type (0xXXXX) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MEL | Version | OpCode | Flags | TLV Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID/Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target MEP/MIP ID TLV |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [optional Requesting MEP ID TLV] |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [other optional TLV starts here] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End TLV |
+-+-+-+-+-+-+-+-+-+
Figure 2 LBM Packet Format
The OpCode MUST be set to 0x03 (LBM). The TLV Offset MUST be set to
0x04. The formats of the Target MEP/MIP ID TLV and of the Requesting
MEP ID TLV are defined in 4.2.1.
The Target MEP/MIP ID MUST be always present as the first TLV within
the LBM PDU. When present, the Requesting MEP ID TLV MUST immediately
follow the Target MEP/MIP ID TLV.
When the LBM packet is sent to a target MIP, the source MEP MUST know
the hop count to the target MIP and set the TTL field accordingly, as
described in [6].
This solution allows supporting per-node and per-interface MIP
implementations as described in section 3.4 of [6]:
o In the case of a per-node MIP implementation, the LBM packet is
processed in the per-node MIP if the Target MEP/MIP ID matches the
per-node MIP identifier; otherwise, the LBM packet is dropped;
Busi and al. Expires July 11, 2012 [Page 11]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
o In the case of a per-interface MIP implementation, the LBM packet
is processed in the ingress MIP if the Target MEP/MIP ID matches
the ingress MIP identifier; otherwise, the LBM packet is forwarded
to the egress port(s) together (i.e., fate sharing) with the user
data packets. The LBM packet is processed in the egress MIP if the
Target MEP/MIP ID matches the egress MIP identifier; otherwise,
the LBM packet is dropped.
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| Y.1731 Channel Type (0xXXXX) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MEL | Version | OpCode | Flags | TLV Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID/Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replying MEP/MIP ID TLV |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [optional Requesting MEP ID TLV] |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [other optional TLV starts here] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End TLV |
+-+-+-+-+-+-+-+-+-+
Figure 3 LBR Packet Format
The Replying MEP/MIP ID TLV MUST be present as the first TLV within
the LBR PDU. When present, the Requesting MEP ID TLV MUST follow the
Replying MEP/MIP ID TLV within the LBR PDU.
4.2.1. Format of MEP and MIP ID TLVs
The format of the Target and Replying MIP/MEP ID TLVs are shown in
Figure 4 and Figure 5.
Busi and al. Expires July 11, 2012 [Page 12]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
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 (0x21) | Length (25) | Sub-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| MEP/MIP Identifier (format is ID Sub-Type specific) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 Target MEP/MIP ID TLV 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 (0x22) | Length (25) | Sub-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| MEP/MIP Identifier (format is ID Sub-Type specific) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 Replying MEP/MIP ID TLV format
Different formats of MEP/MIP identifiers MAY be used: the format type
is described by the MEP/MIP ID Sub-Type field.
The "Discovery ingress/node MEP/MIP" and the "Discovery egress
MEP/MIP" identifiers MAY only be used within the LBM PDU (and MUST
NOT appear in an LBR PDU) for discovering the identifiers of the MEPs
or of the MIPs located at a given TTL distance from the MEP
originating the LBM PDU.
The format of the Target MEP/MIP ID TLV carrying a "Discovery
ingress/node MEP/MIP" is shown in Figure 6.
Busi and al. Expires July 11, 2012 [Page 13]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
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 (0x21) | Length (25) |Sub-Type (0x00)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| MUST be ZERO |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 Target MEP/MIP ID TLV format (discovery ingress/node
MEP/MIP)
The format of the Target MEP/MIP ID TLV carrying a "Discovery egress
MEP/MIP" is shown in Figure 7.
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 (0x21) | Length (25) |Sub-Type (0x01)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| MUST be ZERO |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7 Target MEP/MIP ID TLV format (discovery egress MEP/MIP)
The format of the Target or Replying MEP/MIP ID TLV carrying an
"ICC-based MEP ID" is shown in Figure 8.
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 | Length (25) |Sub-Type (0x02)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MEP ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ... |
| MUST be ZERO |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8 Target or Replying MEP/MIP ID TLV format (ICC-based MEP ID)
Busi and al. Expires July 11, 2012 [Page 14]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
The MEP ID is a 16-bit integer value identifying the transmitting MEP
within the MEG.
The format of the Target or Replying MEP/MIP ID TLV carrying an
"ICC-based MIP ID" is shown in Figure 9.
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 | Length (25) |Sub-Type (0x03)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITU-T Carrier Code (ICC) |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Node-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Node-ID | IF-Num |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IF-Num | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ... |
| MUST be ZERO |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9 Target or Replying MEP/MIP ID TLV format (ICC-based MIP ID)
The ITU-T Carrier Code (ICC) is a code assigned to a network
operator/service provider and maintained by the ITU-T
Telecommunication Standardization Bureau (TSB) as per [13].
The Node-ID is a numeric identifier of the node where the MIP is
located. Its assignment is a matter for the organization to which the
ICC has been assigned, provided that uniqueness within that
organization is guaranteed.
The IF-Num is a numeric identifier of the Access Point (AP) toward
the server layer trail, which can be either an MPLS-TP or a non
MPLS-TP server layer, where a per-interface MIP is located. Its
assignment is a matter for the node the MIP is located, provided that
uniqueness within that node is guaranteed. Note that the value 0 for
IF-Num is reserved to identify per-node MIPs.
MPLS-TP supports also IP-based format for MIP and MEP identifiers.
These formats are still under definition in [12] and therefore
outside the scope of this document.
Busi and al. Expires July 11, 2012 [Page 15]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
The format of the Requesting MEP ID TLVs is shown in Figure 10.
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 (0x23) | Length (53) | Loopback Ind. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MEP ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| MEG ID |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Reserved (0x0000) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10Requesting MEP ID TLV format
The MEP ID and MEG ID carry the globally unique MEP ID as defined in
section 4.1.1.
The Reserved bits MUST be set to all-ZEROes in transmission and
ignored in reception.
The Loopback Indication MUST be set to 0x0000 when this TLV is
inserted in an LBM PDU and SHOULD be set to 0x0001 in the LBR PDU.
This is used to indicate that the value of this TLV has been checked
by the node that generated the LBR PDU.
4.3. Alarm Indication Signal (AIS)
The AIS PDU is defined in Y.1731 [2]. When encapsulated within MPLS-
TP, as described in section 3, it can be used to support the alarm
reporting MPLS-TP OAM functional requirement (section 2.2.8 of RFC
5860 [8]).
Procedures for transmitting and receiving AIS PDUs are defined in
Y.1731 [2] and described in section 5.3.
4.4. Lock Reporting (LCK)
The LCK PDU is defined in Y.1731 [2]. When encapsulated within MPLS-
TP, as described in section 3, it can be used to support the lock
reporting MPLS-TP OAM functional requirement (section 2.2.7 of RFC
5860 [8]).
Busi and al. Expires July 11, 2012 [Page 16]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
Procedures for transmitting and receiving LCK PDUs are defined in
Y.1731 [2] and described in section 5.4.
4.5. Test (TST)
The TST PDU is defined in Y.1731 [2]. When encapsulated within MPLS-
TP, as described in section 3, it can be used to support the
uni-directional in-service or out-of-service diagnostic tests MPLS-TP
OAM functional requirement (section 2.2.8 of RFC 5860 [8]).
Procedures for transmitting and receiving TST PDUs are defined in
Y.1731 [2] and described in section 5.5.
4.6. Loss Measurement (LMM/LMR)
The LMM/LMR PDUs are defined in Y.1731 [2]. When encapsulated within
MPLS-TP, as described in section 3, they can be used to support on-
demand packet loss measurement MPLS-TP OAM functional requirement
(section 2.2.11 of RFC 5860 [8]).
Procedures for transmitting and receiving LMM/LMR PDUs are defined in
Y.1731 [2] and described in section 5.6.
4.7. One-way delay measurement (1DM)
The 1DM PDU is defined in Y.1731 [2]. When encapsulated within MPLS-
TP, as described in section 3, it can be used to support the on-
demand one-way packet delay measurement MPLS-TP OAM functional
requirement (section 2.2.12 of RFC 5860 [8]).
It can also be used to support proactive one-way delay measurement
MPLS-TP OAM functional requirement (section 2.2.12 of RFC 5860 [8]).
Procedures for transmitting and receiving 1DM PDUs are defined in
Y.1731 [2] and described in section 5.7.
4.8. Two-way delay Measurement Message/Reply (DM)
The DMM/DMR PDUs are defined in Y.1731 [2]. When encapsulated within
MPLS-TP, as described in section 3, they can be used to support on-
demand two-ways packet delay measurement MPLS-TP OAM functional
requirement (section 2.2.12 of RFC 5860 [8]).
Busi and al. Expires July 11, 2012 [Page 17]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
They can also be used to support proactive two-ways packet delay
measurement MPLS-TP OAM functional requirement (section 2.2.12 of RFC
5860 [8]).
Procedures for transmitting and receiving DMM/DMR PDUs are defined in
Y.1731 [2] and described in section 5.8.
4.9. Client Signal Fail (CSF)
The CSF PDU is defined in Y.1731 Amendment 1 [3]. When encapsulated
within MPLS-TP, as described in section 3, it can be used to support
the client failure indication MPLS-TP OAM functional requirement
(section 2.2.10 of RFC 5860 [8]).
Procedures for transmitting and receiving CSF PDUs are defined in
Y.1731 Amendment 1 [3] and described in section 5.9.
5. MPLS-TP OAM Procedures
The high level procedures for processing Y.1731 OAM PDUs are
described in [2] and [3]. The technology independent procedures are
also applicable to MPLS-TP OAM.
More detailed and formal procedures for processing Y.1731 OAM PDUs
are defined in G.8021 [4]. Although the description in [4] is
Ethernet-specific, the technology independent procedures are also
applicable to MPLS-TP OAM.
This section describes the MPLS-TP OAM procedures based on the
technology independent ones defined in [2], [3] and [4].
5.1. Continuity Check Message (MT-CCM) procedures
The MT-CCM PDU format is defined in section 4.1.
When CCM generation is enabled, the MEP MUST generate CCM OAM packets
with the periodicity and the PHB configured by the operator:
o MEL field MUST be set to the configured value (see section 3);
o Version field MUST be set to 0 (see section 3);
o OpCode field MUST be set to 0x01 (see section 4.1);
Busi and al. Expires July 11, 2012 [Page 18]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
o RDI flag MUST be set, if the MEP asserts signal file. Otherwise,
it MUST be cleared;
o Reserved flags MUST be set to 0 (see section 4.1);
o Period field MUST be set according to the configured periodicity
(see Table 9-3 of [2]);
o TLV Offset field MUST be set to 70 (see section 4.1);
o Sequence Number MUST be set to 0 (see section 4.1);
o MEP ID and MEG ID fields MUST carry the configured values;
o The TxFCf field MUST carry the current value of the counter for
in-profile data packets transmitted towards the peer MEP, when
pro-active loss measurement is enabled. Otherwise it MUST be set
to 0.
o The RxFCb field MUST carry the current value of the counter for
in-profile data packets received from the peer MEP, if pro-active
loss measurement is enabled. Otherwise it MUST be set to 0.
o The TxFCb field MUST carry the value of TxFCf of the last received
CCM PDU from the peer MEP, if pro active loss measurement is
enabled. Otherwise it MUST be set to 0.
o Reserved field MUST be set to 0 (see section 4.1);
o End TLV MUST be inserted after the Reserved field (see section
4.1).
The transmission period of the CCM is always the configured period
and does not change unless the operator reconfigures it.
When a MEP receives a CCM OAM packet, it checks the various fields
(see Figure 8-19 of [4]). The following defects are detected as
described in clause 6.1 of [4]: dLOC, dUNL, dMMG, dUNM, dUNP, dUNPr
and dRDI.
If the Version, MEL, MEG and MEP fields are valid and pro-active loss
measurement is enabled, the values of the packet counters are
processed as described in clause 8.1.7.4 of [4].
Busi and al. Expires July 11, 2012 [Page 19]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
5.2. OAM Loopback (MT-LBM/LBR) procedures
The MT-LBM/LBR PDU formats are defined in section 4.2.
When an out-of-service OAM loopback function is performed, client
data traffic is disrupted in the diagnosed ME. The MEP configured for
the out-of-service test MUST transmit MT-LCK packets in the immediate
client (sub-)layer, as described in section 5.4.
When an in-service OAM loopback function is performed, client data
traffic is not disrupted and the packets with MT-LBM/LBR information
are transmitted in such a manner that a limited part of the service
bandwidth is utilized. The periodicity for packets with MT-LBM/LBR
information is pre-determined.
When on-demand OAM loopback is enabled at a MEP, the (requesting) MEP
MUST generate and send to one of the MIPs or the peer MEP MT-LBM OAM
packets with the periodicity and the PHB configured by the operator:
o MEL field MUST be set to the configured value (see section 3);
o Version field MUST be set to 0 (see section 3);
o OpCode field MUST be set to 0x03 (see section 4.2);
o Flags field MUST be set to all-ZEROes (see section 4.2);
o TLV Offset field MUST be set to 4 (see section 4.2);
o Transaction field is a 4-octet field that contains the transaction
ID/sequence number for the loop-back measurement;
o Target MEP/MIP-ID and Originator MEP-ID fields are set to carry
the configured values;
o Optional TLV field whose length and contents are configurable at
the requesting MEP. The contents can be a test pattern and an
optional checksum. Examples of test patterns include pseudo-random
bit sequence (PRBS) (2^31-1) as specified in sub-clause 5.8/O.150,
all '0' pattern, etc. For bidirectional diagnostic test
application, configuration is required for a test signal generator
and a test signal detector associated with the MEP;
o End TLV field is set to all-ZEROes (see section 4.2).
Busi and al. Expires July 11, 2012 [Page 20]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
Whenever a valid MT-LBM packet is received by a (receiving) MIP or a
(receiving) MEP, an MT-LBR packet is generated and transmitted by the
receiving MIP/MEP to the requesting MEP:
o MEL field MUST be copied from the received MT-LBM PDU;
o Version field MUST be copied from the received MT-LBM PDU;
o OpCode field MUST be set to 2 (see section 4.2);
o Flags field MUST be copied from the received MT-LBM PDU;
o TLV Offset field MUST be copied from the received MT-LBM PDU;
o Transaction field MUST be copied from the received MT-LBM PDU
o The Target MEP/MIP-ID and Originator MEP-ID fields are is set to
the value which is copied from the last received MT-LBM PDU;
o The Optional TLV field MUST be copied from the received MT-LBM
PDU;
o End TLV field MUST be inserted after the last TLV field and it
MUST be copied from the last received MT-LBM PDU.
5.3. Alarm Indication Signal (MT-AIS) procedures
The MT-AIS PDU format is described in section 4.3.
When the server layer trail termination sink asserts signal fail, it
notifies the server/MT_A_Sk function that raises the aAIS consequent
action. The aAIS is cleared when the server layer trail termination
clears the signal fail condition and notifies the server/MT_A_Sk.
When the aAIS consequent action is raised, the server/MT_A_Sk MUST
continuously generate MPLS-TP OAM packets carrying the AIS PDU until
the aAIS consequent action is cleared:
o MEL field MUST be set to the configured value (see section 3):
o Version field MUST be set to 0 (see section 3):
o OpCode MUST be set to 0x21 (see section 4.3):
o Reserved flags MUST be set to 0 (see section 4.3):
Busi and al. Expires July 11, 2012 [Page 21]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
o Period field MUST be set according to the configure periodicity
(see Table 9-4 of [2]);
o TLV Offset MUST be set to 0 (see section 4.3):
o End TLV MUST be inserted after the TLV Offset field (see section
4.3).
The DEFAULT periodicity for MT-AIS is once per second.
The generated AIS packets MUST be inserted in the incoming stream,
i.e., the output stream contains the incoming packets and the
generated AIS packets.
When a MEP receives an AIS packet with the correct MEL value, it MUST
detect the dAIS defect as described in clause 6.1 of [4].
5.4. Lock Reporting (LCK)
The MT-LCK PDU format is described in section 4.4.
When the access to the server layer trail is administratively locked
by the operator, the server/MT_A_So and server/MT_A_Sk functions
raise the aLCK consequent action. The aLCK is cleared when the access
to the server layer trail is administratively unlocked.
When the aLCK consequent action is raised, the server/MT_A_So and
server/MT_A_Sk MUST continuously generate, on both directions,
MPLS-TP OAM packets carrying the LCK PDU until the aLCK consequent
action is cleared:
o MEL field MUST be set to the configured value (see section 3):
o Version field MUST be set to 0 (see section 3):
o OpCode MUST be set to 0x23 (see section 4.4):
o Reserved flags MUST be set to 0 (see section 4.4):
o Period field MUST be set according to the configure periodicity
(see Table 9-4 of [2]);
o TLV Offset MUST be set to 0 (see section 4.4):
Busi and al. Expires July 11, 2012 [Page 22]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
o End TLV MUST be inserted after the TLV Offset field (see section
4.4).
The DEFAULT periodicity for MT-LCK is once per second.
When a MEP receives an LCK packet with the correct MEL value, it
detects the dLCK defect as described in clause 6.1 of [4].
5.5. Test (TST)
5.6. Loss Measurement (LMM/LMR)
5.7. One-way delay measurement (1DM)
5.8. Two-way delay Measurement Message/Reply (DM)
5.9. Client Signal Fail (CSF)
6. Security Considerations
Spurious OAM messages, such as those defined in this document,
potentially could form a vector for a denial of service attack.
However, since these messages are carried in a control channel, one
would have to gain access to a node providing the service in order to
launch such an attack. Since transport networks are usually operated
as a walled garden, such threats are less likely.
7. IANA Considerations
IANA is requested to allocate a Channel Type value 0xXXXX to identify
an associated channel carrying all the OAM PDUs that are defined in
section 4
[Editor's note - The value 0x8902 has been proposed to keep the
channel type identical to the EtherType value used in Ethernet OAM]
8. Acknowledgments
The authors gratefully acknowledge the contributions of Malcolm
Betts, Zhenlong Cui, Feng Huang, Kam Lam, Jian Yang, Haiyan Zhang for
the definition of extensions to LBM/LBR required for supporting
on-demand connectivity verification OAM functions.
The authors would like to thank all the members of the CCSA for their
comments and support.
Busi and al. Expires July 11, 2012 [Page 23]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
The authors would also like to thank Brian Branscomb, Feng Huang, Kam
Lam, Fang Li, Akira Sakurai and Yaakov Stein for their comments and
enhancements to the text.
This document was prepared using 2-Word-v2.0.template.dot.
Busi and al. Expires July 11, 2012 [Page 24]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ITU-T Recommendation Y.1731 (02/08), "OAM functions and
mechanisms for Ethernet based networks", February 2008
[3] ITU-T Recommendation Y.1731 Amendment 1 (07/10), "OAM functions
and mechanisms for Ethernet based networks", July 2010
[4] ITU-T Recommendation G.8021 (12/07), "Characteristics of
Ethernet transport network equipment functional blocks",
December 2007
[5] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R.,
"MPLS Generic Associated Channel", RFC 5586, June 2009
[6] Busi, I., Allan, D., " Operations, Administration and
Maintenance Framework for MPLS-based Transport Networks",
draft-ietf-mpls-tp-oam-framework-11 (work in progress),
February 2011
[7] Beller, D., Farrel, A., "An Inband Data Communication Network
For the MPLS Transport Profile", RFC 5718, January 2010
9.2. Informative References
[8] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
MPLS Transport Networks", RFC 5860, May 2010
[9] Li, F., Li, H., D'Alessandro, A., Jing, R., Wang, G., "Operator
Considerations on MPLS-TP OAM Mechanisms",
draft-fang-mpls-tp-oam-considerations-02 (work in progress),
July 2011
[10] Nadeau, T., et al., "Pseudo Wire (PW) OAM Message Mapping",
draft-ietf-pwe3-oam-msg-map-16 (work in progress), April 2011
[11] Boutros, S., et al., "Operating MPLS Transport Profile LSP in
Loopback Mode", draft-ietf-mpls-tp-li-lb-02 (work in progress),
June 2011
Busi and al. Expires July 11, 2012 [Page 25]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
[12] Swallow, G., Bocci, M., " MPLS-TP Identifiers", draft-ietf-
mpls-tp-identifiers-02 (work in progress), July 2010
[13] ITU-T Recommendation M.1400 (07/06), " Designations for
interconnections among operators' networks", July 2006
[14] IEEE Standard 802.1ag-2007, "IEEE Standard for Local and
Metropolitan Area Networks: Connectivity Fault Management",
September 2007
Author's Addresses
Italo Busi (Editor)
Alcatel-Lucent
Email: Italo.Busi@alcatel-lucent.com
Huub van Helvoort (Editor)
Huawei Technologies
Email: hhelvoort@huawei.com
Jia He (Editor)
Huawei Technologies
Email: hejia@huawei.com
Contributing Authors' Addresses
Christian Addeo
Alcatel-Lucent
Email: Christian.Addeo@alcatel-lucent.com
Alessandro D'Alessandro
Telecom Italia
Email: alessandro.dalessandro@telecomitalia.it
Busi and al. Expires July 11, 2012 [Page 26]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
Simon Delord
Telstra
Email: simon.a.delord@team.telstra.com
John Hoffmans
KPN
Email: john.hoffmans@kpn.com
Ruiquan Jing
China Telecom
Email: jingrq@ctbri.com.cn
Hing-Kam (Kam) Lam
Alcatel-Lucent
Email: Kam.Lam@alcatel-lucent.com
Wang Lei
China Mobile Communications Corporation
Email: wangleiyj@chinamobile.com
Han Li
China Mobile Communications Corporation
Email: lihan@chinamobile.com
Vishwas Manral
IPInfusion Inc
Email: vishwas@ipinfusion.com
Busi and al. Expires July 11, 2012 [Page 27]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
Masahiko Mizutani
Hitachi, Ltd.
Email: masahiko.mizutani.ew@hitachi.com
Manuel Paul
Deutsche Telekom
Email: Manuel.Paul@telekom.de
Josef Roese
Deutsche Telekom
Email: Josef.Roese@t-systems.com
Vincenzo Sestito
Alcatel-Lucent
Email: vincenzo.sestito@alcatel-lucent.com
Yuji Tochio
Fujitsu
Email: tochio@jp.fujitsu.com
Munefumi Tsurusawa
KDDI R&D Labs
Email: tsuru@kddilabs.jp
Maarten Vissers
Huawei Technologies
Email: maarten.vissers@huawei.com
Busi and al. Expires July 11, 2012 [Page 28]
Internet-Draft MPLS-TP OAM based on Y.1731 January 2012
Rolf Winter
NEC
Email: Rolf.Winter@nw.neclab.eu
Busi and al. Expires July 11, 2012 [Page 29]
