Internet Engineering Task Force (IETF) N. Sprecher Request for Comments: 6670 Nokia Siemens Networks Category: Informational KY. Hong ISSN: 2070-1721 Cisco Systems July 2012 The Reasons for Selecting a Single Solution for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM)
AbstractThe 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.
Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6670. 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.
1. Introduction ....................................................4 1.1. Background .................................................5 1.2. The Development of a Parallel MPLS-TP OAM Solution .........7 2. Terminology .....................................................8 2.1. Acronyms ...................................................8 3. Motivations for a Single OAM Solution in MPLS-TP ................9 3.1. MPLS-TP Is an MPLS Technology ..............................9 3.2. MPLS-TP Is a Convergence Technology ........................9 3.3. There Is an End-to-End Requirement for OAM ................10 3.4. The Complexity Sausage ....................................10 3.5. Interworking Is Expensive and Has Deployment Issues .......11 3.6. Selection of a Single OAM Solution When There Is a Choice ....................................................13 3.7. Migration Issues ..........................................14 4. Potential Models for Coexistence ...............................15 4.1. Protocol Incompatibility ..................................15 4.2. Inevitable Coexistence ....................................16 4.3. Models for Coexistence ....................................16 4.3.1. The Integrated Model ...............................17 4.3.2. The Island Model ...................................18 5. The Argument for Two Solutions .................................20 5.1. Progress of the IETF Solution .............................20 5.2. Commonality with Ethernet OAM .............................21 5.3. Different Application Scenarios ...........................21 5.4. Interaction between Solutions .............................22 5.5. Letting the Market Decide .................................23 6. Security Considerations ........................................24 7. Acknowledgments ................................................24 8. References .....................................................24 8.1. Normative References ......................................24 8.2. Informative References ....................................25 Appendix A. Examples of Interworking Issues in the Internet .......27 A.1. IS-IS/OSPF .................................................27 A.2. Time Division Multiplexing Pseudowires .....................28 A.3. Codecs .....................................................28 A.4. MPLS Signaling Protocols ...................................29 A.5. IPv4 and IPv6 ..............................................29 Appendix B. Other Examples of Interworking Issues .................30 B.1. SONET and SDH ..............................................30 B.2. IEEE 802.16d and IEEE 802.16e ..............................32 B.3. CDMA and GSM ...............................................32
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 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 of [RFC1958] says: If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements. 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 the 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 [LS26]. 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 Pseudowire Emulation Edge-to-Edge (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 the 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 [DesignReport]. 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 this writing, the most important of these documents have completed development within the MPLS working group and are advancing through the IETF process toward publication as RFCs. These documents cover the following OAM features: 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. 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 (NMSs) 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. [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.
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. Section 4, interworking between protocols adds significant complexity; thus, a single default OAM is strongly preferred.
Some motivation for the second OAM solution is the simplicity of operation at a single node in conjunction with other transport OAM mechanisms. However, when we drive OAM complexity out of one network element at the cost of increased complexity at a peer network element, we lose 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.
fault detection, code path, etc.) when both protocols are run on a common platform. It also requires code and the processes to deal with the negotiation of which protocol to use and to deal with conflict resolution (which may be remote and multi-party) when an inconsistent choice is made. In short, this option results in more than double the cost, 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. 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 to 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 makes them expensive, fragile, and unstable; hard to update when new revisions of protocols are released; and difficult to manage. 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 sufficient translation capacity and sufficient data bandwidth, as well as 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 "telephone".
At the very least, the evaluation of these questions constitutes a cost and introduces 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 more than linearly with code size, and (as noted in Section 3.5) the need to test for coexistence and interaction between the protocols adds to the cost and complexity. 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. 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. 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?
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.
2. An "island" model, where groups of similar nodes are deployed together. In this model, there may be translation or mapping, but it is not always required. This model can be further decomposed as follows: * "Islands in a sea", where connectivity between islands of the same type is achieved across a sea of a different type. * "Border crossings", where connectivity between different islands is achieved at the borders between them. 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 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. Section 22.214.171.124 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. Section 126.96.36.199) 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 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.
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. 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 core work on MPLS-TP OAM within the IETF was completed, and the specifications were published as RFCs. For more information, see [ISOCAnnounce]. Section 4 arise. If a peer networking gateway model (see Section 188.8.131.52) is applied, there is a strong argument for 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. 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, as 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. 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 as that found in SONET/SDH and Optical Transport Networks (OTNs). The basic MPLS-TP OAM requirements in [RFC5654] make this point as follows: Furthermore, for carriers it is important that operation of such packet transport networks should preserve the look-and-feel to which carriers have become accustomed in deploying their optical transport networks, while providing common, multi-layer operations, resiliency, control, and multi-technology management. 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 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 functions, 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. 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; 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.
[RFC5654] Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M., Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS Transport Profile", RFC 5654, September 2009. [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010.
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, June 1996. [RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure- Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, June 2006. [RFC4929] Andersson, L., Ed., and A. Farrel, Ed., "Change Process for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, June 2007. [RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and P. Pate, "Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)", RFC 5086, December 2007. [RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, December 2007. [RFC5317] Bryant, S., Ed., and L. Andersson, Ed., "Joint Working Team (JWT) Report on MPLS Architectural Considerations for a Transport Profile", RFC 5317, February 2009. [RFC5921] Bocci, M., Ed., Bryant, S., Ed., Frost, D., Ed., Levrau, L., and L. Berger, "A Framework for MPLS in Transport Networks", RFC 5921, July 2010. [OAM-OVERVIEW] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Mechanisms", Work in Progress, March 2012. [Y.Sup4] "Supplement on transport requirements for T-MPLS OAM and considerations for the application of IETF MPLS technology", ITU-T Y.1300-series Supplement 4, January 2008. [G.707] "Network node interface for the synchronous digital hierarchy (SDH)", ITU-T Recommendation G.707, January 2007.
[TD7] "IETF and ITU-T cooperation on extensions to MPLS for transport network functionality", ITU-T TD7 (WP3/SG15), December 2008. [TD522] "Clarification of the PTN/solution X environment", ITU-T TD522 (WP3/SG15), February 2011. [LS26] "Cooperation Between IETF and ITU-T on the Development of MPLS-TP", ITU-T COM 15-LS26-E, December 2008, <http://datatracker.ietf.org/documents/LIAISON/ file596.pdf>. [DesignReport] "MPLS-TP OAM Analysis", Proc. IETF 75, Stockholm, Sweden, July 2009, <http://www.ietf.org/proceedings/75/slides/ mpls-17/mpls-17_files/frame.htm>. [ISOCAnnounce] "Milestone Achieved in Internet Carrier Network Standards - Multiprotocol Label Switching Transport Profile (MPLS-TP) Specifications Published", Internet Society, December 2011, <http://www.isoc.org/standards/mpls.shtml>.
RFC4553] and is the mandatory-to-implement, default mode of operation. 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 RFCs. 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 he 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, he may select equipment from a vendor offering CESoPSN or TDMoIP in addition to SAToP. Provided that all of his equipment and his management system can handle the optimized approach, he can run this in his network, but he 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.
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 functionality). 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 affect its adoption and the viability of its use in the Internet.
transition to IPv6 arose from the expansion of the network size beyond the wildest dreams of the creators of the Internet and from 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 were straightforward by comparison, but it has been exceptionally difficult to migrate networks from one established protocol to a new protocol. 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. 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.
Until 1988, the standards were unpublished and under development. o The SONET standard ANSI T1.105-1988 was published in 1988. o The SDH standard ETSI EN 300 417 was first published in 1992. o The compromise SDH/SONET standard ITU-T G.707 was published in 1988 (see below for the nature of this compromise). Some implementers were confused by 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 manufacturers 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 of 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 the ITU-T to define a frame structure and a frame rate that would allow interconnection of SONET and SDH. A compromise was agreed upon and approved in an ITU-T meeting in Seoul in 1988. The SDH standard supports both the North American and Japanese 24-channel/T1/T3 hierarchy and the European 30-channel/E1/E4-based hierarchy within a single multiplexing structure. SDH has options for payloads at VC-4 (150 Mb/s) and above. SDH allows T1/T3 services to be delivered in Europe and E1 services to be delivered in North America using a common infrastructure. Deployment of an 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
the 24-channel/T1 format. Clearly, given the existing network deployments (in 1988), this was not a practical proposition and was the principal reason why a compromise was reached. The result of the compromise is documented in ITU-T Recommendation G.707 [G.707], which includes the frame definition and frame rates and also documents how SONET and SDH can interconnect. An extensive interworking function had to be implemented in order to provide global connectivity (e.g., throughout the 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.