[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 RFC 6670

Network Working Group                                        N. Sprecher
Internet-Draft                                    Nokia Siemens Networks
Intended status: Informational                                  KY. Hong
Expires: November 1, 2012                                  Cisco Systems
                                                          April 30, 2012

      The Reasons for Selecting a Single Solution for MPLS-TP OAM


   The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS
   technology for use in transport network deployments.  The work on
   MPLS-TP has extended the MPLS technology with additional
   architectural elements and functions that can be used in any MPLS
   deployment.  MPLS-TP is a set of functions and features selected from
   the extended MPLS toolset and applied in a consistent way to meet the
   needs and requirements of operators of packet transport networks.

   During the process of development of the profile, additions to the
   MPLS toolset have been made to ensure that the tools available met
   the requirements.  These additions were motivated by MPLS-TP, but
   form part of the wider MPLS toolset such that any of them could be
   used in any MPLS deployment.

   One major set of additions provides enhanced support for Operations,
   Administration, and Maintenance (OAM).  This enables fault management
   and performance monitoring to the level needed in a transport
   network.  Many solutions and protocol extensions have been proposed
   to address the requirements for MPLS-TP OAM, and this document sets
   out the reasons for selecting a single, coherent set of solutions for

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Sprecher & Hong         Expires November 1, 2012                [Page 1]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

   This Internet-Draft will expire on November 1, 2012.

Copyright Notice

   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) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Sprecher & Hong         Expires November 1, 2012                [Page 2]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Background . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.2.  The Development of a Parallel MPLS-TP OAM Solution . . . .  6
   2.  Terminology and References . . . . . . . . . . . . . . . . . .  8
     2.1.  Acronyms . . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.  Motivations for a Single OAM Solution in MPLS-TP . . . . . . .  8
     3.1.  MPLS-TP is an MPLS Technology  . . . . . . . . . . . . . .  8
     3.2.  MPLS-TP is a Convergence Technology  . . . . . . . . . . .  9
     3.3.  There is an End-to-End Requirement for OAM . . . . . . . .  9
     3.4.  The Complexity Sausage . . . . . . . . . . . . . . . . . . 10
     3.5.  Interworking is Expensive and Has Deployment Issues  . . . 10
     3.6.  Selection of a Single OAM Solution When There is a
           Choice . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     3.7.  Migration Issues . . . . . . . . . . . . . . . . . . . . . 14
   4.  Potential Models For Coexistence . . . . . . . . . . . . . . . 14
     4.1.  Protocol Incompatibility . . . . . . . . . . . . . . . . . 15
     4.2.  Inevitable Coexistence . . . . . . . . . . . . . . . . . . 15
     4.3.  Models for Coexistence . . . . . . . . . . . . . . . . . . 16
       4.3.1.  The Integrated Model . . . . . . . . . . . . . . . . . 16
       4.3.2.  Island Model . . . . . . . . . . . . . . . . . . . . . 18
   5.  The Argument For Two Solutions . . . . . . . . . . . . . . . . 19
     5.1.  Progress of the IETF Solution  . . . . . . . . . . . . . . 20
     5.2.  Commonality with Ethernet OAM  . . . . . . . . . . . . . . 20
     5.3.  Different Application Scenarios  . . . . . . . . . . . . . 21
     5.4.  Interaction Between Solutions  . . . . . . . . . . . . . . 22
     5.5.  Letting The Market Decide  . . . . . . . . . . . . . . . . 22
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 23
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
   8.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 24
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 24
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 24
   Appendix A.   Examples of Interworking Issues in the Internet  . . 25
   Appendix A.1. IS-IS/OSPF . . . . . . . . . . . . . . . . . . . . . 26
   Appendix A.2. Time Division Multiplexing Pseudowires . . . . . . . 26
   Appendix A.3. Codecs . . . . . . . . . . . . . . . . . . . . . . . 27
   Appendix A.4. MPLS Signaling Protocols . . . . . . . . . . . . . . 28
   Appendix A.5. IPv4 and IPv6  . . . . . . . . . . . . . . . . . . . 28
   Appendix B.   Other Examples of Interworking Issues  . . . . . . . 29
   Appendix B.1. SONET and SDH  . . . . . . . . . . . . . . . . . . . 29
   Appendix B.2. IEEE 802.16d and IEEE 802.16e  . . . . . . . . . . . 30
   Appendix B.3. CDMA and GSM . . . . . . . . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31

Sprecher & Hong         Expires November 1, 2012                [Page 3]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

1.  Introduction

   The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology
   for use in transport network deployments.  Note that transport in
   this document is used in the context of transport networks as
   discussed in Section 1.3 of [RFC5654] and in [RFC5921].  The work on
   MPLS-TP has extended the MPLS toolset with additional architectural
   elements and functions that can be used in any MPLS deployment.
   MPLS-TP is a set of functions and features selected from the extended
   MPLS toolset and applied in a consistent way to meet the needs and
   requirements of operators of packet transport networks.

   Operations, Administration, and Maintenance (OAM) plays a significant
   role in carrier networks, providing methods for fault management and
   performance monitoring in both the transport and the service layers,
   and enabling these layers to support services with guaranteed and
   strict Service Level Agreements (SLAs) while reducing their
   operational costs.

   OAM provides a comprehensive set of capabilities that operate in the
   data plane.  Network-oriented mechanisms are used to monitor the
   network's infrastructure in order to enhance the network's general
   behavior and level of performance.  Service-oriented mechanisms are
   used to monitor the services offered to end customers.  Such
   mechanisms enable rapid response to a failure event and facilitate
   the verification of some SLA parameters.  Fault management mechanisms
   are used for fault detection and localization as well as for
   diagnostics and notification.  Performance management mechanisms
   enable monitoring of the quality of service with regard to key SLA
   criteria (e.g., jitter, latency, and packet loss).

   During the process of development of MPLS-TP, additions to the MPLS
   toolset have been made to ensure that the tools available meet the
   requirements.  These additions were motivated by MPLS-TP, but form
   part of the wider MPLS toolset such that any of them could be used in
   any MPLS deployment.

   One major set of additions provides enhanced support for OAM.  Many
   solutions and protocol extensions have been proposed to address 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 that 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

