Network Working Group
INTERNET-DRAFT                                              L. Fang, Ed.
   Internet Draft                                      Cisco Systems
Intended status: Status: Informational                                     Cisco
Expires: June 16, 2013                                          N. Bitar
   Expires: December 11, 2012
                                                                 Verizon
                                                                R. Zhang
                                                          Alcatel Lucent
                                                              M. DAIKOKU Daikoku
                                                                    KDDI
                                                                  P. Pan
                                                                Infinera

                                                       June 11,

                                                       December 16, 2012

             MPLS-TP Applicability; Use Cases and Design
              draft-ietf-mpls-tp-use-cases-and-design-02.txt
             draft-ietf-mpls-tp-use-cases-and-design-03.txt

Abstract

   This document provides applicability, use case studies and network
   design considerations for the Multiprotocol Label Switching Transport
   profile
   Profile (MPLS-TP).

   In the recent years, MPLS-TP has emerged as the technology of choice
   for the new generation of packet transport. Many service providers
   (SPs) are working to replace the legacy transport technologies, e.g.
   SONET/SDH, TDM, and ATM technologies, with MPLS-TP for packet
   transport, in order to achieve higher efficiency, lower operational
   cost, while maintaining transport characteristics. The use cases for MPLS-TP include Metro Ethernet access and
   aggregation,
   aggregation transport, Mobile backhaul, and packet optical transport. The
   design considerations discussed in this documents ranging from
   operational experience; standards compliance; technology maturity;
   end-to-end forwarding and OAM consistency; compatibility with
   IP/MPLS networks; multi-vendor interoperability; and optimization
   vs. simplicity design trade off discussion. The general design
   principle is to provide reliable, manageable, and scalable transport
   solutions.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   MPLS-TP Use Case and Design Considerations
   Expires December 2012

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF). (IETF), its areas, and its working groups.  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 progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft will expire on December 11, 2012. Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright and License Notice
INTERNET DRAFT              <Document Title>                <Issue Date>

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.

   1  Introduction ...................................................3                                                                       3
   1.1.  Background and Motivation ...................................3  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2.  Co-authors and contributors .................................3                                                                       5
   2. Terminologies ..................................................5                                                                       5
   3. Overview of MPLS-TP base functions .............................6                                                                       6
   3.1.  MPLS-TP development principles ..............................6                                                                       6
   3.2.  Data Plane ..................................................7                                                                       7
   3.3.  Control Plane ...............................................7                                                                       7
   3.4.  OAM .........................................................7                                                                       7
   3.5.  Survivability ...............................................8                                                                       8
   4. MPLS-TP Use Case Studies .......................................8                                                                       8 MPLS-TP Use Case Cases . . . . . . . . . . . . . . . . . . . . . . .  5
     3.1. Metro Access and Design Considerations
   Expires December 2012

   4.2. Aggregation  . . . . . . . . . . . . . . .  5
     3.2. Packet Optical Transport ....................................9                                                                       9
   4.3.  Mobile Backhaul ............................................10                                                                     10
   5. Network Design Considerations .................................11                                                                     11  . . . . . . . . . . . . . . . . .  6
     3.3. Mobile Backhaul . . . . . . . . . . . . . . . . . . . . . .  7
       3.3.2. 2G and 3G Mobile Backhaul . . . . . . . . . . . . . . .  7
       3.3.2. 4G/LTE Mobile Backhaul  . . . . . . . . . . . . . . . .  8
   5. Network Design Considerations . . . . . . . . . . . . . . . . .  8
     5.1.  IP/MPLS vs. The role of MPLS-TP ........................................11                                                                     11
   5.2. . . . . . . . . . . . . . . . . . . . .  8
     5.2 Provisioning mode  . . . . . . . . . . . . . . . . . . . . .  8
     5.3. Standards compliance .......................................11                                                                     12
   5.3.  . . . . . . . . . . . . . . . . . . .  9
     5.4. End-to-end MPLS OAM consistency ............................12                                                                      13
   5.4. . . . . . . . . . . . . . .  9
     5.5. PW Design considerations in MPLS-TP networks ...............13                                                                      13
   5.5.  . . . . . . .  9
     5.6. Proactive and event driven on-demand MPLS-TP OAM tools ...............13                                                                      14
   5.6. . . . . . . . . . 10
     5.7. MPLS-TP and IP/MPLS Interworking considerations ............14                                                                      14
   5.7.  Delay and delay variation ..................................14                                                                      14
   5.8.  More on MPLS-TP Deployment Considerations ..................17                                                                      17 . . . . . . 10
   6. Security Considerations .......................................19                                                                      19 . . . . . . . . . . . . . . . . . . . . 11
   7. IANA Considerations ...........................................19                                                                      19
   8. . . . . . . . . . . . . . . . . . . . . . . 11
   8. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     9.1  Normative References ..........................................19                                                                      19
   9.  . . . . . . . . . . . . . . . . . . . 11
     9.2  Informative References ........................................19                                                                     19
   10.  Author's Addresses...........................................20                                                                     20

   Requirements Language

   Although this document is not a protocol specification, the key
   words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119 [RFC
   2119].

1.  . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
   Contributors' Address  . . . . . . . . . . . . . . . . . . . . . . 13

INTERNET DRAFT              <Document Title>                <Issue Date>

1  Introduction

   1.1. Background and Motivation

   This document provides applicability, use case studies and network
   design considerations for the Multiprotocol Label Switching Transport
   Profile (MPLS-TP).

   In recent years, the urgency for moving from traditional transport
   technologies, such as SONET/SDH, TDM/ATM, 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, especially as a
   consequence of the explosion of smart phone applications; the
   continued growth of business VPNs and residential broadband. The end of live for broadband services.
   2) Network infrastructure evolution. As many legacy TDM transport devices
   and the continuing network convergence effort
   are also key
   contributing factors for transport moving toward 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 Use Case complements existing IP/MPLS
   technologies; it closes the gaps in the traditional access and Design Considerations
   Expires December 2012

   technologies.
   aggregation transport to enable end-to-end packet technology
   solutions in a cost efficient, reliable, and interoperable manner.
   After several years of heated industry debate on which packet technology to
   use, MPLS-TP has emerged as the next generation transport technology
   of choice for many service providers 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 is based on 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 technologies. experience, and enhances the
   ability to support revenue generating services.

   MPLS-TP re-use is a subset of MPLS base functions, such as functions that meet the packet transport
   requirements defined in [RFC5654]. This subset includes: MPLS data
   forwarding, Pseudo-wire pseudo-wire encapsulation for circuit emulation, and
   dynamic control plane using GMPLS control for LSP, LSP and tLDP for PW,
   as dynamic control plane options;
   pseudo-wire (PW). MPLS-TP extended current also extends previous MPLS OAM functions,
   such as BFD extension for Connectivity for proactive Connectivity Check (CC) and
   Connectivity Verification (CV), (CC-CV) [RFC6428], and Remote Defect
   Indication (RDI), (RDI) [RFC6428], LSP Ping Extension for on demand
   Connectivity Check (CC) and Connectivity Verification (CV), on-demand CC-CV
   [RFC6426], fault allocation, and remote integrity check. New tools are being
   have been defined for alarm suppression with Alarm Indication Signal (AIS),
   (AIS) [RFC6427], and
   trigger of switch over switch-over triggering with Link Defect
   Indication (LDI).

   The goal is to take advantage of Note that since the maturity MPLS OAM feature extensions
   defined through the process of MPLS-TP development are part of the

