MPLS Working Group Fang Li (Ed)
Internet Draft CATR,China
Intended status: Informational Han Li (Ed)
China Mobile
Alessando D'Alessandro(Ed)
Telecom Italia
Ruiquan Jing (Ed)
China Telecom
Guangquan Wang(Ed)
China Unicom
Juan Pedro Fernandez-Palacios Gi(Ed)
Telefonica I+D
Expires: January 2012 July 11, 2011
Operator Considerations on MPLS-TP OAM Mechanisms
draft-fang-mpls-tp-oam-considerations-02
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) 2011 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Fang et al. Expires January 11, 2012 [Page 1]
Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July
2011
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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 Simplified BSD License.
Abstract
Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) is
based on a profile of the MPLS and pseudo wire (PW) procedures as
specified in the MPLS Traffic Engineering (MPLS-TE), pseudo wire (PW)
and multi-segment PW (MS-PW) architectures complemented with
additional Operations, Administration and Maintenance (OAM)
procedures for fault, performance and protection-switching management
for packet transport applications that do not rely on the presence of
a control plane.
This document is intended to explain the criticality of progressing
the essential suite of MPLS-TP OAM solution elements in order to meet
the urgent and increasing requirements for metro packet transport
networks. It describes examples of key packet transport network
applications for several operators, reviews associated MPLS-TP
service provider requirements, and analyzes MPLS-TP OAM solution
approaches that have been submitted to the IETF. Based upon this, it
is recommended that the solution elements described in draft-bhh-
mpls-tp-oam-y1731 [6] be included within the MPLS-TP toolkit for
supporting MPLS-TP OAM Functions, and that the draft be progressed as
a Standards Track RFC.
Table of Contents
1. Introduction.................................................3
1.1. Contributing Authors....................................4
2. Conventions used in this document............................4
2.1. Terminology.............................................4
3. PTN network Applications.....................................4
3.1. Summary of MPLS-TP based PTN Applications...............4
3.2. China Mobile............................................5
3.3. China Telecom...........................................6
3.4. China Unicom............................................6
3.5. Telecom Italia..........................................7
Fang et al. Expires January 11, 2012 [Page 2]
Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July
2011
3.6. Telefonica I+D..........................................7
4. Requirement of MPLS-TP OAM function toolset..................7
5. OAM solutions................................................8
5.1. draft-bhh solution approach.............................8
5.2. Extension of IP/MPLS OAM tools approach.................9
5.3. Development of new OAM tools approach..................10
6. Interoperability of draft-bhh implementations...............10
7. Considerations..............................................12
8. Proposal....................................................13
9. Security Considerations.....................................13
10. IANA Considerations........................................13
11. Acknowledgments............................................13
12. References.................................................14
12.1. Normative References..................................14
12.2. Informative References................................14
1. Introduction
This document is intended to explain the criticality of progressing
the essential suite of MPLS-TP OAM solution elements in order to meet
the urgent and increasing requirements for metro packet transport
networks (e.g. mobile backhauling). It describes examples of key
packet transport network applications for several operators, reviews
associated MPLS-TP network operators' requirements (which is defined
in RFC5654 [1]), and analyzes MPLS-TP OAM solution approaches that
have been submitted to the IETF. Based upon this, it is recommended
that the solution elements described in draft-bhh-mpls-tp-oam-y1731
[6] be included within the MPLS-TP toolkit for supporting MPLS-TP OAM
Functions, and that the draft be progressed as a Standards Track RFC.
This solution satisfies essential MPLS-TP OAM requirements as defined
in RFC5860 [3], and has been tested, validated and deployed by
several operators. While draft-bhh-mpls-tp-oam-y1731 [6] documents
these solution elements within a single document, the solution
approach allows operators to select the particular OAM functions they
wish to use. Thus, it can complement other solution elements, as it
does not deprecate existing MPLS and PW OAM mechanisms or preclude
definition/utilization of other MPLS-TP OAM tools.
The draft-bhh-mpls-tp-oam-y1731 [6] solution approach encapsulates
Y.1731 [4] OAM PDUs within MPLS-TP packets in compliance with RFC
5586 [2] and the draft-ietf-mpls-tp-oam-framework [5]. This approach
leverages ITU-T Y.1731 [4] PDUs and procedures (state machines) and
IETF RFC 5586 mechanisms to provide a set of MPLS-TP OAM mechanisms
that satisfy RFC5860 requirements and fit within the MPLS-TP OAM
framework as described in draft-ietf-mpls-tp-oam-framework [5]. This
offers an excellent example of what could be considered a cooperative
product of IETF and ITU-T, which builds upon the experience of both
Fang et al. Expires January 11, 2012 [Page 3]
Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July
2011
standards development organizations, to provide a robust and timely
solution.
1.1. Contributing Authors
Haiyi Zhang, Lei Wang, Yusen Yang, Pei Zhang, Andrea Di Giglio
2. Conventions used in this document
2.1. Terminology
AIS Alarm Indication Signal
CC Continuity Check
CFI Client Failure Indication
CV Connectivity Verification
DM Packet Delay Measurement
LB Loopback
LM Packet Loss Measurement
MPLS-TP MPLS Transport Profile
OAM Operation, Administration and Management
PTN Packet Transport Network
RDI Remote Defect Indication
TCM Tandem Connection Monitoring
3. PTN network Applications
3.1. Summary of MPLS-TP based PTN Applications
Current requirements of operators for supporting MPLS-TP based PTN
applications are mainly driven by mobile backhauling and L2 VPN
services for business customers.
In typical network deployments, IP-based and transport-based
environments are separated. IP backbone and metro core networks are
based on IP/MPLS routers, while metro aggregation and access networks
are based on PTN equipments. Of these, for several operators, the
Fang et al. Expires January 11, 2012 [Page 4]
Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July
2011
most urgent MPLS-TP application scenarios are for the PTN-based metro
networks, which are separated in the existing networks from the core
IP/MPLS networks. However, in the future, deployments of MPLS-TP
within backbone/core networks are not precluded.
The following section provides some examples of PTN applications in
many operators' metro networks, to illustrate the urgent market
requirement for MPLS-TP to be standardized in a reasonable way as
soon as possible.
Although the functionality of MPLS-TP OAM is more important than the
message format of OAM, when operators began to widely deploy MPLS-TP
technology, the network interworking between each vendor becomes a
key concern. Usually, there are at least two vendor's equipments in
one metro network. In order to provide end-to-end reliable services
(such as L2 VPN) supporting OAM and protection, the requirement for
standardized OAM PDU formats and procedures is urgent.
Hundreds of thousands of MPLS-TP based PTN boxes are being deployed
in countries such as Korea, China, Japan, India, Italy, etc. More and
more operators have started/are planning to test all the available
draft about MPLS-TP OAM to explore how far the proposed solutions
(from standard bodies and fora) and already available vendor
solutions can satisfy operators' requirements for superior protection,
fault and performance management in the MPLS-TP space. Many operators
are actively monitoring and contributing to the MPLS-TP
standardization process with the aim to get shortly a comprehensive
implementation of latest drafts as required from the market trend.
While it would be desirable to converge to a single solution in the
end, the viability of all protocol proposals on the table should be
explored at this point.
3.2. China Mobile
China Mobile had deployed 38315 PTN nodes in 138 metro networks in
2009 and has deployed more than 110,000 PTN nodes in 28 of 31
provinces's metro network till September 2010. And more than 130,000
PTN boxes will be deployed in 2011. PTN deployment speeds up in 2011
with the roll out of 3G base stations.
According to the PTN OAM specifications in CCSA PTN standards and
China Mobile PTN equipment requirements, the main PTN vendors have
already finished the new OAM software version development based on
draft-bhh-mpls-tp-oam-y1731 and passed the experimental upgrade test
from ITU-T G.8114 to draft-bhh-mpls-tp-oam-y1731 in lab from May to
July 2010.
Fang et al. Expires January 11, 2012 [Page 5]
Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July
2011
In Aug. 2010, China Mobile has successfully carried out a large scale
field trial whose objective was to upgrade the PTN OAM protocols
based on ITU-T G.8114 to draft-bhh-mpls-tp-oam-y1731 [6]. The main
PTN vendors have participated in this upgrading field trial. The
trial results show that PTN OAM smoothly upgrading from ITU-T G.8114
to draft-bhh-mpls-tp-oam-y1731 is already a mature approach. Such
field trial has involved 422 PTN nodes in 3 cities. Since then, such
network has been running with OAM functionalities based on draft-bhh-
mpls-tp-oam-y1731 without any problem.
In July 2011, CMCC has successfully migrated 10,000 nodes from G.8114
PTN OAM to draft-bhh-mpls-tp-oam-y1731 PTN OAM and has deployed
additional 160,000 new nodes running just draft-bhh-mpls-tp-oam-y1731
PTN OAM. PTN box deployed in 2011 will support draft-bhh only, by the
end of this year, all 330,000 PTN equipments in CMCC will run draft-
bhh only.
In a typical China Mobile metro network, there are several thousands
PTN nodes to provide wireless backhauling, broadband (PON-OLT)
backhauling, 10M/100M/GE private line services.
3.3. China Telecom
China Telecom has evaluated the application of PTN technologies for
more than two years and concluded that Mobile backhaul and Ethernet
Line service will be the main service drivers to deploy PTN. China
Telecom regarded PTN technology to be mainly based on MPLS-TP.
Further more it is necessary to build a PTN network that satisfies
the rapidly growing mobile service (currently growing on the order of
millions of customers per month) in wireless network.
China Telecom has selected PTN as one of the mobile backhaul
solutions for its CDMA 2000 EV-DO networks. For example, a PTN
network with 2200 nodes has been built in Chongqing, Sichuan. Two
commercial trial PTN networks have been built in Jiangsu and Hubei
province.
3.4. China Unicom
China Unicom regards PTN technology as key for multi-service
transport platforms. Currently, MSTP is still the preferred transport
technology for China Unicom. However, from the long-term point of
view, PTN technology will be important for transport platforms. So
since 2009, China Unicom has been organizing a large scale PTN
testing activities to evaluate the maturity and feasibility of PTN
networks.
Fang et al. Expires January 11, 2012 [Page 6]
Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July
2011
In 2010, China Unicom has deployed PTN technology in some field trail
networks. In 2011, China Unicom has started to build PTN commercial
trail networks in more than 10 cities.
3.5. Telecom Italia
Telecom Italia investigated PTN technologies and has been testing
several vendors' PTN equipment. Telecom Italia has recently
finalized a tender for acquiring PTN equipment and is going to deploy
them in the second half of 2011 in its metro aggregation networks. TI
is therefore interested in a fast definition of MPLS-TP
specifications in order to guarantee the interworking between
different implementations, particularly in respect to OAM and
protection mechanisms.
3.6. Telefonica I+D
Telefonica I+D, as R&D branch of Telefonica Group, is investigating
end to end PTN based network architectures based on the deployment of
PTN technologies in both metro aggregation and core networks. Main
drivers for end to end PTN networks are:
1. Automated end to end service provisioning (e.g L2 VPNS between
different metro networks)
2. Automated network failure detection and restoration by end to end
OAM mechanisms
MPLS-TP is one of the PTN technologies under analysis. According to
it, Telefonica I+D is interested in the definition of MPLS-TP
specifications enabling OAM multi-vendor compatibility in end to end
MPLS-TP networks.
4. Requirement of MPLS-TP OAM function toolset
From operator's view, the following OAM toolset and functionality are
essential for MPLS-TP deployment for PTN applications:
1. Pro-active Continuity Check and Connectivity Verification: to
support protection switching and misconnection detection;
2. Alarm and Lock reporting: to suppress pro-active CC/CV alarm
storms;
3. Remote Defect Indication: to support bi-direction performance
monitoring and single-ended fault management of bi-directional
connections;
Fang et al. Expires January 11, 2012 [Page 7]
Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July
2011
4. Pro-active and on-demand packet Loss/Delay Measurement: to be able
to compare the PM on the same path provide by ETH OAM and MPLS-TP
OAM. E.g. LM/DM should have the same behavior and results in both
Ethernet and MPLS-TP;
5. Client Failure Indication(CFI): to support services where alarm
propagation capabilities are not available/supported by the client
traffic (e.g., EPL services connecting two CEs not supporting
Ethernet OAM);
6. On-demand CV and diagnostic test: to allow service providers to
localize fault (at least the Loop-back tool) and check the out-of-
service test before service commissioning;
7. Tandem Connection Monitoring(TCM): for any transport path (e.g.,
LSPs and PWs) to support inter-domain monitoring;
Note: the OAM tools of Route Tracing to support on-demand CV in
connection-oriented PTN network is not needed, for the transport path
can be get in the PTN NMS trail management function.
5. OAM solutions
The operator's preference for a particular OAM solution depends on
the application domain and their network evolution strategy.
o For the PTN application domain described in this draft, the
priority is maximal synergy with transport-oriented operations and
managerial practices. The solution based upon draft-bhh-mpls-tp-
oam-y1731 [6] is consistent with this desired optimization.
o For some other operators who are evolving from an IP/MPLS
environment, leveraging on IP-oriented mechanisms such as BFD and
LSP-Ping is preferable (where possible to do so).
Both operator viewpoints are valid and standards should be capable of
providing interoperable solutions to meet the entire operator
community needs.
Different approaches have been submitted to the IETF standardization
process and are summarized in the next sections.
5.1. draft-bhh solution approach
The draft-bhh-mpls-tp-oam-y1731 [6] solution approach encapsulates
Y.1731 [4] OAM PDUs within MPLS-TP OAM packets in compliance with RFC
5586 [2] and draft-ietf-mpls-tp-oam-framework [5]. This approach
leverages ITU-T Y.1731 [4] PDUs and procedures (state machines) and
Fang et al. Expires January 11, 2012 [Page 8]
Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July
2011
IETF RFC 5586 [2] mechanisms to provide the essential set of OAM
mechanisms that meet the MPLS-TP OAM requirements as defined in RFC
5860 [3].
ITU-T Recommendation Y.1731 [4] 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
The first release of ITU-T Rec. Y.1731 [4] was approved in May 2006.
This Recommendation meets the operator's OAM requirements for
supporting end-to-end Ethernet services, which represents the most
popular and increasing market for operators and services providers.
Although Y.1731 [4] is focused on Ethernet service OAM, the
definition of OAM PDUs and procedures are technology independent and
can also be used for other packet technologies (e.g., MPLS-TP)
provided that the technology specific encapsulation is defined.
The draft-bhh-mpls-tp-oam-y1731 [6] solution approach encapsulates
Y.1731 [4] OAM PDUs within MPLS-TP packets in compliance with RFC
5586 [2] and draft-ietf-mpls-tp-oam-framework [5] (i.e., the OAM PDUs
are carried over the G-ACH [2]).
While draft-bhh-mpls-tp-oam-y1731 [6] documents these solution
elements within a single document, the solution approach allows
operators to select the particular OAM functions they wish to use.
Thus, it can complement other solution elements, as it does not
deprecate existing MPLS and PW OAM mechanisms or preclude
definition/utilization of other MPLS-TP OAM tools.
5.2. Extension of IP/MPLS OAM tools approach
Another solution approach is to extend IP/MPLS OAM tools to meet the
MPLS-TP OAM requirements as defined in RFC 5860 [3].
Some work in this direction is ongoing in draft-ietf-mpls-tp-cc-cv-
rdi [7] and draft-ietf-mpls-tp-on-demand-cv [9]. This approach is
currently limited to support only the pro-active CC, CV, RDI and
on-demand CV and tracerouting functions as defined in RFC 5860 [3].
So far a lot of technical difficulties have been encountered in
meeting some important transport requirements and behaviours, while
maintaining backward compatibility with existing BFD and LSP Ping
implementations. Those technical difficulties have not been resolved
Fang et al. Expires January 11, 2012 [Page 9]
Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July
2011
even during MPLS WG Last Call and the solution drafts that have been
moved toward IESG Processing still do not meet the transport
networks' needs for several service providers.
5.3. Development of new OAM tools approach
For other OAM functions described in RFC 5860 [3] and not covered by
the extensions of existing IP/MPLS OAM tools (mentioned in section
5.2), new tools would need to be developed.
A series of separated drafts have been submitted with different
maturity levels and there are some overlaps and inconsistencies that
need to be resolved. These drafts appear to re-use some Y.1731 [4]
information elements (e.g., draft-ietf-mpls-tp-loss-delay-profile
[8]).
6. Interoperability of draft-bhh implementations
As discussed earlier, interoperability testing of multi-vendor
implementations continues to be conducted by various operators.
Public interoperability events have also been conducted, as described
below.
In Sep. 2009 CEWC, EANTC conducted an MPLS-TP interoperability test
and reported:
"Different solutions have been proposed in individual author drafts
such as draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rdi [10] and
draft-bhh-mpls-tp-oam-y1731 [6], however the working group has not
yet accepted these documents as IETF working group drafts. The
purpose of EANTC's effort is to evaluate the current status of the
industry and to examine progress made since their last test in
February. The two OAM proposals tested have received substantial
vendor and service provider backing, so EANTC were able to stage
multi-vendor interoperability tests. The Alcatel-Lucent 1850 TSS-160,
Alcatel-Lucent 1850 TSS-320, and Huawei PTN 3900 successfully tested
an interoperable OAM solution based on the draft-bhh-mpls-tp-oam-
y1731 [6] which proposes modifications to Ethernet OAM tools as
defined in ITU-T Y.1731 [4] for use with MPLS-TP OAM. The enhanced
BFD protocol was used to check the continuity (liveliness) of the
MPLS-TP LSP established between the Ericsson devices. Both OAM
solutions were verified for the use of GAL and G-ACh."
Fang et al. Expires January 11, 2012 [Page 10]
Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July
2011
The EANTC whitepaper can be getting at:
http://www.eantc.com/fileadmin/eantc/downloads/events/2007-
2010/CEWC09/EANTC-CEWC2009-WhitePaper-v1_2.pdf (P.16~17).
In Feb. 2010 MPLS &Ethernet WC, EANTC conducted another MPLS-TP
interoperability test and reported:
"EANTC tested the MPLS-TP OAM approach supported by Alcatel-Lucent,
Huawei, and ZTE based on Y.1731 [4]. The Alcatel-Lucent 1850 TSS-
320, Huawei PTN 3900, and ZTE ZXCTN 6100 all successfully tested
interoperability for their MPLS-TP OAM implementations, based on ITU-
T Y.1731 which defines a protocol for Ethernet OAM. EANTC tested
this by first verifying that the protocol was used by all vendors to
establish connectivity on the respective MPLS-TP transport path, and
their ability to switch over to a backup transport path upon loss of
such connectivity. Between those devices was a LAN segment, to make
sure that the trigger was the loss of CCM frames (not the LOS)."
The EANTC whitepaper can be getting at:
http://www.eantc.com/fileadmin/eantc/downloads/events/2007-
2010/MPLSEWC2010/EANTC-MPLSEWC2010-WhitePaper.pdf (P.13~14).
In Sep. 2010 CEWC, EANTC conducted an MPLS-TP 1:1 LSP protection
interoperability test and reported:
"Most recently, one of the author drafts for a Bidirectional
Forwarding Detection (BFD) based OAM titled 'Proactive Connection
Verification, Continuity Check and Remote Defect Indication for MPLS
Transport Profile' has been accepted by the IETF MPLS working group.
In parallel, a series of vendors registered to the interop event
ready to test their OAM solutions based on ITU-T Recommendation
Y.1731[6]".
"In order to perform this test several multi-vendors pairs were
built... The observed failover times ranged between 13 to 28 ms for
link failure. The OAM tools from these vendors was based on draft-
bhh-mpls-tp-oam-y1731 and the linear protection was tested according
to draft-zulr-mpls-tp-linear-protection-switching-01."
The EANTC whitepaper can be downloaded at:
http://www.eantc.de/fileadmin/eantc/downloads/events/2007-
2010/CEWC2010/EANTC-CEWC2010-WhitePaper-v1_1.pdf (P.17~18)
Fang et al. Expires January 11, 2012 [Page 11]
Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July
2011
7. Considerations
For PTN-based metro aggregation and access networks, the OAM
mechanisms defined in draft-bhh-mpls-tp-oam-y1731 [6] fully satisfy
all the essential MPLS-TP OAM requirements.
The operators who have contributed to this draft fully support global
standards, and have relied upon the work of ITU-T and IETF. For this
reason, full support was given to the JWT agreement reached between
ITU-T and IETF, whose goal was to define the required MPLS-TP
standard solutions by October 2009. However, after waiting for over
two years, the essential solutions are still not available, and based
on the ongoing technical discussions there is great concern that a
solution will not be available in time for the planned deployments.
MPLS-TP based PTN significant deployment has started in this year.
There is urgency for standard MPLS-TP solutions this year to support
PTN applications, which are based on mature, multi-vendor
interoperable and tested mechanisms and procedures.
The maturity of OAM mechanisms is a key concern for operators. The
OAM toolset defined in Y.1731 [4] has emerged as a high benchmark for
OAM capabilities for support of managed end-to-end Ethernet services.
Using the approach in draft-bhh-mpls-tp-oam-y1731 [6], which is based
on proven ITU-T Y.1731 [4] OAM mechanisms and procedures, can help
the industry in providing MPLS-TP technology in time to meet market
needs. Also, for those operators who will have their PTN network
managed and maintained by their transport staff, this approach offers
the most expedient way to deploy MPLS-TP technology, as the
mechanisms defined in draft-bhh-mpls-tp-oam-y1731 [6] are very
similar to those of transport OAM.
Operator's OAM preference depends on the application domains, network
evolution strategy, etc. The roadmap for OAM toolset standardization
based on re-use of IP tools and development of new tools does not
meet the market needs of some operators like China Mobile, Telecom
Italia, China Telecom and China Unicom, and therefore, for the sake
of satisfying market needs, the solution described in draft-bhh-mpls-
tp-oam-y1731 [6], which leverages existing ITU-T and IETF standards,
should be taken into account.
In June 2010, during the ITU-T SG15 meeting, some members asked ITU-T
to liaise IETF the request to provide roadmap for MPLS-TP OAM toolset
and related internet drafts by sending a liaison to IETF. However,
roadmap was not clarified by IETF during the IETF 78 and in the
response liaison.
Moreover no action was taken about the proposal to get draft-bhh-
mpls-tp-oam-y1731 [6] included within the MPLS-TP toolkit although
Fang et al. Expires January 11, 2012 [Page 12]
Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July
2011
the discussion during the MPLS-TP sessions had been heavily focused
on MPLS-TP OAM and many operators and vendors expressed a clear
support for draft-bhh-mpls-tp-oam-y1731[6].
Currently, the schedule for completion of MPLS-TP OAM toolsets and
related drafts/RFCs in IETF is not clear so negatively affecting the
MPLS-TP standardization process in both IETF and ITU-T and the
telecommunication industry as a whole.
As discussed earlier, this proposal allows operators to select the
particular OAM functions they wish to use, and can complement other
MPLS-TP OAM solution elements currently under definition in the IETF.
8. Proposal
This Informational Internet-Draft is aimed at moving forward the
progress of an essential MPLS-TP OAM solution set to meet the urgent
and increasing requirements of PTN applications for the metro packet
transport network. Therefore, it is recommended that the solution
elements described in draft-bhh-mpls-tp-oam-y1731 [6] be included
within the MPLS-TP toolkit for supporting MPLS-TP OAM Functions, and
that the draft be progressed as a Standards Track RFC.
9. Security Considerations
There are not any security considerations in this draft.
10. IANA Considerations
No new IANA considerations.
11. Acknowledgments
The authors would like to thank the good cooperation between IETF and
ITU-T and thanks all IETF experts and ITU-T experts work on MPLS-TP
technology to push MPLS-TP standard rapidly.
Fang et al. Expires January 11, 2012 [Page 13]
Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July
2011
12. References
12.1. Normative References
[1] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., Ueno,
S., "MPLS-TP Requirements", RFC 5654, September 2009
[2] Vigoureux, M., Bocci, M., Swallow, G., Ward, D., Aggarwal, R.,
"MPLS Generic Associated Channel", RFC 5586, June 2009
[3] Vigoureux, M., Betts, M., Ward, D., "Requirements for OAM in
MPLS Transport Networks", RFC 5860, May, 2010
[4] ITU-T Recommendation Y.1731 (02/2008), " OAM functions and
mechanisms for Ethernet based networks ", Feb,2008
[5] I. Busi, B. Niven-Jenkins, D. Allan," MPLS-TP OAM
Framework",draft-ietf-mpls-tp-oam-framework-11 (work in
progress)
[6] I. Busi, H. van Helvoort, J.He "MPLS-TP OAM based on Y.1731",
draft-bhh-mpls-tp-oam-y1731-06 (work in progress)
12.2. Informative References
[7] Dave Allan, George Swallow, John Drake, "Proactive Connection
Verification, Continuity Check and Remote Defect indication for
MPLS Transport Profile" draft-ietf-mpls-tp-cc-cv-rdi-05 (work
in progress)
[8] Dan Frost, Stewart Bryant, "Packet Loss and Delay Measurement
for the MPLS Transport Profile" draft-ietf-mpls-tp-loss-delay-
profile-03 (work in progress)
[9] N. Bahadur, R. Aggarwal, S. Boutros, E. Gray, "LSP-Ping
extensions for MPLS-TP" draft-ietf-mpls-tp-on-demand-cv-05
(work in progress)
[10] A. Fulignoli , S. Boutros , M.Vigoureux ," MPLS-TP BFD for
Proactive CC-CV and RDI ",draft-fulignoli-mpls-tp-bfd-cv-
proactive-and-rdi-01 (expired and merged into draft-ietf-mpls-
tp-cc-cv-rdi; work in progress)
Fang et al. Expires January 11, 2012 [Page 14]
Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July
2011
Authors' Addresses
Fang Li (Editor)
China Academy of Telecommunication Research, P.R.China
Email: lifang@catr.cn
Han Li (Editor)
China Moblie
Email: lihan@chinamobile.com
Alessando D'Alessandro (Editor)
Telecom Italia
Email: alessandro.dalessandro@telecomitalia.it
Guangquan WANG (Editor)
China Unicom
Email: wanggq@dimpt.com
Ruiquan Jing (Editor)
China telecom
Email: jingrq@ctbri.com.cn
Juan Pedro Fernandez-Palacios Gi
Telefonica I+D
Email: jpfpg@tid.es
Contributing Authors' Addresses
Haiyi Zhang
China Academy of Telecommunication Research, P.R.China
Email: zhanghaiyi@catr.cn
Fang et al. Expires January 11, 2012 [Page 15]
Internet-Draft Operator Considerations on MPLS-TP OAM Mechanisms July
2011
Lei Wang
China Mobile
Email: wangleiyj@chinamobile.com
Pei zhang
China Unicom
Email: hq-zhangp@chinaunicom.cn
Yusen Yang
China Telecom
Email: yangys@chinatelecom.com.cn
Andrea Di Giglio
Telecom Italia
Email: andrea.digiglio@telecomitalia.it
Fang et al. Expires January 11, 2012 [Page 16]