RFC 6670

The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM)

📅 published July 2012, from ietf

RFC 6670: The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM) 🎀

okay bestie, title block tea 🫖

  • Authors: N. Sprecher (Nokia Siemens Networks) and KY. Hong (Cisco Systems) 💅
  • Category: Informational 📚
  • ISSN: 2070-1721
  • Date: July 2012 🌸
  • Obsoletes/Updates: the title block doesn't list anything this one obsoletes or updates ✨

Abstract

okay so the MPLS Transport Profile (MPLS-TP) is basically MPLS dressed up for transport network deployments 🧚. The MPLS-TP work added new architectural elements and functions to MPLS, and any MPLS deployment can use them. MPLS-TP is a set of functions and features picked from that extended MPLS toolset and applied in a consistent way, so it meets the needs and requirements of operators running packet transport networks 🦋.

while the profile was being developed, people added stuff to the MPLS toolset so the available tools could actually meet the requirements 🔧. these additions were motivated by MPLS-TP, but they're part of the wider MPLS toolset, so any of them could be used in any MPLS deployment 💜.

one major set of additions gives enhanced support for Operations, Administration, and Maintenance (OAM) ⭐. this enables fault management and performance monitoring to the level a transport network needs 🔥. lots of solutions and protocol extensions were proposed for the MPLS-TP OAM requirements, and this document explains why picking a single, coherent set of solutions for standardization is the move 👑.

Status of This Memo

this document is not an Internet Standards Track specification. it's published for informational purposes 📚.

it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶. it got public review and 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 see Section 2 of RFC 5741 for that 🙈.

for the current status, any errata, and how to give feedback on this document, check http://www.rfc-editor.org/info/rfc6670 🌈.

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

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. please read these carefully, because they spell out your rights and restrictions for this document 📜. any Code Components pulled out of this document must include 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 ....................................................4
      1.1. Background .................................................5
      1.2. The Development of a Parallel MPLS-TP OAM Solution .........7
   2. Terminology .....................................................8
      2.1. Acronyms ...................................................8
   3. Motivations for a Single OAM Solution in MPLS-TP ................9
      3.1. MPLS-TP Is an MPLS Technology ..............................9
      3.2. MPLS-TP Is a Convergence Technology ........................9
      3.3. There Is an End-to-End Requirement for OAM ................10
      3.4. The Complexity Sausage ....................................10
      3.5. Interworking Is Expensive and Has Deployment Issues .......11
      3.6. Selection of a Single OAM Solution When There Is a
           Choice ....................................................13
      3.7. Migration Issues ..........................................14
   4. Potential Models for Coexistence ...............................15
      4.1. Protocol Incompatibility ..................................15
      4.2. Inevitable Coexistence ....................................16
      4.3. Models for Coexistence ....................................16
           4.3.1. The Integrated Model ...............................17
           4.3.2. The Island Model ...................................18
   5. The Argument for Two Solutions .................................20
      5.1. Progress of the IETF Solution .............................20
      5.2. Commonality with Ethernet OAM .............................21
      5.3. Different Application Scenarios ...........................21
      5.4. Interaction between Solutions .............................22
      5.5. Letting the Market Decide .................................23
   6. Security Considerations ........................................24
   7. Acknowledgments ................................................24
   8. References .....................................................24
      8.1. Normative References ......................................24
      8.2. Informative References ....................................25
   Appendix A. Examples of Interworking Issues in the Internet .......27
     A.1. IS-IS/OSPF .................................................27
     A.2. Time Division Multiplexing Pseudowires .....................28
     A.3. Codecs .....................................................28
     A.4. MPLS Signaling Protocols ...................................29
     A.5. IPv4 and IPv6 ..............................................29
   Appendix B. Other Examples of Interworking Issues .................30
     B.1. SONET and SDH ..............................................30
     B.2. IEEE 802.16d and IEEE 802.16e ..............................32
     B.3. CDMA and GSM ...............................................32

1. Introduction 🌟

okay so the MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology for use in transport network deployments 🚀. quick note: "transport" in this document means transport networks as discussed in Section 1.3 of [RFC5654] and in [RFC5921] 💖. the MPLS-TP work extended the MPLS toolset with extra architectural elements and functions that any MPLS deployment can use 🦋. MPLS-TP is a set of functions and features selected from that extended toolset and applied consistently, so it meets what operators of packet transport networks need and require 💅.

Operations, Administration, and Maintenance (OAM) plays a huge role in carrier networks 😭. it gives methods for fault management and performance monitoring in both the transport and service layers, and it lets those layers support services with guaranteed, strict Service Level Agreements (SLAs) while keeping operational costs down 💜.

OAM gives you a comprehensive set of capabilities that run in the data plane 🔥. network-oriented mechanisms monitor the network's infrastructure to improve the network's general behavior and level of performance 🎀. service-oriented mechanisms monitor the services offered to end customers 🫶. these mechanisms let you respond quickly to a failure event and help verify some SLA parameters ⭐. fault management mechanisms handle fault detection and localization, plus diagnostics and notification 🧚. performance management mechanisms let you monitor quality of service against key SLA criteria, like jitter, latency, and packet loss 🍓.

during MPLS-TP's development, people added stuff to the MPLS toolset so the tools available could meet the requirements 🔧. these additions were motivated by MPLS-TP, but they form part of the wider MPLS toolset, so any of them could be used in any MPLS deployment 🌈.

one major set of additions gives enhanced support for OAM 👑. lots of solutions and protocol extensions have been proposed for these OAM requirements 🙈. this document sets out the reasons for selecting a single, coherent set of OAM solutions for standardization ✨.

the content of this document should be read in the context of [RFC1958]. in particular, Section 3.2 of [RFC1958] says:

If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements.

that's the vibe for part 1! more parts coming 🫶🎀

1.1. Background 💖

okay so the ITU-T and the IETF teamed up and formed a Joint Working Team (JWT) 🤝 to check whether they could build a joint solution for the OAM requirements of MPLS transport networks, called the MPLS Transport Profile (MPLS-TP) ✨. The JWT said yes, MPLS could be extended to fully meet the requirements [RFC5317] 🙌. The JWT laid the groundwork, and then the IETF did a thorough technical analysis, with strong input from the ITU-T, to make sure the MPLS-TP OAM requirements from both groups would actually get met 💅.

The JWT report [RFC5317] was accepted by the ITU-T and written up in [TD7]. The ITU-T then sent it to the IETF in a liaison statement [LS26] 📨. The ITU-T was very clear that any extensions to MPLS would go through the IETF standards process, using the procedures in [RFC4929] 🎀.

