draft-ietf-mpls-tp-use-cases-and-design-02.txt   draft-ietf-mpls-tp-use-cases-and-design-03.txt 
Network Working Group L. Fang, Ed. INTERNET-DRAFT L. Fang, Ed.
Internet Draft Cisco Systems Intended Status: Informational Cisco
Intended status: Informational N. Bitar Expires: June 16, 2013 N. Bitar
Expires: December 11, 2012 Verizon Verizon
R. Zhang R. Zhang
Alcatel Lucent Alcatel Lucent
M. DAIKOKU M. Daikoku
KDDI KDDI
P. Pan P. Pan
Infinera Infinera
June 11, 2012 December 16, 2012
MPLS-TP Applicability; Use Cases and Design MPLS-TP Applicability; Use Cases and Design
draft-ietf-mpls-tp-use-cases-and-design-02.txt draft-ietf-mpls-tp-use-cases-and-design-03.txt
Abstract Abstract
This document provides applicability, use case studies and network This document provides applicability, use case studies and network
design considerations for Multiprotocol Label Switching Transport design considerations for the Multiprotocol Label Switching Transport
profile (MPLS-TP). Profile (MPLS-TP). The use cases include Metro Ethernet access and
aggregation transport, Mobile backhaul, and packet optical transport.
In the recent years, MPLS-TP has emerged as the technology of choice
for the new generation of packet transport. Many service providers
(SPs) are working to replace the legacy transport technologies, e.g.
SONET/SDH, TDM, and ATM technologies, with MPLS-TP for packet
transport, in order to achieve higher efficiency, lower operational
cost, while maintaining transport characteristics.
The use cases for MPLS-TP include Metro Ethernet access and
aggregation, Mobile backhaul, and packet optical transport. The
design considerations discussed in this documents ranging from
operational experience; standards compliance; technology maturity;
end-to-end forwarding and OAM consistency; compatibility with
IP/MPLS networks; multi-vendor interoperability; and optimization
vs. simplicity design trade off discussion. The general design
principle is to provide reliable, manageable, and scalable transport
solutions.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with the
the provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
MPLS-TP Use Case and Design Considerations
Expires December 2012
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF), its areas, and its working groups. Note that
working documents as Internet-Drafts. The list of current Internet- other groups may also distribute working documents as
Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at any
at any time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress. material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 11, 2012. The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
Copyright Notice The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
INTERNET DRAFT <Document Title> <Issue Date>
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ...................................................3 3 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background and Motivation ...................................3 3 3. MPLS-TP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Co-authors and contributors .................................3 5 3.1. Metro Access and Aggregation . . . . . . . . . . . . . . . 5
2. Terminologies ..................................................5 5 3.2. Packet Optical Transport . . . . . . . . . . . . . . . . . 6
3. Overview of MPLS-TP base functions .............................6 6 3.3. Mobile Backhaul . . . . . . . . . . . . . . . . . . . . . . 7
3.1. MPLS-TP development principles ..............................6 6 3.3.2. 2G and 3G Mobile Backhaul . . . . . . . . . . . . . . . 7
3.2. Data Plane ..................................................7 7 3.3.2. 4G/LTE Mobile Backhaul . . . . . . . . . . . . . . . . 8
3.3. Control Plane ...............................................7 7 5. Network Design Considerations . . . . . . . . . . . . . . . . . 8
3.4. OAM .........................................................7 7 5.1. The role of MPLS-TP . . . . . . . . . . . . . . . . . . . . 8
3.5. Survivability ...............................................8 8 5.2 Provisioning mode . . . . . . . . . . . . . . . . . . . . . 8
4. MPLS-TP Use Case Studies .......................................8 8 5.3. Standards compliance . . . . . . . . . . . . . . . . . . . 9
MPLS-TP Use Case and Design Considerations 5.4. End-to-end MPLS OAM consistency . . . . . . . . . . . . . . 9
Expires December 2012 5.5. PW Design considerations in MPLS-TP networks . . . . . . . 9
5.6. Proactive and on-demand MPLS-TP OAM tools . . . . . . . . . 10
4.2. Packet Optical Transport ....................................9 9 5.7. MPLS-TP and IP/MPLS Interworking considerations . . . . . . 10
4.3. Mobile Backhaul ............................................10 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 11
5. Network Design Considerations .................................11 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11
5.1. IP/MPLS vs. MPLS-TP ........................................11 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Standards compliance .......................................11 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. End-to-end MPLS OAM consistency ............................12 13 9.1 Normative References . . . . . . . . . . . . . . . . . . . 11
5.4. PW Design considerations in MPLS-TP networks ...............13 13 9.2 Informative References . . . . . . . . . . . . . . . . . . 12
5.5. Proactive and event driven MPLS-TP OAM tools ...............13 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
5.6. MPLS-TP and IP/MPLS Interworking considerations ............14 14 Contributors' Address . . . . . . . . . . . . . . . . . . . . . . 13
5.7. Delay and delay variation ..................................14 14
5.8. More on MPLS-TP Deployment Considerations ..................17 17
6. Security Considerations .......................................19 19
7. IANA Considerations ...........................................19 19
8. Normative References ..........................................19 19
9. Informative References ........................................19 19
10. Author's Addresses...........................................20 20
Requirements Language
Although this document is not a protocol specification, the key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 [RFC
2119].
1. Introduction INTERNET DRAFT <Document Title> <Issue Date>
1.1. Background and Motivation 1 Introduction
This document provides case studies and network design This document provides applicability, use case studies and network
considerations for Multiprotocol Label Switching Transport Profile design considerations for the Multiprotocol Label Switching Transport
(MPLS-TP). Profile (MPLS-TP).
In recent years, the urgency for moving from traditional transport In recent years, the urgency for moving from traditional transport
technologies, such as SONET/SDH, TDM/ATM, to new packet technologies technologies, such as SONET/SDH, TDM, and ATM, to new packet
data services, such as IPTV and IP Video for content downloading, technologies has been rising. This is largely due to the fast growing
streaming, and sharing; rapid growth of mobile services, especially demand for bandwidth, which has been fueled by the following factors:
smart phone applications; the continued growth of business VPNs and 1) The growth of new services. This includes: the tremendous success
residential broadband. The end of live for many legacy TDM devices of data services, such as IPTV and IP Video for content downloading,
and the continuing network convergence effort are also key streaming, and sharing; the rapid growth of mobile services, as a
contributing factors for transport moving toward packet consequence of the explosion of smart phone applications; the
MPLS-TP Use Case and Design Considerations continued growth of business VPNs and residential broadband services.
Expires December 2012 2) Network infrastructure evolution. As many legacy transport devices
are approaching end of life, Service Providers transition to new
technologies. After several years of heated debate on which packet packet technologies and evolve their transport network into the next
technology to use, MPLS-TP has emerged as the next generation generation packet transport.
transport technology of choice for many service providers
worldwide.
MPLS-TP is based on MPLS technologies. MPLS-TP re-use a subset of
MPLS base functions, such as MPLS data forwarding, Pseudo-wire
encapsulation for circuit emulation, and GMPLS for LSP, tLDP for PW,
as dynamic control plane options; MPLS-TP extended current MPLS OAM
functions, such as BFD extension for Connectivity for proactive
Connectivity Check (CC) and Connectivity Verification (CV), and
Remote Defect Indication (RDI), LSP Ping Extension for on demand
Connectivity Check (CC) and Connectivity Verification (CV), fault
allocation, and remote integrity check. New tools are being defined
for alarm suppression with Alarm Indication Signal (AIS), and
trigger of switch over with Link Defect Indication (LDI).
The goal is to take advantage of the maturity of MPLS technology,
re-use the existing component when possible and extend the existing
protocols or create new procedures/protocols when needed to fully
satisfy the transport requirements.
The general requirements of MPLS-TP are provided in MPLS-TP
Requirements [RFC 5654], and the architectural framework are defined
in MPLS-TP Framework [RFC 5921]. This document intent to provide the
use case studies and design considerations from practical point of
view based on Service Providers deployments plans and field
implementations.
The most common use cases for MPLS-TP include Metro access and As part of MPLS family, MPLS-TP complements existing IP/MPLS
aggregation, Mobile Backhaul, and Packet Optical Transport. MPLS-TP
data plane architecture, path protection mechanisms, and OAM
functionalities are used to support these deployment scenarios.
As part of MPLS family, MPLS-TP complements today's 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
use, MPLS-TP has emerged as the next generation transport technology
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) appear to be very attractive to many SPs. It streamlines
the operation, many help to reduce the overall complexity and the operation, reduces the overall complexity, and improves end-to-
improve end-to-end convergence. It leverages the MPLS experience, end convergence. It leverages the MPLS experience, and enhances the
and enhances the ability to support revenue generating services. ability to support revenue generating services.
The design considerations discussed in this document are generic.
While many design criteria are commonly apply to most of SPs, each
individual SP may place the importance of one aspect over another
MPLS-TP Use Case and Design Considerations
Expires December 2012
depending on the existing operational environment, what type of
applications need to be supported, the design objectives, the cost
constrain, and the network evolution plans.
1.2. Co-authors and contributors
Luyuan Fang, Cisco Systems
Nabil Bitar, Verizon
Raymond Zhang, Alcatel Lucent
Masahiro DAIKOKU, KDDI
Ping Pan, Infinera
Mach(Guoyi) Chen, Huawei Technologies
Dan Frost, Cisco Systems
Kam Lee Yap, XO Communications
Henry Yu, Time W Telecom
Jian Ping Zhang, China Telecom, Shanghai
Nurit Sprecher, Nokia Siemens Networks
Lei Wang, Telenor
2. Terminologies
AIS Alarm Indication Signal
APS Automatic Protection Switching
ATM Asynchronous Transfer Mode
BFD Bidirectional Forwarding Detection
CC Continuity Check
CE Customer Edge device
CV Connectivity Verification
CM Configuration Management
DM Packet delay measurement
ECMP Equal Cost Multi-path
FM Fault Management
GAL Generic Alert Label
G-ACH Generic Associated Channel
GMPLS Generalized Multi-Protocol Label Switching
LB Loopback
LDP Label Distribution Protocol
LM Packet loss measurement
LSP Label Switched Path
LT Link trace
MEP Maintenance End Point
MIP Maintenance Intermediate Point
MP2MP Multi-Point to Multi-Point connections
MPLS Multi-Protocol Label Switching
MPLS-TP MPLS transport profile
MPLS-TP Use Case and Design Considerations
Expires December 2012
OAM Operations, Administration, and Management
P2P Point to Multi-Point connections
P2MP Point to Point connections
PE Provider-Edge device
PHP Penultimate Hop Popping
PM Performance Management
PW Pseudowire
RDI Remote Defect Indication
RSVP-TE Resource Reservation Protocol with Traffic
Engineering Extensions
SLA Service Level Agreement
SNMP Simple Network Management Protocol
SONET Synchronous Optical Network
S-PE Switching Provider Edge
SRLG Shared Risk Link Group
SM-PW Multi-Segment PW
SS-PW Signle-Segment PW
TDM Time Division Multiplexing
TE Traffic Engineering
tLDP target LDP
TTL Time-To-Live
T-PE Terminating Provider Edge
VPN Virtual Private Network
3. Overview of MPLS-TP base functions
The section provides a summary view of MPLS-TP technology,
especially in comparison to the base IP/MPLS technologies. For
complete requirements and architecture definitions, please refer to
[RFC 5654] and [RFC 5921].
3.1. MPLS-TP development principles
The principles for MPLS-TP development are: meeting transport
requirements; maintain transport characteristics; re-using the
existing MPLS technologies wherever possible to avoid duplicate the
effort; ensuring consistency and inter-operability of MPLS-TP and
IP/MPLS networks; developing new tools as necessary to fully meet
transport requirements.
MPLS-TP Technologies include four major areas: Data Plane, Control
Plane, OAM, and Survivability. The short summary is provided below.
MPLS-TP Use Case and Design Considerations
Expires December 2012
3.2. Data Plane
MPLS-TP re-used MPLS and PW architecture; and MPLS forwarding
mechanism;
MPLS-TP extended the LSP support from unidirectional to both bi-
directional unidirectional support.
MPLS-TP defined PHP as optional, disallowed ECMP and MP2MP, only P2P
and P2MP are supported.
3.3. Control Plane
MPLS-TP allowed two control plane options:
Static: Using NMS for static provisioning; MPLS-TP is a subset of MPLS functions that meet the packet transport
Dynamic control plane for LSP: using GMPLS, OSPF-TE, RSVP-TE for requirements defined in [RFC5654]. This subset includes: MPLS data
full automation; forwarding, pseudo-wire encapsulation for circuit emulation, and
Dymanic control plane for PW: using tLDP. dynamic control plane using GMPLS control for LSP and tLDP for
ACH concept in PW is extended to G-ACh for MPLS-TP LSP to support pseudo-wire (PW). MPLS-TP also extends previous MPLS OAM functions,
in-band OAM. such as BFD extension for proactive Connectivity Check and
Connectivity Verification (CC-CV) [RFC6428], and Remote Defect
Indication (RDI) [RFC6428], LSP Ping Extension for on-demand CC-CV
[RFC6426], fault allocation, and remote integrity check. New tools
have been defined for alarm suppression with Alarm Indication Signal
(AIS) [RFC6427], and switch-over triggering with Link Defect
Indication (LDI). Note that since the MPLS OAM feature extensions
defined through the process of MPLS-TP development are part of the
Both Static and dynamic control plane options must allow control INTERNET DRAFT <Document Title> <Issue Date>
plane, data plane, management plane separation.
3.4. OAM MPLS family, the applicability is general to MPLS, and not limited to
MPLS-TP.
OAM received most attention in MPLS-TP development; Many OAM The requirements of MPLS-TP are provided in MPLS-TP Requirements [RFC
functions require protocol extensions or new development to meet the 5654], and the architectural framework is defined in MPLS-TP
transport requirements. Framework [RFC5921]. This document's intent is to provide the use
case studies and design considerations from a practical point of view
based on Service Providers deployments plans and actual deployments.
1) Continuity Check (CC), Continuity Verification (CV), and Remote The most common use cases for MPLS-TP include Metro access and
Integrity: aggregation, Mobile Backhaul, and Packet Optical Transport. MPLS-TP
- Proactive CC and CV: Extended BFD data plane architecture, path protection mechanisms, and OAM
- On demand CC and CV: Extended LSP Ping functionality are used to support these deployment scenarios.
- Proactive Remote Integrity: Extended BFD
- On demand Remote Integrity: Extended LSP Ping
2) Fault Management: The design considerations discussed in this documents include: role
- Fault Localization: Extended LSP Ping of MPLS-TP in the network; provisioning options; standards
- Alarm Suppression: created AIS compliance; end-to-end forwarding and OAM consistency; compatibility
- Remote Defect Indication (RDI): Extended BFD with existing IP/MPLS networks; and optimization vs. simplicity
- Lock reporting: Created Lock Instruct design trade-offs.
- Link defect Indication: Created LDI
- Static PW defect indication: Use Static PW status
MPLS-TP Use Case and Design Considerations
Expires December 2012
Performance Management: 2. Terminology
- Loss Management: Create MPLS-TP loss/delay measurement
- Delay Measurement: Create MPLS-TP loss/delay measurement
MPLS-TP OAM tool set overview can be found at [OAM Tool Set]. ## This document uses the terminology and architecture reference
defined in MPLS-TP Framework [RFC 5654] and MPLS-TP requirements
defined in [RFC 5921].
3.5. Survivability Term Definition
------ -----------------------------------------------
2G 2nd Generation Mobile network: GSM/CDMA
3G 3rd Generation Mobile network: UMTS/HSPA/1xEVDO
4G 4th Generation Mobile network: LTE
ADSL Asymmetric Digital Subscriber Line
AIS Alarm Indication Signal
ASNGW Access Service Network Gateway
ATM Asynchronous Transfer Mode
BFD Bidirectional Forwarding Detection
BTS Base Transceiver Station
CC-CV Continuity Check and Connectivity Verification
CDMA Code Division Multiple Access
E-LINE Ethernet point-to-point connectivity
E-LAN Ethernet LAN, provides multipoint connectivity
eNB Evolved Node B
E-VLAN Ethernet Virtual Private LAN
EVDO Evolution-Data Optimized
G-ACh Generic Associated Channel
GMPLS Generalized Multi-Protocol Label Switching
GSM Global System for Mobile Communications
HSPA High Speed Packet Access
- Deterministic path protection INTERNET DRAFT <Document Title> <Issue Date>
- Switch over within 50ms
- 1:1, 1+1, 1:N protection
- Linear protection
- Ring protection
- Shared Mesh Protection
MPLS transport Profile Survivability Framework [RFC 6372] provides IPTV Internet Protocol television
more details on the subject. L2VPN Layer 2 Virtual Private Network
L3VPN Layer 3 Virtual Private Network
LAN Local Access Network
LDI Link Down Indication
LDP Label Distribution Protocol
LSP Label Switched Path
LTE Long Term Evolution
MEP Maintenance End Point
MIP Maintenance Intermediate Point
NMS Network Management System
MPLS MultiProtocol Label Switching
MPLS-TP MultiProtocol Label Switching Transport Profile
MS-PW Multi-Segment Pseudowire
OAM Operations, Administration, and Management
OPEX Operating Expenses
PE Provider-Edge device
PSW Packet Data Network Gateway
RAN Radio Access Network
RDI Remote Defect Indication
SDH Synchronous Digital Hierarchy
SGW Serving Gateway
SLA Service Level Agreement
SONET Synchronous Optical Network
S-PE PW Switching Provider Edge
SP Service Provider
SRLG Shared Risk Link Groups
SS-PW Single-Segment Pseudowire
TDM Time Division Multiplexing
tLDP Targeted Label Distribution Protocol
VPN Virtual Private Network
UMTS Universal Mobile Telecommunications System
4. MPLS-TP Use Case Studies 3. MPLS-TP Use Cases
4.1. Metro Access and Aggregation 3.1. Metro Access and Aggregation
The most common deployment cases observed in the field upto today is The use of MPLS-TP for Metro access and aggregation transport is the
using MPLS-TP for Metro access and aggregation. Some SPs are most common deployment scenario observed in the field.
building green field access and aggregation infrastructure, while
others are upgrading/replacing the existing transport infrastructure
with new packet technologies such as MPLS-TP.
The access and aggregation networks today can be based on ATM, TDM,
MSTP, or Ethernet technologies as later development.
Some other SPs announced their plans for replacing their ATM or TDM Some operators are building green-field access and aggregation
aggregation networks with MPLS-TP technologies, simply because their transport infrastructure, while others are upgrading/replacing their
ATM / TDM aggregation networks are no longer suited to support the existing transport infrastructure with new packet technologies. The
rapid bandwidth growth, and they are expensive to maintain or may existing legacy access and aggregation networks are usually based on
also be and impossible expand due to End of Sale and End of Life TDM or ATM technologies. Some operators are replacing these networks
legacy equipments. Operators have to move forward with the next with MPLS-TP technologies, since legacy ATM/TDM aggregation and
generation packet technology, the adoption of MPLS-TP in access and access are becoming inadequate to support the rapid business growth
aggregation becomes a natural choice. The statistical muxing in and too expensive to maintain. In addition, in many cases the legacy
MPLS-TP helps to achieve higher efficiency comparing with the time
division scheme in the legacy technologies.
The unified MPLS strategy, using MPLS from core to aggregation and INTERNET DRAFT <Document Title> <Issue Date>
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
the operation, many help to reduce the overall complexity and
MPLS-TP Use Case and Design Considerations
Expires December 2012
improve end-to-end convergence. It leverages the MPLS experience, devices are facing End of Sale and End of Life issues. As operators
and enhances the ability to support revenue generating services. must move forward with the next generation packet technology, the
adoption of MPLS-TP in access and aggregation becomes a natural
choice. The statistical multiplexing in MPLS-TP helps to achieve
higher efficiency comparing with the time division scheme in the
legacy technologies. MPLS-TP OAM tools and protection mechanisms help
to maintain high reliability of transport network and achieve fast
recovery.
The current requirements from the SPs for ATM/TDM aggregation As most Service Providers core networks are MPLS enabled, extending
replacement often include maintaining the current operational model, the MPLS technology to the aggregation and access transport networks
with the similar user experience in NMS, supports current access with a Unified MPLS strategy is very attractive to many Service
network (e.g. Ethernet, ADSL, ATM, STM, etc.), support the Providers. Unified MPLS strategy in this document means having end-
connections with the core networks, support the same operational to-end MPLS technologies through core, aggregation, and access. It
feasibility even after migrating to MPLS-TP from ATM/TDM and reduces OPEX by streamlining operation and leveraging the operational
services (OCN, IP-VPN, E-VLAN, Dedicated line, etc.). MPLS-TP experience already gained with MPLS technologies; it also improves
currently defined in IETF are meeting these requirements to support network efficiency and reduces end-to-end convergence time.
a smooth transition.
The green field network deployment is targeting using the state of The requirements from the SPs for ATM/TDM aggregation replacement
art technology to build most stable, scalable, high quality, high often include: i) maintaining the previous operational model, which
efficiency networks to last for the next many years. IP/MPLS and means providing a similar user experience in NMS, ii) supporting the
MPLS-TP are both good choices, depending on the operational model. 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.
4.2. Packet Optical Transport 3.2. Packet Optical Transport
Many SP's transport networks consist of both packet and optical Many SP's transport networks consist of both packet and optical
portions. The transport operators are typically sensitive to network portions. The transport operators are typically sensitive to network
deployment cost and operation simplicity. MPLS-TP is therefore a deployment cost and operational simplicity. MPLS-TP supports both
natural fit in some of the transport networks, where the operators static provisioning through NMS and dynamic provisioning via the
can utilize the MPLS-TP LSP's (including the ones statically GMPLS control plane. As such, it is viewed as a natural fit in some
provisioned) to manage user traffic as "circuits" in both packet and of the transport networks, where the operators can utilize the MPLS-
optical networks. TP LSP's (including the ones statically provisioned) to manage user
Among other attributes, bandwidth management, protection/recovery traffic as "circuits" in both packet and optical networks, and when
and OAM are critical in Packet/Optical transport networks. In the they are ready, move to dynamic control plane for greater efficiency.
context of MPLS-TP, each LSP is expected to be associated with a
fixed amount of bandwidth in terms of bps and/or time-slots. OAM is
to be performed on each individual LSP. For some of performance
monitoring (PM) functions, the OAM mechanisms need to be able
transmit and process OAM packets at very high frequency, as low as
several msec's.
Protection is another important element in transport networks.
Typically, ring and linear protection can be readily applied in
metro networks. However, as long-haul networks are sensitive to
bandwidth cost and tend to have mesh-like topology, shared mesh
protection is becoming increasing important.
Packet optical deployment plans in some SPs cases are using MPLS-TP Among other attributes, bandwidth management, protection/recovery and
from long haul optical packet transport all the way to the OAM are critical in Packet/Optical transport networks. In the context
aggregation and access. of MPLS-TP, each LSP is expected to be associated with a fixed amount
of bandwidth in terms of bits-per-second and/or time-slots. OAM is to
be performed on each individual LSP. For some of the performance
monitoring (PM) functions, the OAM mechanisms need to be able to
transmit and process OAM packets at very high frequency. An overview
of MPLS-TP OAM toolset is found in [RFC6669].
MPLS-TP Use Case and Design Considerations INTERNET DRAFT <Document Title> <Issue Date>
Expires December 2012
4.3. Mobile Backhaul Protection [RFC6372] is another important element in transport
networks. Typically, ring and linear protection can be readily
applied in metro networks. However, as long-haul networks are
sensitive to bandwidth cost and tend to have mesh-like topology,
shared mesh protection is becoming increasingly important.
Wireless communication is one of the fastest growing areas in In some cases, SPs plan to deploy MPLS-TP from their long haul
communication world wide. For some regions, the tremendous rapid optical packet transport all the way to the aggregation and access in
mobile growth is fueled with lack of existing land-line and cable their networks.
infrastructure. For other regions, the introduction of Smart phones
quickly drove mobile data traffic to become the primary mobile
bandwidth consumer, some SPs have already seen 85% of total mobile
traffic are data traffic.
MPLS-TP has been viewed as a suitable technology for Mobile 3.3. Mobile Backhaul
backhaul.
4.3.1. 2G and 3G Mobile Backhaul Support Wireless communication is one of the fastest growing areas in
communication worldwide. In some regions, the tremendous mobile
growth is fueled by the lack of existing land-line and cable
infrastructure. In other regions, the introduction of smart phones is
quickly driving mobile data traffic to become the primary mobile
bandwidth consumer (some SPs have already observed more than 85% of
total mobile traffic are data traffic). MPLS-TP is viewed as a
suitable technology for Mobile backhaul.
MPLS-TP is commonly viewed as a very good fit for 2G)/3G Mobile 3.3.2. 2G and 3G Mobile Backhaul
backhaul.
2G (GSM/CDMA) and 3G (UMTS/HSPA/1xEVDO) Mobile Backhaul Networks are MPLS-TP is commonly viewed as a very good fit for 2G/3G Mobile
dominating mobile infrastructure today. backhaul. 2G (GSM/CDMA) and 3G (UMTS/HSPA/1xEVDO) Mobile Backhaul
Networks are still currently dominating the mobile infrastructure.
The connectivity for 2G/3G networks are Point to point. The logical The connectivity for 2G/3G networks is point to point (P2P). The
connections are hub-and-spoke. The physical construction of the logical connections are hub-and-spoke. Networks are physically
networks can be star topology or ring topology. In the Radio Access constructed using a star or ring topology. In the Radio Access
Network (RAN), each mobile base station (BTS/Node B) is Network (RAN), each mobile Base Transceiver Station (BTS/Node B) is
communicating with one Radio Controller (BSC/RNC) only. These communicating with a Radio Controller (BSC/RNC). These connections
connections are often statically set up. are often statically set up.
Hierarchical Aggregation Architecture / Centralized Architecture are Hierarchical or centralized architectures are often used for pre-
often used for pre-aggregation and aggregation layers. Each aggregation and aggregation layers. Each aggregation network inter-
aggregation networks inter-connects with multiple access networks. connects with multiple access networks. For example, a single
For example, single aggregation ring could aggregate traffic for 10 aggregation ring could aggregate traffic for 10 access rings with
access rings with total 100 base stations. total 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 SPs with great success. MPLS-TP is another suitable choice for Mobile
Mobile RAN. The P2P connection from base station to Radio Controller RAN. The P2P connections from base station to Radio Controller can be
can be set statically to mimic the operation today in many RAN set statically to mimic the operation of today's RAN environments;
environments, in-band OAM and deterministic path protection would in-band OAM and deterministic path protection can support fast
support the fast failure detection and switch over to satisfy the failure detection and switch-over to satisfy the SLA agreements.
SLA agreement. Bidirectional LSP may help to simplify the
provisioning process. The deterministic nature of MPLS-TP LSP set up
can also help packet based synchronization to maintain predictable
performance regarding packet delay and jitters.
MPLS-TP Use Case and Design Considerations INTERNET DRAFT <Document Title> <Issue Date>
Expires December 2012
4.3.2. LTE Mobile Backhaul Bidirectional LSPs may help to simplify the provisioning process. The
deterministic nature of MPLS-TP LSP set up can also support packet
based synchronization to maintain predictable performance regarding
packet delay and jitters.
One key difference between LTE and 2G/3G Mobile networks is that the 3.3.2. 4G/LTE Mobile Backhaul
logical connection in LTE is mesh while 2G/3G is P2P star
connections.
In LTE, the base stations eNB/BTS can communicate with multiple One key difference between LTE and 2G/3G Mobile networks is that the
Network controllers (PSW/SGW or ASNGW), and each Radio element can logical connection in LTE is a mesh, while in 2G/3G is a P2P star. In
communicate with each other for signal exchange and traffic offload LTE, the base stations eNB/BTS communicate with multiple Network
to wireless or Wireline infrastructures. controllers (PSW/SGW or ASNGW), and the radio elements communicate
with one another for signal exchange and traffic offload to wireless
or wireline infrastructures.
IP/MPLS may have a great advantage in any-to-any connectivity IP/MPLS has a great advantage in any-to-any connectivity environment.
environment. The use of mature IP or L3VPN technologies is Thus, the use of mature IP or L3VPN technologies is particularly
particularly common in the design of SP's LTE deployment plan. common in the design of SP's LTE deployment plans.
MPLS-TP can also bring advantages with the in-band OAM and path The extended OAM functions defined in MPLS-TP, such as in-band OAM
protection mechanism. MPLS-TP dynamic control-plane with GMPLS and path protection mechanisms bring additional advantages to support
signaling may bring additional advantages in the mesh environment SLAs. The dynamic control-plane with GMPLS signaling is especially
for real time adaptivities, dynamic topology changes, and network suited for the mesh environment, to support dynamic topology changes
optimization. and network optimization.
Since MPLS-TP is part of the MPLS family. Many component already 5. Network Design Considerations
shared by both IP/MPLS and MPLS-TP, the line can be further blurred
by sharing more common features. For example, it is desirable for
many SPs to introduce the in-band OAM developed for MPLS-TP back
into IP/MPLS networks as an enhanced OAM option. Today's MPLS PW can
also be set statically to be deterministic if preferred by the SPs
without going through full MPLS-TP deployment.
4.3.3. WiMAX Backhaul 5.1. The role of MPLS-TP
WiMAX Mobile backhaul shares the similar characteristics as LTE,
with mesh connections rather than P2P, star logical connections.
5. Network Design Considerations The role of MPLS-TP is to provide a solution to help evolving
traditional transport towards packet. It is designed to support the
transport characteristics/behavior described in [RFC5654]. The
primary use of MPLS-TP is largely to replace legacy transport
technologies, such as SONET/SDH. MPLS-TP is not designed to replace
the service support capabilities of IP/MPLS, such as L2VPN, L3VPN,
IPTV, Mobile RAN, etc.
5.1. IP/MPLS vs. MPLS-TP 5.2 Provisioning mode
Questions one might hear: I have just built a new IP/MPLS network to MPLS-TP supports two provisioning modes: i) a mandatory static
support multi-services, including L2/L3 VPNs, Internet service, provisioning mode, which must be supported without dependency on
IPTV, etc. Now there is new MPLS-TP development in IETF. Do I need dynamic routing or signaling; and ii) an optional distributed dynamic
to move onto MPLS-TP technology to state current with technologies? control plane, which is used to enable dynamic service provisioning.
MPLS-TP Use Case and Design Considerations
Expires December 2012
The answer is no. MPLS-TP is developed to meet the needs of The decision on which mode to use is largely dependent on the
traditional transport moving towards packet. It is designed to operational feasibility and the stage of evolution transition.
support the transport behavior coming with the long history. IP/MPLS Operators who are accustomed with the transport-centric operational
and MPLS-TP both are state of art technologies. IP/MPLS support both
transport (e.g. PW, RSVP-TE, etc.) and services (e.g L2/L3 VPNs,
IPTV, Mobile RAN, etc.), MPLS-TP provides transport only. The new
enhanced OAM features built in MPLS-TP should be share in both
flavors through future implementation.
Another common question: I need to evolve my ATM/TDM/SONET/SDH INTERNET DRAFT <Document Title> <Issue Date>
networks into new packet technologies, but my operational force is
largely legacy transport, not familiar with new data technologies,
and I want to maintain the same operational model for the time
being, what should I do? The answer would be: MPLS-TP may be the
best choice today for the transition.
A few important factors need to be considered for IP/MPLS or MPLS-TP model (e.g., NMS configuration without control plane) typically
include: prefer the static provisioning mode. This is the most common choice
in current deployments. The dynamic provisioning mode can be more
powerful but it is more suited for operators who are familiar with
the operation and maintenance of IP/MPLS technologies or ready to
step up through training and planned transition.
- Technology maturity (IP/MPLS is much more mature with 12 years There may be also cases where operators choose to use the combination
development) of both modes. This is appropriate when parts of the network are
- Operation experience (Work force experience, Union agreement, how provisioned in a static fashion and other parts are controlled by
easy to transition to a new technology? how much does it cost?) dynamic signaling. This combination may also be used to transition
- Needs for Multi-service support on the same node (MPLS-TP provide from static provisioning to dynamic control plane.
transport only, does not replace many functions of IP/MPLS)
- LTE, IPTV/Video distribution considerations (which path is the
most viable for reaching the end goal with minimal cost? but it also
meet the need of today's support)
5.2. Standards compliance 5.3. Standards compliance
It is generally recognized by SPs that standards compliance are It is generally recognized by SPs that standards compliance is
important for driving the cost down and product maturity up, multi- important for lowering cost, accelerating product maturity, achieving
vendor interoperability, also important to meet the expectation of multi-vendor interoperability, and meeting the expectations of their
the business customers of SP's. enterprise customers.
MPLS-TP is a joint work between IETF and ITU-T. In April 2008, IETF MPLS-TP is a joint work between IETF and ITU-T. In April 2008, IETF
and ITU-T jointly agreed to terminate T-MPLS and progress MPLS-TP as and ITU-T jointly agreed to terminate T-MPLS and progress MPLS-TP as
joint work [RFC 5317]. The transport requirements would be provided joint work [RFC5317]. The transport requirements are provided by ITU-
by ITU-T, the protocols would be developed in IETF. T, the protocols are developed in IETF.
Today, majority of the core set of MPLS-TP protocol definitions are
published as IETF RFCs already. It is important to deploy the
solutions based on the standards definitions, in order to ensure the
compatibility between MPLS-TP and IP/MPLS networks, and the
interoperability among different equipment by different vendors.
MPLS-TP Use Case and Design Considerations
Expires December 2012
Note that using non-standards, e.g. experimental code point is not
recommended practice, it bares the risk of code-point collision, as
indicated by [RFC 3692]: It can lead to interoperability problems
when the chosen value collides with a different usage, as it someday
surely will.
5.3. End-to-end MPLS OAM consistency
In the case Service Providers deploy end-to-end MPLS solution with
the combination of dynamic IP/MPLS and static or dynamic MPLS-TP
cross core, service edge, and aggregation/access networks, end-to-
end MPLS OAM consistency becomes an essential requirements from many
Service Provider. The end-to-end MPLS OAM can only be achieved
through implementation of IETF MPLS-TP OAM definitions.
5.4. PW Design considerations in MPLS-TP networks
In general, PW works the same as in IP/MPLS network, both SS-PW and
MS-PW are supported.
For dynamic control plane, tLDP is used. For static provisioning is
used, PW status is a new PW OAM feature for failure notification.
In addition, both directions of a PW must be bound to the same
transport bidirectional LSP.
When multi-tier rings involved in the network topology, should S-PE 5.4. End-to-end MPLS OAM consistency
be used or not? It is a design trade-off.
. Pros for using S-PE End-to-end MPLS OAM consistency is highly desirable in order to
. Domain isolation, may facilitate trouble shooting enable Service Providers to deploy end-to-end MPLS solution with a
. the PW failure recovery may be quicker combination of IP/MPLS (for example, in the core including service
. Cons for using S-PE edge) and MPLS-TP (for example, in the aggregation/access networks).
. Adds more complexity Using MPLS based OAM in MPLS-TP can help achieving such a goal.
. If the operation simplicity is the high priority, some
SPs choose not to use S-PE, simply forming longer path
across primary and secondary rings.
Should PW protection for the same end points be considered? It is 5.5. PW Design considerations in MPLS-TP networks
another design trade-off.
. Pros for using PW protection In general, PWs in MPLS-TP work the same as in IP/MPLS networks. Both
. PW is protected when both working and protect LSPs Single-Segment PW (SS-PW) and Multi-Segment PW (MS-PW) are supported.
carrying the working PW fails as long as the protection For dynamic control plane, Targeted LDP (tLDP) is used. In static
PW is following a diverse LSP path from the one provisioning mode, PW status is a new PW OAM feature for failure
carrying the working PW. notification. In addition, both directions of a PW must be bound to
the same transport bidirectional LSP.
MPLS-TP Use Case and Design Considerations In the common network topology involving multi-tier rings, the design
Expires December 2012 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
relevant here, since MPLS-TP is more sensitive to the operational
complexities, as noted by operators. If MS-PW is used, Switched PE
(S-PE) must be deployed to connect the rings. The advantage of this
. Cons for using PW protection INTERNET DRAFT <Document Title> <Issue Date>
. Adds more complexity, some may choose not to use if
protection against single point of failure is
sufficient.
5.5. Proactive and event driven MPLS-TP OAM tools choice is that it provides domain isolation, which in turn
facilitates trouble shooting and allows for faster PW failure
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
require S-PEs, but less efficient because the paths across primary
and secondary rings are longer. If operational simplicity is a higher
priority, some SPs choose the latter.
MPLS-TP provide both proactive tools and event drive OAM Tools. Another design trade-off is whether to use PW protection in addition
to LSP protection or rely solely on LSP protection. By definition,
MPLS-TP LSPs are protected. If the working LSP fails, the protect LSP
assures that the connectivity is maintained and the PW is not
impacted. However, in the case of simultaneous failure of both
working and protect LSPs, the attached PW would fail. By adding PW
protection, and attaching the protect PW to a diverse LSP not in the
same Shared Risk Link Group (SRLG), the PW is protected even when the
primary PW fails. Clearly, using PW protection adds considerably
more complexity and resource usage, and thus operators often may
choose not to use it, and consider protection against single point of
failure as sufficient.
E.g. in the proactive fashion, the BFD hellos can be sent every 3.3 5.6. Proactive and on-demand MPLS-TP OAM tools
ms as its lowest interval, 3 missed hellos would be trigger the
failure protection switch over. BFD sessions should be configured
for both working and protecting LSPs.
When Unidirectional Failure occurs, RDI will send the failure MPLS-TP provide both proactive and on-demand OAM Tools. As a
notification to the opposite direction to trigger both end switch proactive OAM fault management tool, BFD hellos can be sent at
over. regular intervals for Connectivity Check; 3 missed hellos trigger the
failure protection switch-over. BFD sessions are configured for both
working and protecting LSPs.
In the reactive fashion, when there is a fiber cut for example, LDI A design decision is choosing the value of the BFD hello interval.
message would be generated from the failure point and propagate to The shorter the interval (3.3ms is the minimum allowed interval), the
MEP to trigger immediate switch over from working to protect path. faster the detection time is, but also the higher the resource
And AIS would propagate from MIP to MEP for alarm suppression. utilization is. The proper value depends on the application and the
service needs.
Should both proactive and event driven OAM tools be used? The answer As an on-demand OAM fault management mechanism, for example when
is yes. there is a fiber cut, Link Down Indication (LDI) message [RFC6427] is
generated from the failure point and propagated to the Maintenance
End Points (MEPs) to trigger immediate switch-over from working to
protect path. An Alarm Indication Signal (AIS) propagates from the
Maintenance Intermediate Point (MIP) to the MEPs for alarm
suppression.
Should BFD timers be set as low as possible? It depends on the In general, both proactive and on-demand OAM tools should be enabled
applications. In many cases, it is not necessary. The lower the to guarantee short switch-over times.
times are, the faster the detection time, and also the higher
resource utilization. It is good to choose a balance point.
5.6. MPLS-TP and IP/MPLS Interworking considerations 5.7. MPLS-TP and IP/MPLS Interworking considerations
INTERNET DRAFT <Document Title> <Issue Date>
Since IP/MPLS is largely deployment in most networks, MPLS-TP and Since IP/MPLS is largely deployed in most SPs' networks, MPLS-TP and
IP/MPLS interworking is a reality. IP/MPLS interworking is a reality.
Typically, there is peer model and overlay model. The interworking issues are addressed in a separate document
[Interworking].
The inter-connection can be simply VLAN, or PW, or could be MPLS-TE.
A separate document is addressing the in the interworking issues,
please refer to the descriptions in [Interworking].
5.7. Delay and delay variation
MPLS-TP Use Case and Design Considerations
Expires December 2012
Background/motivation: Telecommunication Carriers plan to replace
the aging TDM Services (e.g. legacy VPN services) provided by Legacy
TDM technologies/equipments to new VPN services provided by MPLS-TP
technologies/equipments with minimal cost. The Carriers cannot allow
any degradation of service quality, service operation Level, and
service availability when migrating out of Legacy TDM
technologies/equipments to MPLS-TP transport. The requirements from
the customers of these carriers are the same before and after the
migration.
5.7.1. Network Delay
From our recent observation, more and more Ethernet VPN customers
becoming very sensitive to the network delay issues, especially the
financial customers. Many of those customers has upgraded their
systems in their Data Centers, e.g., their accounting systems. Some
of the customers built the special tuned up networks, i.e. Fiber
channel networks, in their Data Centers, this tripped more strict
delay requirements to the carriers.
There are three types of network delay:
1. Absolute Delay Time
Absolute Delay Time here is the network delay within SLA contract.
It means the customers have already accepted the value of the
Absolute Delay Time as part of the contract before the Private Line
Service is provisioned.
2. Variation of Absolute Delay Time (without network configuration
changes).
The variation under discussion here is mainly induced by the
buffering in network elements.
Although there is no description of Variation of Absolute Delay Time
on the contract, this has no practical impact on the customers who
contract for the highest quality of services available. The
bandwidth is guaranteed for those customers' traffic.
3. Relative Delay Time
Relative Delay Time is the difference of the Absolute Delay Time
between using working and protect path.
MPLS-TP Use Case and Design Considerations
Expires December 2012
Ideally, Carriers would prefer the Relative Delay Time to be zero,
for the following technical reasons and network operation
feasibility concerns.
The following are the three technical reasons:
Legacy throughput issue
In the case that Relative Delay Time is increased between FC
networks or TCP networks, the effective throughput is degraded. The
effective throughput, though it may be recovered after revert back
to the original working path in revertive mode.
On the other hand, in that case that Relative Delay Time is
decreased between FC networks or TCP networks, buffering over flow
may occur at receiving end due to receiving large number of busty
packets. As a consequence, effective throughput is degraded as
well. Moreover, if packet reordering is occurred due to RTT
decrease, unnecessary packet resending is induced and effective
throughput is also further degraded. Therefore, management of
Relative Delay Time is preferred, although this is known as the
legacy TCP throughput issue.
Locating Network Acceralators at CE
In order to improve effective throughput between customer's FC
networks over Ethernet private line service, some customer put "WAN
Accelerator" to increase throughput value. For example, some WAN
Accelerators at receiving side may automatically send back "R_RDY"
in order to avoid decreasing a number of BBcredit at sending side,
and the other WAN Accelerators at sending side may have huge number
of initial BB credit.
When customer tunes up their CE by locating WAN Accelerator, for
example, when Relative Delay Time is changes, there is a possibility
that effective throughput is degraded. This is because a lot of
packet destruction may be occurred due to loss of synchronization,
when change of Relative delay time induces packet reordering. And,
it is difficult to re-tune up their CE network element automatically
when Relative Delay Time is changed, because only less than 50 ms
network down detected at CE.
Depending on the tuning up method, since Relative Delay Time affects
effective throughput between customer's FC networks, management of
Relative Delay Time is preferred.
c) Use of synchronized replication system
MPLS-TP Use Case and Design Considerations
Expires December 2012
Some strict customers, e.g. financial customers, implement
"synchronized replication system" for all data back-up and load
sharing. Due to synchronized replication system, next data
processing is conducted only after finishing the data saving to both
primary and replication DC storage. And some tuning function could
be applied at Server Network to increase throughput to the
replication DC and Client Network. Since Relative Delay Time affects
effective throughput, management of Relative Delay Time is
preferred.
The following are the network operational feasibility issues.
Some strict customers, e.g., financial customer, continuously
checked the private line connectivity and absolute delay time at
CEs. When the absolute delay time is changed, that is Relative
delay time is increased or decreased, the customer would complain.
From network operational point of view, carrier want to minimize the
number of customers complains, MPLS-TP LSP provisioning with zero
Relative delay time is preferred and management of Relative Delay
Time is preferred.
Obviously, when the Relative Delay Time is increased, the customer
would complain about the longer delay. When the Relative Delay Time
is decreased, the customer expects to keep the lesser Absolute Delay
Time condition and would complain why Carrier did not provide the
best solution in the first place. Therefore, MPLS-TP LSP
provisioning with zero Relative Delay Time is preferred and
management of Relative Delay Time is preferred.
More discussion will be added on how to manage the Relative delay
time.
5.8. More on MPLS-TP Deployment Considerations 6. Security Considerations
5.8.1. Network Modes Selection In the use case of Metro access and aggregation, in the scenario
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
over the control plane option because it eliminates the possibility
of a control plane attack which may potentially impact the whole
network.
When considering deployment of MPLS-TP in the network, possibly Similar location issues apply to the mobile use cases, since
couple of questions will come into mind, for example, where should equipment is often placed in remote and outdoor environment, which
the MPLS-TP be deployed? (e.g., access, aggregation or core can increase the risk of un-authorized access to the equipment.
network?) Should IP/MPLS be deployed with MPLS-TP simultaneously? If
MPLS-TP and IP/MPLS is deployed in the same network, what is the
relationship between MPLS-TP and IP/MPLS (e.g., peer or overlay?)
and where is the demarcation between MPLS-TP domain and IP/MPLS
MPLS-TP Use Case and Design Considerations
Expires December 2012
domain? The results for these questions depend on the real In general, NMS access can be a common point of attack in all MPLS-TP
requirements on how MPLS-TP and IP/MPLS are used to provide use cases. General security considerations for MPLS and GMPLS
services. For different services, there could be different choice. networks are addressed in Security Framework for MPLS and GMPLS
According to the combination of MPLS-TP and IP/MPLS, here are some Networks [RFC5920]. General MPLS-TP security considerations are
typical network modes: described in MPLS-TP Security Framework [MPLS-TP Sec FW].
Pure MPLS-TP as the transport connectivity (E2E MPLS-TP), this 7. IANA Considerations
situation more happens when the network is a totally new constructed
network. For example, a new constructed packet transport network for
Mobile Backhaul, or migration from ATM/TDM transport network to
packet based transport network.
Pure IP/MPLS as transport connectivity (E2E IP/MPLS), this is the This document contains no new IANA considerations.
current practice for many deployed networks.
MPLS-TP combines with IP/MPLS as the transport connectivity (Hybrid
mode).
Peer mode: some domains adopt MPLS-TP as the transport connectivity; 8. Acknowledgements
other domains adopt IP/MPLS as the transport connectivity. MPLS-TP
domains and IP/MPLS domains are interconnected to provide transport
connectivity. Considering there are a lot of IP/MPLS deployments in
the field, this mode may be the normal practice in the early stage
of MPLS-TP deployment.
Overlay mode: The authors wish to thank Adrian Farrel for his review as Routing
b-1: MPLS-TP as client of IP/MPLS, this is for the case where MPLS- Area Director, Adrian's detailed comments were of great help for
TP domains are distributed and IP/MPLS do-main/network is used for improving the quality of this document. The authors would also like
the connection of the distributed MPLS-TP domains. For examples, to thank Loa Andersson for his continued support and guidance.
there are some service providers who have no their own Backhaul
network, they have to rent the Backhaul network that is IP/MPLS
based from other service providers.
b-2: IP/MPLS as client of MPLS-TP, this is for the case where 9. References
transport network below the IP/MPLS network is a MPLS-TP based
network, the MPLS-TP network provides transport connectivity for the
IP/MPLS routers, the usage is analogous as today's ATM/TDM/SDH based
transport network that are used for providing connectivity for
IP/MPLS routers.
5.8.2. Provisioning Modes Selection 9.1 Normative References
As stated in MPLS-TP requirements [RFC 5654], MPLS-TP network MUST [RFC5317] Bryant, S., Ed., and L. Andersson, Ed., "Joint Working
be possible to work without using Control Plane. And this does not Team (JWT) Report on MPLS Architectural Considerations for
mean that MPLS-TP network has no control plane. Instead, operators a Transport Profile", RFC 5317, February 2009.
could deploy their MPLS-TP with static provisioning (e.g., CLI, NMS
etc.), dynamic control plane signaling (e.g., OSPF-TE/ISIS-TE,
GMPLS, LDP, RSVP-TE etc.), or combination of static and dynamic
provisioning (Hybrid mode). Each mode has its own pros and cons and
how to determine the right mode for a specific network mainly
MPLS-TP Use Case and Design Considerations
Expires December 2012
depends on the operators' preference. For the operators who are used [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
to operate traditional transport network and familiar with the Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport-Centric operational model (e.g., NMS configuration without Transport Profile", RFC 5654, September 2009.
control plane) may prefer static provisioning mode. The dynamic
provisioning mode is more suitable for the operators who are
familiar with the operation and maintenance of IP/MPLS network where
a fully dynamic control plane is used. The hybrid mode may be used
when parts of the network are provisioned with static way and the
other parts are controlled by dynamic signaling. For example, for
big SP, the network is operated and maintained by several different
departments who prefer to different modes, thus they could adopt
this hybrid mode to support both static and dynamic modes hence to
satisfy different requirements. Another example is that static
provisioning mode is suitable for some parts of the network and
dynamic provisioning mode is suitable for other parts of the
networks (e.g., static for access network, dynamic for metro
aggregate and core network).
6. Security Considerations INTERNET DRAFT <Document Title> <Issue Date>
General security considerations for MPLS and GMPLS networks are [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
addressed in Security Framework for MPLS and GMPLS Networks[RFC 5920]. Networks", RFC 5920, July 2010.
General MPLS-TP security considerations are described in MPLS-TP
Security Framework [MPLS-TP Sec FW]. No new security issues in this
document.
7. IANA Considerations [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
On-Demand Connectivity Verification and Route Tracing",
RFC 6426, November 2011.
This document contains no new IANA considerations. [RFC6427] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed.,
Boutros, S., and D. Ward, "MPLS Fault Management
Operations, Administration, and Maintenance (OAM)",
RFC 6427, November 2011.
8. Normative References [RFC6428] Allan, D., Ed., Swallow Ed., G., and J. Drake Ed.,
"Proactive Connectivity Verification, Continuity Check,
and Remote Defect Indication for the MPLS Transport
Profile", RFC 6428, November 2011.
[RFC 5317]: Joint Working Team (JWT) Report on MPLS Architectural 9.2 Informative References
Considerations for a Transport Profile, Feb. 2009.
[RFC 5654], Niven-Jenkins, B., et al, "MPLS-TP Requirements," RFC [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
5654, September 2009. L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, July 2010.
9. Informative References [RFC6372] Sprecher, N., Ed., and A. Farrel, Ed., "MPLS Transport
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Profile (MPLS-TP) Survivability Framework", RFC 6372,
Requirement Levels", BCP 14, RFC 2119, March 1997. September 2011.
[RFC 3692] T. Narten, "Assigning Experimental and Testing Numbers [RFC6669] Sprecher, N. and L. Fang, "An Overview of the Operations,
Considered Useful", RFC 3692, Jan. 2004. Administration, and Maintenance (OAM) Toolset for MPLS-
Based Transport Networks", RFC 6669, July 2012.
[RFC 5921] Bocci, M., ED., Bryant, S., ED., et al., Frost, D. ED., [Interworking] Martinotti, R., et al., "Interworking between MPLS-
Levrau, L., Berger., L., "A Framework for MPLS in Transport," July TP and IP/MPLS," draft-martinotti-mpls-tp-interworking-02.txt, June
2010. 2011.
MPLS-TP Use Case and Design Considerations [MPLS-TP Sec FW] Fang, L. ED., et al., "MPLS-TP Security Framework,"
Expires December 2012 draft-ietf-mpls-tp-security-framework-05.txt, October 2012.
[RFC 5920] Fang, L., ED., et al, "Security Framework for MPLS and Authors' Addresses
GMPLS Networks," July 2010.
[RFC 6372] Sprecher, N., Ferrel, A., MPLS transport Profile Luyuan Fang
Survivability Framework [RFC 6372], September 2011. Cisco Systems, Inc.
111 Wood Ave. South
Iselin, NJ 08830
United States
Email: lufang@cisco.com
[OAM Tool Set] Sprecher, N., Fang, L., "An Overview of the OAM Tool INTERNET DRAFT <Document Title> <Issue Date>
Set for MPLS Based Transport Networks,", draft-ietf-mpls-to-oam-
analysis-09.txt, April 2012, work in progress.
[Interworking] Martinotti, R., et al., "Interworking between MPLS-TP Nabil Bitar
and IP/MPLS," draft-martinotti-mpls-tp-interworking-02.txt, June Verizon
2011. 40 Sylvan Road
Waltham, MA 02145
United States
Email: nabil.bitar@verizon.com
[MPLS-TP Sec FW] Fang, L. ED., et al., "MPLS-TP Security Framework," Raymond Zhang
draft-ietf-mpls-tp-security-framework-03.txt, March 2012. Alcatel-Lucent
701 Middlefield Road
Mountain View, CA 94043
United States
Email: raymond.zhang@alcatel-lucent.com
10. Author's Addresses Masahiro DAIKOKU
KDDI corporation
3-11-11.Iidabashi, Chiyodaku, Tokyo
Japan
Email: ms-daikoku@kddi.com
Luyuan Fang Ping Pan
Cisco Systems, Inc. Infinera
111 Wood Ave. South United States
Iselin, NJ 08830 Email: ppan@infinera.com
USA
Email: lufang@cisco.com
Nabil Bitar Contributors' Address
Verizon
40 Sylvan Road
Waltham, MA 02145
USA
Email: nabil.bitar@verizon.com
Raymond Zhang Kam Lee Yap
Alcatel-Lucent XO Communications
701 Middlefield Road 13865 Sunrise Valley Drive,
Mountain View, CA 94043 Herndon, VA 20171
Email: raymond.zhang@alcatel-lucent.com United States
Email: klyap@xo.com
Masahiro DAIKOKU Dan Frost
KDDI corporation Cisco Systems, Inc.
3-11-11.Iidabashi, Chiyodaku, Tokyo United Kingdom
Japan Email:danfrost@cisco.com
Email: ms-daikoku@kddi.com
MPLS-TP Use Case and Design Considerations
Expires December 2012
Kam Lee Yap Henry Yu
XO Communications TW Telecom
13865 Sunrise Valley Drive, 10475 Park Meadow Dr.
Herndon, VA 20171 Littleton, CO 80124
Email: klyap@xo.com United States
Email: henry.yu@twtelecom.com
Dan Frost Jian Ping Zhang China Telecom, Shanghai
Cisco Systems, Inc. Room 3402, 211 Shi Ji Da Dao
Email:danfrost@cisco.com
Henry Yu INTERNET DRAFT <Document Title> <Issue Date>
TW Telecom
10475 Park Meadow Dr.
Littleton, CO 80124
Email: henry.yu@twtelecom.com
Jian Ping Zhang China Telecom, Shanghai Pu Dong District, Shanghai
Room 3402, 211 Shi Ji Da Dao China
Pu Dong District, Shanghai Email: zhangjp@shtel.com.cn
China Email: zhangjp@shtel.com.cn
Lei Wang Lei Wang
Telenor Lime Networks
Telenor Norway Strandveien 30, 1366 Lysaker
Office Snaroyveien Norway
1331 Fornedbu Email: lei.wang@limenetworks.no
Email: Lai.wang@telenor.com
Mach(Guoyi) Chen Mach(Guoyi) Chen
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
No. 3 Xinxi Road No. 3 Xinxi Road
Shangdi Information Industry Base Shangdi Information Industry Base
Hai-Dian District, Beijing 100085 Hai-Dian District, Beijing 100085
China China
Email: mach@huawei.com Email: mach@huawei.com
Nurit Sprecher Nurit Sprecher
Nokia Siemens Networks Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B 3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241 Hod Hasharon, 45241
Israel Israel
Email: nurit.sprecher@nsn.com Email: nurit.sprecher@nsn.com
 End of changes. 126 change blocks. 
848 lines changed or deleted 511 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/