Sprecher & Hong         Expires November 1, 2012                [Page 4]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

         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

1.1.  Background

   The ITU-T and IETF jointly commissioned a Joint Working Team (JWT) to
   examine the feasibility of a collaborative solution to support OAM
   requirements for MPLS transport networks (MPLS-TP).  The JWT reported
   that it is possible to extend the MPLS technology to fully satisfy
   the requirements [RFC5317].  The investigation by the JWT laid the
   foundations for the work to extend MPLS, but a thorough technical
   analysis was subsequently carried out within the IETF with strong
   input from the ITU-T to ensure that the MPLS-TP OAM requirements
   provided by the ITU-T and IETF would be met.

   The report of the JWT [RFC5317] as accepted by the ITU-T was
   documented in [TD7] and was communicated to the IETF in a liaison
   statement [LS26URL].  In particular, the ITU-T stated that any
   extensions to MPLS technology will be progressed via the IETF
   standards process using the procedures defined in [RFC4929].

   [RFC5317] includes the analysis 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."  This provided a starting point for the work on MPLS-TP.

   [RFC5654] in general, and [RFC5860] in particular, define a set of
   requirements for OAM functionality in MPLS-TP that are applicable to
   MPLS-TP Label Switched Paths (LSPs), Pseudowires (PWs), and MPLS-TP
   links.  These documents are the results of a joint effort by the
   ITU-T and the IETF to include an MPLS Transport Profile within the
   IETF MPLS and PWE3 architectures to enable the deployment of a packet
   transport network that supports the capabilities and functionalities
   of a transport network as defined by the ITU-T.  The OAM requirements
   are derived from those specified by ITU-T in [Y.Sup4].

   An analysis of the technical options for OAM solutions was carried
   out by a design team (the MEAD team) consisting of experts from both
   the ITU-T and the IETF.  The team reached an agreement on the
   principles of the design and the direction for the development of an
   MPLS-TP OAM toolset.  A report was subsequently submitted to the IETF
   MPLS Working Group at the Stockholm IETF meeting in July 2009
   [DesignReportURL].  The guidelines drawn up by the design team have
   played an important role in the creation of a coherent MPLS-TP OAM

Sprecher & Hong         Expires November 1, 2012                [Page 5]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

   The MPLS working group has modularized the function of MPLS-TP OAM
   allowing for separate and prioritized development of solutions.  This
   has given rise to a number of documents each describing a different
   part of the solution toolset.  At the time of writing, the most
   important of these documents have completed development within the
   MPLS working group and are advancing through the IETF process towards
   publication as RFCs.  These documents cover the following OAM

   o  Continuity Check

   o  Connection Verification

   o  On-demand Connection Verification

   o  Route Tracing

   o  Remote Defect Indication

   o  Packet Loss Measurement

   o  Packet Delay Measurement

   o  Lock Instruction

   o  Loopback Testing

   o  Fault Management

   The standardization process within the IETF allows for the continued
   analysis of whether the OAM solutions under development meet the
   documented requirements, and facilitates the addition of new
   requirements if any are discovered.  It is not the purpose of this
   document to analyze the correctness of the selection of specific OAM
   solutions.  This document is intended to explain why it would be
   unwise to standardize multiple solutions for MPLS-TP OAM, and to show
   how the existence of multiple solutions would complicate MPLS-TP
   development and deployment, making networks more expensive to build,
   less stable, and more costly to operate.

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

   It has been suggested that a second, different OAM solution should
   also be developed and documented in an ITU-T Recommendation.  Various
   arguments have been presented for this duplication of effort,