[RFC5317] concluded that "it is technically feasible that the existing MPLS architecture can be extended to meet the requirements of a Transport profile, and that the architecture allows for a single OAM technology for LSPs, PWs, and a deeply nested network" 🧚. That became the starting point for the MPLS-TP work 🌸.

[RFC5654] in general, and [RFC5860] in particular, define the OAM requirements for MPLS-TP that apply to MPLS-TP Label Switched Paths (LSPs), Pseudowires (PWs), and MPLS-TP links 🦋. These documents came out of a joint ITU-T and IETF effort to bring an MPLS Transport Profile into the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures. The goal is a packet transport network that has the capabilities and functions of a transport network as the ITU-T defines them 🌈. The OAM requirements come from the ones the ITU-T wrote in [Y.Sup4] ⭐.

A design team called the MEAD team, made up of experts from both the ITU-T and the IETF, analysed the technical options for OAM solutions 🔥. They agreed on the design principles and the direction for building an MPLS-TP OAM toolset 💜. They presented a report to the IETF MPLS working group at the Stockholm IETF meeting in July 2009 [DesignReport] 🍓. The guidelines from that design team were a huge part of creating a coherent MPLS-TP OAM solution, so main character energy for sure 👑.

The MPLS working group split up the MPLS-TP OAM work into modules, so each piece could be developed separately and in order of priority 🧩. That produced a bunch of documents, each covering a different part of the toolset ✨. When this was written, the most important ones had finished development in the MPLS working group and were moving through the IETF process toward publication as RFCs 🚀. These documents cover the following OAM features:

  • Continuity Check
  • Connection Verification
  • On-Demand Connection Verification
  • Route Tracing
  • Remote Defect Indication
  • Packet Loss Measurement
  • Packet Delay Measurement
  • Lock Instruction
  • Loopback Testing
  • Fault Management

The IETF standards process lets people keep checking whether the OAM solutions in development meet the documented requirements. It also makes room for new requirements if any turn up 🔍. This document is not here to analyse whether the choice of specific OAM solutions was correct 🙅‍♀️. Instead, it explains why standardising multiple solutions for MPLS-TP OAM would be unwise 🚫. It also shows how having multiple solutions would make MPLS-TP development and deployment harder, making networks more expensive to build, less stable, and more costly to operate 💀.

1.2. The Development of a Parallel MPLS-TP OAM Solution 🙈

okay so some people suggested that a second, different OAM solution should also be developed and written up in an ITU-T Recommendation 😳. There were a few arguments for this duplication of effort, including the following:

  • Similarity to OAM encodings and mechanisms used in Ethernet.
  • The existence of two distinct MPLS-TP deployment environments: Packet Switched Networks (PSNs) and Packet Transport Networks (PTNs).
  • The need for similar operational experience in MPLS-TP networks and in pre-existing transport networks (especially Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) networks).

The first argument was discussed in the IETF's MPLS working group. The group gave priority to the JWT's recommendation to pick a solution that reused pre-existing MPLS tools as much as possible 🛠️. They also decided that consistency with the encodings and mechanisms already used in MPLS was even more important 💅.

The second argument hasn't been looked at in much depth, because nobody has documented or presented real evidence that two deployment environments exist 🤷‍♀️. Honestly, one of the main differences cited between the two supposedly separate environments is the choice of MPLS-TP OAM solution itself. That's a circular argument, bestie 🌀.

The third argument has a really important point at its core: network operators want a smooth migration from legacy technologies like SONET/SDH to their new packet transport networks 🥹. That transition gets way easier if the new networks offer similar OAM features and can be managed with tools that look and feel similar 🎀. The requirements specifications [RFC5654] and [RFC5860] capture the key issues that have to be solved to get that same look and feel 📋. Since the OAM solutions developed within the IETF meet the documented requirements, Network Management Systems (NMSs) can be built easily to give the same kind of control over MPLS-TP networks as other transport networks have ✨. It's also worth understanding that building an NMS doesn't depend on the protocols and packet formats inside the OAM. It depends on the high-level features and functions the OAM offers 🧠.

This document doesn't debate the technical merits of any specific solution 🫶. That discussion, plus the documentation of MPLS-TP OAM specifications, was handed over by the IETF and ITU-T to the MPLS working group. It can all happen through the normal consensus-driven IETF process 🗳️. [OAM-OVERVIEW] gives an overview of the OAM mechanisms that have already been defined, plus the ones being defined by the IETF right now. It also compares them with other OAM mechanisms defined by the IEEE and ITU-T 📚.

This document focuses on what happens when two MPLS-TP OAM solutions exist at the same time 💥.

2. Terminology 📖

2.1. Acronyms 🔤

This document uses the following acronyms:

ANSI      American National Standards Institute
CESoPSN   Circuit Emulation Service over Packet Switched Network
ETSI      European Telecommunications Standards Institute
FPGA      Field-Programmable Gate Array
GFP       Generic Framing Procedure
IEEE      Institute of Electrical and Electronics Engineers
ITU-T     International Telecommunication Union - Telecommunication
             Standardization Sector
JWT       Joint Working Team
LSP       Label Switched Path
MPLS-TP   MPLS Transport Profile
NMS       Network Management System
OAM       Operations, Administration, and Maintenance
PDH       Plesiochronous Digital Hierarchy
PSN       Packet Switched Network
PTN       Packet Transport Network
PW        Pseudowire
PWE3      Pseudowire Emulation Edge-to-Edge
SAToP     Structure-Agnostic Time Division Multiplexing over Packet
SDH       Synchronous Digital Hierarchy
SLA       Service Level Agreement
SONET     Synchronous Optical Network
TDM       Time Division Multiplexing
TDMoIP    Time Division Multiplexing over IP

3. Motivations for a Single OAM Solution in MPLS-TP 🎯

okay this section is where the drama is 🎭. It talks through what it means to develop and deploy more than one MPLS OAM protocol. The short version is that there are strong technical, operational, and economic reasons to avoid developing and deploying anything other than a single MPLS OAM protocol 👑.

3.1. MPLS-TP Is an MPLS Technology 💜

MPLS-TP is an MPLS technology, full stop 💅. It's designed to apply MPLS to a new application 🌟. The original proposers assumed the transport variant of MPLS would always live in a disjoint network. Their first attempt at the technology, Transport MPLS (T-MPLS), had a number of significant incompatibilities with MPLS that just couldn't be reconciled 😭. When it became clear that coexistence in the same layer network could and would happen, T-MPLS development was stopped and MPLS-TP development began 🔄. In MPLS-TP, MPLS was extended to meet the transport network requirements in a way that's compatible with both the MPLS already deployed and the MPLS the IETF envisioned for the future 🫶.

