INTERNET-DRAFT
Internet Engineering Task Force (IETF)                      L. Fang, Ed.
Intended Status: Informational
Request for Comments: 6965                                         Cisco
Expires: November 1, 2013
Category: Informational                                         N. Bitar
ISSN: 2070-1721                                                  Verizon
                                                                R. Zhang
                                                          Alcatel Lucent
                                                          Alcatel-Lucent
                                                              M. Daikoku
                                                                    KDDI
                                                                  P. Pan
                                                                Infinera

                                                             May 1,
                                                             August 2013

             MPLS-TP Applicability;

  MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design
             draft-ietf-mpls-tp-use-cases-and-design-08.txt

Abstract

   This document provides describes the applicability of Multiprotocol Label
   Switching the MPLS Transport
   Profile (MPLS-TP) with use case studies and network design
   considerations.  The use cases include Metro Ethernet access and
   aggregation transport, Mobile mobile backhaul, and packet optical transport.

Status of this This Memo

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

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum
   (IETF).  It represents the consensus of six months the IETF community.  It has
   received public review and may be updated, replaced, or obsoleted has been approved for publication by other the
   Internet Engineering Steering Group (IESG).  Not all documents at
   approved by the IESG are a candidate for any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list status of Internet-Draft Shadow Directories can this document, any errata,
   and how to provide feedback on it may be accessed obtained at
   http://www.ietf.org/shadow.html
   http://www.rfc-editor.org/info/rfc6965.

Copyright and License Notice

   Copyright (c) 2013 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. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3 ....................................................3
      1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3 ................................................3
      1.2. Background  . . . . . . . . . . . . . . . . . . . . . . . .  4 .................................................4
   2. MPLS-TP Use Cases . . . . . . . . . . . . . . . . . . . . . . .  6 ...............................................6
      2.1. Metro Access and Aggregation  . . . . . . . . . . . . . . .  6 ...............................6
      2.2. Packet Optical Transport  . . . . . . . . . . . . . . . . .  7 ...................................7
      2.3. Mobile Backhaul . . . . . . . . . . . . . . . . . . . . . .  7 ............................................8
           2.3.1. 2G and 3G Mobile Backhaul . . . . . . . . . . . . . . .  8 ...........................8
           2.3.2. 4G/LTE Mobile Backhaul  . . . . . . . . . . . . . . . .  8 ..............................9
   3. Network Design Considerations . . . . . . . . . . . . . . . . .  9 ..................................10
      3.1. The role Role of MPLS-TP . . . . . . . . . . . . . . . . . . . .  9 .......................................10
      3.2. Provisioning mode . . . . . . . . . . . . . . . . . . . . .  9 Mode .........................................10
      3.3. Standards compliance  . . . . . . . . . . . . . . . . . . . 10 Compliance ......................................10
      3.4. End-to-end End-to-End MPLS OAM consistency . . . . . . . . . . . . . . 10 Consistency ...........................11
      3.5. PW Design considerations Considerations in MPLS-TP networks  . . . . . . . 11 Networks ..............11
      3.6. Proactive and on-demand On-Demand MPLS-TP OAM tools . . . . . . . . . 11 Tools .................12
      3.7. MPLS-TP and IP/MPLS Interworking considerations . . . . . . 12 Considerations ...........12
   4. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 ........................................13
   5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12
   6. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 12
   7. ...............................................13
   6. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     7.1. .....................................................13
      6.1. Normative References  . . . . . . . . . . . . . . . . . . . 13
     7.2. ......................................13
      6.2. Informative References  . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
   Contributors' Addresses  . . . . . . . . . . . . . . . . . . . . . 15 ....................................14
   7. Contributors ...................................................15

1.  Introduction

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