Sprecher & Hong         Expires November 1, 2012                [Page 6]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

   o  Similarity to OAM encodings and mechanisms used in Ethernet.

   o  The existence of two distinct MPLS-TP deployment environments
      called Packet Switched Network (PSN) and Packet Transport Network

   o  The need for similar operational experience in MPLS-TP networks
      and in pre-existing transport networks (especially SONET/SDH

   The first of these was discussed within the IETF's MPLS working group
   where precedence was given to adherence to the JWT's recommendation
   to select a solution that reused as far as possible pre-existing MPLS
   tools.  Additionally, it was decided that consistency with encodings
   and mechanisms used in MPLS was of greater importance.

   The second argument has not been examined in great detail because
   substantive evidence of the existence of two deployment environments
   has not been documented or presented.  Indeed, one of the key
   differences cited between the two allegedly distinct environments is
   the choice of MPLS-TP OAM solution, which makes a circular argument.

   The third argument contains a very important point: network operators
   want to achieve a smooth migration from legacy technologies such as
   SONET/SDH to their new packet transport networks.  This transition
   can be eased if the new networks offer similar OAM features and can
   be managed using tools with similar look and feel.  The requirements
   specifications [RFC5654] and [RFC5860] specifications [RFC5654] and
   [RFC5860] capture the essential issues that must be resolved to allow
   the same look and feel to be achieved.  Since the OAM solutions
   developed within the IETF meet the documented requirements, Network
   Management Systems (NMS) can easily be built to give the same type of
   control of MPLS-TP networks as is seen in other transport networks.
   Indeed, it should be understood that the construction of an NMS is
   not dependent on the protocols and packet formats within the OAM, but
   on the high-level features and functions offered by the OAM.

   This document does not debate the technical merits of any specific
   solution.  That discussion, and the documentation of MPLS-TP OAM
   specifications, was delegated by the IETF and ITU-T to the MPLS
   working group and can be conducted using the normal consensus-driven
   IETF process.  [I-D.ietf-opsawg-oam-overview] presents an overview of
   the OAM mechanisms that have already been defined and that are
   currently being defined by the IETF, as well as a comparison with
   other OAM mechanisms that were defined by the IEEE and ITU-T.

   This document focuses on an examination of the consequences of the
   existence of two MPLS-TP OAM solutions.

Sprecher & Hong         Expires November 1, 2012                [Page 7]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

2.  Terminology and References

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 Telecommunications Union - Telecommunication
           Standardization Sector
   JWT     Joint Working Team
   LSP     Label Switched Path
   MPLS-TP MPLS Transport Profile
   NMS     Network Management Systems
   PDH     Plesiochronous Digital Hierarchy
   OAM     Operations, Administration, and Maintenance
   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 Agreements
   SONET   Synchronous Optical Network
   TDM     Time Division Multiplexing
   TDMoIP  Time Division Multiplexing over IP

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

   This section presents a discussion of the implications of the
   development and deployment of more than one MPLS OAM protocol.  The
   summary is that it can be seen that there are strong technical,
   operational, and economic reasons to avoid the development and
   deployment of anything other than a single MPLS OAM protocol.

3.1.  MPLS-TP is an MPLS Technology

   MPLS-TP is an MPLS technology.  It is designed to apply MPLS to a new
   application.  The original proposers of the concept assumed that the
   transport variant of MPLS would always exist in a disjoint network,
   and indeed their first attempt at the technology (T-MPLS) had a
   number of significant incompatibilities with MPLS that were
   irreconcilable.  When it was established that co-existence in the

Sprecher & Hong         Expires November 1, 2012                [Page 8]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

   same layer network could and would occur, T-MPLS development was
   stopped and the development of MPLS-TP was begun.  In MPLS-TP, MPLS
   was extended to satisfy the transport network requirements in a way
   that was compatible both with MPLS as has already been deployed, and
   with MPLS as the IETF envisioned it would develop in the future.

   Given this intention for compatibility, it follows that the MPLS-TP
   OAM protocols should be designed according to the design philosophies
   that were applied for the existing deployed MPLS OAM and that have
   led to the current widespread adoption of MPLS.  Key elements here
   are scalability and hardware independence, i.e. that the tradeoff
   between scaling to large numbers of monitored objects and the
   performance of the monitoring system should be a matter for vendors
   and operators to resolve, and that the tradeoff should be a soft
   transition rather than a cliff.  Furthermore there should be no
   requirement to execute any component (other than packet forwarding)
   in hardware to achieve usable performance.

3.2.  MPLS-TP is a Convergence Technology

   It is possible to argue that using MPLS for Transport is only a
   stepping stone in the middle of a longer transition.  Quite clearly
   all communication applications are being moved to operate over the
   Internet protocol stack of TCP/IP/MPLS, and the various layers that
   have existed in communications networks are gradually being collapsed
   into the minimum necessary set of layers.  Thus, for example, we no
   longer run IP over X.25 over HDLC over multi-layered Time Division
   Multiplexing (TDM) networks.

   Increasingly the entire point of transport networks is to support the
   transmission of TCP/IP/MPLS.  Using MPLS to construct a transport
   network may be a relatively short-term stepping-stone toward running
   IP and MPLS directly over fiber optics.  MPLS has been deployed in
   operational networks for approximately a decade, and the existing
   MPLS OAM techniques have seen wide deployment.  Service providers are
   not going to stop using the MPLS based OAM techniques that they have
   been using for years, and no one has proposed that they would.  Thus,
   the question is not which OAM to use for transport networks; the
   question is whether service providers want to use two different sets
   of OAM tools in the future converged network.  If we arrive at a
   destination where TCP/IP/MPLS runs directly over fiber, the operators
   will use MPLS OAM tools to make this work.

3.3.  There is an End-to-End Requirement for OAM

   The purpose of OAM is usually to execute a function that operates
   end-to-end on the monitored object (such as an LSP or PW).  Since
   LSPs and PWs provide edge-to-edge connectivity and can cross network

Sprecher & Hong         Expires November 1, 2012                [Page 9]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

   operator boundaries, the OAM must similarly operate across network
   operator boundaries.  This is particularly the case with the
   continuity check and connection verification functions that are
   needed to test the end-to-end connectivity of LSPs and PWs.  It is,
   therefore, necessary that any two equipments that could ever be a
   part of an end-to-end communications path have a common OAM.  This
   necessity is emphasized in the case of equipment executing an edge
   function, since with a global technology such as MPLS it could be
   interconnected with an edge equipment deployed by any other operator
   in any part of the global network.

   This leads to the conclusion that it is desirable for any network
   layer protocol in every equipment to be able to execute or to
   interwork with a canonical form of the OAM.  As we shall demonstrate,
   interworking between protocols adds significant complexity, and thus
   a single default OAM is strongly preferred.

3.4.  The Complexity Sausage

   A frequent driver for the replacement of an established technology is
   a perception that the new technology is simpler, and thus of greater
   economic benefit to the user.  In an isolated system this may be the
   case, however when, as is usually case with communications
   technologies, simplification in one element of the system introduces
   a (possibly non-linear) increase in complexity elsewhere.

   This creates the "squashed sausage" effect, where reduction in
   complexity at one place leads to significant increase in complexity
   at a remote location.  When we drive complexity out of hardware by
   placing complexity in the control plane there is frequently an
   economic benefit, as illustrated by MPLS itself.

   Some motivation for the second OAM solution is the simplicity of
   operation at a single node in conjunction with other transport OAM.
   However, when we drive OAM complexity out of one network element at
   the cost of increased complexity at a peer network element we loose
   out economically and, more importantly, we lose out in terms of the
   reliability of this important network functionality.  Due to the need
   to ensure compatibility of an interworking function between the two
   MPLS-TP OAM solutions (in order to achieve end-to-end OAM) we create
   a situation where neither of two disjoint protocol developments is
   able to make technical advances.  Such a restriction is unacceptable
   within the context of the Internet.

3.5.  Interworking is Expensive and Has Deployment Issues

   The issue of OAM interworking can easily be illustrated by
   considering an analogy with people speaking different languages.

Sprecher & Hong         Expires November 1, 2012               [Page 10]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

   Interworking is achieved through the use of an interpreter.  The
   interpreter introduces cost, slows down the rate of information
   exchange, and may require transition through an intermediate
   language.  There is considerable risk of translation errors and
   semantic ambiguities.  These considerations also apply to computer
   protocols, particularly given the ultra-pedantic nature of such
   systems.  In all cases, the availability of a single working language
   dramatically simplifies the system, reduces cost, and speeds reliable

   If two MPLS OAM protocols were to be deployed we would have to
   consider three possible scenarios:

   1.  Isolation of the network into two incompatible and unconnected

   2.  Universal use of both OAM protocols.

   3.  Placement of interworking (translation) functions or gateways.

   We have many existence proofs that isolation is not a viable
   approach, and the reader is referred to the early T-MPLS discussions
   for examples.  In summary, the purpose of the Internet is to achieve
   an integrated universal connectivity.  Partition of the Internet into
   incompatible and unconnected islands is neither desirable nor

   Universal deployment of both OAM protocols requires the sum of the
   costs associated with each protocol.  This manifests as
   implementation time, development cost, memory requirements, hardware
   components, and management systems.  It introduces additional testing
   requirements to ensure there are no conflicts (processing state,
   fault detection, code path, etc.) when both protocols are run on a
   common platform.  It also requires code and processes to deal with
   the negotiation of which protocol to use and conflict resolution
   (which may be remote and multi-party) when an inconsistent choice is
   made.  In short, this option results in worse than double costs,
   increases the complexity of the resulting system, risks the stability
   of the deployed network, and makes the networks more expensive and
   more complicated to operate.

   The third possibility is the use of some form of interworking
   function.  This is not a simple solution and inevitably leads to cost
   and complexity in implementation, deployment, and operation.  Where
   there is a chain of communication (end-to-end messages passed through
   a series of transit nodes) a choice must be made about where to apply
   the translation and interworking.

Sprecher & Hong         Expires November 1, 2012               [Page 11]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

   o  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 can look very appealing
      and only one end-node is required to be able to perform the
      translation function (effectively speaking both OAM languages).
      But in the more complex reality of the Internet, nearly every
      network node performs the function of an end-node, and so the
      result is that nearly every node must be implemented with the
      capability to handle both OAM protocols and to translate between
      them.  This turns out be even more complex than the universal
      deployment of both protocols discussed above.

   o  In a flat architecture, interworking is performed at a "gateway"
      between islands implementing different protocols.  Gateways are
      substantially complex entities that usually have to maintain end-
      to-end state within the network (something that is against one of
      the fundamental design principles of the Internet) and must bridge
      the differences in state machines, message formats, and
      information elements in the two protocols.  The complexity of
      gateways make them expensive, fragile and unstable, hard to update
      when new revisions of protocols are released, and difficult to

   To deploy an interworking function it is necessary to determine
   whether the OAM protocol on the arriving segment of the OAM is
   identical to the OAM protocol on the departing segment.  Where the
   protocols are not the same, it is necessary to determine which party
   will perform the translation.  It is then necessary to route the LSP
   or PW through a translation point that has both sufficient
   translation capacity and sufficient data bandwidth and adequate path
   diversity.  When an upgraded OAM function is required, the problem
   changes from a two party negotiation to an n-party negotiation with
   commercial and deployment issues added to the mix.

   Note that when an end-to-end LSP or PW is deployed, it may transit
   many networks and the OAM might require repeated translation back and
   forth between the OAM protocols.  The consequent loss of information
   and potential for error is similar to the children's game of Chinese

3.6.  Selection of a Single OAM Solution When There is a Choice

   When there is a choice of protocols for deployment or operation, a
   network operator must make a choice.  Choice can be a good thing when
   it provides for selection between different features and functions,
   but it is a burden when the protocols offer essentially the same
   functions, but are incompatible.

Sprecher & Hong         Expires November 1, 2012               [Page 12]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

   In this case, the elements of the choice include:

   o  Which protocol will continue to be developed by its SDO?

   o  Which protocol is most stable in implementations?

   o  How to test and evaluate the two protocols?

   o  Which vendors support and will continue to support which protocol?

   o  What equipment from different vendors is compatible?

   o  Which management tools support which protocols?

   o  What protocols are supported by peer operators and what
      interworking function is needed?

   o  Which protocols are engineers experienced with and trained in?

   o  What are the consequences of a wrong choice?

   o  Will it be possible to migrate from one protocol to another in the

   o  How to integrate with other function already present in the

   o  How to future-proof against the inclusion of new function in the

   At the very least, the evaluation of these questions constitute a
   cost and introduce delay for the operator.  The consequence of a
   wrong choice could be very expensive, and it is likely that any
   comparative testing will more than double the lab-test costs prior to

   From a vendor's perspective, the choice is even harder.  A vendor
   does not want to risk not offering a product for which there is
   considerable demand, so both protocols may need to be developed
   leading to more than doubled development costs.  Indeed, code
   complexity and defect rates have often been shown to increase worse
   than linearly with code size, and (as noted in a previous section)
   the need to test for co-existence and interaction between the
   protocols adds to the cost and complexity.

   It should be noted that, in the long-run, it is the end-users who pay
   the price for the additional development costs and any network
   instability that arises.

Sprecher & Hong         Expires November 1, 2012               [Page 13]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

3.7.   Migration Issues

   Deployment of a technology that is subsequently replaced or obsoleted
   often leads to the need to migrate from one technology to another.
   Such a situation might arise if an operator deploys one of the two
   OAM protocol solutions and discovers that it needs to move to use the
   other one.  A specific case would be 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 would be 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 be service-affecting even with
   sophisticated devices with redundant hardware components.
   Furthermore, since it would be impractical to upgrade every device in
   the network at the same time, there is a need for either a
   significantly large maintenance period across the whole network or
   for a rolling plan that involves upgrading 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.  Such networks are not
   desirable because of their cost and complexity.

   In short, the potential for future migration will need to be part of
   the deployment planning exercise when there are two OAM protocols to
   choose between.  This issue will put pressure on making the "right"
   choice when performing the selection described in Section 3.6.

4.  Potential Models For Coexistence

   This section expands upon the discussion in Section 3 by examining
   three questions:

   o  What does it mean for two protocols to be incompatible?

   o  Why can't we assume that the two solutions will never coexist in
      the same network?

   o  What models could we support for coexistence?

Sprecher & Hong         Expires November 1, 2012               [Page 14]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

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
   such that data packets would be intercepted and mistaken for OAM

   A lesser incompatibility arises where 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 the
   packets of the other protocol to be discarded and may result in the
   LSP or PW being torn down.

   The least level of incompatibility is where the packets of one
   protocol are recognized as "unknown" by implementations of the other
   protocol.  In this case the protocols rules of one protocol allow the
   packets of the other protocol to be ignored, and they are either
   silently discarded or forwarded untouched.

   These are issues with all of these grades of incompatibility ranging
   from disruption or corruption of user data, through connection
   failure, to the inability 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 wish to merge the operation of the two networks.
   This makes partitioning networks by protocol deployment a significant
   issue for future-proofing commercial interactions.  Although a
   network operator may wish to present difficulties to disincentivize
   hostile take-over (a poison pill) most operators are interested in
   future options to grow their networks.

   As described in Section 3.2, MPLS is a convergence technology.  That
   means that there is 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 is a need for OAM to span multiple networks.

Sprecher & Hong         Expires November 1, 2012               [Page 15]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

   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
   initially planned.

4.3.  Models for Coexistence

   Two models for co-existence 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:

       *  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

       *  Fully-integrated dual mode where all nodes support both

   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:

       *  "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 of 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
   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.

Sprecher & Hong         Expires November 1, 2012               [Page 16]

Internet-Draft         MPLS-TP OAM Considerations             April 2012  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 cannot form part of
   the OAM function for the LSP or PW.

   In order to provision an end-to-end connection that benefits from the
   full OAM functionality, the planning and path-computation tool must
   know the capabilities of each network node, and must select a path
   that includes only nodes of 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 of the same OAM capability.
   This leads to 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 of 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.  Partial Integration

   In a partially integrated network, the network in Section 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 is greater
   connectivity potential in the network.  Dual Mode

   Dual mode is a development of partial integration described in
   Section such that all nodes in the network are capable of
   both OAM protocols.  As in that Section, 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.  Thus, every LSP or PW in

Sprecher & Hong         Expires November 1, 2012               [Page 17]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

   the network can be configured to use either of the OAM protocols.

   However, it seems unlikely that an operator would choose which OAM
   protocol to use on a per LSP or per PW basis.  That would lead to
   additional complexity in the management system and potential
   confusion if additional diagnostic analytics need to be performed.
   This mode increases the complexity of implementation, deployment, and
   operation without adding to the function within the network (since
   both OAM solutions provide the same level of function), so this mode
   would not be selected for deployment except, perhaps, during
   migration of the network from one OAM protocol to the other.

4.3.2.  Island Model

   In the island model, regions or clusters of nodes with the same OAM
   capabilities are grouped together.  Tools to interconnect the
   technologies are deployed based on layered networking or on
   interworking between the protocols.  These lead to the two sub-models
   described in the sections that follow.  Islands in a Sea

   One way to view clusters of nodes supporting one OAM protocol is as
   an island in a sea of nodes supporting the other protocol.  In this
   view, tunnels are used to carry LSPs or PWs using one OAM type across
   the sea and into another island of a compatible OAM type.  The tunnel
   in this case is an LSP utilizing the OAM protocol supported by the
   nodes in the sea.  Theoretically an island can be as small as one
   node, and the strait between two islands can be as narrow as just one

   Layering in this way is an elegant solution to operating two
   protocols simultaneously and is, of course, used to support different
   technologies (such as MPLS over optical).  However, in such layering
   deployments there is no simple integration of OAM between the layers,
   and the OAM in the upper layer must regard the tunnel as a single hop
   with no visibility into the OAM of the lower layer.  Diagnostics
   within the upper layer are complicated by this "hiding" of the nodes
   along the path of the tunnel in the lower layer.

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

   A number of islands may lie along the path between end-points
   necessitating the use of more than one tunnel.  To further complicate

Sprecher & Hong         Expires November 1, 2012               [Page 18]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

   matters, the islands may lie in an inland sea so that it is necessary
   to nest tunnels.

   Regardless of the scenario, operating tunnels/layers adds to the
   management complexity and expense.  Furthermore, it should be noted
   that in an MPLS network there is often a call for any-to-any
   connectivity.  That is, any node in the network may need to establish
   an LSP or a PW to any other node in the network.  As previously
   noted, the end-points of any LSP or PW must support the same OAM type
   in the islands-in-a-sea model, so this tends to imply that all, or
   nearly all, nodes will end up needing to support both OAM protocols.

   The use of tunnels can also degrade network services unless carefully
   coordinated.  For example, a service in the upper layer may be
   provisioned with protection so that a working and backup path is
   constructed using diverse paths to make them robust against a single
   failure.  However, the paths of the tunnels (in the lower layer) are
   not visible to the path computation in the upper layer with the risk
   that the upper layer working and protection paths share a single
   point of failure in the lower layer.  Traffic engineering techniques
   have been developed to resolve this type of issue, but they add
   significant complexity to a system that would be a simple flat
   network if only one OAM technology was used.  Border Crossings

   Instead of connecting islands with tunnels across the sea, islands of
   different types can be connected direct so that the LSP or PW
   transits the series of islands without tunneling.  In this case
   protocol translation is performed each time the LSP/PW crosses a
   border between islands that use a different OAM protocol.

   In principle this makes for a straight-forward end-to-end connection.
   However, protocol translation presents a number of issues as
   described in Section 3.  The complexity is that in planning the end-
   to-end connection, gateways with protocol translation capabilities
   must be selected to lie 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:

   o  The IETF solution is taking too long to standardize

   o  Commonality with Ethernet solutions is beneficial

Sprecher & Hong         Expires November 1, 2012               [Page 19]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

   o  There are two different application scenarios

   o  There is no risk of interaction between the solutions

   o  The market should be allowed to decide between competing

   The following sections look briefly at each of these claims.

5.1.  Progress of the IETF Solution

   The MPLS-TP OAM work carried out within the IETF is the product of
   joint work within the IETF and ITU-T communities.  That is, all
   interested parties share the responsibility for progressing this work
   as fast as possible.  Since the work is contribution-driven, there is
   no reason to assume that consensus on the technical content of the
   work could be reached any faster.

   Opening discussions on a second solution seems certain to increase
   the work-load, and will only slow down the speed at which consensus
   is reached.

   The core work on MPLS-TP OAM within the IETF completed and the
   specifications were published as RFCs.  For more information, see

5.2.  Commonality with Ethernet OAM

   Ethernet can be used to build packet transport networks and so there
   is an argument that Ethernet and MPLS-TP networks will be operated as
   peers.  Examining the issues of end-to-end connections across mixed
   networks, many of the same issues as discussed in Section 4 arise.
   If a peer networking gateway model (see Section is applied
   there is a strong argument to making the OAM technologies as similar
   as possible.

   While this might be a valid discussion point when selecting the
   single OAM solution for MPLS-TP, it is countered by the need to
   achieve OAM consistency between MPLS and MPLS-TP networks.  One might
   make the counter argument that if there is a strong need to make
   MPLS-TP as similar as possible to Ethernet, it would be better to go
   the full distance and simply deploy Ethernet.

   Furthermore, the approach of a second MPLS-TP OAM protocol does not
   resolve anything.  Since MPLS-TP is not Ethernet, a gateway will
   still be needed, and this would constitute a second MPLS-TP OAM so
   additional gateways or interworking functions will be needed because
   coexistence is inevitable as described in the rest of this document.

Sprecher & Hong         Expires November 1, 2012               [Page 20]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

   Additionally, it may be claimed that implementation can be simplified
   if the OAM solution developed for MPLS-TP is similar to Ethernet OAM.
   This would apply both in the hardware/software implementing the OAM,
   and at the server-to-client interface where OAM-induced fault status
   is reported.  The questions here are very much implementation-
   dependent and are the necessary function is contained within
   individual nodes.  The counter argument is that implementation
   simplicity can also be achieved by making MPLS-TP OAM similar to MPLS
   OAM especially since the client technology may well be IP/MPLS and
   since MPLS is an end-to-end technology.

5.3.  Different Application Scenarios

   It has been suggested that two different applications of MPLS-TP
   exist: Packet Switched Network (PSN) and Packet Transport Network
   (PTN).  These applications have not been documented in the IETF and
   most of the support for the idea has come in discussions with a
   documentationin the ITU-T [TD522].

   One of the stated differences between these applications lies in the
   OAM tools that are required to support the distinct operational
   scenarios.  The OAM used in a PSN should be similar to that used in
   an MPLS network (and so should be the MPLS-TP OAM defined in the
   IETF) while the OAM used in a PTN should provide the same operational
   experience to that found in SONET/SDH and OTN networks.

   The basic MPLS-TP OAM requirements in [RFC5654] make this point,

         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.

   Thus, the look-and-feel of the OAM has been a concern in the design
   of MPLS-TP from the start, and the solutions that have been defined
   in the IETF were designed to comply with the requirements and to
   provide operational behavior, functionality and processes similar to
   those available in existing transport networks.  In particular, the
   toolset supports the same controls and indications as those present
   in other transport networks, and the same management information
   model can be used to support the MPLS-TP OAM tools (in areas where
   the technology type is irrelevant).

   It is important to note that the operational look-and-feel does not
   determine the way in which OAM function is achieved.  There are

Sprecher & Hong         Expires November 1, 2012               [Page 21]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

   multiple ways of achieving the required functionality while still
   providing the same operational experience and supporting the same
   management information model.  Thus, the OAM protocol solution does
   not dictate the look-and-feel, and the demand for a particular
   operational experience does not necessitate the development of a
   second OAM protocol.

5.4.  Interaction Between Solutions

   Section 3 of this document discusses how network convergence occurs
   and indicates that where two MPLS-TP solutions exist they are, in
   fact, very likely to appear either in the same network or at gateways
   between networks in order to provide an end-to-end OAM functionality.

   Indeed, since nodes offering either solution are likely to both be
   branded as "MPLS-TP", and since network interoperation (as described
   in Section 4) demands the existence of some nodes that are either
   dual-mode or act as protocol translators/gateways, there is
   considerable likelihood of the two OAM solutions interacting through
   design or through accident.  When a node is capable of supporting
   both OAM protocols, it must be configured to support the correct
   protocol for each interface and LSP/PW.  When a device has interfaces
   that offer different MPLS-TP OAM function, the risk of
   misconfiguration is significant.  When a device is intended to
   support end-to-end connections, it may need to translate, map, or
   tunnel to accommodate both protocols.

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

   When two technologies compete it is common to let the market decide
   which one will survive.  Sometimes the resolution is quite fast, and
   one technology dominates the other before there is widespread
   deployment.  Sometimes it takes considerable time before one
   technology overcomes the other, perhaps because one technology has
   become entrenched before the emergence of the other, as in the case
   of MPLS replacing ATM.  In more cases, however, the market does not
   select in favor of one technology or the other - as in many of the
   cases described in Sections 4 and 5 of this document, sometimes both
   technologies continue to live in the network.

   Letting the market decide is not a cheap option.  Even when the
   resolution is rapid, equipment vendors and early adopters pay the
   price of both technologies.  When it takes longer to determine which
   technology is correct there will be a period of coexistence followed
   by the need to transition equipment from the losing solution to the

Sprecher & Hong         Expires November 1, 2012               [Page 22]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

   winning one.  In the cases where no choice is made, the network is
   permanently complicated by the existence of the competing

   In fact, the only time when allowing the market to decide can be
   easily supported is when the competing technologies do not overlap.
   In those cases, for example different applications in the user-space,
   the core network is not perturbed by the decision-making process and
   transition from one technology to the other is relatively painless.
   This is not the case for MPLS-TP OAM, and coexistence while the
   market determines the correct approach would be expensive, while the
   necessary transition after the decision has been 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
   raise a number of security concerns:

   o  Each OAM protocol must be secured.  This leads to the existence of
      two security solutions each needing configuration and management.
      The increased complexity of operating security mechanisms tends to
      reduce the likelihood of them being used in the field and so
      increases the vulnerability of the network.  Similarly, the
      existence of two security mechanisms raises the risk of

   o  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 and, because some nodes may
      support both OAM protocols, it may be possible to cause the
      disruption at a remote point in the network.

   o  Securing a network protocol is not a trivial matter for protocol
      designers.  Duplicating design effort is unlikely to result in a
      stronger solution and runs the risk of diluting the effort and
      creating two less-secure solutions.

7.  IANA Considerations

   This informational document makes no requests for IANA action.

Sprecher & Hong         Expires November 1, 2012               [Page 23]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

8.  Acknowledgment

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

   Thanks to Huub van Helvoort for supplying text and history about

9.  References

9.1.  Normative References

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

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

9.2.  Informative References

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

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

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

   [RFC5086]  Vainshtein, A., 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. and L. Andersson, "Joint Working Team (JWT)
              Report on MPLS Architectural Considerations for a
              Transport Profile", RFC 5317, February 2009.

Sprecher & Hong         Expires November 1, 2012               [Page 24]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

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

              Mizrahi, T., Sprecher, N., Bellagamba, E., and Y.
              Weingarten, "An Overview of Operations, Administration,
              and Maintenance (OAM) Mechanisms",
              draft-ietf-opsawg-oam-overview-06 (work in progress),
              March 2012.

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

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

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

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

   [LS26URL]  "LS: Cooperation Between IETF and ITU-T on the Development
              of MPLS-TP", December 2008, <http://datatracker.ietf.org/

              "IETF 75 Proceedings, MPLS-TP OAM Analysis", July 2009, <h

              "Milestone Achieved in Internet Carrier Network Standards
              -  Multiprotocol Label Switching Transport Profile
              (MPLS-TP) Specifications Published", December 2011,

Appendix A.  Examples of Interworking Issues in the Internet

   It is, of course, right to observe that there are a number of
   instances of multiple protocols serving the same purpose that have
   arisen within the Internet.  It is valuable to examine these examples
   to understand what issues they have caused and how they have been

Sprecher & Hong         Expires November 1, 2012               [Page 25]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

Appendix A.1.  IS-IS/OSPF

   IS-IS and OSPF are two competing link state IGP routing protocols
   that derive from the same root technology and which, for political
   and personality reasons, were never reconciled prior to wide-scale
   deployment.  It is an accident of history that one of these protocols
   did not gain overwhelming deployment and so force the other into

   The existence of these two widely deployed and highly functional
   competing IGPs doubles the cost of link state IGP maintenance and
   deployment in the Internet.  This is a situation that will almost
   certainly continue for the lifetime of the Internet.  Although the
   Internet is clearly successful and operates well, the existence of
   these two IGPs forces router vendors to implement both protocols
   (doubling the protocol cost of all routers even when an operator only
   wants to deploy one of the protocols), forcing an operator to make an
   active choice between IGPs during deployment, and requiring a gateway
   function between the islands of protocol use.

   A mitigating factor in this specific case is that, owing to the way
   networks are partitioned for administrative and scaling reasons,
   there already existed a gateway routing protocol called BGP that
   propagates a summarized form of the IGP reachability information
   through-out the Internet.  BGP means that there is actually no
   requirement for IS-IS and OSPF to interwork directly: that is, there
   is no need for a translation function between OSPF and IS-IS, and the
   two IGPs can continue to exist without impacting the function of the
   Internet.  Thus, unlike the situation with MPLS OAM, the choice of
   IGP protocol is truly a local decision, however, there is a cost to
   BGP implementations that must support interactions with both OSPF and

Appendix A.2.  Time Division Multiplexing Pseudowires

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

   o  SAToP is a relatively simple design.  It is a Proposed Standard
      RFC [RFC4553] and is the mandatory to implement, default, mode of

   o  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

Sprecher & Hong         Expires November 1, 2012               [Page 26]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

   In this case all implementations must include the default mode of
   operation (SAToP).  This means that end-to-end operation is
   guaranteed: an operator can select equipment from any vendor in the
   knowledge that they will be able to build and operate an end-to-end
   TDM PW service.

   If an operator wishes to deploy a TDM PW optimized for a specific
   application they may select equipment from a vendor offering CESoPSN
   or TDMoIP in addition to SAToP.  Provided that all of their equipment
   and their management system can handle the optimized approach, they
   can run this in their network, but the operator has to carry the cost
   of selecting, purchasing, configuring, and operating the extended
   mode of operation.

   This situation is far from ideal, and it is possible that long-
   distance, multi-operator optimized TDM PWs cannot be achieved.
   However, the existence of a default mode implemented in all devices
   helps to reduce pain for the operator and ensures that simpler end-
   to-end operation is always available.  Additionally, the growth of
   other protocols is acting to diminish the use of long distance TDM
   circuits making this a self limiting problem.

Appendix A.3.  Codecs

   The n-squared codec interworking problem was brought to the attention
   of the IETF by the ITU-T when the IETF started its work on a royalty-
   free codec suitable for use in the Internet.  Every time a new codec
   is deployed, translation between it and all other deployed codecs
   must be available within the network, each participating node must be
   able to handle the new codec.  Translation between codecs is
   expensive and can lead to reduced quality.

   This problem seriously constrains the addition of new codecs to the
   available set, and new codecs are only designed and released when
   there is a well established need (such as a major difference in

   The application layer of the Internet is, however, predicated on a
   business model that allows for the use of shared, free, and open-
   source software; this model requires the existence of a royalty-free
   codec.  This, together with the specific characteristics of
   transmission over lossy packet networks, comprised requirements
   equivalent to a major difference in functionality, and led to work in
   the IETF to specify a new codec.

   The complexity, economic, and quality costs associated with
   interworking with this new codec will need to be factored into the
   deployment model.  This, in turn, may adversely effect its adoption

Sprecher & Hong         Expires November 1, 2012               [Page 27]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

   and the viably of its use in the Internet.

Appendix A.4.  MPLS Signaling Protocols

   There are three MPLS signaling control protocols used for
   distributing labels to set up LSPs and PWs in MPLS networks: LDP,
   RSVP-TE, and GMPLS.

   The application domain for each of these is different, and unlike the
   OAM situation, there is limited requirement for interworking between
   the protocols.  For example, although one provider may use LDP to set
   up LSPs while its peer uses RSVP-TE, connectivity between the two
   providers usually takes place at the IP layer.

   It should be noted that the IETF initially worked on another
   signaling protocol called CR-LDP with variants applicable to MPLS and
   to GMPLS.  The development of this protocol was allowed to progress
   in parallel with RSVP-TE.  However, once it was possible to determine
   that the solution preferred by the community of vendors and operators
   was RSVP-TE, the IETF terminated all further work on CR-LDP.  No
   translation function or gateway point interfacing RSVP-TE to CR-LDP
   was ever proposed.

Appendix A.5.  IPv4 and IPv6

   If there were ever an example of why protocol interworking is to be
   avoided if at all possible, it is the transition from IPv4 to IPv6.

   The reasons for introducing IPv6 into the Internet are well rehearsed
   and don't need discussion here.  IPv6 was not introduced as a
   competitor to IPv4, but rather as a planned replacement.  The need
   for the transition to IPv6 arises from the expansion of the network
   size beyond the wildest dreams of the creators of the Internet, and
   the consequent depletion of the IPv4 address space.

   This transition has proved to be the hardest problem that the IETF
   has ever addressed.  The invention and standardization of IPv6 was
   straight-forward by comparison, but it has been exceptionally
   difficult to migrate networks from one established protocol to a new

   The early assumption that by the time the IPv4 address space was
   exhausted IPv6 would be universally deployed failed to materialize
   due to (understandable) short-term economic constraints.  Early
   migration would have been simpler and less costly than the current
   plans.  The Internet is now faced with the considerable complexity of
   implementing and deploying interworking functions.

Sprecher & Hong         Expires November 1, 2012               [Page 28]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

   If anything can be learned from the IPv4/IPv6 experience it is that
   every effort should be applied to avoid the need to migrate or
   jointly operate two protocols within one network.  Adding to the mix
   a number of issues caused by OAM interworking of MPLS, one of the
   Internet's core protocols, would be most unwelcome and would
   complicate matters still further.

Appendix B.  Other Examples of Interworking Issues

Appendix B.1.  SONET and SDH

   SONET and SDH were defined as competing standards that basically
   provided the same functionality (simultaneous transport of multiple
   circuits of differing origin within a single framing protocol).
   SONET was developed first by ANSI based on the 24 channel PDH
   hierarchy existing in North America and Japan.  The basic rate based
   on DS3.  Some time later ETSI developed SDH based on the 30 channnel
   PDH deployed in Europe.  The basic rate based on E4 (3x DS3).

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

   Significant confusion resulted from this situation.  Equipment
   manufacturers initially needed to select the market segment they
   intended to address.  The cost of chipsets for a limited market
   increased and only a limited number of equipment manufactures were
   available for selection in each market.

   Obviously, most equipment vendors wanted to sell their equipment in
   both regions.  Hence, today most chips support both SONET and SDH,
   and the selection is a matter of provisioning.  The impact of the
   additional function to support both markets has had a mixed impact on
   cost.  It has enabled a higher volume of production which reduced
   cost, but it has required increased development and complexity which
   increased cost.

   Because the regions or applicability of SONET and SDH are well known,
   service providers do not need to consider the merits of the two
   standards and their long-term role in the industry when examining
   their investment options.

   To be able to deploy SONET and SDH worldwide the regional SDO experts
   came together in ITU-T to define a frame structure and a frame-rate
   that would allow interconnection of SONET and SDH.  A compromise was
   agreed and approved in an ITU-T meeting in Seoul in 1988.

   The SDH standard supports both the North American and Japanese 24

Sprecher & Hong         Expires November 1, 2012               [Page 29]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

   channel/T1/T3 hierarchy and the European 30 channel/E1/E4 based
   hierarchy within a single multiplexing structure.  SDH has no options
   for payloads at VC-4 (150Mb/s) and above.  This has provided the
   basis for common solutions for packet based clients (GFP).  SDH
   allows T1/T3 services to be delivered in Europe and E1 services to be
   delivered in North America using a common infra structure.

   Deployment of a E1 only standard in North America would have required
   the conversion of all of the 24 channel/T1 deployed equipment and
   services into the 30 channel/E1 format.  Similarly deployment of a T1
   only standard in Europe would have required the conversion of all of
   the 30 channel/E1 equipment and services into 24 channel/T1 format.
   Clearly given the existing network deployments (in 1988) this was not
   a practical proposition.

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

   A massive interworking function had to be implemented in order to
   provide global connectivity (e.g., through U.S. and Europe) and this
   resulted in an increase in operational overhead.  The interworking
   function has to be performed before the SDH-based segment is reached.
   The reason for placing the interworking function on the SONET side
   was that in a previous agreement on interconnection the functionality
   was placed on the European side.

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

   IEEE 802.16d and IEEE 802.16e were two different, incompatible
   iterations of the WiMAX standards.  In addition to the issues
   described for SONET/SDH, developers who implemented IEEE 802.16d
   found that they could not re-use their equipment design when
   developing the IEEE 802.16e variant.  This increased the cost of
   development and lengthened the time to market.

Appendix B.3.  CDMA and GSM

   CDMA and GSM are two competing technologies for mobile connectivity.

   In addition to all the undesirable effects described above, the
   existence of these two technologies adversely affected customers who
   used roaming when overseas.  Sometimes, customers were obliged to
   obtain an additional device from their service providers in order to
   roam when travelling abroad (for example, when travelling from Europe
   to the U.S).

Sprecher & Hong         Expires November 1, 2012               [Page 30]

Internet-Draft         MPLS-TP OAM Considerations             April 2012

Authors' Addresses

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

   Email: nurit.sprecher@nsn.com

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

   Email: hongk@cisco.com

Sprecher & Hong         Expires November 1, 2012               [Page 31]

Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/