Given this goal of compatibility, it follows that the MPLS-TP OAM protocols should be designed using the same design philosophies that were applied to the existing deployed MPLS OAM. Those philosophies are a big reason MPLS has gotten such wide adoption 🌈. The key elements are scalability and hardware independence. That means the trade-off between scaling to large numbers of monitored objects and the performance of the monitoring system should be something vendors and operators resolve themselves 🧚. It also means that trade-off should be a soft transition rather than an abrupt one 🦋. Furthermore, there should be no requirement to run any component (other than packet forwarding) in hardware to get usable performance 🔥.

3.2. MPLS-TP Is a Convergence Technology 🌸

it's possible to argue that using MPLS for transport is only a stepping stone in the middle of a longer transition 🪜. Honestly, all communication applications are moving to run over the TCP/IP/MPLS Internet protocol stack, and the layers that used to exist in communications networks are gradually collapsing into the minimum necessary set 🍓. So, for example, we no longer run IP over X.25 over High-Level Data Link Control (HDLC) over multi-layered Time Division Multiplexing (TDM) networks 🙅‍♀️.

More and more, the whole point of transport networks is to carry TCP/IP/MPLS traffic 🚛. Using MPLS to build a transport network may be a fairly short-term stepping stone toward running IP and MPLS directly over fiber optics ✨. MPLS has been deployed in operational networks for about a decade, and the existing MPLS OAM techniques have seen wide deployment 🎉. Service providers aren't going to stop using the MPLS-based OAM techniques they've relied on for years, and nobody has proposed that they would 🙌. So the question isn't which OAM to use for transport networks. The real question is whether service providers want to use two different sets of OAM tools in the future converged network 🤔. If we end up somewhere TCP/IP/MPLS runs directly over fiber, operators will use MPLS OAM tools to make it work 💜.

3.3. There Is an End-to-End Requirement for OAM ✨

okay so the whole point of OAM is usually to run a function end to end on the thing being monitored, like an LSP or a PW 🛤️ and since LSPs and PWs give you edge-to-edge connectivity and can cross network operator boundaries, the OAM has to work across those boundaries too, no exceptions 🙅‍♀️ this is especially true for the continuity check and connection verification functions, which are the ones that test end-to-end connectivity of LSPs and PWs. so basically, any two pieces of equipment that could ever be part of an end-to-end communications path need to have a common OAM 🫶 this matters even more for equipment running an edge function, because MPLS is a global technology, so it could be interconnected with edge equipment deployed by any other operator in any part of the world 🌍

so it's desirable that any network-layer protocol in all equipment can either execute a canonical form of the OAM or interwork with it 💜 like we talked about in Section 4, interworking between protocols adds a lot of complexity, so a single default OAM is strongly preferred. main character energy for one OAM 👑

3.4. The Complexity Sausage 🌭

a frequent reason people replace an established technology is the perception that the new one is simpler and therefore more economically beneficial for the user 💭 in an isolated system, that might actually be true ngl 🙈 but as usual with communications technologies, simplifying one element of the system causes an increase (possibly a non-linear one) in complexity somewhere else 😩

this creates the "squashed sausage" effect, where cutting complexity in one spot leads to a big jump in complexity at a remote location 🌭💥 when we push complexity out of hardware by putting it in the control plane, there's often an economic benefit, and MPLS itself is a perfect example of that 🧚

some of the motivation for the second OAM solution is how simple it is to operate at a single node alongside other transport OAM mechanisms 🤏 but when we drive OAM complexity out of one network element at the cost of more complexity at a peer network element, we lose out economically, and even worse, we lose out on the reliability of this super important network functionality 😭 because the interworking function between the two MPLS-TP OAM solutions has to stay compatible (so we can get end-to-end OAM), neither of the two disjoint protocol developments can actually make technical advances 🔒 bestie, that kind of restriction is unacceptable within the context of the Internet 🚫

3.5. Interworking Is Expensive and Has Deployment Issues 💸

okay so picture people who speak different languages trying to chat 🗣️ the only way they can understand each other is through an interpreter 🎀 that interpreter adds cost, slows down the rate of information exchange, and might need to go through an intermediate language too 🌀 there's also a big risk of translation errors and semantic ambiguities 😬 and this applies to computer protocols too, especially since those systems are ultra-pedantic 🤓 in every case, having a single working language dramatically simplifies the system, reduces cost, and speeds up reliable communication ✨

if two MPLS OAM protocols were deployed, we'd have to consider three possible scenarios:

  1. Isolation of the network into two incompatible and unconnected islands.
  2. Universal use of both OAM protocols.
  3. Placement of interworking (translation) functions or gateways.

we have so many existence proofs that isolation is not a viable approach 🏝️ (the early T-MPLS discussions are a great place to see examples of this 📚) the whole purpose of the Internet is integrated universal connectivity 🌐 so partitioning it into incompatible, unconnected islands is neither desirable nor acceptable 💅

now, universal deployment of both OAM protocols costs the sum of the costs of each protocol 💰 that shows up as implementation time, development costs, memory requirements, hardware components, and management systems 🧾 it also means extra testing to make sure there are no conflicts (processing state, fault detection, code path, and so on) when both protocols run on a common platform 🧪 and it needs code and processes to negotiate which protocol to use, plus conflict resolution (which might be remote and multi-party) when someone makes an inconsistent choice 🥴 in short, this option results in more than double the cost, makes the system more complex, risks the stability of the deployed network, and makes networks more expensive and more complicated to operate 💀

the third possibility is some form of interworking function 🔁 this is not a simple solution and it inevitably leads to cost and complexity in implementation, deployment, and operation 😵‍💫 where there's a chain of communication (end-to-end messages passed through a series of transit nodes), a choice has to be made about where to apply the translation and interworking 🧩

  • In a layered architecture, interworking can be achieved through tunneling, with the translation points at the end-points of the tunnels 🚇 in simple network diagrams, this looks super appealing, and only one end-node needs to be able to do the translation (effectively speaking both OAM languages) 🥰 but in the much more complex reality of the Internet, nearly every network node acts as an end-node, so nearly every node has to be implemented with the ability to handle both OAM protocols and translate between them 😱 that turns out to be even more complex than the universal deployment of both protocols we talked about above 🌪️
  • In a flat architecture, interworking is performed at a "gateway" between islands that implement different protocols 🚪 gateways are substantially complex entities that usually have to maintain end-to-end state within the network (which goes against one of the fundamental design principles of the Internet 🙃) and they have to bridge the differences in state machines, message formats, and information elements in the two protocols 🧱 all that complexity makes gateways expensive, fragile, and unstable; hard to update when new protocol revisions come out; and difficult to manage 🫠

