RFC 6965

MPLS Transport Profile (MPLS-TP) Applicability: Use Cases and Design 🦋

Okay bestie, this one is RFC 6965 🎀 and it's giving infrastructure. It was published in August 2013 and written by L. Fang, Ed. (Cisco), N. Bitar (Verizon), R. Zhang (Alcatel-Lucent), M. Daikoku (KDDI), and P. Pan (Infinera). Its category is Informational, so it's not a Standards Track spec, and its ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates. 💅

Abstract ✨

So the vibe here is: this doc explains where MPLS-TP (MPLS Transport Profile) fits, with real use case studies and network design considerations 🧚. The use cases covered are Metro Ethernet access and aggregation transport, mobile backhaul, and packet optical transport 🌸.

Status of This Memo 🌈

Real talk, this is not an Internet Standards Track specification. It's published for informational purposes only 💜.

This document is a product of the Internet Engineering Task Force (IETF) 👑. It represents the consensus of the IETF community and it has gone through public review. It was approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🙈.

If you want the latest status, any errata, or a way to send feedback, head to http://www.rfc-editor.org/info/rfc6965 🦋.

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), as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 📜. Code Components extracted from this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come 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

1. Introduction ✨

Okay so this section basically repeats the abstract 💅. The document describes the applicability of the MPLS Transport Profile (MPLS-TP) with use case studies and network design considerations. Main character energy, no notes 🦋.

1.1. Terminology 📖

Here's the glossary, and it's literally the acronym cheat sheet you need before anything else makes sense 🧚💜. Terms you'll see: 2G, 3G, 4G, ADSL, AIS, ATM, BFD, BTS, CC-V, CDMA, E-LINE, E-LAN, eNB, EPC, E-VLAN, EVDO, G-ACh, GAL, GMPLS, GSM, HSPA, IPTV, L2VPN, L3VPN, LAN, LDI, LDP, LSP, LTE, MEP, MIP, MPLS, MPLS-TP, MS-PW, NMS, OAM, PE, PW, RAN, RDI, S-PE, S1, SDH, SONET, SP, SRLG, SS-PW, TDM, TFS, tLDP, UMTS, VPN, and X2. The full table is below, exactly as the spec has it 🎀.

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

That's the end of part 1 of 4 🦋 Section 1.2 (Background) and everything after it are coming up in the next parts, so stay tuned bestie 💖

1.2. Background ✨

okay so bestie, the transport world is going through a glow-up 💖 Traditional options like SONET/SDH, TDM, and ATM are being swapped out for new packet transport technologies. Packet transport comes with some key perks, and the demand for bandwidth keeps climbing too 📈

Bandwidth efficiency 🦋

TDM transport is giving very rigid vibes. It supports fixed bandwidth with no statistical multiplexing, so the bandwidth is reserved in the transport network whether or not the client is actually using it. Packet technologies support statistical multiplexing, and this is the biggest reason the industry is moving over ✨ Distributed applications that talk to servers over the network in a bursty way keep driving packet adoption, because multiplexing traffic from bursty sources uses bandwidth way more efficiently than circuit-based TDM does 🔥

Flexible data rate connections 🌸

Traditional transport data rates are stuck on the strict Plesiochronous Digital Hierarchy (PDH) ladder (e.g., DS1, DS3) or the SONET ladder (e.g., OC3, OC12). Packet technologies support flexible data rate connections instead 💅 Finer data rate granularity matters a lot for today's wireline and wireless services and apps 🧚

QoS support 🎀

Traditional transport technologies such as TDM do guarantee bandwidth, but they have zero clue what kind of traffic they're carrying 🙈 They are not packet aware and don't provide packet-level services. Packet transport can offer the differentiated services capability needed to support oversubscription and to handle traffic prioritization when congestion hits. Those issues only show up in packet networks, so this is a huge win 👑

The reason transport is moving to packets is that applications themselves are shifting from TDM to packet. Think Voice TDM becoming VoIP, Video becoming Video over IP, TDM access lines becoming Ethernet, and TDM VPNs becoming IP VPNs and Ethernet VPNs 💜 On top of that, network convergence and technology refreshes are fueling the need for one common, flexible infrastructure that supports multiple services ⭐

As part of the MPLS family, MPLS-TP complements existing IP/MPLS technologies. It closes the gaps in traditional access and aggregation transport so you can get end-to-end packet technology solutions that are cost efficient, reliable, and interoperable 🫶 After several years of industry debate over which packet technology to pick, MPLS-TP has emerged as the next generation transport technology of choice for many Service Providers worldwide 🌈

The Unified MPLS strategy is lowkey the dream for a lot of SPs. It means using MPLS from core to aggregation and access (e.g., IP/MPLS in the core, IP/MPLS or MPLS-TP in aggregation and access). It streamlines operations, reduces overall complexity, and improves end-to-end convergence. It also builds on MPLS experience and boosts the ability to support revenue-generating services 🤑

