draft-ietf-mpls-tp-use-cases-and-design-03.txt   draft-ietf-mpls-tp-use-cases-and-design-04.txt 
skipping to change at page 1, line 17 skipping to change at page 1, line 17
R. Zhang R. Zhang
Alcatel Lucent Alcatel Lucent
M. Daikoku M. Daikoku
KDDI KDDI
P. Pan P. Pan
Infinera Infinera
December 16, 2012 December 16, 2012
MPLS-TP Applicability; Use Cases and Design MPLS-TP Applicability; Use Cases and Design
draft-ietf-mpls-tp-use-cases-and-design-03.txt draft-ietf-mpls-tp-use-cases-and-design-04.txt
Abstract Abstract
This document provides applicability, use case studies and network This document provides applicability, use case studies and network
design considerations for the Multiprotocol Label Switching Transport design considerations for the Multiprotocol Label Switching Transport
Profile (MPLS-TP). The use cases include Metro Ethernet access and Profile (MPLS-TP). The use cases include Metro Ethernet access and
aggregation transport, Mobile backhaul, and packet optical transport. aggregation transport, Mobile backhaul, and packet optical transport.
Status of this Memo Status of this Memo
skipping to change at page 2, line 4 skipping to change at page 2, line 4
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
INTERNET DRAFT <Document Title> <Issue Date>
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. MPLS-TP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 5 3. MPLS-TP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Metro Access and Aggregation . . . . . . . . . . . . . . . 5 3.1. Metro Access and Aggregation . . . . . . . . . . . . . . . 5
3.2. Packet Optical Transport . . . . . . . . . . . . . . . . . 6 3.2. Packet Optical Transport . . . . . . . . . . . . . . . . . 6
3.3. Mobile Backhaul . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Mobile Backhaul . . . . . . . . . . . . . . . . . . . . . . 7
3.3.2. 2G and 3G Mobile Backhaul . . . . . . . . . . . . . . . 7 3.3.1. 2G and 3G Mobile Backhaul . . . . . . . . . . . . . . . 7
3.3.2. 4G/LTE Mobile Backhaul . . . . . . . . . . . . . . . . 8 3.3.2. 4G/LTE Mobile Backhaul . . . . . . . . . . . . . . . . 8
5. Network Design Considerations . . . . . . . . . . . . . . . . . 8 4. Network Design Considerations . . . . . . . . . . . . . . . . . 8
5.1. The role of MPLS-TP . . . . . . . . . . . . . . . . . . . . 8 4.1. The role of MPLS-TP . . . . . . . . . . . . . . . . . . . . 8
5.2 Provisioning mode . . . . . . . . . . . . . . . . . . . . . 8 4.2. Provisioning mode . . . . . . . . . . . . . . . . . . . . . 8
5.3. Standards compliance . . . . . . . . . . . . . . . . . . . 9 4.3. Standards compliance . . . . . . . . . . . . . . . . . . . 9
5.4. End-to-end MPLS OAM consistency . . . . . . . . . . . . . . 9 4.4. End-to-end MPLS OAM consistency . . . . . . . . . . . . . . 9
5.5. PW Design considerations in MPLS-TP networks . . . . . . . 9 4.5. PW Design considerations in MPLS-TP networks . . . . . . . 9
5.6. Proactive and on-demand MPLS-TP OAM tools . . . . . . . . . 10 4.6. Proactive and on-demand MPLS-TP OAM tools . . . . . . . . . 10
5.7. MPLS-TP and IP/MPLS Interworking considerations . . . . . . 10 4.7. MPLS-TP and IP/MPLS Interworking considerations . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1 Normative References . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2 Informative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Contributors' Address . . . . . . . . . . . . . . . . . . . . . . 13 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 13
INTERNET DRAFT <Document Title> <Issue Date>
1 Introduction 1. Introduction
This document provides applicability, use case studies and network This document provides applicability, use case studies and network
design considerations for the Multiprotocol Label Switching Transport design considerations for the Multiprotocol Label Switching Transport
Profile (MPLS-TP). Profile (MPLS-TP).
In recent years, the urgency for moving from traditional transport In recent years, the urgency for moving from traditional transport
technologies, such as SONET/SDH, TDM, and ATM, to new packet technologies, such as SONET/SDH, TDM, and ATM, to new packet
technologies has been rising. This is largely due to the fast growing technologies has been rising. This is largely due to the fast growing
demand for bandwidth, which has been fueled by the following factors: demand for bandwidth, which has been fueled by the following factors:
1) The growth of new services. This includes: the tremendous success 1) The growth of new services. This includes: the tremendous success
skipping to change at page 3, line 35 skipping to change at page 3, line 33
generation packet transport. generation packet transport.
As part of MPLS family, MPLS-TP complements existing IP/MPLS As part of MPLS family, MPLS-TP complements existing IP/MPLS
technologies; it closes the gaps in the traditional access and technologies; it closes the gaps in the traditional access and
aggregation transport to enable end-to-end packet technology aggregation transport to enable end-to-end packet technology
solutions in a cost efficient, reliable, and interoperable manner. solutions in a cost efficient, reliable, and interoperable manner.
After several years of industry debate on which packet technology to After several years of industry debate on which packet technology to
use, MPLS-TP has emerged as the next generation transport technology use, MPLS-TP has emerged as the next generation transport technology
of choice for many Service Providers worldwide. of choice for many Service Providers worldwide.
The unified MPLS strategy - using MPLS from core to aggregation and The Unified MPLS strategy - using MPLS from core to aggregation and
access (e.g. IP/MPLS in the core, IP/MPLS or MPLS-TP in aggregation access (e.g. IP/MPLS in the core, IP/MPLS or MPLS-TP in aggregation
and access) appear to be very attractive to many SPs. It streamlines and access) appear to be very attractive to many SPs. It streamlines
the operation, reduces the overall complexity, and improves end-to- the operation, reduces the overall complexity, and improves end-to-
end convergence. It leverages the MPLS experience, and enhances the end convergence. It leverages the MPLS experience, and enhances the
ability to support revenue generating services. ability to support revenue generating services.
MPLS-TP is a subset of MPLS functions that meet the packet transport MPLS-TP is a subset of MPLS functions that meet the packet transport
requirements defined in [RFC5654]. This subset includes: MPLS data requirements defined in [RFC5654]. This subset includes: MPLS data
forwarding, pseudo-wire encapsulation for circuit emulation, and forwarding, pseudo-wire encapsulation for circuit emulation, and
dynamic control plane using GMPLS control for LSP and tLDP for dynamic control plane using GMPLS control for LSP and tLDP for
pseudo-wire (PW). MPLS-TP also extends previous MPLS OAM functions, pseudo-wire (PW). MPLS-TP also extends previous MPLS OAM functions,
such as BFD extension for proactive Connectivity Check and such as BFD extension for proactive Connectivity Check and
Connectivity Verification (CC-CV) [RFC6428], and Remote Defect Connectivity Verification (CC-CV) [RFC6428], and Remote Defect
Indication (RDI) [RFC6428], LSP Ping Extension for on-demand CC-CV Indication (RDI) [RFC6428], LSP Ping Extension for on-demand CC-CV
[RFC6426], fault allocation, and remote integrity check. New tools [RFC6426], fault allocation, and remote integrity check. New tools
have been defined for alarm suppression with Alarm Indication Signal have been defined for alarm suppression with Alarm Indication Signal
(AIS) [RFC6427], and switch-over triggering with Link Defect (AIS) [RFC6427], and switch-over triggering with Link Defect
Indication (LDI). Note that since the MPLS OAM feature extensions Indication (LDI). Note that since the MPLS OAM feature extensions
defined through the process of MPLS-TP development are part of the defined through the process of MPLS-TP development are part of the
INTERNET DRAFT <Document Title> <Issue Date>
MPLS family, the applicability is general to MPLS, and not limited to MPLS family, the applicability is general to MPLS, and not limited to
MPLS-TP. MPLS-TP.
The requirements of MPLS-TP are provided in MPLS-TP Requirements [RFC The requirements of MPLS-TP are provided in MPLS-TP Requirements [RFC
5654], and the architectural framework is defined in MPLS-TP 5654], and the architectural framework is defined in MPLS-TP
Framework [RFC5921]. This document's intent is to provide the use Framework [RFC5921]. This document's intent is to provide the use
case studies and design considerations from a practical point of view case studies and design considerations from a practical point of view
based on Service Providers deployments plans and actual deployments. based on Service Providers deployments plans and actual deployments.
The most common use cases for MPLS-TP include Metro access and The most common use cases for MPLS-TP include Metro access and
aggregation, Mobile Backhaul, and Packet Optical Transport. MPLS-TP aggregation, Mobile Backhaul, and Packet Optical Transport. MPLS-TP
data plane architecture, path protection mechanisms, and OAM data plane architecture, path protection mechanisms, and OAM
functionality are used to support these deployment scenarios. functionality are used to support these deployment scenarios.
The design considerations discussed in this documents include: role The design considerations discussed in this documents include: role
of MPLS-TP in the network; provisioning options; standards of MPLS-TP in the network; provisioning options; standards
compliance; end-to-end forwarding and OAM consistency; compatibility compliance; end-to-end forwarding and OAM consistency; compatibility
with existing IP/MPLS networks; and optimization vs. simplicity with existing IP/MPLS networks; and optimization vs. simplicity
design trade-offs. design trade-offs.
2. Terminology 2. Terminology
## This document uses the terminology and architecture reference
defined in MPLS-TP Framework [RFC 5654] and MPLS-TP requirements
defined in [RFC 5921].
Term Definition Term Definition
------ ----------------------------------------------- ------ -------------------------------------------------------
2G 2nd Generation Mobile network: GSM/CDMA 2G 2nd generation wireless telephone technology
3G 3rd Generation Mobile network: UMTS/HSPA/1xEVDO 3G 3rd generation of mobile telecommunications technology
4G 4th Generation Mobile network: LTE 4G 4th Generation Mobile network: LTE
ADSL Asymmetric Digital Subscriber Line ADSL Asymmetric Digital Subscriber Line
AIS Alarm Indication Signal AIS Alarm Indication Signal
ASNGW Access Service Network Gateway ASNGW Access Service Network Gateway
ATM Asynchronous Transfer Mode ATM Asynchronous Transfer Mode
BFD Bidirectional Forwarding Detection BFD Bidirectional Forwarding Detection
BTS Base Transceiver Station BTS Base Transceiver Station
CC-CV Continuity Check and Connectivity Verification CC-CV Continuity Check and Connectivity Verification
CDMA Code Division Multiple Access CDMA Code Division Multiple Access
E-LINE Ethernet point-to-point connectivity E-LINE Ethernet point-to-point connectivity
E-LAN Ethernet LAN, provides multipoint connectivity E-LAN Ethernet LAN, provides multipoint connectivity
eNB Evolved Node B eNB Evolved Node B
E-VLAN Ethernet Virtual Private LAN E-VLAN Ethernet Virtual Private LAN
EVDO Evolution-Data Optimized EVDO Evolution-Data Optimized
G-ACh Generic Associated Channel G-ACh Generic Associated Channel
GAL G-ACh Label
GMPLS Generalized Multi-Protocol Label Switching GMPLS Generalized Multi-Protocol Label Switching
GSM Global System for Mobile Communications GSM Global System for Mobile Communications
HSPA High Speed Packet Access HSPA High Speed Packet Access
INTERNET DRAFT <Document Title> <Issue Date>
IPTV Internet Protocol television IPTV Internet Protocol television
L2VPN Layer 2 Virtual Private Network L2VPN Layer 2 Virtual Private Network
L3VPN Layer 3 Virtual Private Network L3VPN Layer 3 Virtual Private Network
LAN Local Access Network LAN Local Access Network
LDI Link Down Indication LDI Link Down Indication
LDP Label Distribution Protocol LDP Label Distribution Protocol
LSP Label Switched Path LSP Label Switched Path
LTE Long Term Evolution LTE Long Term Evolution
MEP Maintenance End Point MEP Maintenance End Point
MIP Maintenance Intermediate Point MIP Maintenance Intermediate Point
skipping to change at page 6, line 4 skipping to change at page 5, line 49
most common deployment scenario observed in the field. most common deployment scenario observed in the field.
Some operators are building green-field access and aggregation Some operators are building green-field access and aggregation
transport infrastructure, while others are upgrading/replacing their transport infrastructure, while others are upgrading/replacing their
existing transport infrastructure with new packet technologies. The existing transport infrastructure with new packet technologies. The
existing legacy access and aggregation networks are usually based on existing legacy access and aggregation networks are usually based on
TDM or ATM technologies. Some operators are replacing these networks TDM or ATM technologies. Some operators are replacing these networks
with MPLS-TP technologies, since legacy ATM/TDM aggregation and with MPLS-TP technologies, since legacy ATM/TDM aggregation and
access are becoming inadequate to support the rapid business growth access are becoming inadequate to support the rapid business growth
and too expensive to maintain. In addition, in many cases the legacy and too expensive to maintain. In addition, in many cases the legacy
INTERNET DRAFT <Document Title> <Issue Date>
devices are facing End of Sale and End of Life issues. As operators devices are facing End of Sale and End of Life issues. As operators
must move forward with the next generation packet technology, the must move forward with the next generation packet technology, the
adoption of MPLS-TP in access and aggregation becomes a natural adoption of MPLS-TP in access and aggregation becomes a natural
choice. The statistical multiplexing in MPLS-TP helps to achieve choice. The statistical multiplexing in MPLS-TP helps to achieve
higher efficiency comparing with the time division scheme in the higher efficiency comparing with the time division scheme in the
legacy technologies. MPLS-TP OAM tools and protection mechanisms help legacy technologies. MPLS-TP OAM tools and protection mechanisms help
to maintain high reliability of transport network and achieve fast to maintain high reliability of transport network and achieve fast
recovery. recovery.
As most Service Providers core networks are MPLS enabled, extending As most Service Providers core networks are MPLS enabled, extending
skipping to change at page 7, line 5 skipping to change at page 6, line 50
Among other attributes, bandwidth management, protection/recovery and Among other attributes, bandwidth management, protection/recovery and
OAM are critical in Packet/Optical transport networks. In the context 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 MPLS-TP, each LSP is expected to be associated with a fixed amount
of bandwidth in terms of bits-per-second and/or time-slots. OAM is to of bandwidth in terms of bits-per-second and/or time-slots. OAM is to
be performed on each individual LSP. For some of the performance be performed on each individual LSP. For some of the performance
monitoring (PM) functions, the OAM mechanisms need to be able to monitoring (PM) functions, the OAM mechanisms need to be able to
transmit and process OAM packets at very high frequency. An overview transmit and process OAM packets at very high frequency. An overview
of MPLS-TP OAM toolset is found in [RFC6669]. of MPLS-TP OAM toolset is found in [RFC6669].
INTERNET DRAFT <Document Title> <Issue Date>
Protection [RFC6372] is another important element in transport Protection [RFC6372] is another important element in transport
networks. Typically, ring and linear protection can be readily networks. Typically, ring and linear protection can be readily
applied in metro networks. However, as long-haul networks are applied in metro networks. However, as long-haul networks are
sensitive to bandwidth cost and tend to have mesh-like topology, sensitive to bandwidth cost and tend to have mesh-like topology,
shared mesh protection is becoming increasingly important. shared mesh protection is becoming increasingly important.
In some cases, SPs plan to deploy MPLS-TP from their long haul In some cases, SPs plan to deploy MPLS-TP from their long haul
optical packet transport all the way to the aggregation and access in optical packet transport all the way to the aggregation and access in
their networks. their networks.
skipping to change at page 7, line 28 skipping to change at page 7, line 23
Wireless communication is one of the fastest growing areas in Wireless communication is one of the fastest growing areas in
communication worldwide. In some regions, the tremendous mobile communication worldwide. In some regions, the tremendous mobile
growth is fueled by the lack of existing land-line and cable growth is fueled by the lack of existing land-line and cable
infrastructure. In other regions, the introduction of smart phones is infrastructure. In other regions, the introduction of smart phones is
quickly driving mobile data traffic to become the primary mobile quickly driving mobile data traffic to become the primary mobile
bandwidth consumer (some SPs have already observed more than 85% of bandwidth consumer (some SPs have already observed more than 85% of
total mobile traffic are data traffic). MPLS-TP is viewed as a total mobile traffic are data traffic). MPLS-TP is viewed as a
suitable technology for Mobile backhaul. suitable technology for Mobile backhaul.
3.3.2. 2G and 3G Mobile Backhaul 3.3.1. 2G and 3G Mobile Backhaul
MPLS-TP is commonly viewed as a very good fit for 2G/3G Mobile MPLS-TP is commonly viewed as a very good fit for 2G/3G mobile
backhaul. 2G (GSM/CDMA) and 3G (UMTS/HSPA/1xEVDO) Mobile Backhaul backhaul. 2G (GSM/CDMA) and 3G (UMTS/HSPA/1xEVDO) Mobile Backhaul
Networks are still currently dominating the mobile infrastructure. Networks are still currently dominating the mobile infrastructure.
The connectivity for 2G/3G networks is point to point (P2P). The The connectivity for 2G/3G networks is point to point (P2P). The
logical connections are hub-and-spoke. Networks are physically logical connections are hub-and-spoke. Networks are physically
constructed using a star or ring topology. In the Radio Access constructed using a star or ring topology. In the Radio Access
Network (RAN), each mobile Base Transceiver Station (BTS/Node B) is Network (RAN), each mobile Base Transceiver Station (BTS/Node B) is
communicating with a Radio Controller (BSC/RNC). These connections communicating with a Radio Controller (BSC/RNC). These connections
are often statically set up. are often statically set up.
skipping to change at page 8, line 4 skipping to change at page 7, line 50
total 100 base stations. total 100 base stations.
The technology used today is largely ATM based. Mobile providers are The technology used today is largely ATM based. Mobile providers are
replacing the ATM RAN infrastructure with newer packet technologies. replacing the ATM RAN infrastructure with newer packet technologies.
IP RAN networks with IP/MPLS technologies are deployed today by many IP RAN networks with IP/MPLS technologies are deployed today by many
SPs with great success. MPLS-TP is another suitable choice for Mobile SPs with great success. MPLS-TP is another suitable choice for Mobile
RAN. The P2P connections from base station to Radio Controller can be RAN. The P2P connections from base station to Radio Controller can be
set statically to mimic the operation of today's RAN environments; set statically to mimic the operation of today's RAN environments;
in-band OAM and deterministic path protection can support fast in-band OAM and deterministic path protection can support fast
failure detection and switch-over to satisfy the SLA agreements. failure detection and switch-over to satisfy the SLA agreements.
INTERNET DRAFT <Document Title> <Issue Date>
Bidirectional LSPs may help to simplify the provisioning process. The Bidirectional LSPs may help to simplify the provisioning process. The
deterministic nature of MPLS-TP LSP set up can also support packet deterministic nature of MPLS-TP LSP set up can also support packet
based synchronization to maintain predictable performance regarding based synchronization to maintain predictable performance regarding
packet delay and jitters. packet delay and jitters.
3.3.2. 4G/LTE Mobile Backhaul 3.3.2. 4G/LTE Mobile Backhaul
One key difference between LTE and 2G/3G Mobile networks is that the One key difference between LTE and 2G/3G mobile networks is that the
logical connection in LTE is a mesh, while in 2G/3G is a P2P star. In logical connection in LTE is a mesh, while in 2G/3G is a P2P star. In
LTE, the base stations eNB/BTS communicate with multiple Network LTE, the base stations eNB/BTS communicate with multiple Network
controllers (PSW/SGW or ASNGW), and the radio elements communicate controllers (PSW/SGW or ASNGW), and the radio elements communicate
with one another for signal exchange and traffic offload to wireless with one another for signal exchange and traffic offload to wireless
or wireline infrastructures. or wireline infrastructures.
IP/MPLS has a great advantage in any-to-any connectivity environment. IP/MPLS has a great advantage in any-to-any connectivity environment.
Thus, the use of mature IP or L3VPN technologies is particularly Thus, the use of mature IP or L3VPN technologies is particularly
common in the design of SP's LTE deployment plans. common in the design of SP's LTE deployment plans.
The extended OAM functions defined in MPLS-TP, such as in-band OAM The extended OAM functions defined in MPLS-TP, such as in-band OAM
and path protection mechanisms bring additional advantages to support and path protection mechanisms bring additional advantages to support
SLAs. The dynamic control-plane with GMPLS signaling is especially SLAs. The dynamic control-plane with GMPLS signaling is especially
suited for the mesh environment, to support dynamic topology changes suited for the mesh environment, to support dynamic topology changes
and network optimization. and network optimization.
5. Network Design Considerations 4. Network Design Considerations
5.1. The role of MPLS-TP 4.1. The role of MPLS-TP
The role of MPLS-TP is to provide a solution to help evolving The role of MPLS-TP is to provide a solution to help evolving
traditional transport towards packet. It is designed to support the traditional transport towards packet. It is designed to support the
transport characteristics/behavior described in [RFC5654]. The transport characteristics/behavior described in [RFC5654]. The
primary use of MPLS-TP is largely to replace legacy transport primary use of MPLS-TP is largely to replace legacy transport
technologies, such as SONET/SDH. MPLS-TP is not designed to replace technologies, such as SONET/SDH. MPLS-TP is not designed to replace
the service support capabilities of IP/MPLS, such as L2VPN, L3VPN, the service support capabilities of IP/MPLS, such as L2VPN, L3VPN,
IPTV, Mobile RAN, etc. IPTV, Mobile RAN, etc.
5.2 Provisioning mode 4.2. Provisioning mode
MPLS-TP supports two provisioning modes: i) a mandatory static MPLS-TP supports two provisioning modes: i) a mandatory static
provisioning mode, which must be supported without dependency on provisioning mode, which must be supported without dependency on
dynamic routing or signaling; and ii) an optional distributed dynamic dynamic routing or signaling; and ii) an optional distributed dynamic
control plane, which is used to enable dynamic service provisioning. control plane, which is used to enable dynamic service provisioning.
The decision on which mode to use is largely dependent on the The decision on which mode to use is largely dependent on the
operational feasibility and the stage of evolution transition. operational feasibility and the stage of evolution transition.
Operators who are accustomed with the transport-centric operational Operators who are accustomed with the transport-centric operational
INTERNET DRAFT <Document Title> <Issue Date>
model (e.g., NMS configuration without control plane) typically model (e.g., NMS configuration without control plane) typically
prefer the static provisioning mode. This is the most common choice prefer the static provisioning mode. This is the most common choice
in current deployments. The dynamic provisioning mode can be more in current deployments. The dynamic provisioning mode can be more
powerful but it is more suited for operators who are familiar with powerful but it is more suited for operators who are familiar with
the operation and maintenance of IP/MPLS technologies or ready to the operation and maintenance of IP/MPLS technologies or ready to
step up through training and planned transition. step up through training and planned transition.
There may be also cases where operators choose to use the combination There may be also cases where operators choose to use the combination
of both modes. This is appropriate when parts of the network are of both modes. This is appropriate when parts of the network are
provisioned in a static fashion and other parts are controlled by provisioned in a static fashion and other parts are controlled by
dynamic signaling. This combination may also be used to transition dynamic signaling. This combination may also be used to transition
from static provisioning to dynamic control plane. from static provisioning to dynamic control plane.
5.3. Standards compliance 4.3. Standards compliance
It is generally recognized by SPs that standards compliance is It is generally recognized by SPs that standards compliance is
important for lowering cost, accelerating product maturity, achieving important for lowering cost, accelerating product maturity, achieving
multi-vendor interoperability, and meeting the expectations of their multi-vendor interoperability, and meeting the expectations of their
enterprise customers. enterprise customers.
MPLS-TP is a joint work between IETF and ITU-T. In April 2008, IETF MPLS-TP is a joint work between IETF and ITU-T. In April 2008, IETF
and ITU-T jointly agreed to terminate T-MPLS and progress MPLS-TP as and ITU-T jointly agreed to terminate T-MPLS and progress MPLS-TP as
joint work [RFC5317]. The transport requirements are provided by ITU- joint work [RFC5317]. The transport requirements are provided by ITU-
T, the protocols are developed in IETF. T, the protocols are developed in IETF.
5.4. End-to-end MPLS OAM consistency 4.4. End-to-end MPLS OAM consistency
End-to-end MPLS OAM consistency is highly desirable in order to End-to-end MPLS OAM consistency is highly desirable in order to
enable Service Providers to deploy end-to-end MPLS solution with a enable Service Providers to deploy end-to-end MPLS solution with a
combination of IP/MPLS (for example, in the core including service combination of IP/MPLS (for example, in the core including service
edge) and MPLS-TP (for example, in the aggregation/access networks). edge) and MPLS-TP (for example, in the aggregation/access networks).
Using MPLS based OAM in MPLS-TP can help achieving such a goal. Using MPLS based OAM in MPLS-TP can help achieving such a goal.
5.5. PW Design considerations in MPLS-TP networks 4.5. PW Design considerations in MPLS-TP networks
In general, PWs in MPLS-TP work the same as in IP/MPLS networks. Both In general, PWs in MPLS-TP work the same as in IP/MPLS networks. Both
Single-Segment PW (SS-PW) and Multi-Segment PW (MS-PW) are supported. Single-Segment PW (SS-PW) and Multi-Segment PW (MS-PW) are supported.
For dynamic control plane, Targeted LDP (tLDP) is used. In static For dynamic control plane, Targeted LDP (tLDP) is used. In static
provisioning mode, PW status is a new PW OAM feature for failure provisioning mode, PW status is a new PW OAM feature for failure
notification. In addition, both directions of a PW must be bound to notification. In addition, both directions of a PW must be bound to
the same transport bidirectional LSP. the same transport bidirectional LSP.
In the common network topology involving multi-tier rings, the design In the common network topology involving multi-tier rings, the design
choice is between using SS-PW or MS-PW. This is not a discussion choice is between using SS-PW or MS-PW. This is not a discussion
unique to MPLS-TP, as it applies to PW design in general, but it is unique to MPLS-TP, as it applies to PW design in general, but it is
relevant here, since MPLS-TP is more sensitive to the operational relevant here, since MPLS-TP is more sensitive to the operational
complexities, as noted by operators. If MS-PW is used, Switched PE complexities, as noted by operators. If MS-PW is used, Switched PE
(S-PE) must be deployed to connect the rings. The advantage of this (S-PE) must be deployed to connect the rings. The advantage of this
INTERNET DRAFT <Document Title> <Issue Date>
choice is that it provides domain isolation, which in turn choice is that it provides domain isolation, which in turn
facilitates trouble shooting and allows for faster PW failure facilitates trouble shooting and allows for faster PW failure
recovery. On the other hand, the disadvantage of using S-PE is that recovery. On the other hand, the disadvantage of using S-PE is that
it adds more complexity. Using SS-PW is simpler, since it does not it adds more complexity. Using SS-PW is simpler, since it does not
require S-PEs, but less efficient because the paths across primary require S-PEs, but less efficient because the paths across primary
and secondary rings are longer. If operational simplicity is a higher and secondary rings are longer. If operational simplicity is a higher
priority, some SPs choose the latter. priority, some SPs choose the latter.
Another design trade-off is whether to use PW protection in addition Another design trade-off is whether to use PW protection in addition
to LSP protection or rely solely on LSP protection. By definition, to LSP protection or rely solely on LSP protection. By definition,
skipping to change at page 10, line 28 skipping to change at page 10, line 23
assures that the connectivity is maintained and the PW is not assures that the connectivity is maintained and the PW is not
impacted. However, in the case of simultaneous failure of both impacted. However, in the case of simultaneous failure of both
working and protect LSPs, the attached PW would fail. By adding PW working and protect LSPs, the attached PW would fail. By adding PW
protection, and attaching the protect PW to a diverse LSP not in the protection, and attaching the protect PW to a diverse LSP not in the
same Shared Risk Link Group (SRLG), the PW is protected even when the same Shared Risk Link Group (SRLG), the PW is protected even when the
primary PW fails. Clearly, using PW protection adds considerably primary PW fails. Clearly, using PW protection adds considerably
more complexity and resource usage, and thus operators often may more complexity and resource usage, and thus operators often may
choose not to use it, and consider protection against single point of choose not to use it, and consider protection against single point of
failure as sufficient. failure as sufficient.
5.6. Proactive and on-demand MPLS-TP OAM tools 4.6. Proactive and on-demand MPLS-TP OAM tools
MPLS-TP provide both proactive and on-demand OAM Tools. As a MPLS-TP provide both proactive and on-demand OAM Tools. As a
proactive OAM fault management tool, BFD hellos can be sent at proactive OAM fault management tool, BFD hellos can be sent at
regular intervals for Connectivity Check; 3 missed hellos trigger the regular intervals for Connectivity Check; 3 missed hellos trigger the
failure protection switch-over. BFD sessions are configured for both failure protection switch-over. BFD sessions are configured for both
working and protecting LSPs. working and protecting LSPs.
A design decision is choosing the value of the BFD hello interval. A design decision is choosing the value of the BFD hello interval.
The shorter the interval (3.3ms is the minimum allowed interval), the The shorter the interval (3.3ms is the minimum allowed interval), the
faster the detection time is, but also the higher the resource faster the detection time is, but also the higher the resource
skipping to change at page 10, line 53 skipping to change at page 10, line 48
there is a fiber cut, Link Down Indication (LDI) message [RFC6427] is there is a fiber cut, Link Down Indication (LDI) message [RFC6427] is
generated from the failure point and propagated to the Maintenance generated from the failure point and propagated to the Maintenance
End Points (MEPs) to trigger immediate switch-over from working to End Points (MEPs) to trigger immediate switch-over from working to
protect path. An Alarm Indication Signal (AIS) propagates from the protect path. An Alarm Indication Signal (AIS) propagates from the
Maintenance Intermediate Point (MIP) to the MEPs for alarm Maintenance Intermediate Point (MIP) to the MEPs for alarm
suppression. suppression.
In general, both proactive and on-demand OAM tools should be enabled In general, both proactive and on-demand OAM tools should be enabled
to guarantee short switch-over times. to guarantee short switch-over times.
5.7. MPLS-TP and IP/MPLS Interworking considerations 4.7. MPLS-TP and IP/MPLS Interworking considerations
INTERNET DRAFT <Document Title> <Issue Date>
Since IP/MPLS is largely deployed in most SPs' networks, MPLS-TP and Since IP/MPLS is largely deployed in most SPs' networks, MPLS-TP and
IP/MPLS interworking is a reality. IP/MPLS interworking is a reality.
The interworking issues are addressed in a separate document The interworking issues are addressed in a separate document
[Interworking]. [Interworking].
6. Security Considerations 5. Security Considerations
In the use case of Metro access and aggregation, in the scenario Under the use case of Metro access and aggregation, in the scenario
where some of the access equipment is placed in facilities not owned where some of the access equipment is placed in facilities not owned
by the SP, the static provisioning mode of MPLS-TP is often preferred by the SP, the static provisioning mode of MPLS-TP is often preferred
over the control plane option because it eliminates the possibility over the control plane option because it eliminates the possibility
of a control plane attack which may potentially impact the whole of a control plane attack which may potentially impact the whole
network. network. This scenario falls into the Security Reference Model 2 as
described in [MPLS-TP Sec FW].
Similar location issues apply to the mobile use cases, since Similar location issues apply to the mobile use cases, since
equipment is often placed in remote and outdoor environment, which equipment is often placed in remote and outdoor environment, which
can increase the risk of un-authorized access to the equipment. can increase the risk of un-authorized access to the equipment.
In general, NMS access can be a common point of attack in all MPLS-TP In general, NMS access can be a common point of attack in all MPLS-TP
use cases. General security considerations for MPLS and GMPLS use cases, and attacks to GAL or G-ACh are unique security treats to
networks are addressed in Security Framework for MPLS and GMPLS MPLS-TP. The MPLS-TP security considerations are discussed in MPLS-TP
Networks [RFC5920]. General MPLS-TP security considerations are Security Framework [MPLS-TP Sec FW]. General security considerations
described in MPLS-TP Security Framework [MPLS-TP Sec FW]. for MPLS and GMPLS networks are addressed in Security Framework for
MPLS and GMPLS Networks [RFC5920].
7. IANA Considerations 6. IANA Considerations
This document contains no new IANA considerations. This document contains no new IANA considerations.
8. Acknowledgements 7. Acknowledgements
The authors wish to thank Adrian Farrel for his review as Routing The authors wish to thank Adrian Farrel for his review as Routing
Area Director, Adrian's detailed comments were of great help for Area Director, Adrian's detailed comments were of great help for
improving the quality of this document. The authors would also like improving the quality of this document. The authors would also like
to thank Loa Andersson for his continued support and guidance. to thank Loa Andersson for his continued support and guidance.
9. References 8. References
9.1 Normative References 8.1. Normative References
[RFC5317] Bryant, S., Ed., and L. Andersson, Ed., "Joint Working [RFC5317] Bryant, S., Ed., and L. Andersson, Ed., "Joint Working
Team (JWT) Report on MPLS Architectural Considerations for Team (JWT) Report on MPLS Architectural Considerations for
a Transport Profile", RFC 5317, February 2009. a Transport Profile", RFC 5317, February 2009.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., [RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed.,
Sprecher, N., and S. Ueno, "Requirements of an MPLS Sprecher, N., and S. Ueno, "Requirements of an MPLS
Transport Profile", RFC 5654, September 2009. Transport Profile", RFC 5654, September 2009.
INTERNET DRAFT <Document Title> <Issue Date>
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
[RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS [RFC6426] Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
On-Demand Connectivity Verification and Route Tracing", On-Demand Connectivity Verification and Route Tracing",
RFC 6426, November 2011. RFC 6426, November 2011.
[RFC6427] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed., [RFC6427] Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed.,
Boutros, S., and D. Ward, "MPLS Fault Management Boutros, S., and D. Ward, "MPLS Fault Management
Operations, Administration, and Maintenance (OAM)", Operations, Administration, and Maintenance (OAM)",
RFC 6427, November 2011. RFC 6427, November 2011.
[RFC6428] Allan, D., Ed., Swallow Ed., G., and J. Drake Ed., [RFC6428] Allan, D., Ed., Swallow Ed., G., and J. Drake Ed.,
"Proactive Connectivity Verification, Continuity Check, "Proactive Connectivity Verification, Continuity Check,
and Remote Defect Indication for the MPLS Transport and Remote Defect Indication for the MPLS Transport
Profile", RFC 6428, November 2011. Profile", RFC 6428, November 2011.
9.2 Informative References 8.2. Informative References
[RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau,
L., and L. Berger, "A Framework for MPLS in Transport L., and L. Berger, "A Framework for MPLS in Transport
Networks", RFC 5921, July 2010. Networks", RFC 5921, July 2010.
[RFC6372] Sprecher, N., Ed., and A. Farrel, Ed., "MPLS Transport [RFC6372] Sprecher, N., Ed., and A. Farrel, Ed., "MPLS Transport
Profile (MPLS-TP) Survivability Framework", RFC 6372, Profile (MPLS-TP) Survivability Framework", RFC 6372,
September 2011. September 2011.
[RFC6669] Sprecher, N. and L. Fang, "An Overview of the Operations, [RFC6669] Sprecher, N. and L. Fang, "An Overview of the Operations,
Administration, and Maintenance (OAM) Toolset for MPLS- Administration, and Maintenance (OAM) Toolset for MPLS-
Based Transport Networks", RFC 6669, July 2012. Based Transport Networks", RFC 6669, July 2012.
[Interworking] Martinotti, R., et al., "Interworking between MPLS- [Interworking] Martinotti, R., et al., "Interworking between MPLS-TP
TP and IP/MPLS," draft-martinotti-mpls-tp-interworking-02.txt, June and IP/MPLS," draft-martinotti-mpls-tp-interworking-
2011. 02.txt, June 2011.
[MPLS-TP Sec FW] Fang, L. ED., et al., "MPLS-TP Security Framework," [MPLS-TP Sec FW] Fang, L. Ed., Niven-Jenkins, B., Ed., Mansfield,
draft-ietf-mpls-tp-security-framework-05.txt, October 2012. S., Ed., Graveman, R., Ed., "MPLS-TP Security Framework,"
draft-ietf-mpls-tp-security-framework-05.txt, October
2012.
Authors' Addresses Authors' 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
United States United States
Email: lufang@cisco.com Email: lufang@cisco.com
INTERNET DRAFT <Document Title> <Issue Date>
Nabil Bitar Nabil Bitar
Verizon Verizon
40 Sylvan Road 40 Sylvan Road
Waltham, MA 02145 Waltham, MA 02145
United States United States
Email: nabil.bitar@verizon.com Email: nabil.bitar@verizon.com
Raymond Zhang Raymond Zhang
Alcatel-Lucent Alcatel-Lucent
701 Middlefield Road 701 Middlefield Road
skipping to change at page 13, line 32 skipping to change at page 13, line 31
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
Ping Pan Ping Pan
Infinera Infinera
United States United States
Email: ppan@infinera.com Email: ppan@infinera.com
Contributors' Address Contributors' Addresses
Kam Lee Yap Kam Lee Yap
XO Communications XO Communications
13865 Sunrise Valley Drive, 13865 Sunrise Valley Drive,
Herndon, VA 20171 Herndon, VA 20171
United States United States
Email: klyap@xo.com Email: klyap@xo.com
Dan Frost Dan Frost
Cisco Systems, Inc. Cisco Systems, Inc.
skipping to change at page 13, line 52 skipping to change at page 14, line 4
Cisco Systems, Inc. Cisco Systems, Inc.
United Kingdom United Kingdom
Email:danfrost@cisco.com Email:danfrost@cisco.com
Henry Yu Henry Yu
TW Telecom TW Telecom
10475 Park Meadow Dr. 10475 Park Meadow Dr.
Littleton, CO 80124 Littleton, CO 80124
United States United States
Email: henry.yu@twtelecom.com Email: henry.yu@twtelecom.com
Jian Ping Zhang China Telecom, Shanghai Jian Ping Zhang China Telecom, Shanghai
Room 3402, 211 Shi Ji Da Dao Room 3402, 211 Shi Ji Da Dao
INTERNET DRAFT <Document Title> <Issue Date>
Pu Dong District, Shanghai Pu Dong District, Shanghai
China China
Email: zhangjp@shtel.com.cn Email: zhangjp@shtel.com.cn
Lei Wang Lei Wang
Lime Networks Lime Networks
Strandveien 30, 1366 Lysaker Strandveien 30, 1366 Lysaker
Norway Norway
Email: lei.wang@limenetworks.no Email: lei.wang@limenetworks.no
 End of changes. 45 change blocks. 
91 lines changed or deleted 59 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/