draft-ietf-mpls-tp-use-cases-and-design-01.txt   draft-ietf-mpls-tp-use-cases-and-design-02.txt 
Network Working Group L. Fang, Ed. Network Working Group L. Fang, Ed.
Internet Draft Cisco Systems Internet Draft Cisco Systems
Intended status: Informational N. Bitar Intended status: Informational N. Bitar
Expires: June 20, 2012 Verizon Expires: December 11, 2012 Verizon
R. Zhang R. Zhang
Alcatel Lucent Alcatel Lucent
M. DAIKOKU M. DAIKOKU
KDDI KDDI
P. Pan P. Pan
Infinera Infinera
December 20, 2011 June 11, 2012
MPLS-TP Applicability; Use Cases and Design MPLS-TP Applicability; Use Cases and Design
draft-ietf-mpls-tp-use-cases-and-design-01.txt draft-ietf-mpls-tp-use-cases-and-design-02.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 Multiprotocol Label Switching Transport
profile (MPLS-TP). profile (MPLS-TP).
In the recent years, MPLS-TP has emerged as the technology of choice In the recent years, MPLS-TP has emerged as the technology of choice
for the new generation of packet transport. Many service providers for the new generation of packet transport. Many service providers
(SPs) are working to replace the legacy transport technologies, e.g. (SPs) are working to replace the legacy transport technologies, e.g.
skipping to change at page 2, line 6 skipping to change at page 2, line 6
vs. simplicity design trade off discussion. The general design vs. simplicity design trade off discussion. The general design
principle is to provide reliable, manageable, and scalable transport principle is to provide reliable, manageable, and scalable transport
solutions. 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 provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
MPLS-TP Use Case and Design Considerations 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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any 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 June 18, 2012. This Internet-Draft will expire on December 11, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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 to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
skipping to change at page 3, line 5 skipping to change at page 3, line 5
1.2. Co-authors and contributors .................................3 5 1.2. Co-authors and contributors .................................3 5
2. Terminologies ..................................................5 5 2. Terminologies ..................................................5 5
3. Overview of MPLS-TP base functions .............................6 6 3. Overview of MPLS-TP base functions .............................6 6
3.1. MPLS-TP development principles ..............................6 6 3.1. MPLS-TP development principles ..............................6 6
3.2. Data Plane ..................................................7 7 3.2. Data Plane ..................................................7 7
3.3. Control Plane ...............................................7 7 3.3. Control Plane ...............................................7 7
3.4. OAM .........................................................7 7 3.4. OAM .........................................................7 7
3.5. Survivability ...............................................8 8 3.5. Survivability ...............................................8 8
4. MPLS-TP Use Case Studies .......................................8 8 4. MPLS-TP Use Case Studies .......................................8 8
MPLS-TP Use Case and Design Considerations MPLS-TP Use Case and Design Considerations
Expires December 2012
4.2. Packet Optical Transport ....................................9 9 4.2. Packet Optical Transport ....................................9 9
4.3. Mobile Backhaul ............................................10 10 4.3. Mobile Backhaul ............................................10 10
5. Network Design Considerations .................................11 11 5. Network Design Considerations .................................11 11
5.1. IP/MPLS vs. MPLS-TP ........................................11 11 5.1. IP/MPLS vs. MPLS-TP ........................................11 11
5.2. Standards compliance .......................................11 12 5.2. Standards compliance .......................................11 12
5.3. End-to-end MPLS OAM consistency ............................12 13 5.3. End-to-end MPLS OAM consistency ............................12 13
5.4. PW Design considerations in MPLS-TP networks ...............13 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.5. Proactive and event driven MPLS-TP OAM tools ...............13 14
5.6. MPLS-TP and IP/MPLS Interworking considerations ............14 14 5.6. MPLS-TP and IP/MPLS Interworking considerations ............14 14
5.7. Delay and delay variation ..................................14 14 5.7. Delay and delay variation ..................................14 14
skipping to change at page 4, line 5 skipping to change at page 4, line 5
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/ATM, to new packet technologies
data services, such as IPTV and IP Video for content downloading, data services, such as IPTV and IP Video for content downloading,
streaming, and sharing; rapid growth of mobile services, especially streaming, and sharing; rapid growth of mobile services, especially
smart phone applications; the continued growth of business VPNs and smart phone applications; the continued growth of business VPNs and
residential broadband. The end of live for many legacy TDM devices residential broadband. The end of live for many legacy TDM devices
and the continuing network convergence effort are also key and the continuing network convergence effort are also key
contributing factors for transport moving toward packet contributing factors for transport moving toward packet
MPLS-TP Use Case and Design Considerations MPLS-TP Use Case and Design Considerations
Expires December 2012
technologies. After several years of heated debate on which packet technologies. After several years of heated debate on which packet
technology to use, MPLS-TP has emerged as the next generation technology to use, MPLS-TP has emerged as the next generation
transport technology of choice for many service providers transport technology of choice for many service providers
worldwide. worldwide.
MPLS-TP is based on MPLS technologies. MPLS-TP re-use a subset of MPLS-TP is based on MPLS technologies. MPLS-TP re-use a subset of
MPLS base functions, such as MPLS data forwarding, Pseudo-wire MPLS base functions, such as MPLS data forwarding, Pseudo-wire
encapsulation for circuit emulation, and GMPLS for LSP, tLDP for PW, encapsulation for circuit emulation, and GMPLS for LSP, tLDP for PW,
as dynamic control plane options; MPLS-TP extended current MPLS OAM as dynamic control plane options; MPLS-TP extended current MPLS OAM
functions, such as BFD extension for Connectivity for proactive functions, such as BFD extension for Connectivity for proactive
skipping to change at page 5, line 5 skipping to change at page 5, line 5
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, many help to reduce the overall complexity and
improve end-to-end convergence. It leverages the MPLS experience, improve end-to-end convergence. It leverages the MPLS experience,
and enhances the ability to support revenue generating services. and enhances the ability to support revenue generating services.
The design considerations discussed in this document are generic. The design considerations discussed in this document are generic.
While many design criteria are commonly apply to most of SPs, each While many design criteria are commonly apply to most of SPs, each
individual SP may place the importance of one aspect over another individual SP may place the importance of one aspect over another
MPLS-TP Use Case and Design Considerations MPLS-TP Use Case and Design Considerations
Expires December 2012
depending on the existing operational environment, what type of depending on the existing operational environment, what type of
applications need to be supported, the design objectives, the cost applications need to be supported, the design objectives, the cost
constrain, and the network evolution plans. constrain, and the network evolution plans.
1.2. Co-authors and contributors 1.2. Co-authors and contributors
Luyuan Fang, Cisco Systems Luyuan Fang, Cisco Systems
Nabil Bitar, Verizon Nabil Bitar, Verizon
Raymond Zhang, Alcatel Lucent Raymond Zhang, Alcatel Lucent
Masahiro DAIKOKU, KDDI Masahiro DAIKOKU, KDDI
skipping to change at page 6, line 6 skipping to change at page 6, line 6
LM Packet loss measurement LM Packet loss measurement
LSP Label Switched Path LSP Label Switched Path
LT Link trace LT Link trace
MEP Maintenance End Point MEP Maintenance End Point
MIP Maintenance Intermediate Point MIP Maintenance Intermediate Point
MP2MP Multi-Point to Multi-Point connections MP2MP Multi-Point to Multi-Point connections
MPLS Multi-Protocol Label Switching MPLS Multi-Protocol Label Switching
MPLS-TP MPLS transport profile MPLS-TP MPLS transport profile
MPLS-TP Use Case and Design Considerations MPLS-TP Use Case and Design Considerations
Expires December 2012
OAM Operations, Administration, and Management OAM Operations, Administration, and Management
P2P Point to Multi-Point connections P2P Point to Multi-Point connections
P2MP Point to Point connections P2MP Point to Point connections
PE Provider-Edge device PE Provider-Edge device
PHP Penultimate Hop Popping PHP Penultimate Hop Popping
PM Performance Management PM Performance Management
PW Pseudowire PW Pseudowire
RDI Remote Defect Indication RDI Remote Defect Indication
RSVP-TE Resource Reservation Protocol with Traffic RSVP-TE Resource Reservation Protocol with Traffic
Engineering Extensions Engineering Extensions
skipping to change at page 7, line 6 skipping to change at page 7, line 6
requirements; maintain transport characteristics; re-using the requirements; maintain transport characteristics; re-using the
existing MPLS technologies wherever possible to avoid duplicate the existing MPLS technologies wherever possible to avoid duplicate the
effort; ensuring consistency and inter-operability of MPLS-TP and effort; ensuring consistency and inter-operability of MPLS-TP and
IP/MPLS networks; developing new tools as necessary to fully meet IP/MPLS networks; developing new tools as necessary to fully meet
transport requirements. transport requirements.
MPLS-TP Technologies include four major areas: Data Plane, Control MPLS-TP Technologies include four major areas: Data Plane, Control
Plane, OAM, and Survivability. The short summary is provided below. Plane, OAM, and Survivability. The short summary is provided below.
MPLS-TP Use Case and Design Considerations MPLS-TP Use Case and Design Considerations
Expires December 2012
3.2. Data Plane 3.2. Data Plane
MPLS-TP re-used MPLS and PW architecture; and MPLS forwarding MPLS-TP re-used MPLS and PW architecture; and MPLS forwarding
mechanism; mechanism;
MPLS-TP extended the LSP support from unidirectional to both bi- MPLS-TP extended the LSP support from unidirectional to both bi-
directional unidirectional support. directional unidirectional support.
MPLS-TP defined PHP as optional, disallowed ECMP and MP2MP, only P2P MPLS-TP defined PHP as optional, disallowed ECMP and MP2MP, only P2P
and P2MP are supported. and P2MP are supported.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
- On demand Remote Integrity: Extended LSP Ping - On demand Remote Integrity: Extended LSP Ping
2) Fault Management: 2) Fault Management:
- Fault Localization: Extended LSP Ping - Fault Localization: Extended LSP Ping
- Alarm Suppression: created AIS - Alarm Suppression: created AIS
- Remote Defect Indication (RDI): Extended BFD - Remote Defect Indication (RDI): Extended BFD
- Lock reporting: Created Lock Instruct - Lock reporting: Created Lock Instruct
- Link defect Indication: Created LDI - Link defect Indication: Created LDI
- Static PW defect indication: Use Static PW status - Static PW defect indication: Use Static PW status
MPLS-TP Use Case and Design Considerations MPLS-TP Use Case and Design Considerations
Expires December 2012
Performance Management: Performance Management:
- Loss Management: Create MPLS-TP loss/delay measurement - Loss Management: Create MPLS-TP loss/delay measurement
- Delay Measurement: 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]. MPLS-TP OAM tool set overview can be found at [OAM Tool Set].
3.5. Survivability 3.5. Survivability
- Deterministic path protection - Deterministic path protection
- Switch over within 50ms - Switch over within 50ms
skipping to change at page 9, line 5 skipping to change at page 9, line 5
generation packet technology, the adoption of MPLS-TP in access and generation packet technology, the adoption of MPLS-TP in access and
aggregation becomes a natural choice. The statistical muxing in aggregation becomes a natural choice. The statistical muxing in
MPLS-TP helps to achieve higher efficiency comparing with the time MPLS-TP helps to achieve higher efficiency comparing with the time
division scheme in the legacy technologies. division scheme in the legacy technologies.
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, many help to reduce the overall complexity and
MPLS-TP Use Case and Design Considerations MPLS-TP Use Case and Design Considerations
Expires December 2012
improve end-to-end convergence. It leverages the MPLS experience, improve end-to-end convergence. It leverages the MPLS experience,
and enhances the ability to support revenue generating services. and enhances the ability to support revenue generating services.
The current requirements from the SPs for ATM/TDM aggregation The current requirements from the SPs for ATM/TDM aggregation
replacement often include maintaining the current operational model, replacement often include maintaining the current operational model,
with the similar user experience in NMS, supports current access with the similar user experience in NMS, supports current access
network (e.g. Ethernet, ADSL, ATM, STM, etc.), support the network (e.g. Ethernet, ADSL, ATM, STM, etc.), support the
connections with the core networks, support the same operational connections with the core networks, support the same operational
feasibility even after migrating to MPLS-TP from ATM/TDM and feasibility even after migrating to MPLS-TP from ATM/TDM and
services (OCN, IP-VPN, E-VLAN, Dedicated line, etc.). MPLS-TP services (OCN, IP-VPN, E-VLAN, Dedicated line, etc.). MPLS-TP
skipping to change at page 10, line 6 skipping to change at page 10, line 6
Typically, ring and linear protection can be readily applied in Typically, ring and linear protection can be readily applied in
metro networks. However, as long-haul networks are sensitive to metro networks. However, as long-haul networks are sensitive to
bandwidth cost and tend to have mesh-like topology, shared mesh bandwidth cost and tend to have mesh-like topology, shared mesh
protection is becoming increasing important. protection is becoming increasing important.
Packet optical deployment plans in some SPs cases are using MPLS-TP Packet optical deployment plans in some SPs cases are using MPLS-TP
from long haul optical packet transport all the way to the from long haul optical packet transport all the way to the
aggregation and access. aggregation and access.
MPLS-TP Use Case and Design Considerations MPLS-TP Use Case and Design Considerations
Expires December 2012
4.3. Mobile Backhaul 4.3. Mobile Backhaul
Wireless communication is one of the fastest growing areas in Wireless communication is one of the fastest growing areas in
communication world wide. For some regions, the tremendous rapid communication world wide. For some regions, the tremendous rapid
mobile growth is fueled with lack of existing land-line and cable mobile growth is fueled with lack of existing land-line and cable
infrastructure. For other regions, the introduction of Smart phones infrastructure. For other regions, the introduction of Smart phones
quickly drove mobile data traffic to become the primary mobile quickly drove mobile data traffic to become the primary mobile
bandwidth consumer, some SPs have already seen 85% of total mobile bandwidth consumer, some SPs have already seen 85% of total mobile
traffic are data traffic. traffic are data traffic.
skipping to change at page 11, line 6 skipping to change at page 11, line 6
Mobile RAN. The P2P connection from base station to Radio Controller Mobile RAN. The P2P connection from base station to Radio Controller
can be set statically to mimic the operation today in many RAN can be set statically to mimic the operation today in many RAN
environments, in-band OAM and deterministic path protection would environments, in-band OAM and deterministic path protection would
support the fast failure detection and switch over to satisfy the support the fast failure detection and switch over to satisfy the
SLA agreement. Bidirectional LSP may help to simplify the SLA agreement. Bidirectional LSP may help to simplify the
provisioning process. The deterministic nature of MPLS-TP LSP set up provisioning process. The deterministic nature of MPLS-TP LSP set up
can also help packet based synchronization to maintain predictable can also help packet based synchronization to maintain predictable
performance regarding packet delay and jitters. performance regarding packet delay and jitters.
MPLS-TP Use Case and Design Considerations MPLS-TP Use Case and Design Considerations
Expires December 2012
4.3.2. LTE Mobile Backhaul 4.3.2. LTE Mobile Backhaul
One key difference between LTE and 2G/3G Mobile networks is that the One key difference between LTE and 2G/3G Mobile networks is that the
logical connection in LTE is mesh while 2G/3G is P2P star logical connection in LTE is mesh while 2G/3G is P2P star
connections. connections.
In LTE, the base stations eNB/BTS can communicate with multiple In LTE, the base stations eNB/BTS can communicate with multiple
Network controllers (PSW/SGW or ASNGW), and each Radio element can Network controllers (PSW/SGW or ASNGW), and each Radio element can
communicate with each other for signal exchange and traffic offload communicate with each other for signal exchange and traffic offload
skipping to change at page 12, line 5 skipping to change at page 12, line 5
5. Network Design Considerations 5. Network Design Considerations
5.1. IP/MPLS vs. MPLS-TP 5.1. IP/MPLS vs. MPLS-TP
Questions one might hear: I have just built a new IP/MPLS network to Questions one might hear: I have just built a new IP/MPLS network to
support multi-services, including L2/L3 VPNs, Internet service, support multi-services, including L2/L3 VPNs, Internet service,
IPTV, etc. Now there is new MPLS-TP development in IETF. Do I need 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? to move onto MPLS-TP technology to state current with technologies?
MPLS-TP Use Case and Design Considerations MPLS-TP Use Case and Design Considerations
Expires December 2012
The answer is no. MPLS-TP is developed to meet the needs of The answer is no. MPLS-TP is developed to meet the needs of
traditional transport moving towards packet. It is designed to traditional transport moving towards packet. It is designed to
support the transport behavior coming with the long history. IP/MPLS support the transport behavior coming with the long history. IP/MPLS
and MPLS-TP both are state of art technologies. IP/MPLS support both 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, 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 IPTV, Mobile RAN, etc.), MPLS-TP provides transport only. The new
enhanced OAM features built in MPLS-TP should be share in both enhanced OAM features built in MPLS-TP should be share in both
flavors through future implementation. flavors through future implementation.
Another common question: I need to evolve my ATM/TDM/SONET/SDH Another common question: I need to evolve my ATM/TDM/SONET/SDH
skipping to change at page 13, line 6 skipping to change at page 13, line 6
joint work [RFC 5317]. The transport requirements would be provided joint work [RFC 5317]. The transport requirements would be provided
by ITU-T, the protocols would be developed in IETF. by ITU-T, the protocols would be developed in IETF.
Today, majority of the core set of MPLS-TP protocol definitions are Today, majority of the core set of MPLS-TP protocol definitions are
published as IETF RFCs already. It is important to deploy the published as IETF RFCs already. It is important to deploy the
solutions based on the standards definitions, in order to ensure the solutions based on the standards definitions, in order to ensure the
compatibility between MPLS-TP and IP/MPLS networks, and the compatibility between MPLS-TP and IP/MPLS networks, and the
interoperability among different equipment by different vendors. interoperability among different equipment by different vendors.
MPLS-TP Use Case and Design Considerations MPLS-TP Use Case and Design Considerations
Expires December 2012
Note that using non-standards, e.g. experimental code point is not Note that using non-standards, e.g. experimental code point is not
recommended practice, it bares the risk of code-point collision, as recommended practice, it bares the risk of code-point collision, as
indicated by [RFC 3692]: It can lead to interoperability problems indicated by [RFC 3692]: It can lead to interoperability problems
when the chosen value collides with a different usage, as it someday when the chosen value collides with a different usage, as it someday
surely will. surely will.
5.3. End-to-end MPLS OAM consistency 5.3. End-to-end MPLS OAM consistency
In the case Service Providers deploy end-to-end MPLS solution with In the case Service Providers deploy end-to-end MPLS solution with
the combination of dynamic IP/MPLS and static or dynamic MPLS-TP the combination of dynamic IP/MPLS and static or dynamic MPLS-TP
skipping to change at page 13, line 48 skipping to change at page 13, line 50
. Cons for using S-PE . Cons for using S-PE
. Adds more complexity . Adds more complexity
. If the operation simplicity is the high priority, some . If the operation simplicity is the high priority, some
SPs choose not to use S-PE, simply forming longer path SPs choose not to use S-PE, simply forming longer path
across primary and secondary rings. across primary and secondary rings.
Should PW protection for the same end points be considered? It is Should PW protection for the same end points be considered? It is
another design trade-off. another design trade-off.
. Pros for using PW protection . Pros for using PW protection
. PW is protected when both working and protect LSPs . PW is protected when both working and protect LSPs
carrying the working PW fails as long as the protection carrying the working PW fails as long as the protection
PW is following a diverse LSP path from the one PW is following a diverse LSP path from the one
carrying the working PW. carrying the working PW.
MPLS-TP Use Case and Design Considerations MPLS-TP Use Case and Design Considerations
Expires December 2012
. Cons for using PW protection . Cons for using PW protection
. Adds more complexity, some may choose not to use if . Adds more complexity, some may choose not to use if
protection against single point of failure is protection against single point of failure is
sufficient. sufficient.
5.5. Proactive and event driven MPLS-TP OAM tools 5.5. Proactive and event driven MPLS-TP OAM tools
MPLS-TP provide both proactive tools and event drive OAM Tools. MPLS-TP provide both proactive tools and event drive OAM Tools.
skipping to change at page 15, line 5 skipping to change at page 15, line 5
IP/MPLS interworking is a reality. IP/MPLS interworking is a reality.
Typically, there is peer model and overlay model. Typically, there is peer model and overlay model.
The inter-connection can be simply VLAN, or PW, or could be MPLS-TE. The inter-connection can be simply VLAN, or PW, or could be MPLS-TE.
A separate document is addressing the in the interworking issues, A separate document is addressing the in the interworking issues,
please refer to the descriptions in [Interworking]. please refer to the descriptions in [Interworking].
5.7. Delay and delay variation 5.7. Delay and delay variation
MPLS-TP Use Case and Design Considerations MPLS-TP Use Case and Design Considerations
Expires December 2012
Background/motivation: Telecommunication Carriers plan to replace Background/motivation: Telecommunication Carriers plan to replace
the aging TDM Services (e.g. legacy VPN services) provided by Legacy the aging TDM Services (e.g. legacy VPN services) provided by Legacy
TDM technologies/equipments to new VPN services provided by MPLS-TP TDM technologies/equipments to new VPN services provided by MPLS-TP
technologies/equipments with minimal cost. The Carriers cannot allow technologies/equipments with minimal cost. The Carriers cannot allow
any degradation of service quality, service operation Level, and any degradation of service quality, service operation Level, and
service availability when migrating out of Legacy TDM service availability when migrating out of Legacy TDM
technologies/equipments to MPLS-TP transport. The requirements from technologies/equipments to MPLS-TP transport. The requirements from
the customers of these carriers are the same before and after the the customers of these carriers are the same before and after the
migration. migration.
skipping to change at page 16, line 6 skipping to change at page 16, line 6
on the contract, this has no practical impact on the customers who on the contract, this has no practical impact on the customers who
contract for the highest quality of services available. The contract for the highest quality of services available. The
bandwidth is guaranteed for those customers' traffic. bandwidth is guaranteed for those customers' traffic.
3. Relative Delay Time 3. Relative Delay Time
Relative Delay Time is the difference of the Absolute Delay Time Relative Delay Time is the difference of the Absolute Delay Time
between using working and protect path. between using working and protect path.
MPLS-TP Use Case and Design Considerations MPLS-TP Use Case and Design Considerations
Expires December 2012
Ideally, Carriers would prefer the Relative Delay Time to be zero, Ideally, Carriers would prefer the Relative Delay Time to be zero,
for the following technical reasons and network operation for the following technical reasons and network operation
feasibility concerns. feasibility concerns.
The following are the three technical reasons: The following are the three technical reasons:
Legacy throughput issue Legacy throughput issue
In the case that Relative Delay Time is increased between FC In the case that Relative Delay Time is increased between FC
networks or TCP networks, the effective throughput is degraded. The networks or TCP networks, the effective throughput is degraded. The
skipping to change at page 17, line 5 skipping to change at page 17, line 5
it is difficult to re-tune up their CE network element automatically it is difficult to re-tune up their CE network element automatically
when Relative Delay Time is changed, because only less than 50 ms when Relative Delay Time is changed, because only less than 50 ms
network down detected at CE. network down detected at CE.
Depending on the tuning up method, since Relative Delay Time affects Depending on the tuning up method, since Relative Delay Time affects
effective throughput between customer's FC networks, management of effective throughput between customer's FC networks, management of
Relative Delay Time is preferred. Relative Delay Time is preferred.
c) Use of synchronized replication system c) Use of synchronized replication system
MPLS-TP Use Case and Design Considerations MPLS-TP Use Case and Design Considerations
Expires December 2012
Some strict customers, e.g. financial customers, implement Some strict customers, e.g. financial customers, implement
"synchronized replication system" for all data back-up and load "synchronized replication system" for all data back-up and load
sharing. Due to synchronized replication system, next data sharing. Due to synchronized replication system, next data
processing is conducted only after finishing the data saving to both processing is conducted only after finishing the data saving to both
primary and replication DC storage. And some tuning function could primary and replication DC storage. And some tuning function could
be applied at Server Network to increase throughput to the be applied at Server Network to increase throughput to the
replication DC and Client Network. Since Relative Delay Time affects replication DC and Client Network. Since Relative Delay Time affects
effective throughput, management of Relative Delay Time is effective throughput, management of Relative Delay Time is
preferred. preferred.
skipping to change at page 18, line 5 skipping to change at page 18, line 5
5.8.1. Network Modes Selection 5.8.1. Network Modes Selection
When considering deployment of MPLS-TP in the network, possibly When considering deployment of MPLS-TP in the network, possibly
couple of questions will come into mind, for example, where should couple of questions will come into mind, for example, where should
the MPLS-TP be deployed? (e.g., access, aggregation or core the MPLS-TP be deployed? (e.g., access, aggregation or core
network?) Should IP/MPLS be deployed with MPLS-TP simultaneously? If 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 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?) relationship between MPLS-TP and IP/MPLS (e.g., peer or overlay?)
and where is the demarcation between MPLS-TP domain and IP/MPLS and where is the demarcation between MPLS-TP domain and IP/MPLS
MPLS-TP Use Case and Design Considerations MPLS-TP Use Case and Design Considerations
Expires December 2012
domain? The results for these questions depend on the real domain? The results for these questions depend on the real
requirements on how MPLS-TP and IP/MPLS are used to provide requirements on how MPLS-TP and IP/MPLS are used to provide
services. For different services, there could be different choice. services. For different services, there could be different choice.
According to the combination of MPLS-TP and IP/MPLS, here are some According to the combination of MPLS-TP and IP/MPLS, here are some
typical network modes: typical network modes:
Pure MPLS-TP as the transport connectivity (E2E MPLS-TP), this Pure MPLS-TP as the transport connectivity (E2E MPLS-TP), this
situation more happens when the network is a totally new constructed situation more happens when the network is a totally new constructed
network. For example, a new constructed packet transport network for network. For example, a new constructed packet transport network for
Mobile Backhaul, or migration from ATM/TDM transport network to Mobile Backhaul, or migration from ATM/TDM transport network to
packet based transport network. packet based transport network.
Pure IP/MPLS as transport connectivity (E2E IP/MPLS), this is the Pure IP/MPLS as transport connectivity (E2E IP/MPLS), this is the
current practice for many deployed networks. current practice for many deployed networks.
MPLS-TP combines with IP/MPLS as the transport connectivity (Hybrid MPLS-TP combines with IP/MPLS as the transport connectivity (Hybrid
mode) mode).
Peer mode, some domains adopt MPLS-TP as the transport connectivity;
Peer mode: some domains adopt MPLS-TP as the transport connectivity;
other domains adopt IP/MPLS as the transport connectivity. MPLS-TP other domains adopt IP/MPLS as the transport connectivity. MPLS-TP
domains and IP/MPLS domains are interconnected to provide transport domains and IP/MPLS domains are interconnected to provide transport
connectivity. Considering there are a lot of IP/MPLS deployments in connectivity. Considering there are a lot of IP/MPLS deployments in
the field, this mode may be the normal practice in the early stage the field, this mode may be the normal practice in the early stage
of MPLS-TP deployment. of MPLS-TP deployment.
Overlay mode
Overlay mode:
b-1: MPLS-TP as client of IP/MPLS, this is for the case where MPLS- 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 TP domains are distributed and IP/MPLS do-main/network is used for
the connection of the distributed MPLS-TP domains. For examples, the connection of the distributed MPLS-TP domains. For examples,
there are some service providers who have no their own Backhaul there are some service providers who have no their own Backhaul
network, they have to rent the Backhaul network that is IP/MPLS network, they have to rent the Backhaul network that is IP/MPLS
based from other service providers. based from other service providers.
b-2: IP/MPLS as client of MPLS-TP, this is for the case where 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 transport network below the IP/MPLS network is a MPLS-TP based
network, the MPLS-TP network provides transport connectivity for the network, the MPLS-TP network provides transport connectivity for the
IP/MPLS routers, the usage is analogous as today's ATM/TDM/SDH based IP/MPLS routers, the usage is analogous as today's ATM/TDM/SDH based
transport network that are used for providing connectivity for transport network that are used for providing connectivity for
IP/MPLS routers. IP/MPLS routers.
5.8.2. Provisioning Modes Select ion 5.8.2. Provisioning Modes Selection
As stated in MPLS-TP requirements [RFC 5654], MPLS-TP network MUST As stated in MPLS-TP requirements [RFC 5654], MPLS-TP network MUST
be possible to work without using Control Plane. And this does not be possible to work without using Control Plane. And this does not
mean that MPLS-TP network has no control plane. Instead, operators mean that MPLS-TP network has no control plane. Instead, operators
could deploy their MPLS-TP with static provisioning (e.g., CLI, NMS could deploy their MPLS-TP with static provisioning (e.g., CLI, NMS
etc.), dynamic control plane signaling (e.g., OSPF-TE/ISIS-TE, etc.), dynamic control plane signaling (e.g., OSPF-TE/ISIS-TE,
GMPLS, LDP, RSVP-TE etc.), or combination of static and dynamic GMPLS, LDP, RSVP-TE etc.), or combination of static and dynamic
provisioning (Hybrid mode). Each mode has its own pros and cons and provisioning (Hybrid mode). Each mode has its own pros and cons and
how to determine the right mode for a specific network mainly how to determine the right mode for a specific network mainly
MPLS-TP Use Case and Design Considerations MPLS-TP Use Case and Design Considerations
Expires December 2012
depends on the operators' preference. For the operators who are used depends on the operators' preference. For the operators who are used
to operate traditional transport network and familiar with the to operate traditional transport network and familiar with the
Transport-Centric operational model (e.g., NMS configuration without Transport-Centric operational model (e.g., NMS configuration without
control plane) may prefer static provisioning mode. The dynamic control plane) may prefer static provisioning mode. The dynamic
provisioning mode is more suitable for the operators who are provisioning mode is more suitable for the operators who are
familiar with the operation and maintenance of IP/MPLS network where familiar with the operation and maintenance of IP/MPLS network where
a fully dynamic control plane is used. The hybrid mode may be used 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 when parts of the network are provisioned with static way and the
other parts are controlled by dynamic signaling. For example, for other parts are controlled by dynamic signaling. For example, for
big SP, the network is operated and maintained by several different big SP, the network is operated and maintained by several different
departments who prefer to different modes, thus they could adopt departments who prefer to different modes, thus they could adopt
this hybrid mode to support both static and dynamic modes hence to this hybrid mode to support both static and dynamic modes hence to
satisfy different requirements. Another example is that static satisfy different requirements. Another example is that static
provisioning mode is suitable for some parts of the network and provisioning mode is suitable for some parts of the network and
dynamic provisioning mode is suitable for other parts of the dynamic provisioning mode is suitable for other parts of the
networks (e.g., static for access network, dynamic for metro networks (e.g., static for access network, dynamic for metro
aggregate and core network). aggregate and core network).
6. Security Considerations 6. Security Considerations
Reference to [RFC 5920]. More will be added. General security considerations for MPLS and GMPLS networks are
addressed in Security Framework for MPLS and GMPLS Networks[RFC 5920].
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 7. IANA Considerations
This document contains no new IANA considerations. This document contains no new IANA considerations.
8. Normative References 8. Normative References
[RFC 5317]: Joint Working Team (JWT) Report on MPLS Architectural [RFC 5317]: Joint Working Team (JWT) Report on MPLS Architectural
Considerations for a Transport Profile, Feb. 2009. Considerations for a Transport Profile, Feb. 2009.
skipping to change at page 20, line 6 skipping to change at page 20, line 6
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 3692] T. Narten, "Assigning Experimental and Testing Numbers [RFC 3692] T. Narten, "Assigning Experimental and Testing Numbers
Considered Useful", RFC 3692, Jan. 2004. Considered Useful", RFC 3692, Jan. 2004.
[RFC 5921] Bocci, M., ED., Bryant, S., ED., et al., Frost, D. ED., [RFC 5921] Bocci, M., ED., Bryant, S., ED., et al., Frost, D. ED.,
Levrau, L., Berger., L., "A Framework for MPLS in Transport," July Levrau, L., Berger., L., "A Framework for MPLS in Transport," July
2010. 2010.
MPLS-TP Use Case and Design Considerations MPLS-TP Use Case and Design Considerations
Expires December 2012
[RFC 5920] Fang, L., ED., et al, "Security Framework for MPLS and [RFC 5920] Fang, L., ED., et al, "Security Framework for MPLS and
GMPLS Networks," July 2010. GMPLS Networks," July 2010.
[RFC 6372] Sprecher, N., Ferrel, A., MPLS transport Profile [RFC 6372] Sprecher, N., Ferrel, A., MPLS transport Profile
Survivability Framework [RFC 6372], September 2011. Survivability Framework [RFC 6372], September 2011.
[OAM Tool Set] Sprecher, N., Fang, L., "An Overview of the OAM Tool [OAM Tool Set] Sprecher, N., Fang, L., "An Overview of the OAM Tool
Set for MPLS Based Transport Networks, ", draft-ietf-mpls-to-oam- Set for MPLS Based Transport Networks,", draft-ietf-mpls-to-oam-
analysis-06.txt, Oct. 2011, work in progress. analysis-09.txt, April 2012, work in progress.
[Interworking] Martinotti, R., et al., "Interworking between MPLS-TP [Interworking] Martinotti, R., et al., "Interworking between MPLS-TP
and IP/MPLS", draft-martinotti-mpls-tp-interworking-02.txt, June and IP/MPLS," draft-martinotti-mpls-tp-interworking-02.txt, June
2011. 2011.
[MPLS-TP Sec FW] Fang, L. ED., et al., "MPLS-TP Security Framework,"
draft-ietf-mpls-tp-security-framework-03.txt, March 2012.
10. Author's Addresses 10. Author's Addresses
Luyuan Fang Luyuan Fang
Cisco Systems, Inc. Cisco Systems, Inc.
111 Wood Ave. South 111 Wood Ave. South
Iselin, NJ 08830 Iselin, NJ 08830
USA USA
Email: lufang@cisco.com Email: lufang@cisco.com
Nabil Bitar Nabil Bitar
Verizon Verizon
40 Sylvan Road 40 Sylvan Road
Waltham, MA 02145 Waltham, MA 02145
USA USA
Email: nabil.bitar@verizon.com Email: nabil.bitar@verizon.com
Raymond Zhang Raymond Zhang
British Telecom Alcatel-Lucent
BT Center 701 Middlefield Road
81 Newgate Street Mountain View, CA 94043
London, EC1A 7AJ Email: raymond.zhang@alcatel-lucent.com
United Kingdom
Email: raymond.zhang@bt.com
Masahiro DAIKOKU Masahiro DAIKOKU
KDDI corporation KDDI corporation
3-11-11.Iidabashi, Chiyodaku, Tokyo 3-11-11.Iidabashi, Chiyodaku, Tokyo
Japan Japan
Email: ms-daikoku@kddi.com Email: ms-daikoku@kddi.com
MPLS-TP Use Case and Design Considerations MPLS-TP Use Case and Design Considerations
Expires December 2012
Kam Lee Yap Kam Lee Yap
XO Communications XO Communications
13865 Sunrise Valley Drive, 13865 Sunrise Valley Drive,
Herndon, VA 20171 Herndon, VA 20171
Email: klyap@xo.com Email: klyap@xo.com
Dan Frost Dan Frost
Cisco Systems, Inc. Cisco Systems, Inc.
Email:danfrost@cisco.com Email:danfrost@cisco.com
 End of changes. 34 change blocks. 
20 lines changed or deleted 65 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/