MPLS-TP is a subset of MPLS functions that meet the packet transport requirements defined in [RFC5654]. That subset includes MPLS data forwarding, pseudowire encapsulation for circuit emulation, and a dynamic control plane that uses GMPLS control for LSPs and tLDP for pseudowires (PW). MPLS-TP also extends earlier 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 were defined for alarm suppression with Alarm Indication Signal (AIS) [RFC6427] and for switch-over triggering with Link Down Indication (LDI) [RFC6427] 🔔 Since the MPLS OAM feature extensions made during MPLS-TP development are part of the MPLS family, their applicability is general to MPLS and not limited to MPLS-TP 🧠

The requirements for MPLS-TP live 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 share use case studies and design considerations from a practical point of view, based on Service Providers' deployment plans as well as actual deployments 📚

The most common MPLS-TP use cases are Metro access and aggregation, mobile backhaul, and packet optical transport. The MPLS-TP data-plane architecture, path protection mechanisms, and OAM functionality are what support these deployment scenarios 🍓

The design considerations in this document cover 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. Lots to chew on, bestie 😭

---

2. MPLS-TP Use Cases 🎀

2.1. Metro Access and Aggregation 🏙️

Using MPLS-TP for Metro access and aggregation transport is the most common deployment scenario seen in the field. It's the main character of the use cases 👑

Some operators are building green-field access and aggregation transport infrastructure from scratch, while others are upgrading or replacing what they already have with new packet technologies. The existing legacy access and aggregation networks are usually based on TDM or ATM. Some operators are swapping these out for MPLS-TP, since legacy ATM/TDM aggregation and access are becoming inadequate for rapid business growth and are too expensive to maintain 💸 On top of that, in many cases the legacy devices are dealing with End of Sale and End of Life issues 💀 As operators have to move forward with next-generation packet technology, adopting MPLS-TP in access and aggregation becomes a natural choice 🦋 Statistical multiplexing in MPLS-TP helps reach higher efficiency compared with the time-division scheme used in legacy technologies. MPLS-TP OAM tools and protection mechanisms help keep transport networks highly reliable and achieve fast recovery 🔥

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

SPs replacing ATM/TDM aggregation often need the following:

• 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 are made up of both packet and optical portions. 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. That makes it a natural fit for transport networks, where operators can use MPLS-TP LSPs (including statically provisioned ones) to manage user traffic as "circuits" in both packet and optical networks 🔌 Once operators are ready, they can migrate the network to 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 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, long-haul networks are sensitive to bandwidth cost and tend to have mesh-like topology, so shared mesh protection is becoming increasingly important 🕸️

In some cases, SPs plan to deploy MPLS-TP from their long-haul optical packet transport all the way to 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, 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

okay so MPLS-TP is commonly seen as a really good fit for 2G/3G mobile backhaul 💖 and 2G (GSM/CDMA) and 3G (UMTS/HSPA/1xEVDO) networks are still totally dominating the mobile infrastructure rn 📱✨

the connectivity for 2G/3G is point to point (P2P) 🎀 and the logical connections have a hub-and-spoke configuration 🌸. The networks are physically built as a star or ring topology 🧚. In the Radio Access Network (RAN), each mobile Base Transceiver Station (BTS/Node B) talks to 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 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, so it is out of scope of this document 🙈.

2.3.2. 4G/LTE Mobile Backhaul

ngl the big difference between LTE and 2G/3G 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, mature IP or L3VPN technologies are 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 🫶.

---

3. Network Design Considerations ✨

3.1. The Role of MPLS-TP

the role of MPLS-TP is 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 operational feasibility and the stage of network transition 🧠. Operators who are used 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 who 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 💼✨.

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, and 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 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 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, so 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 📚.

4. Security Considerations 🔐

okay bestie, this part is serious but we are still going to be iconic about it 💅 So here's the tea: in Metro access and aggregation, some of the access gear can end up sitting in places the SP doesn't own 🏚️. In that case, the static provisioning mode of MPLS-TP is usually the move, because it gets rid of the chance of a control-plane attack that could hit the whole network 😭. This setup lands in the Security Reference Model 2 described in [RFC6941] 🧚.

Mobile use cases have the same location problem 📍. The equipment is often out in remote, outdoor spots, and that makes it easier for someone to get unauthorized access to it 🙈.

Overall, NMS access is a common target in every MPLS-TP use case 🎯, and attacks on GAL or G-ACh are threats that are unique to MPLS-TP 💀. The MPLS-TP security stuff is covered in the MPLS-TP security framework [RFC6941] 🌸. For general security across MPLS and GMPLS networks, check out "Security Framework for MPLS and GMPLS Networks" [RFC5920] 💜.

---

5. Acknowledgements 🫶

The authors want to thank Adrian Farrel for his review as Routing Area Director 👑 and for his ongoing support and guidance. Adrian's detailed comments and suggestions helped a ton in making this document better ✨. The authors also want to shout out Loa Andersson for his continued support and guidance 🎀, Weiqiang Cheng for his helpful input on LTE mobile backhaul based on his real-world deployment experience 🌈, 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. 🔐
• [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. ⏰

---

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

---

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