INTERNET DRAFT              <Document Title>                <Issue Date>

   MPLS technology,
   re-use family, the existing component when possible applicability is general to MPLS, and extend the existing
   protocols or create new procedures/protocols when needed not limited to fully
   satisfy the transport requirements.
   MPLS-TP.

   The general requirements of MPLS-TP are provided in MPLS-TP Requirements [RFC
   5654], and the architectural framework are is defined in MPLS-TP
   Framework [RFC 5921]. [RFC5921]. This document document's intent is to provide the use
   case studies and design considerations from a practical point of view
   based on Service Providers deployments plans and field
   implementations. 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
   functionalities
   functionality are used to support these deployment scenarios.
   As part

   The design considerations discussed in this documents include: role
   of MPLS family, MPLS-TP complements today's IP/MPLS
   technologies; it closes the gaps in the traditional access and
   aggregation transport to enable network; provisioning options; standards
   compliance; end-to-end packet technology
   solutions in a cost efficient, reliable, forwarding and interoperable manner.

   The unified MPLS strategy, using MPLS from core to aggregation and
   access (e.g. IP/MPLS in the core, OAM consistency; compatibility
   with existing 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, networks; and enhances the ability to support revenue generating services.

   The optimization vs. simplicity
   design considerations discussed in this trade-offs.

   2. Terminology

   ## 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
   MPLS-TP Use Case and Design Considerations
   Expires December 2012

   depending on the existing operational environment, what type of
   applications need to be supported, uses the design objectives, the cost
   constrain, terminology and the network evolution plans.

   1.2. Co-authors architecture reference
   defined in MPLS-TP Framework [RFC 5654] and contributors

   Luyuan Fang, Cisco Systems
   Nabil Bitar, Verizon
   Raymond Zhang, Alcatel Lucent
   Masahiro DAIKOKU, KDDI
   Ping Pan, Infinera
   Mach(Guoyi) Chen, Huawei Technologies
   Dan Frost, Cisco Systems
   Kam Lee Yap, XO Communications
   Henry Yu, Time W Telecom
   Jian Ping Zhang, China Telecom, Shanghai
   Nurit Sprecher, Nokia Siemens Networks
   Lei Wang, Telenor

2. Terminologies MPLS-TP requirements
   defined in [RFC 5921].

      Term     Definition
      ------   -----------------------------------------------
      2G       2nd Generation Mobile network: GSM/CDMA
      3G       3rd Generation Mobile network: UMTS/HSPA/1xEVDO
      4G       4th Generation Mobile network: LTE
      ADSL     Asymmetric Digital Subscriber Line
      AIS      Alarm Indication Signal
      APS       Automatic Protection Switching
      ASNGW    Access Service Network Gateway
      ATM      Asynchronous Transfer Mode
      BFD      Bidirectional Forwarding Detection
      CC
      BTS      Base Transceiver Station
      CC-CV    Continuity Check
      CE Customer Edge device
      CV and Connectivity Verification
      CM        Configuration Management
      DM        Packet delay measurement
      ECMP      Equal Cost Multi-path
      FM        Fault Management
      GAL       Generic Alert Label
      G-ACH
      CDMA     Code Division Multiple Access
      E-LINE   Ethernet point-to-point connectivity
      E-LAN    Ethernet LAN, provides multipoint connectivity
      eNB      Evolved Node B
      E-VLAN   Ethernet Virtual Private LAN
      EVDO     Evolution-Data Optimized
      G-ACh    Generic Associated Channel
      GMPLS    Generalized Multi-Protocol Label Switching
      LB        Loopback
      GSM      Global System for Mobile Communications
      HSPA     High Speed Packet Access

INTERNET DRAFT              <Document Title>                <Issue Date>

      IPTV     Internet Protocol television
      L2VPN    Layer 2 Virtual Private Network
      L3VPN    Layer 3 Virtual Private Network
      LAN      Local Access Network
      LDI      Link Down Indication
      LDP      Label Distribution Protocol
      LM        Packet loss measurement
      LSP      Label Switched Path
      LT        Link trace
      LTE      Long Term Evolution
      MEP      Maintenance End Point
      MIP      Maintenance Intermediate Point
      MP2MP     Multi-Point to Multi-Point connections
      NMS      Network Management System
      MPLS      Multi-Protocol     MultiProtocol Label Switching
      MPLS-TP   MPLS transport profile

   MPLS-TP Use Case and Design Considerations
   Expires December 2012  MultiProtocol Label Switching Transport Profile
      MS-PW    Multi-Segment Pseudowire
      OAM      Operations, Administration, and Management
      P2P       Point to Multi-Point connections
      P2MP      Point to Point connections
      OPEX     Operating Expenses
      PE       Provider-Edge device
      PHP       Penultimate Hop Popping
      PM        Performance Management
      PW         Pseudowire
      PSW      Packet Data Network Gateway
      RAN      Radio Access Network
      RDI      Remote Defect Indication
      RSVP-TE   Resource Reservation Protocol with Traffic
                Engineering Extensions
      SDH      Synchronous Digital Hierarchy
      SGW      Serving Gateway
      SLA      Service Level Agreement
      SNMP      Simple Network Management Protocol
      SONET    Synchronous Optical Network
      S-PE     PW Switching Provider Edge
      SP       Service Provider
      SRLG     Shared Risk Link Group
      SM-PW     Multi-Segment PW Groups
      SS-PW     Signle-Segment PW    Single-Segment Pseudowire
      TDM      Time Division Multiplexing
      TE         Traffic Engineering
      tLDP      target LDP
      TTL       Time-To-Live
      T-PE      Terminating Provider Edge     Targeted Label Distribution Protocol
      VPN      Virtual Private Network
      UMTS     Universal Mobile Telecommunications System

3. Overview of MPLS-TP base functions Use Cases

3.1. Metro Access and Aggregation

   The section provides a summary view use of MPLS-TP technology,
   especially for Metro access and aggregation transport is the
   most common deployment scenario observed in comparison to the base IP/MPLS technologies. For
   complete requirements and architecture definitions, please refer to
   [RFC 5654] field.

   Some operators are building green-field access and [RFC 5921].

   3.1. MPLS-TP development principles

   The principles for MPLS-TP development are: meeting aggregation
   transport
   requirements; maintain infrastructure, while others are upgrading/replacing their
   existing transport characteristics; re-using the infrastructure with new packet technologies. The
   existing MPLS technologies wherever possible legacy access and aggregation networks are usually based on
   TDM or ATM technologies. Some operators are replacing these networks
   with MPLS-TP technologies, since legacy ATM/TDM aggregation and
   access are becoming inadequate to avoid duplicate support the
   effort; ensuring consistency rapid business growth
   and inter-operability too expensive to maintain. In addition, in many cases the legacy

INTERNET DRAFT              <Document Title>                <Issue Date>

   devices are facing End of MPLS-TP Sale and
   IP/MPLS networks; developing new tools as necessary to fully meet
   transport requirements. End of Life issues. As operators
   must move forward with the next generation packet technology, the
   adoption of MPLS-TP Technologies include four major areas: Data Plane, Control
   Plane, OAM, in access and Survivability. aggregation becomes a natural
   choice. The short summary is provided below. statistical multiplexing in MPLS-TP Use Case and Design Considerations
   Expires December 2012

   3.2. Data Plane helps to achieve
   higher efficiency comparing with the time division scheme in the
   legacy technologies. MPLS-TP re-used MPLS OAM tools and PW architecture; protection mechanisms help
   to maintain high reliability of transport network and achieve fast
   recovery.

   As most Service Providers core networks are MPLS forwarding
   mechanism;

   MPLS-TP extended enabled, extending
   the LSP support from unidirectional MPLS technology to both bi-
   directional unidirectional support.

   MPLS-TP defined PHP as optional, disallowed ECMP and MP2MP, only P2P the aggregation and P2MP are supported.

   3.3. Control Plane

   MPLS-TP allowed two control plane options:

   Static: Using NMS for static provisioning;
   Dynamic control plane for LSP: using GMPLS, OSPF-TE, RSVP-TE for
   full automation;
   Dymanic control plane for PW: using tLDP.
   ACH concept in PW access transport networks
   with a Unified MPLS strategy is extended to G-ACh for MPLS-TP LSP very attractive to support
   in-band OAM.

   Both Static and dynamic control plane options must allow control
   plane, data plane, management plane separation.

   3.4. OAM

   OAM received most attention many Service
   Providers. Unified MPLS strategy in MPLS-TP development; Many OAM
   functions require protocol extensions or new development to meet the
   transport requirements.

   1) Continuity Check (CC), Continuity Verification (CV), and Remote
   Integrity:
   - Proactive CC and CV: Extended BFD
   - On demand CC this document means having end-
   to-end MPLS technologies through core, aggregation, and CV: Extended LSP Ping
   - Proactive Remote Integrity: Extended BFD
   - On demand Remote Integrity: Extended LSP Ping

   2) Fault Management:
   - Fault Localization: Extended LSP Ping
   - Alarm Suppression: created AIS
   - Remote Defect Indication (RDI): Extended BFD
   - Lock reporting: Created Lock Instruct
   - Link defect Indication: Created LDI
   - Static PW defect indication: Use Static PW status
   MPLS-TP Use Case access. It
   reduces OPEX by streamlining operation and Design Considerations
   Expires December 2012

   Performance Management:
   - Loss Management: Create MPLS-TP loss/delay measurement
   - Delay Measurement: Create MPLS-TP loss/delay measurement

   MPLS-TP OAM tool set overview can be found at [OAM Tool Set].

   3.5. Survivability

   - Deterministic path protection
   - Switch over within 50ms
   - 1:1, 1+1, 1:N protection
   - Linear protection
   - Ring protection
   - Shared Mesh Protection

   MPLS transport Profile Survivability Framework [RFC 6372] provides
   more details on leveraging the subject.