1.1.  Terminology

      Term     Definition
      ------   -------------------------------------------------------
      2G       2nd generation wireless telephone of mobile telecommunications technology
      3G       3rd generation of mobile telecommunications technology
      4G       4th Generation Mobile network generation of mobile telecommunications technology
      ADSL     Asymmetric Digital Subscriber Line
      AIS      Alarm Indication Signal
      ASNGW    Access Service Network Gateway
      ATM      Asynchronous Transfer Mode
      BFD      Bidirectional Forwarding Detection
      BTS      Base Transceiver Station
      CC-CV
      CC-V     Continuity Check and Connectivity Verification
      CDMA     Code Division Multiple Access
      E-LINE   Ethernet line; provides point-to-point connectivity
      E-LAN    Ethernet LAN, LAN; provides multipoint connectivity
      eNB      Evolved Node B
      EPC      Evolved Packet Core
      E-VLAN   Ethernet Virtual Private LAN
      EVDO     Evolution-Data Optimized
      G-ACh    Generic Associated Channel
      GAL      G-ACh Label
      GMPLS    Generalized Multi-Protocol Multiprotocol Label Switching
      GSM      Global System for Mobile Communications
      HSPA     High Speed Packet Access
      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
      LSP      Label Switched Path
      LTE      Long Term Evolution
      MEP      Maintenance Entity Group End Point
      MIP      Maintenance Entity Group Intermediate Point
      MPLS     MultiProtocol     Multiprotocol Label Switching
      MPLS-TP  MultiProtocol Label Switching  MPLS Transport Profile
      MS-PW    Multi-Segment Pseudowire
      NMS      Network Management System
      OAM      Operations, Administration, and Maintenance
      OPEX     Operating Expenses
      PE       Provider-Edge device
      PDN GW   Packet Data Network Gateway
      PW       Pseudowire
      RAN      Radio Access Network
      RDI      Remote Defect Indication
      S-PE     PW Switching Provider Edge
      S1       LTE Standardized interface between eNB and EPC
      SDH      Synchronous Digital Hierarchy
      SGW      Serving Gateway
      SLA      Service Level Agreement
      SONET    Synchronous Optical Network
      S-PE     PW Switching Provider Edge
      SP       Service Provider
      SRLG     Shared Risk Link Groups
      SS-PW    Single-Segment Pseudowire
      TDM      Time Division      Time-Division Multiplexing
      TFS      Time and Frequency Synchronization
      tLDP     Targeted Label Distribution Protocol
      VPN      Virtual Private Network
      UMTS     Universal Mobile Telecommunications System
      VPN      Virtual Private Network
      X2       LTE Standardized interface between eNBs for handover

