MPLS Working Group I. Busi (Ed)
Internet Draft Alcatel-Lucent
H. van Helvoort (Ed)
J. He (Ed)
Huawei
Expires: September 2010 March 8, 2010
MPLS-TP OAM based on Y.1731
draft-bhh-mpls-tp-oam-y1731-04.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 September 8, 2010 [Page 1]
Internet-Draft MPLS-TP OAM based on Y.1731 March 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 September 8, 2010 [Page 2]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2010
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 Functions........................................8
4.1. Pro-active CC-V and RDI (CCM)...........................8
4.2. OAM Loopback (LB).......................................9
4.3. Alarm Indication Signal (AIS)..........................10
4.4. Lock Reporting (LCK)...................................10
4.5. Test (TST).............................................10
4.6. Automatic Protection Switching (APS)...................11
4.7. Loss Measurement (LM)..................................11
4.8. One-way delay measurement (1DM)........................11
4.9. Two-way delay Measurement Message/Reply (DM)...........11
5. Security Considerations.....................................12
6. IANA Considerations.........................................12
7. Acknowledgments.............................................12
8. References..................................................13
8.1. Normative References...................................13
8.2. Informative References.................................13
Busi and al. Expires September 8, 2010 [Page 3]
Internet-Draft MPLS-TP OAM based on Y.1731 March 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.
[Editor's note - Place information on the fact that existing
implementations of this solution already exist]
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 Availability of MPLS-TP OAM functions in the near terms, since
Ethernet OAM functions are already 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 September 8, 2010 [Page 4]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2010
Ethernet and MPLS-TP capabilities, e.g. VPLS and H-VPLS
applications.
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, 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
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 September 8, 2010 [Page 5]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2010
2.1. Terminology
ACH Associated Channel Header
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 MAC DA, MAC SA and
EtherType are 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.
[Editor's note - The value 0x8902 has been proposed to keep the
channel type identical to the EtherType value used in Ethernet OAM]
OAM PDUs are encapsulated using the ACH, according to [3], as
described in Figure 1 below.
Busi and al. Expires September 8, 2010 [Page 6]
Internet-Draft MPLS-TP OAM based on Y.1731 March 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
The usage of the ACH TLV object, as defined in [3], provides enough
flexibility to support IP-based addressing schemes to allow the usage
of these OAM tools also within an IP/MPLS environment.
[Editor's note - Further considerations (e.g., usage of the ACH
Authentication TLV as defined in draft-manral-mpls-tp-oam-auth-tlv-
00) about the usage of the ACH TLV will be added in the future
version of this draft]
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].
Busi and al. Expires September 8, 2010 [Page 7]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2010
[Editor's note - This option allows packing multiple PDUs together.
The mechanisms and the advantages of packing multiple OAM PDUs in the
same packets require further study.]
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].
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).
[Editor's note - Check draft-he-mpls-tp-csf as well as the status of
CSF definition within ITU-T and, if needed, add the CSF PDU to a
future version of this draft]
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]);
Busi and al. Expires September 8, 2010 [Page 8]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2010
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.
In order to perform pro-active Connectivity Verification, the CCM
packet contains a globally unique identifier of the source MEP, as
described in [4]. In transport networks, the source MEP for LSPs, PWs
and Sections is identified by combining a globally unique MEG ID,
which uses the ICC-based format as defined in Annex A of Y.1731 [2],
with a MEP ID that is unique within the scope of the Maintenance
Entity Group.
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 September 8, 2010 [Page 9]
Internet-Draft MPLS-TP OAM based on Y.1731 March 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 or within the ACH TLV.
[Editor's note - This issue will be further investigated in the next
version of the draft but it is not a showstopper for reusing Y.1731
OAM PDU and procedures in MPLS-TP.]
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.
[Editor's note - Clarify that this solution supports both per-node
and per-interface MIP architectures]
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]).
Busi and al. Expires September 8, 2010 [Page 10]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2010
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.
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.
[Editor's note - Further details will be provided in the next version
of the draft]
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]).
Busi and al. Expires September 8, 2010 [Page 11]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2010
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
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 September 8, 2010 [Page 12]
Internet-Draft MPLS-TP OAM based on Y.1731 March 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 September 8, 2010 [Page 13]
Internet-Draft MPLS-TP OAM based on Y.1731 March 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
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
Busi and al. Expires September 8, 2010 [Page 14]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2010
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
Philippe Niger
France Telecom
Email: philippe.niger@orange-ftgroup.com
Manuel Paul
Deutsche Telekom
Email: Manuel.Paul@telekom.de
Busi and al. Expires September 8, 2010 [Page 15]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2010
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
Maarten Vissers
Huawei Technologies
Email: maarten.vissers@huawei.com
Busi and al. Expires September 8, 2010 [Page 16]