to deploy an interworking function, we first need to figure out whether the OAM protocol on the arriving segment is identical to the OAM protocol on the departing segment 🔍 if they aren't the same, we have to decide which party performs the translation 🤝 then we need to route the LSP or PW through a translation point that has enough translation capacity, enough data bandwidth, and adequate path diversity 🛣️ and when an upgraded OAM function is required, the problem goes from a two-party negotiation to an n-party negotiation, with commercial and deployment issues added to the mix 📈💼

and here's the kicker 😭 when an end-to-end LSP or PW is deployed, it may transit many networks, and the OAM might need repeated translation back and forth between the OAM protocols 🔄 the consequent loss of information and potential for error is basically the children's game of "telephone" 📞🤪

3.6. Selection of a Single OAM Solution When There Is a Choice 🎀

okay so when there's a choice of protocols to deploy or run, a network operator must make a choice 💅. Choice is a good thing when it gives you different features and functions, but it's a real burden when the protocols do essentially the same stuff and still aren't compatible 😭.

so the stuff you have to weigh is:

  • Which protocol will continue to be developed by its Standards Development Organization (SDO)? 💖
  • Which protocol is most stable in implementations? 🫶
  • How does a network operator test and evaluate the two protocols? 🧪
  • Which vendors support, and will continue to support, which protocol?
  • What equipment from different vendors is compatible?
  • Which management tools support which protocols?
  • What protocols are supported by peer operators, and what interworking function is needed?
  • Which protocols are engineers experienced with and trained in?
  • What are the consequences of a wrong choice? 💀
  • Will it be possible to migrate from one protocol to another in the future?
  • How is integration with other functions already present in the network accomplished?
  • How does a network operator future-proof against the inclusion of new functions in the network? 🔮

at the very least, just evaluating these questions costs money and adds delay for the operator. a wrong choice could be super expensive, and it's likely that any comparative testing will more than double the lab-test costs before deployment 😩.

from a vendor's perspective the choice is even harder 🥺. a vendor doesn't want to risk not offering a product that has considerable demand, so both protocols may need to be developed, which leads to more than doubled development costs. honestly, code complexity and defect rates have often been shown to increase more than linearly with code size, and (as noted in Section 3.5) the need to test for coexistence and interaction between the protocols adds to the cost and complexity 🌀.

worth noting: in the long run, it's the end-users who pay the price for the extra development costs and any network instability that arises. the people at the end always get the bill 💅

3.7. Migration Issues 🦋

deploying a technology that gets replaced or obsoleted later often means you have to migrate from one technology to another. this might happen if an operator deploys one of the two OAM protocol solutions and then discovers they need to move to the other one. a specific case is when two operators merge their networks but are using different OAM solutions 🤝.

when the migration is between versions of a protocol, it may be that the new version is defined to support the old version. if the implementation is in software (including FPGAs), upgrades can be managed centrally. however, neither of these is the case with MPLS-TP OAM mechanisms, and hardware components would need to be upgraded in the field using expensive call-out services 📞💸.

hardware upgrades are likely to affect service, even with sophisticated devices that have redundant hardware components 😬. and since it would be impractical to upgrade every device in the network at the same time, there's a need for either a significantly large maintenance period across the whole network, or a rolling plan that upgrades nodes one at a time with new hardware that has dual capabilities. such hardware is, of course, more expensive and more complex to configure than hardware dedicated to just one OAM protocol 🙈.

additionally, the transition phase of migration leads to dual-mode networks, as described in Section 4.3. these networks are not desirable because of their cost and complexity 🫠.

in short, the potential for future migration needs to be part of the deployment planning exercise whenever there are two OAM protocols to choose between. this issue puts pressure on making the "right" choice when performing the selection described in Section 3.6 👑.

4. Potential Models for Coexistence ✨

this section expands on the discussion in Section 3 by examining three questions:

  • What does it mean for two protocols to be incompatible?
  • Why can't we assume that the two solutions will never coexist in the same network?
  • What models could we support for coexistence?

4.1. Protocol Incompatibility 💥

protocol incompatibility comes in a range of grades of seriousness. at the most extreme, the operation of one protocol will prevent the safe and normal operation of the other protocol. this was the case with the original T-MPLS, where MPLS labels that could be used for data in a native MPLS system were assigned special meaning in T-MPLS, so data packets would be intercepted and mistaken for OAM packets 😱.

a lesser incompatibility happens when the packets of one protocol are recognized as "unknown" or "not valid" by implementations of the other protocol. in this case, the rules of one protocol require that the packets of the other protocol be discarded, and this may result in the LSP or PW being torn down 💔.

the least serious level of incompatibility is when the packets of one protocol are recognized as "unknown" by implementations of the other protocol, but the rules of one protocol allow those packets to be ignored. in this case, such packets are either silently discarded or forwarded untouched 🫥.

these problems show up at every grade of incompatibility. they range from disruption or corruption of user data, through connection failure, to not being able to provide end-to-end OAM function without careful planning and translation functions 🙃.

4.2. Inevitable Coexistence 🌍

networks expand and merge. for example, one service provider may acquire another and want to merge the operation of the two networks. this makes partitioning networks by protocol deployment a big deal for future-proofing commercial interactions. sure, a network operator might want to make things difficult in order to disincentivize a hostile takeover (a poison pill), but most operators are interested in future options to grow their networks 📈.

as described in Section 3.2, MPLS is a convergence technology. that means there's a tendency for an ever-increasing number of services to be supported by MPLS, and for MPLS to be deployed in an increasing number of environments. it would be an unwise operator who deployed a high-function convergence technology in such a way that the network could never be expanded to offer new services or to integrate with other networks or technologies 🧠.

as described in Section 3.3, there is a requirement for end-to-end OAM. that means that where LSPs and PWs span multiple networks, there's a need for OAM to span multiple networks too 🔗.

so all of this means that if two different OAM protocol technologies are deployed, there will inevitably come a time when some form of coexistence is required, no matter how carefully the separation is planned at the start 🫶✨.

4.3. Models for Coexistence 🧩

two models for coexistence can be considered:

  1. An integrated model based on the "ships-in-the-night" approach. In this model, there is no protocol translation or mapping. This model can be decomposed as follows:
    • A non-integrated mixed network, where some nodes support just one protocol, some support just the other, and no node supports both protocols.
    • Partial integration, where some nodes support just one protocol, some support just the other, and some support both protocols.
    • Fully integrated dual mode, where all nodes support both protocols.
  2. An "island" model, where groups of similar nodes are deployed together. In this model, there may be translation or mapping, but it is not always required. This model can be further decomposed as follows:
    • "Islands in a sea", where connectivity between islands of the same type is achieved across a sea of a different type.
    • "Border crossings", where connectivity between different islands is achieved at the borders between them.

4.3.1. The Integrated Model 🌈

