MPLS Working Group I. Busi (Ed)
Internet Draft Alcatel-Lucent
Intended status: Standard Track H. van Helvoort (Ed)
J. He (Ed)
Huawei
Expires: January 2011 July 12, 2010
MPLS-TP OAM based on Y.1731
draft-bhh-mpls-tp-oam-y1731-05.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 [6].
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 January 12, 2011 [Page 1]
Internet-Draft MPLS-TP OAM based on Y.1731 July 2010
Copyright Notice
Copyright (c) 2010 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Busi and al. Expires January 12, 2011 [Page 2]
Internet-Draft MPLS-TP OAM based on Y.1731 July 2010
Table of Contents
1. Introduction.................................................4
1.1. Contributing Authors....................................5
2. Conventions used in this document............................5
2.1. Terminology.............................................5
3. Encapsulation of OAM PDU in MPLS-TP..........................6
4. MPLS-TP OAM Functions........................................7
4.1. Pro-active CC-V and RDI (CCM)...........................8
4.1.1. MEG ID Formats.....................................9
4.2. OAM Loopback (LB).......................................9
4.2.1. Format of MEP and MIP ID TLV......................11
4.3. Alarm Indication Signal (AIS)..........................11
4.4. Lock Reporting (LCK)...................................11
4.5. Test (TST).............................................11
4.6. Automatic Protection Switching (APS)...................11
4.7. Loss Measurement (LM)..................................12
4.8. One-way delay measurement (1DM)........................12
4.9. Two-way delay Measurement Message/Reply (DM)...........12
5. Security Considerations.....................................12
6. IANA Considerations.........................................13
7. Acknowledgments.............................................13
8. References..................................................14
8.1. Normative References...................................14
8.2. Informative References.................................14
Busi and al. Expires January 12, 2011 [Page 3]
Internet-Draft MPLS-TP OAM based on Y.1731 July 2010
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 [6].
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
Ethernet and MPLS-TP capabilities, e.g. VPLS and H-VPLS
applications.
Busi and al. Expires January 12, 2011 [Page 4]
Internet-Draft MPLS-TP OAM based on Y.1731 July 2010
Ethernet OAM is also defined by IEEE 802.1ag [9]. 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. IEEE 802.1ag defines
additional status reporting that is advantageous in enterprise
networks but not required in transport networks. ITU-T Y.1731 defines
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 [7]. 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 [7].
The mapping procedures are outside the scope of this version of the
document. They will be specified in a future version of this
document, in a future version of [7] or in another document that
updates [7].
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, Wang Lei,
Han Li, Vishwas Manral, Julien Meuric, Masahiko Mizutani, Philippe
Niger, Manuel Paul, Josef Roese, Vincenzo Sestito, Yaakov Stein, 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].
2.1. Terminology
ACH Associated Channel Header
Busi and al. Expires January 12, 2011 [Page 5]
Internet-Draft MPLS-TP OAM based on Y.1731 July 2010
ME Maintenance Entity
MEG Maintenance Entity Group
MEP Maintenance End Point
MIP Maintenance Intermediate Point
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 [4], OAM packets are distinguished from
user data packets using the GAL and ACH [3] 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 (0xXX) 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.
OAM PDUs are encapsulated using the ACH, according to [3], as
described in Figure 1 below.
Busi and al. Expires January 12, 2011 [Page 6]
Internet-Draft MPLS-TP OAM based on Y.1731 July 2010
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 (0xXX) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 not 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 Functions
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 [6].
Busi and al. Expires January 12, 2011 [Page 7]
Internet-Draft MPLS-TP OAM based on Y.1731 July 2010
This document is proposing not to use the Y.1731 MCC OAM PDU in
MPLS-TP. The solution proposed in [5], 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. 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.
In order to support the MPLS-TP OAM Requirements for Route Tracing,
as defined in [6], two options are possible:
o extend the current definition of LTM/LTR to make them applicable
to MPLS-TP;
o define a new tool (as reported in section 1, this document is not
precluding the definition of other MPLS-TP OAM tools).
4.1. Pro-active CC-V and RDI (CCM)
The CCM PDU, defined in Y.1731 [2] and encapsulated within MPLS-TP as
described in section 3, can be used to support the following MPLS-TP
OAM functional requirements:
o Pro-active continuity check (section 2.2.2 of [6]);
o Pro-active connectivity verification (section 2.2.3 of [6]);
o Pro-active remote defect indication (section 2.2.9 of [6]);
o Pro-active packet loss measurement (section 2.2.11 of [6]).
Procedures for generating and processing CCM PDUs are defined in
Y.1731 [2].
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
protocol behavior: in transport networks the operator configures and
fully controls the repetition rate of pro-active CC-V.
Busi and al. Expires January 12, 2011 [Page 8]
Internet-Draft MPLS-TP OAM based on Y.1731 July 2010
In order to perform pro-active Connectivity Verification, the CCM
packet contains a globally unique identifier of the source MEP, as
described in [4].
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
defined in this section.
The IP-based formats for MEG ID will be added in a future version of
the document.
4.2. OAM Loopback (LB)
The LBM/LBR PDUs, defined in Y.1731 [2] and encapsulated within MPLS-
TP as described in section 3, and can be used to support the
following MPLS-TP OAM functional requirements:
o On-demand bidirectional connectivity verification (section 2.2.3
of [6]);
o Bidirectional in-service or out-of-service diagnostic test
(section 2.2.5 of [6]).
Procedures for generating and processing LBM/LBR PDUs are defined in
Y.1731 [2].
It is worth noticing that these OAM PDUs cover different functions
than those defined in [8].
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 January 12, 2011 [Page 9]
Internet-Draft MPLS-TP OAM based on Y.1731 July 2010
path is locked on both sides by network management operations.
However, single-ended procedures as defined in [8] MAY be used.
LBM/LBR OAM requires Target MEP/MIP ID and Originator MEP ID to be
carried. Current Y.1731 Recommendation [2] assumes that those IDs are
carried in the DA and SA fields of the encapsulating Ethernet frames.
In MPLS-TP OAM those IDs can be carried in additional TLV within the
LBM/LBR PDU shown in Figure 2.
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.
When a MEP receives an LBR packet with the Originator MEP ID equal to
its ID, with an expected Transaction ID and within 5 seconds after
transmitting the LBM packet, the LBR packet is valid. Otherwise the
LBR packet addressed to it is invalid and is discarded.
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 (0xXX) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MEL | Version | OpCode | Flags | TLV Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID/Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target MEP/MIP ID TLV |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator MEP ID TLV |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [optional TLV starts here] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End TLV |
+-+-+-+-+-+-+-+-+-+
Figure 2 LB Packet Format
The OpCode set to 0x03 (LBM) or 0x02 (LBR). The TLV Offset set to
0x04. The formats of the Target MEP/MIP ID TLV and of the Originator
MEP ID TLV are defined in 4.2.1.
Busi and al. Expires January 12, 2011 [Page 10]
Internet-Draft MPLS-TP OAM based on Y.1731 July 2010
The Target MEP/MIP ID, if present, MUST be the first TLV within the
OAM PDU. The Originator MEP ID TLV, if present, 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.
4.2.1. Format of MEP and MIP ID TLV
To be added in a future version of the document.
4.3. Alarm Indication Signal (AIS)
The AIS PDU, defined in Y.1731 [2] and encapsulated within MPLS-TP as
described in section 3, can be used to support the alarm reporting
MPLS-TP OAM functional requirement (section 2.2.8 of [6]).
Procedures for generating and processing AIS PDUs are defined in
Y.1731 [2].
4.4. Lock Reporting (LCK)
The LCK PDU, defined in Y.1731 [2] and encapsulated within MPLS-TP as
described in section 3, can be used to support the lock reporting
MPLS-TP OAM functional requirement (section 2.2.7 of [6]).
Procedures for generating and processing LCK PDUs are defined in
Y.1731 [2].
4.5. Test (TST)
The TST PDU, defined in Y.1731 [2] and encapsulated within MPLS-TP as
described in section 3, 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 [6]).
Procedures for generating and processing TST PDUs are defined in
Y.1731 [2].
4.6. Automatic Protection Switching (APS)
The APS PDU supports the requirements for MPLS-TP protection
switching coordination.
Busi and al. Expires January 12, 2011 [Page 11]
Internet-Draft MPLS-TP OAM based on Y.1731 July 2010
The complete format of the APS PDUs and the associated procedures are
outside the scope of [2]. They will be added in future version of
this document.
4.7. Loss Measurement (LM)
The LMM/LMR PDUs, defined in Y.1731 [2] and encapsulated within MPLS-
TP as described in section 3, can be used to support on-demand and
proactive packet loss measurement MPLS-TP OAM functional requirement
(section 2.2.11 of [6]).
Procedures for generating and processing LMM/LMR PDUs are defined in
Y.1731 [2].
4.8. One-way delay measurement (1DM)
The 1DM PDU, defined in Y.1731 [2] and encapsulated within MPLS-TP as
described in section 3, can be used to support the on-demand one-way
packet delay measurement MPLS-TP OAM functional requirement (section
2.2.12 of [6]).
It can also be used to support proactive one-way delay measurement
MPLS-TP OAM functional requirement (section 2.2.12 of [6]).
Procedures for generating and processing 1DM PDUs are defined in
Y.1731 [2].
4.9. Two-way delay Measurement Message/Reply (DM)
The DMM/DMR PDUs, defined in Y.1731 [2] and encapsulated within MPLS-
TP as described in section 3, can be used to support on-demand two-
ways packet delay measurement MPLS-TP OAM functional requirement
(section 2.2.12 of [6]).
It can also be used to support proactive two-ways packet delay
measurement MPLS-TP OAM functional requirement (section 2.2.12 of
[6]).
Procedures for generating and processing DMM/DMR PDUs are defined in
Y.1731 [2].
5. Security Considerations
To be added in a future version of the document
Busi and al. Expires January 12, 2011 [Page 12]
Internet-Draft MPLS-TP OAM based on Y.1731 July 2010
6. IANA Considerations
IANA is requested to allocate a Channel Type value 0xXX 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]
7. Acknowledgments
To be added in a future version of the document
This document was prepared using 2-Word-v2.0.template.dot.
Busi and al. Expires January 12, 2011 [Page 13]
Internet-Draft MPLS-TP OAM based on Y.1731 July 2010
8. References
8.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] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R.,
"MPLS Generic Associated Channel", RFC 5586, June 2009
[4] Busi,I., Niven-Jenkins, B., "MPLS-TP OAM Framework and
Overview", draft-ietf-mpls-tp-oam-framework-05 (work in
progress), March 2010
[5] Beller, D., Farrel, A., "An Inband Data Communication Network
For the MPLS Transport Profile", RFC 5718, January 2010
8.2. Informative References
[6] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements-
06 (work in progress), March 2010
[7] Nadeau, T., et al., "Pseudo Wire (PW) OAM Message Mapping",
draft-ietf-pwe3-oam-msg-map-11 (work in progress), June 2009
[8] Boutros, S., et al., "Operating MPLS Transport Profile LSP in
Loopback Mode", draft-boutros-mpls-tp-loopback-03 (work in
progress), March 2010
[9] Swallow, G., Bocci, M., " MPLS-TP Identifiers", draft-ietf-
mpls-tp-identifiers-00 (work in progress), November 2010
[10] ITU-T Recommendation M.1400 (07/06), " Designations for
interconnections among operators' networks", July 2006
[11] IEEE Standard 802.1ag-2007, "IEEE Standard for Local and
Metropolitan Area Networks: Connectivity Fault Management",
September 2007
Busi and al. Expires January 12, 2011 [Page 14]
Internet-Draft MPLS-TP OAM based on Y.1731 July 2010
Author's Addresses
Italo Busi (Editor)
Alcatel-Lucent
Email: Italo.Busi@alcatel-lucent.it
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.it
Alessandro D'Alessandro
Telecom Italia
Email: alessandro.dalessandro@telecomitalia.it
Simon Delord
Telstra
Email: simon.a.delord@team.telstra.com
Busi and al. Expires January 12, 2011 [Page 15]
Internet-Draft MPLS-TP OAM based on Y.1731 July 2010
John Hoffmans
KPN
Email: john.hoffmans@kpn.com
Ruiquan Jing
China Telecom
Email: jingrq@ctbri.com.cn
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
Julien Meuric
France Telecom
Email: julien.meuric@orange-ftgroup.com
Masahiko Mizutani
Hitachi, Ltd.
Email: masahiko.mizutani.ew@hitachi.com
Busi and al. Expires January 12, 2011 [Page 16]
Internet-Draft MPLS-TP OAM based on Y.1731 July 2010
Philippe Niger
France Telecom
Email: philippe.niger@orange-ftgroup.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.it
Yaakov (Jonathan) Stein
RAD Data Communications
Email: yaakov_s@rad.com
Yuji Tochio
Fujitsu
Email: tochio@jp.fujitsu.com
Munefumi Tsurusawa
KDDI R&D Labs
Email: tsuru@kddilabs.jp
Busi and al. Expires January 12, 2011 [Page 17]
Internet-Draft MPLS-TP OAM based on Y.1731 July 2010
Maarten Vissers
Huawei Technologies
Email: maarten.vissers@huawei.com
Rolf Winter
NEC
Email: Rolf.Winter@nw.neclab.eu
Busi and al. Expires January 12, 2011 [Page 18]