MPLS-TP Applicability; Use Cases and Design
draft-ietf-mpls-tp-use-cases-and-design-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 6965.
|
|
|---|---|---|---|
| Authors | Luyuan Fang , Dr. Nabil N. Bitar , Raymond Zhang | ||
| Last updated | 2011-12-20 (Latest revision 2011-12-19) | ||
| Replaces | draft-fang-mpls-tp-use-cases-and-design | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 6965 (Informational) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-mpls-tp-use-cases-and-design-01
Network Working Group L. Fang, Ed.
Internet Draft Cisco Systems
Intended status: Informational N. Bitar
Expires: June 20, 2012 Verizon
R. Zhang
Alcatel Lucent
M. DAIKOKU
KDDI
P. Pan
Infinera
December 20, 2011
MPLS-TP Applicability; Use Cases and Design
draft-ietf-mpls-tp-use-cases-and-design-01.txt
Abstract
This document provides applicability, 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
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
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
[Page 1]
MPLS-TP Use Case and Design Considerations
Expires June 2012
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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.
This Internet-Draft will expire on June 18, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(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
3
1.1. Background and Motivation ...................................3
3
1.2. Co-authors and contributors .................................3
5
2. Terminologies ..................................................5
5
3. Overview of MPLS-TP base functions .............................6
6
3.1. MPLS-TP development principles ..............................6
6
3.2. Data Plane ..................................................7
7
3.3. Control Plane ...............................................7
7
3.4. OAM .........................................................7
7
3.5. Survivability ...............................................8
8
4. MPLS-TP Use Case Studies .......................................8
8
4.1. Metro Access and Aggregation ...............................8
8
[Page 2]
MPLS-TP Use Case and Design Considerations
Expires June 2012
4.2. Packet Optical Transport ....................................9
9
4.3. Mobile Backhaul ............................................10
10
5. Network Design Considerations .................................11
11
5.1. IP/MPLS vs. MPLS-TP ........................................11
11
5.2. Standards compliance .......................................11
12
5.3. End-to-end MPLS OAM consistency ............................12
13
5.4. PW Design considerations in MPLS-TP networks ...............13
13
5.5. Proactive and event driven MPLS-TP OAM tools ...............13
14
5.6. MPLS-TP and IP/MPLS Interworking considerations ............14
14
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
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
smart phone applications; the continued growth of business VPNs and
residential broadband. The end of live for many legacy TDM devices
and the continuing network convergence effort are also key
contributing factors for transport moving toward packet
[Page 3]
MPLS-TP Use Case and Design Considerations
Expires June 2012
technologies. After several years of heated debate on which packet
technology to use, 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 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
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
aggregation transport to enable end-to-end packet technology
solutions in a cost efficient, reliable, and interoperable manner.
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 to many SPs. It streamlines
the operation, many help to reduce the overall complexity and
improve end-to-end convergence. It leverages the MPLS experience,
and enhances the 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
[Page 4]
MPLS-TP Use Case and Design Considerations
Expires June 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
[Page 5]
MPLS-TP Use Case and Design Considerations
Expires June 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.
[Page 6]
MPLS-TP Use Case and Design Considerations
Expires June 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;
Dynamic control plane for LSP: using GMPLS, OSPF-TE, RSVP-TE for
full automation;
Dymanic control plane for PW: using tLDP.
ACH concept in PW is extended to G-ACh for MPLS-TP LSP to support
in-band OAM.
Both Static and dynamic control plane options must allow control
plane, data plane, management 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: created AIS
- Remote Defect Indication (RDI): Extended BFD
- Lock reporting: Created Lock Instruct
- Link defect Indication: Created LDI
- Static PW defect indication: Use Static PW status
[Page 7]
MPLS-TP Use Case and Design Considerations
Expires June 2012
Performance Management:
- 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].
3.5. Survivability
- Deterministic path protection
- 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
more details on the subject.
4. MPLS-TP Use Case Studies
4.1. Metro Access and Aggregation
The most common deployment cases observed in the field upto today is
using MPLS-TP for Metro access and aggregation. Some SPs are
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
aggregation networks with MPLS-TP technologies, simply because their
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 Life
legacy equipments. Operators have to move forward with the next
generation packet technology, the adoption of MPLS-TP in access and
aggregation becomes a natural choice. The statistical muxing in
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
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
[Page 8]
MPLS-TP Use Case and Design Considerations
Expires June 2012
improve end-to-end convergence. It leverages the MPLS experience,
and enhances the ability to support revenue generating 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, support the same operational
feasibility even after migrating to MPLS-TP from ATM/TDM 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.2. Packet Optical Transport
Many SP's transport networks consist of both packet and optical
portions. The transport operators are typically sensitive to network
deployment cost and operation simplicity. MPLS-TP is therefore a
natural fit in some of the transport networks, where the operators
can utilize the MPLS-TP LSP's (including the ones statically
provisioned) to manage user traffic as "circuits" in both packet and
optical networks.
Among other attributes, bandwidth management, protection/recovery
and OAM are critical in Packet/Optical transport networks. In the
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
from long haul optical packet transport all the way to the
aggregation and access.
[Page 9]
MPLS-TP Use Case and Design Considerations
Expires June 2012
4.3. Mobile Backhaul
Wireless communication 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.3.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.
[Page 10]
MPLS-TP Use Case and Design Considerations
Expires June 2012
4.3.2. LTE Mobile Backhaul
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.3.3. WiMAX Backhaul
WiMAX Mobile backhaul shares the similar characteristics as LTE,
with mesh connections rather than P2P, star logical connections.
5. Network Design Considerations
5.1. IP/MPLS vs. MPLS-TP
Questions one might 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?
[Page 11]
MPLS-TP Use Case and Design Considerations
Expires June 2012
The answer is no. MPLS-TP is developed to meet the needs of
traditional transport moving towards packet. It is designed 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 common 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, 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.
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.
[Page 12]
MPLS-TP Use Case and Design Considerations
Expires June 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
be used or not? It is a design trade-off.
. Pros for using S-PE
. Domain isolation, may facilitate trouble shooting
. the PW failure recovery may be quicker
. Cons for using S-PE
. Adds more complexity
. 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
another design trade-off.
. Pros for using PW protection
. PW is protected when both working and protect LSPs
carrying the working PW fails as long as the protection
PW is following a diverse LSP path from the one
carrying the working PW.
[Page 13]
MPLS-TP Use Case and Design Considerations
Expires June 2012
. Cons for using PW protection
. 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
MPLS-TP provide both proactive tools and event drive OAM Tools.
E.g. in the proactive fashion, the BFD hellos can be sent every 3.3
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
notification to the opposite direction to trigger both end switch
over.
In the reactive fashion, when there is a fiber cut for example, LDI
message would be generated from the failure point and propagate to
MEP to trigger immediate switch over from working to protect path.
And AIS would propagate from MIP to MEP for alarm suppression.
Should both proactive and event driven OAM tools be used? The answer
is yes.
Should BFD timers be set as low as possible? It depends on the
applications. In many cases, it is not necessary. The lower the
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
Since IP/MPLS is largely deployment in most networks, MPLS-TP and
IP/MPLS interworking is a reality.
Typically, there is peer model and overlay model.
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
[Page 14]
MPLS-TP Use Case and Design Considerations
Expires June 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.
[Page 15]
MPLS-TP Use Case and Design Considerations
Expires June 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
[Page 16]
MPLS-TP Use Case and Design Considerations
Expires June 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
5.8.1. Network Modes Selection
When considering deployment of MPLS-TP in the network, possibly
couple of questions will come into mind, for example, where should
the MPLS-TP be deployed? (e.g., access, aggregation or core
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
[Page 17]
MPLS-TP Use Case and Design Considerations
Expires June 2012
domain? The results for these questions depend on the real
requirements on how MPLS-TP and IP/MPLS are used to provide
services. For different services, there could be different choice.
According to the combination of MPLS-TP and IP/MPLS, here are some
typical network modes:
Pure MPLS-TP as the transport connectivity (E2E MPLS-TP), this
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
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;
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
b-1: MPLS-TP as client of IP/MPLS, this is for the case where MPLS-
TP domains are distributed and IP/MPLS do-main/network is used for
the connection of the distributed MPLS-TP domains. For examples,
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
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 Select
ion
As stated in MPLS-TP requirements [RFC 5654], MPLS-TP network MUST
be possible to work without using Control Plane. And this does not
mean that MPLS-TP network has no control plane. Instead, operators
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
[Page 18]
MPLS-TP Use Case and Design Considerations
Expires June 2012
depends on the operators' preference. For the operators who are used
to operate traditional transport network and familiar with the
Transport-Centric operational model (e.g., NMS configuration without
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
Reference to [RFC 5920]. More will be added.
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.
9. Informative References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 3692] T. Narten, "Assigning Experimental and Testing Numbers
Considered Useful", RFC 3692, Jan. 2004.
[RFC 5921] Bocci, M., ED., Bryant, S., ED., et al., Frost, D. ED.,
Levrau, L., Berger., L., "A Framework for MPLS in Transport," July
2010.
[Page 19]
MPLS-TP Use Case and Design Considerations
Expires June 2012
[RFC 5920] Fang, L., ED., et al, "Security Framework for MPLS and
GMPLS Networks," July 2010.
[RFC 6372] Sprecher, N., Ferrel, A., MPLS transport Profile
Survivability Framework [RFC 6372], September 2011.
[OAM Tool Set] Sprecher, N., Fang, L., "An Overview of the OAM Tool
Set for MPLS Based Transport Networks, ", draft-ietf-mpls-to-oam-
analysis-06.txt, Oct. 2011, work in progress.
[Interworking] Martinotti, R., et al., "Interworking between MPLS-TP
and IP/MPLS", draft-martinotti-mpls-tp-interworking-02.txt, June
2011.
10. Author's Addresses
Luyuan Fang
Cisco Systems, Inc.
111 Wood Ave. South
Iselin, NJ 08830
USA
Email: lufang@cisco.com
Nabil Bitar
Verizon
40 Sylvan Road
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
3-11-11.Iidabashi, Chiyodaku, Tokyo
Japan
Email: ms-daikoku@kddi.com
[Page 20]
MPLS-TP Use Case and Design Considerations
Expires June 2012
Kam Lee Yap
XO Communications
13865 Sunrise Valley Drive,
Herndon, VA 20171
Email: klyap@xo.com
Dan Frost
Cisco Systems, Inc.
Email:danfrost@cisco.com
Henry Yu
TW Telecom
10475 Park Meadow Dr.
Littleton, CO 80124
Email: henry.yu@twtelecom.com
Jian Ping Zhang China Telecom, Shanghai
Room 3402, 211 Shi Ji Da Dao
Pu Dong District, Shanghai
China Email: zhangjp@shtel.com.cn
Lei Wang
Telenor
Telenor Norway
Office Snaroyveien
1331 Fornedbu
Email: Lai.wang@telenor.com
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
Nurit Sprecher
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon, 45241
Israel
Email: nurit.sprecher@nsn.com
[Page 21]