1.2.  Background

   Traditional transport technologies include SONET/SDH, TDM, and ATM.
   There is a transition away from these transport technologies to new
   packet transport technologies.  In addition to the increasing demand
   for bandwidth, packet transport technologies offer the following key
   advantages:

   Bandwidth efficiency:

   Traditional TDM transport technologies support fixed Bandwidth, bandwidth with
   no packet statistical multiplexing, the multiplexing.  The bandwidth is reserved in the
   transport network network, regardless of whether or not it is used by the client
   or not.
   client.  In contrast, packet technologies support statistical
   multiplexing.  This is the most important motivation for the
   transition from traditional transport technologies to packet
   transport technologies.  The proliferation of new distributed
   applications which that communicate with servers over the network in a
   bursty fashion has been driving the adoption of packet transport
   techniques, since packet multiplexing of traffic from bursty sources
   provides more efficient use of bandwidth than traditional circuit-
   based TDM technologies.

   Flexible data rate connections:

   The granularity of data rate connections of traditional transport
   technologies is limited to the rigid PDH Plesiochronous Digital Hierarchy
   (PDH) hierarchy (e.g., DS1, DS3) or SONET hierarchy (e.g., DS1, DS3, OC3, OC12, etc.).
   OC12).  Packet technologies support flexible data rate connections.
   The support of finer data rate granularity is particularly important
   for today's wireline and wireless services and applications.

   QoS support: While traditional

   Traditional transport technology, such technologies (such as TDM, has
   very limited QoS support, TDM) provide bandwidth
   guarantees, but they are unaware of the types of traffic they carry.
   They are not packet aware and do not provide packet-level services.
   Packet transport can provide proper QoS
   treatment for IPTV, Voice the differentiated services capability
   needed to support oversubscription and Video over IP applications. to deal with traffic
   prioritization upon congestion: issues that arise only in packet
   networks.

   The root cause for transport moving to packet transport is the shift
   of application applications from TDM to packet. For packet -- for example, Voice TDM to VoIP; VoIP,
   Video to Video over IP; IP, TDM access lines to Ethernet; Ethernet, and TDM VPNs to
   IP VPNs and Ethernet VPNs.  In addition, network convergence and
   technology refreshes contribute to the demand for a common and a
   flexible infrastructure that provides multiple services.

   As part of the MPLS family, MPLS-TP complements existing IP/MPLS
   technologies; it closes the gaps in the traditional access and
   aggregation transport to enable end-to-end packet technology
   solutions in a cost efficient, reliable, and interoperable manner.
   After several years of industry debate on which packet technology to
   use, MPLS-TP has emerged as the next generation transport technology
   of choice for many Service Providers worldwide.

   The Unified MPLS strategy - -- using MPLS from core to aggregation and
   access (e.g. (e.g., IP/MPLS in the core, IP/MPLS or MPLS-TP in aggregation
   and access) appear -- appears to be very attractive to many SPs.  It
   streamlines the operation, reduces the overall complexity, and
   improves end-to-
   end end-to-end convergence.  It leverages the MPLS experience, experience
   and enhances the ability to support revenue generating revenue-generating services.

   MPLS-TP is a subset of MPLS functions that meet the packet transport
   requirements defined in [RFC5654].  This subset includes: MPLS data
   forwarding, pseudo-wire pseudowire encapsulation for circuit emulation, and
   dynamic control plane using GMPLS control for LSP and tLDP for
   pseudo-wire
   pseudowire (PW).  MPLS-TP also extends previous MPLS OAM functions,
   such as the BFD extension for proactive Connectivity Check and
   Connectivity Verification (CC-CV) (CC-V) [RFC6428], and Remote Defect Indication
   (RDI) [RFC6428], and LSP Ping Extension for on-demand CC-CV CC-V [RFC6426].
   New tools have been defined for alarm suppression with Alarm
   Indication Signal (AIS) [RFC6427], [RFC6427] and switch-over triggering with
   Link Defect Down Indication (LDI) [RFC6427].  Note that since the MPLS OAM
   feature extensions defined through the process of MPLS-TP development
   are part of the MPLS family, the applicability is general to MPLS, MPLS and
   not limited to MPLS-TP.

   The requirements of MPLS-TP are provided in the MPLS-TP Requirements [RFC
   5654], requirements
   document [RFC5654], and the architectural framework is defined in the
   MPLS-TP
   Framework framework document [RFC5921].  This document's intent is to
   provide the use case studies and design considerations from a
   practical point of view based on Service Providers Providers' deployments plan plans
   as well as actual deployments.

   The most common use cases for MPLS-TP include Metro access and
   aggregation, Mobile Backhaul, mobile backhaul, and Packet Optical Transport. packet optical transport.  MPLS-TP
   data plane
   data-plane architecture, path protection mechanisms, and OAM
   functionality are used to support these deployment scenarios.

   The design considerations discussed in this document include: include the role
   of MPLS-TP in the network; network, provisioning options; options, standards
   compliance;
   compliance, end-to-end forwarding and OAM consistency; consistency, compatibility
   with existing IP/MPLS networks; networks, and optimization vs. simplicity
   design trade-offs.

2.  MPLS-TP Use Cases

2.1.  Metro Access and Aggregation

   The use of MPLS-TP for Metro access and aggregation transport is the
   most common deployment scenario observed in the field.

   Some operators are building green-field access and aggregation
   transport infrastructure, while others are upgrading/replacing upgrading or replacing
   their existing transport infrastructure with new packet technologies.
   The existing 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 support the rapid business
   growth and too expensive to maintain.  In addition, in many cases the
   legacy devices are facing End of Sale and End of Life issues.  As
   operators must move forward with the next generation next-generation packet
   technology, the adoption of MPLS-TP in access and aggregation becomes
   a natural choice.  The statistical multiplexing in MPLS-TP helps to
   achieve higher efficiency compared with the time division time-division scheme in
   the legacy technologies.  MPLS-TP OAM tools and protection mechanisms
   help to maintain high reliability of transport networks and achieve
   fast recovery.

   As most Service Providers' core networks are MPLS enabled, extending
   the MPLS technology to the aggregation and access transport networks
   with a Unified MPLS strategy is very attractive to many Service
   Providers.  Unified MPLS strategy in this document means having end-
   to-end
   end-to-end MPLS technologies through core, aggregation, and access.
   It reduces OPEX operating expenses by streamlining the operation and
   leveraging the operational experience already gained with MPLS
   technologies; it also improves network efficiency and reduces end-to-end end-to-
   end convergence time.

   The requirements from the SPs for ATM/TDM aggregation replacement
   often include: i)

   -  maintaining the previous operational model, which means providing
      a similar user experience in NMS, ii)

   -  supporting the existing access network, network (e.g., Ethernet, ADSL, ATM,
      TDM, etc.), etc.) and connections with the core networks, and iii)

   -  supporting the same operational capabilities and services (L3VPN,
      L2VPN, E-LINE/E-LAN/E-
   VLAN, E-LINE/E-LAN/E-VLAN, Dedicated Line, etc.).

   MPLS-TP can meet these requirements and and, in general general, the requirements
   defined in [RFC5654] to support a smooth transition.

