| Network Working Group | N. Sprecher |
| Internet-Draft | Nokia Siemens Networks |
| Intended status: Informational | KY. Hong |
| Expires: October 30, 2012 | Cisco Systems |
| April 30, 2012 |
The Reasons for Selecting a Single Solution for MPLS-TP OAM
draft-sprecher-mpls-tp-oam-considerations-02.txt
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 standardization.
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."
This Internet-Draft will expire on October 30, 2012.
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.
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:
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 solution.
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 features:
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.
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, including:
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.
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 |
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.
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 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.
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.
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 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.
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.
The issue of OAM interworking can easily be illustrated by considering an analogy with people speaking different languages. 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 communication.
If two MPLS OAM protocols were to be deployed we would have to consider three possible scenarios:
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 acceptable.
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.
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 Whispers.
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.
In this case, the elements of the choice include:
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 deployment.
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.
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.
This section expands upon the discussion in Section 3 by examining three questions:
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 packets.
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.
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.
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.
Two models for co-existence can be considered:
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.
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.
In a partially integrated network, the network 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 is greater connectivity potential in the network.
Dual mode is a development of partial integration described in Section 4.3.1.2 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 6.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 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.
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.
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 node.
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 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.
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.
The decision to define and develop an alternative MPLS-TP OAM solution was based on several assertions:
The following sections look briefly at each of these claims.
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 [ISOCAccounceURL].
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 4.3.2.2) 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.
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.
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, saying:
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 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.
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.
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 winning one. In the cases where no choice is made, the network is permanently complicated by the existence of the competing technologies.
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.
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:
This informational document makes no requests for IANA action.
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 SONET/SDH.
| [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. |