GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6965

Internet Engineering Task Force (IETF) L. Fang, Ed. Request for Comments: 6965 Cisco Category: Informational N. Bitar ISSN: 2070-1721 Verizon

                                                              R. Zhang
                                                        Alcatel-Lucent
                                                            M. Daikoku
                                                                  KDDI
                                                                P. Pan
                                                              Infinera
                                                           August 2013
MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design

Abstract

 This document describes the applicability of 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 backhaul, and packet optical transport.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6965.

Fang, et al. Informational [Page 1] RFC 6965 MPLS-TP Use Cases and Design August 2013

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

Fang, et al. Informational [Page 2] RFC 6965 MPLS-TP Use Cases and Design August 2013

1. Introduction

 This document describes the applicability of the MPLS Transport
 Profile (MPLS-TP) with use case studies and network design
 considerations.

1.1. Terminology

    Term     Definition
    ------   -------------------------------------------------------
    2G       2nd generation of mobile telecommunications technology
    3G       3rd generation of mobile telecommunications technology
    4G       4th generation of mobile telecommunications technology
    ADSL     Asymmetric Digital Subscriber Line
    AIS      Alarm Indication Signal
    ATM      Asynchronous Transfer Mode
    BFD      Bidirectional Forwarding Detection
    BTS      Base Transceiver Station
    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; 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 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 Label Switching
    MPLS-TP  MPLS Transport Profile
    MS-PW    Multi-Segment Pseudowire
    NMS      Network Management System
    OAM      Operations, Administration, and Maintenance
    PE       Provider-Edge device
    PW       Pseudowire

Fang, et al. Informational [Page 3] RFC 6965 MPLS-TP Use Cases and Design August 2013

    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
    SONET    Synchronous Optical Network
    SP       Service Provider
    SRLG     Shared Risk Link Groups
    SS-PW    Single-Segment Pseudowire
    TDM      Time-Division Multiplexing
    TFS      Time and Frequency Synchronization
    tLDP     Targeted Label Distribution Protocol
    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 with
 no statistical multiplexing.  The bandwidth is reserved in the
 transport network, regardless of whether or not it is used by the
 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 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 Plesiochronous Digital Hierarchy
 (PDH) hierarchy (e.g., DS1, DS3) or SONET hierarchy (e.g., OC3,
 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.

Fang, et al. Informational [Page 4] RFC 6965 MPLS-TP Use Cases and Design August 2013

 QoS support:
 Traditional transport technologies (such as 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 the differentiated services capability
 needed to support oversubscription and 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 applications from TDM to packet -- for example, Voice TDM to VoIP,
 Video to Video over IP, TDM access lines to 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
 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., IP/MPLS in the core, IP/MPLS or MPLS-TP in aggregation
 and access) -- appears to be very attractive to many SPs.  It
 streamlines the operation, reduces the overall complexity, and
 improves end-to-end convergence.  It leverages the MPLS experience
 and enhances the ability to support revenue-generating services.
 MPLS-TP is a subset of MPLS functions that meet the packet transport
 requirements defined in [RFC5654].  This subset includes: MPLS data
 forwarding, pseudowire encapsulation for circuit emulation, and
 dynamic control plane using GMPLS control for LSP and tLDP for
 pseudowire (PW).  MPLS-TP also extends previous MPLS OAM functions,
 such as the BFD extension for proactive Connectivity Check and
 Connectivity Verification (CC-V) [RFC6428], Remote Defect Indication
 (RDI) [RFC6428], and LSP Ping Extension for on-demand CC-V [RFC6426].
 New tools have been defined for alarm suppression with Alarm
 Indication Signal (AIS) [RFC6427] and switch-over triggering with
 Link 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 and
 not limited to MPLS-TP.

Fang, et al. Informational [Page 5] RFC 6965 MPLS-TP Use Cases and Design August 2013

 The requirements of MPLS-TP are provided in the MPLS-TP requirements
 document [RFC5654], and the architectural framework is defined in the
 MPLS-TP 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' deployments plans
 as well as actual deployments.
 The most common use cases for MPLS-TP include Metro access and
 aggregation, mobile backhaul, and packet optical transport.  MPLS-TP
 data-plane architecture, path protection mechanisms, and OAM
 functionality are used to support these deployment scenarios.
 The design considerations discussed in this document include the role
 of MPLS-TP in the network, provisioning options, standards
 compliance, end-to-end forwarding and OAM consistency, compatibility
 with existing IP/MPLS networks, and optimization vs. simplicity
 design trade-offs.

2. MPLS-TP Use Cases

2.1. Metro Access and Aggregation

 The use of MPLS-TP for Metro access and aggregation transport is the
 most common deployment scenario observed in the field.
 Some operators are building green-field access and aggregation
 transport infrastructure, while others are 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 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 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 MPLS technologies through core, aggregation, and access.
 It reduces operating expenses by streamlining the operation and

Fang, et al. Informational [Page 6] RFC 6965 MPLS-TP Use Cases and Design August 2013

 leveraging the operational experience already gained with MPLS
 technologies; it also improves network efficiency and reduces end-to-
 end convergence time.
 The requirements from the SPs for ATM/TDM aggregation replacement
 often include:
  1. maintaining the previous operational model, which means providing

a similar user experience in NMS,

  1. supporting the existing access network (e.g., Ethernet, ADSL, ATM,

TDM, etc.) and connections with the core networks, and

  1. supporting the same operational capabilities and services (L3VPN,

L2VPN, E-LINE/E-LAN/E-VLAN, Dedicated Line, etc.).

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

2.2. Packet Optical Transport

 Many 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
 transport networks where the operators can utilize the MPLS-TP LSPs
 (including the ones statically provisioned) to manage user traffic as
 "circuits" in both packet and optical networks.  Also, when the
 operators are ready, they can migrate the network to use the 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, LSPs may be associated with bandwidth allocation
 policies.  OAM is to be performed on each individual LSP.  For some
 of the performance monitoring 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, 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.

Fang, et al. Informational [Page 7] RFC 6965 MPLS-TP Use Cases and Design August 2013

 In some cases, SPs plan to deploy MPLS-TP from their long-haul
 optical packet transport all the way to the aggregation and access in
 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 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 is data traffic).  MPLS-TP is viewed as a
 suitable technology for 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 are still currently dominating the mobile infrastructure.
 The connectivity for 2G/3G networks is point to point (P2P).  The
 logical connections 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 (RNC).  These connections are often statically set
 up.
 Hierarchical or centralized architectures are often used for
 pre-aggregation and aggregation layers.  Each aggregation network
 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 service
 level agreements (SLAs).  Bidirectional LSPs may help to simplify the
 provisioning process.  The deterministic nature of MPLS-TP LSP setup
 can also support packet-based synchronization to maintain predictable
 performance regarding packet delay and jitter.  The traffic-
 engineered and co-routed bidirectional properties of an MPLS-TP LSP