4. MPLS-TP Use Case Studies

   4.1. Metro Access operational
   experience already gained with MPLS technologies; it also improves
   network efficiency and Aggregation reduces end-to-end convergence time.

   The most common deployment cases observed in requirements from the field upto today is
   using MPLS-TP for Metro access and aggregation. Some SPs are
   building green field access and for ATM/TDM aggregation infrastructure, while
   others are upgrading/replacing replacement
   often include: i) maintaining the previous operational model, which
   means providing a similar user experience in NMS, ii) supporting the
   existing transport infrastructure
   with new packet technologies such as MPLS-TP.
   The access and aggregation networks today can be based on network, (e.g., Ethernet, ADSL, ATM, TDM,
   MSTP, or Ethernet technologies as later development.

   Some other SPs announced their plans for replacing their ATM or TDM
   aggregation networks with MPLS-TP technologies, simply because their
   ATM / TDM aggregation networks are no longer suited to support the
   rapid bandwidth growth, and they are expensive to maintain or may
   also be and impossible expand due to End of Sale and End of Life
   legacy equipments. Operators have to move forward with the next
   generation packet technology, the adoption of MPLS-TP in access and
   aggregation becomes a natural choice. The statistical muxing in
   MPLS-TP helps to achieve higher efficiency comparing with the time
   division scheme in the legacy technologies.

   The unified MPLS strategy, using MPLS from core to aggregation and
   access (e.g. IP/MPLS in the core, IP/MPLS or MPLS-TP in aggregation
   and access) appear to be very attractive to many SPs. It streamlines
   the operation, many help to reduce the overall complexity and
   MPLS-TP Use Case and Design Considerations
   Expires December 2012

   improve end-to-end convergence. It leverages the MPLS experience,
   and enhances the ability to support revenue generating services.

   The current requirements from the SPs for ATM/TDM aggregation
   replacement often include maintaining the current operational model,
   with the similar user experience in NMS, supports current access
   network (e.g. Ethernet, ADSL, ATM, STM, etc.), support the and
   connections with the core networks, support and iii) supporting the same
   operational
   feasibility even after migrating to MPLS-TP from ATM/TDM capabilities and services (OCN, IP-VPN, E-VLAN, (L3VPN, L2VPN, E-LINE/E-LAN/E-
   VLAN, Dedicated line, Line, etc.). MPLS-TP
   currently defined in IETF are meeting can meet these requirements and
   in general the requirements defined in [RFC5654] to support a smooth
   transition.

   The green field network deployment is targeting using the state of
   art technology to build most stable, scalable, high quality, high
   efficiency networks to last for the next many years. IP/MPLS and
   MPLS-TP are both good choices, depending on the operational model.

   4.2.

3.2. Packet Optical Transport

   Many SP's transport networks consist of both packet and optical
   portions. The transport operators are typically sensitive to network
   deployment cost and operation operational simplicity. MPLS-TP supports both
   static provisioning through NMS and dynamic provisioning via the
   GMPLS control plane. As such, it is therefore viewed as a natural fit in some
   of the transport networks, where the operators can utilize the MPLS-TP MPLS-
   TP LSP's (including the ones statically provisioned) to manage user
   traffic as "circuits" in both packet and optical networks. networks, and when
   they are ready, move to dynamic control plane for greater efficiency.

   Among other attributes, bandwidth management, protection/recovery and
   OAM are critical in Packet/Optical transport networks. In the context
   of MPLS-TP, each LSP is expected to be associated with a fixed amount
   of bandwidth in terms of bps bits-per-second and/or time-slots. OAM is to
   be performed on each individual LSP. For some of the performance
   monitoring (PM) functions, the OAM mechanisms need to be able to
   transmit and process OAM packets at very high frequency, as low as
   several msec's. frequency. An overview
   of MPLS-TP OAM toolset is found in [RFC6669].

INTERNET DRAFT              <Document Title>                <Issue Date>

   Protection [RFC6372] is another important element in transport
   networks. Typically, ring and linear protection can be readily
   applied in metro networks. However, as long-haul networks are
   sensitive to bandwidth cost and tend to have mesh-like topology,
   shared mesh protection is becoming increasing increasingly important.

   Packet optical deployment plans in

   In some cases, SPs cases are using plan to deploy MPLS-TP from their long haul
   optical packet transport all the way to the aggregation and access.

   MPLS-TP Use Case and Design Considerations
   Expires December 2012

   4.3. access in
   their networks.

3.3. Mobile Backhaul

   Wireless communication is one of the fastest growing areas in
   communication world wide. For worldwide. In some regions, the tremendous rapid mobile
   growth is fueled with by the lack of existing land-line and cable
   infrastructure. For In other regions, the introduction of Smart smart phones is
   quickly drove driving mobile data traffic to become the primary mobile
   bandwidth consumer, some consumer (some SPs have already seen observed more than 85% of
   total mobile traffic are data traffic. traffic). MPLS-TP has been is viewed as a
   suitable technology for Mobile backhaul.

   4.3.1.

3.3.2. 2G and 3G Mobile Backhaul Support

   MPLS-TP is commonly viewed as a very good fit for 2G)/3G 2G/3G Mobile
   backhaul. 2G (GSM/CDMA) and 3G (UMTS/HSPA/1xEVDO) Mobile Backhaul
   Networks are still currently dominating the mobile infrastructure today. infrastructure.

   The connectivity for 2G/3G networks are Point is point to point. point (P2P). The
   logical connections are hub-and-spoke. The physical construction of the
   networks can be Networks are physically
   constructed using a star topology or ring topology. In the Radio Access
   Network (RAN), each mobile base station Base Transceiver Station (BTS/Node B) is
   communicating with one a Radio Controller (BSC/RNC) only. (BSC/RNC). These connections
   are often statically set up.

   Hierarchical Aggregation Architecture / Centralized Architecture or centralized architectures are often used for pre-aggregation pre-
   aggregation and aggregation layers. Each aggregation networks inter-connects network inter-
   connects with multiple access networks. For example, a 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.

   MPLS-TP Use Case and Design Considerations
   Expires December 2012

  4.3.2. LTE Mobile Backhaul

   One key difference between LTE and 2G/3G Mobile networks is that the
   logical connection in LTE is mesh while 2G/3G is P2P star
   connections.

   In LTE, the base stations eNB/BTS can communicate with multiple
   Network controllers (PSW/SGW or ASNGW), and each Radio element can
   communicate with each other for signal exchange and traffic offload
   to wireless or Wireline infrastructures.

   IP/MPLS may have a great advantage in any-to-any connectivity
   environment. The use of mature IP or L3VPN technologies is
   particularly common in the design of SP's LTE deployment plan.

   MPLS-TP can also bring advantages with the in-band OAM and path
   protection mechanism. MPLS-TP dynamic control-plane with GMPLS
   signaling may bring additional advantages in the mesh environment
   for real time adaptivities, dynamic topology changes, and network
   optimization.

   Since MPLS-TP is part of the MPLS family. Many component already
   shared by both IP/MPLS and MPLS-TP, the line can be further blurred
   by sharing more common features. For example, it is desirable for
   many SPs to introduce the in-band OAM developed for MPLS-TP back
   into IP/MPLS networks as an enhanced OAM option. Today's MPLS PW can
   also be set statically to be deterministic if preferred by the SPs
   without going through full MPLS-TP deployment.

  4.3.3. WiMAX Backhaul
   WiMAX Mobile backhaul shares the similar characteristics as LTE,
   with mesh connections rather than P2P, star logical connections.

