diff options
Diffstat (limited to 'doc/rfc/rfc6965.txt')
| -rw-r--r-- | doc/rfc/rfc6965.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc6965.txt b/doc/rfc/rfc6965.txt new file mode 100644 index 0000000..04c5dfa --- /dev/null +++ b/doc/rfc/rfc6965.txt @@ -0,0 +1,899 @@ + + + + + + +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: + + - maintaining the previous operational model, which means providing + a similar user experience in NMS, + + - supporting the existing access network (e.g., Ethernet, ADSL, ATM, + TDM, etc.) and connections with the core networks, and + + - 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: + + - a mandatory static provisioning mode, which must be supported + without dependency on dynamic routing or signaling; and + + - 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] + |