Network Working Group Luyuan Fang Internet Draft Dan Frost Intended status: Informational Cisco Systems Expires: October 27, 2011 Nabil Bitar Verizon Raymond Zhang BT Masahiro DAIKOKU KDDI Jian Ping Zhang China Telecom, Shanghai Lei Wang Telenor Henry Yu TW Telecom Mach(Guoyi) Chen Huawei Technologies Nurit Sprecher Nokia Siemens Networks April 27, 2011 MPLS-TP Use Cases Studies and Design Considerations draft-fang-mpls-tp-use-cases-and-design-03.txt Abstract This document provides use case studies and network design considerations for Multiprotocol Label Switching Transport Profile (MPLS-TP). In the recent years, MPLS-TP has emerged as the technology of choice to meet the needs of transport evolution. Many service providers (SPs) intend to replace SONET/SDH, TDM, ATM traditional transport technologies with MPLS-TP, to achieve higher efficiency, lower operational cost, while maintaining transport characteristics. The use cases for MPLS-TP include Mobile backhaul, Metro Ethernet access and aggregation, and packet optical transport. The design considerations include the following aspects: 1) operational considerations; 2) common topologies and feature set; 3) compatibility with IP/MPLS networks; 4) Potential issues need to be solved. The end goal is to provide reliable, manageable, and scalable transport solutions with lower cost. [Page 1] MPLS-TP Use Cases Studies and Design Considerations April 2011 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress. This Internet-Draft will expire on October 27, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. [Page 2] MPLS-TP Use Cases Studies and Design Considerations April 2011 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction ................................................ 4 1.1. Background and Motivation ................................ 4 1.2. Contributing authors ..................................... 5 2. Terminologies ............................................... 5 3. Overview of MPLS-TP base functions .......................... 6 3.1. MPLS-TP development principles ........................... 7 3.2. Data Plane ............................................... 7 3.3. Control Plane ............................................ 7 3.4. OAM ...................................................... 7 3.5. Survivability ............................................ 8 4. MPLS-TP Use Case Studies .................................... 8 4.1. Mobile Backhaul .......................................... 8 4.2. Metro Access and Aggregation .............................10 4.3. Packet Optical Transport .................................11 5. Network Design Considerations ...............................11 5.1. IP/MPLS vs. MPLS-TP ......................................11 5.2. Standards compliance .....................................12 5.3. End-to-end MPLS OAM consistency ..........................12 5.4. Delay and delay variation ................................12 5.5. General network design considerations ....................15 6. MPLS-TP Deployment Consideration ............................15 6.1. Network Modes Selection ..................................15 6.2. Provisioning Modes Selection .............................16 7. Security Considerations .....................................16 8. IANA Considerations .........................................17 9. Normative References ........................................17 10. Informative References ....................................17 11. Author's Addresses ........................................17 [Page 3] MPLS-TP Use Cases Studies and Design Considerations April 2011 Requirements Language Although this document is not a protocol specification, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC 2119]. 1. Introduction 1.1. Background and Motivation This document provides case studies and network design considerations for Multiprotocol Label Switching Transport Profile (MPLS-TP). In recent years, the urgency for moving from traditional transport technologies such as SONET/SDH, TDM/ATM to new packet technologies has been rising. This is largely due to the tremendous success of data services, such as IPTV and IP Video for content downloading, streaming, and sharing; rapid growth of mobile services, especially smart phone applications; business VPNs and residential broadband. Continued network convergence effort is another contributing factor for transport moving toward packet technologies. After several years of heated debate, MPLS-TP has emerged as the next generation transport technology of choice for many service providers worldwide. MPLS-TP is based on MPLS technologies. MPLS-TP re-use a subset of MPLS base functions, such as MPLS data forwarding, Pseudo-wire encapsulation for circuit emulation, and GMPLS for control plane option; MPLS-TP extended current MPLS OAM functions, such as BFD extension for Connectivity for proactive Connectivity Check (CC) and Connectivity Verification (CV), and Remote Defect Indication (RDI), LSP Ping Extension for on demand Connectivity Check (CC) and Connectivity Verification (CV), fault allocation, and remote integrity check. New tools are being defined for alarm suppression with Alarm Indication Signal (AIS), and trigger of switch over with Link Defect Indication (LDI). The goal is to take advantage of the maturity of MPLS technology, re-use the existing component when possible and extend the existing protocols or create new procedures/protocols when needed to fully satisfy the transport requirements. The general requirements of MPLS-TP are provided in MPLS-TP Requirements [RFC 5654], and the architectural framework are defined [Page 4] MPLS-TP Use Cases Studies and Design Considerations April 2011 in MPLS-TP Framework [RFC 5921]. This document intent to provide the use case studies and design considerations from practical point of view based on Service Providers deployments plans and field implementations. The most common use cases for MPLS-TP include Mobile Backhaul, Metro Ethernet access and aggregation, and Packet Optical Transport. MPLS- TP data plane architecture, path protection mechanisms, and OAM functionalities are used to support these deployment scenarios. As part of MPLS family, MPLS-TP complements today's IP/MPLS technologies; it closes the gaps in the traditional access and aggregation transport to provide end-to-end solutions in a cost efficient, reliable, and interoperable manner. The unified MPLS strategy, using MPLS from core to aggregation and access (e.g. IP/MPLS in the core, IP/MPLS or MPLS-TP in aggregation and access) appear to be very attractive to many SPs. It streamlines the operation, many help to reduce the overall complexity and improve end-to-end convergence. It leverages the MPLS experience, and enhances the ability to support revenue generating services. The design considerations discussed in this document are generic. While many design criteria are commonly apply to most of SPs, each individual SP may place the importance of one aspect over another depending on the existing operational environment, the applications need to be supported, the design objective, and the expected duration of the network to be in service for a particular design. 1.2. Contributing authors Luyuan Fang, Cisco Systems Nabil Bitar, Verizon Raymond Zhang, BT Masahiro DAIKOKU, KDDI Jian Ping Zhang, China Telecom, Shanghai Mach(Guoyi) Chen, Huawei Technologies 2. Terminologies AIS Alarm Indication Signal APS Automatic Protection Switching ATM Asynchronous Transfer Mode BFD Bidirectional Forwarding Detection CC Continuity Check CE Customer Edge device [Page 5] MPLS-TP Use Cases Studies and Design Considerations April 2011 CV Connectivity Verification CM Configuration Management DM Packet delay measurement ECMP Equal Cost Multi-path FM Fault Management GAL Generic Alert Label G-ACH Generic Associated Channel GMPLS Generalized Multi-Protocol Label Switching LB Loopback LDP Label Distribution Protocol LM Packet loss measurement LSP Label Switched Path LT Link trace MEP Maintenance End Point MIP Maintenance Intermediate Point MP2MP Multi-Point to Multi-Point connections MPLS Multi-Protocol Label Switching MPLS-TP MPLS transport profile OAM Operations, Administration, and Management P2P Point to Multi-Point connections P2MP Point to Point connections PE Provider-Edge device PHP Penultimate Hop Popping PM Performance Management PW Pseudowire RDI Remote Defect Indication RSVP-TE Resource Reservation Protocol with Traffic Engineering Extensions SLA Service Level Agreement SNMP Simple Network Management Protocol SONET Synchronous Optical Network S-PE Switching Provider Edge SRLG Shared Risk Link Group TDM Time Division Multiplexing TE Traffic Engineering TTL Time-To-Live T-PE Terminating Provider Edge VPN Virtual Private Network 3. Overview of MPLS-TP base functions The section provides a summary view of MPLS-TP technology, especially in comparison to the base IP/MPLS technologies. For complete requirements and architecture definitions, please refer to [RFC 5654] and [RFC 5921]. [Page 6] MPLS-TP Use Cases Studies and Design Considerations April 2011 3.1. MPLS-TP development principles The principles for MPLS-TP development are: meeting transport requirements; maintain transport characteristics; re-using the existing MPLS technologies wherever possible to avoid duplicate the effort; ensuring consistency and inter-operability of MPLS-TP and IP/MPLS networks; developing new tools as necessary to fully meet transport requirements. MPLS-TP Technologies include four major areas: Data Plane, Control Plane, OAM, and Survivability. The short summary is provided below. 3.2. Data Plane MPLS-TP re-used MPLS and PW architecture; and MPLS forwarding mechanism; MPLS-TP extended the LSP support from unidirectional to both bi- directional unidirectional support. MPLS-TP defined PHP as optional, disallowed ECMP and MP2MP, only P2P and P2MP are allowed. 3.3. Control Plane MPLS-TP allowed two control plane options: Static: Using NMS for static provisioning; Dynamic Control Plane using GMPLS, OSPF-TE, RSVP-TE for full automation ACH concept in PW is extended to GACH for MPLS-TP LSP to support in- band OAM. Both Static and dynamic control plane options must allow control plane and data plane separation. 3.4. OAM OAM received most attention in MPLS-TP development; Many OAM functions require protocol extensions or new development to meet the transport requirements. 1) Continuity Check (CC), Continuity Verification (CV), and Remote Integrity: - Proactive CC and CV: Extended BFD [Page 7] MPLS-TP Use Cases Studies and Design Considerations April 2011 - On demand CC and CV: Extended LSP Ping - Proactive Remote Integrity: Extended BFD - On demand Remote Integrity: Extended LSP Ping 2) Fault Management: - Fault Localization: Extended LSP Ping - Alarm Suppression: create AIS - Remote Defect Indication (RDI): Extended BFD - Lock reporting: Create Lock Instruct - Link defect Indication: Create LDI - Static PW defect indication: Use Static PW status Performance Management: - Loss Management: Create MPLS-TP loss/delay measurement - Delay Measurement: Create MPLS-TP loss/delay measurement 3.5. Survivability - Deterministic path protection - Switch over within 50ms - 1:1, 1+1, 1:N protection - Linear protection - Ring protection 4. MPLS-TP Use Case Studies 4.1. Mobile Backhaul Mobility is one of the fastest growing areas in communication world wide. For some regions, the tremendous rapid mobile growth is fueled with lack of existing land-line and cable infrastructure. For other regions, the introduction of Smart phones quickly drove mobile data traffic to become the primary mobile bandwidth consumer, some SPs have already seen 85% of total mobile traffic are data traffic. MPLS-TP has been viewed as a suitable technology for Mobile backhaul. 4.1.1. 2G and 3G Mobile Backhaul Support MPLS-TP is commonly viewed as a very good fit for 2G)/3G Mobile backhaul. 2G (GSM/CDMA) and 3G (UMTS/HSPA/1xEVDO) Mobile Backhaul Networks are dominating mobile infrastructure today. [Page 8] MPLS-TP Use Cases Studies and Design Considerations April 2011 The connectivity for 2G/3G networks are Point to point. The logical connections are hub-and-spoke. The physical construction of the networks can be star topology or ring topology. In the Radio Access Network (RAN), each mobile base station (BTS/Node B) is communicating with one Radio Controller (BSC/RNC) only. These connections are often statically set up. Hierarchical Aggregation Architecture / Centralized Architecture are often used for pre-aggregation and aggregation layers. Each aggregation networks inter-connects with multiple access networks. For example, single aggregation ring could aggregate traffic for 10 access rings with total 100 base stations. The technology used today is largely ATM based. Mobile providers are replacing the ATM RAN infrastructure with newer packet technologies. IP RAN networks with IP/MPLS technologies are deployed today by many SPs with great success. MPLS-TP is another suitable choice for Mobile RAN. The P2P connection from base station to Radio Controller can be set statically to mimic the operation today in many RAN environments, in-band OAM and deterministic path protection would support the fast failure detection and switch over to satisfy the SLA agreement. Bidirectional LSP may help to simplify the provisioning process. The deterministic nature of MPLS-TP LSP set up can also help packet based synchronization to maintain predictable performance regarding packet delay and jitters. 4.1.2. LTE Mobile Backhaul One key difference between LTE and 2G/3G Mobile networks is that the logical connection in LTE is mesh while 2G/3G is P2P star connections. In LTE, the base stations eNB/BTS can communicate with multiple Network controllers (PSW/SGW or ASNGW), and each Radio element can communicate with each other for signal exchange and traffic offload to wireless or Wireline infrastructures. IP/MPLS may have a great advantage in any-to-any connectivity environment. The use of mature IP or L3VPN technologies is particularly common in the design of SP's LTE deployment plan. MPLS-TP can also bring advantages with the in-band OAM and path protection mechanism. MPLS-TP dynamic control-plane with GMPLS signaling may bring additional advantages in the mesh environment for real time adaptivities, dynamic topology changes, and network optimization. Since MPLS-TP is part of the MPLS family. Many component already shared by both IP/MPLS and MPLS-TP, the line can be further blurred [Page 9] MPLS-TP Use Cases Studies and Design Considerations April 2011 by sharing more common features. For example, it is desirable for many SPs to introduce the in-band OAM developed for MPLS-TP back into IP/MPLS networks as an enhanced OAM option. Today's MPLS PW can also be set statically to be deterministic if preferred by the SPs without going through full MPLS-TP deployment. 4.1.3. WiMAX Backhaul WiMAX Mobile backhaul shares the similar characteristics as LTE, with mesh connections rather than P2P, star logical connections. 4.2. Metro Access and Aggregation Some SPs are building new Access and aggregation infrastructure, while others plan to upgrade/replace of existing transport infrastructure with new packet technologies such as MPLS-TP. The later is of course more common than the former. The access and aggregation networks today can be based on ATM, TDM, MSTP, or Ethernet technologies as later development. Some SPs announced their plans for replacing their ATM or TDM aggregation networks with MPLS-TP technologies, because the ATM / TDM aggregation networks are no longer suited to support the rapid bandwidth growth, and they are expensive to maintain or may also be and impossible expand due to End of Sale and End of Life legacy equipments. The statistical muxing in MPLS-TP helps to achieve higher efficiency comparing with the time division scheme in the legacy technologies. The unified MPLS strategy, using MPLS from core to aggregation and access (e.g. IP/MPLS in the core, IP/MPLS or MPLS-TP in aggregation and access) appear to be very attractive to many SPs. It streamlines the operation, many help to reduce the overall complexity and improve end-to-end convergence. It leverages the MPLS experience, and enhances the ability to support revenue generating services. The current requirements from the SPs for ATM/TDM aggregation replacement often include maintaining the current operational model, with the similar user experience in NMS, supports current access network (e.g. Ethernet, ADSL, ATM, STM, etc.), support the connections with the core networks, support the same operational feasibility even after migrating to MPLS-TP from ATM/TDM and services (OCN, IP-VPN, E-VLAN, Dedicated line, etc.). MPLS-TP currently defined in IETF are meeting these requirements to support a smooth transition. [Page 10] MPLS-TP Use Cases Studies and Design Considerations April 2011 The green field network deployment is targeting using the state of art technology to build most stable, scalable, high quality, high efficiency networks to last for the next many years. IP/MPLS and MPLS-TP are both good choices, depending on the operational model. 4.3. Packet Optical Transport (to be added) 5. Network Design Considerations 5.1. IP/MPLS vs. MPLS-TP Questions we often hear: I have just built a new IP/MPLS network to support multi-services, including L2/L3 VPNs, Internet service, IPTV, etc. Now there is new MPLS-TP development in IETF. Do I need to move onto MPLS-TP technology to state current with technologies? The answer is no generally speaking. MPLS-TP is developed to meet the needs of traditional transport moving towards packet. It is geared to support the transport behavior coming with the long history. IP/MPLS and MPLS-TP both are state of art technologies. IP/MPLS support both transport (e.g. PW, RSVP-TE, etc.) and services (e.g L2/L3 VPNs, IPTV, Mobile RAN, etc.), MPLS-TP provides transport only. The new enhanced OAM features built in MPLS-TP should be share in both flavors through future implementation. Another question: I need to evolve my ATM/TDM/SONET/SDH networks into new packet technologies, but my operational force is largely legacy transport, not familiar with new data technologies, and I want to maintain the same operational model for the time being, what should I do? The answer would be: MPLS-TP may be the best choice today for the transition. A few important factors need to be considered for IP/MPLS or MPLS-TP include: - Technology maturity (IP/MPLS is much more mature with 12 years development) - Operation experience (Work force experience, Union agreement, how easy to transition to a new technology? how much does it cost?) - Needs for Multi-service support on the same node (MPLS-TP provide transport only, does not replace many functions of IP/MPLS) - LTE, IPTV/Video distribution considerations (which path is the most viable for reaching the end goal with minimal cost? but it also meet the need of today's support) [Page 11] MPLS-TP Use Cases Studies and Design Considerations April 2011 5.2. Standards compliance It is generally recognized by SPs that standards compliance are important for driving the cost down and product maturity up, multi- vendor interoperability, also important to meet the expectation of the business customers of SP's. MPLS-TP is a joint work between IETF and ITU-T. In April 2008, IETF and ITU-T jointly agreed to terminate T-MPLS and progress MPLS-TP as joint work [RFC 5317]. The transport requirements would be provided by ITU-T, the protocols would be developed in IETF. T-MPLS is not MPLS-TP. T-MPLS solution would not inter-op with IP/MPLS, it would not be compatible with MPLS-TP defined in IETF. 5.3. End-to-end MPLS OAM consistency In the case Service Providers deploy end-to-end MPLS solution with the combination of dynamic IP/MPLS and static or dynamic MPLS-TP cross core, service edge, and aggregation/access networks, end-to- end MPLS OAM consistency becomes an essential requirements from many Service Provider. The end-to-end MPLS OAM can only be achieved through implementation of IETF MPLS-TP OAM definitions. 5.4. Delay and delay variation Background/motivation: Telecommunication Carriers plan to replace the aging TDM Services (e.g. legacy VPN services) provided by Legacy TDM technologies/equipments to new VPN services provided by MPLS-TP technologies/equipments with minimal cost. The Carriers cannot allow any degradation of service quality, service operation Level, and service availability when migrating out of Legacy TDM technologies/equipments to MPLS-TP transport. The requirements from the customers of these carriers are the same before and after the migration. 5.4.1. Network Delay From our recent observation, more and more Ethernet VPN customers becoming very sensitive to the network delay issues, especially the financial customers. Many of those customers has upgraded their systems in their Data Centers, e.g., their accounting systems. Some of the customers built the special tuned up networks, i.e. Fiber channel networks, in their Data Centers, this tripped more strict delay requirements to the carriers. There are three types of network delay: [Page 12] MPLS-TP Use Cases Studies and Design Considerations April 2011 1. Absolute Delay Time Absolute Delay Time here is the network delay within SLA contract. It means the customers have already accepted the value of the Absolute Delay Time as part of the contract before the Private Line Service is provisioned. 2. Variation of Absolute Delay Time (without network configuration changes). The variation under discussion here is mainly induced by the buffering in network elements. Although there is no description of Variation of Absolute Delay Time on the contract, this has no practical impact on the customers who contract for the highest quality of services available. The bandwidth is guaranteed for those customers' traffic. 3. Relative Delay Time Relative Delay Time is the difference of the Absolute Delay Time between using working and protect path. Ideally, Carriers would prefer the Relative Delay Time to be zero, for the following technical reasons and network operation feasibility concerns. The following are the three technical reasons: Legacy throughput issue In the case that Relative Delay Time is increased between FC networks or TCP networks, the effective throughput is degraded. The effective throughput, though it may be recovered after revert back to the original working path in revertive mode. On the other hand, in that case that Relative Delay Time is decreased between FC networks or TCP networks, buffering over flow may occur at receiving end due to receiving large number of busty packets. As a consequence, effective throughput is degraded as well. Moreover, if packet reordering is occurred due to RTT decrease, unnecessary packet resending is induced and effective throughput is also further degraded. Therefore, management of Relative Delay Time is preferred, although this is known as the legacy TCP throughput issue. Locating Network Acceralators at CE [Page 13] MPLS-TP Use Cases Studies and Design Considerations April 2011 In order to improve effective throughput between customer's FC networks over Ethernet private line service, some customer put "WAN Accelerator" to increase throughput value. For example, some WAN Accelerators at receiving side may automatically send back "R_RDY" in order to avoid decreasing a number of BBcredit at sending side, and the other WAN Accelerators at sending side may have huge number of initial BB credit. When customer tunes up their CE by locating WAN Accelerator, for example, when Relative Delay Time is changes, there is a possibility that effective throughput is degraded. This is because a lot of packet destruction may be occurred due to loss of synchronization, when change of Relative delay time induces packet reordering. And, it is difficult to re-tune up their CE network element automatically when Relative Delay Time is changed, because only less than 50 ms network down detected at CE. Depending on the tuning up method, since Relative Delay Time affects effective throughput between customer's FC networks, management of Relative Delay Time is preferred. c) Use of synchronized replication system Some strict customers, e.g. financial customers, implement "synchronized replication system" for all data back-up and load sharing. Due to synchronized replication system, next data processing is conducted only after finishing the data saving to both primary and replication DC storage. And some tuning function could be applied at Server Network to increase throughput to the replication DC and Client Network. Since Relative Delay Time affects effective throughput, management of Relative Delay Time is preferred. The following are the network operational feasibility issues. Some strict customers, e.g., financial customer, continuously checked the private line connectivity and absolute delay time at CEs. When the absolute delay time is changed, that is Relative delay time is increased or decreased, the customer would complain. From network operational point of view, carrier want to minimize the number of customers complains, MPLS-TP LSP provisioning with zero Relative delay time is preferred and management of Relative Delay Time is preferred. Obviously, when the Relative Delay Time is increased, the customer would complain about the longer delay. When the Relative Delay Time is decreased, the customer expects to keep the lesser Absolute Delay Time condition and would complain why Carrier did not provide the [Page 14] MPLS-TP Use Cases Studies and Design Considerations April 2011 best solution in the first place. Therefore, MPLS-TP LSP provisioning with zero Relative Delay Time is preferred and management of Relative Delay Time is preferred. More discussion will be added on how to manage the Relative delay time. 5.5. General network design considerations - Migration considerations - Resilency - Scalability - Performance 6. MPLS-TP Deployment Consideration 6.1. Network Modes Selection When considering deployment of MPLS-TP in the network, possibly couple of questions will come into mind, for example, where should the MPLS-TP be deployed? (e.g., access, aggregation or core network?) Should IP/MPLS be deployed with MPLS-TP simultaneously? If MPLS-TP and IP/MPLS is deployed in the same network, what is the relationship between MPLS-TP and IP/MPLS (e.g., peer or overlay?) and where is the demarcation between MPLS-TP domain and IP/MPLS domain? The results for these questions depend on the real requirements on how MPLS-TP and IP/MPLS are used to provide services. For different services, there could be different choice. According to the combination of MPLS-TP and IP/MPLS, here are some typical network modes: Pure MPLS-TP as the transport connectivity (E2E MPLS-TP), this situation more happens when the network is a totally new constructed network. For example, a new constructed packet transport network for Mobile Backhaul, or migration from ATM/TDM transport network to packet based transport network. Pure IP/MPLS as transport connectivity (E2E IP/MPLS), this is the current practice for many deployed networks. MPLS-TP combines with IP/MPLS as the transport connectivity (Hybrid mode) Peer mode, some domains adopt MPLS-TP as the transport connectivity; other domains adopt IP/MPLS as the transport connectivity. MPLS-TP domains and IP/MPLS domains are interconnected to provide transport connectivity. Considering there are a lot of IP/MPLS deployments in the field, this mode may be the normal practice in the early stage of MPLS-TP deployment. Overlay mode b-1: MPLS-TP as client of IP/MPLS, this is for the case where MPLS- TP domains are distributed and IP/MPLS do-main/network is used for the connection of the distributed MPLS-TP domains. For examples, [Page 15] MPLS-TP Use Cases Studies and Design Considerations April 2011 there are some service providers who have no their own Backhaul network, they have to rent the Backhaul network that is IP/MPLS based from other service providers. b-2: IP/MPLS as client of MPLS-TP, this is for the case where transport network below the IP/MPLS network is a MPLS-TP based network, the MPLS-TP network provides transport connectivity for the IP/MPLS routers, the usage is analogous as today's ATM/TDM/SDH based transport network that are used for providing connectivity for IP/MPLS routers. 6.2. Provisioning Modes Selection As stated in MPLS-TP requirements [RFC5654], MPLS-TP network MUST be possible to work without using Control Plane. And this does not mean that MPLS-TP network has no control plane. Instead, operators could deploy their MPLS-TP with static provisioning (e.g., CLI, NMS etc.), dynamic control plane signaling (e.g., OSPF-TE/ISIS-TE, GMPLS, LDP, RSVP-TE etc.), or combination of static and dynamic provisioning (Hybrid mode). Each mode has its own pros and cons and how to determine the right mode for a specific network mainly depends on the operators' preference. For the operators who are used to operate traditional transport network and familiar with the Transport- Centric operational model (e.g., NMS configuration without control plane) may prefer static provisioning mode. The dynamic provisioning mode is more suitable for the operators who are familiar with the operation and maintenance of IP/MPLS network where a fully dynamic control plane is used. The hybrid mode may be used when parts of the network are provisioned with static way and the other parts are controlled by dynamic signaling. For example, for big SP, the network is operated and maintained by several different departments who prefer to different modes, thus they could adopt this hybrid mode to support both static and dynamic modes hence to satisfy different requirements. Another example is that static provisioning mode is suitable for some parts of the network and dynamic provisioning mode is suitable for other parts of the networks (e.g., static for access network, dynamic for metro aggregate and core network). Note: This draft is work in progress, more would be filled in the following revision. 7. Security Considerations Reference to [RFC 5920]. More will be added. [Page 16] MPLS-TP Use Cases Studies and Design Considerations April 2011 8. IANA Considerations This document contains no new IANA considerations. 9. Normative References [RFC 5317]: Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile, Feb. 2009. [RFC 5654], Niven-Jenkins, B., et al, "MPLS-TP Requirements," RFC 5654, September 2009. (More to be added) 10.Informative References [RFC 5921] Bocci, M., ED., Bryant, S., ED., et al., Frost, D. ED., Levrau, L., Berger., L., "A Framework for MPLS in Transport," July 2010. [RFC 5920] L. Fang, ED., et al, "Security Framework for MPLS and GMPLS Networks, " July 2010. (More to be added) 11.Author's Addresses Luyuan Fang Cisco Systems, Inc. 111 Wood Ave. South Iselin, NJ 08830 USA Email: lufang@cisco.com Dan Frost Cisco Systems, Inc. Email: danfrost@cisco.com Nabil Bitar Verizon 40 Sylvan Road Waltham, MA 02145 USA [Page 17] MPLS-TP Use Cases Studies and Design Considerations April 2011 Email: nabil.bitar@verizon.com Raymond Zhang British Telecom BT Center 81 Newgate Street London, EC1A 7AJ United Kingdom Email: raymond.zhang@bt.com Masahiro DAIKOKU KDDI corporation 3-11-11.Iidabashi, Chiyodaku, Tokyo Japan Email: ms-daikoku@kddi.com Jian Ping Zhang China Telecom, Shanghai Room 3402, 211 Shi Ji Da Dao Pu Dong District, Shanghai China Email: zhangjp@shtel.com.cn Lai Wang Telenor Telenor Norway Office Snaroyveien 1331 Fornedbu Email: Lai.wang@telenor.com Henry Yu TW Telecom 10475 Park Meadow Drive Littleton, CO 80124 Email : henry.yu@twtelecom.com Mach(Guoyi) Chen Huawei Technologies Co., Ltd. No. 3 Xinxi Road Shangdi Information Industry Base Hai-Dian District, Beijing 100085 China Email: mach@huawei.com Nurit Sprecher Nokia Siemens Networks 3 Hanagar St. Neve Ne'eman B Hod Hasharon, 45241 Israel Email: nurit.sprecher@nsn.com [Page 19]