5. Network Design Considerations

   5.1. IP/MPLS vs. MPLS-TP

   Questions one might hear: I have just built a new IP/MPLS network to
   support multi-services, including L2/L3 VPNs, Internet service,
   IPTV, etc. Now there is new MPLS-TP development in IETF. Do I need
   to move onto MPLS-TP technology to state current with technologies?
   MPLS-TP Use Case and Design Considerations
   Expires December 2012

   The answer is no. MPLS-TP is developed to meet the needs of
   traditional transport moving towards packet. It is designed to
   support the transport behavior coming with the long history. IP/MPLS
   and MPLS-TP both are state of art technologies. IP/MPLS support both
   transport (e.g. PW, RSVP-TE, etc.) and services (e.g L2/L3 VPNs,
   IPTV, Mobile RAN, etc.), MPLS-TP provides transport only. The new
   enhanced OAM features built in MPLS-TP should be share in both
   flavors through future implementation.

   Another common question: I need to evolve my ATM/TDM/SONET/SDH
   networks into new packet technologies, but my operational force is
   largely legacy transport, not familiar with new data technologies,
   and I want to maintain the same operational model for the time
   being, what should I do? The answer would be: MPLS-TP may be the
   best choice today for the transition.

   A few important factors need to be considered for IP/MPLS or MPLS-TP
   include:

   - Technology maturity (IP/MPLS is much more mature with 12 years
   development)
   - Operation experience (Work force experience, Union agreement, how
   easy to transition to a new technology? how much does it cost?)
   - Needs for Multi-service support on the same node (MPLS-TP provide
   transport only, does not replace many functions of IP/MPLS)
   - LTE, IPTV/Video distribution considerations (which path is the
   most viable for reaching the end goal with minimal cost? but it also
   meet the need of today's support)

   5.2. Standards compliance

   It is generally recognized by SPs that standards compliance are
   important for driving the cost down and product maturity up, multi-
   vendor interoperability, also important to meet the expectation of
   the business customers of SP's.

   MPLS-TP is a joint work between IETF and ITU-T. In April 2008, IETF
   and ITU-T jointly agreed to terminate T-MPLS and progress MPLS-TP as
   joint work [RFC 5317]. The transport requirements would be provided
   by ITU-T, the protocols would be developed in IETF.

   Today, majority of the core set of MPLS-TP protocol definitions are
   published as IETF RFCs already. It is important to deploy the
   solutions based on the standards definitions, in order to ensure the
   compatibility between MPLS-TP and IP/MPLS networks, and the
   interoperability among different equipment by different vendors.

   MPLS-TP Use Case and Design Considerations
   Expires December 2012

   Note that using non-standards, e.g. experimental code point is not
   recommended practice, it bares the risk of code-point collision, as
   indicated by [RFC 3692]: It can lead to interoperability problems
   when the chosen value collides with a different usage, as it someday
   surely will.

   5.3. End-to-end MPLS OAM consistency

   In the case Service Providers deploy end-to-end MPLS solution with
   the combination of dynamic IP/MPLS and static or dynamic MPLS-TP
   cross core, service edge, and aggregation/access networks, end-to-
   end MPLS OAM consistency becomes an essential requirements from many
   Service Provider. The end-to-end MPLS OAM can only be achieved
   through implementation of IETF MPLS-TP OAM definitions.

   5.4. PW Design considerations in MPLS-TP networks

   In general, PW works the same as in IP/MPLS network, both SS-PW and
   MS-PW are supported.

   For dynamic control plane, tLDP is used. For static provisioning is
   used, PW status is a new PW OAM feature for failure notification.

   In addition, both directions of a PW must be bound to the same
   transport bidirectional LSP.

   When multi-tier rings involved in the network topology, should S-PE
   be used or not? It is a design trade-off.

        . Pros for using S-PE
             .  Domain isolation, may facilitate trouble shooting
             .  the PW failure recovery may be quicker
        .  Cons for using S-PE
             .  Adds more complexity
             .  If the operation simplicity is the high priority, some
               SPs choose not to use S-PE, simply forming longer path
               across primary and secondary rings.

   Should PW protection for the same end points be considered? It is
   another design trade-off.

        . Pros for using PW protection
             .  PW is protected when both working and protect LSPs
               carrying the working PW fails as long as the protection
               PW is following a diverse LSP path from the one
               carrying the working PW.

   MPLS-TP Use Case and Design Considerations
   Expires December 2012

        . Cons for using PW protection
             . Adds more complexity, some may choose not to use if
               protection against single point of failure is
               sufficient.

   5.5. Proactive and event driven MPLS-TP OAM tools

   MPLS-TP provide both proactive tools and event drive OAM Tools.

   E.g. in the proactive fashion, the BFD hellos can be sent every 3.3
   ms as its lowest interval, 3 missed hellos would be trigger the
   failure protection switch over. BFD sessions should be configured
   for both working and protecting LSPs.

   When Unidirectional Failure occurs, RDI will send the failure
   notification to the opposite direction to trigger both end switch
   over.

   In the reactive fashion, when there is a fiber cut for example, LDI
   message would be generated from the failure point and propagate to
   MEP to trigger immediate switch over from working to protect path.
   And AIS would propagate from MIP to MEP for alarm suppression.

   Should both proactive and event driven OAM tools be used? The answer
   is yes.

   Should BFD timers be set as low as possible? It depends on the
   applications. In many cases, it is not necessary. The lower the
   times are, the faster the detection time, and also the higher
   resource utilization. It is good to choose a balance point.

   5.6. MPLS-TP and IP/MPLS Interworking considerations

   Since IP/MPLS is largely deployment in most networks, MPLS-TP and
   IP/MPLS interworking is a reality.

   Typically, there is peer model and overlay model.

   The inter-connection can be simply VLAN, or PW, or could be MPLS-TE.
   A separate document is addressing the in the interworking issues,
   please refer to the descriptions in [Interworking].

   5.7. Delay and delay variation
   MPLS-TP Use Case and Design Considerations
   Expires December 2012

   Background/motivation: Telecommunication Carriers plan to replace
   the aging TDM Services (e.g. legacy VPN services) provided by Legacy
   TDM technologies/equipments to new VPN services provided by MPLS-TP
   technologies/equipments with minimal cost. The Carriers cannot allow
   any degradation of service quality, service operation Level, and
   service availability when migrating out of Legacy TDM
   technologies/equipments to MPLS-TP transport. The requirements from
   the customers of these carriers are the same before and after the
   migration.

  5.7.1. Network Delay

   From our recent observation, more and more Ethernet VPN customers
   becoming very sensitive to the network delay issues, especially the
   financial customers. Many of those customers has upgraded their
   systems in their Data Centers, e.g., their accounting systems.  Some
   of the customers built the special tuned up networks, i.e. Fiber
   channel networks, in their Data Centers, this tripped more strict
   delay requirements Mobile
   RAN. The P2P connections from base station to Radio Controller can be
   set statically to mimic the carriers.

   There are three types operation of network delay:

   1. Absolute Delay Time

   Absolute Delay Time here is today's RAN environments;
   in-band OAM and deterministic path protection can support fast
   failure detection and switch-over to satisfy 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 agreements.

INTERNET DRAFT              <Document Title>                <Issue Date>

   Bidirectional LSPs may help to simplify the Private Line
   Service is provisioned.

   2. Variation of Absolute Delay Time (without network configuration
   changes). provisioning process. The variation under discussion here
   deterministic nature of MPLS-TP LSP set up can also support packet
   based synchronization to maintain predictable performance regarding
   packet delay and jitters.

3.3.2. 4G/LTE Mobile Backhaul

   One key difference between LTE and 2G/3G Mobile networks is mainly induced by that the
   buffering
   logical connection in network elements.

   Although there LTE is no description of Variation of Absolute Delay Time
   on a mesh, while in 2G/3G is a P2P star. In
   LTE, the contract, this has no practical impact on base stations eNB/BTS communicate with multiple Network
   controllers (PSW/SGW or ASNGW), and the customers who
   contract radio elements communicate
   with one another for signal exchange and traffic offload to wireless
   or wireline infrastructures.

   IP/MPLS has a great advantage in any-to-any connectivity environment.
   Thus, the highest quality use of services available. The
   bandwidth is guaranteed for those customers' traffic.

   3. Relative Delay Time

   Relative Delay Time mature IP or L3VPN technologies is particularly
   common in the difference design of the Absolute Delay Time
   between using working and protect path.

   MPLS-TP Use Case SP's LTE deployment plans.

   The extended OAM functions defined in MPLS-TP, such as in-band OAM
   and Design Considerations
   Expires December 2012

   Ideally, Carriers would prefer the Relative Delay Time path protection mechanisms bring additional advantages to be zero, support
   SLAs. The dynamic control-plane with GMPLS signaling is especially
   suited for the following technical reasons mesh environment, to support dynamic topology changes
   and network operation
   feasibility concerns. optimization.

5. Network Design Considerations

5.1. The role of MPLS-TP

   The following are the three technical reasons:

   Legacy throughput issue

   In the case that Relative Delay Time role of MPLS-TP is increased between FC
   networks or TCP networks, the effective throughput to provide a solution to help evolving
   traditional transport towards packet. It is degraded.  The
   effective throughput, though it may be recovered after revert back designed to support the original working path in revertive mode.

   On the other hand,
   transport characteristics/behavior described 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 [RFC5654]. The
   primary use of busty
   packets.  As a consequence, effective throughput MPLS-TP is degraded largely to replace legacy transport
   technologies, such as
   well.  Moreover, if packet reordering SONET/SDH. MPLS-TP is occurred due not designed to RTT
   decrease, unnecessary packet resending is induced and effective
   throughput is also further degraded.  Therefore, management replace
   the service support capabilities of
   Relative Delay Time is preferred, although this is known IP/MPLS, such as the
   legacy TCP throughput issue.

   Locating Network Acceralators at CE

   In order to improve effective throughput between customer's FC
   networks over Ethernet private line service, some customer put "WAN
   Accelerator" to increase throughput value.  For example, some WAN
   Accelerators at receiving side may automatically send back "R_RDY"
   in order to avoid decreasing L2VPN, L3VPN,
   IPTV, Mobile RAN, etc.

5.2 Provisioning mode

   MPLS-TP supports two provisioning modes: i) a number of BBcredit at sending side, mandatory static
   provisioning mode, which must be supported without dependency on
   dynamic routing or signaling; 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 ii) an optional distributed dynamic
   control plane, which is because a lot of
   packet destruction may be occurred due used to loss of synchronization,
   when change of Relative delay time induces packet reordering.  And,
   it is difficult enable dynamic service provisioning.

   The decision on which mode to re-tune up their CE network element automatically
   when Relative Delay Time use is changed, because only less than 50 ms
   network down detected at CE.

   Depending largely dependent on the tuning up method, since Relative Delay Time affects
   effective throughput between customer's FC networks, management
   operational feasibility and the stage of
   Relative Delay Time evolution transition.
   Operators who are accustomed with the transport-centric operational