2.2.  Packet Optical Transport

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

   Among other attributes, bandwidth management, protection/recovery protection/recovery,
   and OAM are critical in Packet/Optical packet/optical transport networks.  In the
   context of MPLS-TP, each LSP is expected to LSPs may be associated with a fixed amount
   of bandwidth in terms of bits-per-second and/or time-slots. allocation
   policies.  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.
   An overview of the MPLS-TP OAM toolset is found in [RFC6669].

   Protection [RFC6372]

   Protection, as defined in [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 increasingly important.

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

2.3.  Mobile Backhaul

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

2.3.1.  2G and 3G Mobile Backhaul

   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 mobile backhaul
   networks are still currently dominating the mobile infrastructure.

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

   Hierarchical or centralized architectures are often used for pre-
   aggregation
   pre-aggregation and aggregation layers.  Each aggregation network inter-
   connects
   interconnects with multiple access networks.  For example, a single
   aggregation ring could aggregate traffic for 10 access rings with a
   total of 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 connections from base station to Radio
   Controller can be set statically to mimic the operation of today's
   RAN environments; in-band OAM and deterministic path protection can
   support fast failure detection and switch-over to satisfy the SLA agreements. service
   level agreements (SLAs).  Bidirectional LSPs may help to simplify the
   provisioning process.  The deterministic nature of MPLS-TP LSP set up setup
   can also support packet
   based packet-based synchronization to maintain predictable
   performance regarding packet delay and jitters. jitter.  The traffic traffic-
   engineered and co-routed bidirectional properties of an MPLS-TP LSP
   are of benefit in transporting packet based packet-based Time and Frequency
   Synchronization (TFS)
   protocols protocols, such as [1588overmpls]. [TICTOC].  However, the
   choice between an external, physical layer physical-layer method or packet based a packet-based
   TFS method is network dependent and thus is out of scope of this
   document.

2.3.2.  4G/LTE Mobile Backhaul

   One key difference between LTE and 2G/3G mobile networks is that the
   logical connection in LTE is a mesh, while in 2G/3G it is a P2P star.
   In LTE, the each base stations eNB/BTS communicate station (eNB/BTS) communicates with multiple Network
   network controllers (PDN GW/SGW or ASNGW), (e.g., Packet Data Network Gateway, Packet Data
   Network Serving Gateway, Access Service Network Gateway), and the
   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
   environments.  Thus, the use of mature IP or L3VPN technologies is
   particularly common in the design of an SP's LTE deployment plans.

   The extended OAM functions defined in MPLS-TP, such as in-band OAM
   and path protection mechanisms mechanisms, bring additional advantages to
   support SLAs.  The dynamic control-plane control plane with GMPLS signaling is
   especially suited for the mesh environment, to support dynamic
   topology changes and network optimization.

   Some operators are using the same model as in 2G and 3G Mobile
   Backhaul, mobile
   backhaul, which uses IP/MPLS in the core, core and MPLS-TP with static
   provisioning (through NMS) in aggregation and access.  The reasoning
   is as follows: currently, the X2 traffic load in LTE networks currently may be
   a very small percentage of the total traffic.  For example, one large
   mobile operator observed that X2 traffic was less than one percent of
   the total S1 traffic.  Therefore, optimizing the X2 traffic may not
   be the design objective in this case.  The X2 traffic can be carried
   through the same static tunnels together with the S1 traffic in the
   aggregation and access networks, networks and further forwarded across the
   IP/MPLS core.  In addition, mesh protection may be more efficient
   with regard to bandwidth utilization, but linear protection and ring
   protection are often considered simpler by some operators from the
   point of view of operation maintenance and trouble shooting, troubleshooting, and so
   are widely deployed.  In general, using MPLS-TP with static
   provisioning for LTE backhaul is a viable option.  The design
   objective of using this approach is to keep the operation simple and
   use a common model for mobile backhaul, especially during the
   transition period.

   The TFS considerations stated in Section 3.3.1 2.3.1 apply to the 4G/LTE
   Mobile Backhaul
   mobile backhaul case as well.

3.  Network Design Considerations

3.1.  The role Role of MPLS-TP

   The role of MPLS-TP is to provide a solution to help evolve
   traditional transport towards packet. packet transport networks.  It is
   designed to support the transport characteristics/behavior characteristics and behavior
   described in [RFC5654].  The primary use of MPLS-TP is largely to
   replace legacy transport technologies, such as SONET/SDH.  MPLS-TP is
   not designed to replace the service support capabilities of IP/MPLS,
   such as L2VPN, L3VPN, IPTV, Mobile RAN, etc.

3.2.  Provisioning mode Mode

   MPLS-TP supports two provisioning modes: i)

   -  a mandatory static provisioning mode, which must be supported
      without dependency on dynamic routing or signaling; and ii)

   -  an optional distributed dynamic control plane, which is used to
      enable dynamic service provisioning.

   The decision on which mode to use is largely dependent on the
   operational feasibility and the stage of network transition.
   Operators who are accustomed to the transport-centric operational
   model (e.g., NMS configuration without control plane) typically
   prefer the static provisioning mode.  This is the most common choice
   in current deployments.  The dynamic provisioning mode can be more
   powerful
   powerful, but it is more suited to operators who are familiar with
   the operation and maintenance of IP/MPLS technologies or are ready to
   step up through training and planned transition.

   There may be also be cases where operators choose to use the combination
   of both modes.  This is appropriate when parts of the network are
   provisioned in a static fashion fashion, and other parts are controlled by
   dynamic signaling.  This combination may also be used to transition
   from static provisioning to dynamic control plane.