the integrated model assumes that nodes with different capabilities coexist within a single network. dual-mode nodes supporting both OAM solutions may coexist in the same network. interworking is not required in this model, and no nodes are capable of performing a translation or gateway function (see Section 4.3.2 for operational modes including translation and gateways) 🚫.

in this model, protocol messages pass as "ships in the night", unaware of each other and without perturbing each other 🌙.

as noted above, there are several sub-models 🍓.

4.3.1.1. Mixed Network without Integration 🙅‍♀️

in a mixed network with no integration, some nodes support one protocol and other nodes support the other protocol. there are no nodes that have dual capabilities.

all nodes on the path of an LSP or PW that are required to play an active part in OAM must support the same OAM protocol. nodes that do not support the OAM protocol will silently ignore (and possibly discard) OAM packets from the other protocol, and they cannot form part of the OAM function for the LSP or PW 😶.

to set up an end-to-end connection that gets the full OAM functionality, the planning and path-computation tool must know the capabilities of each network node, and it must select a path that includes only nodes with the same OAM protocol capability 🗺️. this can result in considerably suboptimal paths and may lead to the network being partitioned. in the most obvious case, connectivity can only be achieved between end-points with the same OAM capability. this creates considerable operational complexity and expense, as well as the inability to provide a fully flexible mesh of services 🥴.

in the event of dynamic network changes (such as fast reroute), or if misconnectivity occurs, nodes with mismatched OAM capabilities may become interconnected. this will disrupt traffic delivery, because end-to-end continuity checks may be disrupted, and it may be hard or impossible to diagnose the problem, because connectivity verification and route trace functions will not work properly 😭🚨.

4.3.1.2. Partial Integration 🧁

in a partially integrated network, the network described in Section 4.3.1.1 is enhanced by the addition of a number of nodes with dual capabilities. these nodes do not possess gateway or translation capabilities (this is covered in Section 4.3.2), but each such node can act as a transit point or end-node for an LSP or PW that uses either OAM protocol 🦋.

complexity of network operation is not eased, but there's greater connectivity potential in the network 💜.

4.3.1.3. Dual Mode 💜

Okay so dual mode is basically partial integration (Section 4.3.1.2) level up 💅. Every single node in the network can speak both OAM protocols. Same as in that section, these nodes don't have gateway or translation powers (that's Section 4.3.2's whole storyline 🎬), but each one can be a transit point or an end-node for an LSP or PW using either OAM protocol. So every LSP or PW in the network can be configured to use either one. Iconic flexibility, honestly ✨

BUT lowkey, it's unlikely an operator would pick which OAM protocol to use on each LSP or PW one by one 🙈 That would add complexity to the management system and could confuse things if extra diagnostic analytics need to happen. This mode makes implementation, deployment, and operation harder without adding any function to the network (since both OAM solutions give the same level of function) 💀 So it would not be selected for deployment, except maybe while the network is migrating from one OAM protocol to the other 🦋

4.3.2. The Island Model 🏝️

In the island model, regions or clusters of nodes with the same OAM capabilities get grouped together 🫶 Tools to connect these technologies are deployed based on layered networking or on interworking between the protocols. Those lead to the two sub-models in the sections below 🌸

4.3.2.1. Islands in a Sea 🌊

One way to picture clusters of nodes that support one OAM protocol is as an island in a sea of nodes that support the other one 🏝️🌊 In this view, tunnels carry LSPs or PWs using one OAM type across the sea and into another island with a compatible OAM type. The tunnel here is an LSP that uses the OAM protocol the nodes in the sea support. In theory, an island can be as small as one node, and the strait between two islands can be as narrow as just one node 🧚

Layering like this is an elegant solution for running two protocols at the same time, and it's of course used to support different technologies (like MPLS over optical) ✨ But in layering deployments there's no simple integration of OAM between the layers, and the OAM in the upper layer has to treat the tunnel as a single hop with zero visibility into the lower layer's OAM 🙈 Diagnostics in the upper layer get complicated because the nodes along the lower layer's tunnel path are "hidden" 😭

In all the scenarios so far, both ends of each connection have sat in islands of compatible OAM types. It is possible to get connectivity between a node in an island and a node in the sea, but only if the end-point in the sea has dual capabilities (i.e., it can be viewed as a single-node island) 💖

A bunch of islands might lie along the path between end-points, which means you need more than one tunnel 🌈 To make things even more dramatic, the islands might be in an inland sea, so you'd have to nest tunnels 💀

No matter the scenario, running tunnels or layers like this adds to the management complexity and expense 💸 And it's worth noting that an MPLS network often calls for any-to-any connectivity 👑 That means any node in the network may need to set up an LSP or a PW to any other node. As noted before, the end-points of any LSP or PW must support the same OAM type in the islands-in-a-sea model, so that tends to mean all, or nearly all, nodes end up needing to support both OAM protocols 🔥

Tunnels can also quietly degrade network services unless they're carefully coordinated 😬 For example, a service in the upper layer might be provisioned with protection, so a working path and a backup path are built over diverse paths to survive a single failure. BUT the paths of the tunnels (in the lower layer) aren't visible to path computation in the upper layer, so the upper layer's working and protection paths could end up sharing a single point of failure in the lower layer 😱 Traffic engineering techniques have been developed to fix this kind of issue, but they add a lot of complexity to a system that would otherwise be a simple flat network if only one OAM technology were used 🥲

4.3.2.2. Border Crossings 🚧

Instead of connecting islands with tunnels across the sea, islands of different types can be connected directly, so the LSP or PW goes through the series of islands without tunneling 🦋 In this case, protocol translation happens every time the LSP/PW crosses a border between islands that use a different OAM protocol 🔄

In principle, this makes for a straightforward end-to-end connection ✨ However, protocol translation brings a bunch of issues, as described in Section 3 🙃 The catch is that when you're planning the end-to-end connection, you have to pick gateways with protocol translation capabilities to sit on the path 🎀

5. The Argument for Two Solutions 🤔

The decision to define and develop an alternative MPLS-TP OAM solution was based on several assertions:

  • The IETF solution is taking too long to standardize.
  • Commonality with Ethernet solutions is beneficial.
  • There are two different application scenarios.
  • There is no risk of interaction between the solutions.
  • The market should be allowed to decide between competing solutions.

The following sections look briefly at each of these claims 👀

5.1. Progress of the IETF Solution 🐢

The MPLS-TP OAM work done within the IETF is the product of joint work between the IETF and ITU-T communities 🤝 So all the interested parties share responsibility for moving this work along as fast as possible. Since the work is contribution-driven, there's no reason to assume consensus on the technical content could be reached any faster 💅