INTERNET DRAFT              <Document Title>                <Issue Date>

   model (e.g., NMS configuration without control plane) typically
   prefer the static provisioning mode. This is preferred.

   c) Use of synchronized replication system
   MPLS-TP Use Case and Design Considerations
   Expires December 2012

   Some strict customers, e.g. financial customers, implement
   "synchronized replication system" for all data back-up and load
   sharing.  Due to synchronized replication system, next data
   processing the most common choice
   in current deployments. The dynamic provisioning mode can be more
   powerful but it is conducted only after finishing more suited for operators who are familiar with
   the data saving operation and maintenance of IP/MPLS technologies or ready to both
   primary
   step up through training and replication DC storage.  And some tuning function could planned transition.

   There may be applied at Server Network to increase throughput also cases where operators choose to use the
   replication DC and Client Network. Since Relative Delay Time affects
   effective throughput, management combination
   of Relative Delay Time both modes. This is
   preferred.

   The following are appropriate when parts of the network operational feasibility issues.

   Some strict customers, e.g., financial customer, continuously
   checked the private line connectivity are
   provisioned in a static fashion and absolute delay time at
   CEs.  When the absolute delay time other parts are controlled by
   dynamic signaling. This combination may also be used to transition
   from static provisioning to dynamic control plane.