3.3.  Standards compliance

   It is generally recognized by Compliance

   SPs generally recognize that standards compliance is important for
   lowering cost, accelerating product maturity, achieving multi-vendor
   interoperability, and meeting the expectations of their enterprise
   customers.

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

3.4. End-to-end  End-to-End MPLS OAM consistency Consistency

   End-to-end MPLS OAM consistency is highly desirable in order to
   enable Service Providers to deploy an end-to-end MPLS solution.  As
   MPLS-TP adds OAM function to the MPLS toolkit, it cannot be expected
   that a full-function end-to-end LSP with MPLS-TP OAM can be achieved
   when the LSP traverses a legacy MPLS/IP core.  Although it may be
   possible to select a subset of MPLS-TP OAM that can be gatewayed to
   the legacy MPLS/IP OAM, a better solution is achieved by tunneling
   the MPLS-TP LSP over the legacy MPLS/IP network.  In that mode of
   operation, legacy OAM may be run on the tunnel in the core, and the
   tunnel end-points endpoints may report issues in as much detail as possible to
   the MIPs in the MPLS-TP LSP.  Note that over time it is expected that
   routers in the MPLS/IP core will be upgraded to fully support MPLS-TP
   features: once
   features.  Once this has occurred, it will be possible to run end-to-
   end
   end-to-end MPLS-TP LSPs seamlessly across the core.