Opening discussions on a second solution seems certain to increase the workload and will only slow down how quickly consensus gets reached 😩

The core MPLS-TP OAM work in the IETF was completed, and the specifications were published as RFCs 🎉 For more info, see [ISOCAnnounce].

5.2. Commonality with Ethernet OAM 🧃

Ethernet can be used to build packet transport networks, so there's an argument that Ethernet and MPLS-TP networks will be operated as peers 👯 When you look at end-to-end connections across mixed networks, a lot of the same issues as in Section 4 pop up. If a peer networking gateway model (see Section 4.3.2.2) is applied, there's a strong argument for making the OAM technologies as similar as possible 💖

BUT while that could be a valid discussion point when picking the single OAM solution for MPLS-TP, it's countered by the need to get OAM consistency between MPLS and MPLS-TP networks 🙃 Someone could argue that if MPLS-TP needs to be as similar to Ethernet as possible, it would be better to go the full distance and just deploy Ethernet 💀

Also, a second MPLS-TP OAM protocol doesn't fix anything 😬 Since MPLS-TP is not Ethernet, a gateway will still be needed. That second MPLS-TP OAM would mean additional gateways or interworking functions are needed, because coexistence is inevitable, as the rest of this document describes 🫠

It may also be claimed that implementation gets simpler if the OAM solution for MPLS-TP is similar to Ethernet OAM 🧠 That would apply both to the hardware/software doing the OAM and at the server-to-client interface where OAM-induced fault status gets reported. Honestly, the questions here are very implementation dependent, since the necessary function lives inside individual nodes 🤷‍♀️ The counter-argument is that implementation simplicity can also come from making MPLS-TP OAM similar to MPLS OAM, especially since the client technology may well be IP/MPLS, and MPLS is an end-to-end technology 🌐

5.3. Different Application Scenarios 🎭

People have suggested that MPLS-TP has two different applications: Packet Switched Networks (PSNs) and Packet Transport Networks (PTNs) 🧩 These applications haven't been documented in the IETF, and most of the support for this idea has been documented by the ITU-T [TD522].

One of the stated differences between these applications is the OAM tools needed to support their distinct operational scenarios. The OAM used in a PSN should be similar to what's used in an MPLS network (and so should the MPLS-TP OAM defined in the IETF), while the OAM used in a PTN should give the same operational experience as SONET/SDH and Optical Transport Networks (OTNs) 🌟

The basic MPLS-TP OAM requirements in [RFC5654] make this point as follows:

Furthermore, for carriers it is important that operation of such packet transport networks should preserve the look-and-feel to which carriers have become accustomed in deploying their optical transport networks, while providing common, multi-layer operations, resiliency, control, and multi-technology management.