5.3. Standards compliance

   It is changed, generally recognized by SPs that standards compliance is Relative
   delay time is increased or decreased, the customer would complain.

   From network operational point of view, carrier want to minimize
   important for lowering cost, accelerating product maturity, achieving
   multi-vendor interoperability, and meeting the
   number expectations of customers complains, their
   enterprise customers.

   MPLS-TP LSP provisioning with zero
   Relative delay time is preferred a joint work between IETF 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 ITU-T. In April 2008, IETF
   and ITU-T jointly agreed to keep the lesser Absolute Delay
   Time condition terminate T-MPLS and would complain why Carrier did not provide progress MPLS-TP as
   joint work [RFC5317]. The transport requirements are provided by ITU-
   T, the
   best solution protocols are developed in the first place. Therefore, MPLS-TP LSP
   provisioning with zero Relative Delay Time is preferred and
   management of Relative Delay Time IETF.

5.4. End-to-end MPLS OAM consistency

   End-to-end MPLS OAM consistency is preferred.

   More discussion will be added on how to manage the Relative delay
   time.

   5.8. More on MPLS-TP Deployment Considerations

   5.8.1. Network Modes Selection

   When considering deployment of MPLS-TP highly desirable 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 order to
   enable Service Providers to deploy end-to-end MPLS solution with MPLS-TP simultaneously? If
   MPLS-TP and a
   combination of IP/MPLS is deployed (for example, in the same network, what is the
   relationship between MPLS-TP and IP/MPLS (e.g., peer or overlay?) core including service
   edge) and where is the demarcation between MPLS-TP domain and IP/MPLS (for example, in the aggregation/access networks).
   Using MPLS based OAM in MPLS-TP Use Case and can help achieving such a goal.

