MPLS Working Group Italo Busi (Ed)
Internet Draft Alcatel-Lucent
Intended status: Standard Track H. van Helvoort (Ed)
J. He (Ed)
Huawei
Christian Addeo John Hoffmans
Vincenzo Sestito KPN
Alcatel-Lucent
Ruiquan Jing Josef Roese
China Telecom Deutsche Telekom
Yaakov Stein Yuji Tochio
RAD Fujitsu
Munefumi Tsurusawa Maarten Vissers
KDDI R&D Labs Huawei
Expires: September 2009 March 9, 2009
MPLS-TP OAM based on Y.1731
draft-bhh-mpls-tp-oam-y1731-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Busi and al. Expires September 9, 2009 [Page 1]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
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............................4
2.1. Terminology.............................................4
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........................................8
4.1. Continuity check message (CCM) PDU......................8
4.2. Loopback Message/Reply (LBM/LBR) PDU...................11
4.3. Alarm Indication Signal (AIS) PDU......................11
4.4. Locked (LCK) PDU.......................................11
4.5. Test (TST) PDU.........................................12
4.6. Automatic Protection Switching (APS) PDU...............12
4.7. Loss Measurement Message/Reply (LMM/LMR) PDU...........12
4.8. One-way delay measurement (1DM) PDU....................13
4.9. Delay Measurement Message/Reply (DMM/DMR) PDU..........13
5. MPLS-TP and Ethernet OAM Interworking.......................13
6. Security Considerations.....................................13
7. IANA Considerations.........................................13
8. Acknowledgments.............................................14
9. References..................................................15
Busi and al. Expires September 9, 2009 [Page 2]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
9.1. Normative References...................................15
9.2. Informative References.................................15
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.
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.
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.
Busi and al. Expires September 9, 2009 [Page 3]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
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, John
Hoffmans, Ruiquan Jing, Josef Roese, Yaakov Stein, Yuji Tochio,
Munefumi Tsurusawa, Vincenzo Sestito, 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].
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
Busi and al. Expires September 9, 2009 [Page 4]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
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.
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.
Busi and al. Expires September 9, 2009 [Page 5]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
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.
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.
Busi and al. Expires September 9, 2009 [Page 6]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
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.
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
Busi and al. Expires September 9, 2009 [Page 7]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
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. .
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 - 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
Busi and al. Expires September 9, 2009 [Page 8]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
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.
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
Busi and al. Expires September 9, 2009 [Page 9]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
o The Period field MUST indicate the transmission and reception
period of CCM packets according to the following table:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0| Invalid value | Invalid value for CCM PDU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1| 3.33 ms | 300 frames per second |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 0| 10 ms | 100 frames per second |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1| 100 ms | 10 frames per second |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 0| 1 s | 1 frame per second |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 0 1| 10 s | 6 frames per minute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0| 1 min | 1 frame per minute |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1| 10 min | 6 frame 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 frame 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]
Busi and al. Expires September 9, 2009 [Page 10]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
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].
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].
Busi and al. Expires September 9, 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 MPLS-TP OAM unidirectional in-service
or out-of-service diagnostic test function 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 9, 2009 [Page 12]
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.
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
Busi and al. Expires September 9, 2009 [Page 13]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
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 9, 2009 [Page 14]
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", 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
Author's Addresses
Italo Busi (Editor)
Alcatel-Lucent
Email: Italo.Busi@alcatel-lucent.it
Busi and al. Expires September 9, 2009 [Page 15]
Internet-Draft MPLS-TP OAM based on Y.1731 March 2009
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
John Hoffmans
KPN
Email: john.hoffmans@kpn.com
Ruiquan Jing
China Telecom
Email: jingrq@ctbri.com.cn
Josef Roese
Deutsche Telekom
Email: Josef.Roese@t-systems.com
Yaakov (Jonathan) Stein
RAD Data Communications
Email: yaakov_s@rad.com
Busi and al. Expires September 9, 2009 [Page 16]
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
Vincenzo Sestito
Alcatel-Lucent
Email: vincenzo.sestito@alcatel-lucent.it
Maarten Vissers
Huawei Technologies
Email: maarten.vissers@huawei.com
Busi and al. Expires September 9, 2009 [Page 17]