So the look and feel of OAM has been a concern in MPLS-TP design from the very start 👀 The solutions defined in the IETF were designed to meet the requirements and to provide operational behavior, functionality, and processes similar to what exists in current transport networks ✨ In particular, the toolset supports the same controls and indications as other transport networks, and the same management information model can be used for the MPLS-TP OAM tools (in areas where the technology type doesn't matter) 💜

It's important to note that the operational look and feel doesn't determine how the OAM function gets achieved 🙌 There are multiple ways to achieve the required functionality while still giving the same operational experience and supporting the same management information model. So the OAM protocol solution doesn't dictate the look and feel, and wanting a particular operational experience doesn't require developing a second OAM protocol 🎀

5.4. Interaction between Solutions 💥

Section 3 of this document discusses how network convergence happens, and it points out that where two MPLS-TP solutions exist, they are very likely to show up either in the same network or at gateways between networks, so that end-to-end OAM functionality can be provided 😳

Honestly, nodes offering either solution will probably both get branded as "MPLS-TP" 🏷️ And since network interoperation (as described in Section 4) requires some nodes that are either dual-mode or act as protocol translators/gateways, there's a real chance the two OAM solutions interact, whether by design or by accident 🫣 When a node can support both OAM protocols, it must be configured to support the correct protocol for each interface and LSP/PW 🔧 When a device has interfaces offering different MPLS-TP OAM functions, the risk of misconfiguration is significant 🚨 And when a device is meant to support end-to-end connections, it may need to translate, map, or tunnel to accommodate both protocols 🔁

So the very existence of two OAM protocols within the common MPLS-TP family makes copresence and integration most likely 🌈✨

5.5. Letting the Market Decide 🍿

Okay so when two techs are competing, the usual move is to just let the market decide who survives 💅. Sometimes it's super fast and one tech straight up dominates the other before there's any real deployment. Other times it takes forever, like when one tech got entrenched before the other showed up (MPLS replacing ATM is the classic example 👀). But ngl, a lot of the time the market doesn't pick a winner at all. Like in many of the cases in Sections 4 and 5 of this document, both techs just keep living in the network together 🫶

Letting the market decide is not a cheap option though 😩. Even when the call is quick, equipment vendors and early adopters still pay for both technologies. When it takes longer to figure out which technology is correct, there's a period of coexistence, and then the equipment has to be transitioned from the losing solution to the winning one. In the cases where no choice gets made, the network stays permanently complicated because the competing technologies are still around 🌀

Here's the thing: allowing the market to decide is only easy to support when the competing technologies don't overlap 🦋. In those cases (for example, different applications in the user space), the core network isn't disturbed by the decision-making process, and switching from one technology to the other is relatively painless ✨. This is NOT the case for MPLS-TP OAM 🙈. Coexistence while the market works out the correct approach would be expensive, and the necessary transition after the decision is made would be difficult and costly 💀

6. Security Considerations 🔐

This informational document does not introduce any security issues. ✅

However, it should be noted that the existence of two OAM protocols raises a number of security concerns 😬:

  • Each OAM protocol has to be secured. That leads to two security solutions that each need configuration and management. The extra complexity of operating security mechanisms tends to make them less likely to actually get used in the field, and that increases the vulnerability of the network 🚨. Two security mechanisms also raise the risk of misconfiguration 🙃.
  • One OAM protocol may be used as a vector to attack the other 🗡️. Inserting an OAM message of the other OAM protocol onto a link may cause the service to be disrupted. Because some nodes may support both OAM protocols, it may be possible to cause that disruption at a remote point in the network 😱.
  • Securing a network protocol is not a trivial matter for protocol designers 🧠. Duplicating design effort is unlikely to result in a stronger solution, and it runs the risk of diluting the effort and creating two less-secure solutions 💔.

7. Acknowledgments 🫶

Thanks to Brian Carpenter, Tom Petch, Rolf Winter, Alexander Vainshtein, Ross Callon, Malcolm Betts, and Martin Vigoureux for their review and useful comments 🌸.

Thanks to Huub van Helvoort for supplying text and history about SONET/SDH 🧚.

8. References 📚

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

[RFC5860]  Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed.,
           "Requirements for Operations, Administration, and
           Maintenance (OAM) in MPLS Transport Networks", RFC 5860,
           May 2010.

8.2. Informative References

[RFC1958]  Carpenter, B., Ed., "Architectural Principles of the
           Internet", RFC 1958, June 1996.

[RFC4553]  Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure-
           Agnostic Time Division Multiplexing (TDM) over Packet
           (SAToP)", RFC 4553, June 2006.

[RFC4929]  Andersson, L., Ed., and A. Farrel, Ed., "Change Process
           for Multiprotocol Label Switching (MPLS) and Generalized
           MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC 4929,
           June 2007.

[RFC5086]  Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and
           P. Pate, "Structure-Aware Time Division Multiplexed (TDM)
           Circuit Emulation Service over Packet Switched Network
           (CESoPSN)", RFC 5086, December 2007.

[RFC5087]  Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi,
           "Time Division Multiplexing over IP (TDMoIP)", RFC 5087,
           December 2007.

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

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

[OAM-OVERVIEW]
           Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
           Weingarten, "An Overview of Operations, Administration,
           and Maintenance (OAM) Mechanisms", Work in Progress,
           March 2012.

[Y.Sup4]   "Supplement on transport requirements for T-MPLS OAM and
           considerations for the application of IETF MPLS
           technology", ITU-T Y.1300-series Supplement 4,
           January 2008.

[G.707]    "Network node interface for the synchronous digital
           hierarchy (SDH)", ITU-T Recommendation G.707,
           January 2007.

[TD7]      "IETF and ITU-T cooperation on extensions to MPLS for
           transport network functionality", ITU-T TD7 (WP3/SG15),
           December 2008.

[TD522]    "Clarification of the PTN/solution X environment",
           ITU-T TD522 (WP3/SG15), February 2011.

[LS26]     "Cooperation Between IETF and ITU-T on the Development of
           MPLS-TP", ITU-T COM 15-LS26-E, December 2008,
           <http://datatracker.ietf.org/documents/LIAISON/
           file596.pdf>.

[DesignReport]
           "MPLS-TP OAM Analysis", Proc. IETF 75, Stockholm, Sweden,
           July 2009, <http://www.ietf.org/proceedings/75/slides/
           mpls-17/mpls-17_files/frame.htm>.

[ISOCAnnounce]
           "Milestone Achieved in Internet Carrier Network Standards
           - Multiprotocol Label Switching Transport Profile
           (MPLS-TP) Specifications Published", Internet Society,
           December 2011, <http://www.isoc.org/standards/mpls.shtml>.

Appendix A. Examples of Interworking Issues in the Internet 🕰️

Of course it's right to point out that there are a bunch of cases where multiple protocols serve the same purpose on the Internet 🌈. It's really valuable to look at these examples so we can see what issues they caused and how they got mitigated 🔍.

A.1. IS-IS/OSPF 🥊

IS-IS and OSPF are two competing link-state IGP routing protocols. They come from the same root technology, and for political and personality reasons, they were never reconciled before wide-scale deployment 😤. It's kind of an accident of history that one of them didn't gain overwhelming deployment and force the other into retirement 🤷‍♀️.

Having these two widely deployed, highly functional, competing IGPs doubles the cost of link-state IGP maintenance and deployment in the Internet 💸. This is going to almost certainly continue for the lifetime of the Internet 🫠. The Internet is clearly successful and operates well, but these two IGPs still force router vendors to implement both protocols (doubling the protocol cost of all routers, even when an operator only wants to deploy one of them) 🧾. They also force the operator to make an active choice between IGPs during deployment, and they require a gateway function between the islands of protocol use 🏝️.

A mitigating factor in this specific case is that, because networks are partitioned for administrative and scaling reasons, there already was a gateway routing protocol called BGP. It propagates a summarized form of the IGP reachability information throughout the Internet 🌐. BGP means there's actually no requirement for IS-IS and OSPF to interwork directly. There's no need for a translation function between OSPF and IS-IS, and the two IGPs can keep existing without impacting the function of the Internet 🎀. So unlike the situation with MPLS OAM, the choice of IGP protocol is truly a local decision. There is still a cost, though: BGP implementations have to support interactions with both OSPF and IS-IS 💅.

A.2. Time Division Multiplexing Pseudowires 🧩

The IETF's PWE3 working group published the specification of three different TDM PW types 📦. This happened after a lot of effort to reach a compromise failed to reduce the set of options 😮‍💨.

  • SAToP is a relatively simple design 🍓. It is a Proposed Standard RFC [RFC4553] and is the mandatory-to-implement, default mode of operation ✅.
  • CESoPSN [RFC5086] and TDMoIP [RFC5087] are more complex approaches, with different degrees of bandwidth efficiency optimized for different applications 🎯. They are both published as Informational RFCs 📄.

In this case, all implementations must include the default mode of operation (SAToP). That means end-to-end operation is guaranteed: an operator can pick equipment from any vendor, knowing he'll be able to build and operate an end-to-end TDM PW service 🥰.

If an operator wants to deploy a TDM PW optimized for a specific application, he can select equipment from a vendor offering CESoPSN or TDMoIP in addition to SAToP ✨. As long as all of his equipment and his management system can handle the optimized approach, he can run it in his network. But he has to carry the cost of selecting, purchasing, configuring, and operating the extended mode of operation 💸.

Honestly this situation is far from ideal, and it's possible that long-distance, multi-operator optimized TDM PWs can't be achieved 😭. Still, the default mode being implemented in all devices helps reduce the pain for the operator and makes sure simpler end-to-end operation is always available 🫶. Plus, the growth of other protocols is diminishing the use of long-distance TDM circuits, so this is a self-limiting problem 🌷.

A.3. Codecs ✨

okay so the n-squared codec interworking problem got brought to the IETF's attention by the ITU-T, right when the IETF started working on a royalty-free codec for the Internet 🎀. Every time a new codec gets deployed, translation between it and all the other deployed codecs has to be available inside the network. Every participating node must be able to handle the new codec 😭. And translation between codecs is expensive and can make quality worse 💀.

This seriously limits adding new codecs to the set, so new ones only get designed and released when there's a well-established need, like a major difference in functionality 🙈.

BUT the application layer of the Internet runs on a business model built around shared, free, and open-source software, and that model needs a royalty-free codec 🫶. That, plus the specific stuff about sending media over lossy packet networks, added up to requirements equivalent to a major difference in functionality. So the IETF went ahead and worked on specifying a new codec 🦋.

The complexity, economic, and quality costs of interworking with this new codec will need to be factored into the deployment model 💅. And that, in turn, may hurt its adoption and how viable it is to use on the Internet 🥺.

A.4. MPLS Signaling Protocols 🧚

there are three MPLS signaling control protocols used to distribute labels for setting up LSPs and PWs in MPLS networks: LDP, RSVP - Traffic Engineering (RSVP-TE), and GMPLS 🌈.

Each one has a different application domain, and unlike the OAM situation, there's limited requirement for interworking between them. For example, one provider might use LDP to set up LSPs while its peer uses RSVP-TE, but the two providers usually connect at the IP layer anyway 🌸.

Also, the IETF originally worked on another signaling protocol called Constraint-based Routed LDP (CR-LDP), with variants for MPLS and GMPLS. Its development ran in parallel with RSVP-TE 👀. But once it was clear that the solution the vendor and operator community preferred was RSVP-TE, the IETF stopped all further work on CR-LDP 😤. No translation function or gateway point between RSVP-TE and CR-LDP was ever proposed 💜.

A.5. IPv4 and IPv6 🌍

if there was ever an example of why protocol interworking should be avoided if at all possible, it's the IPv4 to IPv6 transition 😭🔥.

The reasons for bringing IPv6 into the Internet are well known, so we don't need to rehash them here 💅. IPv6 wasn't introduced as a competitor to IPv4. It was a planned replacement 🫶. The need to transition came from the network growing way beyond the wildest dreams of the Internet's creators, and from the resulting depletion of the IPv4 address space 🌈.

This transition has turned out to be the hardest problem the IETF has ever tackled ✨. Inventing and standardizing IPv6 was straightforward by comparison. But migrating networks from one established protocol to a new one has been exceptionally difficult 💀.

The early assumption was that by the time IPv4 addresses ran out, IPv6 would be universally deployed. That didn't happen, because of (understandable) short-term economic constraints 🥲. Migrating early would have been simpler and cheaper than the plans we have now. So the Internet is now stuck with the considerable complexity of implementing and deploying interworking functions 😩.

If anything is worth learning from the IPv4/IPv6 experience, it's that every effort should go into avoiding the need to migrate or jointly operate two protocols within one network 🙏. And adding OAM interworking issues for MPLS, one of the Internet's core protocols, to the mix would be super unwelcome and make things even more complicated 💀🍓.

Appendix B. Other Examples of Interworking Issues 🎀

B.1. SONET and SDH 🍓

SONET and SDH were defined as competing standards that basically did the same thing: carry multiple circuits of different origins at the same time within a single framing protocol 👯. SONET was developed first by ANSI, based on the 24-channel PDH hierarchy that existed in North America and Japan. Its basic rate is based on DS3. Some time later, ETSI developed SDH based on the 30-channel PDH deployed in Europe. Its basic rate is based on E4 (3x DS3) ✨. The key difference is that the "S" stands for "synchronous" and the "P" stands for "plesiochronous", so the difference between the two technologies is really about timing ⏱️.

SONET was adopted in the U.S., Canada, and Japan, and SDH in the rest of the world 🌏.

Until 1988, the standards were unpublished and still under development 📜.

  • The SONET standard ANSI T1.105-1988 was published in 1988.
  • The SDH standard ETSI EN 300 417 was first published in 1992.
  • The compromise SDH/SONET standard ITU-T G.707 was published in 1988 (see below for the nature of this compromise).

Some implementers were confused by all this 😵‍💫. Equipment manufacturers initially had to pick the market segment they wanted to address. The cost of chipsets for a limited market went up, and only a limited number of equipment manufacturers were available to choose from in each market 💸.

Obviously, most equipment vendors wanted to sell in both regions 🌎. So today most chips support both SONET and SDH, and the choice comes down to provisioning 🔧. The extra function needed to support both markets has had a mixed impact on cost. It enabled higher production volume, which lowered cost, but it also required more development and complexity, which raised cost 🤷‍♀️.

Because the regions where SONET and SDH apply are well known, service providers don't need to weigh the merits of the two standards and their long-term role in the industry when looking at investment options 💼✨.

To deploy SONET and SDH worldwide, the regional SDO experts came together in the ITU-T to define a frame structure and frame rate that would let SONET and SDH interconnect 🤝. A compromise was agreed upon and approved at an ITU-T meeting in Seoul in 1988 🇰🇷.

The SDH standard supports both the North American and Japanese 24-channel/T1/T3 hierarchy and the European 30-channel/E1/E4-based hierarchy within a single multiplexing structure 🧩. SDH has options for payloads at VC-4 (150 Mb/s) and above. It lets T1/T3 services be delivered in Europe and E1 services be delivered in North America using a common infrastructure 🌈.

Deploying an E1-only standard in North America would have meant converting all the deployed 24-channel/T1 equipment and services into the 30-channel/E1 format. Likewise, deploying a T1-only standard in Europe would have meant converting all the 30-channel/E1 equipment and services into the 24-channel/T1 format 😱. Given the existing network deployments (in 1988), that clearly wasn't practical, and it was the main reason a compromise was reached 💅.

The result of the compromise is documented in ITU-T Recommendation G.707 [G.707], which includes the frame definition and frame rates and also documents how SONET and SDH can interconnect 📖.

An extensive interworking function had to be implemented to provide global connectivity (e.g., throughout the U.S. and Europe), and that increased operational overhead 😮‍💨. The interworking function has to be performed before the SDH-based segment is reached. The reason it sits on the SONET side is that an earlier interconnection agreement had placed the functionality on the European side 🙃.

B.2. IEEE 802.16d and IEEE 802.16e 📡

IEEE 802.16d and IEEE 802.16e were two different, incompatible iterations of the Worldwide Interoperability for Microwave Access (WiMAX) standards 💥. On top of the issues described for SONET/SDH, developers who implemented IEEE 802.16d found they couldn't reuse their equipment design when developing the IEEE 802.16e variant. That raised development costs and stretched out time to market ⏳.

B.3. CDMA and GSM 📱

Code Division Multiple Access (CDMA) and the Global System for Mobile Communications (GSM) are two competing technologies for mobile connectivity 📶.

On top of all the undesirable effects described above, having these two technologies around hurt customers who roamed while overseas 🧳. Sometimes customers had to get an additional device from their service provider in order to roam when traveling abroad (for example, when traveling from Europe to the U.S.) 😤.

Authors' Addresses 💌

Nurit Sprecher
Nokia Siemens Networks
3 Hanagar St. Neve Ne'eman B
Hod Hasharon  45241
Israel

EMail: nurit.sprecher@nsn.com


Kyung-Yeop Hong
Cisco Systems
300 Beaver Brook Road
Boxborough, Massachusetts  01719
USA

EMail: hongk@cisco.com
📦 where this page comes from