Fang, et al. Informational [Page 8] RFC 6965 MPLS-TP Use Cases and Design August 2013

 are of benefit in transporting packet-based Time and Frequency
 Synchronization (TFS) protocols, such as [TICTOC].  However, the
 choice between an external, physical-layer method or 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, each base station (eNB/BTS) communicates with multiple
 network controllers (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, bring additional advantages to
 support SLAs.  The dynamic 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, which uses IP/MPLS in the 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 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 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 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 2.3.1 apply to the 4G/LTE
 mobile backhaul case as well.

Fang, et al. Informational [Page 9] RFC 6965 MPLS-TP Use Cases and Design August 2013

3. Network Design Considerations

3.1. The Role of MPLS-TP

 The role of MPLS-TP is to provide a solution to help evolve
 traditional transport towards packet transport networks.  It is
 designed to support the transport 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

 MPLS-TP supports two provisioning modes:
  1. a mandatory static provisioning mode, which must be supported

without dependency on dynamic routing or signaling; and

  1. 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, 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 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, 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

 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.

Fang, et al. Informational [Page 10] RFC 6965 MPLS-TP Use Cases and Design August 2013

 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 the ITU-T; the protocols are developed in the IETF.

3.4. End-to-End MPLS OAM 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 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 this has occurred, it will be possible to run
 end-to-end MPLS-TP LSPs seamlessly across the core.

3.5. PW Design Considerations in MPLS-TP 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.  However,
 it is relevant here, since MPLS-TP is more sensitive to the
 operational complexities, as noted by operators.  If MS-PW is used,
 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 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 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 protecting LSP

Fang, et al. Informational [Page 11] RFC 6965 MPLS-TP Use Cases and Design August 2013

 assures that the connectivity is maintained and the PW is not
 impacted.  However, in the case of simultaneous failure of both the
 working and protecting LSPs, the attached PW would fail.  By adding
 PW protection and attaching the 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 and consider protection against a single point
 of failure as sufficient.

3.6. Proactive and On-Demand MPLS-TP OAM Tools

 MPLS-TP provides both proactive and on-demand OAM tools.  As a
 proactive OAM fault management tool, BFD Connectivity Check (CC) can
 be sent at regular intervals for Connectivity Check; three (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, as well as the protection
 mechanism provided at the lower layer.
 As an on-demand OAM fault management mechanism (for example, when
 there is a fiber 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 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

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

Fang, et al. Informational [Page 12] RFC 6965 MPLS-TP Use Cases and Design August 2013

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 option because it eliminates the possibility
 of a 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 since equipment
 is often placed in remote and outdoor environment, which can increase
 the risk of 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 threats to
 MPLS-TP.  The MPLS-TP security considerations are discussed in the
 MPLS-TP security framework [RFC6941].  General security
 considerations for MPLS and GMPLS networks are addressed in "Security
 Framework for MPLS and GMPLS Networks" [RFC5920].

5. Acknowledgements

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

6. References

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.

Fang, et al. Informational [Page 13] RFC 6965 MPLS-TP Use Cases and Design August 2013

 [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.

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., Ed., Niven-Jenkins, B., Ed., Mansfield, S., Ed.,
            and R. Graveman, Ed., "MPLS Transport Profile (MPLS-TP)
            Security Framework", RFC 6941, April 2013.
 [TICTOC]   Davari, S., Oren, A., Bhatia, M., Roberts, P., Montini,
            L., and L. Martini, "Transporting Timing messages over
            MPLS Networks", Work in Progress, June 2013.

Fang, et al. Informational [Page 14] RFC 6965 MPLS-TP Use Cases and Design August 2013

7. Contributors

 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
 Pu Dong District, Shanghai
 China
 EMail: zhangjp@shtel.com.cn
 Lei Wang
 Lime Networks
 Strandveien 30, 1366 Lysaker
 Norway
 EMail: 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

Fang, et al. Informational [Page 15] RFC 6965 MPLS-TP Use Cases and Design August 2013

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

Fang, et al. Informational [Page 16]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6965.txt · Last modified: 2013/08/01 16:42 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki