MPLS Working Group I. Busi (Ed)
Internet Draft Alcatel-Lucent
Intended status: Standard Track H. van Helvoort (Ed)
J. He (Ed)
Huawei
Christian Addeo Manuel Paul
Vincenzo Sestito Josef Roese
Alcatel-Lucent Deutsche Telekom
Simon Delord Nurit Sprecher
Uecomm Yaacov Weingarten
John Hoffmans Nokia Siemens Networks
KPN Yaakov Stein
Ruiquan Jing RAD
China Telecom Yuji Tochio
Julien Meuric Fujitsu
Philippe Niger Munefumi Tsurusawa
France Telecom KDDI R&D Labs
Maarten Vissers
Huawei
Expires: September 2009 March 24, 2009
MPLS-TP OAM based on Y.1731
draft-bhh-mpls-tp-oam-y1731-02.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
Busi and al. Expires September 24, 2009 [Page 1]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Abstract
This document specifies how 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 specifies 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.
Table of Contents
1. Introduction.................................................3
1.1. Contributing Authors....................................4
2. Conventions used in this document............................5
2.1. Terminology.............................................5
3. Encapsulation of OAM PDU in MPLS-TP..........................5
3.1. Encapsulation of different OAM PDUs within a single ACH
Channel Type.................................................6
3.2. Encapsulation of different OAM PDUs within different ACH
Channel Types................................................7
4. MPLS-TP OAM Functions........................................9
4.1. Continuity check message (CCM) PDU......................9
4.2. Loopback Message/Reply (LBM/LBR) PDU...................11
4.3. Alarm Indication Signal (AIS) PDU......................12
4.4. Locked (LCK) PDU.......................................12
4.5. Test (TST) PDU.........................................13
4.6. Automatic Protection Switching (APS) PDU...............13
4.7. Loss Measurement Message/Reply (LMM/LMR) PDU...........13
Busi and al. Expires September 24, 2009 [Page 2]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
4.8. One-way delay measurement (1DM) PDU....................14
4.9. Delay Measurement Message/Reply (DMM/DMR) PDU..........14
5. MPLS-TP and Ethernet OAM Interworking.......................14
6. Security Considerations.....................................14
7. IANA Considerations.........................................14
8. Acknowledgments.............................................15
9. References..................................................16
9.1. Normative References...................................16
9.2. Informative References.................................16
1. Introduction
This document specifies how to leverage Y.1731 [2] Protocol Data
Units (PDU) 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].
ITU-T Recommendation Y.1731 [2] specifies:
o OAM PDUs and procedures (state machines) 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 be used also
in other packet technologies (e.g. MPLS-TP) provided that the
technology specific encapsulation is defined.
This document proposes that MPLS-TP OAM reuses the same OAM PDUs and
procedures (state machines) defined in Y.1731 [2], specifying the
necessary MPLS-TP technology specific encapsulation mechanisms for
supporting MPLS-TP OAM capabilities.
Following are the advantages of using this approach:
o Availability of MPLS-TP OAM functions in the near terms, since
Ethernet OAM functions are already supported and deployed
o Simplify the interworking between a p2p Ethernet Service VLAN and a
p2p MS-PW. Further details regarding this interworking will be
provided in section 5.
Busi and al. Expires September 24, 2009 [Page 3]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
o Reduce the complexity and increase the reuse of code for
implementation in packet transport devices that may support both
Ethernet (e.g. VPLS and H-VPLS) and MPLS-TP capabilities.
[Editor's note - Add also the description of operational benefit of
reusing the same OAM protocols in LSP, PW and VPLS (i.e. the operator
has to test and maintain a single protocol set rather than two).]
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 advantages 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
or preclude definition of other MPLS-TP OAM tools.
Precedence rules are for further study.
The mechanisms proposed 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, Julien Meuric, Philippe Niger, Manuel
Paul, Josef Roese, Vincenzo Sestito, Nurit Sprecher, Yaakov Stein,
Yuji Tochio, Munefumi Tsurusawa, Maarten Vissers, Yaacov Weingarten
Busi and al. Expires September 24, 2009 [Page 4]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
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
LME LSP Maintenance Entity
ME Maintenance Entity
MEP Maintenance End Point
MIP Maintenance Intermediate Point
PME PW Maintenance Entity
SME Section Maintenance Entity
TCME Tandem Connection Maintenance Entity
TPME Tandem PW Maintenance Entity
TLV Type Length Value
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 ACH [3] construct and they are addressed
to MEPs and MIPs by using label stacking and TTL expiration.
Busi and al. Expires September 24, 2009 [Page 5]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
It is therefore possible to encapsulate OAM PDUs within MPLS-TP using
the [3] to distinguish OAM packets from user data packets. The label
stack entries on top of the ACH and the TTL field are used as defined
in [4] to address these packets to the correct MEPs and MIPs.
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 about the usage of the ACH
TLV will be added in the future version of this draft]
This version of the document describes two possible options to
encapsulate OAM PDUs within ACH:
1. Use a single ACH Channel Type (0xXX) identifying the whole Y.1731
toolset and rely upon the OpCode field in Y.1731 to identify the
specific OAM PDU
2. Use of multiple ACH Channel Type values, one for each OAM PDU thus
making the usage of the OpCode field within the OAM PDU not
required when used in MPLS-TP
Future versions of the document will describe the proposed option to
be standardized for encapsulating OAM PDUs within ACH.
Moreover, MPLS-TP relies upon a different mechanism for supporting
tandem connection monitoring (i.e. label stacking) than that 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.
3.1. Encapsulation of different OAM PDUs within a single ACH Channel
Type
When the first option is used, OAM PDUs are encapsulated using the
ACH, according to [3], as described in Figure 1 below.
Busi and al. Expires September 24, 2009 [Page 6]
Internet-Draft MPLS-TP OAM based on Y.1731 March 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| Y.1731 Channel Type (0xXX) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MEL | Version | OpCode | Flags | TLV Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| OAM function specific fields |
| (Y.1731 based) |
+ +
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 Y.1731 PDU within a single ACH Channel Type
The Channel Type value 0xXX identifies the payload as a Y.1731 PDU.
[Editor's note - The value 0x8902 has been proposed to keep the
channel type identical to the EtherType value used in Ethernet OAM]
It is worth noticing that this document proposes that MPLS-TP OAM
supports the OAM PDUs and procedures that are defined in [2], as
approved in February 2008, and that are explicitly listed in section
4.
If in the future, additional OAM PDUs, or update versions of existing
OAM PDUs and procedures, need to be supported for MPLS-TP OAM, a new
document that explicitly proposes their support will be developed
according to the IETF Standard Process.
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] and reproduced in 4. .
3.2. Encapsulation of different OAM PDUs within different ACH Channel
Types
When the second option is used, OAM PDUs are encapsulated using the
ACH, according to [3], as described in Figure 2 below.
Busi and al. Expires September 24, 2009 [Page 7]
Internet-Draft MPLS-TP OAM based on Y.1731 March 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| Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MEL | Version | OpCode | Flags | TLV Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| OAM function specific fields |
| (Y.1731 based) |
+ +
: ... :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Y.1731 PDU within multiple ACH Channel Types
The Channel Type MUST be set to a value that is obtained by adding
the OpCode value defined in Y.1731 to an offset 0xYY (to be defined).
[Editor's note - The value 0x0200 has been proposed as the offset for
channel type]
This approach requires that IANA reserves 256 channel type codepoints
to identify Y.1731 PDUs to allow a simple mapping of the Y.1731
OpCode and ACH Channel Type field.
It is worth noticing that these 256 codepoints need just to be
reserved and not to be allocated. Only the codepoints associated with
the Y.1731 PDUs and procedures that are defined in [2], as approved
in February 2008, and that are explicitly listed in section 4. need
to be allocated.
If in the future, additional OAM PDUs, or updated versions of
existing OAM PDUs and procedures, need to be supported for MPLS-TP
OAM, a new document that explicitly proposes their support will be
developed according to the IETF Standard Process. That document MUST
allocate the required Channel Type codepoint(s) within this reserved
range according to the rule described in this document.
The OpCode field MUST NOT be used.
The setting of the Version, Flags and TLV Offset is OpCode specific
and described in Y.1731 [2] and reproduced in 4. .
Busi and al. Expires September 24, 2009 [Page 8]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
4. MPLS-TP OAM Functions
This section describes the OAM PDUs and procedures, as defined in
Y.1731 [2], that are proposed by this document to be used in MPLS-TP
environment as well as the functions supported by each OAM PDU to
meet MPLS-TP OAM Requirements, as defined in [6].
This document is proposing not to use the VSM/VSR and EXM/EXR OAM
PDUs in MPLS-TP. The experimental ACH Channel Type code-points that
are allocated in [3] should be used instead.
This document is proposing not to use the MCC OAM PDU in MPLS-TP. The
solution proposed in [5] should be used instead.
[Editor's note - Clarify that LTM/LTR, as currently defined in
Y.1731, are not applicable to MPLS-TP]
[Editor's note - There is a need to ensure the full alignment between
the technology-independent OAM PDUs and procedures defined in Y.1731
and in this document]
[Editor's Note - This section will be completed in the next version
of the document, for example other PDUs can be added on the basis of
IETF consensus]
4.1. Continuity check message (CCM) PDU
The format of the CCM PDU and the associated procedures are defined
in Y.1731 [2] and reproduced in this section.
These PDUs are encapsulated within MPLS-TP as described in section 3.
and can be used to support the following MPLS-TP OAM functions
required in [6]:
o Pro-active continuity and connectivity verification
o Pro-active remote defect indication
o Pro-active loss measurement
The format of the CCM PDU within the ACH is described in Figure 3.
Busi and al. Expires September 24, 2009 [Page 9]
Internet-Draft MPLS-TP OAM based on Y.1731 March 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| Y.1731 Channel Type (0xXX) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MEL | Version | OpCode |R| Res. | Per | TLV Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MEP ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
: MEG ID (48 bytes) :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | TxFCf |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TxFCf | RxFCb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RxFCb | TxFCb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TxFCb | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | End TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 CCM PDU within a single ACH Channel Type
The fields of the CCM PDU format are as follows:
o The MEL field MUST be set to a configurable value (Default value is
"111")
o The Version field MUST be set to "00000"
o The OpCode field MUST be set to 0x01 (indicating a CCM PDU)
o The R (RDI) bit MUST be set to 1 to indicate RDI. Otherwise is MUST
be set to 0
o The Res. Bits are reserved and MUST be set to "0000" in
transmission and ignored in reception
o The Period field MUST indicate the transmission and reception
period of CCM packets according to the following table:
Busi and al. Expires September 24, 2009 [Page 10]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0| Invalid value | Invalid value for CCM PDU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1| 3.33 ms | 300 packets per second |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0| 10 ms | 100 packets per second |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1| 100 ms | 10 packets per second |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0| 1 s | 1 packet per second |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 1| 10 s | 6 packets per minute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0| 1 min | 1 packet per minute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1| 10 min | 6 packets per hour |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o The TLV OffSet field MUST be set to 0d70
o The MEP ID field MUST be set to a configurable 13-bit integer value
identifying the transmitting MEP within the MEG. The three MSBs of
the first octet are not used and MUST be set to ZERO.
o The MEG ID field MUST be set to a configurable 48-octet value.
Refer to Annex A of ITU-T Recommendation Y.1731 for the format used
for the MEG ID field with ICC-based format
o TxFCf, TxFCb, RxFCb: 4-octet integer values with samples of the
wrap-around packet counters. These fields are set to all-ZEROes
when not used.
o Reserved fields MUST be set to all ZEROes
o The End TLV is an all ZEROes octet representing that there are no
TLVs within the CCM PDU.
[Editor's note - Further details will be provided in the next version
of the draft]
4.2. Loopback Message/Reply (LBM/LBR) PDU
The format of the LBM/LBR PDUs and the associated procedures are
defined in Y.1731 [2].
Busi and al. Expires September 24, 2009 [Page 11]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
These PDUs are encapsulated within MPLS-TP as described in section 3.
and can be used to support the following MPLS-TP OAM functions
required in [6]:
o On-demand bidirectional continuity and connectivity verification
o Bidirectional in-service or out-of-service diagnostic test
Note - It is worth noticing that these OAM PDUs cover different
functions that those defined in [8]
NOTE: LBM/LBR OAM requires TargetMEP/MIP ID and OriginatorMEP 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 adopting the
proposal of reusing Y.1731 OAM PDU and procedures in MPLS-TP.]
[Editor's note - The format of these PDUs and the procedures will be
illustrated in a future version of this document]
4.3. Alarm Indication Signal (AIS) PDU
This format of the AIS PDU and the associated procedures are defined
in Y.1731 [2].
These PDUs are encapsulated within MPLS-TP as described in section 3.
and can be used to support the MPLS-TP OAM alarm suppression
function, in case of a failure condition of the MPLS-TP server
(sub-)layer, as required in [6].
[Editor's note - The format of these PDUs and the procedures will be
illustrated in a future version of this document]
4.4. Locked (LCK) PDU
This format of the LCK PDU and the associated procedures are defined
in Y.1731 [2].
These PDUs are encapsulated within MPLS-TP as described in section 3.
and can be used to support the MPLS-TP OAM alarm suppression
Busi and al. Expires September 24, 2009 [Page 12]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
function, in case of an administrative locking of the MPLS-TP server
(sub-)layer, as required in [6].
[Editor's note - The format of these PDUs and the procedures will be
illustrated in a future version of this document]
4.5. Test (TST) PDU
This format of the TST PDU and the associated procedures are defined
in Y.1731 [2].
These PDUs are encapsulated within MPLS-TP as described in section 3.
and can be used to support the MPLS-TP OAM alarm suppression
function, in case of an administrative locking of the MPLS-TP server
(sub-)layer, as required in [6].
[Editor's note - The format of these PDUs and the procedures will be
illustrated in a future version of this document]
4.6. Automatic Protection Switching (APS) PDU
This 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 - The format of these PDUs and the procedures will be
illustrated in a future version of this document]
4.7. Loss Measurement Message/Reply (LMM/LMR) PDU
The format of the LMM/LMR PDUs and the associated procedures are
defined in Y.1731 [2].
These PDUs are encapsulated within MPLS-TP as described in section 3.
and can be used to support the MPLS-TP OAM on-demand and proactive
bidirectional packet loss measurement functions as required in [6].
[Editor's note - The format of these PDUs and the procedures will be
illustrated in a future version of this document]
Busi and al. Expires September 24, 2009 [Page 13]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
4.8. One-way delay measurement (1DM) PDU
This format of the 1DM PDU and the associated procedures are defined
in Y.1731 [2].
These PDUs are encapsulated within MPLS-TP as described in section 3.
and can be used to support the MPLS-TP OAM on-demand one-way delay
measurement as required in [6].
These PDUs can also be used to support MPLS-TP OAM proactive one-way
delay measurement.
[Editor's note - The format of these PDUs and the procedures will be
illustrated in a future version of this document]
4.9. Delay Measurement Message/Reply (DMM/DMR) PDU
The format of the DMM/DMR PDUs and the associated procedures are
defined in Y.1731 [2].
These PDUs are encapsulated within MPLS-TP as described in section 3.
and can be used to support the MPLS-TP OAM on-demand two-ways delay
measurement function as required in [6].
These PDUs can also be used to support MPLS-TP OAM proactive two-ways
delay measurement.
[Editor's note - The format of these PDUs and the procedures will be
illustrated in a future version of this document]
5. MPLS-TP and Ethernet OAM Interworking
To be added in a future version of the document
6. Security Considerations
To be added in a future version of the document
7. IANA Considerations
The IANA considerations of this draft depend on the mechanism that
will be specified for the encapsulation of Y.1731 derived OAM PDUs
within MPLS-TP.
Busi and al. Expires September 24, 2009 [Page 14]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
If the first option is selected (i.e. one codepoint for all of these
OAM PDUs) IANA is requested to allocate a Channel Type value 0xXX to
identify an associated channel carrying all such OAM PDUs and
procedures 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]
If in the future, additional Y.1731 OAM PDUs, or update versions of
existing OAM PDUs and procedures, MAY need to be supported for MPLS-
TP OAM, and a new document that explicitly proposes their support
MUST be developed according to the IETF Standards Process. That
document MUST request IANA to update the reference to this Channel
Type allocation.
If the second option is selected (i.e. one codepoint for each OAM
PDU), IANA is requested to reserve (but not to allocate) 256
consecutive channel type codepoints as described in section 3.2.
IANA is also requested to allocate the codepoints associated with the
OAM PDUs and procedures that are explicitly listed in section 4.
If in the future, additional such OAM PDUs, or updated versions of
existing OAM PDUs and procedures, need to be supported for MPLS-TP
OAM, a new document that explicitly proposes their support MUST be
developed according to the IETF Standards Process. That document MUST
request IANA to allocate the required Channel Type codepoint(s),
within this reserved range according to the rule described in this
document, for the new proposed OAM PDUs, if any, and/or to update the
reference to existing Channel Type allocations for the proposed
updated OAM PDUs and procedures.
[Editor's note - The IANA considerations will be completed in a
future version of the document where the encapsulation mechanism will
be defined]
8. 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 24, 2009 [Page 15]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
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] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R.,
"MPLS Generic Associated Channel", draft-ietf-mpls-tp-gach-gal-
02 (work in progress), February 2009
[4] Busi,I., Niven-Jenkins, B., "MPLS-TP OAM Framework and
Overview", draft-busi-mpls-tp-oam-framework-00(work in
progress), October 2008
[5] Beller, D., Farrel, A., "An Inband Data Communication Network
For the MPLS Transport Profile", draft-beller-mpls-tp-gach-dcn-
00 (work in progress), January 2009
9.2. Informative References
[6] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
MPLS Transport Networks", draft-ietf-mpls-tp-oam-requirements-
00 (work in progress), December 2008
[7] Nadeau, T., et al., "Pseudo Wire (PW) OAM Message Mapping",
draft-ietf-pwe3-oam-msg-map-08 (work in progress), November
2008
[8] Boutros, S., et al., "Operating MPLS Transport Profile LSP in
Loopback Mode", draft-boutros-mpls-tp-loopback-01 (work in
progress), December 2008
[9] IEEE Standard 802.1ag-2007, "IEEE Standard for Local and
Metropolitan Area Networks: Connectivity Fault Management",
September 2007
Busi and al. Expires September 24, 2009 [Page 16]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
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
Huawei Technologies
Email: hejia@huawei.com
Contributing Authors' Addresses
Christian Addeo
Alcatel-Lucent
Email: Christian.Addeo@alcatel-lucent.it
Simon Delord
Uecomm
Email: sdelord@uecomm.com.au
John Hoffmans
KPN
Email: john.hoffmans@kpn.com
Ruiquan Jing
China Telecom
Email: jingrq@ctbri.com.cn
Busi and al. Expires September 24, 2009 [Page 17]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
Julien Meuric
France Telecom
Email: julien.meuric@orange-ftgroup.com
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
Nurit Sprecher
Nokia Siemens Networks
Email: nurit.sprecher@nsn.com
Yaakov (Jonathan) Stein
RAD Data Communications
Email: yaakov_s@rad.com
Busi and al. Expires September 24, 2009 [Page 18]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
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
Yaacov Weingarten
Nokia Siemens Networks
Email: yaacov.weingarten@nsn.com
Busi and al. Expires September 24, 2009 [Page 19]