3.5.  PW Design considerations Considerations in MPLS-TP networks 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
   supported.  For 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
   bound to the same transport bidirectional LSP.

   In the common network topology involving multi-tier rings, the design
   choice is between using SS-PW or MS-PW.  This is not a discussion
   unique to MPLS-TP, as it applies to PW design in general, but general.  However,
   it is relevant here, since MPLS-TP is more sensitive to the
   operational complexities, as noted by operators.  If MS-PW is used, Switched
   Switching PE (S-PE) must be deployed to connect the rings.  The
   advantage of this choice is that it provides domain isolation, which
   in turn facilitates trouble shooting troubleshooting and allows for faster PW failure
   recovery.  On the other hand, the disadvantage of using S-PE is that
   it adds more complexity.  Using SS-PW is simpler, since it does not
   require S-PEs, but it is less efficient because the paths across
   primary and secondary rings are longer.  If operational simplicity is
   a higher priority, some SPs choose the latter. SS-PW.

   Another design trade-off is whether to use PW protection in addition
   to LSP protection or rely solely on LSP protection.  When the MPLS-TP
   LSPs are protected, if the working LSP fails, the protect protecting LSP
   assures that the connectivity is maintained and the PW is not
   impacted.  However, in the case of simultaneous failure of both the
   working and
   protect protecting LSPs, the attached PW would fail.  By adding
   PW protection, protection and attaching the protect protecting PW to a diverse LSP not in
   the same Shared Risk Link Group (SRLG), the PW is protected even when
   the primary PW fails.  Clearly, using PW protection adds considerably
   more complexity and resource usage, and thus operators often may
   choose not to use it, it and consider protection against a single point
   of failure as sufficient.

3.6.  Proactive and on-demand On-Demand MPLS-TP OAM tools Tools

   MPLS-TP provide provides both proactive and on-demand OAM Tools. tools.  As a
   proactive OAM fault management tool, BFD Connectivity Check (CC) can
   be sent at regular intervals for Connectivity Check; three missed CC
   messages (or a
   configurable number) of missed CC messages can trigger the failure
   protection switch-over.  BFD sessions are configured for both working
   and protecting LSPs.

   A design decision is choosing the value of the BFD CC interval.  The
   shorter the interval, the faster the detection time is, but also the
   higher the resource utilization is.  The proper value depends on the
   application and the service needs. needs, as well as the protection
   mechanism provided at the lower layer.

   As an on-demand OAM fault management mechanism, for example mechanism (for example, when
   there is a fiber cut, cut), a Link Down Indication (LDI) message [RFC6427]
   can be generated from the failure point and propagated to the
   Maintenance Entity Group End Points (MEPs) to trigger immediate
   switch-over from working to protect protecting path.  An Alarm Indication
   Signal (AIS) can be propagated from the Maintenance Entity Group
   Intermediate Point (MIP) to the MEPs for alarm suppression.

   In general, both proactive and on-demand OAM tools should be enabled
   to guarantee short switch-over times.

3.7.  MPLS-TP and IP/MPLS Interworking considerations Considerations

   Since IP/MPLS is largely deployed in most SPs' networks, MPLS-TP and
   IP/MPLS Interworking interworking is inevitable if not a reality.  However,
   Interworking
   interworking discussion is out of the scope of this document; it is
   for further study.

4.  Security Considerations

   Under the use case of Metro access and aggregation, in the scenario
   where some of the access equipment is placed in facilities not owned
   by the SP, the static provisioning mode of MPLS-TP is often preferred
   over the control plane control-plane option because it eliminates the possibility
   of a control plane attack control-plane attack, which may potentially impact the whole
   network.  This scenario falls into the Security Reference Model 2 as
   described in [RFC6941].

   Similar location issues apply to the mobile use cases, cases since equipment
   is often placed in remote and outdoor environment, which can increase
   the risk of un-authorized unauthorized access to the equipment.

   In general, NMS access can be a common point of attack in all MPLS-TP
   use cases, and attacks to GAL or G-ACh are unique security treats threats to
   MPLS-TP.  The MPLS-TP security considerations are discussed in the
   MPLS-TP
   Security Framework security framework [RFC6941].  General security
   considerations for MPLS and GMPLS networks are addressed in Security "Security
   Framework for MPLS and GMPLS Networks Networks" [RFC5920].