5.5. PW Design Considerations
   Expires December 2012

   domain? The results for these questions depend on the real
   requirements on how considerations in MPLS-TP and networks

   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 used to provide
   services. supported.
   For different services, there could dynamic control plane, Targeted LDP (tLDP) is used. In static
   provisioning mode, PW status is a new PW OAM feature for failure
   notification. In addition, both directions of a PW must be different choice.
   According bound to
   the combination of MPLS-TP and IP/MPLS, here are some
   typical network modes:

   Pure MPLS-TP as the same transport connectivity (E2E MPLS-TP), this
   situation more happens when bidirectional LSP.

   In the common network topology involving multi-tier rings, the design
   choice is a totally new constructed
   network. For example, a new constructed packet transport network for
   Mobile Backhaul, between using SS-PW or migration from ATM/TDM transport network MS-PW. This is not a discussion
   unique to
   packet based transport network.

   Pure IP/MPLS MPLS-TP, as transport connectivity (E2E IP/MPLS), this it applies to PW design in general, but it 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.
   relevant here, since MPLS-TP
   domains and IP/MPLS domains are interconnected is more sensitive to provide transport
   connectivity. Considering there are a lot of IP/MPLS deployments in the field, this mode may operational
   complexities, as noted by operators. If MS-PW is used, Switched PE
   (S-PE) must be deployed to connect the normal practice in the early stage
   of MPLS-TP deployment.

   Overlay mode:
   b-1: MPLS-TP as client rings. The advantage of IP/MPLS, this

INTERNET DRAFT              <Document Title>                <Issue Date>

   choice is for the case where MPLS-
   TP domains are distributed that it provides domain isolation, which in turn
   facilitates trouble shooting and IP/MPLS do-main/network is used allows for faster PW failure
   recovery. On the connection other hand, the disadvantage of using S-PE is that
   it adds more complexity. Using SS-PW is simpler, since it does not
   require S-PEs, but less efficient because the distributed MPLS-TP domains. For examples,
   there paths across primary
   and secondary rings are longer. If operational simplicity is a higher
   priority, some service providers who have no their own Backhaul
   network, they have SPs choose the latter.

   Another design trade-off is whether to use PW protection in addition
   to rent LSP protection or rely solely on LSP protection. By definition,
   MPLS-TP LSPs are protected. If the Backhaul network working LSP fails, the protect LSP
   assures that the connectivity is IP/MPLS
   based from other service providers.

   b-2: IP/MPLS as client of MPLS-TP, this maintained and the PW is for not
   impacted. However, in the case where
   transport network below of simultaneous failure of both
   working and protect LSPs, the IP/MPLS network is a MPLS-TP based
   network, attached PW would fail. By adding PW
   protection, and attaching the MPLS-TP network provides transport connectivity for protect PW to a diverse LSP not in the
   IP/MPLS routers,
   same Shared Risk Link Group (SRLG), the usage PW is analogous as today's ATM/TDM/SDH based
   transport network that are used for providing connectivity for
   IP/MPLS routers.

   5.8.2. Provisioning Modes Selection

   As stated in MPLS-TP requirements [RFC 5654], MPLS-TP network MUST
   be possible to work without protected even when the
   primary PW fails.  Clearly, using Control Plane. And this does not
   mean that MPLS-TP network has no control plane. Instead, PW protection adds considerably
   more complexity and resource usage, and thus 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 often may
   choose not to use it, and dynamic
   provisioning (Hybrid mode). Each mode has its own pros consider protection against single point of
   failure as sufficient.

5.6. Proactive and cons on-demand MPLS-TP OAM tools

   MPLS-TP provide both proactive and
   how to determine the right mode on-demand OAM Tools. As a
   proactive OAM fault management tool, BFD hellos can be sent at
   regular intervals for a specific network mainly
   MPLS-TP Use Case and Design Considerations
   Expires December 2012

   depends on the operators' preference. For Connectivity Check; 3 missed hellos trigger the operators who
   failure protection switch-over. BFD sessions are used
   to operate traditional transport network configured for both
   working and familiar with protecting LSPs.

   A design decision is choosing the
   Transport-Centric operational model (e.g., NMS configuration without
   control plane) may prefer static provisioning mode. value of the BFD hello interval.
   The dynamic
   provisioning mode shorter the interval (3.3ms is more suitable for the operators who are
   familiar with minimum allowed interval), the operation and maintenance of IP/MPLS network where
   a fully dynamic control plane is used.
   faster the detection time is, but also the higher the resource
   utilization is. The hybrid mode may be used
   when parts of proper value depends on the network are provisioned with static way application and the
   other parts are controlled by dynamic signaling. For example,
   service needs.

   As an on-demand OAM fault management mechanism, for
   big SP, the network example when
   there is a fiber cut, Link Down Indication (LDI) message [RFC6427] is operated
   generated from the failure point and maintained by several different
   departments who prefer propagated to different modes, thus they could adopt
   this hybrid mode the Maintenance
   End Points (MEPs) to support trigger immediate switch-over from working to
   protect path. An Alarm Indication Signal (AIS) propagates from the
   Maintenance Intermediate Point (MIP) to the MEPs for alarm
   suppression.

   In general, both static proactive and dynamic modes hence on-demand OAM tools should be enabled
   to
   satisfy different requirements. Another example guarantee short switch-over times.

5.7. MPLS-TP and IP/MPLS Interworking considerations
INTERNET DRAFT              <Document Title>                <Issue Date>

   Since IP/MPLS is that static
   provisioning mode largely deployed in most SPs' networks, MPLS-TP and
   IP/MPLS interworking is suitable for a reality.

   The interworking issues are addressed in a separate document
   [Interworking].

