draft-ietf-mpls-tp-use-cases-and-design-08.txt   rfc6965.txt 
INTERNET-DRAFT L. Fang, Ed. Internet Engineering Task Force (IETF) L. Fang, Ed.
Intended Status: Informational Cisco Request for Comments: 6965 Cisco
Expires: November 1, 2013 N. Bitar Category: Informational N. Bitar
Verizon ISSN: 2070-1721 Verizon
R. Zhang R. Zhang
Alcatel Lucent Alcatel-Lucent
M. Daikoku M. Daikoku
KDDI KDDI
P. Pan P. Pan
Infinera Infinera
August 2013
May 1, 2013 MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design
MPLS-TP Applicability; Use Cases and Design
draft-ietf-mpls-tp-use-cases-and-design-08.txt
Abstract Abstract
This document provides the applicability of Multiprotocol Label This document describes the applicability of the MPLS Transport
Switching Transport Profile (MPLS-TP) with use case studies and Profile (MPLS-TP) with use case studies and network design
network design considerations. The use cases include Metro Ethernet considerations. The use cases include Metro Ethernet access and
access and aggregation transport, Mobile backhaul, and packet optical aggregation transport, mobile backhaul, and packet optical transport.
transport.
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 Status of This Memo
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 This document is not an Internet Standards Track specification; it is
and may be updated, replaced, or obsoleted by other documents at any published for informational purposes.
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 This document is a product of the Internet Engineering Task Force
http://www.ietf.org/1id-abstracts.html (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6965.
Copyright and License Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology ................................................3
1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Background .................................................4
2. MPLS-TP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 6 2. MPLS-TP Use Cases ...............................................6
2.1. Metro Access and Aggregation . . . . . . . . . . . . . . . 6 2.1. Metro Access and Aggregation ...............................6
2.2. Packet Optical Transport . . . . . . . . . . . . . . . . . 7 2.2. Packet Optical Transport ...................................7
2.3. Mobile Backhaul . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Mobile Backhaul ............................................8
2.3.1. 2G and 3G Mobile Backhaul . . . . . . . . . . . . . . . 8 2.3.1. 2G and 3G Mobile Backhaul ...........................8
2.3.2. 4G/LTE Mobile Backhaul . . . . . . . . . . . . . . . . 8 2.3.2. 4G/LTE Mobile Backhaul ..............................9
3. Network Design Considerations . . . . . . . . . . . . . . . . . 9 3. Network Design Considerations ..................................10
3.1. The role of MPLS-TP . . . . . . . . . . . . . . . . . . . . 9 3.1. The Role of MPLS-TP .......................................10
3.2. Provisioning mode . . . . . . . . . . . . . . . . . . . . . 9 3.2. Provisioning Mode .........................................10
3.3. Standards compliance . . . . . . . . . . . . . . . . . . . 10 3.3. Standards Compliance ......................................10
3.4. End-to-end MPLS OAM consistency . . . . . . . . . . . . . . 10 3.4. End-to-End MPLS OAM Consistency ...........................11
3.5. PW Design considerations in MPLS-TP networks . . . . . . . 11 3.5. PW Design Considerations in MPLS-TP Networks ..............11
3.6. Proactive and on-demand MPLS-TP OAM tools . . . . . . . . . 11 3.6. Proactive and On-Demand MPLS-TP OAM Tools .................12
3.7. MPLS-TP and IP/MPLS Interworking considerations . . . . . . 12 3.7. MPLS-TP and IP/MPLS Interworking Considerations ...........12
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations ........................................13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 5. Acknowledgements ...............................................13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 6. References .....................................................13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Normative References ......................................13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 6.2. Informative References ....................................14
7.2. Informative References . . . . . . . . . . . . . . . . . . 13 7. Contributors ...................................................15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document provides applicability, use case studies and network This document describes the applicability of the MPLS Transport
design considerations for the Multiprotocol Label Switching Transport Profile (MPLS-TP) with use case studies and network design
Profile (MPLS-TP). considerations.
1.1. Terminology 1.1. Terminology
Term Definition Term Definition
------ ------------------------------------------------------- ------ -------------------------------------------------------
2G 2nd generation wireless telephone technology 2G 2nd generation of mobile telecommunications technology
3G 3rd generation of mobile telecommunications technology 3G 3rd generation of mobile telecommunications technology
4G 4th Generation Mobile network 4G 4th generation of mobile telecommunications technology
ADSL Asymmetric Digital Subscriber Line ADSL Asymmetric Digital Subscriber Line
AIS Alarm Indication Signal AIS Alarm Indication Signal
ASNGW Access Service Network Gateway
ATM Asynchronous Transfer Mode ATM Asynchronous Transfer Mode
BFD Bidirectional Forwarding Detection BFD Bidirectional Forwarding Detection
BTS Base Transceiver Station BTS Base Transceiver Station
CC-CV Continuity Check and Connectivity Verification CC-V Continuity Check and Connectivity Verification
CDMA Code Division Multiple Access CDMA Code Division Multiple Access
E-LINE Ethernet point-to-point connectivity E-LINE Ethernet line; provides point-to-point connectivity
E-LAN Ethernet LAN, provides multipoint connectivity E-LAN Ethernet LAN; provides multipoint connectivity
eNB Evolved Node B eNB Evolved Node B
EPC Evolved Packet Core EPC Evolved Packet Core
E-VLAN Ethernet Virtual Private LAN E-VLAN Ethernet Virtual Private LAN
EVDO Evolution-Data Optimized EVDO Evolution-Data Optimized
G-ACh Generic Associated Channel G-ACh Generic Associated Channel
GAL G-ACh Label GAL G-ACh Label
GMPLS Generalized Multi-Protocol Label Switching GMPLS Generalized Multiprotocol Label Switching
GSM Global System for Mobile Communications GSM Global System for Mobile Communications
HSPA High Speed Packet Access HSPA High Speed Packet Access
IPTV Internet Protocol television IPTV Internet Protocol television
L2VPN Layer 2 Virtual Private Network L2VPN Layer 2 Virtual Private Network
L3VPN Layer 3 Virtual Private Network L3VPN Layer 3 Virtual Private Network
LAN Local Access Network LAN Local Access Network
LDI Link Down Indication LDI Link Down Indication
LDP Label Distribution Protocol LDP Label Distribution Protocol
LSP Label Switched Path LSP Label Switched Path
LTE Long Term Evolution LTE Long Term Evolution
MEP Maintenance Entity Group End Point MEP Maintenance Entity Group End Point
MIP Maintenance Entity Group Intermediate Point MIP Maintenance Entity Group Intermediate Point
MPLS MultiProtocol Label Switching MPLS Multiprotocol Label Switching
MPLS-TP MultiProtocol Label Switching Transport Profile MPLS-TP MPLS Transport Profile
MS-PW Multi-Segment Pseudowire MS-PW Multi-Segment Pseudowire
NMS Network Management System NMS Network Management System
OAM Operations, Administration, and Maintenance OAM Operations, Administration, and Maintenance
OPEX Operating Expenses
PE Provider-Edge device PE Provider-Edge device
PDN GW Packet Data Network Gateway
PW Pseudowire PW Pseudowire
RAN Radio Access Network RAN Radio Access Network
RDI Remote Defect Indication RDI Remote Defect Indication
S-PE PW Switching Provider Edge
S1 LTE Standardized interface between eNB and EPC S1 LTE Standardized interface between eNB and EPC
SDH Synchronous Digital Hierarchy SDH Synchronous Digital Hierarchy
SGW Serving Gateway
SLA Service Level Agreement
SONET Synchronous Optical Network SONET Synchronous Optical Network
S-PE PW Switching Provider Edge
SP Service Provider SP Service Provider
SRLG Shared Risk Link Groups SRLG Shared Risk Link Groups
SS-PW Single-Segment Pseudowire SS-PW Single-Segment Pseudowire
TDM Time Division Multiplexing TDM Time-Division Multiplexing
TFS Time and Frequency Synchronization TFS Time and Frequency Synchronization
tLDP Targeted Label Distribution Protocol tLDP Targeted Label Distribution Protocol
VPN Virtual Private Network
UMTS Universal Mobile Telecommunications System UMTS Universal Mobile Telecommunications System
VPN Virtual Private Network
X2 LTE Standardized interface between eNBs for handover X2 LTE Standardized interface between eNBs for handover
1.2. Background 1.2. Background
Traditional transport technologies include SONET/SDH, TDM, and ATM. Traditional transport technologies include SONET/SDH, TDM, and ATM.
There is a transition away from these transport technologies to new There is a transition away from these transport technologies to new
packet transport technologies. In addition to the increasing demand packet transport technologies. In addition to the increasing demand
for bandwidth, packet transport technologies offer the following key for bandwidth, packet transport technologies offer the following key
advantages: advantages:
Bandwidth efficiency: Traditional transport technologies support Bandwidth efficiency:
fixed Bandwidth, no packet statistical multiplexing, the bandwidth is
reserved in the transport network regardless it is used by the client Traditional TDM transport technologies support fixed bandwidth with
or not. In contrast, packet technologies support statistical no statistical multiplexing. The bandwidth is reserved in the
multiplexing. This is the most important motivation for the transport network, regardless of whether or not it is used by the
client. In contrast, packet technologies support statistical
multiplexing. This is the most important motivation for the
transition from traditional transport technologies to packet transition from traditional transport technologies to packet
transport technologies. The proliferation of new distributed transport technologies. The proliferation of new distributed
applications which communicate with servers over the network in a applications that communicate with servers over the network in a
bursty fashion has been driving the adoption of packet transport bursty fashion has been driving the adoption of packet transport
techniques, since packet multiplexing of traffic from bursty sources techniques, since packet multiplexing of traffic from bursty sources
provides more efficient use of bandwidth than traditional circuit- provides more efficient use of bandwidth than traditional circuit-
based TDM technologies. based TDM technologies.
Flexible data rate connections: The granularity of data rate Flexible data rate connections:
connections of traditional transport technologies is limited to the
rigid PDH or SONET hierarchy (e.g., DS1, DS3, OC3, OC12, etc.).
Packet technologies support flexible data rate connections. The
support of finer data rate granularity is particularly important for
today's wireline and wireless services and applications.
QoS support: While traditional transport technology, such as TDM, has The granularity of data rate connections of traditional transport
very limited QoS support, packet transport can provide proper QoS technologies is limited to the rigid Plesiochronous Digital Hierarchy
treatment for IPTV, Voice and Video over IP applications. (PDH) hierarchy (e.g., DS1, DS3) or SONET hierarchy (e.g., OC3,
OC12). Packet technologies support flexible data rate connections.
The support of finer data rate granularity is particularly important
for today's wireline and wireless services and applications.
QoS support:
Traditional transport technologies (such as TDM) provide bandwidth
guarantees, but they are unaware of the types of traffic they carry.
They are not packet aware and do not provide packet-level services.
Packet transport can provide the differentiated services capability
needed to support oversubscription and to deal with traffic
prioritization upon congestion: issues that arise only in packet
networks.
The root cause for transport moving to packet transport is the shift The root cause for transport moving to packet transport is the shift
of application from TDM to packet. For example, Voice TDM to VoIP; of applications from TDM to packet -- for example, Voice TDM to VoIP,
Video to Video over IP; TDM access lines to Ethernet; TDM VPNs to IP Video to Video over IP, TDM access lines to Ethernet, and TDM VPNs to
VPNs and Ethernet VPNs. In addition, network convergence and IP VPNs and Ethernet VPNs. In addition, network convergence and
technology refreshes demand for common and a flexible infrastructure technology refreshes contribute to the demand for a common and
that provides multiple services. flexible infrastructure that provides multiple services.
As part of MPLS family, MPLS-TP complements existing IP/MPLS As part of the MPLS family, MPLS-TP complements existing IP/MPLS
technologies; it closes the gaps in the traditional access and technologies; it closes the gaps in the traditional access and
aggregation transport to enable end-to-end packet technology aggregation transport to enable end-to-end packet technology
solutions in a cost efficient, reliable, and interoperable manner. solutions in a cost efficient, reliable, and interoperable manner.
After several years of industry debate on which packet technology to After several years of industry debate on which packet technology to
use, MPLS-TP has emerged as the next generation transport technology use, MPLS-TP has emerged as the next generation transport technology
of choice for many Service Providers worldwide. of choice for many Service Providers worldwide.
The Unified MPLS strategy - using MPLS from core to aggregation and The Unified MPLS strategy -- using MPLS from core to aggregation and
access (e.g. IP/MPLS in the core, IP/MPLS or MPLS-TP in aggregation access (e.g., IP/MPLS in the core, IP/MPLS or MPLS-TP in aggregation
and access) appear to be very attractive to many SPs. It streamlines and access) -- appears to be very attractive to many SPs. It
the operation, reduces the overall complexity, and improves end-to- streamlines the operation, reduces the overall complexity, and
end convergence. It leverages the MPLS experience, and enhances the improves end-to-end convergence. It leverages the MPLS experience
ability to support revenue generating services. and enhances the ability to support revenue-generating services.
MPLS-TP is a subset of MPLS functions that meet the packet transport MPLS-TP is a subset of MPLS functions that meet the packet transport
requirements defined in [RFC5654]. This subset includes: MPLS data requirements defined in [RFC5654]. This subset includes: MPLS data
forwarding, pseudo-wire encapsulation for circuit emulation, and forwarding, pseudowire encapsulation for circuit emulation, and
dynamic control plane using GMPLS control for LSP and tLDP for dynamic control plane using GMPLS control for LSP and tLDP for
pseudo-wire (PW). MPLS-TP also extends previous MPLS OAM functions, pseudowire (PW). MPLS-TP also extends previous MPLS OAM functions,
such as BFD extension for proactive Connectivity Check and such as the BFD extension for proactive Connectivity Check and
Connectivity Verification (CC-CV) [RFC6428], and Remote Defect Connectivity Verification (CC-V) [RFC6428], Remote Defect Indication
Indication (RDI) [RFC6428], LSP Ping Extension for on-demand CC-CV (RDI) [RFC6428], and LSP Ping Extension for on-demand CC-V [RFC6426].
[RFC6426]. New tools have been defined for alarm suppression with New tools have been defined for alarm suppression with Alarm
Alarm Indication Signal (AIS) [RFC6427], and switch-over triggering Indication Signal (AIS) [RFC6427] and switch-over triggering with
with Link Defect Indication (LDI) [RFC6427]. Note that since the MPLS Link Down Indication (LDI) [RFC6427]. Note that since the MPLS OAM
OAM feature extensions defined through the process of MPLS-TP feature extensions defined through the process of MPLS-TP development
development are part of the MPLS family, the applicability is general are part of the MPLS family, the applicability is general to MPLS and
to MPLS, and not limited to MPLS-TP. not limited to MPLS-TP.
The requirements of MPLS-TP are provided in MPLS-TP Requirements [RFC The requirements of MPLS-TP are provided in the MPLS-TP requirements
5654], and the architectural framework is defined in MPLS-TP document [RFC5654], and the architectural framework is defined in the
Framework [RFC5921]. This document's intent is to provide the use MPLS-TP framework document [RFC5921]. This document's intent is to
case studies and design considerations from a practical point of view provide the use case studies and design considerations from a
based on Service Providers deployments plan as well as actual practical point of view based on Service Providers' deployments plans
deployments. as well as actual deployments.
The most common use cases for MPLS-TP include Metro access and The most common use cases for MPLS-TP include Metro access and
aggregation, Mobile Backhaul, and Packet Optical Transport. MPLS-TP aggregation, mobile backhaul, and packet optical transport. MPLS-TP
data plane architecture, path protection mechanisms, and OAM data-plane architecture, path protection mechanisms, and OAM
functionality are used to support these deployment scenarios. functionality are used to support these deployment scenarios.
The design considerations discussed in this document include: the The design considerations discussed in this document include the role
role of MPLS-TP in the network; provisioning options; standards of MPLS-TP in the network, provisioning options, standards
compliance; end-to-end forwarding and OAM consistency; compatibility compliance, end-to-end forwarding and OAM consistency, compatibility
with existing IP/MPLS networks; and optimization vs. simplicity with existing IP/MPLS networks, and optimization vs. simplicity
design trade-offs. design trade-offs.
2. MPLS-TP Use Cases 2. MPLS-TP Use Cases
2.1. Metro Access and Aggregation 2.1. Metro Access and Aggregation
The use of MPLS-TP for Metro access and aggregation transport is the The use of MPLS-TP for Metro access and aggregation transport is the
most common deployment scenario observed in the field. most common deployment scenario observed in the field.
Some operators are building green-field access and aggregation Some operators are building green-field access and aggregation
transport infrastructure, while others are upgrading/replacing their transport infrastructure, while others are upgrading or replacing
existing transport infrastructure with new packet technologies. The their existing transport infrastructure with new packet technologies.
existing legacy access and aggregation networks are usually based on The existing legacy access and aggregation networks are usually based
TDM or ATM technologies. Some operators are replacing these networks on TDM or ATM technologies. Some operators are replacing these
with MPLS-TP technologies, since legacy ATM/TDM aggregation and networks with MPLS-TP technologies, since legacy ATM/TDM aggregation
access are becoming inadequate to support the rapid business growth and access are becoming inadequate to support the rapid business
and too expensive to maintain. In addition, in many cases the legacy growth and too expensive to maintain. In addition, in many cases the
devices are facing End of Sale and End of Life issues. As operators legacy devices are facing End of Sale and End of Life issues. As
must move forward with the next generation packet technology, the operators must move forward with the next-generation packet
adoption of MPLS-TP in access and aggregation becomes a natural technology, the adoption of MPLS-TP in access and aggregation becomes
choice. The statistical multiplexing in MPLS-TP helps to achieve a natural choice. The statistical multiplexing in MPLS-TP helps to
higher efficiency compared with the time division scheme in the achieve higher efficiency compared with the time-division scheme in
legacy technologies. MPLS-TP OAM tools and protection mechanisms help the legacy technologies. MPLS-TP OAM tools and protection mechanisms
to maintain high reliability of transport networks and achieve fast help to maintain high reliability of transport networks and achieve
recovery. fast recovery.
As most Service Providers' core networks are MPLS enabled, extending As most Service Providers' core networks are MPLS enabled, extending
the MPLS technology to the aggregation and access transport networks the MPLS technology to the aggregation and access transport networks
with a Unified MPLS strategy is very attractive to many Service with a Unified MPLS strategy is very attractive to many Service
Providers. Unified MPLS strategy in this document means having end- Providers. Unified MPLS strategy in this document means having
to-end MPLS technologies through core, aggregation, and access. It end-to-end MPLS technologies through core, aggregation, and access.
reduces OPEX by streamlining operation and leveraging the operational It reduces operating expenses by streamlining the operation and
experience already gained with MPLS technologies; it also improves leveraging the operational experience already gained with MPLS
network efficiency and reduces end-to-end convergence time. technologies; it also improves network efficiency and reduces end-to-
end convergence time.
The requirements from the SPs for ATM/TDM aggregation replacement The requirements from the SPs for ATM/TDM aggregation replacement
often include: i) maintaining the previous operational model, which often include:
means providing a similar user experience in NMS, ii) supporting the
existing access network, (e.g., Ethernet, ADSL, ATM, TDM, etc.), and
connections with the core networks, and iii) supporting the same
operational capabilities and services (L3VPN, L2VPN, E-LINE/E-LAN/E-
VLAN, Dedicated Line, etc.). MPLS-TP can meet these requirements and
in general the requirements defined in [RFC5654] to support a smooth
transition.
2.2. Packet Optical Transport - maintaining the previous operational model, which means providing
a similar user experience in NMS,
Many SP's transport networks consist of both packet and optical - supporting the existing access network (e.g., Ethernet, ADSL, ATM,
portions. The transport operators are typically sensitive to network TDM, etc.) and connections with the core networks, and
deployment cost and operational simplicity. MPLS-TP supports both
- supporting the same operational capabilities and services (L3VPN,
L2VPN, E-LINE/E-LAN/E-VLAN, Dedicated Line, etc.).
MPLS-TP can meet these requirements and, in general, the requirements
defined in [RFC5654] to support a smooth transition.
2.2. Packet Optical Transport
Many SPs' transport networks consist of both packet and optical
portions. The transport operators are typically sensitive to network
deployment cost and operational simplicity. MPLS-TP supports both
static provisioning through NMS and dynamic provisioning via the static provisioning through NMS and dynamic provisioning via the
GMPLS control plane. As such, it is viewed as a natural fit in some GMPLS control plane. As such, it is viewed as a natural fit in
of the transport networks, where the operators can utilize the MPLS- transport networks where the operators can utilize the MPLS-TP LSPs
TP LSP's (including the ones statically provisioned) to manage user (including the ones statically provisioned) to manage user traffic as
traffic as "circuits" in both packet and optical networks, and when "circuits" in both packet and optical networks. Also, when the
they are ready, move to dynamic control plane for greater efficiency. operators are ready, they can migrate the network to use the dynamic
control plane for greater efficiency.
Among other attributes, bandwidth management, protection/recovery and Among other attributes, bandwidth management, protection/recovery,
OAM are critical in Packet/Optical transport networks. In the context and OAM are critical in packet/optical transport networks. In the
of MPLS-TP, each LSP is expected to be associated with a fixed amount context of MPLS-TP, LSPs may be associated with bandwidth allocation
of bandwidth in terms of bits-per-second and/or time-slots. OAM is to policies. OAM is to be performed on each individual LSP. For some
be performed on each individual LSP. For some of the performance of the performance monitoring functions, the OAM mechanisms need to
monitoring (PM) functions, the OAM mechanisms need to be able to be able to transmit and process OAM packets at very high frequency.
transmit and process OAM packets at very high frequency. An overview An overview of the MPLS-TP OAM toolset is found in [RFC6669].
of MPLS-TP OAM toolset is found in [RFC6669].
Protection [RFC6372] is another important element in transport Protection, as defined in [RFC6372], is another important element in
networks. Typically, ring and linear protection can be readily transport networks. Typically, ring and linear protection can be
applied in metro networks. However, as long-haul networks are readily applied in metro networks. However, as long-haul networks
sensitive to bandwidth cost and tend to have mesh-like topology, are sensitive to bandwidth cost and tend to have mesh-like topology,
shared mesh protection is becoming increasingly important. shared mesh protection is becoming increasingly important.
In some cases, SPs plan to deploy MPLS-TP from their long haul In some cases, SPs plan to deploy MPLS-TP from their long-haul
optical packet transport all the way to the aggregation and access in optical packet transport all the way to the aggregation and access in
their networks. their networks.
2.3. Mobile Backhaul 2.3. Mobile Backhaul
Wireless communication is one of the fastest growing areas in Wireless communication is one of the fastest growing areas in
communication worldwide. In some regions, the tremendous mobile communication worldwide. In some regions, the tremendous mobile
growth is fueled by the lack of existing land-line and cable growth is fueled by the lack of existing landline and cable
infrastructure. In other regions, the introduction of smart phones is infrastructure. In other regions, the introduction of smart phones
quickly driving mobile data traffic to become the primary mobile is quickly driving mobile data traffic to become the primary mobile
bandwidth consumer (some SPs have already observed more than 85% of bandwidth consumer (some SPs have already observed that more than 85%
total mobile traffic are data traffic). MPLS-TP is viewed as a of total mobile traffic is data traffic). MPLS-TP is viewed as a
suitable technology for Mobile backhaul. suitable technology for mobile backhaul.
2.3.1. 2G and 3G Mobile Backhaul 2.3.1. 2G and 3G Mobile Backhaul
MPLS-TP is commonly viewed as a very good fit for 2G/3G mobile MPLS-TP is commonly viewed as a very good fit for 2G/3G mobile
backhaul. 2G (GSM/CDMA) and 3G (UMTS/HSPA/1xEVDO) Mobile Backhaul backhaul. 2G (GSM/CDMA) and 3G (UMTS/HSPA/1xEVDO) mobile backhaul
Networks are still currently dominating the mobile infrastructure. networks are still currently dominating the mobile infrastructure.
The connectivity for 2G/3G networks is point to point (P2P). The The connectivity for 2G/3G networks is point to point (P2P). The
logical connections are hub-and-spoke. Networks are physically logical connections have a hub-and-spoke configuration. Networks are
constructed using a star or ring topology. In the Radio Access physically constructed using a star or ring topology. In the Radio
Network (RAN), each mobile Base Transceiver Station (BTS/Node B) is Access Network (RAN), each mobile Base Transceiver Station (BTS/Node
communicating with a Radio Controller (BSC/RNC). These connections B) is communicating with a Base Station Controller (BSC) or Radio
are often statically set up. Network Controller (RNC). These connections are often statically set
up.
Hierarchical or centralized architectures are often used for pre- Hierarchical or centralized architectures are often used for
aggregation and aggregation layers. Each aggregation network inter- pre-aggregation and aggregation layers. Each aggregation network
connects with multiple access networks. For example, a single interconnects with multiple access networks. For example, a single
aggregation ring could aggregate traffic for 10 access rings with a aggregation ring could aggregate traffic for 10 access rings with a
total of 100 base stations. total of 100 base stations.
The technology used today is largely ATM based. Mobile providers are The technology used today is largely ATM based. Mobile providers are
replacing the ATM RAN infrastructure with newer packet technologies. replacing the ATM RAN infrastructure with newer packet technologies.
IP RAN networks with IP/MPLS technologies are deployed today by many IP RAN networks with IP/MPLS technologies are deployed today by many
SPs with great success. MPLS-TP is another suitable choice for Mobile SPs with great success. MPLS-TP is another suitable choice for
RAN. The P2P connections from base station to Radio Controller can be Mobile RAN. The P2P connections from base station to Radio
set statically to mimic the operation of today's RAN environments; Controller can be set statically to mimic the operation of today's
in-band OAM and deterministic path protection can support fast RAN environments; in-band OAM and deterministic path protection can
failure detection and switch-over to satisfy the SLA agreements. support fast failure detection and switch-over to satisfy service
Bidirectional LSPs may help to simplify the provisioning process. The level agreements (SLAs). Bidirectional LSPs may help to simplify the
deterministic nature of MPLS-TP LSP set up can also support packet provisioning process. The deterministic nature of MPLS-TP LSP setup
based synchronization to maintain predictable performance regarding can also support packet-based synchronization to maintain predictable
packet delay and jitters. The traffic engineered and co-routed performance regarding packet delay and jitter. The traffic-
bidirectional properties of an MPLS-TP LSP are of benefit in engineered and co-routed bidirectional properties of an MPLS-TP LSP
transporting packet based Time and Frequency Synchronization (TFS) are of benefit in transporting packet-based Time and Frequency
protocols such as [1588overmpls]. However, the choice between an Synchronization (TFS) protocols, such as [TICTOC]. However, the
external, physical layer or packet based TFS method is network choice between an external, physical-layer method or a packet-based
dependent and thus is out of scope of this document. TFS method is network dependent and thus is out of scope of this
document.
2.3.2. 4G/LTE Mobile Backhaul 2.3.2. 4G/LTE Mobile Backhaul
One key difference between LTE and 2G/3G mobile networks is that the One key difference between LTE and 2G/3G mobile networks is that the
logical connection in LTE is a mesh, while in 2G/3G is a P2P star. In logical connection in LTE is a mesh, while in 2G/3G it is a P2P star.
LTE, the base stations eNB/BTS communicate with multiple Network In LTE, each base station (eNB/BTS) communicates with multiple
controllers (PDN GW/SGW or ASNGW), and the radio elements communicate network controllers (e.g., Packet Data Network Gateway, Packet Data
with one another for signal exchange and traffic offload to wireless Network Serving Gateway, Access Service Network Gateway), and the
or wireline infrastructures. radio elements communicate with one another for signal exchange and
traffic offload to wireless or wireline infrastructures.
IP/MPLS has a great advantage in any-to-any connectivity IP/MPLS has a great advantage in any-to-any connectivity
environments. Thus, the use of mature IP or L3VPN technologies is environments. Thus, the use of mature IP or L3VPN technologies is
particularly common in the design of SP's LTE deployment plans. particularly common in the design of an SP's LTE deployment plans.
The extended OAM functions defined in MPLS-TP, such as in-band OAM The extended OAM functions defined in MPLS-TP, such as in-band OAM
and path protection mechanisms bring additional advantages to support and path protection mechanisms, bring additional advantages to
SLAs. The dynamic control-plane with GMPLS signaling is especially support SLAs. The dynamic control plane with GMPLS signaling is
suited for the mesh environment, to support dynamic topology changes especially suited for the mesh environment, to support dynamic
and network optimization. topology changes and network optimization.
Some operators are using the same model as in 2G and 3G Mobile Some operators are using the same model as in 2G and 3G mobile
Backhaul, which uses IP/MPLS in the core, and MPLS-TP with static backhaul, which uses IP/MPLS in the core and MPLS-TP with static
provisioning (through NMS) in aggregation and access. The reasoning provisioning (through NMS) in aggregation and access. The reasoning
is as follows: the X2 traffic load in LTE networks currently may be a is as follows: currently, the X2 traffic load in LTE networks may be
very small percentage of the total traffic. For example, one large a very small percentage of the total traffic. For example, one large
mobile operator observed that X2 traffic was less than one percent of mobile operator observed that X2 traffic was less than one percent of
the total S1 traffic. Therefore, optimizing the X2 traffic may not be the total S1 traffic. Therefore, optimizing the X2 traffic may not
the design objective in this case. The X2 traffic can be carried be the design objective in this case. The X2 traffic can be carried
through the same static tunnels together with the S1 traffic in the through the same static tunnels together with the S1 traffic in the
aggregation and access networks, and further forwarded across the aggregation and access networks and further forwarded across the
IP/MPLS core. In addition, mesh protection may be more efficient with IP/MPLS core. In addition, mesh protection may be more efficient
regard to bandwidth utilization, but linear protection and ring with regard to bandwidth utilization, but linear protection and ring
protection are often considered simpler by some operators from the protection are often considered simpler by some operators from the
point of view of operation maintenance and trouble shooting, and so point of view of operation maintenance and troubleshooting, and so
are widely deployed. In general, using MPLS-TP with static are widely deployed. In general, using MPLS-TP with static
provisioning for LTE backhaul is a viable option. The design provisioning for LTE backhaul is a viable option. The design
objective of using this approach is to keep the operation simple and objective of using this approach is to keep the operation simple and
use a common model for mobile backhaul, especially during the use a common model for mobile backhaul, especially during the
transition period. transition period.
The TFS considerations stated in Section 3.3.1 apply to the 4G/LTE The TFS considerations stated in Section 2.3.1 apply to the 4G/LTE
Mobile Backhaul case as well. mobile backhaul case as well.
3. Network Design Considerations 3. Network Design Considerations
3.1. The role of MPLS-TP 3.1. The Role of MPLS-TP
The role of MPLS-TP is to provide a solution to help evolve The role of MPLS-TP is to provide a solution to help evolve
traditional transport towards packet. It is designed to support the traditional transport towards packet transport networks. It is
transport characteristics/behavior described in [RFC5654]. The designed to support the transport characteristics and behavior
primary use of MPLS-TP is largely to replace legacy transport described in [RFC5654]. The primary use of MPLS-TP is largely to
technologies, such as SONET/SDH. MPLS-TP is not designed to replace replace legacy transport technologies, such as SONET/SDH. MPLS-TP is
the service support capabilities of IP/MPLS, such as L2VPN, L3VPN, not designed to replace the service support capabilities of IP/MPLS,
IPTV, Mobile RAN, etc. such as L2VPN, L3VPN, IPTV, Mobile RAN, etc.
3.2. Provisioning mode 3.2. Provisioning Mode
MPLS-TP supports two provisioning modes: i) a mandatory static MPLS-TP supports two provisioning modes:
provisioning mode, which must be supported without dependency on
dynamic routing or signaling; and ii) an optional distributed dynamic - a mandatory static provisioning mode, which must be supported
control plane, which is used to enable dynamic service provisioning. without dependency on dynamic routing or signaling; and
- an optional distributed dynamic control plane, which is used to
enable dynamic service provisioning.
The decision on which mode to use is largely dependent on the The decision on which mode to use is largely dependent on the
operational feasibility and the stage of network transition. operational feasibility and the stage of network transition.
Operators who are accustomed to the transport-centric operational Operators who are accustomed to the transport-centric operational
model (e.g., NMS configuration without control plane) typically model (e.g., NMS configuration without control plane) typically
prefer the static provisioning mode. This is the most common choice prefer the static provisioning mode. This is the most common choice
in current deployments. The dynamic provisioning mode can be more in current deployments. The dynamic provisioning mode can be more
powerful but it is more suited to operators who are familiar with the powerful, but it is more suited to operators who are familiar with
operation and maintenance of IP/MPLS technologies or are ready to the operation and maintenance of IP/MPLS technologies or are ready to
step up through training and planned transition. step up through training and planned transition.
There may be also cases where operators choose to use the combination There may also be cases where operators choose to use the combination
of both modes. This is appropriate when parts of the network are of both modes. This is appropriate when parts of the network are
provisioned in a static fashion and other parts are controlled by provisioned in a static fashion, and other parts are controlled by
dynamic signaling. This combination may also be used to transition dynamic signaling. This combination may also be used to transition
from static provisioning to dynamic control plane. from static provisioning to dynamic control plane.
3.3. Standards compliance 3.3. Standards Compliance
It is generally recognized by SPs that standards compliance is SPs generally recognize that standards compliance is important for
important for lowering cost, accelerating product maturity, achieving lowering cost, accelerating product maturity, achieving multi-vendor
multi-vendor interoperability, and meeting the expectations of their interoperability, and meeting the expectations of their enterprise
enterprise customers. customers.
MPLS-TP is a joint work between IETF and ITU-T. In April 2008, IETF MPLS-TP is a joint work between the IETF and ITU-T. In April 2008,
and ITU-T jointly agreed to terminate T-MPLS and progress MPLS-TP as the IETF and ITU-T jointly agreed to terminate T-MPLS and progress
joint work [RFC5317]. The transport requirements are provided by ITU- MPLS-TP as joint work [RFC5317]. The transport requirements are
T, the protocols are developed in IETF. provided by the ITU-T; the protocols are developed in the IETF.
3.4. End-to-end MPLS OAM consistency 3.4. End-to-End MPLS OAM Consistency
End-to-end MPLS OAM consistency is highly desirable in order to End-to-end MPLS OAM consistency is highly desirable in order to
enable Service Providers to deploy an end-to-end MPLS solution. As enable Service Providers to deploy an end-to-end MPLS solution. As
MPLS-TP adds OAM function to the MPLS toolkit, it cannot be expected MPLS-TP adds OAM function to the MPLS toolkit, it cannot be expected
that a full-function end-to-end LSP with MPLS-TP OAM can be achieved that a full-function end-to-end LSP with MPLS-TP OAM can be achieved
when the LSP traverses a legacy MPLS/IP core. Although it may be when the LSP traverses a legacy MPLS/IP core. Although it may be
possible to select a subset of MPLS-TP OAM that can be gatewayed to possible to select a subset of MPLS-TP OAM that can be gatewayed to
the legacy MPLS/IP OAM, a better solution is achieved by tunneling the legacy MPLS/IP OAM, a better solution is achieved by tunneling
the MPLS-TP LSP over the legacy MPLS/IP network. In that mode of the MPLS-TP LSP over the legacy MPLS/IP network. In that mode of
operation, legacy OAM may be run on the tunnel in the core, and the operation, legacy OAM may be run on the tunnel in the core, and the
tunnel end-points may report issues in as much detail as possible to tunnel endpoints may report issues in as much detail as possible to
the MIPs in the MPLS-TP LSP. Note that over time it is expected that the MIPs in the MPLS-TP LSP. Note that over time it is expected that
routers in the MPLS/IP core will be upgraded to fully support MPLS-TP routers in the MPLS/IP core will be upgraded to fully support MPLS-TP
features: once this has occurred, it will be possible to run end-to- features. Once this has occurred, it will be possible to run
end MPLS-TP LSPs seamlessly across the core. end-to-end MPLS-TP LSPs seamlessly across the core.
3.5. PW Design considerations in MPLS-TP networks 3.5. PW Design Considerations in MPLS-TP Networks
In general, PWs in MPLS-TP work the same as in IP/MPLS networks. Both In general, PWs in MPLS-TP work the same as in IP/MPLS networks.
Single-Segment PW (SS-PW) and Multi-Segment PW (MS-PW) are supported. Both Single-Segment PW (SS-PW) and Multi-Segment PW (MS-PW) are
For dynamic control plane, Targeted LDP (tLDP) is used. In static supported. For dynamic control plane, Targeted LDP (tLDP) is used.
provisioning mode, PW status is a new PW OAM feature for failure In static provisioning mode, PW status is a new PW OAM feature for
notification. In addition, both directions of a PW must be bound to failure notification. In addition, both directions of a PW must be
the same transport bidirectional LSP. bound to the same transport bidirectional LSP.
In the common network topology involving multi-tier rings, the design In the common network topology involving multi-tier rings, the design
choice is between using SS-PW or MS-PW. This is not a discussion choice is between using SS-PW or MS-PW. This is not a discussion
unique to MPLS-TP, as it applies to PW design in general, but it is unique to MPLS-TP, as it applies to PW design in general. However,
relevant here, since MPLS-TP is more sensitive to the operational it is relevant here, since MPLS-TP is more sensitive to the
complexities, as noted by operators. If MS-PW is used, Switched PE operational complexities, as noted by operators. If MS-PW is used,
(S-PE) must be deployed to connect the rings. The advantage of this Switching PE (S-PE) must be deployed to connect the rings. The
choice is that it provides domain isolation, which in turn advantage of this choice is that it provides domain isolation, which
facilitates trouble shooting and allows for faster PW failure in turn facilitates troubleshooting and allows for faster PW failure
recovery. On the other hand, the disadvantage of using S-PE is that recovery. On the other hand, the disadvantage of using S-PE is that
it adds more complexity. Using SS-PW is simpler, since it does not it adds more complexity. Using SS-PW is simpler, since it does not
require S-PEs, but less efficient because the paths across primary require S-PEs, but it is less efficient because the paths across
and secondary rings are longer. If operational simplicity is a higher primary and secondary rings are longer. If operational simplicity is
priority, some SPs choose the latter. a higher priority, some SPs choose SS-PW.
Another design trade-off is whether to use PW protection in addition Another design trade-off is whether to use PW protection in addition
to LSP protection or rely solely on LSP protection. When the MPLS-TP to LSP protection or rely solely on LSP protection. When the MPLS-TP
LSPs are protected, if the working LSP fails, the protect LSP assures LSPs are protected, if the working LSP fails, the protecting LSP
that the connectivity is maintained and the PW is not impacted. assures that the connectivity is maintained and the PW is not
However, in the case of simultaneous failure of both working and impacted. However, in the case of simultaneous failure of both the
protect LSPs, the attached PW would fail. By adding PW protection, working and protecting LSPs, the attached PW would fail. By adding
and attaching the protect PW to a diverse LSP not in the same Shared PW protection and attaching the protecting PW to a diverse LSP not in
Risk Link Group (SRLG), the PW is protected even when the primary PW the same Shared Risk Link Group (SRLG), the PW is protected even when
fails. Clearly, using PW protection adds considerably more the primary PW fails. Clearly, using PW protection adds considerably
complexity and resource usage, and thus operators often may choose more complexity and resource usage, and thus operators often may
not to use it, and consider protection against single point of choose not to use it and consider protection against a single point
failure as sufficient. of failure as sufficient.
3.6. Proactive and on-demand MPLS-TP OAM tools 3.6. Proactive and On-Demand MPLS-TP OAM Tools
MPLS-TP provide both proactive and on-demand OAM Tools. As a MPLS-TP provides both proactive and on-demand OAM tools. As a
proactive OAM fault management tool, BFD Connectivity Check (CC) can proactive OAM fault management tool, BFD Connectivity Check (CC) can
be sent at regular intervals for Connectivity Check; three missed CC be sent at regular intervals for Connectivity Check; three (or a
messages (or a configurable number) can trigger the failure configurable number) of missed CC messages can trigger the failure
protection switch-over. BFD sessions are configured for both working protection switch-over. BFD sessions are configured for both working
and protecting LSPs. and protecting LSPs.
A design decision is choosing the value of the BFD CC interval. The A design decision is choosing the value of the BFD CC interval. The
shorter the interval, the faster the detection time is, but also the shorter the interval, the faster the detection time is, but also the
higher the resource utilization is. The proper value depends on the higher the resource utilization is. The proper value depends on the
application and the service needs. application and the service needs, as well as the protection
mechanism provided at the lower layer.
As an on-demand OAM fault management mechanism, for example when As an on-demand OAM fault management mechanism (for example, when
there is a fiber cut, Link Down Indication (LDI) message [RFC6427] there is a fiber cut), a Link Down Indication (LDI) message [RFC6427]
can be generated from the failure point and propagated to the can be generated from the failure point and propagated to the
Maintenance Entity Group End Points (MEPs) to trigger immediate Maintenance Entity Group End Points (MEPs) to trigger immediate
switch-over from working to protect path. An Alarm Indication Signal switch-over from working to protecting path. An Alarm Indication
(AIS) can be propagated from the Maintenance Entity Group Signal (AIS) can be propagated from the Maintenance Entity Group
Intermediate Point (MIP) to the MEPs for alarm suppression. Intermediate Point (MIP) to the MEPs for alarm suppression.
In general, both proactive and on-demand OAM tools should be enabled In general, both proactive and on-demand OAM tools should be enabled
to guarantee short switch-over times. to guarantee short switch-over times.
3.7. MPLS-TP and IP/MPLS Interworking considerations 3.7. MPLS-TP and IP/MPLS Interworking Considerations
Since IP/MPLS is largely deployed in most SPs' networks, MPLS-TP and Since IP/MPLS is largely deployed in most SPs' networks, MPLS-TP and
IP/MPLS Interworking is inevitable if not a reality. However, IP/MPLS interworking is inevitable if not a reality. However,
Interworking discussion is out of the scope of this document; it is interworking discussion is out of the scope of this document; it is
for further study. for further study.
4. Security Considerations 4. Security Considerations
Under the use case of Metro access and aggregation, in the scenario Under the use case of Metro access and aggregation, in the scenario
where some of the access equipment is placed in facilities not owned where some of the access equipment is placed in facilities not owned
by the SP, the static provisioning mode of MPLS-TP is often preferred by the SP, the static provisioning mode of MPLS-TP is often preferred
over the control plane option because it eliminates the possibility over the control-plane option because it eliminates the possibility
of a control plane attack which may potentially impact the whole of a control-plane attack, which may potentially impact the whole
network. This scenario falls into the Security Reference Model 2 as network. This scenario falls into the Security Reference Model 2 as
described in [RFC6941]. described in [RFC6941].
Similar location issues apply to the mobile use cases, since Similar location issues apply to the mobile use cases since equipment
equipment is often placed in remote and outdoor environment, which is often placed in remote and outdoor environment, which can increase
can increase the risk of un-authorized access to the equipment. the risk of unauthorized access to the equipment.
In general, NMS access can be a common point of attack in all MPLS-TP In general, NMS access can be a common point of attack in all MPLS-TP
use cases, and attacks to GAL or G-ACh are unique security treats to use cases, and attacks to GAL or G-ACh are unique security threats to
MPLS-TP. The MPLS-TP security considerations are discussed in MPLS-TP MPLS-TP. The MPLS-TP security considerations are discussed in the
Security Framework [RFC6941]. General security considerations for MPLS-TP security framework [RFC6941]. General security
MPLS and GMPLS networks are addressed in Security Framework for MPLS considerations for MPLS and GMPLS networks are addressed in "Security
and GMPLS Networks [RFC5920]. Framework for MPLS and GMPLS Networks" [RFC5920].
5. IANA Considerations
This document contains no new IANA considerations.
6. Acknowledgements 5. Acknowledgements
The authors wish to thank Adrian Farrel for his review as Routing The authors wish to thank Adrian Farrel for his review as Routing
Area Director, Adrian's detailed comments and suggestions were of Area Director and his continued support and guidance. Adrian's
great help for improving the quality of this document, and thank Loa detailed comments and suggestions were of great help for improving
Andersson and Adrian Farrel for their continued support and guidance. the quality of this document. In addition, the authors would like to
The authors would also like to thank Weiqiang Cheng for his helpful thank the following individuals: Loa Andersson for his continued
input on LTE Mobile backhaul based on his knowledge and experience in support and guidance; Weiqiang Cheng for his helpful input on LTE
real world deployment, thank Stewart Bryant for his text contribution mobile backhaul based on his knowledge and experience in real world
on timing, thank Russ Housley for his improvement suggestions, thank deployment; Stewart Bryant for his text contribution on timing; Russ
Andrew Malis for his support and use case discussion, thank Pablo Housley for his improvement suggestions; Andrew Malis for his support
Frank, Lucy Yong, Huub van Helvoort, Tom Petch, Curtis Villamizar, and use case discussion; Pablo Frank, Lucy Yong, Huub van Helvoort,
and Paul Doolan for their comments and suggestions, thank Joseph Yee Tom Petch, Curtis Villamizar, and Paul Doolan for their comments and
and Miguel Garcia for their APPSDIR and Gen-ART reviews and comments suggestions; and Joseph Yee and Miguel Garcia for their APPSDIR and
respectively. Gen-ART reviews and comments, respectively.
7. References 6. References
7.1. Normative References 6.1. Normative References
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, September 2009. Transport Profile", RFC 5654, September 2009.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, July 2010. Networks", RFC 5921, July 2010.
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
On-Demand Connectivity Verification and Route Tracing", On-Demand Connectivity Verification and Route Tracing",
RFC 6426, November 2011. RFC 6426, November 2011.
[RFC6427] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed., [RFC6427] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed.,
Boutros, S., and D. Ward, "MPLS Fault Management Boutros, S., and D. Ward, "MPLS Fault Management
Operations, Administration, and Maintenance (OAM)", Operations, Administration, and Maintenance (OAM)", RFC
RFC 6427, November 2011. 6427, November 2011.
[RFC6428] Allan, D., Ed., Swallow Ed., G., and J. Drake Ed., [RFC6428] Allan, D., Ed., Swallow Ed., G., and J. Drake Ed.,
"Proactive Connectivity Verification, Continuity Check, "Proactive Connectivity Verification, Continuity Check,
and Remote Defect Indication for the MPLS Transport and Remote Defect Indication for the MPLS Transport
Profile", RFC 6428, November 2011. Profile", RFC 6428, November 2011.
7.2. Informative References 6.2. Informative References
[RFC5317] Bryant, S., Ed., and L. Andersson, Ed., "Joint Working [RFC5317] Bryant, S., Ed., and L. Andersson, Ed., "Joint Working
Team (JWT) Report on MPLS Architectural Considerations for Team (JWT) Report on MPLS Architectural Considerations for
a Transport Profile", RFC 5317, February 2009. a Transport Profile", RFC 5317, February 2009.
[RFC6372] Sprecher, N., Ed., and A. Farrel, Ed., "MPLS Transport [RFC6372] Sprecher, N., Ed., and A. Farrel, Ed., "MPLS Transport
Profile (MPLS-TP) Survivability Framework", RFC 6372, Profile (MPLS-TP) Survivability Framework", RFC 6372,
September 2011. September 2011.
[RFC6669] Sprecher, N. and L. Fang, "An Overview of the Operations, [RFC6669] Sprecher, N. and L. Fang, "An Overview of the Operations,
Administration, and Maintenance (OAM) Toolset for MPLS- Administration, and Maintenance (OAM) Toolset for MPLS-
Based Transport Networks", RFC 6669, July 2012. Based Transport Networks", RFC 6669, July 2012.
[RFC6941] Fang, L. Ed., Niven-Jenkins, B., Ed., Mansfield, [RFC6941] Fang, L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed.,
S., Ed., and R. Graveman, Ed., "MPLS-TP Security and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP)
Framework," RFC 6941, April 2013. Security Framework", RFC 6941, April 2013.
[1588overmpls], Davari, S., Oren, A., Bhatia, M., Roberts, P., and [TICTOC] Davari, S., Oren, A., Bhatia, M., Roberts, P., Montini,
L. Montini, "Transporting Timing messages over MPLS L., and L. Martini, "Transporting Timing messages over
Networks," draft-ietf-tictoc-1588overmpls-04.txt, February MPLS Networks", Work in Progress, June 2013.
2013.
Authors' Addresses 7. Contributors
Luyuan Fang Kam Lee Yap
Cisco Systems, Inc. XO Communications
111 Wood Ave. South 13865 Sunrise Valley Drive
Iselin, NJ 08830 Herndon, VA 20171
United States United States
Email: lufang@cisco.com EMail: klyap@xo.com
Nabil Bitar Dan Frost
Verizon Cisco Systems, Inc.
40 Sylvan Road United Kingdom
Waltham, MA 02145 EMail: danfrost@cisco.com
United States
Email: nabil.bitar@verizon.com
Raymond Zhang Henry Yu
Alcatel-Lucent TW Telecom
701 Middlefield Road 10475 Park Meadow Dr.
Mountain View, CA 94043 Littleton, CO 80124
United States United States
Email: raymond.zhang@alcatel-lucent.com EMail: henry.yu@twtelecom.com
Masahiro Daikoku Jian Ping Zhang
KDDI corporation China Telecom, Shanghai
3-11-11.Iidabashi, Chiyodaku, Tokyo Room 3402, 211 Shi Ji Da Dao
Japan Pu Dong District, Shanghai
Email: ms-daikoku@kddi.com China
EMail: zhangjp@shtel.com.cn
Ping Pan Lei Wang
Infinera Lime Networks
United States Strandveien 30, 1366 Lysaker
Email: ppan@infinera.com Norway
EMail: lei.wang@limenetworks.no
Contributors' Addresses Mach (Guoyi) Chen
Huawei Technologies Co., Ltd.
No. 3 Xinxi Road
Shangdi Information Industry Base
Hai-Dian District, Beijing 100085
China
EMail: mach@huawei.com
Kam Lee Yap Nurit Sprecher
XO Communications Nokia Siemens Networks
13865 Sunrise Valley Drive, 3 Hanagar St. Neve Ne'eman B
Herndon, VA 20171 Hod Hasharon, 45241
United States Israel
Email: klyap@xo.com EMail: nurit.sprecher@nsn.com
Dan Frost Authors' Addresses
Cisco Systems, Inc.
United Kingdom
Email:danfrost@cisco.com
Henry Yu Luyuan Fang (editor)
TW Telecom Cisco Systems, Inc.
10475 Park Meadow Dr. 111 Wood Ave. South
Littleton, CO 80124 Iselin, NJ 08830
United States United States
Email: henry.yu@twtelecom.com EMail: lufang@cisco.com
Jian Ping Zhang Nabil Bitar
China Telecom, Shanghai Verizon
Room 3402, 211 Shi Ji Da Dao 40 Sylvan Road
Pu Dong District, Shanghai Waltham, MA 02145
China United States
Email: zhangjp@shtel.com.cn EMail: nabil.bitar@verizon.com
Lei Wang Raymond Zhang
Lime Networks Alcatel-Lucent
Strandveien 30, 1366 Lysaker 701 Middlefield Road
Norway Mountain View, CA 94043
Email: lei.wang@limenetworks.no United States
EMail: raymond.zhang@alcatel-lucent.com
Mach(Guoyi) Chen Masahiro Daikoku
Huawei Technologies Co., Ltd. KDDI Corporation
No. 3 Xinxi Road 3-11-11.Iidabashi, Chiyodaku, Tokyo
Shangdi Information Industry Base Japan
Hai-Dian District, Beijing 100085 EMail: ms-daikoku@kddi.com
China
Email: mach@huawei.com
Nurit Sprecher Ping Pan
Nokia Siemens Networks Infinera
3 Hanagar St. Neve Ne'eman B United States
Hod Hasharon, 45241 EMail: ppan@infinera.com
Israel
Email: nurit.sprecher@nsn.com
 End of changes. 129 change blocks. 
436 lines changed or deleted 441 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/