idnits 2.17.1 draft-ietf-opsawg-oam-overview-07.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 -- The document date (September 12, 2012) is 4238 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ITU-T-Y.1711' is mentioned on line 328, but not defined == Missing Reference: 'ITU-T-Y.1731' is mentioned on line 894, but not defined == Missing Reference: 'IEEE-802.3ah' is mentioned on line 326, but not defined == Missing Reference: 'MPLS-TP-Term' is mentioned on line 439, but not defined == Missing Reference: 'OAM-Analysis' is mentioned on line 878, but not defined == Unused Reference: 'OAM-Label' is defined on line 1089, but no explicit reference was found in the text == Unused Reference: 'BFD-Gen' is defined on line 1150, but no explicit reference was found in the text == Unused Reference: 'MPLS-TP-Fault' is defined on line 1187, but no explicit reference was found in the text == Unused Reference: 'TP-Lock-Loop' is defined on line 1191, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4379 (ref. 'LSP-Ping') (Obsoleted by RFC 8029) ** Obsolete normative reference: RFC 2679 (ref. 'IPPM-1DM') (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (ref. 'IPPM-1LM') (Obsoleted by RFC 7680) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Operations and Management Area Working Group T. Mizrahi 2 Internet Draft Marvell 3 Intended status: Informational N. Sprecher 4 Expires: March 2013 Nokia Siemens Networks 5 E. Bellagamba 6 Ericsson 7 Y. Weingarten 9 September 12, 2012 11 An Overview of 12 Operations, Administration, and Maintenance (OAM) Mechanisms 13 draft-ietf-opsawg-oam-overview-07.txt 15 Abstract 17 Operations, Administration, and Maintenance (OAM) is a general term 18 that refers to a toolset that can be used for fault detection and 19 isolation, and for performance measurement. OAM mechanisms have been 20 defined for various layers in the protocol stack, and are used with a 21 variety of protocols. 23 This document presents an overview of the OAM mechanisms that have 24 been defined and are currently being defined by the IETF. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on March 12, 2013. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction ................................................. 3 67 1.1. Background .............................................. 3 68 1.2. The OAM toolsets ........................................ 4 69 1.3. IETF OAM Standards ...................................... 5 70 1.4. Non-IETF OAM Standards .................................. 8 71 2. Basic Terminology ............................................ 9 72 2.1. Abbreviations ........................................... 9 73 2.2. Terminology used in OAM Standards ...................... 10 74 2.2.1. General Terms ..................................... 10 75 2.2.2. OAM Maintenance Entities .......................... 11 76 2.2.3. OAM Maintenance Points ............................ 11 77 2.2.4. Proactive and On-demand activation ................ 12 78 2.2.5. Connectivity Verification and Continuity Checks ... 12 79 2.2.6. Failures .......................................... 13 80 3. OAM Tools ................................................... 13 81 3.1. ICMP Ping .............................................. 13 82 3.2. Traceroute ............................................. 13 83 3.3. Bidirectional Forwarding Detection (BFD) ............... 14 84 3.3.1. Overview .......................................... 14 85 3.3.2. BFD Control ....................................... 14 86 3.3.3. BFD Echo .......................................... 15 87 3.4. LSP Ping ............................................... 15 88 3.5. PWE3 Virtual Circuit Connectivity Verification (VCCV) .. 16 89 3.6. IP Performance Metrics (IPPM) .......................... 17 90 3.6.1. Overview .......................................... 17 91 3.6.2. Control and Test Protocols ........................ 17 92 3.6.3. OWAMP ............................................. 18 93 3.6.4. TWAMP ............................................. 18 94 3.7. MPLS-TP OAM ............................................ 19 95 3.7.1. Overview .......................................... 19 96 3.7.2. Generic Associated Channel ........................ 19 97 3.7.3. MPLS-TP OAM Toolset ............................... 20 98 3.7.3.1. Continuity Check and Connectivity Verification 20 99 3.7.3.2. Route Tracing ................................ 21 100 3.7.3.3. Lock Instruct ................................ 21 101 3.7.3.4. Lock Reporting ............................... 21 102 3.7.3.5. Alarm Reporting .............................. 21 103 3.7.3.6. Remote Defect Indication ..................... 22 104 3.7.3.7. Client Failure Indication .................... 22 105 3.7.3.8. Packet Loss Measurement ...................... 22 106 3.7.3.9. Packet Delay Measurement ..................... 22 107 3.8. Summary of OAM Functions ............................... 23 108 4. Security Considerations ..................................... 24 109 5. IANA Considerations ......................................... 24 110 6. Acknowledgments ............................................. 24 111 7. References .................................................. 24 112 7.1. Normative References ................................... 24 113 7.2. Informative References ................................. 27 115 1. Introduction 117 OAM is a general term that refers to a toolset that can be used for 118 detecting, isolating and reporting connection failures or measurement 119 of connection performance parameters. The term OAM has been used over 120 the years in several different contexts, as discussed in [OAM-Def]. 121 This term as been associated with the 3 logical abstraction layers: 122 the forwarding plane, the control plane, and the management plane. In 123 the context of this document OAM refers to Operations, 124 Administration, and Maintenance. Hence, management aspects are 125 outside the scope of this document. 127 1.1. Background 129 The communication of a network may be configured and maintained by 130 use of various tools at different layers - these include use of a 131 control plane or management plane to configure and maintain the 132 connectivity of the network from the outside - looking in - and 133 controlling the connections when the need arises. OAM, on the other 134 hand, traditionally has been used to maintain the connectivity in- 135 band with the actual data traffic, i.e. in the data plane. 137 While the OAM tools may, and quite often do, work in conjunction with 138 a control-plane or management plane, they are usually defined to be 139 independent of the control-plane. The OAM tools communicate with the 140 management plane to raise alarms, and often the on-demand tools may 141 be activated by the management, e.g. to locate and localize problems. 143 The considerations of the control-plane maintenance tools or the 144 functionality of the management-plane are out of scope for this 145 document, which will concentrate on presenting the data-plane tools 146 that are used for OAM. 148 1.2. The OAM toolsets 150 This memo provides an overview of the different sets of OAM 151 mechanisms defined by the IETF. It is intended for those with little 152 or no familiarity with the described mechanisms. The set of OAM 153 mechanisms described in this memo are applicable to IP unicast, MPLS, 154 pseudowires, and MPLS for the transport environment (MPLS-TP). While 155 OAM mechanisms that are applicable to other technologies exist, they 156 are beyond the scope of this memo. This document focuses on IETF 157 documents that have been published as RFCs, while other ongoing OAM- 158 related work is outside the scope. 160 The IETF has defined OAM protocols and mechanisms in several 161 different fronts: 163 o ICMP Ping: 164 ICMP Echo request, also known as Ping, as defined in [ICMPv4], and 165 [ICMPv6]. ICMP Ping is a very simple and basic mechanism in 166 failure diagnosis. LSP Ping is to some extent based on ICMP Ping. 168 o IPPM: 169 IP Performance Metrics (IPPM) is a working group in the IETF that 170 defined common metrics for performance measurement, as well as a 171 protocol for measuring delay and packet loss in IP networks. 173 o MPLS: 174 MPLS LSP Ping, as defined in [MPLS-OAM], [MPLS-OAM-FW] and [LSP- 175 Ping], is an OAM mechanism for point to point MPLS LSPs. 177 o MPLS-TP: 178 The OAM requirements for MPLS Transport Profile (MPLS-TP) are 179 defined in [MPLS-TP-OAM], and the toolset is described in [TP-OAM- 180 FW]. 182 o BFD: 183 Bidirectional Forwarding Detection (BFD) is defined in [BFD] as a 184 framework for a lightweight generic OAM mechanism. The intention 185 is to define a base mechanism that can be used with various 186 encapsulation types, network environments, and in various medium 187 types. 189 This document summarizes the OAM mechanisms defined by the IETF. We 190 first present a comparison of the terminology used in various OAM 191 standards, and then summarize the OAM functions that each OAM 192 standard provides. 194 1.3. IETF OAM Standards 196 Table 1 summarizes the IETF OAM standards discussed in this document. 198 The table includes a "Type" column, specifying the nature of each of 199 the listed documents: 201 o Tool: documents that define an OAM tool or mechanism. 203 o Prof.: documents that define a profile or a variant for an OAM 204 tool that is defined in other documents. 206 o Inf.: documents that define an infrastructure that is used by OAM 207 tools. 209 o Misc.: other OAM related documents, e.g., OAM requirement and 210 framework documents. 212 +-----------+--------------------------------------+-----+----------+ 213 | | Title |Type | RFC | 214 +-----------+--------------------------------------+-----+----------+ 215 |ICMPv4 Ping| Internet Control Message Protocol |Tool | RFC 792 | 216 | | | | | 217 +-----------+--------------------------------------+-----+----------+ 218 |ICMPv6 Ping| Internet Control Message Protocol |Tool | RFC 4443 | 219 | | (ICMPv6) for the Internet Protocol | | | 220 | | Version 6 (IPv6) Specification | | | 221 +-----------+--------------------------------------+-----+----------+ 222 |Traceroute | A Primer On Internet and TCP/IP |Tool | RFC 2151 | 223 | | Tools and Utilities | | | 224 +-----------+--------------------------------------+-----+----------+ 225 |BFD | Bidirectional Forwarding Detection |Tool | RFC 5880 | 226 | +--------------------------------------+-----+----------+ 227 | | Bidirectional Forwarding Detection |Prof.| RFC 5881 | 228 | | (BFD) for IPv4 and IPv6 (Single Hop) | | | 229 | +--------------------------------------+-----+----------+ 230 | | Generic Application of Bidirectional |Misc.| RFC 5882 | 231 | | Forwarding Detection | | | 232 | +--------------------------------------+-----+----------+ 233 | | Bidirectional Forwarding Detection |Prof.| RFC 5883 | 234 | | (BFD) for Multihop Paths | | | 235 | +--------------------------------------+-----+----------+ 236 | | Bidirectional Forwarding Detection |Prof.| RFC 5884 | 237 | | for MPLS Label Switched Paths (LSPs) | | | 238 | +--------------------------------------+-----+----------+ 239 | | Bidirectional Forwarding Detection |Prof.| RFC 5885 | 240 | | for the Pseudowire Virtual Circuit | | | 241 | | Connectivity Verification (VCCV) | | | 242 +-----------+--------------------------------------+-----+----------+ 243 |IETF MPLS | Operations and Management (OAM) |Misc.| RFC 4377 | 244 |OAM | Requirements for Multi-Protocol Label| | | 245 |(LSP Ping) | Switched (MPLS) Networks | | | 246 | +--------------------------------------+-----+----------+ 247 | | A Framework for Multi-Protocol |Misc.| RFC 4378 | 248 | | Label Switching (MPLS) Operations | | | 249 | | and Management (OAM) | | | 250 | +--------------------------------------+-----+----------+ 251 | | Detecting Multi-Protocol Label |Tool | RFC 4379 | 252 | | Switched (MPLS) Data Plane Failures | | | 253 | +--------------------------------------+-----+----------+ 254 | | Operations and Management (OAM) |Misc.| RFC 4687 | 255 | | Requirements for Point-to-Multipoint | | | 256 | | MPLS Networks | | | 257 | +--------------------------------------+-----+----------+ 258 | | ICMP Extensions for Multiprotocol |Tool | RFC 4950 | 259 | | Label Switching | | | 260 +-----------+--------------------------------------+-----+----------+ 261 |MPLS-TP | Requirements for OAM in MPLS-TP |Misc.| RFC 5860 | 262 |OAM +--------------------------------------+-----+----------+ 263 | | MPLS Generic Associated Channel |Inf. | RFC 5586 | 264 | +--------------------------------------+-----+----------+ 265 | | MPLS-TP OAM Framework |Misc.| RFC 6371 | 266 | +--------------------------------------+-----+----------+ 267 | | Proactive Connectivity Verification, |Tool | RFC 6428 | 268 | | Continuity Check, and Remote Defect | | | 269 | | Indication for the MPLS Transport | | | 270 | | Profile | | | 271 | +--------------------------------------+-----+----------+ 272 | | MPLS On-Demand Connectivity |Tool | RFC 6426 | 273 | | Verification and Route Tracing | | | 274 | +--------------------------------------+-----+----------+ 275 | | MPLS Fault Management Operations, |Tool | RFC 6427 | 276 | | Administration, and Maintenance (OAM)| | | 277 | +--------------------------------------+-----+----------+ 278 | | MPLS Transport Profile Lock Instruct |Tool | RFC 6435 | 279 | | and Loopback Functions | | | 280 | +--------------------------------------+-----+----------+ 281 | | Packet Loss and Delay Measurement for|Tool | RFC 6374 | 282 | | MPLS Networks | | | 283 | +--------------------------------------+-----+----------+ 284 | | A Packet Loss and Delay Measurement |Prof.| RFC 6375 | 285 | | Profile for MPLS-Based Transport | | | 286 | | Networks | | | 287 +-----------+--------------------------------------+-----+----------+ 288 |PW VCCV | Pseudowire Virtual Circuit |Inf. | RFC 5085 | 289 | | Connectivity Verification (VCCV): | | | 290 | | A Control Channel for Pseudowires | | | 291 +-----------+--------------------------------------+-----+----------+ 292 |IPPM | Framework for IP Performance Metrics |Misc.| RFC 2330 | 293 | +--------------------------------------+-----+----------+ 294 | | IPPM Metrics for Measuring |Misc.| RFC 2678 | 295 | | Connectivity | | | 296 | +--------------------------------------+-----+----------+ 297 | | A One-way Delay Metric for IPPM |Misc.| RFC 2679 | 298 | +--------------------------------------+-----+----------+ 299 | | A One-way Packet Loss Metric for IPPM|Misc.| RFC 2680 | 300 | +--------------------------------------+-----+----------+ 301 | | A Round-trip Delay Metric for IPPM |Misc.| RFC 2681 | 302 | +--------------------------------------+-----+----------+ 303 | | A One-way Active Measurement Protocol|Tool | RFC 4656 | 304 | | (OWAMP) | | | 305 | +--------------------------------------+-----+----------+ 306 | | A Two-Way Active Measurement Protocol|Tool | RFC 5357 | 307 | | (TWAMP) | | | 308 +-----------+--------------------------------------+-----+----------+ 309 Table 1 Summary of IETF OAM Related Standards 311 1.4. Non-IETF OAM Standards 313 In addition to the OAM mechanisms defined by the IETF, the IEEE and 314 ITU-T have also defined various OAM mechanisms that focus on 315 Ethernet, and various other transport network environments. These 316 various mechanisms, defined by the three standard organizations, are 317 often tightly coupled, and have had a mutual effect on each other. 318 The ITU-T and IETF have both defined OAM mechanisms for MPLS LSPs, 319 [ITU-T-Y.1711] and [LSP-Ping]. The following OAM standards by the 320 IEEE and ITU-T are to some extent linked to IETF OAM mechanisms 321 listed above and are mentioned here only as reference material: 323 o OAM mechanisms for Ethernet based networks have been defined by 324 both the ITU-T in [ITU-T-Y.1731], and by the IEEE in [IEEE- 325 802.1ag]. The IEEE 802.3 standard defines OAM for one-hop Ethernet 326 links [IEEE-802.3ah]. 328 o The ITU-T has defined OAM for MPLS LSPs in [ITU-T-Y.1711]. 330 Table 2 summarizes the OAM standards mentioned in this document. This 331 document focuses on IETF OAM standards, but these non-IETF standards 332 are referenced where relevant. 334 +-----------+--------------------------------------+---------------+ 335 | | Title |Standard/Draft | 336 +-----------+--------------------------------------+---------------+ 337 |ITU-T | Operation & Maintenance mechanism |[ITU-T-Y.1711] | 338 |MPLS OAM | for MPLS networks | | 339 | +--------------------------------------+---------------+ 340 | | Assignment of the 'OAM Alert Label' | RFC 3429 | 341 | | for Multiprotocol Label Switching | | 342 | | Architecture (MPLS) Operation and | | 343 | | Maintenance (OAM) Functions | | 344 | | | | 345 | | Note: although this is an IETF | | 346 | | document, it is listed as one of the| | 347 | | non-IETF OAM standards, since it | | 348 | | was defined as a complementary part | | 349 | | of Y.1711. | | 350 +-----------+--------------------------------------+---------------+ 351 |ITU-T | OAM Functions and Mechanisms for |[ITU-T-Y.1731] | 352 |Ethernet | Ethernet-based Networks | | 353 |OAM | | | 354 +-----------+--------------------------------------+---------------+ 355 |IEEE | Connectivity Fault Management |[IEEE-802.1ag] | 356 |CFM | | | 357 +-----------+--------------------------------------+---------------+ 358 |IEEE | Media Access Control Parameters, |[IEEE-802.3ah] | 359 |802.3 | Physical Layers, and Management | | 360 |link level | Parameters for Subscriber Access | | 361 |OAM | Networks | | 362 +-----------+--------------------------------------+---------------+ 363 Table 2 Non-IETF OAM Standards Mentioned in this Document 365 2. Basic Terminology 367 2.1. Abbreviations 369 ACH Associated Channel Header 371 AIS Alarm Indication Signal 373 BFD Bidirectional Forwarding Detection 375 CC Continuity Check 377 CCM Continuity Check Message 379 CV Connectivity Verification 381 DM Delay Measurement 383 FEC Forwarding Equivalence Class 385 GAL Generic Associated Label 387 ICMP Internet Control Message Protocol 389 L2TP Layer Two Tunneling Protocol 391 LCCE L2TP Control Connection Endpoint 393 LDP Label Distribution Protocol 395 LM Loss Measurement 397 LOC Loss Of Continuity 398 LSP Label Switched Path 400 LSR Label Switching Router 402 ME Maintenance Entity 404 MEG Maintenance Entity Group 406 MEP MEG End Point 408 MIP MEG Intermediate Point 410 MP Maintenance Point 412 MPLS Multiprotocol Label Switching 414 MPLS-TP MPLS Transport Profile 416 MTU Maximum Transmission Unit 418 OAM Operations, Administration, and Maintenance 420 PE Provider Edge 422 PW Pseudowire 424 PWE3 Pseudowire Emulation Edge-to-Edge 426 RDI Remote Defect Indication 428 TTL Time To Live 430 VCCV Virtual Circuit Connectivity Verification 432 2.2. Terminology used in OAM Standards 434 2.2.1. General Terms 436 A wide variety of terms is used in various OAM standards. Each of the 437 OAM standards listed in the reference section includes a section that 438 defines terms relevant to that tool. A thesaurus of terminology for 439 MPLS-TP terms is presented in [MPLS-TP-Term], and provides a good 440 summary of some of the OAM related terminology. 442 This section presents a comparison of the terms used in various OAM 443 standards, without fully quoting the definition of each term. For a 444 formal definition of each term, refer to the references at the end of 445 this document. 447 2.2.2. OAM Maintenance Entities 449 OAM tools are designed to monitor and manage a Maintenance Entity 450 (ME). An ME, as defined in [TP-OAM-FW], defines a relationship 451 between two points of a transport path to which maintenance and 452 monitoring operations apply. 454 The following related terms are also quoted from [TP-OAM-FW]: 456 o MEP: The two points that define a maintenance entity. 458 o MEG: The collection of one or more MEs that belongs to the same 459 transport path and that are maintained and monitored as a group 460 are known as a Maintenance Entity Group (MEG). 462 o MIP: In between MEPs, there are zero or more intermediate points, 463 called Maintenance Entity Group Intermediate Points (MIPs). 465 A pair of MEPs engaged in an ME are connected by a communication 466 link, which may be one of several types of connection, e.g. a single 467 physical connection, a set of physical connections, or a virtual link 468 such as an MPLS LSP. 470 The term Maintenance Entity (ME) is used in ITU-T Recommendations 471 (e.g. [ITU-T-Y.1731]), as well as in the MPLS-TP terminology ([TP- 472 OAM-FW]). Various terms are used to refer to an ME. For example, BFD 473 does not explicitly use a term that is equivalent to ME, but rather 474 uses the term "session", referring to the relationship between two 475 nodes using a BFD protocol. The MPLS LSP Ping ([LSP-Ping]) 476 terminology simply uses the term "LSP" in this context. 478 MPLS-TP has defined the terms ME and Maintenance Entity Group (MEG) 479 in [TP-OAM-FW], similar to the terms defined by ITU-T. A MEG allows 480 the monitoring of a compound set of MEs, for example when monitoring 481 a p2mp MEG that is considered to be the set of MEs between the root 482 and each individual destination MEP. 484 2.2.3. OAM Maintenance Points 486 A Maintenance Point (MP) is a functional entity that is defined at a 487 node in the network, and either initiates or reacts to OAM messages. 488 A Maintenance End Point (MEP) is one of the end points of an ME, and 489 can initiate OAM messages and respond to them. A Maintenance 490 Intermediate Point (MIP) is an intermediate point between two MEPs, 491 that does not generally initiate OAM frames (one exception to this is 492 the use of AIS notifications), but is able to respond to OAM frames 493 that are destined to it. A MIP in MPLS-TP identifies OAM packets 494 destined to it by the value of the TTL field in the OAM packet. The 495 term Maintenance Point is a general term for MEPs and MIPs. 497 The 802.1ag defines a finer distinction between Up MPs and Down MPs. 498 An MP is a bridge interface, that is monitored by an OAM protocol 499 either in the direction facing the network, or in the direction 500 facing the bridge. A Down MP is an MP that receives OAM packets from, 501 and transmits them to the direction of the network. An Up MP receives 502 OAM packets from, and transmits them to the direction of the bridging 503 entity. 505 MPLS-TP ([TP-OAM-FW]) uses a similar distinction on the placement of 506 the MP - either at the ingress, egress, or forwarding function of the 507 node (Down / Up MPs). This placement is important for localization 508 of a connection failure. 510 2.2.4. Proactive and On-demand activation 512 The different OAM tools may be used in one of two basic types of 513 activation: 515 o Proactive activation - indicates that the tool is activated on a 516 continual basis periodically, where messages are sent between the 517 two MEPs, and errors are detected when a certain number of 518 expected messages are not received. 520 o On-demand activation - indicates that the tool is activated 521 "manually" to detect a specific anomaly. In this activation a 522 small number of OAM messages are sent by a MEP and the reply 523 message is received. 525 2.2.5. Connectivity Verification and Continuity Checks 527 Two distinct classes of failure management functions are used in OAM 528 protocols, connectivity verification and continuity checks. The 529 distinction between these terms is defined in [MPLS-TP-OAM], and is 530 used similarly in this document. 532 Continuity checks are used to verify the liveness of a connection or 533 a path between two MPs, and are typically sent proactively, though 534 they can be invoked on-demand as well. 536 A connectivity verification function allows an MP to check whether it 537 is connected to a peer MP or not. This function also allows the MP to 538 verify that messages from the peer MP are received through the 539 correct path, thereby verifying not only that the two MPs are 540 connected, but also that they are connected through the expected 541 path. This allows detection of unexpected topology changes. A 542 connectivity verification (CV) protocol typically uses a CV message, 543 followed by a CV reply that is sent back to the originator. A CV 544 function can be applied proactively or on-demand. 546 Connectivity verification and continuity checks are considered 547 complementary mechanisms, and are often used in conjunction with each 548 other. 550 2.2.6. Failures 552 The terms Failure, Fault, and Defect are used interchangeably in the 553 standards, referring to a malfunction that can be detected by a 554 connectivity or a continuity check. In some standards, such as [IEEE- 555 802.1ag], there is no distinction between these terms, while in other 556 standards each of these terms refers to a different type of 557 malfunction. 559 The terminology used in IETF MPLS-TP OAM takes after the ITU-T, which 560 distinguishes between these terms in [ITU-T-G.806]; The term Fault 561 refers to an inability to perform a required action, e.g., an 562 unsuccessful attempt to deliver a packet. The term Defect refers to 563 an interruption in the normal operation, such as a consecutive period 564 of time where no packets are delivered successfully. The term Failure 565 refers to the termination of the required function. While a Defect 566 typically refers to a limited period of time, a failure refers to a 567 long period of time. 569 3. OAM Tools 571 3.1. ICMP Ping 573 ICMP provides a connectivity verification function for the Internet 574 Protocol. The originator transmits an ICMP Echo request packet, and 575 the receiver replies with an echo reply. ICMP ping is defined in two 576 variants, [ICMPv4] is used for IPv4, and [ICMPv6] is used for IPv6. 578 3.2. Traceroute 580 Traceroute ([TCPIP-Tools]) is an application that allows users to 581 discover the path between an IP source and an IP destination. 582 Traceroute sends a sequence of UDP packets to UDP port 33434 at the 583 destination. By default, Traceroute begins by sending three packets, 584 each with an IP Time-To-Live (TTL) value of one to the destination. 586 These packets expire as soon as they reach the first router in the 587 path. That router responds by sending three ICMP Time Exceeded 588 Messages to the Traceroute application. Traceroute now sends another 589 three UDP packets, each with the TTL value of 2. These messages cause 590 the second router to return ICMP messages. This process continues, 591 with ever increasing values for the TTL field, until the packets 592 actually reach the destination. Because no application listens to 593 port 33434 at the destination, the destination returns ICMP 594 Destination Unreachable Messages indicating an unreachable port. This 595 event indicates to the Traceroute application that it is finished. 596 The Traceroute program displays the round-trip delay associated with 597 each of the attempts. 599 Note that IP routing may be asymmetric. While Traceroute reveals the 600 path between a source and destination, it may not reveal the reverse 601 path. 603 3.3. Bidirectional Forwarding Detection (BFD) 605 3.3.1. Overview 607 While multiple OAM mechanisms have been defined for various protocols 608 in the protocol stack, Bidirectional Forwarding Detection [BFD], 609 defined by the IETF BFD working group, is a generic OAM mechanism 610 that can be deployed over various encapsulating protocols, and in 611 various medium types. The IETF has defined variants of the protocol 612 for IP ([BFD-IP], [BFD-Multi]), for MPLS LSPs [BFD-LSP], and for PWE3 613 [BFD-VCCV]. The usage of BFD in MPLS-TP is defined in [MPLS-TP-CC- 614 CV]. 616 BFD includes two main OAM functions, using two types of BFD packets: 617 BFD Control packets, and BFD Echo packets. 619 3.3.2. BFD Control 621 BFD supports a bidirectional continuity check, using BFD control 622 packets, that are exchanged within a BFD session. BFD sessions 623 operate in one of two modes: 625 o Asynchronous mode (i.e. proactive): in this mode BFD control 626 packets are sent periodically. When the receiver detects that no 627 BFD control packet have been received during a predetermined 628 period of time, a failure is detected. 630 o Demand mode: in this mode, BFD control packets are sent on-demand. 631 Upon need, a system initiates a series of BFD control packets to 632 verify the liveness of the session. BFD control packets are sent 633 independently in each direction. 635 Each of the end-points of the monitored path maintains its own 636 session identification, called a Discriminator, both of which are 637 included in the BFD Control Packets that are exchanged between the 638 end-points. At the time of session establishment, the Discriminators 639 are exchanged between the two-end points. In addition, the 640 transmission (and reception) rate is negotiated between the two end- 641 points, based on information included in the control packets. These 642 transmission rates may be renegotiated during the session. 644 During normal operation of the session, i.e. no failures are 645 detected, the BFD session is in the Up state. If no BFD Control 646 packets are received during a fixed period of time, called the 647 Detection Time, the session is declared to be Down. The detection 648 time is a function of the negotiated transmission time, and a 649 parameter called Detect Mult. Detect Mult determines the number of 650 missing BFD Control packets that cause the session to be declared as 651 Down. This parameter is included in the BFD Control packet. 653 3.3.3. BFD Echo 655 A BFD echo packet is sent to a peer system, and is looped back to the 656 originator. The echo function can be used proactively, or on-demand. 658 The BFD echo function has been defined in BFD for IPv4 and IPv6 659 ([BFD-IP]), but is not used in BFD for MPLS LSPs, PWs, or in BFD for 660 MPLS-TP. 662 3.4. LSP Ping 664 The IETF MPLS working group has defined OAM for MPLS LSPs. The 665 requirements and framework of this effort are defined in [MPLS-OAM- 666 FW] and [MPLS-OAM], respectively. The corresponding OAM mechanism 667 defined, in this context, is LSP Ping [LSP-Ping]. 669 LSP Ping is based on ICMP Ping and just like its predecessor may be 670 used in one of two modes: 672 o "Ping" mode: In this mode LSP ping is used for end-to-end 673 connectivity verification between two LERs. 675 o "Traceroute" mode: This mode is used for hop-by-hop fault 676 isolation. 678 LSP Ping extends the basic ICMP Ping operation (of data-plane 679 connectivity verification) with functionality to verify data-plane 680 vs. control-plane consistency for a Forwarding Equivalence Class 681 (FEC) and also Maximum Transmission Unit (MTU) problems. The 682 traceroute functionality may be used to isolate and localize the MPLS 683 faults, using the Time-to-live (TTL) indicator to incrementally 684 identify the sub-path of the LSP that is successfully traversed 685 before the faulty link or node. 687 It should be noted that LSP Ping supports unique identification of 688 the LSP within an addressing domain. The identification is checked 689 using the full FEC identification. LSP Ping is easily extensible to 690 include additional information needed to support new functionality, 691 by use of Type-Length-Value (TLV) constructs. The usage of TLVs is 692 typically not easy to perform in hardware, and is thus typically 693 handled by the control plane. 695 LSP Ping supports both asynchronous, as well as, on-demand 696 activation. 698 3.5. PWE3 Virtual Circuit Connectivity Verification (VCCV) 700 VCCV, as defined in [VCCV], provides a means for end-to-end fault 701 detection and diagnostics tools to be extended for PWs (regardless of 702 the underlying tunneling technology). The VCCV switching function 703 provides a control channel associated with each PW (based on the PW 704 Associated Channel Header (ACH) which is defined in [PW-ACH]), and 705 allows transmitting the OAM packets in-band with PW data (using CC 706 Type 1: In-band VCCV). 708 VCCV currently supports the following OAM mechanisms: ICMP Ping, LSP 709 Ping, and BFD. ICMP and LSP Ping are IP encapsulated before being 710 sent over the PW ACH. BFD for VCCV supports two modes of 711 encapsulation - either IP/UDP encapsulated (with IP/UDP header) or 712 PW-ACH encapsulated (with no IP/UDP header) and provides support to 713 signal the AC status. The use of the VCCV control channel provides 714 the context, based on the MPLS-PW label, required to bind and 715 bootstrap the BFD session to a particular pseudo wire (FEC), 716 eliminating the need to exchange Discriminator values. 718 VCCV consists of two components: (1) signaled component to 719 communicate VCCV capabilities as part of VC label, and (2) switching 720 component to cause the PW payload to be treated as a control packet. 722 VCCV is not directly dependent upon the presence of a control plane. 723 The VCCV capability negotiation may be performed as part of the PW 724 signaling when LDP is used. In case of manual configuration of the 725 PW, it is the responsibility of the operator to set consistent 726 options at both ends. 728 3.6. IP Performance Metrics (IPPM) 730 3.6.1. Overview 732 The IPPM working group in the IETF defines common criteria and 733 metrics for measuring performance of IP traffic ([IPPM-FW]). Some of 734 the key RFCs published by this working group have defined metrics for 735 measuring connectivity [IPPM-Con], delay ([IPPM-1DM], [IPPM-2DM]), 736 and packet loss [IPPM-1LM]. 738 Alternative protocols for performance measurement are defined, for 739 example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet 740 OAM [ITU-T-Y.1731]. 742 The IPPM working group has defined not only metrics for performance 743 measurement, but also protocols that define how the measurement is 744 carried out. The One-way Active Measurement Protocol [OWAMP] and the 745 Two-Way Active Measurement Protocol [TWAMP] define a method and 746 protocol for measuring delay and packet loss in IP networks. 748 OWAMP [OWAMP] enables measurement of one-way characteristics of IP 749 networks, such as one-way packet loss and one-way delay. For its 750 proper operation OWAMP requires accurate time of day setting at its 751 end points. 753 TWAMP [TWAMP] is a similar protocol that enables measurement of two- 754 way (round trip) characteristics. TWAMP does not require accurate 755 time of day, and, furthermore, allows the use of a simple session 756 reflector, making it an attractive alternative to OWAMP. 758 OWAMP and TWAMP use two separate protocols: a Control plane protocol, 759 and a Test plane protocol. 761 3.6.2. Control and Test Protocols 763 OWAMP and TWAMP control protocols run over TCP, while the test 764 protocols run over UDP. The purpose of the control protocols is to 765 initiate, start, and stop test sessions, and for OWAMP to fetch 766 results. The test protocols introduce test packets (which contain 767 sequence numbers and timestamps) along the IP path under test 768 according to a schedule, and record statistics of packet arrival. 769 Multiple sessions may be simultaneously defined, each with a session 770 identifier, and defining the number of packets to be sent, the amount 771 of padding to be added (and thus the packet size), the start time, 772 and the send schedule (which can be either a constant time between 773 test packets or exponentially distributed pseudo-random). Statistics 774 recorded conform to the relevant IPPM RFCs. 776 OWAMP and TWAMP test traffic is designed with security in mind. Test 777 packets are hard to detect because they are simply UDP streams 778 between negotiated port numbers, with potentially nothing static in 779 the packets. OWAMP and TWAMP also include optional authentication 780 and encryption for both control and test packets. 782 3.6.3. OWAMP 784 OWAMP defines the following logical roles: Session-Sender, Session- 785 Receiver, Server, Control-Client, and Fetch-Client. The Session- 786 Sender originates test traffic that is received by the Session- 787 Receiver. The Server configures and manages the session, as well as 788 returning the results. The Control-Client initiates requests for 789 test sessions, triggers their start, and may trigger their 790 termination. The Fetch-Client requests the results of a completed 791 session. Multiple roles may be combined in a single host - for 792 example, one host may play the roles of Control-Client, Fetch-Client, 793 and Session-Sender, and a second playing the roles of Server and 794 Session-Receiver. 796 In a typical OWAMP session the Control-Client establishes a TCP 797 connection to port 861 of the Server, which responds with a server 798 greeting message indicating supported security/integrity modes. The 799 Control-Client responds with the chosen communications mode and the 800 Server accepts the modes. The Control-Client then requests and fully 801 describes a test session to which the Server responds with its 802 acceptance and supporting information. More than one test session 803 may be requested with additional messages. The Control-Client then 804 starts a test session and the Server acknowledges. The Session- 805 Sender then sends test packets with pseudorandom padding to the 806 Session-Receiver until the session is complete or until the Control- 807 client stops the session. Once finished, the Fetch-Client sends a 808 fetch request to the server, which responds with an acknowledgement 809 and immediately thereafter the result data. 811 3.6.4. TWAMP 813 TWAMP defines the following logical roles: session-sender, session- 814 reflector, server, and control-client. These are similar to the 815 OWAMP roles, except that the Session-Reflector does not collect any 816 packet information, and there is no need for a Fetch-Client. 818 In a typical TWAMP session the Control-Client establishes a TCP 819 connection to port 862 of the Server, and mode is negotiated as in 820 OWAMP. The Control-Client then requests sessions and starts them. 821 The Session-Sender sends test packets with pseudorandom padding to 822 the Session-Reflector which returns them with insertion of 823 timestamps. 825 3.7. MPLS-TP OAM 827 3.7.1. Overview 829 The MPLS working group is currently working on defining the OAM 830 toolset that fulfills the requirements for MPLS-TP OAM. The full set 831 of requirements for MPLS-TP OAM are defined in [MPLS-TP-OAM], and 832 include both general requirements for the behavior of the OAM 833 mechanisms and a set of operations that should be supported by the 834 OAM toolset. The set of mechanisms required are further elaborated 835 in [TP-OAM-FW], which describes the general architecture of the OAM 836 system as well as giving overviews of the functionality of the OAM 837 toolset. 839 Some of the basic requirements for the OAM toolset for MPLS-TP are: 841 o MPLS-TP OAM must be able to support both an IP based and non-IP 842 based environment. If the network is IP based, i.e. IP routing and 843 forwarding are available, then the MPLS-TP OAM toolset should rely 844 on the IP routing and forwarding capabilities. On the other hand, 845 in environments where IP functionality is not available, the OAM 846 tools must still be able to operate without dependence on IP 847 forwarding and routing. 849 o OAM packets and the user traffic are required to be congruent 850 (i.e. OAM packets are transmitted in-band) and there is a need to 851 differentiate OAM packets from user-plane ones. Inherent in this 852 requirement is the principle that MPLS-TP OAM be independent of 853 any existing control-plane, although it should not preclude use of 854 the control-plane functionality. 856 3.7.2. Generic Associated Channel 858 In order to address the requirement for in-band transmission of MPLS- 859 TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh), 860 defined in [G-ACh] for LSP-based OAM traffic. This mechanism is based 861 on the same concepts as the PWE3 ACH and VCCV mechanisms. However, 862 to address the needs of LSPs as differentiated from PW, the following 863 concepts were defined for [G-ACh]: 865 o An Associated Channel Header (ACH), that uses a format similar to 866 the PW Control Word, is a 4-byte header that is prepended to OAM 867 packets. 869 o A Generic Associated Label (GAL). The GAL is a reserved MPLS label 870 value (13) that indicates that the packet is an ACH packet and the 871 payload follows immediately after the label stack. 873 3.7.3. MPLS-TP OAM Toolset 875 To address the functionality that is required of the OAM toolset, the 876 MPLS WG conducted an analysis of the existing IETF and ITU-T OAM 877 mechanisms and their ability to fulfill the required functionality. 878 The conclusions of this analysis are documented in [OAM-Analysis]. 879 The MPLS working group currently plans to use a mixture of OAM 880 mechanisms that are based on various existing standards, and adapt 881 them to the requirements of [MPLS-TP-OAM]. Some of the main building 882 blocks of this solution are based on: 884 o Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) for 885 proactive continuity check and connectivity verification. 887 o LSP Ping as defined in [LSP-Ping] for on-demand connectivity 888 verification. 890 o New protocol packets, using G-ACH, to address different 891 functionality. 893 o Performance measurement protocols that are based on the 894 functionality that is described in [ITU-T-Y.1731]. 896 The following sub-sections describe the OAM tools defined for MPLS-TP 897 as described in [TP-OAM-FW]. 899 3.7.3.1. Continuity Check and Connectivity Verification 901 Continuity Check and Connectivity Verification are presented in 902 Section 2.2.5 of this document. As presented there, these tools may 903 be used either proactively or on-demand. When using these tools 904 proactively, they are generally used in tandem. 906 For MPLS-TP there are two distinct tools, the proactive tool is 907 defined in [MPLS-TP-CC-CV] while the on-demand tool is defined in 908 [OnDemand-CV].Proactively [MPLS-TP-OAM] states that the function 909 should allow the MEPs to monitor the liveness and connectivity of a 910 transport path. In on-demand mode, this function should support 911 monitoring between the MEPs and, in addition, between a MEP and MIP. 913 [TP-OAM-FW] highlights, when performing Connectivity Verification, 914 the need for the CC-V messages to include unique identification of 915 the MEG that is being monitored and the MEP that originated the 916 message. 918 The proactive tool [MPLS-TP-CC-CV] is based on extensions to BFD (see 919 Section 3.3) with the additional limitation that the transmission and 920 receiving rates are based on configuration by the operator. The on- 921 demand tool [OnDemand-CV] is an adaptation of LSP Ping (See Section 922 3.4) for the required behavior of MPLS-TP. 924 3.7.3.2. Route Tracing 926 [MPLS-TP-OAM] defines that there is a need for functionality that 927 would allow a path end-point to identify the intermediate and end- 928 points of the path. This function would be used in on-demand mode. 929 Normally, this path will be used for bidirectional PW, LSP, and 930 sections, however, unidirectional paths may be supported only if a 931 return path exists. The tool for this is based on the LSP Ping (See 932 Section 3.4) functionality and is described in [OnDemand-CV]. 934 3.7.3.3. Lock Instruct 936 The Lock Instruct function is used to notify a transport path end- 937 point of an administrative need to disable the transport path. This 938 functionality will generally be used in conjunction with some 939 intrusive OAM function, e.g. Performance measurement, Diagnostic 940 testing, to minimize the side-effect on user data traffic. 942 3.7.3.4. Lock Reporting 944 Lock Reporting is a function used by an end-point of a path to report 945 to its far-end end-point that a lock condition has been affected on 946 the path. 948 3.7.3.5. Alarm Reporting 950 Alarm Reporting is a function used by an intermediate point of a 951 path, that becomes aware of a fault on the path, to report to the 952 end-points of the path. [TP-OAM-FW] states that this may occur as a 953 result of a defect condition discovered at a server sub-layer. This 954 generates an Alarm Indication Signal (AIS) that continues until the 955 fault is cleared. The consequent action of this function is detailed 956 in [TP-OAM-FW]. 958 3.7.3.6. Remote Defect Indication 960 Remote Defect Indication (RDI) is used proactively by a path end- 961 point to report to its peer end-point that a defect is detected on a 962 bidirectional connection between them. [MPLS-TP-OAM] points out that 963 this function may be applied to a unidirectional LSP only if there a 964 return path exists. [TP-OAM-FW] points out that this function is 965 associated with the proactive CC-V function. 967 3.7.3.7. Client Failure Indication 969 Client Failure Indication (CFI) is defined in [MPLS-TP-OAM] to allow 970 the propagation information from one edge of the network to the 971 other. The information concerns a defect to a client, in the case 972 that the client does not support alarm notification. 974 3.7.3.8. Packet Loss Measurement 976 Packet Loss Measurement is a function used to verify the quality of 977 the service. This function indicates the ratio of packets that are 978 not delivered out of all packets that are transmitted by the path 979 source. 981 There are two possible ways of determining this measurement: 983 o Using OAM packets, it is possible to compute the statistics based 984 on a series of OAM packets. This, however, has the disadvantage of 985 being artificial, and may not be representative since part of the 986 packet loss may be dependent upon packet sizes. 988 o Sending delimiting messages for the start and end of a measurement 989 period during which the source and sink of the path count the 990 packets transmitted and received. After the end delimiter, the 991 ratio would be calculated by the path OAM entity. 993 3.7.3.9. Packet Delay Measurement 995 Packet Delay Measurement is a function that is used to measure one- 996 way or two-way delay of a packet transmission between a pair of the 997 end-points of a path (PW, LSP, or Section). Where: 999 o One-way packet delay is the time elapsed from the start of 1000 transmission of the first bit of the packet by a source node until 1001 the reception of the last bit of that packet by the destination 1002 node. 1004 o Two-way packet delay is the time elapsed from the start of 1005 transmission of the first bit of the packet by a source node until 1006 the reception of the last bit of the loop-backed packet by the 1007 same source node, when the loopback is performed at the packet's 1008 destination node. 1010 Similarly to the packet loss measurement this could be performed in 1011 either of the two ways outlined above. 1013 3.8. Summary of OAM Functions 1015 Table 3 summarizes the OAM functions that are supported in each of 1016 the standards that were analyzed in this section. 1018 +-----------+-------+--------+--------+-----------+-------+--------+ 1019 | Standard |Continu|Connecti|Path |Defect |Perform|Other | 1020 | |ity |vity |Discover|Indications|ance |Function| 1021 | |Check |Verifica|y | |Monitor|s | 1022 | | |tion | | |ing | | 1023 +-----------+-------+--------+--------+-----------+-------+--------+ 1024 |ICMP Ping | |Echo | | | | | 1025 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1026 |Traceroute | | |Tracerou| | | | 1027 | | | |te | | | | 1028 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1029 |BFD |BFD |BFD | | | | | 1030 | |Control|Echo | | | | | 1031 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1032 |LSP Ping | |"Ping" |"Tracero| | | | 1033 | | |mode |ute" | | | | 1034 | | | |mode | | | | 1035 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1036 |IPPM | | | | |-Delay | | 1037 | | | | | | measur| | 1038 | | | | | | ement | | 1039 | | | | | |-Packet| | 1040 | | | | | | loss | | 1041 | | | | | | measur| | 1042 | | | | | | ement | | 1043 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1044 |MPLS-TP |CC |CV/pro- |Route |-Alarm |-LM |-Diagnos| 1045 |OAM | |active |Tracing | Reporting |-DM | tic Tes| 1046 | | |or on- | |-Client | | t | 1047 | | |demand | | Failure | |-Lock | 1048 | | | | | Indication| | | 1049 | | | | |-Remote | | | 1050 | | | | | Defect | | | 1051 | | | | | Indication| | | 1052 +-----------+-------+--------+--------+-----------+-------+--------+ 1053 Table 3 Summary of OAM Functions 1055 4. Security Considerations 1057 This memo presents an overview of existing OAM mechanisms, and 1058 proposes no new OAM mechanisms. Therefore, this document introduces 1059 no security considerations. However, the OAM mechanism reviewed in 1060 this document can and do present security issues. The reader is 1061 encouraged to review the Security Considerations section of each 1062 document reference by this memo. 1064 5. IANA Considerations 1066 There are no new IANA considerations implied by this document. 1068 6. Acknowledgments 1070 This document was prepared using 2-Word-v2.0.template.dot. 1072 7. References 1074 7.1. Normative References 1076 [LSP-Ping] Kompella, K., Swallow, G., "Detecting Multi-Protocol 1077 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1078 February 2006. 1080 [MPLS-OAM] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and 1081 Matsushima, S., "Operations and Management (OAM) 1082 Requirements for Multi-Protocol Label Switched (MPLS) 1083 Networks", RFC 4377, February 2006. 1085 [MPLS-OAM-FW] Allan, D., Nadeau, T., "A Framework for Multi-Protocol 1086 Label Switching (MPLS) Operations and Management 1087 (OAM)", RFC 4378, February 2006. 1089 [OAM-Label] Ohta, H., "Assignment of the 'OAM Alert Label' for 1090 Multiprotocol Label Switching Architecture (MPLS) 1091 Operation and Maintenance (OAM) Functions", RFC 3429, 1092 November 2002. 1094 [MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements for 1095 OAM in MPLS Transport Networks", RFC 5860, May 2010. 1097 [G-ACh] Bocci, M., Vigoureux, M., Bryant, S., "MPLS Generic 1098 Associated Channel", RFC 5586, June 2009. 1100 [VCCV] Nadeau, T., Pignataro, C., "Pseudowire Virtual Circuit 1101 Connectivity Verification (VCCV): A Control Channel 1102 for Pseudowires", RFC 5085, December 2007. 1104 [PW-ACH] Bryant, S., Swallow, G., Martini, L., McPherson, D., 1105 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word 1106 for Use over an MPLS PSN", RFC 4385, February 2006. 1108 [ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, 1109 RFC 792, September 1981. 1111 [ICMPv6] Conta, A., Deering, S., and M. Gupta, "Internet Control 1112 Message Protocol (ICMPv6) for the Internet Protocol 1113 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1115 [TCPIP-Tools] Kessler, G., Shepard, S., "A Primer On Internet and 1116 TCP/IP Tools and Utilities", RFC 2151, June 1997. 1118 [IPPM-FW] Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., 1119 "Framework for IP Performance Metrics", RFC 2330, May 1120 1998. 1122 [IPPM-Con] Mahdavi, J., Paxson, V., "IPPM Metrics for Measuring 1123 Connectivity", RFC 2678, September 1999. 1125 [IPPM-1DM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way 1126 Delay Metric for IPPM", RFC 2679, September 1999. 1128 [IPPM-1LM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way 1129 Packet Loss Metric for IPPM", RFC 2680, September 1130 1999. 1132 [IPPM-2DM] Almes, G., Kalidindi, S., Zekauskas, M., "A Round-trip 1133 Delay Metric for IPPM", RFC 2681, September 1999. 1135 [OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and 1136 Zekauskas, M., "A One-way Active Measurement Protocol 1137 (OWAMP)", RFC 4656, September 2006. 1139 [TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and 1140 Babiarz, J., "A Two-Way Active Measurement Protocol 1141 (TWAMP)", RFC 5357, October 2008. 1143 [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection 1144 (BFD)", RFC 5880, June 2010. 1146 [BFD-IP] Katz, D., Ward, D., "Bidirectional Forwarding Detection 1147 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 1148 2010. 1150 [BFD-Gen] Katz, D., Ward, D., "Generic Application of 1151 Bidirectional Forwarding Detection (BFD)", RFC 5882, 1152 June 2010. 1154 [BFD-Multi] Katz, D., Ward, D., "Bidirectional Forwarding Detection 1155 (BFD) for Multihop Paths", RFC 5883, June 2010. 1157 [BFD-LSP] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, 1158 G., "Bidirectional Forwarding Detection (BFD) for MPLS 1159 Label Switched Paths (LSPs)", RFC 5884, June 2010. 1161 [BFD-VCCV] Nadeau, T., Pignataro, C., "Bidirectional Forwarding 1162 Detection (BFD) for the Pseudowire Virtual Circuit 1163 Connectivity Verification (VCCV)", RFC 5885, June 1164 2010. 1166 [TP-OAM-FW] Busi, I., Allan, D., "Operations, Administration and 1167 Maintenance Framework for MPLS-based Transport 1168 Networks ", RFC 6371, September 2011. 1170 [MPLS-TP-CC-CV] Allan, D., Swallow, G., Drake, J., "Proactive 1171 Connectivity Verification, Continuity Check and Remote 1172 Defect indication for MPLS Transport Profile", RFC 1173 6428, November 2011. 1175 [OnDemand-CV] Gray, E., Bahadur, N., Boutros, S., Aggarwal, R. "MPLS 1176 On-Demand Connectivity Verification and Route 1177 Tracing", RFC 6426, November 2011. 1179 [MPLS-LM-DM] Frost, D., Bryant, S., "Packet Loss and Delay 1180 Measurement for MPLS Networks", RFC 6374, September 1181 2011. 1183 [TP-LM-DM] Frost, D., Bryant, S., "A Packet Loss and Delay 1184 Measurement Profile for MPLS-Based Transport 1185 Networks", RFC 6375, September 2011. 1187 [MPLS-TP-Fault] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, 1188 S., "MPLS Fault Management Operations, Administration, 1189 and Maintenance (OAM)", RFC 6427, November 2011. 1191 [TP-Lock-Loop] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, 1192 M., Dai, X., "MPLS Transport Profile Lock Instruct and 1193 Loopback Functions", RFC 6435, November 2011. 1195 7.2. Informative References 1197 [OAM-Def] Andersson, L., Van Helvoort, H., Bonica, R., Romascanu, 1198 D., Mansfield, S., "Guidelines for the use of the OAM 1199 acronym in the IETF ", RFC 6291, June 2011. 1201 [OAM-Analysis]Sprecher, N., Fang, L., "An Overview of the OAM Tool 1202 Set for MPLS based Transport Networks", RFC 6669, 1203 July 2012. 1205 [MPLS-TP-Term]Van Helvoort, H., Andersson, L., Sprecher, N., "A 1206 Thesaurus for the Terminology used in Multiprotocol 1207 Label Switching Transport Profile (MPLS-TP) 1208 drafts/RFCs and ITU-T's Transport Network 1209 Recommendations", work-in-progress, draft-ietf-mpls- 1210 tp-rosetta-stone, January 2012. 1212 [IEEE-802.1ag]"Connectivity Fault Management", December 2007. 1214 [ITU-T-Y.1731]"OAM Functions and Mechanisms for Ethernet-based 1215 Networks", February 2008. 1217 [ITU-T-Y.1711]"Operation & Maintenance mechanism for MPLS networks", 1218 February 2004. 1220 [IEEE-802.3ah]"Media Access Control Parameters, Physical Layers, and 1221 Management Parameters for Subscriber Access Networks", 1222 clause 57, September 2004. 1224 [ITU-T-G.806] "Characteristics of transport equipment - Description 1225 methodology and generic functionality", January, 2009. 1227 Authors' Addresses 1229 Tal Mizrahi 1230 Marvell 1231 6 Hamada St. 1232 Yokneam, 20692 1233 Israel 1235 Email: talmi@marvell.com 1237 Nurit Sprecher 1238 Nokia Siemens Networks 1239 3 Hanagar St. Neve Ne'eman B 1240 Hod Hasharon, 45241 1241 Israel 1243 Email: nurit.sprecher@nsn.com 1245 Elisa Bellagamba 1246 Ericsson 1247 6 Farogatan St. 1248 Stockholm, 164 40 1249 Sweden 1251 Phone: +46 761440785 1252 Email: elisa.bellagamba@ericsson.com 1254 Yaacov Weingarten 1255 34 Hagefen St. 1256 Karnei Shomron, 4485500 1257 Israel 1259 Email: wyaacov@gmail.com