Network Working Group Luyuan Fang
Internet Draft Cisco Systems
Intended status: Informational Nabil Bitar
Expires: January 5, 2011 Verizon
Raymond Zhang
BT
Masa DAIKOKU
KDDI
July 5, 2010
MPLS-TP Use Cases Studies and Design Considerations
draft-fang-mpls-tp-use-cases-and-design-00.txt
Abstract
This document provides use case studies and network design
considerations for Multiprotocol Label Switching Transport Profile
(MPLS-TP).
In the recent years, MPLS-TP has emerged as the technology of
choice to meet the needs of transport evolution. Many service
providers (SPs) intend to replace SONET/SDH, TDM, ATM traditional
transport technologies with MPLS-TP, to achieve higher efficiency,
low operational cost, while maintaining transport characteristics.
The use cases for MPLS-TP include Mobile backhaul, Metro Ethernet
access and aggregation, packet optical transport. The design
considerations include operational experience, standards
compliance, technology maturity, end-to-end design and OAM
consistency, compatibility with IP/MPLS networks, and multi-vendor
interoperability. The goal is to provide reliable, manageable, and
scalable transport solutions.
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
and access) appear to be very attractive for many SPs. It
streamlines the operation, reduce the overall complexity and
convergence issues, leveraging MPLS experience, and improve the
ability to support revenue generating services.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
[Page 1]
MPLS-TP Use Cases Studies and Design Considerations July 2010
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 5, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction..................................................3
1.1. Background and Motivation..................................3
[Page 2]
MPLS-TP Use Cases Studies and Design Considerations July 2010
1.2. Contributing authors.......................................5
2. Terminologies.................................................5
3. Overview of MPLS-TP base functions............................6
3.1. MPLS-TP development principles.............................6
3.2. Data Plane.................................................6
3.3. Control Plane..............................................6
3.4. OAM........................................................7
3.5. Survivability..............................................7
4. MPLS-TP Use Case Studies......................................7
4.1. Mobile Backhaul............................................7
4.2. Metro Access and Aggregation...............................9
4.3. Packet Optical Transport..................................10
5. Network Design Considerations................................10
5.1. IP/MPLS vs. MPLS-TP.......................................10
5.2. Standards compliance......................................11
5.3. General network design considerations.....................11
6. Security Considerations......................................12
7. IANA Considerations..........................................12
8. Normative References.........................................12
9. Informative References.......................................12
10. Author's Addresses..........................................12
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
1.1. Background and Motivation
This document provides case studies and network design
considerations for Multiprotocol Label Switching Transport Profile
(MPLS-TP).
In recent years, the urgency for moving from traditional transport
technologies such as SONET/SDH, TDM/ATM to new packet technologies
has been rising. This is largely due to the tremendous success of
data services, such as IPTV and IP Video for content downloading,
streaming, and sharing; rapid growth of mobile services, especially
[Page 3]
MPLS-TP Use Cases Studies and Design Considerations July 2010
smart phone applications; business VPNs and residential broadband.
Continued network convergence effort is another contributing factor
for transport moving toward packet technologies. After several
years of heated debate, MPLS-TP has emerged as the next generation
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 control plane
option; 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 [MPLS-TP FW]. 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 Mobile Backhaul,
Metro Ethernet access and aggregation, 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 aggregation transport to provide end-to-end solutions in
a cost efficient, reliable, and interoperable manner.
The design considerations discussed here are generic. Many design
criteria are common, while individual SP may place the importance
of one aspect over another depending on the existing operational
environment, the applications need to be supported, the design
philosophy, and the expected duration of the network to be in
service.
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
and access) appear to be very attractive for many SPs. It streamlines
[Page 4]
MPLS-TP Use Cases Studies and Design Considerations July 2010
the operation, reduce the overall complexity and convergence
issues, leveraging MPLS experience, and improve the ability to
support revenue generating services.
1.2. Contributing authors
Luyuan Fang, Cisco Systems
Nabil Bitar, Verizon
Raymond Zhang, BT
Masa DAIKOKU, KDDI
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
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
[Page 5]
MPLS-TP Use Cases Studies and Design Considerations July 2010
SNMP Simple Network Management Protocol
SONET Synchronous Optical Network
S-PE Switching Provider Edge
SRLG Shared Risk Link Group
TDM Time Division Multiplexing
TE Traffic Engineering
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 [MPLS-TP FW].
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.
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 allowed.
3.3. Control Plane
MPLS-TP allowed two control plane options:
[Page 6]
MPLS-TP Use Cases Studies and Design Considerations July 2010
1) Static: Using NMS for static provisioning;
2) Dynamic Control Plane using GMPLS, OSPF-TE, RSVP-TE for full
automation
3) ACH concept in PW is extended to GACH for MPLS-TP LSP to support
in-band OAM.
Both Static and dynamic control plane options must allow control
plane and data plane separation.
3.4. OAM
OAM received most attention in MPLS-TP development; Many OAM
functions require protocol extensions or new development to meet
the transport requirements.
1) Continuity Check (CC), Continuity Verification (CV), and
Remote Integrity:
- Proactive CC and CV: Extended BFD
- On demand CC and CV: Extended LSP Ping
- Proactive Remote Integrity: Extended BFD
- On demand Remote Integrity: Extended LSP Ping
2) Fault Management:
- Fault Localization: Extended LSP Ping
- Alarm Suppression: create AIS
- Remote Defect Indication (RDI): Extended BFD
- Lock reporting: Create Lock Instruct
- Link defect Indication: Create LDI
- Static PW defect indication: Use Static PW status
3) Performance Management:
- Loss Management: Create MPLS-TP loss/delay measurement
- Delay Measurement: Create MPLS-TP loss/delay measurement
3.5. Survivability
- Deterministic path protection
- Switch over within 50ms
- 1:1, 1+1, 1:N protection
- Linear protection
- Ring protection
4. MPLS-TP Use Case Studies
4.1. Mobile Backhaul
[Page 7]
MPLS-TP Use Cases Studies and Design Considerations July 2010
Mobility is one of the fastest growing areas in communication world
wide. For some regions, the tremendous rapid mobile growth is
fueled with lack of existing land-line and cable 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
backhaul.
4.1.1. 2G and 3G Mobile Backhaul Support
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 Networks are
dominating mobile infrastructure today.
The connectivity for 2G/3G networks are Point to point. The logical
connections are hub-and-spoke. The physical construction of the
networks can be star topology or ring topology. In the Radio Access
Network (RAN), each mobile base station (BTS/Node B) is
communicating with one Radio Controller (BSC/RNC) only. These
connections are often statically set up.
Hierarchical Aggregation Architecture / Centralized Architecture are
often used for pre-aggregation and aggregation layers. Each
aggregation networks inter-connects with multiple access networks.
For example, single aggregation ring could aggregate traffic for 10
access rings with total 100 base stations.
The technology used today is largely ATM based. Mobile providers are
replacing the ATM RAN infrastructure with newer packet technologies.
IP RAN networks with IP/MPLS technologies are deployed today by many
SPs with great success. MPLS-TP is another suitable choice for
Mobile RAN. The P2P connection from base station to Radio Controller
can be set statically to mimic the operation today in many RAN
environments, in-band OAM and deterministic path protection would
support the fast failure detection and switch over to satisfy the
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.
4.1.2. LTE Mobile Backhaul
[Page 8]
MPLS-TP Use Cases Studies and Design Considerations July 2010
One key difference between LTE and 2G/3G Mobile networks is that the
logical connection in LTE is mesh while 2G/3G is P2P star
connections.
In LTE, the base stations eNB/BTS can communicate with multiple
Network controllers (PSW/SGW or ASNGW), and each Radio element can
communicate with each other for signal exchange and traffic offload
to wireless or Wireline infrastructures.
IP/MPLS may have a great advantage in any-to-any connectivity
environment. The use of mature IP or L3VPN technologies is
particularly common in the design of SP's LTE deployment plan.
MPLS-TP can also bring advantages with the in-band OAM and path
protection mechanism. MPLS-TP dynamic control-plane with GMPLS
signaling may bring additional advantages in the mesh environment
for real time adaptivities, dynamic topology changes, and network
optimization.
Since MPLS-TP is part of the MPLS family. Many component already
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.1.3. WiMAX Backhaul
WiMAX Mobile backhaul shares the similar characteristics as LTE,
with mesh connections rather than P2P, star logical connections.
4.2. Metro Access and Aggregation
Some SPs are building new Access and aggregation infrastructure,
while others plan to upgrade/replace of existing transport
infrastructure with new packet technologies such as MPLS_TP. The
later is of course more common than the former.
The access and aggregation networks today can be based on ATM, TDM,
MSTP, or Ethernet technologies as later development.
Some SPs announced their plans for replacing their ATM or TDM
aggregation networks with MPLS-TP technologies, because the ATM /
TDM aggregation networks are no longer suited to support the rapid
bandwidth growth, and they are expensive to maintain or may also be
and impossible expand due to End of Sale and End of Line legacy
equipments. The statistical muxing in MPLS-TP helps to achieve
[Page 9]
MPLS-TP Use Cases Studies and Design Considerations July 2010
higher efficiency comparing with the time division scheme in the
legacy technologies.
The unified MPLS strategy, e.g. IP/MPLS in the core, IP/MPLS or
MPLS-TP in aggregation and access appear to be attractive for many
SPs. It streamlines the operation, reduce the overall complexity
and convergence issues, leveraging MPLS experience, and improve the
ability to support revenue generating higher layer services.
The current requirements from the SPs for ATM/TDM aggregation
replacement often include maintaining the current operational
model, with the similar user experience in NMS, supports current
access network (e.g. Ethernet, ADSL, ATM, STM, etc.), support the
connections with the core networks and services (OCN, IP-VPN, E-
VLAN, Dedicated line, etc.). MPLS-TP currently defined in IETF are
meeting these requirements to support a smooth transition.
The green field network deployment is targeting using the state of
art technology to build most stable, scalable, high quality, high
efficiency networks to last for the next many years. IP/MPLS and
MPLS-TP are both good choices, depending on the operational model.
4.3. Packet Optical Transport
(to be added)
5. Network Design Considerations
5.1. IP/MPLS vs. MPLS-TP
Questions we often hear: I have just built a new IP/MPLS network to
support multi-services, including L2/L3 VPNs, Internet service,
IPTV, etc. Now there is new MPLS-TP development in IETF. Do I need
to move onto MPLS-TP technology to state current with technologies?
The answer is no generally speaking. MPLS-TP is developed to meet
the needs of traditional transport moving towards packet. It is
geared to support the transport behavior coming with the long
history. IP MPLS 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 question: I need to evolve my ATM/TDM/SONET/SDH 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,
[Page 10]
MPLS-TP Use Cases Studies and Design Considerations July 2010
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 include:
- Technology maturity (IP/MPLS is much more mature with 12
years development)
- Operation experience (Work force experience, Union agreement,
how easy to transition to a new technology? how much does it
cost?)
- Needs for Multi-service support on the same node (MPLS-TP
provide 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
It is generally recognized by SPs that standards compliance are
important for driving the cost down and product maturity up, multi-
vendor interoperability, also important to meet the expectation of
the business customers of SP's.
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 joint work [RFC 5317]. The transport requirements would be
provided by ITU-T, the protocols would be developed in IETF.
T-MPLS is not MPLS-TP. T-MPLS solution would not inter-op with
IP/MPLS, it would not be compatible with MPLS-TP defined in IETF.
5.3. General network design considerations
-
- Migration considerations
- Resilency
- Scalability
- Performance
Design considerations for Delay / loss measurement
It is viewed as very important for some SPs that the working path
and protect path share similar delay measurement. It is critical
for certain financial applications.
This draft is work in progress, more would be filled in the
following revision.
[Page 11]
MPLS-TP Use Cases Studies and Design Considerations July 2010
6. Security Considerations
Reference to [MPLS/GMPLS SEC FW].
7. IANA Considerations
This document contains no new IANA considerations.
8. Normative References
[RFC 5317]: Joint Working Team (JWT) Report on MPLS Architectural
Considerations for a Transport Profile, Feb. 2009.
[RFC 5654], Niven-Jenkins, B., et al, "MPLS-TP Requirements", RFC
5654, September 2009.
(More to be added)
9. Informative References
[MPLS-TP FW] Bocci, M., Bryant, et al., "A Framework for MPLS in
Transport Networks", draft-ietf-mpls-tp-framework-12 (work in
progress), June 2010.
[MPLS/GMPLS SEC FW] L. Fang, et al, Security Framework for MPLS and
GMPLS Networks, draft-ietf-mpls-mpls-and-gmpls-security-framework-
09.txt, March 2010.
(More to be added)
10. Author's Addresses
Luyuan Fang
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA 01719
USA
Email: lufang@cisco.com
Nabil Bitar
Verizon
40 Sylvan Road
[Page 12]
MPLS-TP Use Cases Studies and Design Considerations July 2010
Waltham, MA 02145
USA
Email: nabil.bitar@verizon.com
Raymond Zhang
British Telecom
BT Center
81 Newgate Street
London, EC1A 7AJ
United Kingdom
Email: raymond.zhang@bt.com
Masahiro DAIKOKU
KDDI corporation
Japan
Email: ms-daikoku@kddi.com
[Page 13]
