idnits 2.17.1 draft-sprecher-mpls-tp-oam-considerations-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1136 has weird spacing: '...ansport netwo...' -- The document date (April 30, 2012) is 4350 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-opsawg-oam-overview-06 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Sprecher 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational KY. Hong 5 Expires: November 1, 2012 Cisco Systems 6 April 30, 2012 8 The Reasons for Selecting a Single Solution for MPLS-TP OAM 9 draft-sprecher-mpls-tp-oam-considerations-03.txt 11 Abstract 13 The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS 14 technology for use in transport network deployments. The work on 15 MPLS-TP has extended the MPLS technology with additional 16 architectural elements and functions that can be used in any MPLS 17 deployment. MPLS-TP is a set of functions and features selected from 18 the extended MPLS toolset and applied in a consistent way to meet the 19 needs and requirements of operators of packet transport networks. 21 During the process of development of the profile, additions to the 22 MPLS toolset have been made to ensure that the tools available met 23 the requirements. These additions were motivated by MPLS-TP, but 24 form part of the wider MPLS toolset such that any of them could be 25 used in any MPLS deployment. 27 One major set of additions provides enhanced support for Operations, 28 Administration, and Maintenance (OAM). This enables fault management 29 and performance monitoring to the level needed in a transport 30 network. Many solutions and protocol extensions have been proposed 31 to address the requirements for MPLS-TP OAM, and this document sets 32 out the reasons for selecting a single, coherent set of solutions for 33 standardization. 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on November 1, 2012. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 5 70 1.2. The Development of a Parallel MPLS-TP OAM Solution . . . . 6 71 2. Terminology and References . . . . . . . . . . . . . . . . . . 8 72 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 3. Motivations for a Single OAM Solution in MPLS-TP . . . . . . . 8 74 3.1. MPLS-TP is an MPLS Technology . . . . . . . . . . . . . . 8 75 3.2. MPLS-TP is a Convergence Technology . . . . . . . . . . . 9 76 3.3. There is an End-to-End Requirement for OAM . . . . . . . . 9 77 3.4. The Complexity Sausage . . . . . . . . . . . . . . . . . . 10 78 3.5. Interworking is Expensive and Has Deployment Issues . . . 10 79 3.6. Selection of a Single OAM Solution When There is a 80 Choice . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 3.7. Migration Issues . . . . . . . . . . . . . . . . . . . . . 14 82 4. Potential Models For Coexistence . . . . . . . . . . . . . . . 14 83 4.1. Protocol Incompatibility . . . . . . . . . . . . . . . . . 15 84 4.2. Inevitable Coexistence . . . . . . . . . . . . . . . . . . 15 85 4.3. Models for Coexistence . . . . . . . . . . . . . . . . . . 16 86 4.3.1. The Integrated Model . . . . . . . . . . . . . . . . . 16 87 4.3.2. Island Model . . . . . . . . . . . . . . . . . . . . . 18 88 5. The Argument For Two Solutions . . . . . . . . . . . . . . . . 19 89 5.1. Progress of the IETF Solution . . . . . . . . . . . . . . 20 90 5.2. Commonality with Ethernet OAM . . . . . . . . . . . . . . 20 91 5.3. Different Application Scenarios . . . . . . . . . . . . . 21 92 5.4. Interaction Between Solutions . . . . . . . . . . . . . . 22 93 5.5. Letting The Market Decide . . . . . . . . . . . . . . . . 22 94 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 96 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 24 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 98 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 99 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 100 Appendix A. Examples of Interworking Issues in the Internet . . 25 101 Appendix A.1. IS-IS/OSPF . . . . . . . . . . . . . . . . . . . . . 26 102 Appendix A.2. Time Division Multiplexing Pseudowires . . . . . . . 26 103 Appendix A.3. Codecs . . . . . . . . . . . . . . . . . . . . . . . 27 104 Appendix A.4. MPLS Signaling Protocols . . . . . . . . . . . . . . 28 105 Appendix A.5. IPv4 and IPv6 . . . . . . . . . . . . . . . . . . . 28 106 Appendix B. Other Examples of Interworking Issues . . . . . . . 29 107 Appendix B.1. SONET and SDH . . . . . . . . . . . . . . . . . . . 29 108 Appendix B.2. IEEE 802.16d and IEEE 802.16e . . . . . . . . . . . 30 109 Appendix B.3. CDMA and GSM . . . . . . . . . . . . . . . . . . . . 30 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 112 1. Introduction 114 The MPLS Transport Profile (MPLS-TP) is a profile of MPLS technology 115 for use in transport network deployments. Note that transport in 116 this document is used in the context of transport networks as 117 discussed in Section 1.3 of [RFC5654] and in [RFC5921]. The work on 118 MPLS-TP has extended the MPLS toolset with additional architectural 119 elements and functions that can be used in any MPLS deployment. 120 MPLS-TP is a set of functions and features selected from the extended 121 MPLS toolset and applied in a consistent way to meet the needs and 122 requirements of operators of packet transport networks. 124 Operations, Administration, and Maintenance (OAM) plays a significant 125 role in carrier networks, providing methods for fault management and 126 performance monitoring in both the transport and the service layers, 127 and enabling these layers to support services with guaranteed and 128 strict Service Level Agreements (SLAs) while reducing their 129 operational costs. 131 OAM provides a comprehensive set of capabilities that operate in the 132 data plane. Network-oriented mechanisms are used to monitor the 133 network's infrastructure in order to enhance the network's general 134 behavior and level of performance. Service-oriented mechanisms are 135 used to monitor the services offered to end customers. Such 136 mechanisms enable rapid response to a failure event and facilitate 137 the verification of some SLA parameters. Fault management mechanisms 138 are used for fault detection and localization as well as for 139 diagnostics and notification. Performance management mechanisms 140 enable monitoring of the quality of service with regard to key SLA 141 criteria (e.g., jitter, latency, and packet loss). 143 During the process of development of MPLS-TP, additions to the MPLS 144 toolset have been made to ensure that the tools available meet the 145 requirements. These additions were motivated by MPLS-TP, but form 146 part of the wider MPLS toolset such that any of them could be used in 147 any MPLS deployment. 149 One major set of additions provides enhanced support for OAM. Many 150 solutions and protocol extensions have been proposed to address these 151 OAM requirements. This document sets out the reasons for selecting a 152 single, coherent set of OAM solutions for standardization. 154 The content of this document should be read in the context of 155 [RFC1958]. In particular Section 3.2 that says: 157 If there are several ways of doing the same thing, choose one. 158 If a previous design, in the Internet context or elsewhere, has 159 successfully solved the same problem, choose the same solution 160 unless there is a good technical reason not to. Duplication of 161 the same protocol functionality should be avoided as far as 162 possible, without of course using this argument to reject 163 improvements. 165 1.1. Background 167 The ITU-T and IETF jointly commissioned a Joint Working Team (JWT) to 168 examine the feasibility of a collaborative solution to support OAM 169 requirements for MPLS transport networks (MPLS-TP). The JWT reported 170 that it is possible to extend the MPLS technology to fully satisfy 171 the requirements [RFC5317]. The investigation by the JWT laid the 172 foundations for the work to extend MPLS, but a thorough technical 173 analysis was subsequently carried out within the IETF with strong 174 input from the ITU-T to ensure that the MPLS-TP OAM requirements 175 provided by the ITU-T and IETF would be met. 177 The report of the JWT [RFC5317] as accepted by the ITU-T was 178 documented in [TD7] and was communicated to the IETF in a liaison 179 statement [LS26URL]. In particular, the ITU-T stated that any 180 extensions to MPLS technology will be progressed via the IETF 181 standards process using the procedures defined in [RFC4929]. 183 [RFC5317] includes the analysis that "it is technically feasible that 184 the existing MPLS architecture can be extended to meet the 185 requirements of a Transport profile, and that the architecture allows 186 for a single OAM technology for LSPs, PWs, and a deeply nested 187 network." This provided a starting point for the work on MPLS-TP. 189 [RFC5654] in general, and [RFC5860] in particular, define a set of 190 requirements for OAM functionality in MPLS-TP that are applicable to 191 MPLS-TP Label Switched Paths (LSPs), Pseudowires (PWs), and MPLS-TP 192 links. These documents are the results of a joint effort by the 193 ITU-T and the IETF to include an MPLS Transport Profile within the 194 IETF MPLS and PWE3 architectures to enable the deployment of a packet 195 transport network that supports the capabilities and functionalities 196 of a transport network as defined by the ITU-T. The OAM requirements 197 are derived from those specified by ITU-T in [Y.Sup4]. 199 An analysis of the technical options for OAM solutions was carried 200 out by a design team (the MEAD team) consisting of experts from both 201 the ITU-T and the IETF. The team reached an agreement on the 202 principles of the design and the direction for the development of an 203 MPLS-TP OAM toolset. A report was subsequently submitted to the IETF 204 MPLS Working Group at the Stockholm IETF meeting in July 2009 205 [DesignReportURL]. The guidelines drawn up by the design team have 206 played an important role in the creation of a coherent MPLS-TP OAM 207 solution. 209 The MPLS working group has modularized the function of MPLS-TP OAM 210 allowing for separate and prioritized development of solutions. This 211 has given rise to a number of documents each describing a different 212 part of the solution toolset. At the time of writing, the most 213 important of these documents have completed development within the 214 MPLS working group and are advancing through the IETF process towards 215 publication as RFCs. These documents cover the following OAM 216 features: 218 o Continuity Check 220 o Connection Verification 222 o On-demand Connection Verification 224 o Route Tracing 226 o Remote Defect Indication 228 o Packet Loss Measurement 230 o Packet Delay Measurement 232 o Lock Instruction 234 o Loopback Testing 236 o Fault Management 238 The standardization process within the IETF allows for the continued 239 analysis of whether the OAM solutions under development meet the 240 documented requirements, and facilitates the addition of new 241 requirements if any are discovered. It is not the purpose of this 242 document to analyze the correctness of the selection of specific OAM 243 solutions. This document is intended to explain why it would be 244 unwise to standardize multiple solutions for MPLS-TP OAM, and to show 245 how the existence of multiple solutions would complicate MPLS-TP 246 development and deployment, making networks more expensive to build, 247 less stable, and more costly to operate. 249 1.2. The Development of a Parallel MPLS-TP OAM Solution 251 It has been suggested that a second, different OAM solution should 252 also be developed and documented in an ITU-T Recommendation. Various 253 arguments have been presented for this duplication of effort, 254 including: 256 o Similarity to OAM encodings and mechanisms used in Ethernet. 258 o The existence of two distinct MPLS-TP deployment environments 259 called Packet Switched Network (PSN) and Packet Transport Network 260 (PTN). 262 o The need for similar operational experience in MPLS-TP networks 263 and in pre-existing transport networks (especially SONET/SDH 264 networks). 266 The first of these was discussed within the IETF's MPLS working group 267 where precedence was given to adherence to the JWT's recommendation 268 to select a solution that reused as far as possible pre-existing MPLS 269 tools. Additionally, it was decided that consistency with encodings 270 and mechanisms used in MPLS was of greater importance. 272 The second argument has not been examined in great detail because 273 substantive evidence of the existence of two deployment environments 274 has not been documented or presented. Indeed, one of the key 275 differences cited between the two allegedly distinct environments is 276 the choice of MPLS-TP OAM solution, which makes a circular argument. 278 The third argument contains a very important point: network operators 279 want to achieve a smooth migration from legacy technologies such as 280 SONET/SDH to their new packet transport networks. This transition 281 can be eased if the new networks offer similar OAM features and can 282 be managed using tools with similar look and feel. The requirements 283 specifications [RFC5654] and [RFC5860] specifications [RFC5654] and 284 [RFC5860] capture the essential issues that must be resolved to allow 285 the same look and feel to be achieved. Since the OAM solutions 286 developed within the IETF meet the documented requirements, Network 287 Management Systems (NMS) can easily be built to give the same type of 288 control of MPLS-TP networks as is seen in other transport networks. 289 Indeed, it should be understood that the construction of an NMS is 290 not dependent on the protocols and packet formats within the OAM, but 291 on the high-level features and functions offered by the OAM. 293 This document does not debate the technical merits of any specific 294 solution. That discussion, and the documentation of MPLS-TP OAM 295 specifications, was delegated by the IETF and ITU-T to the MPLS 296 working group and can be conducted using the normal consensus-driven 297 IETF process. [I-D.ietf-opsawg-oam-overview] presents an overview of 298 the OAM mechanisms that have already been defined and that are 299 currently being defined by the IETF, as well as a comparison with 300 other OAM mechanisms that were defined by the IEEE and ITU-T. 302 This document focuses on an examination of the consequences of the 303 existence of two MPLS-TP OAM solutions. 305 2. Terminology and References 307 2.1. Acronyms 309 This document uses the following acronyms: 311 ANSI American National Standards Institute 312 CESoPSN Circuit Emulation Service over Packet Switched Network 313 ETSI European Telecommunications Standards Institute 314 FPGA Field-Programmable Gate Array 315 GFP Generic Framing Procedure 316 IEEE Institute of Electrical and Electronics Engineers 317 ITU-T International Telecommunications Union - Telecommunication 318 Standardization Sector 319 JWT Joint Working Team 320 LSP Label Switched Path 321 MPLS-TP MPLS Transport Profile 322 NMS Network Management Systems 323 PDH Plesiochronous Digital Hierarchy 324 OAM Operations, Administration, and Maintenance 325 PSN Packet Switched Network 326 PTN Packet Transport Network 327 PW Pseudowire 328 PWE3 Pseudowire Emulation Edge to Edge 329 SAToP Structure-Agnostic Time Division Multiplexing over Packet 330 SDH Synchronous Digital Hierarchy 331 SLA Service Level Agreements 332 SONET Synchronous Optical Network 333 TDM Time Division Multiplexing 334 TDMoIP Time Division Multiplexing over IP 336 3. Motivations for a Single OAM Solution in MPLS-TP 338 This section presents a discussion of the implications of the 339 development and deployment of more than one MPLS OAM protocol. The 340 summary is that it can be seen that there are strong technical, 341 operational, and economic reasons to avoid the development and 342 deployment of anything other than a single MPLS OAM protocol. 344 3.1. MPLS-TP is an MPLS Technology 346 MPLS-TP is an MPLS technology. It is designed to apply MPLS to a new 347 application. The original proposers of the concept assumed that the 348 transport variant of MPLS would always exist in a disjoint network, 349 and indeed their first attempt at the technology (T-MPLS) had a 350 number of significant incompatibilities with MPLS that were 351 irreconcilable. When it was established that co-existence in the 352 same layer network could and would occur, T-MPLS development was 353 stopped and the development of MPLS-TP was begun. In MPLS-TP, MPLS 354 was extended to satisfy the transport network requirements in a way 355 that was compatible both with MPLS as has already been deployed, and 356 with MPLS as the IETF envisioned it would develop in the future. 358 Given this intention for compatibility, it follows that the MPLS-TP 359 OAM protocols should be designed according to the design philosophies 360 that were applied for the existing deployed MPLS OAM and that have 361 led to the current widespread adoption of MPLS. Key elements here 362 are scalability and hardware independence, i.e. that the tradeoff 363 between scaling to large numbers of monitored objects and the 364 performance of the monitoring system should be a matter for vendors 365 and operators to resolve, and that the tradeoff should be a soft 366 transition rather than a cliff. Furthermore there should be no 367 requirement to execute any component (other than packet forwarding) 368 in hardware to achieve usable performance. 370 3.2. MPLS-TP is a Convergence Technology 372 It is possible to argue that using MPLS for Transport is only a 373 stepping stone in the middle of a longer transition. Quite clearly 374 all communication applications are being moved to operate over the 375 Internet protocol stack of TCP/IP/MPLS, and the various layers that 376 have existed in communications networks are gradually being collapsed 377 into the minimum necessary set of layers. Thus, for example, we no 378 longer run IP over X.25 over HDLC over multi-layered Time Division 379 Multiplexing (TDM) networks. 381 Increasingly the entire point of transport networks is to support the 382 transmission of TCP/IP/MPLS. Using MPLS to construct a transport 383 network may be a relatively short-term stepping-stone toward running 384 IP and MPLS directly over fiber optics. MPLS has been deployed in 385 operational networks for approximately a decade, and the existing 386 MPLS OAM techniques have seen wide deployment. Service providers are 387 not going to stop using the MPLS based OAM techniques that they have 388 been using for years, and no one has proposed that they would. Thus, 389 the question is not which OAM to use for transport networks; the 390 question is whether service providers want to use two different sets 391 of OAM tools in the future converged network. If we arrive at a 392 destination where TCP/IP/MPLS runs directly over fiber, the operators 393 will use MPLS OAM tools to make this work. 395 3.3. There is an End-to-End Requirement for OAM 397 The purpose of OAM is usually to execute a function that operates 398 end-to-end on the monitored object (such as an LSP or PW). Since 399 LSPs and PWs provide edge-to-edge connectivity and can cross network 400 operator boundaries, the OAM must similarly operate across network 401 operator boundaries. This is particularly the case with the 402 continuity check and connection verification functions that are 403 needed to test the end-to-end connectivity of LSPs and PWs. It is, 404 therefore, necessary that any two equipments that could ever be a 405 part of an end-to-end communications path have a common OAM. This 406 necessity is emphasized in the case of equipment executing an edge 407 function, since with a global technology such as MPLS it could be 408 interconnected with an edge equipment deployed by any other operator 409 in any part of the global network. 411 This leads to the conclusion that it is desirable for any network 412 layer protocol in every equipment to be able to execute or to 413 interwork with a canonical form of the OAM. As we shall demonstrate, 414 interworking between protocols adds significant complexity, and thus 415 a single default OAM is strongly preferred. 417 3.4. The Complexity Sausage 419 A frequent driver for the replacement of an established technology is 420 a perception that the new technology is simpler, and thus of greater 421 economic benefit to the user. In an isolated system this may be the 422 case, however when, as is usually case with communications 423 technologies, simplification in one element of the system introduces 424 a (possibly non-linear) increase in complexity elsewhere. 426 This creates the "squashed sausage" effect, where reduction in 427 complexity at one place leads to significant increase in complexity 428 at a remote location. When we drive complexity out of hardware by 429 placing complexity in the control plane there is frequently an 430 economic benefit, as illustrated by MPLS itself. 432 Some motivation for the second OAM solution is the simplicity of 433 operation at a single node in conjunction with other transport OAM. 434 However, when we drive OAM complexity out of one network element at 435 the cost of increased complexity at a peer network element we loose 436 out economically and, more importantly, we lose out in terms of the 437 reliability of this important network functionality. Due to the need 438 to ensure compatibility of an interworking function between the two 439 MPLS-TP OAM solutions (in order to achieve end-to-end OAM) we create 440 a situation where neither of two disjoint protocol developments is 441 able to make technical advances. Such a restriction is unacceptable 442 within the context of the Internet. 444 3.5. Interworking is Expensive and Has Deployment Issues 446 The issue of OAM interworking can easily be illustrated by 447 considering an analogy with people speaking different languages. 449 Interworking is achieved through the use of an interpreter. The 450 interpreter introduces cost, slows down the rate of information 451 exchange, and may require transition through an intermediate 452 language. There is considerable risk of translation errors and 453 semantic ambiguities. These considerations also apply to computer 454 protocols, particularly given the ultra-pedantic nature of such 455 systems. In all cases, the availability of a single working language 456 dramatically simplifies the system, reduces cost, and speeds reliable 457 communication. 459 If two MPLS OAM protocols were to be deployed we would have to 460 consider three possible scenarios: 462 1. Isolation of the network into two incompatible and unconnected 463 islands. 465 2. Universal use of both OAM protocols. 467 3. Placement of interworking (translation) functions or gateways. 469 We have many existence proofs that isolation is not a viable 470 approach, and the reader is referred to the early T-MPLS discussions 471 for examples. In summary, the purpose of the Internet is to achieve 472 an integrated universal connectivity. Partition of the Internet into 473 incompatible and unconnected islands is neither desirable nor 474 acceptable. 476 Universal deployment of both OAM protocols requires the sum of the 477 costs associated with each protocol. This manifests as 478 implementation time, development cost, memory requirements, hardware 479 components, and management systems. It introduces additional testing 480 requirements to ensure there are no conflicts (processing state, 481 fault detection, code path, etc.) when both protocols are run on a 482 common platform. It also requires code and processes to deal with 483 the negotiation of which protocol to use and conflict resolution 484 (which may be remote and multi-party) when an inconsistent choice is 485 made. In short, this option results in worse than double costs, 486 increases the complexity of the resulting system, risks the stability 487 of the deployed network, and makes the networks more expensive and 488 more complicated to operate. 490 The third possibility is the use of some form of interworking 491 function. This is not a simple solution and inevitably leads to cost 492 and complexity in implementation, deployment, and operation. Where 493 there is a chain of communication (end-to-end messages passed through 494 a series of transit nodes) a choice must be made about where to apply 495 the translation and interworking. 497 o In a layered architecture, interworking can be achieved through 498 tunneling with the translation points at the end-points of the 499 tunnels. In simple network diagrams this can look very appealing 500 and only one end-node is required to be able to perform the 501 translation function (effectively speaking both OAM languages). 502 But in the more complex reality of the Internet, nearly every 503 network node performs the function of an end-node, and so the 504 result is that nearly every node must be implemented with the 505 capability to handle both OAM protocols and to translate between 506 them. This turns out be even more complex than the universal 507 deployment of both protocols discussed above. 509 o In a flat architecture, interworking is performed at a "gateway" 510 between islands implementing different protocols. Gateways are 511 substantially complex entities that usually have to maintain end- 512 to-end state within the network (something that is against one of 513 the fundamental design principles of the Internet) and must bridge 514 the differences in state machines, message formats, and 515 information elements in the two protocols. The complexity of 516 gateways make them expensive, fragile and unstable, hard to update 517 when new revisions of protocols are released, and difficult to 518 manage. 520 To deploy an interworking function it is necessary to determine 521 whether the OAM protocol on the arriving segment of the OAM is 522 identical to the OAM protocol on the departing segment. Where the 523 protocols are not the same, it is necessary to determine which party 524 will perform the translation. It is then necessary to route the LSP 525 or PW through a translation point that has both sufficient 526 translation capacity and sufficient data bandwidth and adequate path 527 diversity. When an upgraded OAM function is required, the problem 528 changes from a two party negotiation to an n-party negotiation with 529 commercial and deployment issues added to the mix. 531 Note that when an end-to-end LSP or PW is deployed, it may transit 532 many networks and the OAM might require repeated translation back and 533 forth between the OAM protocols. The consequent loss of information 534 and potential for error is similar to the children's game of Chinese 535 Whispers. 537 3.6. Selection of a Single OAM Solution When There is a Choice 539 When there is a choice of protocols for deployment or operation, a 540 network operator must make a choice. Choice can be a good thing when 541 it provides for selection between different features and functions, 542 but it is a burden when the protocols offer essentially the same 543 functions, but are incompatible. 545 In this case, the elements of the choice include: 547 o Which protocol will continue to be developed by its SDO? 549 o Which protocol is most stable in implementations? 551 o How to test and evaluate the two protocols? 553 o Which vendors support and will continue to support which protocol? 555 o What equipment from different vendors is compatible? 557 o Which management tools support which protocols? 559 o What protocols are supported by peer operators and what 560 interworking function is needed? 562 o Which protocols are engineers experienced with and trained in? 564 o What are the consequences of a wrong choice? 566 o Will it be possible to migrate from one protocol to another in the 567 future? 569 o How to integrate with other function already present in the 570 network? 572 o How to future-proof against the inclusion of new function in the 573 network? 575 At the very least, the evaluation of these questions constitute a 576 cost and introduce delay for the operator. The consequence of a 577 wrong choice could be very expensive, and it is likely that any 578 comparative testing will more than double the lab-test costs prior to 579 deployment. 581 From a vendor's perspective, the choice is even harder. A vendor 582 does not want to risk not offering a product for which there is 583 considerable demand, so both protocols may need to be developed 584 leading to more than doubled development costs. Indeed, code 585 complexity and defect rates have often been shown to increase worse 586 than linearly with code size, and (as noted in a previous section) 587 the need to test for co-existence and interaction between the 588 protocols adds to the cost and complexity. 590 It should be noted that, in the long-run, it is the end-users who pay 591 the price for the additional development costs and any network 592 instability that arises. 594 3.7. Migration Issues 596 Deployment of a technology that is subsequently replaced or obsoleted 597 often leads to the need to migrate from one technology to another. 598 Such a situation might arise if an operator deploys one of the two 599 OAM protocol solutions and discovers that it needs to move to use the 600 other one. A specific case would be when two operators merge their 601 networks, but are using different OAM solutions. 603 When the migration is between versions of a protocol, it may be that 604 the new version is defined to support the old version. If the 605 implementation is in software (including FPGAs), upgrades can be 606 managed centrally. However, neither of these would be the case with 607 MPLS-TP OAM mechanisms, and hardware components would need to be 608 upgraded in the field using expensive call-out services. 610 Hardware upgrades are likely to be service-affecting even with 611 sophisticated devices with redundant hardware components. 612 Furthermore, since it would be impractical to upgrade every device in 613 the network at the same time, there is a need for either a 614 significantly large maintenance period across the whole network or 615 for a rolling plan that involves upgrading nodes one at a time with 616 new hardware that has dual capabilities. Such hardware is, of 617 course, more expensive and more complex to configure than hardware 618 dedicated to just one OAM protocol. 620 Additionally, the transition phase of migration leads to dual mode 621 networks as described in Section 4.3. Such networks are not 622 desirable because of their cost and complexity. 624 In short, the potential for future migration will need to be part of 625 the deployment planning exercise when there are two OAM protocols to 626 choose between. This issue will put pressure on making the "right" 627 choice when performing the selection described in Section 3.6. 629 4. Potential Models For Coexistence 631 This section expands upon the discussion in Section 3 by examining 632 three questions: 634 o What does it mean for two protocols to be incompatible? 636 o Why can't we assume that the two solutions will never coexist in 637 the same network? 639 o What models could we support for coexistence? 641 4.1. Protocol Incompatibility 643 Protocol incompatibility comes in a range of grades of seriousness. 644 At the most extreme, the operation of one protocol will prevent the 645 safe and normal operation of the other protocol. This was the case 646 with the original T-MPLS where MPLS labels that could be used for 647 data in a native MPLS system were assigned special meaning in T-MPLS 648 such that data packets would be intercepted and mistaken for OAM 649 packets. 651 A lesser incompatibility arises where the packets of one protocol are 652 recognized as "unknown" or "not valid" by implementations of the 653 other protocol. In this case the rules of one protocol require the 654 packets of the other protocol to be discarded and may result in the 655 LSP or PW being torn down. 657 The least level of incompatibility is where the packets of one 658 protocol are recognized as "unknown" by implementations of the other 659 protocol. In this case the protocols rules of one protocol allow the 660 packets of the other protocol to be ignored, and they are either 661 silently discarded or forwarded untouched. 663 These are issues with all of these grades of incompatibility ranging 664 from disruption or corruption of user data, through connection 665 failure, to the inability to provide end-to-end OAM function without 666 careful planning and translation functions. 668 4.2. Inevitable Coexistence 670 Networks expand and merge. For example, one service provider may 671 acquire another and wish to merge the operation of the two networks. 672 This makes partitioning networks by protocol deployment a significant 673 issue for future-proofing commercial interactions. Although a 674 network operator may wish to present difficulties to disincentivize 675 hostile take-over (a poison pill) most operators are interested in 676 future options to grow their networks. 678 As described in Section 3.2, MPLS is a convergence technology. That 679 means that there is a tendency for an ever-increasing number of 680 services to be supported by MPLS, and for MPLS to be deployed in an 681 increasing number of environments. It would be an unwise operator 682 who deployed a high-function convergence technology in such a way 683 that the network could never be expanded to offer new services or to 684 integrate with other networks or technologies. 686 As described in Section 3.3, there is a requirement for end-to-end 687 OAM. That means that where LSPs and PWs span multiple networks, 688 there is a need for OAM to span multiple networks. 690 All of this means that, if two different OAM protocol technologies 691 are deployed, there will inevitably come a time when some form of 692 coexistence is required, no matter how carefully the separation is 693 initially planned. 695 4.3. Models for Coexistence 697 Two models for co-existence can be considered: 699 1. An integrated model based on the "ships-in-the-night" approach. 700 In this model, there is no protocol translation or mapping. This 701 model can be decomposed as: 703 * Non-integrated mixed network where some nodes support just one 704 protocol, some support just the other, and no node supports 705 both protocols. 707 * Partial integration where some nodes support just one 708 protocol, some support just the other, and some support both 709 protocols. 711 * Fully-integrated dual mode where all nodes support both 712 protocols. 714 2. An "island" model where groups of similar nodes are deployed 715 together. In this model there may be translation or mapping, but 716 it is not always required. This model can be further decomposed: 718 * "Islands in a sea" where connectivity between islands of the 719 same type is achieved across a sea of a different type. 721 * "Border crossings" where connectivity between different 722 islands is achieved at the borders between them. 724 4.3.1. The Integrated Model 726 The integrated model assumes that nodes of different capabilities 727 coexist within a single network. Dual-mode nodes supporting both OAM 728 solutions may coexist in the same network. Interworking is not 729 required in this model, and no nodes are capable of performing 730 translation or gateway function (see Section 4.3.2 for operational 731 modes including translation and gateways). 733 In this model, protocol messages pass "as ships in the night" unaware 734 of each other, and without perturbing each other. 736 As noted above, there are several sub-models. 738 4.3.1.1. Mixed Network Without Integration 740 In a mixed network with no integration some nodes support one 741 protocol and other nodes support the other protocol. There are no 742 nodes that have dual capabilities. 744 All nodes on the path of an LSP or PW that are required to play an 745 active part in OAM must support the same OAM protocol. Nodes that do 746 not support the OAM protocol will silently ignore (and possibly 747 discard) OAM packets from the other protocol, and cannot form part of 748 the OAM function for the LSP or PW. 750 In order to provision an end-to-end connection that benefits from the 751 full OAM functionality, the planning and path-computation tool must 752 know the capabilities of each network node, and must select a path 753 that includes only nodes of the same OAM protocol capability. This 754 can result in considerably suboptimal paths, and may lead to the 755 network being partitioned. In the most obvious case, connectivity 756 can only be achieved between end-points of the same OAM capability. 757 This leads to considerable operational complexity and expense, as 758 well as the inability to provide a fully-flexible mesh of services. 760 In the event of dynamic network changes (such as fast reroute) or if 761 misconnectivity occurs, nodes of mismatched OAM capabilities may 762 become interconnected. This will disrupt traffic delivery because 763 end-to-end continuity checks may be disrupted, and it may be hard or 764 impossible to diagnose the problem because connectivity verification 765 and route trace functions will not work properly. 767 4.3.1.2. Partial Integration 769 In a partially integrated network, the network in Section 4.3.1.1 is 770 enhanced by the addition of a number of nodes with dual capabilities. 771 These nodes do not possess gateway or translation capabilities (this 772 is covered in Section 4.3.2), but each such node can act as a transit 773 point or end-node for an LSP or PW that uses either OAM protocol. 775 Complexity of network operation is not eased, but there is greater 776 connectivity potential in the network. 778 4.3.1.3. Dual Mode 780 Dual mode is a development of partial integration described in 781 Section 4.3.1.2 such that all nodes in the network are capable of 782 both OAM protocols. As in that Section, these nodes do not possess 783 gateway or translation capabilities (this is covered in Section 784 4.3.2), but each such node can act as a transit point or end-node for 785 an LSP or PW that uses either OAM protocol. Thus, every LSP or PW in 786 the network can be configured to use either of the OAM protocols. 788 However, it seems unlikely that an operator would choose which OAM 789 protocol to use on a per LSP or per PW basis. That would lead to 790 additional complexity in the management system and potential 791 confusion if additional diagnostic analytics need to be performed. 792 This mode increases the complexity of implementation, deployment, and 793 operation without adding to the function within the network (since 794 both OAM solutions provide the same level of function), so this mode 795 would not be selected for deployment except, perhaps, during 796 migration of the network from one OAM protocol to the other. 798 4.3.2. Island Model 800 In the island model, regions or clusters of nodes with the same OAM 801 capabilities are grouped together. Tools to interconnect the 802 technologies are deployed based on layered networking or on 803 interworking between the protocols. These lead to the two sub-models 804 described in the sections that follow. 806 4.3.2.1. Islands in a Sea 808 One way to view clusters of nodes supporting one OAM protocol is as 809 an island in a sea of nodes supporting the other protocol. In this 810 view, tunnels are used to carry LSPs or PWs using one OAM type across 811 the sea and into another island of a compatible OAM type. The tunnel 812 in this case is an LSP utilizing the OAM protocol supported by the 813 nodes in the sea. Theoretically an island can be as small as one 814 node, and the strait between two islands can be as narrow as just one 815 node. 817 Layering in this way is an elegant solution to operating two 818 protocols simultaneously and is, of course, used to support different 819 technologies (such as MPLS over optical). However, in such layering 820 deployments there is no simple integration of OAM between the layers, 821 and the OAM in the upper layer must regard the tunnel as a single hop 822 with no visibility into the OAM of the lower layer. Diagnostics 823 within the upper layer are complicated by this "hiding" of the nodes 824 along the path of the tunnel in the lower layer. 826 In the scenarios described so far, both ends of each connection have 827 been placed in islands of compatible OAM types. It is possible to 828 achieve connectivity between a node in an island and a node in the 829 sea if the end-point in the sea has dual capabilities (i.e., can be 830 viewed as a single-node island). 832 A number of islands may lie along the path between end-points 833 necessitating the use of more than one tunnel. To further complicate 834 matters, the islands may lie in an inland sea so that it is necessary 835 to nest tunnels. 837 Regardless of the scenario, operating tunnels/layers adds to the 838 management complexity and expense. Furthermore, it should be noted 839 that in an MPLS network there is often a call for any-to-any 840 connectivity. That is, any node in the network may need to establish 841 an LSP or a PW to any other node in the network. As previously 842 noted, the end-points of any LSP or PW must support the same OAM type 843 in the islands-in-a-sea model, so this tends to imply that all, or 844 nearly all, nodes will end up needing to support both OAM protocols. 846 The use of tunnels can also degrade network services unless carefully 847 coordinated. For example, a service in the upper layer may be 848 provisioned with protection so that a working and backup path is 849 constructed using diverse paths to make them robust against a single 850 failure. However, the paths of the tunnels (in the lower layer) are 851 not visible to the path computation in the upper layer with the risk 852 that the upper layer working and protection paths share a single 853 point of failure in the lower layer. Traffic engineering techniques 854 have been developed to resolve this type of issue, but they add 855 significant complexity to a system that would be a simple flat 856 network if only one OAM technology was used. 858 4.3.2.2. Border Crossings 860 Instead of connecting islands with tunnels across the sea, islands of 861 different types can be connected direct so that the LSP or PW 862 transits the series of islands without tunneling. In this case 863 protocol translation is performed each time the LSP/PW crosses a 864 border between islands that use a different OAM protocol. 866 In principle this makes for a straight-forward end-to-end connection. 867 However, protocol translation presents a number of issues as 868 described in Section 3. The complexity is that in planning the end- 869 to-end connection, gateways with protocol translation capabilities 870 must be selected to lie on the path. 872 5. The Argument For Two Solutions 874 The decision to define and develop an alternative MPLS-TP OAM 875 solution was based on several assertions: 877 o The IETF solution is taking too long to standardize 879 o Commonality with Ethernet solutions is beneficial 880 o There are two different application scenarios 882 o There is no risk of interaction between the solutions 884 o The market should be allowed to decide between competing 885 solutions. 887 The following sections look briefly at each of these claims. 889 5.1. Progress of the IETF Solution 891 The MPLS-TP OAM work carried out within the IETF is the product of 892 joint work within the IETF and ITU-T communities. That is, all 893 interested parties share the responsibility for progressing this work 894 as fast as possible. Since the work is contribution-driven, there is 895 no reason to assume that consensus on the technical content of the 896 work could be reached any faster. 898 Opening discussions on a second solution seems certain to increase 899 the work-load, and will only slow down the speed at which consensus 900 is reached. 902 The core work on MPLS-TP OAM within the IETF completed and the 903 specifications were published as RFCs. For more information, see 904 [ISOCAccounceURL]. 906 5.2. Commonality with Ethernet OAM 908 Ethernet can be used to build packet transport networks and so there 909 is an argument that Ethernet and MPLS-TP networks will be operated as 910 peers. Examining the issues of end-to-end connections across mixed 911 networks, many of the same issues as discussed in Section 4 arise. 912 If a peer networking gateway model (see Section 4.3.2.2) is applied 913 there is a strong argument to making the OAM technologies as similar 914 as possible. 916 While this might be a valid discussion point when selecting the 917 single OAM solution for MPLS-TP, it is countered by the need to 918 achieve OAM consistency between MPLS and MPLS-TP networks. One might 919 make the counter argument that if there is a strong need to make 920 MPLS-TP as similar as possible to Ethernet, it would be better to go 921 the full distance and simply deploy Ethernet. 923 Furthermore, the approach of a second MPLS-TP OAM protocol does not 924 resolve anything. Since MPLS-TP is not Ethernet, a gateway will 925 still be needed, and this would constitute a second MPLS-TP OAM so 926 additional gateways or interworking functions will be needed because 927 coexistence is inevitable as described in the rest of this document. 929 Additionally, it may be claimed that implementation can be simplified 930 if the OAM solution developed for MPLS-TP is similar to Ethernet OAM. 931 This would apply both in the hardware/software implementing the OAM, 932 and at the server-to-client interface where OAM-induced fault status 933 is reported. The questions here are very much implementation- 934 dependent and are the necessary function is contained within 935 individual nodes. The counter argument is that implementation 936 simplicity can also be achieved by making MPLS-TP OAM similar to MPLS 937 OAM especially since the client technology may well be IP/MPLS and 938 since MPLS is an end-to-end technology. 940 5.3. Different Application Scenarios 942 It has been suggested that two different applications of MPLS-TP 943 exist: Packet Switched Network (PSN) and Packet Transport Network 944 (PTN). These applications have not been documented in the IETF and 945 most of the support for the idea has come in discussions with a 946 documentationin the ITU-T [TD522]. 948 One of the stated differences between these applications lies in the 949 OAM tools that are required to support the distinct operational 950 scenarios. The OAM used in a PSN should be similar to that used in 951 an MPLS network (and so should be the MPLS-TP OAM defined in the 952 IETF) while the OAM used in a PTN should provide the same operational 953 experience to that found in SONET/SDH and OTN networks. 955 The basic MPLS-TP OAM requirements in [RFC5654] make this point, 956 saying: 958 Furthermore, for carriers it is important that operation of 959 such packet transport networks should preserve the look-and- 960 feel to which carriers have become accustomed in deploying 961 their optical transport networks, while providing common, 962 multi-layer operations, resiliency, control, and multi- 963 technology management. 965 Thus, the look-and-feel of the OAM has been a concern in the design 966 of MPLS-TP from the start, and the solutions that have been defined 967 in the IETF were designed to comply with the requirements and to 968 provide operational behavior, functionality and processes similar to 969 those available in existing transport networks. In particular, the 970 toolset supports the same controls and indications as those present 971 in other transport networks, and the same management information 972 model can be used to support the MPLS-TP OAM tools (in areas where 973 the technology type is irrelevant). 975 It is important to note that the operational look-and-feel does not 976 determine the way in which OAM function is achieved. There are 977 multiple ways of achieving the required functionality while still 978 providing the same operational experience and supporting the same 979 management information model. Thus, the OAM protocol solution does 980 not dictate the look-and-feel, and the demand for a particular 981 operational experience does not necessitate the development of a 982 second OAM protocol. 984 5.4. Interaction Between Solutions 986 Section 3 of this document discusses how network convergence occurs 987 and indicates that where two MPLS-TP solutions exist they are, in 988 fact, very likely to appear either in the same network or at gateways 989 between networks in order to provide an end-to-end OAM functionality. 991 Indeed, since nodes offering either solution are likely to both be 992 branded as "MPLS-TP", and since network interoperation (as described 993 in Section 4) demands the existence of some nodes that are either 994 dual-mode or act as protocol translators/gateways, there is 995 considerable likelihood of the two OAM solutions interacting through 996 design or through accident. When a node is capable of supporting 997 both OAM protocols, it must be configured to support the correct 998 protocol for each interface and LSP/PW. When a device has interfaces 999 that offer different MPLS-TP OAM function, the risk of 1000 misconfiguration is significant. When a device is intended to 1001 support end-to-end connections, it may need to translate, map, or 1002 tunnel to accommodate both protocols. 1004 Thus, the very existence of two OAM protocols within the common 1005 MPLS-TP family makes copresence and integration most likely. 1007 5.5. Letting The Market Decide 1009 When two technologies compete it is common to let the market decide 1010 which one will survive. Sometimes the resolution is quite fast, and 1011 one technology dominates the other before there is widespread 1012 deployment. Sometimes it takes considerable time before one 1013 technology overcomes the other, perhaps because one technology has 1014 become entrenched before the emergence of the other, as in the case 1015 of MPLS replacing ATM. In more cases, however, the market does not 1016 select in favor of one technology or the other - as in many of the 1017 cases described in Sections 4 and 5 of this document, sometimes both 1018 technologies continue to live in the network. 1020 Letting the market decide is not a cheap option. Even when the 1021 resolution is rapid, equipment vendors and early adopters pay the 1022 price of both technologies. When it takes longer to determine which 1023 technology is correct there will be a period of coexistence followed 1024 by the need to transition equipment from the losing solution to the 1025 winning one. In the cases where no choice is made, the network is 1026 permanently complicated by the existence of the competing 1027 technologies. 1029 In fact, the only time when allowing the market to decide can be 1030 easily supported is when the competing technologies do not overlap. 1031 In those cases, for example different applications in the user-space, 1032 the core network is not perturbed by the decision-making process and 1033 transition from one technology to the other is relatively painless. 1034 This is not the case for MPLS-TP OAM, and coexistence while the 1035 market determines the correct approach would be expensive, while the 1036 necessary transition after the decision has been made would be 1037 difficult and costly. 1039 6. Security Considerations 1041 This informational document does not introduce any security issues. 1043 However, it should be noted that the existence of two OAM protocols 1044 raise a number of security concerns: 1046 o Each OAM protocol must be secured. This leads to the existence of 1047 two security solutions each needing configuration and management. 1048 The increased complexity of operating security mechanisms tends to 1049 reduce the likelihood of them being used in the field and so 1050 increases the vulnerability of the network. Similarly, the 1051 existence of two security mechanisms raises the risk of 1052 misconfiguration. 1054 o One OAM protocol may be used as a vector to attack the other. 1055 Inserting an OAM message of the other OAM protocol onto a link may 1056 cause the service to be disrupted and, because some nodes may 1057 support both OAM protocols, it may be possible to cause the 1058 disruption at a remote point in the network. 1060 o Securing a network protocol is not a trivial matter for protocol 1061 designers. Duplicating design effort is unlikely to result in a 1062 stronger solution and runs the risk of diluting the effort and 1063 creating two less-secure solutions. 1065 7. IANA Considerations 1067 This informational document makes no requests for IANA action. 1069 8. Acknowledgment 1071 Thanks to Brian Carpenter, Tom Petch, Rolf Winter, Alexander 1072 Vainshtein, Ross Callon, Malcolm Betts, Martin Vigoureux, for their 1073 review and useful comments. 1075 Thanks to Huub van Helvoort for supplying text and history about 1076 SONET/SDH. 1078 9. References 1080 9.1. Normative References 1082 [RFC5654] Niven-Jenkins, B., Brungard, D., Betts, M., Sprecher, N., 1083 and S. Ueno, "Requirements of an MPLS Transport Profile", 1084 RFC 5654, September 2009. 1086 [RFC5860] Vigoureux, M., Ward, D., and M. Betts, "Requirements for 1087 Operations, Administration, and Maintenance (OAM) in MPLS 1088 Transport Networks", RFC 5860, May 2010. 1090 9.2. Informative References 1092 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 1093 RFC 1958, June 1996. 1095 [RFC4553] Vainshtein, A. and YJ. Stein, "Structure-Agnostic Time 1096 Division Multiplexing (TDM) over Packet (SAToP)", 1097 RFC 4553, June 2006. 1099 [RFC4929] Andersson, L. and A. Farrel, "Change Process for 1100 Multiprotocol Label Switching (MPLS) and Generalized MPLS 1101 (GMPLS) Protocols and Procedures", BCP 129, RFC 4929, 1102 June 2007. 1104 [RFC5086] Vainshtein, A., Sasson, I., Metz, E., Frost, T., and P. 1105 Pate, "Structure-Aware Time Division Multiplexed (TDM) 1106 Circuit Emulation Service over Packet Switched Network 1107 (CESoPSN)", RFC 5086, December 2007. 1109 [RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, 1110 "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, 1111 December 2007. 1113 [RFC5317] Bryant, S. and L. Andersson, "Joint Working Team (JWT) 1114 Report on MPLS Architectural Considerations for a 1115 Transport Profile", RFC 5317, February 2009. 1117 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 1118 Berger, "A Framework for MPLS in Transport Networks", 1119 RFC 5921, July 2010. 1121 [I-D.ietf-opsawg-oam-overview] 1122 Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. 1123 Weingarten, "An Overview of Operations, Administration, 1124 and Maintenance (OAM) Mechanisms", 1125 draft-ietf-opsawg-oam-overview-06 (work in progress), 1126 March 2012. 1128 [Y.Sup4] "ITU-T Y.1300-series: Supplement on transport 1129 requirements for T-MPLS OAM and considerations for the 1130 application of IETF MPLS technology", 2008. 1132 [G.707] "ITU-T G.709: Network node interface for the synchronous 1133 digital hierarchy (SDH)", January 2007. 1135 [TD7] "TD7 (WP3/SG15): IETF and ITU-T cooperation on extensions 1136 to MPLS for transport network functionality", 1137 December 2008. 1139 [TD522] "TD522 (WP3/SG15): Clarification of the PTN/solution X 1140 environment", February 2011. 1142 [LS26URL] "LS: Cooperation Between IETF and ITU-T on the Development 1143 of MPLS-TP", December 2008, . 1146 [DesignReportURL] 1147 "IETF 75 Proceedings, MPLS-TP OAM Analysis", July 2009, . 1151 [ISOCAccounceURL] 1152 "Milestone Achieved in Internet Carrier Network Standards 1153 - Multiprotocol Label Switching Transport Profile 1154 (MPLS-TP) Specifications Published", December 2011, 1155 . 1157 Appendix A. Examples of Interworking Issues in the Internet 1159 It is, of course, right to observe that there are a number of 1160 instances of multiple protocols serving the same purpose that have 1161 arisen within the Internet. It is valuable to examine these examples 1162 to understand what issues they have caused and how they have been 1163 mitigated. 1165 Appendix A.1. IS-IS/OSPF 1167 IS-IS and OSPF are two competing link state IGP routing protocols 1168 that derive from the same root technology and which, for political 1169 and personality reasons, were never reconciled prior to wide-scale 1170 deployment. It is an accident of history that one of these protocols 1171 did not gain overwhelming deployment and so force the other into 1172 retirement. 1174 The existence of these two widely deployed and highly functional 1175 competing IGPs doubles the cost of link state IGP maintenance and 1176 deployment in the Internet. This is a situation that will almost 1177 certainly continue for the lifetime of the Internet. Although the 1178 Internet is clearly successful and operates well, the existence of 1179 these two IGPs forces router vendors to implement both protocols 1180 (doubling the protocol cost of all routers even when an operator only 1181 wants to deploy one of the protocols), forcing an operator to make an 1182 active choice between IGPs during deployment, and requiring a gateway 1183 function between the islands of protocol use. 1185 A mitigating factor in this specific case is that, owing to the way 1186 networks are partitioned for administrative and scaling reasons, 1187 there already existed a gateway routing protocol called BGP that 1188 propagates a summarized form of the IGP reachability information 1189 through-out the Internet. BGP means that there is actually no 1190 requirement for IS-IS and OSPF to interwork directly: that is, there 1191 is no need for a translation function between OSPF and IS-IS, and the 1192 two IGPs can continue to exist without impacting the function of the 1193 Internet. Thus, unlike the situation with MPLS OAM, the choice of 1194 IGP protocol is truly a local decision, however, there is a cost to 1195 BGP implementations that must support interactions with both OSPF and 1196 IS-IS. 1198 Appendix A.2. Time Division Multiplexing Pseudowires 1200 The IETF's PWE3 working group has published the specification of 1201 three different TDM PW types. This happened after considerable 1202 effort to reach a compromise failed to reduce the set of options. 1204 o SAToP is a relatively simple design. It is a Proposed Standard 1205 RFC [RFC4553] and is the mandatory to implement, default, mode of 1206 operation. 1208 o CESoPSN [RFC5086] and TDMoIP [RFC5087] are more complex approaches 1209 with different degrees of bandwidth efficiency optimized for 1210 different applications. They are both published as Informational 1211 RFCs. 1213 In this case all implementations must include the default mode of 1214 operation (SAToP). This means that end-to-end operation is 1215 guaranteed: an operator can select equipment from any vendor in the 1216 knowledge that they will be able to build and operate an end-to-end 1217 TDM PW service. 1219 If an operator wishes to deploy a TDM PW optimized for a specific 1220 application they may select equipment from a vendor offering CESoPSN 1221 or TDMoIP in addition to SAToP. Provided that all of their equipment 1222 and their management system can handle the optimized approach, they 1223 can run this in their network, but the operator has to carry the cost 1224 of selecting, purchasing, configuring, and operating the extended 1225 mode of operation. 1227 This situation is far from ideal, and it is possible that long- 1228 distance, multi-operator optimized TDM PWs cannot be achieved. 1229 However, the existence of a default mode implemented in all devices 1230 helps to reduce pain for the operator and ensures that simpler end- 1231 to-end operation is always available. Additionally, the growth of 1232 other protocols is acting to diminish the use of long distance TDM 1233 circuits making this a self limiting problem. 1235 Appendix A.3. Codecs 1237 The n-squared codec interworking problem was brought to the attention 1238 of the IETF by the ITU-T when the IETF started its work on a royalty- 1239 free codec suitable for use in the Internet. Every time a new codec 1240 is deployed, translation between it and all other deployed codecs 1241 must be available within the network, each participating node must be 1242 able to handle the new codec. Translation between codecs is 1243 expensive and can lead to reduced quality. 1245 This problem seriously constrains the addition of new codecs to the 1246 available set, and new codecs are only designed and released when 1247 there is a well established need (such as a major difference in 1248 functionality). 1250 The application layer of the Internet is, however, predicated on a 1251 business model that allows for the use of shared, free, and open- 1252 source software; this model requires the existence of a royalty-free 1253 codec. This, together with the specific characteristics of 1254 transmission over lossy packet networks, comprised requirements 1255 equivalent to a major difference in functionality, and led to work in 1256 the IETF to specify a new codec. 1258 The complexity, economic, and quality costs associated with 1259 interworking with this new codec will need to be factored into the 1260 deployment model. This, in turn, may adversely effect its adoption 1261 and the viably of its use in the Internet. 1263 Appendix A.4. MPLS Signaling Protocols 1265 There are three MPLS signaling control protocols used for 1266 distributing labels to set up LSPs and PWs in MPLS networks: LDP, 1267 RSVP-TE, and GMPLS. 1269 The application domain for each of these is different, and unlike the 1270 OAM situation, there is limited requirement for interworking between 1271 the protocols. For example, although one provider may use LDP to set 1272 up LSPs while its peer uses RSVP-TE, connectivity between the two 1273 providers usually takes place at the IP layer. 1275 It should be noted that the IETF initially worked on another 1276 signaling protocol called CR-LDP with variants applicable to MPLS and 1277 to GMPLS. The development of this protocol was allowed to progress 1278 in parallel with RSVP-TE. However, once it was possible to determine 1279 that the solution preferred by the community of vendors and operators 1280 was RSVP-TE, the IETF terminated all further work on CR-LDP. No 1281 translation function or gateway point interfacing RSVP-TE to CR-LDP 1282 was ever proposed. 1284 Appendix A.5. IPv4 and IPv6 1286 If there were ever an example of why protocol interworking is to be 1287 avoided if at all possible, it is the transition from IPv4 to IPv6. 1289 The reasons for introducing IPv6 into the Internet are well rehearsed 1290 and don't need discussion here. IPv6 was not introduced as a 1291 competitor to IPv4, but rather as a planned replacement. The need 1292 for the transition to IPv6 arises from the expansion of the network 1293 size beyond the wildest dreams of the creators of the Internet, and 1294 the consequent depletion of the IPv4 address space. 1296 This transition has proved to be the hardest problem that the IETF 1297 has ever addressed. The invention and standardization of IPv6 was 1298 straight-forward by comparison, but it has been exceptionally 1299 difficult to migrate networks from one established protocol to a new 1300 protocol. 1302 The early assumption that by the time the IPv4 address space was 1303 exhausted IPv6 would be universally deployed failed to materialize 1304 due to (understandable) short-term economic constraints. Early 1305 migration would have been simpler and less costly than the current 1306 plans. The Internet is now faced with the considerable complexity of 1307 implementing and deploying interworking functions. 1309 If anything can be learned from the IPv4/IPv6 experience it is that 1310 every effort should be applied to avoid the need to migrate or 1311 jointly operate two protocols within one network. Adding to the mix 1312 a number of issues caused by OAM interworking of MPLS, one of the 1313 Internet's core protocols, would be most unwelcome and would 1314 complicate matters still further. 1316 Appendix B. Other Examples of Interworking Issues 1318 Appendix B.1. SONET and SDH 1320 SONET and SDH were defined as competing standards that basically 1321 provided the same functionality (simultaneous transport of multiple 1322 circuits of differing origin within a single framing protocol). 1323 SONET was developed first by ANSI based on the 24 channel PDH 1324 hierarchy existing in North America and Japan. The basic rate based 1325 on DS3. Some time later ETSI developed SDH based on the 30 channnel 1326 PDH deployed in Europe. The basic rate based on E4 (3x DS3). 1328 SONET was adopted in the U.S., Canada, and Japan, and SDH in the rest 1329 of the world. 1331 Significant confusion resulted from this situation. Equipment 1332 manufacturers initially needed to select the market segment they 1333 intended to address. The cost of chipsets for a limited market 1334 increased and only a limited number of equipment manufactures were 1335 available for selection in each market. 1337 Obviously, most equipment vendors wanted to sell their equipment in 1338 both regions. Hence, today most chips support both SONET and SDH, 1339 and the selection is a matter of provisioning. The impact of the 1340 additional function to support both markets has had a mixed impact on 1341 cost. It has enabled a higher volume of production which reduced 1342 cost, but it has required increased development and complexity which 1343 increased cost. 1345 Because the regions or applicability of SONET and SDH are well known, 1346 service providers do not need to consider the merits of the two 1347 standards and their long-term role in the industry when examining 1348 their investment options. 1350 To be able to deploy SONET and SDH worldwide the regional SDO experts 1351 came together in ITU-T to define a frame structure and a frame-rate 1352 that would allow interconnection of SONET and SDH. A compromise was 1353 agreed and approved in an ITU-T meeting in Seoul in 1988. 1355 The SDH standard supports both the North American and Japanese 24 1356 channel/T1/T3 hierarchy and the European 30 channel/E1/E4 based 1357 hierarchy within a single multiplexing structure. SDH has no options 1358 for payloads at VC-4 (150Mb/s) and above. This has provided the 1359 basis for common solutions for packet based clients (GFP). SDH 1360 allows T1/T3 services to be delivered in Europe and E1 services to be 1361 delivered in North America using a common infra structure. 1363 Deployment of a E1 only standard in North America would have required 1364 the conversion of all of the 24 channel/T1 deployed equipment and 1365 services into the 30 channel/E1 format. Similarly deployment of a T1 1366 only standard in Europe would have required the conversion of all of 1367 the 30 channel/E1 equipment and services into 24 channel/T1 format. 1368 Clearly given the existing network deployments (in 1988) this was not 1369 a practical proposition. 1371 The result of the compromise is documented in ITU-T recommendation 1372 [G.707] which includes the frame definition and frame-rates, and 1373 documents how SONET and SDH can interconnect. 1375 A massive interworking function had to be implemented in order to 1376 provide global connectivity (e.g., through U.S. and Europe) and this 1377 resulted in an increase in operational overhead. The interworking 1378 function has to be performed before the SDH-based segment is reached. 1379 The reason for placing the interworking function on the SONET side 1380 was that in a previous agreement on interconnection the functionality 1381 was placed on the European side. 1383 Appendix B.2. IEEE 802.16d and IEEE 802.16e 1385 IEEE 802.16d and IEEE 802.16e were two different, incompatible 1386 iterations of the WiMAX standards. In addition to the issues 1387 described for SONET/SDH, developers who implemented IEEE 802.16d 1388 found that they could not re-use their equipment design when 1389 developing the IEEE 802.16e variant. This increased the cost of 1390 development and lengthened the time to market. 1392 Appendix B.3. CDMA and GSM 1394 CDMA and GSM are two competing technologies for mobile connectivity. 1396 In addition to all the undesirable effects described above, the 1397 existence of these two technologies adversely affected customers who 1398 used roaming when overseas. Sometimes, customers were obliged to 1399 obtain an additional device from their service providers in order to 1400 roam when travelling abroad (for example, when travelling from Europe 1401 to the U.S). 1403 Authors' Addresses 1405 Nurit Sprecher 1406 Nokia Siemens Networks 1407 3 Hanagar St. Neve Ne'eman B 1408 Hod Hasharon, 45241 1409 Israel 1411 Email: nurit.sprecher@nsn.com 1413 Kyung-Yeop Hong 1414 Cisco Systems 1415 300 Beaver Brook Road 1416 Boxborough, Massachusetts 01719 1417 USA 1419 Email: hongk@cisco.com