idnits 2.17.1 draft-ietf-opsawg-oam-overview-04.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 48 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 29, 2011) is 4771 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ITU-T Y.1731' is mentioned on line 1150, but not defined == Missing Reference: 'ITU-T Y.1711' is mentioned on line 801, but not defined == Missing Reference: 'PW ACH' is mentioned on line 679, but not defined == Missing Reference: 'RFC2679' is mentioned on line 709, but not defined ** Obsolete undefined reference: RFC 2679 (Obsoleted by RFC 7679) == Missing Reference: 'RFC 2681' is mentioned on line 709, but not defined == Missing Reference: 'RFC2681' is mentioned on line 710, but not defined == Unused Reference: 'IPPM 1DM' is defined on line 1436, but no explicit reference was found in the text == Unused Reference: 'IPPM 1LM' is defined on line 1439, but no explicit reference was found in the text == Unused Reference: 'IPPM 2DM' is defined on line 1443, but no explicit reference was found in the text ** 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: 4 errors (**), 0 flaws (~~), 11 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: September 2011 Nokia Siemens Networks 5 E. Bellagamba 6 Ericsson 7 Y. Weingarten 8 Nokia Siemens Networks 9 March 29, 2011 11 An Overview of 12 Operations, Administration, and Maintenance (OAM) Mechanisms 13 draft-ietf-opsawg-oam-overview-04.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 29, 2011. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Abstract 55 Operations, Administration, and Maintenance (OAM) is a general term 56 that refers to a toolset that can be used for fault detection and 57 localization, and for performance measurement. OAM mechanisms have 58 been defined for various layers in the protocol stack, and are used 59 with a variety of protocols. 61 This document presents an overview of the OAM mechanisms that have 62 been defined and are currently being defined by the IETF, as well as 63 a comparison to other OAM mechanisms that have been defined by the 64 IEEE and ITU-T. 66 Table of Contents 68 1. Introduction................................................4 69 2. Conventions used in this document............................8 70 3. Basic Terminology...........................................8 71 3.1. Abbreviations..........................................8 72 3.2. Terminology used in OAM Standards.......................9 73 3.2.1. General Terms......................................9 74 3.2.2. OAM Maintenance Entities and Communication Links...10 75 3.2.3. OAM Maintenance Points............................10 76 3.2.4. Connectivity Verification and Continuity Checks....11 77 3.2.5. Link Failures.....................................11 78 3.2.6. Summary of OAM Terms used in the Standards.........12 79 4. OAM Functions..............................................13 80 4.1. ICMP Ping.............................................13 81 4.2. Bidirectional Forwarding Detection (BFD)...............14 82 4.2.1. Overview.........................................14 83 4.2.2. BFD Control.......................................14 84 4.2.3. BFD Echo.........................................15 85 4.3. LSP Ping..............................................15 86 4.4. PWE3 Virtual Circuit Connectivity Verification (VCCV)...16 87 4.5. IP Performance Metrics (IPPM)..........................16 88 4.5.1. Overview.........................................16 89 4.5.2. Control and Test Protocols........................17 90 4.5.3. OWAMP............................................17 91 4.5.4. TWAMP............................................18 92 4.6. ITU-T Y.1711..........................................18 93 4.6.1. Overview.........................................18 94 4.6.2. Connectivity Verification (CV)....................19 95 4.6.3. Fast Failure Detection (FFD)......................19 96 4.6.4. Forward Defect Indication (FDI)...................19 97 4.6.5. Backward Defect Indication (BDI)..................20 98 4.7. ITU-T Y.1731..........................................20 99 4.7.1. Overview.........................................20 100 4.7.2. ETH-CC...........................................20 101 4.7.3. ETH-LB...........................................21 102 4.7.4. ETH-TST..........................................21 103 4.7.5. ETH-LT...........................................21 104 4.7.6. ETH-AIS..........................................21 105 4.7.7. ETH-LCK..........................................21 106 4.7.8. ETH-RDI..........................................22 107 4.7.9. ETH-APS..........................................22 108 4.7.10. ETH-LM..........................................22 109 4.7.11. ETH-DM..........................................22 110 4.8. IEEE 802.1ag..........................................23 111 4.8.1. Overview.........................................23 112 4.8.2. Continuity Check..................................23 113 4.8.3. Loopback.........................................23 114 4.8.4. Linktrace........................................24 115 4.9. IEEE 802.3ah..........................................24 116 4.9.1. Overview.........................................24 117 4.9.2. Remote Failure Indication.........................24 118 4.9.3. Remote Loopback...................................24 119 4.9.4. Link Monitoring...................................24 120 4.10. MPLS-TP OAM..........................................24 121 4.10.1. Overview........................................24 122 4.10.2. Generic Associated Channel.......................25 123 4.10.3. MPLS-TP OAM Toolset..............................25 124 4.10.3.1. Continuity Check and Connectivity Verification26 125 4.10.3.2. Diagnostic Tests............................26 126 4.10.3.3. Route Tracing...............................26 127 4.10.3.4. Lock Instruct...............................27 128 4.10.3.5. Lock Reporting..............................27 129 4.10.3.6. Alarm Reporting.............................27 130 4.10.3.7. Remote Defect Indication....................27 131 4.10.3.8. Client Failure Indication...................27 132 4.10.3.9. Packet Loss Measurement.....................27 133 4.10.3.10. Packet Delay Measurement...................28 134 4.11. Summary of OAM Functions..............................28 135 4.12. Summary of Continuity Check Mechanisms................30 136 5. Security Considerations.....................................31 137 6. IANA Considerations........................................31 138 7. Acknowledgments............................................31 139 8. References.................................................31 140 8.1. Normative References...................................31 141 8.2. Informative References.................................33 143 1. Introduction 145 OAM is a general term that refers to a toolset that can be used for 146 detecting, isolating and reporting connection failures or measurement 147 of connection performance parameters. The term OAM has been used over 148 the years in several different contexts, as discussed in [OAM Soup]. 149 In the context of this document OAM refers to Operations, 150 Administration, and Maintenance, i.e., this document refers to OAM in 151 the context of monitoring communication entities, e.g., nodes, paths, 152 physical links, or logical links. Other aspects associated with the 153 OAM acronym, such as management, are outside the scope of this 154 document. 156 OAM was originally used in the world of telephony, and has been 157 adopted in packet based networks. OAM mechanisms are used in various 158 layers in the protocol stack, and are applied to a variety of 159 different protocols. 161 The IETF has defined OAM for several protocols, and is currently 162 working on defining several new OAM protocols. A summary of these 163 protocols, old and new, is listed below: 165 o MPLS LSP Ping, as defined in [LSP Ping] is an OAM mechanism for 166 point to point MPLS LSPs. The IETF is currently working on an 167 extension to the LSP Ping for point to multipoint MPLS - [P2MP 168 Ping]. 170 o Virtual Circuit Connectivity Check (VCCV) for Pseudowires, as 171 defined in [VCCV]. 173 o ICMP Echo request, also known as Ping, as defined in [ICMPv4], and 174 [ICMPv6]. ICMP Ping is a very simple and basic mechanism in 175 failure diagnosis, and is not traditionally associated with OAM, 176 but it is presented in this document for the sake of completeness, 177 since both LSP Ping and VCCV are to some extent based on ICMP 178 Ping. 180 o Bidirectional Forwarding Detection (BFD) is defined in [BFD] as a 181 framework for a lightweight generic OAM mechanism. The intention 182 is to define a base mechanism that can be used with various 183 encapsulation types, network environments, and in various medium 184 types. 186 o The OAM requirements for MPLS Transport Profile (MPLS-TP) are 187 defined in [MPLS-TP OAM], and the toolset is described in [MPLS-TP 188 OAM FW]. The OAM toolset for MPLS-TP is currently being defined in 189 the MPLS working group. 191 o IP Performance Metrics (IPPM) is a working group in the IETF that 192 defined common metrics for performance measurement, as well as a 193 protocol for measuring delay and packet loss in IP networks. 194 Alternative protocols for performance measurement are defined, for 195 example, in MPLS-TP OAM [MPLS-TP OAM], and in Ethernet OAM [ITU-T 196 Y.1731]. 198 In addition to the OAM mechanisms defined by the IETF, the IEEE and 199 ITU-T have also defined various OAM mechanisms. These various 200 mechanisms defined by the three standard organizations are often 201 tightly coupled, and have had a mutual effect on each other. The ITU- 202 T and IETF have both defined OAM mechanisms for MPLS LSPs, [ITU-T 203 Y.1711] and [LSP Ping]. The following OAM standards by the IEEE and 204 ITU-T are to some extent linked to IETF OAM mechanisms listed above, 205 and are also discussed in this document: 207 o OAM mechanisms for Ethernet based networks have been defined by 208 both the ITU-T in [ITU-T Y.1731], and by the IEEE in [IEEE 209 802.1ag]. The IEEE 802.3 standard defines OAM for one-hop Ethernet 210 links [IEEE 802.3ah]. 212 o The ITU-T has defined OAM for MPLS LSPs in [ITU-T Y.1711]. 214 This document summarizes the OAM mechanisms defined in the standards 215 above. The focus is on OAM mechanisms defined by the IETF. These 216 mechanisms will be compared with the relevant OAM mechanisms defined 217 by the ITU-T and IEEE, where applicable. We first present a 218 comparison of the terminology used in various OAM standards, and then 219 summarize the OAM functions that each OAM standard provides. 221 Table 1 summarizes the OAM standards discussed in this document. 223 +-----------+--------------------------------------+---------------+ 224 | | Title |Standard/Draft | 225 +-----------+--------------------------------------+---------------+ 226 |ICMPv4 Ping| Internet Control Message Protocol | RFC 792 | 227 | | | | 228 +-----------+--------------------------------------+---------------+ 229 |ICMPv6 Ping| Internet Control Message Protocol | RFC 4443 | 230 | | (ICMPv6) for the Internet Protocol | | 231 | | Version 6 (IPv6) Specification | | 232 +-----------+--------------------------------------+---------------+ 233 |BFD | Bidirectional Forwarding Detection | RFC 5880 | 234 | +--------------------------------------+---------------+ 235 | | Bidirectional Forwarding Detection | RFC 5881 | 236 | | (BFD) for IPv4 and IPv6 (Single Hop) | | 237 | +--------------------------------------+---------------+ 238 | | Generic Application of Bidirectional | RFC 5882 | 239 | | Forwarding Detection | | 240 | +--------------------------------------+---------------+ 241 | | Bidirectional Forwarding Detection | RFC 5883 | 242 | | (BFD) for Multihop Paths | | 243 | +--------------------------------------+---------------+ 244 | | Bidirectional Forwarding Detection | RFC 5884 | 245 | | for MPLS Label Switched Paths (LSPs) | | 246 | +--------------------------------------+---------------+ 247 | | Bidirectional Forwarding Detection | RFC 5885 | 248 | | for the Pseudowire Virtual Circuit | | 249 | | Connectivity Verification (VCCV) | | 250 +-----------+--------------------------------------+---------------+ 251 |IETF MPLS | Operations and Management (OAM) | RFC 4377 | 252 |OAM | Requirements for Multi-Protocol Label| | 253 |(LSP Ping) | Switched (MPLS) Networks | | 254 | +--------------------------------------+---------------+ 255 | | A Framework for Multi-Protocol | RFC 4378 | 256 | | Label Switching (MPLS) Operations | | 257 | | and Management (OAM) | | 258 | +--------------------------------------+---------------+ 259 | | Detecting Multi-Protocol Label | RFC 4379 | 260 | | Switched (MPLS) Data Plane Failures | | 261 | +--------------------------------------+---------------+ 262 | | Operations and Management (OAM) | RFC 4687 | 263 | | Requirements for Point-to-Multipoint | | 264 | | MPLS Networks | | 265 +-----------+--------------------------------------+---------------+ 266 |MPLS-TP | Requirements for OAM in MPLS-TP | RFC 5860 | 267 |OAM +--------------------------------------+---------------+ 268 | | MPLS Generic Associated Channel | RFC 5586 | 269 | +--------------------------------------+---------------+ 270 | | MPLS-TP OAM Framework |[MPLS-TP OAM FW| 271 | | |] - work in | 272 | | |progress | 273 | +--------------------------------------+---------------+ 274 | | MPLS-TP OAM Analysis |[OAM Analysis] | 275 | | | - work in | 276 | | |progress | 277 +-----------+--------------------------------------+---------------+ 278 |PW VCCV | Pseudowire Virtual Circuit | RFC 5085 | 279 | | Connectivity Verification (VCCV): | | 280 | | A Control Channel for Pseudowires | | 281 +-----------+--------------------------------------+---------------+ 282 |IPPM | Framework for IP Performance Metrics | RFC 2330 | 283 | +--------------------------------------+---------------+ 284 | | IPPM Metrics for Measuring | RFC 2678 | 285 | | Connectivity | | 286 | +--------------------------------------+---------------+ 287 | | A One-way Delay Metric for IPPM | RFC 2679 | 288 | +--------------------------------------+---------------+ 289 | | A One-way Packet Loss Metric for IPPM| RFC 2680 | 290 | +--------------------------------------+---------------+ 291 | | A Round-trip Delay Metric for IPPM | RFC 2681 | 292 | +--------------------------------------+---------------+ 293 | | A One-way Active Measurement Protocol| RFC 4656 | 294 | | (OWAMP) | | 295 | +--------------------------------------+---------------+ 296 | | A Two-Way Active Measurement Protocol| RFC 5357 | 297 | | (TWAMP) | | 298 +-----------+--------------------------------------+---------------+ 299 |ITU-T | Operation & Maintenance mechanism |[ITU-T Y.1711] | 300 |MPLS OAM | for MPLS networks | | 301 | +--------------------------------------+---------------+ 302 | | Assignment of the 'OAM Alert Label' | RFC 3429 | 303 | | for Multiprotocol Label Switching | | 304 | | Architecture (MPLS) Operation and | | 305 | | Maintenance (OAM) Functions | | 306 +-----------+--------------------------------------+---------------+ 307 |ITU-T | OAM Functions and Mechanisms for |[ITU-T Y.1731] | 308 |Ethernet | Ethernet-based Networks | | 309 |OAM | | | 310 +-----------+--------------------------------------+---------------+ 311 |IEEE | Connectivity Fault Management |[IEEE 802.1ag] | 312 |CFM | | | 313 +-----------+--------------------------------------+---------------+ 314 |IEEE | Media Access Control Parameters, |[IEEE 802.3ah] | 315 |802.3 | Physical Layers, and Management | | 316 |link level | Parameters for Subscriber Access | | 317 |OAM | Networks | | 318 +-----------+--------------------------------------+---------------+ 319 Table 1 Summary of OAM Standards 321 2. Conventions used in this document 323 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 324 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 325 document are to be interpreted as described in [KEYWORDS]. 327 3. Basic Terminology 329 3.1. Abbreviations 331 AIS Alarm Indication Signal 333 APS Automatic Protection Switching 335 BDI Backward Defect Indication 337 BFD Bidirectional Forwarding Detection 339 CC Continuity Check 341 CCM Continuity Check Message 343 CV Connectivity Verification 345 DM Delay Measurement 347 DTE Data Terminal Equipment 349 FDI Forward Defect Indication 351 FFD Fast Failure Detection 353 ICMP Internet Control Message Protocol 355 L2TP Layer Two Tunneling Protocol 357 LCCE L2TP Control Connection Endpoint 358 LM Loss Measurement 360 LSP Label Switching Path 362 LSR Label Switching Router 364 MA Maintenance Association 366 ME Maintenance Entity 368 MEG Maintenance Entity Group 370 MEP Maintenance End Point 372 MHF MIP Half Function 374 MIP Maintenance Intermediate Point 376 MP Maintenance Point 378 MPLS Multiprotocol Label Switching 380 MPLS-TP MPLS Transport Profile 382 OAM Operations, Administration, and Maintenance 384 PE Provider Edge 386 PW Pseudowire 388 PWE3 Pseudowire Emulation Edge-to-Edge 390 RDI Remote Defect Indication 392 TTL Time To Live 394 TTSI Trail Termination Source Identifier 396 VCCV Virtual Circuit Connectivity Verification 398 3.2. Terminology used in OAM Standards 400 3.2.1. General Terms 402 A wide variety of terms is used in various OAM standards. Each of the 403 OAM standards listed in the reference section includes a section that 404 defines the relevant terms. A thesaurus of terminology for MPLS-TP 405 terms is presented in [MPLS-TP Term], and provides a good summary of 406 some of the OAM related terminology. 408 This section presents a comparison of the terms used in various OAM 409 standards, without fully quoting the definition of each term. For a 410 formal definition of each term, refer to the references at the end of 411 this document. The comparison focuses on three basic terms, and is 412 summarized in section 3 ..2.6. 414 3.2.2. OAM Maintenance Entities and Communication Links 416 A Maintenance Entity (ME) is a point-to-point relationship between 417 two Maintenance Points (MP). The connectivity between these 418 Maintenance Points is managed and monitored by the OAM protocol. 420 A pair of MPs engaged in an ME are connected by a communication Link. 421 The term "Link" in this context is a generic term that may refer to 422 one of several types of connection, e.g. a single physical 423 connection, a set of physical connections, or a virtual link such as 424 an MPLS LSP. The term Link is used throughout this document to refer 425 to the connection between the MPs that is monitored by an OAM 426 protocol. 428 The term Maintenance Entity (ME) is defined in ITU-T standards (e.g. 429 [ITU-T Y.1731]). Various terms are used to refer to an ME. For 430 example, in MPLS LSP Ping ([LSP Ping]) terminology, an ME is simply 431 referred to as an LSP. BFD does not explicitly use a term that is 432 equivalent to ME, but rather uses the term "session", referring to 433 the relationship between two nodes using a BFD protocol. 435 MPLS-TP has defined the terms ME and Maintenance Entity Group (MEG) 436 in [MPLS-TP OAM FW], similar to the terms defined by ITU-T. 438 3.2.3. OAM Maintenance Points 440 A Maintenance Point (MP) is a functional entity that is defined at a 441 node in the network, and either initiates or reacts to OAM messages. 442 A Maintenance End Point (MEP) is one of the end points of an ME, and 443 can initiate OAM messages and respond to them. A Maintenance 444 Intermediate Point (MIP) is an intermediate point between two MEPs, 445 that does not initiate OAM frames, but is able to respond to OAM 446 frames that are destined to it, and to forward others. 448 The terms MEP and MIP are defined in ITU-T standards (e.g. [ITU-T 449 Y.1731]). The term Maintenance Point is a general term for MEPs and 450 MIPs, and is used in [IEEE 802.1ag]. 452 The 802.1ag defines a finer distinction between Up MPs and Down MPs. 453 An MP is a bridge interface, that is monitored by an OAM protocol 454 either in the direction facing the network, or in the direction 455 facing the bridge. A Down MP is an MP that receives OAM packets from, 456 and transmits them to the direction of the network. An Up MP receives 457 OAM packets from, and transmits them to the direction of the bridging 458 entity. 460 MPLS-TP has defined the terms MEP and MIP and their functional 461 characteristics in [MPLS-TP OAM FW], similar to the terms defined by 462 ITU-T. 464 3.2.4. Connectivity Verification and Continuity Checks 466 Two distinct classes of failure management functions are used in OAM 467 protocols, connectivity verification and continuity checks. The 468 distinction between these terms is defined in [MPLS-TP OAM], and is 469 used similarly in this document. 471 Continuity checks are used to verify the liveness of a link, and are 472 typically sent proactively, though they can be invoked on-demand as 473 well. 475 A connectivity verification function allows an MP to check whether it 476 is connected to a peer MP or not. A connectivity verification (CV) 477 protocol typically uses a CV message, followed by a CV reply that is 478 sent back to the originator. A CV function can be applied proactively 479 or on-demand. 481 Connectivity verification and continuity checks are considered 482 complementary mechanisms, and are often used in conjunction with each 483 other. 485 3.2.5. Link Failures 487 The terms Failure, Fault, and Defect are intermittently used in the 488 standards, referring to a malfunction that can be detected by a 489 connectivity or a continuity check. In some standards, such as [IEEE 490 802.1ag], there is no distinction between these terms, while in other 491 standards each of these terms refers to a different type of 492 malfunction. 494 The ITU-T distinguishes between these terms in [ITU-T G.806]. The 495 term Fault refers to an inability to perform a required action, e.g., 496 an unsuccessful attempt to deliver a packet. The term Defect refers 497 to an interruption in the normal operation, such as a consecutive 498 period of time where no packets are delivered successfully. The term 499 Failure refers to the termination of the required function. While a 500 Defect typically refers to a limited period of time, a failure refers 501 to a long period of time. 503 3.2.6. Summary of OAM Terms used in the Standards 505 Table 2 provides a comparison of the terminology used in different 506 OAM standards. 508 +-----------+-------------+-----------+----------------------------+ 509 | |Maintenance |Maintenance|Link Failure Terminology | 510 | |Point |Entity | | 511 | |Terminology |Terminology| | 512 +-----------+-------------+-----------+----------------------------+ 513 |ICMPv4 Ping|-Host | | | 514 | |-Gateway | | | 515 + --------- + ----------- + --------- + -------------------------- + 516 |ICMPv6 Ping| Node | | | 517 + --------- + ----------- + --------- + -------------------------- + 518 |BFD | System | Session |-Failure | 519 | | | |-Session is declared down | 520 + --------- + ----------- + --------- + -------------------------- + 521 |LSP Ping | LSR | LSP |-Failure | 522 | | | |-Fault = typically a local | 523 | | | | isolated failure | 524 + --------- + ----------- + --------- + -------------------------- + 525 |PW VCCV |-PE | PW |-Failure | 526 | |-LCCE | |-Fault | 527 + --------- + ----------- + --------- + -------------------------- + 528 |IPPM |-Host |-Path | Connectivity is indicated | 529 | |-End system |-Measuremen| by a Boolean value. Thus, | 530 | | | t session | a failure is referred to as| 531 | | | | a path with a measurement | 532 | | | | value "false". | 533 + --------- + ----------- + --------- + -------------------------- + 534 |ITU-T | LSR | LSP |-Fault, Defect, Failure: as | 535 |Y.1711 | | | defined in [ITU-T G.806] | 536 + --------- + ----------- + --------- + -------------------------- + 537 |ITU-T |-MEP | ME |-Fault, Defect, Failure: as | 538 |Y.1731 |-MIP | | defined in [ITU-T G.806] | 539 | | | | | 540 + --------- + ----------- + --------- + -------------------------- + 541 |MPLS-TP |-End Point, |-LSP |-Fault, Defect, Failure: as | 542 |OAM | MEP |-PW | defined in [ITU-T G.806] | 543 | |-Intermediate|-Section | | 544 | | Point, MIP | | | 545 + --------- + ----------- + --------- + -------------------------- + 546 |IEEE |-MP (Down,Up)| ME |-Failure | 547 |802.1ag | -MEP | |-Fault | 548 | | -MIP | |-Defect | 549 | | -MHF | | | 550 + --------- + ----------- + --------- + -------------------------- + 551 |IEEE | DTE | Link |-Failure | 552 |802.3ah | | |-Fault | 553 +-----------+-------------+-----------+----------------------------+ 554 Table 2 Summary of OAM Terms 556 4. OAM Functions 558 4.1. ICMP Ping 560 ICMP provides a connectivity verification function for the Internet 561 Protocol. The originator transmits an echo request packet, and the 562 receiver replies with an echo reply. ICMP ping is defined in two 563 variants, [ICMPv4] is used for IPv4, and [ICMPv6] is used for IPv6. 565 ICMP is also used in Traceroute for path discovery. Traceroute allows 566 a host to detect the path to a destination host, as follows: 568 o The originator host repeatedly transmits an ICMP message to the 569 destination host. At first, the value of the Time To Live (TTL) 570 field in the ICMP message is 1, and is then repeatedly incremented 571 by 1. 573 o In turn, each router on the traversing path returns an ICMP 574 message to the originator with an ICMP Time Exceeded error 575 message. 577 o Finally, the destination router replies with an ICMP Echo Reply. 579 4.2. Bidirectional Forwarding Detection (BFD) 581 4.2.1. Overview 583 While multiple OAM mechanisms have been defined for various protocols 584 in the protocol stack, Bidirectional Forwarding Detection [BFD], 585 defined by the IETF BFD working group, is a generic OAM mechanism 586 that can be deployed over various encapsulating protocols, and in 587 various medium types. The IETF has defined variants of the protocol 588 for IP ([BFD IP], [BFD Multi]), for MPLS LSPs [BFD LSP], and for PWE3 589 [BFD VCCV]. BFD for MPLS-TP is currently evolving in the MPLS working 590 group (e.g. [MPLS-TP Ping BFD]). 592 BFD includes two main OAM functions, using two types of BFD packets: 593 BFD Control packets, and BFD Echo packets. 595 4.2.2. BFD Control 597 BFD supports a bidirectional continuity check, using BFD control 598 packets, that are exchanged within a BFD session. BFD sessions 599 operate in one of two modes: 601 o Asynchronous mode: in this mode BFD control packets are sent 602 periodically. When the receiver detects that no BFD control packet 603 have been received during a predetermined period of time, a 604 failure is detected. 606 o Demand mode: in this mode, BFD control packets are sent on-demand. 607 Upon need, a system initiates a series of BFD control packets to 608 verify the link. BFD control packets are sent independently in 609 each direction of the link. 611 Each of the end-points of the monitored path maintains its own 612 session identification, called a Discriminator, both of which are 613 included in the BFD Control Packets that are exchanged between the 614 end-points. At the time of session establishment, the Discriminators 615 are exchanged between the two-end points. In addition, the 616 transmission (and reception) rate is negotiated between the two end- 617 points, based on information included in the control packets. These 618 transmission rates may be renegotiated during the session. 620 During normal operation of the session, i.e. no failures are 621 detected, the BFD session is in the Up state. If no BFD Control 622 packets are received during a fixed period of time, called the 623 Detection Time, the session is declared to be Down. The detection 624 time is a function of the negotiated transmission time, and a 625 parameter called Detect Mult. Detect Mult determines the number of 626 missing BFD Control packets that cause the session to be declared as 627 Down. This parameter is included in the BFD Control packet. 629 4.2.3. BFD Echo 631 The echo function is used for connectivity verification. A BFD echo 632 packet is sent to a peer system, and is looped back to the 633 originator. The echo function can be used proactively, or on-demand. 635 4.3. LSP Ping 637 The IETF MPLS working group has defined OAM for MPLS LSPs. The 638 requirements and framework of this effort was defined in [MPLS OAM 639 FW] and [MPLS OAM], respectively. The corresponding OAM mechanism 640 defined, in this context, is LSP Ping [LSP Ping]. 642 LSP Ping is based on ICMP Ping and just like its predecessor may be 643 used in one of two modes: 645 o "Ping" mode: In this mode LSP ping is used for end-to-end 646 connectivity verification between two LSRs. 648 o "Traceroute" mode: This mode is used for hop-by-hop fault 649 localization. 651 LSP Ping extends the basic ICMP Ping operation (of data-plane 652 connectivity and continuity check) with functionality to verify 653 data-plane vs. control-plane consistency for a Forwarding Equivalence 654 Class (FEC) and also Maximum Transmission Unit (MTU) problems. The 655 traceroute functionality may be used to isolate and localize the MPLS 656 faults, using the Time-to-live (TTL) indicator to incrementally 657 identify the sub-path of the LSP that is successfully traversed 658 before the faulty link or node. 660 It should be noted that LSP Ping does support unique identification 661 of the LSP within an addressing domain. The identification is checked 662 using the full FEC identification. LSP Ping is easily extensible to 663 include additional information needed to support new functionality, 664 by use of Type-Length-Value (TLV) constructs. The usage of TLVs is 665 typically not easy to perform in hardware, and is thus typically 666 handled by the control plane. 668 LSP Ping supports both asynchronous, as well as, on-demand 669 activation. In addition, extensions for LSP Ping are being defined 670 for point-to-multipoint LSPs in [P2MP LSP Ping] and for MPLS Tunnels 671 in [MPLS LSP Ping]. 673 4.4. PWE3 Virtual Circuit Connectivity Verification (VCCV) 675 VCCV, as defined in [VCCV], provides end-to-end fault detection 676 and diagnostics for PWs (regardless of the underlying tunneling 677 technology). The VCCV switching function provides a control channel 678 associated with each PW (based on the PW Associated Channel Header 679 (ACH) which is defined in [PW ACH]), and allows sending OAM packets 680 in-band with PW data (using CC Type 1: In-band VCCV). 682 VCCV currently supports the following OAM mechanisms: ICMP Ping, LSP 683 Ping, and BFD. ICMP and LSP Ping are IP encapsulated before being 684 sent over the PW ACH. BFD for VCCV supports two modes of 685 encapsulation - either IP/UDP encapsulated (with IP/UDP header) or 686 PW-ACH encapsulated (with no IP/UDP header) and provides support to 687 signal the AC status. The use of the VCCV control channel provides 688 the context, based on the MPLS-PW label, required to bind and 689 bootstrap the BFD session to a particular pseudo wire (FEC), 690 eliminating the need to exchange Discriminator values. 692 VCCV consists of two components: (1) signaled component to 693 communicate VCCV capabilities as part of VC label, and (2) switching 694 component to cause the PW payload to be treated as a control packet. 696 VCCV is not directly dependent upon the presence of a control plane. 697 The VCCV capability negotiation may be performed as part of the PW 698 signaling when LDP is used. In case of manual configuration of the 699 PW, it is the responsibility of the operator to set consistent 700 options at both ends. 702 4.5. IP Performance Metrics (IPPM) 704 4.5.1. Overview 706 The IPPM working group [IPPM FW] in the IETF defines common criteria 707 and metrics for measuring performance of IP traffic. Some of the key 708 RFCs published by this working group have defined metrics for 709 measuring connectivity [rfc2678], delay [RFC2679, RFC 2681], and 710 packet loss [RFC2681]. 712 The IPPM working group has defined not only metrics for performance 713 measurement, but also protocols that define how the measurement is 714 carried out. The One-way Active Measurement Protocol [OWAMP] and the 715 Two-Way Active Measurement Protocol [TWAMP] define a method and 716 protocol for measuring delay and packet loss in IP networks. 718 OWAMP [OWAMP] enables measurement of one-way characteristics of IP 719 networks, such as one-way packet loss and one-way delay. For its 720 proper operation OWAMP requires accurate time of day setting at its 721 end points. 723 TWAMP [TWAMP] is a similar protocol that enables measurement of two- 724 way (round trip) characteristics. TWAMP does not require accurate 725 time of day, and, furthermore, allows the use of a simple session 726 reflector, making it an attractive alternative to OWAMP. 728 OWAMP and TWAMP use two separate protocols: a Control plane protocol, 729 and a Test plane protocol. 731 4.5.2. Control and Test Protocols 733 OWAMP and TWAMP control protocols run over TCP, while the test 734 protocols run over UDP. The purpose of the control protocols is to 735 initiate, start, and stop test sessions, and for OWAMP to fetch 736 results. The test protocols introduce test packets (which contain 737 sequence numbers and timestamps) along the IP path under test 738 according to a schedule, and record statistics of packet arrival. 739 Multiple sessions may be simultaneously defined, each with a session 740 identifier, and defining the number of packets to be sent, the amount 741 of padding to be added (and thus the packet size), the start time, 742 and the send schedule (which can be either a constant time between 743 test packets or exponentially distributed pseudo-random). Statistics 744 recorded conform to the relevant IPPM RFCs. 746 OWAMP and TWAMP test traffic is designed with security in mind. Test 747 packets are hard to detect because they are simply UDP streams 748 between negotiated port numbers, with potentially nothing static in 749 the packets. OWAMP and TWAMP also include optional authentication 750 and encryption for both control and test packets. 752 4.5.3. OWAMP 754 OWAMP defines the following logical roles: Session-Sender, Session- 755 Receiver, Server, Control-Client, and Fetch-Client. The Session- 756 Sender originates test traffic that is received by the Session- 757 Receiver. The Server configures and manages the session, as well as 758 returning the results. The Control-Client initiates requests for 759 test sessions, triggers their start, and may trigger their 760 termination. The Fetch-Client requests the results of a completed 761 session. Multiple roles may be combined in a single host - for 762 example, one host may play the roles of Control-Client, Fetch-Client, 763 and Session-Sender, and a second playing the roles of Server and 764 Session-Receiver. 766 In a typical OWAMP session the Control-Client establishes a TCP 767 connection to port 861 of the Server, which responds with a server 768 greeting message indicating supported security/integrity modes. The 769 Control-Client responds with the chosen communications mode and the 770 Server accepts the modes. The Control-Client then requests and fully 771 describes a test session to which the Server responds with its 772 acceptance and supporting information. More than one test session 773 may be requested with additional messages. The Control-Client then 774 starts a test session and the Server acknowledges. The Session- 775 Sender then sends test packets with pseudorandom padding to the 776 Session-Receiver until the session is complete or until the Control- 777 client stops the session. Once finished, the Fetch-Client sends a 778 fetch request to the server, which responds with an acknowledgement 779 and immediately thereafter the result data. 781 4.5.4. TWAMP 783 TWAMP defines the following logical roles: session-sender, session- 784 reflector, server, and control-client. These are similar to the 785 OWAMP roles, except that the Session-Reflector does not collect any 786 packet information, and there is no need for a Fetch-Client. 788 In a typical TWAMP session the Control-Client establishes a TCP 789 connection to port 862 of the Server, and mode is negotiated as in 790 OWAMP. The Control-Client then requests sessions and starts them. 791 The Session-Sender sends test packets with pseudorandom padding to 792 the Session-Reflector which returns them with insertion of 793 timestamps. 795 4.6. ITU-T Y.1711 797 4.6.1. Overview 799 As mentioned above (4.3.), the IETF defined LSP Ping as an OAM 800 mechanism for MPLS. The ITU-T has also defined an OAM protocol for 801 MPLS, defined in recommendation [ITU-T Y.1711]. This recommendation 802 defines mechanisms for connectivity verification and fast failure 803 detection, as well as mechanism for reporting defects that have been 804 identified in an LSP. 806 MPLS OAM packets per Y.1711 are detected by a reserved MPLS label 807 value. The reserved value is 14, and is defined in [OAM Label] as the 808 'OAM Alert Label'. 810 4.6.2. Connectivity Verification (CV) 812 The CV function is used to detect connectivity defects in an LSP. CV 813 frames are sent proactively at a rate of 1 per second. Each frame 814 contains the Trail-Termination Source Identifier (TTSI), indicating 815 the identity of the transmitting LSR. 817 The CV function can detect any of the following defect conditions. 819 o Loss of Connectivity Verification (LOCV): A loss of connectivity 820 is detected when no CV OAM packets are received in a period of 3 821 consecutive transmission periods. 822 It should be noted that the LOCV defect is in fact loss of 823 continuity when using the terminology defined in 3 ..2.4. 825 o TTSI Mismatch: A TTSI mismatch is detected when a CV frame with an 826 unexpected TTSI is received. 828 o TTSI Mismerge: A TTSI mismerge is detected when the CV frames 829 received in a given LSP contain some frame with an expected TTSI, 830 and some frames with an unexpected TTSI. 832 o Excess: An excess is detected when at least 5 CV frames are 833 received during a period of 3 consecutive transmission periods. 835 4.6.3. Fast Failure Detection (FFD) 837 The FFD function is a proactive function, used for fast detection of 838 connectivity defects. While CV is typically sufficient for path 839 failure detection and reporting, protection switching mechanisms 840 typically require faster detection. FFD is very similar to CV in 841 terms of the packet format, and the possible defect conditions, but 842 FFD allows a configurable transmission frequency. The default 843 transmission rate of FFD frames is 20 per second, i.e., every 50 ms, 844 allowing fast detection for protection switching applications. 846 4.6.4. Forward Defect Indication (FDI) 848 The FDI function is used by an LSR to report a defect to affected 849 client layers, allowing them to suppress alarms about this defect. 850 In MPLS-TP OAM this function is referred to as Client Failure 851 Indication. 853 FDI packets are sent at a rate of 1 per second. 855 4.6.5. Backward Defect Indication (BDI) 857 The BDI function is used by an LSR to inform a peer LSR about a 858 defect condition on an LSP for which they are the end points of. 859 In MPLS-TP OAM this function is referred to as Remote Defect 860 Indication. 862 BDI packets are sent at the same transmission rate as FDI. 864 4.7. ITU-T Y.1731 866 4.7.1. Overview 868 The [ITU-T Y.1731] defines a protocol for Ethernet OAM. It is 869 presented in this document as a reference point. Y.1731 defines 870 various OAM functions, including continuity and connectivity 871 verification, and functions for performance monitoring. 873 4.7.2. ETH-CC 875 The Ethernet Continuity Check function is a proactive function that 876 allows a MEP to detect loss of continuity with any of the other MEPs 877 in the MEG. This function also allows detection of other defect 878 conditions, such as unintended connectivity between two MEGs (also 879 known as a mismerge). The ETH-CC function is used for one of three 880 possible applications: fault management, performance monitoring (see 881 4.6.10.), and protection switching. 883 Continuity Check Messages (CCM) are transmitted periodically at a 884 constant rate. There are 7 possible transmission periods, from 3.33 885 ms to 10 min. When the ETH-CC function detects a defect, it reports 886 one of the following defect conditions: 888 o Loss of continuity (LOC): Occurs when at least when no CCM 889 messages have been received from a peer MEP during a period of 3.5 890 times the configured transmission period. 892 o Unexpected MEG level: The MEG level is a 3-bit number that defines 893 the level of hierarchy of the MEG. This defect condition occurs 894 when a CCM is received from a peer MEP with a MEG level that is 895 lower than the expected MEG level. 897 o Mismerge: Occurs when a CCM is received from a peer MEP with an 898 unexpected MEG ID. 900 o Unexpected MEP: Occurs when a CCM is received from a peer MEP with 901 an unexpected transmitting MEP ID. 903 o Unexpected period: Occurs when the transmission period field in 904 the CCM does not match the expected transmission period value. 906 4.7.3. ETH-LB 908 The Ethernet loopback function verifies connectivity with a peer MEP 909 or MIP. The loopback function is performed on-demand, by sending a 910 loopback message (LBM) to the peer MEP or MIP. The peer node then 911 responds with a loopback reply (LBR). 913 More precisely, it is used for one of two purposes: 915 o Bidirectional connectivity test. 917 o Bidirectional in-service / out-of-service test. The in-service 918 mode refers to a test that is run under traffic, while the out-of- 919 service test requires other traffic to be halted. 921 4.7.4. ETH-TST 923 The test function is very similar to the loopback function, but is 924 unidirectional, i.e., the ETH-TST PDUs are terminated by the receiver 925 rather than being looped back to the sender. 927 4.7.5. ETH-LT 929 The Ethernet linktrace is an on-demand function that is used for path 930 discovery to a given target, or for locating a failure in a broken 931 path. 933 4.7.6. ETH-AIS 935 The Alarm Indication Signal indicates that a MEG should suppress 936 alarms about a defect condition at a lower MEG level, i.e., since a 937 defect has occurred in a lower hierarchy in the network, it should 938 not be reported by the current node. 940 A MEP that detects a failure periodically sends AIS messages to 941 higher hierarchies. AIS messages are sent periodically at a 942 recommended rate of 1 packet per second, until the defect condition 943 is resolved. 945 4.7.7. ETH-LCK 947 The lock function is used for administrative locking. A MEP can 948 initiate administrative locking, resulting in interruption of data, 949 e.g., for out-of-service ETH-LB or ETH-TST. 951 A MEP that initiates an administrative locking notifies its peer MEPs 952 to halt all relevant traffic until administrative/diagnostic 953 condition is removed. ETH-LCK frames are used to report to higher MEG 954 levels about the lock. The LCK frame, much like an AIS frame, 955 indicates to the receiving MEP that it should suppress alarms about 956 the locked link. 958 4.7.8. ETH-RDI 960 The Remote Defect Indication allows the sender to indicate that it 961 encountered a defect conditions. The receiving MEPs are then aware 962 that there is a defect condition in the MEG. 964 4.7.9. ETH-APS 966 The Y.1731 standard defines the frame format for Automatic Protection 967 Switching frames. The protection switching operations are defined in 968 other ITU-T standards. 970 4.7.10. ETH-LM 972 The loss measurement function allows a MEP to measure the packet loss 973 rate from/to a given MEP in the MEG. Each MEP maintains counters of 974 transmitted and received in-profile packets to/from each of its peer 975 MEPs. These counters are incorporated in the ETH-LM frames, allowing 976 the MEPs to compute the packet loss rate. 978 The ETH-LM function measures the far-end loss, referring to traffic 979 FROM the MEP to its peer, as well as the near-end loss, referring to 980 traffic from the peer MEP TO the local MEP. 982 ETH-LM is performed in one of two possible modes: 984 o Single-ended LM: in this mode loss measurement is performed on- 985 demand. The initiator sends an LM message (LMM) to its peer MEP, 986 and the peer responds with an LM reply (LMR). 988 o Dual-ended LM: in this mode loss measurement is performed 989 proactively. The continuity check message (CCM) is used for 990 proactive LM. The LM counters are piggy-backed into the CCM, and 991 allow proactive loss measurement. 993 4.7.11. ETH-DM 995 The delay measurement function is an on-demand function that allows a 996 MEP to measure the frame delay and frame delay variation to a peer 997 MEP. 999 ETH-DM can be performed in one of two modes of operation: 1001 o One-way DM: in this mode, a MEP transmits a 1DM frame containing 1002 the time of its transmission, TxTimeStampf. The receiving MEP 1003 receives the 1DM frame and records the time of reception, RxTimef. 1004 The receiving MEP can then compute the one-way delay by: RxTimef - 1005 TxTimeStampf. 1007 o Two-way DM: in this mode, a MEP transmits a delay measurement 1008 message (DMM) containing its transmission time, TxTimeStampf. The 1009 peer MEP receives the DMM and responds with a delay measurement 1010 reply (DMR). Upon receiving the DMR, the initiating MEP records 1011 the time of its reception, RxTimef, and computes the round trip 1012 delay by: RxTimef - TxTimeStampf. 1014 Each MEP maintains a time-of-day clock that is used for timestamping 1015 delay measurement frames. It should be noted that in one-way DM it is 1016 implicitly assumed that the clocks of the two peer MEPs are 1017 synchronized by a time synchronization protocol. 1019 4.8. IEEE 802.1ag 1021 4.8.1. Overview 1023 While the [ITU-T Y.1731] was defined in the ITU-T, the IEEE defined 1024 the [IEEE 802.1ag] as a standard for connectivity fault management in 1025 Ethernet based networks. While the two standards are to some extent 1026 overlapping, they can also be viewed as two complementary parts of a 1027 single Ethernet OAM picture. The two standards use a common packet 1028 format. There are a few differences between the two standards in 1029 terms of terminology: the term MEG level, used in Y.1731, as referred 1030 to as Maintenance Domain level in 802.1ag; the Y.1731 standard uses 1031 the term MEG, while the 802.1ag equivalent is Maintenance Association 1032 (MA). 1034 While Y.1731 defines multiple OAM functions (see section 4.6), the 1035 802.1ag standard focuses on three main OAM functions: continuity 1036 check, loopback, and linktrace, and defines them with great detail. 1038 4.8.2. Continuity Check 1040 See 4.6.2. 1042 4.8.3. Loopback 1044 See 4.6.3. 1046 4.8.4. Linktrace 1048 See 4.6.5. 1050 4.9. IEEE 802.3ah 1052 4.9.1. Overview 1054 The [IEEE 802.3ah] defines Ethernet for the Last Mile (EFM). With 1055 respect to OAM, this standard was designed as an Ethernet link-layer 1056 OAM, for single-hop Ethernet links, allowing to monitor remote 1057 networking devices that are not managed by a centralized management 1058 system. The OAM functions in this standard are described below. 1060 4.9.2. Remote Failure Indication 1062 This function allows a node to notify a peer about a defect in the 1063 receive path. Some physical interfaces allow unidirectional traffic, 1064 where even if one direction of the link fails, the reverse direction 1065 can still be used to convey the remote failure indication. 1067 4.9.3. Remote Loopback 1069 The remote loopback function provides a diagnostic mode that is used 1070 to verify the link connectivity, and to measure the packet loss rate. 1071 When a bridge interface is configured to loopback mode, all incoming 1072 traffic through the interface is looped and sent back to the 1073 originator. 1075 4.9.4. Link Monitoring 1077 Link monitoring provides an event notification function, allowing 1078 peer devices to communicate defect conditions and diagnostic 1079 information. 1081 4.10. MPLS-TP OAM 1083 4.10.1. Overview 1085 The MPLS working group is currently working on defining the OAM 1086 toolset that fulfill the requirements for MPLS-TP OAM. The full set 1087 of requirements for MPLS-TP OAM are defined in [MPLS-TP OAM], and 1088 include both general requirements for the behavior of the OAM 1089 mechanisms and a set of operations that should be supported by the 1090 OAM toolset. The set of mechanisms required are further elaborated 1091 in [MPLS-TP OAM FW], that describes the general architecture of the 1092 OAM system as well as giving overviews of the functionality of the 1093 OAM toolset. 1095 Some of the basic requirements for the OAM toolset for MPLS-TP are: 1097 o MPLS-TP OAM must be able to support both an IP based and non-IP 1098 based environment. If the network is IP based, i.e. IP routing and 1099 forwarding are available, then the MPLS-TP OAM toolset should rely 1100 on the IP routing and forwarding capabilities. On the other hand, 1101 in environments where IP functionality is not available, the OAM 1102 tools must still be able to operate without dependence on IP 1103 forwarding and routing. 1105 o OAM packets and the user traffic are required to be congruent 1106 (i.e. OAM packets are transmitted in-band) and there is a need to 1107 differentiate OAM packets from user-plane ones. Inherent in this 1108 requirement is the principle that MPLS-TP OAM be independent of 1109 any existing control-plane, although it should not preclude use of 1110 the control-plane functionality. 1112 4.10.2. Generic Associated Channel 1114 In order to address the requirement for in-band transmission of MPLS- 1115 TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh), 1116 defined in [G-ACh] for LSP-based OAM traffic. This mechanism is based 1117 on the same concepts as the PWE3 ACH and VCCV mechanisms. However, 1118 to address the needs of LSPs as differentiated from PW, the following 1119 concepts were defined for [G-ACh]: 1121 o An Associated Channel Header (ACH), that uses a format similar to 1122 the PW Control Word, is a 4-byte header that is added to OAM 1123 packets. 1125 o A Generic Associated Label (GAL). The GAL is a reserved MPLS label 1126 value. The reserved value is 13, and indicates the existence of 1127 the ACH immediately after it. 1129 4.10.3. MPLS-TP OAM Toolset 1131 To address the functionality that is required of the OAM toolset, the 1132 MPLS WG conducted an analysis of the existing IETF and ITU-T OAM 1133 mechanisms and their ability to fulfill the required functionality. 1134 The conclusions of this analysis are documented in [OAM Analysis]. 1135 The MPLS working group currently plans to use a mixture of OAM 1136 mechanisms that are based on various existing standards, and adapt 1137 them to the requirements of [MPLS-TP OAM]. Some of the main building 1138 blocks of this solution are based on: 1140 o Bidirectional Forwarding Detection ([BFD], [BFD LSP]) for 1141 proactive continuity check and connectivity verification. 1143 o LSP Ping as defined in [LSP Ping] for on-demand connectivity 1144 verification. 1146 o New protocol packets, using G-ACH, to address different 1147 functionality. 1149 o Performance measurement protocols that are based on the 1150 functionality that is described in [ITU-T Y.1731]. 1152 The following sub-sections describe the OAM tools that will be 1153 defined for MPLS-TP as described in [MPLS-TP OAM FW]. 1155 4.10.3.1. Continuity Check and Connectivity Verification 1157 Continuity Check and Connectivity Verification (CC-V) are OAM 1158 operations generally used in tandem, and compliment each other. These 1159 functions are generally run proactively, but may also be used on- 1160 demand, either due to bandwidth considerations or for diagnoses of a 1161 specific condition. Proactively [MPLS-TP OAM] states that the 1162 function should allow the MEPs to monitor the liveness and 1163 connectivity of a transport path. In on-demand mode, this function 1164 should support monitoring between the MEPs and, in addition, between 1165 a MEP and MIP.[MPLS-TP OAM FW] highlights the need for the CC-V 1166 messages to include unique identification of the MEG that is being 1167 monitored and the MEP that originated the message. The function, both 1168 proactively and in on-demand mode, need to be transmitted at regular 1169 rates pre-configured by the operator. 1171 4.10.3.2. Diagnostic Tests 1173 Diagnostic testing is a protocol that allows a network to send 1174 special test data on a transport path. For example, this could be 1175 used as part of bandwidth utilization measurement. 1177 4.10.3.3. Route Tracing 1179 [MPLS-TP OAM] defines that there is a need for functionality that 1180 would allow a path end-point to identify the intermediate and end- 1181 points of the path. This function would be used in on-demand mode. 1182 Normally, this path will be used for bidirectional PW, LSP, and 1183 sections, however, unidirectional paths may be supported only if a 1184 return path exists. 1186 4.10.3.4. Lock Instruct 1188 The Lock Instruct function is used to notify a transport path end- 1189 point of an administrative need to disable the transport path. This 1190 functionality will generally be used in conjunction with some 1191 intrusive OAM function, e.g. Performance measurement, Diagnostic 1192 testing, to minimize the side-effect on user data traffic. 1194 4.10.3.5. Lock Reporting 1196 Lock Reporting is a function used by an end-point of a path to report 1197 to its far-end end-point that a lock condition has been affected on 1198 the path. 1200 4.10.3.6. Alarm Reporting 1202 Alarm Reporting is a function used by an intermediate point of a 1203 path, that becomes aware of a fault on the path, to report to the 1204 end-points of the path. [MPLS-TP OAM FW] states that this may occur 1205 as a result of a defect condition discovered at a server sub-layer. 1206 This generates an Alarm Indication Signal (AIS) that continues until 1207 the fault is cleared. The consequent action of this function is 1208 detailed in [MPLS-TP OAM FW]. 1210 4.10.3.7. Remote Defect Indication 1212 Remote Defect Indication (RDI) is used proactively by a path end- 1213 point to report to its peer end-point that a defect is detected on a 1214 bidirectional connection between them. [MPLS-TP OAM] points out that 1215 this function may be applied to a unidirectional LSP only if there a 1216 return path exists. [MPLS-TP OAM FW] points out that this function 1217 is associated with the proactive CC-V function. 1219 4.10.3.8. Client Failure Indication 1221 Client Failure Indication (CFI) is defined in [MPLS-TP OAM] to allow 1222 the propagation information from one edge of the network to the 1223 other. The information concerns a defect to a client, in the case 1224 that the client does not support alarm notification. 1226 4.10.3.9. Packet Loss Measurement 1228 Packet Loss Measurement is a function used to verify the quality of 1229 the service. This function indicates the ratio of packets that are 1230 not delivered out of all packets that are transmitted by the path 1231 source. 1233 There are two possible ways of determining this measurement: 1235 o Using OAM packets, it is possible to compute the statistics based 1236 on a series of OAM packets. This, however, has the disadvantage of 1237 being artificial, and may not be representative since part of the 1238 packet loss may be dependent upon packet sizes. 1240 o Sending delimiting messages for the start and end of a measurement 1241 period during which the source and sink of the path count the 1242 packets transmitted and received. After the end delimiter, the 1243 ratio would be calculated by the path OAM entity. 1245 4.10.3.10. Packet Delay Measurement 1247 Packet Delay Measurement is a function that is used to measure one- 1248 way or two-way delay of a packet transmission between a pair of the 1249 end-points of a path (PW, LSP, or Section). Where: 1251 o One-way packet delay is the time elapsed from the start of 1252 transmission of the first bit of the packet by a source node until 1253 the reception of the last bit of that packet by the destination 1254 node. 1256 o Two-way packet delay is the time elapsed from the start of 1257 transmission of the first bit of the packet by a source node until 1258 the reception of the last bit of the loop-backed packet by the 1259 same source node, when the loopback is performed at the packet's 1260 destination node. 1262 Similarly to the packet loss measurement this could be performed in 1263 either of the two ways outlined above. 1265 4.11. Summary of OAM Functions 1267 Table 3 summarizes the OAM functions that are supported in each of 1268 the standards that were analyzed in this section. 1270 +-----------+-------+--------+--------+-----------+-------+--------+ 1271 | Standard |Continu|Connecti|Path |Defect |Perform|Other | 1272 | |ity |vity |Discover|Indications|ance |Function| 1273 | |Check |Verifica|y | |Monitor|s | 1274 | | |tion | | |ing | | 1275 +-----------+-------+--------+--------+-----------+-------+--------+ 1276 |ICMP Ping | |Echo |Tracerou| | | | 1277 | | | |te | | | | 1278 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1279 |BFD |BFD |BFD | | | | | 1280 | |Control|Echo | | | | | 1281 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1282 |LSP Ping | |"Ping" |"Tracero| | | | 1283 | | |mode |ute" | | | | 1284 | | | |mode | | | | 1285 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1286 |PW VCCV | |VCCV | | | | | 1287 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1288 |IPPM | | | | |-Delay | | 1289 | | | | | | measur| | 1290 | | | | | | ement | | 1291 | | | | | |-Packet| | 1292 | | | | | | loss | | 1293 | | | | | | measur| | 1294 | | | | | | ement | | 1295 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1296 |ITU-T |-CV | | | | | | 1297 |Y.1711 |-FFD | | | | | | 1298 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1299 |ITU-T |ETH-CC |ETH-LB |ETH-LT |-ETH-RDI |-ETH-LM|-ETH-LCK| 1300 |Y.1731 | | | |-ETH-AIS |-ETH-DM|-ETH-APS| 1301 | | | | | | |-ETH-TST| 1302 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1303 |IEEE |CC |Loopback|Linktrac| | | | 1304 |802.1ag | | |e | | | | 1305 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1306 |IEEE | |Remote | |-Remote | | | 1307 |802.3ah | |Loopback| | Failure | | | 1308 | | | | | Indication| | | 1309 | | | | |-Link | | | 1310 | | | | | Monitoring| | | 1311 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1312 |MPLS-TP |CC |CV |Route |-Alarm |-LM |-Diagnos| 1313 |OAM | | |Tracing | Reporting |-DM | tic Tes| 1314 | | | | |-Client | | s | 1315 | | | | | Failure | |-Lock | 1316 | | | | | Indication| | | 1317 | | | | |-Remote | | | 1318 | | | | | Defect | | | 1319 | | | | | Indication| | | 1320 +-----------+-------+--------+--------+-----------+-------+--------+ 1321 Table 3 Summary of OAM Functions 1323 4.12. Summary of Continuity Check Mechanisms 1325 A key element in some of the OAM standards that are analyzed in this 1326 document is the continuity check. It is thus interesting to present a 1327 more detailed comparison of the connectivity check mechanisms defined 1328 in OAM standards. Table 4 can be viewed as an extension of Table 3, 1329 but is presented separately for convenience. The table compares the 1330 OAM standards that support a continuity check. MPLS-TP is not 1331 included in the comparison, as the continuity check mechanism in 1332 MPLS-TP has not yet been defined. 1334 The "Tx Interval" column in the table specifies the period between 1335 two consequent message transmissions, while the "Source Identifier" 1336 column specifies the name of the field in the OAM packet that is used 1337 as the identifier of the transmitter. The "Error Codes" column 1338 specifies the possible error codes when the unidirectional 1339 connectivity check detects a failure. 1341 +-----------+-------+--------+---+--------+------------------------+ 1342 | |Mechani|Tx |UC/|Source | Error | 1343 | |sm |Interval|MC |Identifi| Codes | 1344 | | | | |er | | 1345 +-----------+-------+--------+---+--------+------------------------+ 1346 |BFD |BFD |Negotiat|UC |My Discr| Control Detection Time | 1347 | |Control|ed durin| |iminator| Expired | 1348 | | |g sessio| | | | 1349 | | |n | | | | 1350 + --------- + ----- + ------ + - + ------ + ---------------------- + 1351 |ITU-T |CV |CV: 1s |UC |TTSI |-Loss of CV (LOCV) | 1352 |Y.1711 |FFD |FFD: par| | |-TTSI Mismatch | 1353 | | |ameter, | | |-TTSI Mismerge | 1354 | | |default:| | |-Excess | 1355 | | |50 ms | | | | 1356 + --------- + ----- + ------ + - + ------ + ---------------------- + 1357 |ITU-T |CC |7 possib|UC/|MEP ID |-Loss of Continuity(LOC)| 1358 |Y.1731 / | |le perio|MC | |-Unexpected MEG level | 1359 |IEEE | |ds: | | |-Mismerge | 1360 |802.1ag | |3 1/3 ms| | |-Unexpected MEP | 1361 | | |10 ms | | |-Unexpected period | 1362 | | |100 ms | | | | 1363 | | |1 s | | | | 1364 | | |10 s | | | | 1365 | | |1 min | | | | 1366 | | |10 min | | | | 1367 +-----------+-------+--------+---+--------+------------------------+ 1368 Table 4 Summary of OAM Terms 1370 5. Security Considerations 1372 There are no security implications imposed by this document. 1374 6. IANA Considerations 1376 There are no new IANA considerations implied by this document. 1378 7. Acknowledgments 1380 This document was prepared using 2-Word-v2.0.template.dot. 1382 8. References 1384 8.1. Normative References 1386 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1387 Requirement Levels", BCP 14, RFC 2119, March 1997. 1389 [LSP Ping] Kompella, K., Swallow, G., "Detecting Multi-Protocol 1390 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1391 February 2006. 1393 [MPLS OAM] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and 1394 Matsushima, S., "Operations and Management (OAM) 1395 Requirements for Multi-Protocol Label Switched (MPLS) 1396 Networks", RFC 4377, February 2006. 1398 [MPLS OAM FW] Allan, D., Nadeau, T., "A Framework for Multi-Protocol 1399 Label Switching (MPLS) Operations and Management 1400 (OAM)", RFC 4378, February 2006. 1402 [MPLS OAM P2MP] Yasukawa, S., Farrel, A., King, D., and Nadeau, T., 1403 "Operations and Management (OAM) Requirements for 1404 Point-to-Multipoint MPLS Networks", RFC 4687, 1405 September 2006. 1407 [OAM Label] Ohta, H., "Assignment of the 'OAM Alert Label' for 1408 Multiprotocol Label Switching Architecture (MPLS) 1409 Operation and Maintenance (OAM) Functions", RFC 3429, 1410 November 2002. 1412 [MPLS-TP OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements for 1413 OAM in MPLS Transport Networks", RFC 5860, May 2010. 1415 [G-ACh] Bocci, M., Vigoureux, M., Bryant, S., "MPLS Generic 1416 Associated Channel", RFC 5586, June 2009. 1418 [VCCV] Nadeau, T., Pignataro, C., "Pseudowire Virtual Circuit 1419 Connectivity Verification (VCCV): A Control Channel 1420 for Pseudowires", RFC 5085, December 2007. 1422 [ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, 1423 RFC 792, September 1981. 1425 [ICMPv6] Conta, A., Deering, S., and M. Gupta, "Internet Control 1426 Message Protocol (ICMPv6) for the Internet Protocol 1427 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1429 [IPPM FW] Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., 1430 "Framework for IP Performance Metrics", RFC 2330, May 1431 1998. 1433 [IPPM Con] Mahdavi, J., Paxson, V., "IPPM Metrics for Measuring 1434 Connectivity", RFC 2678, September 1999. 1436 [IPPM 1DM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way 1437 Delay Metric for IPPM", RFC 2679, September 1999. 1439 [IPPM 1LM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way 1440 Packet Loss Metric for IPPM", RFC 2680, September 1441 1999. 1443 [IPPM 2DM] Almes, G., Kalidindi, S., Zekauskas, M., "A Round-trip 1444 Delay Metric for IPPM", RFC 2681, September 1999. 1446 [OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and 1447 Zekauskas, M., "A One-way Active Measurement Protocol 1448 (OWAMP)", RFC 4656, September 2006. 1450 [TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and 1451 Babiarz, J., "A Two-Way Active Measurement Protocol 1452 (TWAMP)", RFC 5357, October 2008. 1454 [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection 1455 (BFD)", RFC 5880, June 2010. 1457 [BFD IP] Katz, D., Ward, D., "Bidirectional Forwarding Detection 1458 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 1459 2010. 1461 [BFD Gen] Katz, D., Ward, D., "Generic Application of 1462 Bidirectional Forwarding Detection (BFD)", RFC 5882, 1463 June 2010. 1465 [BFD Multi] Katz, D., Ward, D., "Bidirectional Forwarding Detection 1466 (BFD) for Multihop Paths", RFC 5883, June 2010. 1468 [BFD LSP] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, 1469 G., "Bidirectional Forwarding Detection (BFD) for MPLS 1470 Label Switched Paths (LSPs)", RFC 5884, June 2010. 1472 [BFD VCCV] Nadeau, T., Pignataro, C., "Bidirectional Forwarding 1473 Detection (BFD) for the Pseudowire Virtual Circuit 1474 Connectivity Verification (VCCV)", RFC 5885, June 1475 2010. 1477 [IEEE 802.1ag]"Connectivity Fault Management", December 2007. 1479 [ITU-T Y.1731]"OAM Functions and Mechanisms for Ethernet-based 1480 Networks", February 2008. 1482 [ITU-T Y.1711]"Operation & Maintenance mechanism for MPLS networks", 1483 February 2004. 1485 [IEEE 802.3ah]"Media Access Control Parameters, Physical Layers, and 1486 Management Parameters for Subscriber Access Networks", 1487 clause 57, September 2004. 1489 8.2. Informative References 1491 [OAM Soup] Andersson, L., Van Helvoort, H., Bonica, R., Romascanu, 1492 D., Mansfield, S., " Guidelines for the use of the OAM 1493 acronym in the IETF ", work-in-progress, draft-ietf- 1494 opsawg-mpls-tp-oam-def, September, 2010. 1496 [OAM Analysis] Sprecher, N., Bellagamba, E., Weingarten, Y., "OAM 1497 functions in MPLS based transport network", work-in- 1498 progress, draft-ietf-mpls-tp-oam-analysis, January, 1499 2011. 1501 [MPLS-TP OAM FW] Busi, I., Niven-Jenkins, B., Allan, D., " 1502 Operations, Administration and Maintenance Framework 1503 for MPLS-based Transport Networks ", work-in-progress, 1504 draft-ietf-mpls-tp-oam-framework, February, 2011. 1506 [MPLS-TP Term]Van Helvoort, H., Andersson, L., Sprecher, N., "A 1507 Thesaurus for the Terminology used in Multiprotocol 1508 Label Switching Transport Profile (MPLS-TP) 1509 drafts/RFCs and ITU-T's Transport Network 1510 Recommendations", work-in-progress, draft-ietf-mpls- 1511 tp-rosetta-stone, November, 2010. 1513 [MPLS-TP Ping BFD] Bahadur, N., Aggarwal, R., Ward, D., Nadeau, T., 1514 Sprecher, N., Weingarten, Y., "LSP-Ping and BFD 1515 encapsulation over ACH", draft-ietf-mpls-tp-lsp-ping- 1516 bfd-procedures, work-in-progress, August, 2010. 1518 [P2MP Ping] Saxena, S., Farrel, A. , Yasukawa, S., "Detecting Data 1519 Plane Failures in Point-to-Multipoint Multiprotocol 1520 Label Switching (MPLS) - Extensions to LSP Ping", 1521 work-in-progress, draft-ietf-mpls-p2mp-lsp-ping, 1522 March, 2011. 1524 [ITU-T G.806] "Characteristics of transport equipment - Description 1525 methodology and generic functionality", January 2009. 1527 Authors' Addresses 1529 Tal Mizrahi 1530 Marvell 1531 6 Hamada St. 1532 Yokneam, 20692 1533 Israel 1535 Email: talmi@marvell.com 1537 Nurit Sprecher 1538 Nokia Siemens Networks 1539 3 Hanagar St. Neve Ne'eman B 1540 Hod Hasharon, 45241 1541 Israel 1543 Email: nurit.sprecher@nsn.com 1544 Elisa Bellagamba 1545 Ericsson 1546 6 Farogatan St. 1547 Stockholm, 164 40 1548 Sweden 1550 Phone: +46 761440785 1551 Email: elisa.bellagamba@ericsson.com 1553 Yaacov Weingarten 1554 Nokia Siemens Networks 1555 3 Hanagar St. Neve Ne'eman B 1556 Hod Hasharon, 45241 1557 Israel 1559 Phone: +972-9-775 1827 1560 Email: yaacov.weingarten@nsn.com