draft-ietf-mpls-tp-use-cases-and-design-06.txt   draft-ietf-mpls-tp-use-cases-and-design-07.txt 
INTERNET-DRAFT L. Fang, Ed. INTERNET-DRAFT L. Fang, Ed.
Intended Status: Informational Cisco Intended Status: Informational Cisco
Expires: July 27, 2013 N. Bitar Expires: September 4, 2013 N. Bitar
Verizon Verizon
R. Zhang R. Zhang
Alcatel Lucent Alcatel Lucent
M. Daikoku M. Daikoku
KDDI KDDI
P. Pan P. Pan
Infinera Infinera
January 27, 2013 March 4, 2013
MPLS-TP Applicability; Use Cases and Design MPLS-TP Applicability; Use Cases and Design
draft-ietf-mpls-tp-use-cases-and-design-06.txt draft-ietf-mpls-tp-use-cases-and-design-07.txt
Abstract Abstract
This document provides applicability, use case studies and network This document provides the applicability of Multiprotocol Label
design considerations for the Multiprotocol Label Switching Transport Switching Transport Profile (MPLS-TP) with use case studies and
Profile (MPLS-TP). The use cases include Metro Ethernet access and network design considerations. The use cases include Metro Ethernet
aggregation transport, Mobile backhaul, and packet optical transport. access and aggregation transport, Mobile backhaul, and packet optical
transport.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 20 skipping to change at page 2, line 23
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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
3. MPLS-TP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Metro Access and Aggregation . . . . . . . . . . . . . . . 5 2. MPLS-TP Use Cases . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Packet Optical Transport . . . . . . . . . . . . . . . . . 6 2.1. Metro Access and Aggregation . . . . . . . . . . . . . . . 5
3.3. Mobile Backhaul . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Packet Optical Transport . . . . . . . . . . . . . . . . . 6
3.3.1. 2G and 3G Mobile Backhaul . . . . . . . . . . . . . . . 7 2.3. Mobile Backhaul . . . . . . . . . . . . . . . . . . . . . . 7
3.3.2. 4G/LTE Mobile Backhaul . . . . . . . . . . . . . . . . 8 2.3.1. 2G and 3G Mobile Backhaul . . . . . . . . . . . . . . . 7
4. Network Design Considerations . . . . . . . . . . . . . . . . . 9 2.3.2. 4G/LTE Mobile Backhaul . . . . . . . . . . . . . . . . 8
4.1. The role of MPLS-TP . . . . . . . . . . . . . . . . . . . . 9 3. Network Design Considerations . . . . . . . . . . . . . . . . . 9
4.2. Provisioning mode . . . . . . . . . . . . . . . . . . . . . 9 3.1. The role of MPLS-TP . . . . . . . . . . . . . . . . . . . . 9
4.3. Standards compliance . . . . . . . . . . . . . . . . . . . 9 3.2. Provisioning mode . . . . . . . . . . . . . . . . . . . . . 9
4.4. End-to-end MPLS OAM consistency . . . . . . . . . . . . . . 10 3.3. Standards compliance . . . . . . . . . . . . . . . . . . . 9
4.5. PW Design considerations in MPLS-TP networks . . . . . . . 10 3.4. End-to-end MPLS OAM consistency . . . . . . . . . . . . . . 10
4.6. Proactive and on-demand MPLS-TP OAM tools . . . . . . . . . 11 3.5. PW Design considerations in MPLS-TP networks . . . . . . . 10
4.7. MPLS-TP and IP/MPLS Interworking considerations . . . . . . 11 3.6. Proactive and on-demand MPLS-TP OAM tools . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 11 3.7. MPLS-TP and IP/MPLS Interworking considerations . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 Contributors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
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 1.1. Terminology
technologies, such as SONET/SDH, TDM, and ATM, to new packet
technologies has been rising. This is largely due to the fast growing
demand for bandwidth, which has been fueled by the following factors:
1) The growth of new services. This includes: the tremendous success
of data services, such as IPTV and IP Video for content downloading,
streaming, and sharing; the rapid growth of mobile services, as a
consequence of the explosion of smart phone applications; the
continued growth of business VPNs and residential broadband services.
2) Network infrastructure evolution. As many legacy transport devices
are approaching end of life, Service Providers transition to new
packet technologies and evolve their transport network into the next
generation packet transport.
As part of MPLS family, MPLS-TP complements existing 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.
After several years of industry debate on which packet technology to
use, MPLS-TP has emerged as the next generation transport technology
of choice for many Service Providers worldwide.
The Unified MPLS strategy - using MPLS from core to aggregation and
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, reduces the overall complexity, and improves end-to-
end convergence. It leverages the MPLS experience, and enhances the
ability to support revenue generating services.
MPLS-TP is a subset of MPLS functions that meet the packet transport
requirements defined in [RFC5654]. This subset includes: MPLS data
forwarding, pseudo-wire encapsulation for circuit emulation, and
dynamic control plane using GMPLS control for LSP and tLDP for
pseudo-wire (PW). MPLS-TP also extends previous MPLS OAM functions,
such as BFD extension for proactive Connectivity Check and
Connectivity Verification (CC-CV) [RFC6428], and Remote Defect
Indication (RDI) [RFC6428], LSP Ping Extension for on-demand CC-CV
[RFC6426], fault allocation, and remote integrity check. New tools
have been defined for alarm suppression with Alarm Indication Signal
(AIS) [RFC6427], and switch-over triggering with Link Defect
Indication (LDI). Note that since the MPLS OAM feature extensions
defined through the process of MPLS-TP development are part of the
MPLS family, the applicability is general to MPLS, and not limited to
MPLS-TP.
The requirements of MPLS-TP are provided in MPLS-TP Requirements [RFC
5654], and the architectural framework is defined in MPLS-TP
Framework [RFC5921]. This document's intent is to provide the use
case studies and design considerations from a practical point of view
based on Service Providers deployments plan as well as actual
deployments.
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
functionality are used to support these deployment scenarios.
The design considerations discussed in this document include: the
role of MPLS-TP in the network; provisioning options; standards
compliance; end-to-end forwarding and OAM consistency; compatibility
with existing IP/MPLS networks; and optimization vs. simplicity
design trade-offs.
2. Terminology
Term Definition Term Definition
------ ------------------------------------------------------- ------ -------------------------------------------------------
2G 2nd generation wireless telephone technology 2G 2nd generation wireless telephone technology
3G 3rd generation of mobile telecommunications technology 3G 3rd generation of mobile telecommunications technology
4G 4th Generation Mobile network: LTE 4G 4th Generation Mobile network
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
skipping to change at page 5, line 13 skipping to change at page 3, line 47
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 Entity Group End Point MEP Maintenance Entity Group End Point
MIP Maintenance Entity Group Intermediate Point MIP Maintenance Entity Group Intermediate Point
NMS Network Management System
MPLS MultiProtocol Label Switching MPLS MultiProtocol Label Switching
MPLS-TP MultiProtocol Label Switching Transport Profile MPLS-TP MultiProtocol Label Switching Transport Profile
MS-PW Multi-Segment Pseudowire MS-PW Multi-Segment Pseudowire
NMS Network Management System
OAM Operations, Administration, and Maintenance OAM Operations, Administration, and Maintenance
OPEX Operating Expenses OPEX Operating Expenses
PE Provider-Edge device PE Provider-Edge device
PSW Packet Data Network Gateway PDN GW Packet Data Network Gateway
PW Pseudowire
RAN Radio Access Network RAN Radio Access Network
RDI Remote Defect Indication RDI Remote Defect Indication
S1 LTE Standardized interface between eNB and EPC S1 LTE Standardized interface between eNB and EPC
SDH Synchronous Digital Hierarchy SDH Synchronous Digital Hierarchy
SGW Serving Gateway SGW Serving Gateway
SLA Service Level Agreement SLA Service Level Agreement
SONET Synchronous Optical Network SONET Synchronous Optical Network
S-PE PW Switching Provider Edge S-PE PW Switching Provider Edge
SP Service Provider SP Service Provider
SRLG Shared Risk Link Groups SRLG Shared Risk Link Groups
SS-PW Single-Segment Pseudowire SS-PW Single-Segment Pseudowire
TDM Time Division Multiplexing TDM Time Division Multiplexing
TFS Time and Frequency Synchronization TFS Time and Frequency Synchronization
tLDP Targeted Label Distribution Protocol tLDP Targeted Label Distribution Protocol
VPN Virtual Private Network VPN Virtual Private Network
UMTS Universal Mobile Telecommunications System UMTS Universal Mobile Telecommunications System
X2 LTE Standardized interface between eNBs for handover X2 LTE Standardized interface between eNBs for handover
3. MPLS-TP Use Cases 1.2. Background
3.1. Metro Access and Aggregation In recent years, the urgency for moving from traditional transport
technologies, such as SONET/SDH, TDM, and ATM, to new packet
technologies has been rising. This is largely due to the fast growing
demand for bandwidth, which has been fueled by the following factors:
1) The growth of new services. This includes: the tremendous success
of data services, such as IPTV and IP Video for content downloading,
streaming, and sharing; the rapid growth of mobile services, as a
consequence of the explosion of smart phone applications; the
continued growth of business VPNs and residential broadband services.
2) Network infrastructure evolution. As many legacy transport devices
are approaching end of life, Service Providers transition to new
packet technologies and evolve their transport network into the next
generation packet transport.
As part of MPLS family, MPLS-TP complements existing 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.
After several years of industry debate on which packet technology to
use, MPLS-TP has emerged as the next generation transport technology
of choice for many Service Providers worldwide.
The Unified MPLS strategy - using MPLS from core to aggregation and
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, reduces the overall complexity, and improves end-to-
end convergence. It leverages the MPLS experience, and enhances the
ability to support revenue generating services.
MPLS-TP is a subset of MPLS functions that meet the packet transport
requirements defined in [RFC5654]. This subset includes: MPLS data
forwarding, pseudo-wire encapsulation for circuit emulation, and
dynamic control plane using GMPLS control for LSP and tLDP for
pseudo-wire (PW). MPLS-TP also extends previous MPLS OAM functions,
such as BFD extension for proactive Connectivity Check and
Connectivity Verification (CC-CV) [RFC6428], and Remote Defect
Indication (RDI) [RFC6428], LSP Ping Extension for on-demand CC-CV
[RFC6426]. New tools have been defined for alarm suppression with
Alarm Indication Signal (AIS) [RFC6427], and switch-over triggering
with Link Defect Indication (LDI) [RFC6427]. Note that since the MPLS
OAM feature extensions defined through the process of MPLS-TP
development are part of the MPLS family, the applicability is general
to MPLS, and not limited to MPLS-TP.
The requirements of MPLS-TP are provided in MPLS-TP Requirements [RFC
5654], and the architectural framework is defined in MPLS-TP
Framework [RFC5921]. This document's intent is to provide the use
case studies and design considerations from a practical point of view
based on Service Providers deployments plan as well as actual
deployments.
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
functionality are used to support these deployment scenarios.
The design considerations discussed in this document include: the
role of MPLS-TP in the network; provisioning options; standards
compliance; end-to-end forwarding and OAM consistency; compatibility
with existing IP/MPLS networks; and optimization vs. simplicity
design trade-offs.
2. MPLS-TP Use Cases
2.1. Metro Access and Aggregation
The use of MPLS-TP for Metro access and aggregation transport is the The use of MPLS-TP for Metro access and aggregation transport is the
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
skipping to change at page 6, line 35 skipping to change at page 6, line 37
The requirements from the SPs for ATM/TDM aggregation replacement The requirements from the SPs for ATM/TDM aggregation replacement
often include: i) maintaining the previous operational model, which often include: i) maintaining the previous operational model, which
means providing a similar user experience in NMS, ii) supporting the means providing a similar user experience in NMS, ii) supporting the
existing access network, (e.g., Ethernet, ADSL, ATM, TDM, etc.), and existing access network, (e.g., Ethernet, ADSL, ATM, TDM, etc.), and
connections with the core networks, and iii) supporting the same connections with the core networks, and iii) supporting the same
operational capabilities and services (L3VPN, L2VPN, E-LINE/E-LAN/E- operational capabilities and services (L3VPN, L2VPN, E-LINE/E-LAN/E-
VLAN, Dedicated Line, etc.). MPLS-TP can meet these requirements and VLAN, Dedicated Line, etc.). MPLS-TP can meet these requirements and
in general the requirements defined in [RFC5654] to support a smooth in general the requirements defined in [RFC5654] to support a smooth
transition. transition.
3.2. Packet Optical Transport 2.2. Packet Optical Transport
Many SP's transport networks consist of both packet and optical Many SP's transport networks consist of both packet and optical
portions. The transport operators are typically sensitive to network portions. The transport operators are typically sensitive to network
deployment cost and operational simplicity. MPLS-TP supports both deployment cost and operational simplicity. MPLS-TP supports both
static provisioning through NMS and dynamic provisioning via the static provisioning through NMS and dynamic provisioning via the
GMPLS control plane. As such, it is viewed as a natural fit in some GMPLS control plane. As such, it is viewed as a natural fit in some
of the transport networks, where the operators can utilize the MPLS- of the transport networks, where the operators can utilize the MPLS-
TP LSP's (including the ones statically provisioned) to manage user TP LSP's (including the ones statically provisioned) to manage user
traffic as "circuits" in both packet and optical networks, and when traffic as "circuits" in both packet and optical networks, and when
they are ready, move to dynamic control plane for greater efficiency. they are ready, move to dynamic control plane for greater efficiency.
skipping to change at page 7, line 18 skipping to change at page 7, line 20
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.
3.3. Mobile Backhaul 2.3. Mobile Backhaul
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.1. 2G and 3G Mobile Backhaul 2.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
skipping to change at page 8, line 18 skipping to change at page 8, line 21
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. The traffic engineered and co-routed packet delay and jitters. The traffic engineered and co-routed
bidirectional properties of an MPLS-TP LSP are of benefit in bidirectional properties of an MPLS-TP LSP are of benefit in
transporting packet based Time and Frequency Synchronization (TFS) transporting packet based Time and Frequency Synchronization (TFS)
protocols such as [1588overmpls]. However, the choice between an protocols such as [1588overmpls]. However, the choice between an
external, physical layer or packet based TFS method is network external, physical layer or packet based TFS method is network
dependent and thus is out of scope of this document. dependent and thus is out of scope of this document.
3.3.2. 4G/LTE Mobile Backhaul 2.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 (PDN GW/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 IP/MPLS has a great advantage in any-to-any connectivity
environments. Thus, the use of mature IP or L3VPN technologies is environments. Thus, the use of mature IP or L3VPN technologies is
particularly common in the design of SP's LTE deployment plans. particularly 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
skipping to change at page 9, line 12 skipping to change at page 9, line 14
point of view of operation maintenance and trouble shooting, and so point of view of operation maintenance and trouble shooting, and so
are widely deployed. In general, using MPLS-TP with static are widely deployed. In general, using MPLS-TP with static
provisioning for LTE backhaul is a viable option. The design provisioning for LTE backhaul is a viable option. The design
objective of using this approach is to keep the operation simple and objective of using this approach is to keep the operation simple and
use a common model for mobile backhaul, especially during the use a common model for mobile backhaul, especially during the
transition period. transition period.
The TFS considerations stated in Section 3.3.1 apply to the 4G/LTE The TFS considerations stated in Section 3.3.1 apply to the 4G/LTE
Mobile Backhaul case as well. Mobile Backhaul case as well.
4. Network Design Considerations 3. Network Design Considerations
4.1. The role of MPLS-TP 3.1. The role of MPLS-TP
The role of MPLS-TP is to provide a solution to help evolve The role of MPLS-TP is to provide a solution to help evolve
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.
4.2. Provisioning mode 3.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 network transition. operational feasibility and the stage of network transition.
Operators who are accustomed to the transport-centric operational Operators who are accustomed to the transport-centric operational
model (e.g., NMS configuration without control plane) typically model (e.g., NMS configuration without control plane) typically
skipping to change at page 9, line 47 skipping to change at page 9, line 49
powerful but it is more suited to operators who are familiar with the powerful but it is more suited to operators who are familiar with the
operation and maintenance of IP/MPLS technologies or are ready to operation and maintenance of IP/MPLS technologies or are 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.
4.3. Standards compliance 3.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.
4.4. End-to-end MPLS OAM consistency 3.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 an end-to-end MPLS solution with a enable Service Providers to deploy an 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 achieve such a goal. Using MPLS based OAM in MPLS-TP can help achieve such a goal.
4.5. PW Design considerations in MPLS-TP networks 3.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
skipping to change at page 11, line 8 skipping to change at page 11, line 10
that the connectivity is maintained and the PW is not impacted. that the connectivity is maintained and the PW is not impacted.
However, in the case of simultaneous failure of both working and However, in the case of simultaneous failure of both working and
protect LSPs, the attached PW would fail. By adding PW protection, protect LSPs, the attached PW would fail. By adding PW protection,
and attaching the protect PW to a diverse LSP not in the same Shared and attaching the protect PW to a diverse LSP not in the same Shared
Risk Link Group (SRLG), the PW is protected even when the primary PW Risk Link Group (SRLG), the PW is protected even when the primary PW
fails. Clearly, using PW protection adds considerably more fails. Clearly, using PW protection adds considerably more
complexity and resource usage, and thus operators often may choose complexity and resource usage, and thus operators often may choose
not to use it, and consider protection against single point of not to use it, and consider protection against single point of
failure as sufficient. failure as sufficient.
4.6. Proactive and on-demand MPLS-TP OAM tools 3.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 Connectivity Check (CC) can proactive OAM fault management tool, BFD Connectivity Check (CC) can
be sent at regular intervals for Connectivity Check; three missed CC be sent at regular intervals for Connectivity Check; three missed CC
messages (or a configurable number) can trigger the failure messages (or a configurable number) can trigger the failure
protection switch-over. BFD sessions are configured for both working protection switch-over. BFD sessions are configured for both working
and protecting LSPs. and protecting LSPs.
A design decision is choosing the value of the BFD CC interval. The A design decision is choosing the value of the BFD CC interval. The
shorter the interval, the faster the detection time is, but also the shorter the interval, the faster the detection time is, but also the
skipping to change at page 11, line 33 skipping to change at page 11, line 35
there is a fiber cut, Link Down Indication (LDI) message [RFC6427] there is a fiber cut, Link Down Indication (LDI) message [RFC6427]
can be generated from the failure point and propagated to the can be generated from the failure point and propagated to the
Maintenance Entity Group End Points (MEPs) to trigger immediate Maintenance Entity Group End Points (MEPs) to trigger immediate
switch-over from working to protect path. An Alarm Indication Signal switch-over from working to protect path. An Alarm Indication Signal
(AIS) can be propagated from the Maintenance Entity Group (AIS) can be propagated from the Maintenance Entity Group
Intermediate Point (MIP) to the MEPs for alarm suppression. Intermediate Point (MIP) to the MEPs for alarm 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.
4.7. MPLS-TP and IP/MPLS Interworking considerations 3.7. MPLS-TP and IP/MPLS Interworking considerations
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 inevitable if not a reality. However, IP/MPLS Interworking is inevitable if not a reality. However,
Interworking discussion is out of the scope of this document, it is Interworking discussion is out of the scope of this document; it is
for further study. for further study.
5. Security Considerations 4. Security Considerations
Under 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. This scenario falls into the Security Reference Model 2 as network. This scenario falls into the Security Reference Model 2 as
described in [MPLS-TP Sec FW]. 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, and attacks to GAL or G-ACh are unique security treats to use cases, and attacks to GAL or G-ACh are unique security treats to
MPLS-TP. The MPLS-TP security considerations are discussed in MPLS-TP MPLS-TP. The MPLS-TP security considerations are discussed in MPLS-TP
Security Framework [MPLS-TP Sec FW]. General security considerations Security Framework [MPLS-TP Sec FW]. General security considerations
for MPLS and GMPLS networks are addressed in Security Framework for for MPLS and GMPLS networks are addressed in Security Framework for
MPLS and GMPLS Networks [RFC5920]. MPLS and GMPLS Networks [RFC5920].
6. IANA Considerations 5. IANA Considerations
This document contains no new IANA considerations. This document contains no new IANA considerations.
7. Acknowledgements 6. 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, and thank Loa Andersson and improving the quality of this document, and thank Loa Andersson and
Adrian Farrel for their continued support and guidance. The authors Adrian Farrel for their continued support and guidance. The authors
would also like to thank Weiqiang Cheng for his helpful input on LTE would also like to thank Weiqiang Cheng for his helpful input on LTE
Mobile backhaul based on his knowledge and experience in real world Mobile backhaul based on his knowledge and experience in real world
deployment, thank Stewart for his text contribution on timing, thank deployment, thank Stewart Bryant for his text contribution on timing,
Andrew Malis for his support and use case discussion, thank Pablo thank Andrew Malis for his support and use case discussion, thank
Frank, Lucy Yong, Huub van Helvoort, Tom Petch, and Curtis Villamizar Pablo Frank, Lucy Yong, Huub van Helvoort, Tom Petch, and Curtis
for their comments and suggestions. Villamizar for their comments and suggestions, thank Joseph Yee and
Miguel Garcia for their APPSDIR and Gen-ART reviews and comments
respectively.
8. References 7. References
8.1. Normative References 7.1. Normative References
[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.
[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.
[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
skipping to change at page 13, line 11 skipping to change at page 13, line 15
[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.
8.2. Informative References 7.2. Informative 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.
[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.
[MPLS-TP Sec FW] Fang, L. Ed., Niven-Jenkins, B., Ed., Mansfield, [MPLS-TP Sec FW] Fang, L. Ed., Niven-Jenkins, B., Ed., Mansfield,
S., Ed., and R. Graveman, Ed., "MPLS-TP Security S., Ed., and R. Graveman, Ed., "MPLS-TP Security
Framework," draft-ietf-mpls-tp-security-framework-07.txt, Framework," draft-ietf-mpls-tp-security-framework-09.txt,
January 2013. February 2013.
[1588overmpls], Davari, S., Oren, A., Bhatia, M., Roberts, P., and [1588overmpls], Davari, S., Oren, A., Bhatia, M., Roberts, P., and
L. Montini, "Transporting Timing messages over MPLS L. Montini, "Transporting Timing messages over MPLS
Networks," draft-ietf-tictoc-1588overmpls-03.txt, October Networks," draft-ietf-tictoc-1588overmpls-04.txt, February
2012. 2013.
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
 End of changes. 35 change blocks. 
126 lines changed or deleted 131 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/