6. Security Considerations

   In the use case of Metro access and aggregation, in the scenario
   where some parts of the network and
   dynamic access equipment is placed in facilities not owned
   by the SP, the static provisioning mode of MPLS-TP is suitable for other parts often preferred
   over the control plane option because it eliminates the possibility
   of a control plane attack which may potentially impact the
   networks (e.g., static for access network, dynamic for metro
   aggregate whole
   network.

   Similar location issues apply to the mobile use cases, since
   equipment is often placed in remote and core network).

6. Security Considerations outdoor environment, which
   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
   use cases. General security considerations for MPLS and GMPLS
   networks are addressed in Security Framework for MPLS and GMPLS Networks[RFC 5920].
   Networks [RFC5920]. General MPLS-TP security considerations are
   described in MPLS-TP Security Framework [MPLS-TP Sec FW]. No new security issues in this
   document.

7. IANA Considerations

   This document contains no new IANA considerations.

8. Acknowledgements

   The authors wish to thank Adrian Farrel for his review as Routing
   Area Director, Adrian's detailed comments were of great help for
   improving the quality of this document. The authors would also like
   to thank Loa Andersson for his continued support and guidance.

9.  References

9.1  Normative References

   [RFC 5317]: Joint

   [RFC5317]  Bryant, S., Ed., and L. Andersson, Ed., "Joint Working
              Team (JWT) Report on MPLS Architectural Considerations for
              a Transport Profile, Feb. Profile", RFC 5317, February 2009.

   [RFC 5654],

   [RFC5654]  Niven-Jenkins, B., et al, "MPLS-TP Requirements," Ed., Brungard, D., Ed., Betts, M., Ed.,
              Sprecher, N., and S. Ueno, "Requirements of an MPLS
              Transport Profile", RFC 5654, September 2009.

9. Informative References
   [RFC 2119] Bradner, S., "Key words

INTERNET DRAFT              <Document Title>                <Issue Date>

   [RFC5920]  Fang, L., Ed., "Security Framework for use in RFCs to Indicate
   Requirement Levels", BCP 14, MPLS and GMPLS
              Networks", RFC 2119, March 1997.

   [RFC 3692] T. Narten, "Assigning Experimental and Testing Numbers
   Considered Useful", 5920, July 2010.

   [RFC6426]  Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
              On-Demand Connectivity Verification and Route Tracing",
              RFC 3692, Jan. 2004.

   [RFC 5921] 6426, November 2011.

   [RFC6427]  Swallow, G., Ed., Fulignoli, A., Ed., Vigoureux, M., Ed.,
              Boutros, S., and D. Ward, "MPLS Fault Management
              Operations, Administration, and Maintenance (OAM)",
              RFC 6427, November 2011.

   [RFC6428]  Allan, D., Ed., Swallow Ed., G., and J. Drake Ed.,
              "Proactive Connectivity Verification, Continuity Check,
              and Remote Defect Indication for the MPLS Transport
              Profile", RFC 6428, November 2011.

9.2  Informative References

   [RFC5921]  Bocci, M., ED., Ed., Bryant, S., ED., et al., Ed., Frost, D. ED., D., Ed., Levrau,
              L., Berger., L., and L. Berger, "A Framework for MPLS in Transport," July
   2010.

   MPLS-TP Use Case and Design Considerations
   Expires December 2012

   [RFC 5920] Fang, L., ED., et al, "Security Framework for MPLS and
   GMPLS Networks," Transport
              Networks", RFC 5921, July 2010.

   [RFC 6372]

   [RFC6372]  Sprecher, N., Ferrel, A., MPLS transport Ed., and A. Farrel, Ed., "MPLS Transport
              Profile (MPLS-TP) Survivability Framework [RFC 6372], Framework", RFC 6372,
              September 2011.

   [OAM Tool Set]

   [RFC6669]  Sprecher, N., N. and L. Fang, L., "An Overview of the OAM Tool
   Set Operations,
              Administration, and Maintenance (OAM) Toolset for MPLS MPLS-
              Based Transport Networks,", draft-ietf-mpls-to-oam-
   analysis-09.txt, April 2012, work in progress. Networks", RFC 6669, July 2012.

   [Interworking] Martinotti, R., et al., "Interworking between MPLS-TP   MPLS-
   TP and IP/MPLS," draft-martinotti-mpls-tp-interworking-02.txt, June
   2011.

   [MPLS-TP Sec FW] Fang, L. ED., et al., "MPLS-TP Security Framework,"
   draft-ietf-mpls-tp-security-framework-03.txt, March
   draft-ietf-mpls-tp-security-framework-05.txt, October 2012.

10.     Author's

Authors' Addresses

      Luyuan Fang
      Cisco Systems, Inc.
      111 Wood Ave. South
      Iselin, NJ 08830
   USA
      United States
      Email: lufang@cisco.com

INTERNET DRAFT              <Document Title>                <Issue Date>

      Nabil Bitar
      Verizon
      40 Sylvan Road
      Waltham, MA 02145
   USA
      United States
      Email: nabil.bitar@verizon.com

      Raymond Zhang
      Alcatel-Lucent
      701 Middlefield Road
      Mountain View, CA 94043
      United States
      Email: raymond.zhang@alcatel-lucent.com

      Masahiro DAIKOKU
      KDDI corporation
      3-11-11.Iidabashi, Chiyodaku, Tokyo
      Japan
      Email: ms-daikoku@kddi.com
   MPLS-TP Use Case and Design Considerations
   Expires December 2012

      Ping Pan
      Infinera
      United States
      Email: ppan@infinera.com

Contributors' Address

      Kam Lee Yap
      XO Communications
      13865 Sunrise Valley Drive,
      Herndon, VA 20171
      United States
      Email: klyap@xo.com

      Dan Frost
      Cisco Systems, Inc.
      United Kingdom
      Email:danfrost@cisco.com

      Henry Yu
      TW Telecom
      10475 Park Meadow Dr.
      Littleton, CO 80124
      United States
      Email: henry.yu@twtelecom.com

      Jian Ping Zhang   China Telecom, Shanghai
      Room 3402, 211 Shi Ji Da Dao

INTERNET DRAFT              <Document Title>                <Issue Date>

      Pu Dong District, Shanghai
      China
      Email: zhangjp@shtel.com.cn

      Lei Wang
   Telenor
   Telenor
      Lime Networks
      Strandveien 30, 1366 Lysaker
      Norway
   Office Snaroyveien
   1331 Fornedbu
      Email: Lai.wang@telenor.com lei.wang@limenetworks.no

      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