5. IANA Considerations

   This document contains no new IANA considerations.

6.  Acknowledgements

   The authors wish to thank Adrian Farrel for his review as Routing
   Area Director, Director and his continued support and guidance.  Adrian's
   detailed comments and suggestions were of great help for improving
   the quality of this document, and document.  In addition, the authors would like to
   thank the following individuals: Loa Andersson and Adrian Farrel for their his continued
   support and guidance.
   The authors would also like to thank guidance; Weiqiang Cheng for his helpful input on LTE Mobile
   mobile backhaul based on his knowledge and experience in real world deployment, thank
   deployment; Stewart Bryant for his text contribution on timing, thank timing; Russ
   Housley for his improvement suggestions, thank suggestions; Andrew Malis for his support
   and use case discussion, thank discussion; Pablo Frank, Lucy Yong, Huub van Helvoort,
   Tom Petch, Curtis Villamizar, and Paul Doolan for their comments and suggestions, thank
   suggestions; and Joseph Yee and Miguel Garcia for their APPSDIR and
   Gen-ART reviews and comments comments, respectively.

7.

6.  References

7.1.

6.1.  Normative References

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

   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
              Networks", RFC 5920, July 2010.

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

   [RFC6426]  Gray, E., Bahadur, N., Boutros, S., and R. Aggarwal, "MPLS
              On-Demand Connectivity Verification and Route Tracing",
              RFC 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.

7.2.

6.2. Informative References

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

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

   [RFC6669]  Sprecher, N. and L. Fang, "An Overview of the Operations,
              Administration, and Maintenance (OAM) Toolset for MPLS-
              Based Transport Networks", RFC 6669, July 2012.

   [RFC6941]  Fang, L. L., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed.,
              and R. Graveman, Ed., "MPLS-TP "MPLS Transport Profile (MPLS-TP)
              Security
              Framework," Framework", RFC 6941, April 2013.

   [1588overmpls],

   [TICTOC]   Davari, S., Oren, A., Bhatia, M., Roberts, P., Montini,
              L., and L. Montini, Martini, "Transporting Timing messages over
              MPLS
              Networks," draft-ietf-tictoc-1588overmpls-04.txt, February Networks", Work in Progress, June 2013.

Authors' Addresses

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

      Nabil Bitar
      Verizon
      40 Sylvan Road
      Waltham, MA 02145
      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

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

Contributors' Addresses

7.  Contributors

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

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

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

   Jian Ping Zhang
   China Telecom, Shanghai
   Room 3402, 211 Shi Ji Da Dao
   Pu Dong District, Shanghai
   China
      Email:
   EMail: zhangjp@shtel.com.cn

   Lei Wang
   Lime Networks
   Strandveien 30, 1366 Lysaker
   Norway
      Email:
   EMail: lei.wang@limenetworks.no

      Mach(Guoyi)

   Mach (Guoyi) Chen
   Huawei Technologies Co., Ltd.
   No. 3 Xinxi Road
   Shangdi Information Industry Base
   Hai-Dian District, Beijing 100085
   China
      Email:
   EMail: mach@huawei.com

   Nurit Sprecher
   Nokia Siemens Networks
   3 Hanagar St. Neve Ne'eman B
   Hod Hasharon, 45241
   Israel
      Email:
   EMail: nurit.sprecher@nsn.com

Authors' Addresses

   Luyuan Fang (editor)
   Cisco Systems, Inc.
   111 Wood Ave. South
   Iselin, NJ 08830
   United States
   EMail: lufang@cisco.com

   Nabil Bitar
   Verizon
   40 Sylvan Road
   Waltham, MA 02145
   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

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