idnits 2.17.1 draft-ietf-opsawg-oam-overview-02.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 7, 2010) is 4948 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ITU-T Y.1731' is mentioned on line 1108, but not defined == Missing Reference: 'ITU-T Y.1711' is mentioned on line 767, but not defined == Missing Reference: 'PW ACH' is mentioned on line 645, but not defined == Missing Reference: 'RFC2679' is mentioned on line 675, but not defined ** Obsolete undefined reference: RFC 2679 (Obsoleted by RFC 7679) == Missing Reference: 'RFC 2681' is mentioned on line 675, but not defined == Missing Reference: 'RFC2681' is mentioned on line 676, but not defined == Unused Reference: 'IPPM 1DM' is defined on line 1393, but no explicit reference was found in the text == Unused Reference: 'IPPM 1LM' is defined on line 1396, but no explicit reference was found in the text == Unused Reference: 'IPPM 2DM' is defined on line 1400, 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: 3 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: April 2011 Nokia Siemens Networks 5 E. Bellagamba 6 Ericsson 7 Y. Weingarten 8 Nokia Siemens Networks 9 October 7, 2010 11 An Overview of 12 Operations, Administration, and Maintenance (OAM) Mechanisms 13 draft-ietf-opsawg-oam-overview-02.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 April 7, 2011. 38 Copyright Notice 40 Copyright (c) 2010 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 detecting and reporting 57 connection failures or measurement of connection performance 58 parameters. OAM mechanisms have been defined for various layers in 59 the protocol stack, and are used 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. Link Failures.....................................11 77 3.2.5. Connectivity Verification and Continuity Checks....11 78 3.2.6. Summary of OAM Terms used in the Standards.........11 79 4. OAM Functions..............................................13 80 4.1. ICMP Ping.............................................13 81 4.2. Bidirectional Forwarding Detection (BFD)...............13 82 4.2.1. Overview.........................................13 83 4.2.2. BFD Control.......................................13 84 4.2.3. BFD Echo.........................................14 85 4.3. LSP Ping..............................................14 86 4.4. PWE3 Virtual Circuit Connectivity Verification (VCCV)...15 87 4.5. IP Performance Metrics (IPPM)..........................15 88 4.5.1. Overview.........................................15 89 4.5.2. Control and Test Protocols........................16 90 4.5.3. OWAMP............................................16 91 4.5.4. TWAMP............................................17 92 4.6. ITU-T Y.1711..........................................17 93 4.6.1. Overview.........................................17 94 4.6.2. Connectivity Verification (CV)....................18 95 4.6.3. Fast Failure Detection (FFD)......................18 96 4.6.4. Forward Defect Indication (FDI)...................18 97 4.6.5. Backward Defect Indication (BDI)..................19 98 4.7. ITU-T Y.1731..........................................19 99 4.7.1. Overview.........................................19 100 4.7.2. ETH-CC...........................................19 101 4.7.3. ETH-LB...........................................20 102 4.7.4. ETH-TST..........................................20 103 4.7.5. ETH-LT...........................................20 104 4.7.6. ETH-AIS..........................................20 105 4.7.7. ETH-LCK..........................................20 106 4.7.8. ETH-RDI..........................................21 107 4.7.9. ETH-APS..........................................21 108 4.7.10. ETH-LM..........................................21 109 4.7.11. ETH-DM..........................................21 110 4.8. IEEE 802.1ag..........................................22 111 4.8.1. Overview.........................................22 112 4.8.2. Continuity Check..................................22 113 4.8.3. Loopback.........................................22 114 4.8.4. Linktrace........................................23 115 4.9. IEEE 802.3ah..........................................23 116 4.9.1. Overview.........................................23 117 4.9.2. Remote Failure Indication.........................23 118 4.9.3. Remote Loopback...................................23 119 4.9.4. Link Monitoring...................................23 120 4.10. MPLS-TP OAM..........................................23 121 4.10.1. Overview........................................23 122 4.10.2. Generic Associated Channel.......................24 123 4.10.3. MPLS-TP OAM Toolset..............................24 124 4.10.3.1. Continuity Check and Connectivity Verification25 125 4.10.3.2. Diagnostic Tests............................25 126 4.10.3.3. Route Tracing...............................25 127 4.10.3.4. Lock Instruct...............................25 128 4.10.3.5. Lock Reporting..............................26 129 4.10.3.6. Alarm Reporting.............................26 130 4.10.3.7. Remote Defect Indication....................26 131 4.10.3.8. Client Failure Indication...................26 132 4.10.3.9. Packet Loss Measurement.....................26 133 4.10.3.10. Packet Delay Measurement...................27 134 4.11. Summary of OAM Functions..............................27 135 4.12. Summary of Continuity Check Mechanisms................29 136 5. Security Considerations.....................................30 137 6. IANA Considerations........................................30 138 7. Acknowledgments............................................30 139 8. References.................................................30 140 8.1. Normative References...................................30 141 8.2. Informative References.................................32 143 1. Introduction 145 OAM is a general term that refers to a toolset that can be used for 146 detecting and reporting connection failures or measurement of 147 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 links. Other aspects 152 associated with the OAM acronym, such as management, are not 153 described in this document. 155 OAM was originally used in the world of telephony, and has been 156 adopted in packet based networks. OAM mechanisms are used in various 157 layers in the protocol stack, and are applied to a variety of 158 different protocols. 160 The IETF has defined OAM for several protocols, and is currently 161 working on defining several new OAM protocols. A summary of these 162 protocols, old and new, is listed below: 164 o MPLS LSP Ping, as defined in [LSP Ping] is an OAM mechanism for 165 point to point MPLS LSPs. The IETF is currently working on an 166 extension to the LSP Ping for point to multipoint MPLS - [P2MP 167 Ping]. 169 o Virtual Circuit Connectivity Check (VCCV) for Pseudowires, as 170 defined in [VCCV]. 172 o ICMP Echo request, also known as Ping, as defined in [ICMPv4], and 173 [ICMPv6]. ICMP Ping is a very simple and basic mechanism in 174 failure diagnosis, and is not traditionally associated with OAM, 175 but it is presented in this document for the sake of completeness, 176 since both LSP Ping and VCCV are to some extent based on ICMP 177 Ping. 179 o Bidirectional Forwarding Detection (BFD) is defined in [BFD] as a 180 framework for a lightweight generic OAM mechanism. The intention 181 is to define a base mechanism that can be used with various 182 encapsulation types, network environments, and in various medium 183 types. 185 o The OAM requirements for MPLS Transport Profile (MPLS-TP) are 186 defined in [MPLS-TP OAM], and the toolset is described in [MPLS-TP 187 OAM FW]. The OAM toolset for MPLS-TP is currently being defined in 188 the MPLS working group. 190 o IP Performance Metrics (IPPM) is a working group in the IETF that 191 defined common metrics for performance measurement, as well as a 192 protocol for measuring delay and packet loss in IP networks. 193 Alternative protocols for performance measurement are defined, for 194 example, in MPLS-TP OAM [MPLS-TP OAM], and in Ethernet OAM [ITU-T 195 Y.1731]. 197 In addition to the OAM mechanisms defined by the IETF, the IEEE and 198 ITU-T have also defined various OAM mechanisms. These various 199 mechanisms defined by the three standard organizations are often 200 tightly coupled, and have had a mutual effect on each other. The ITU- 201 T and IETF have both defined OAM mechanisms for MPLS LSPs, [ITU-T 202 Y.1711] and [LSP Ping]. The following OAM standards by the IEEE and 203 ITU-T are to some extent linked to IETF OAM mechanisms listed above, 204 and are also discussed in this document: 206 o OAM mechanisms for Ethernet based networks have been defined by 207 both the ITU-T in [ITU-T Y.1731], and by the IEEE in [IEEE 208 802.1ag]. The IEEE 802.3 standard defines OAM for one-hop Ethernet 209 links [IEEE 802.3ah]. 211 o The ITU-T has defined OAM for MPLS LSPs in [ITU-T Y.1711]. 213 This document summarizes the OAM mechanisms defined in the standards 214 above. The focus is on OAM mechanisms defined by the IETF. These 215 mechanisms will be compared with the relevant OAM mechanisms defined 216 by the ITU-T and IEEE, where applicable. We first present a 217 comparison of the terminology used in various OAM standards, and then 218 summarize the OAM functions that each OAM standard provides. 220 Table 1 summarizes the OAM standards discussed in this document. 222 +-----------+--------------------------------------+---------------+ 223 | | Title |Standard/Draft | 224 +-----------+--------------------------------------+---------------+ 225 |ICMPv4 Ping| Internet Control Message Protocol | RFC 792 | 226 | | | | 227 +-----------+--------------------------------------+---------------+ 228 |ICMPv6 Ping| Internet Control Message Protocol | RFC 4443 | 229 | | (ICMPv6) for the Internet Protocol | | 230 | | Version 6 (IPv6) Specification | | 231 +-----------+--------------------------------------+---------------+ 232 |BFD | Bidirectional Forwarding Detection | RFC 5880 | 233 | +--------------------------------------+---------------+ 234 | | Bidirectional Forwarding Detection | RFC 5881 | 235 | | (BFD) for IPv4 and IPv6 (Single Hop) | | 236 | +--------------------------------------+---------------+ 237 | | Generic Application of Bidirectional | RFC 5882 | 238 | | Forwarding Detection | | 239 | +--------------------------------------+---------------+ 240 | | Bidirectional Forwarding Detection | RFC 5883 | 241 | | (BFD) for Multihop Paths | | 242 | +--------------------------------------+---------------+ 243 | | Bidirectional Forwarding Detection | RFC 5884 | 244 | | for MPLS Label Switched Paths (LSPs) | | 245 | +--------------------------------------+---------------+ 246 | | Bidirectional Forwarding Detection | RFC 5885 | 247 | | for the Pseudowire Virtual Circuit | | 248 | | Connectivity Verification (VCCV) | | 249 +-----------+--------------------------------------+---------------+ 250 |IETF MPLS | Operations and Management (OAM) | RFC 4377 | 251 |OAM | Requirements for Multi-Protocol Label| | 252 |(LSP Ping) | Switched (MPLS) Networks | | 253 | +--------------------------------------+---------------+ 254 | | A Framework for Multi-Protocol | RFC 4378 | 255 | | Label Switching (MPLS) Operations | | 256 | | and Management (OAM) | | 257 | +--------------------------------------+---------------+ 258 | | Detecting Multi-Protocol Label | RFC 4379 | 259 | | Switched (MPLS) Data Plane Failures | | 260 | +--------------------------------------+---------------+ 261 | | Operations and Management (OAM) | RFC 4687 | 262 | | Requirements for Point-to-Multipoint | | 263 | | MPLS Networks | | 264 +-----------+--------------------------------------+---------------+ 265 |MPLS-TP | Requirements for OAM in MPLS-TP | RFC 5860 | 266 |OAM +--------------------------------------+---------------+ 267 | | MPLS Generic Associated Channel | RFC 5586 | 268 | +--------------------------------------+---------------+ 269 | | MPLS-TP OAM Framework |[MPLS-TP OAM FW| 270 | | |] - work in | 271 | | |progress | 272 | +--------------------------------------+---------------+ 273 | | MPLS-TP OAM Analysis |[OAM Analysis] | 274 | | | - work in | 275 | | |progress | 276 +-----------+--------------------------------------+---------------+ 277 |PW VCCV | Pseudowire Virtual Circuit | RFC 5085 | 278 | | Connectivity Verification (VCCV): | | 279 | | A Control Channel for Pseudowires | | 280 +-----------+--------------------------------------+---------------+ 281 |IPPM | Framework for IP Performance Metrics | RFC 2330 | 282 | +--------------------------------------+---------------+ 283 | | IPPM Metrics for Measuring | RFC 2678 | 284 | | Connectivity | | 285 | +--------------------------------------+---------------+ 286 | | A One-way Delay Metric for IPPM | RFC 2679 | 287 | +--------------------------------------+---------------+ 288 | | A One-way Packet Loss Metric for IPPM| RFC 2680 | 289 | +--------------------------------------+---------------+ 290 | | A Round-trip Delay Metric for IPPM | RFC 2681 | 291 | +--------------------------------------+---------------+ 292 | | A One-way Active Measurement Protocol| RFC 4656 | 293 | | (OWAMP) | | 294 | +--------------------------------------+---------------+ 295 | | A Two-Way Active Measurement Protocol| RFC 5357 | 296 | | (TWAMP) | | 297 +-----------+--------------------------------------+---------------+ 298 |ITU-T | Operation & Maintenance mechanism |[ITU-T Y.1711] | 299 |MPLS OAM | for MPLS networks | | 300 | +--------------------------------------+---------------+ 301 | | Assignment of the 'OAM Alert Label' | RFC 3429 | 302 | | for Multiprotocol Label Switching | | 303 | | Architecture (MPLS) Operation and | | 304 | | Maintenance (OAM) Functions | | 305 +-----------+--------------------------------------+---------------+ 306 |ITU-T | OAM Functions and Mechanisms for |[ITU-T Y.1731] | 307 |Ethernet | Ethernet-based Networks | | 308 |OAM | | | 309 +-----------+--------------------------------------+---------------+ 310 |IEEE | Connectivity Fault Management |[IEEE 802.1ag] | 311 |CFM | | | 312 +-----------+--------------------------------------+---------------+ 313 |IEEE | Media Access Control Parameters, |[IEEE 802.3ah] | 314 |802.3 | Physical Layers, and Management | | 315 |link level | Parameters for Subscriber Access | | 316 |OAM | Networks | | 317 +-----------+--------------------------------------+---------------+ 318 Table 1 Summary of OAM Standards 320 2. Conventions used in this document 322 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 323 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 324 document are to be interpreted as described in [KEYWORDS]. 326 3. Basic Terminology 328 3.1. Abbreviations 330 AIS Alarm Indication Signal 332 APS Automatic Protection Switching 334 BDI Backward Defect Indication 336 BFD Bidirectional Forwarding Detection 338 CC Continuity Check 340 CCM Continuity Check Message 342 CV Connectivity Verification 344 DM Delay Measurement 346 DTE Data Terminal Equipment 348 FDI Forward Defect Indication 350 FFD Fast Failure Detection 352 ICMP Internet Control Message Protocol 354 L2TP Layer Two Tunneling Protocol 356 LCCE L2TP Control Connection Endpoint 357 LM Loss Measurement 359 LSP Label Switching Path 361 LSR Label Switching Router 363 MA Maintenance Association 365 ME Maintenance Entity 367 MEG Maintenance Entity Group 369 MEP Maintenance End Point 371 MIP Maintenance Intermediate Point 373 MP Maintenance Point 375 MPLS Multiprotocol Label Switching 377 MPLS-TP MPLS Transport Profile 379 OAM Operations, Administration, and Maintenance 381 PE Provider Edge 383 PW Pseudowire 385 PWE3 Pseudowire Emulation Edge-to-Edge 387 RDI Remote Defect Indication 389 TTSI Trail Termination Source Identifier 391 VCCV Virtual Circuit Connectivity Verification 393 3.2. Terminology used in OAM Standards 395 3.2.1. General Terms 397 A wide variety of terms is used in various OAM standards. Each of the 398 OAM standards listed in the reference section includes a section that 399 defines the relevant terms. A thesaurus of terminology for MPLS-TP 400 terms is presented in [MPLS-TP Term], and provides a good summary of 401 some of the OAM related terminology. 403 This section presents a comparison of the terms used in various OAM 404 standards, without fully quoting the definition of each term. For a 405 formal definition of each term, refer to the references at the end of 406 this document. The comparison focuses on three basic terms, and is 407 summarized in section 3 ..2.6. 409 3.2.2. OAM Maintenance Entities and Communication Links 411 A Maintenance Entity (ME) can be either a point-to-point or a point- 412 to-multipoint relationship between two or more Maintenance Points 413 (MP). The connectivity between these Maintenance Points is managed 414 and monitored by the OAM protocol. 416 A pair of MPs engaged in an ME are connected by a communication Link. 417 Link in this context may refer to a physical connection, or to a 418 logical path such as an MPLS LSP. The term Link is used throughout 419 this document to refer to the connection between the MPs that is 420 monitored by an OAM protocol. 422 The term Maintenance Entity (ME) is defined in ITU-T standards (e.g. 423 [ITU-T Y.1731]). Various terms are used to refer to an ME. For 424 example, in MPLS terminology, an ME is simply referred to as an LSP. 425 BFD does not explicitly use a term that is equivalent to ME, but 426 rather uses the term "session", referring to the relationship between 427 two nodes using a BFD protocol. 429 MPLS-TP has defined the terms ME and Maintenance Entity Group (MEG) 430 in [MPLS-TP OAM FW], similar to the terms defined by ITU-T. 432 3.2.3. OAM Maintenance Points 434 A Maintenance Point (MP) is a function that is defined at a node in 435 the network, and either initiates or reacts to OAM messages. A 436 Maintenance End Point (MEP) is one of the end points of an ME, and 437 can initiate OAM messages and respond to them. A Maintenance 438 Intermediate Point (MIP) is a point between two MEPs, that is able to 439 respond to OAM frames, but does not initiate them. 441 The terms MEP and MIP are defined in ITU-T standards (e.g. [ITU-T 442 Y.1731]). The term Maintenance Point is a general term for MEPs and 443 MIPs, and is used in [IEEE 802.1ag]. 445 MPLS-TP has defined the terms MEP and MIP and their functional 446 characteristics in [MPLS-TP OAM FW], similar to the terms defined by 447 ITU-T. 449 3.2.4. Link Failures 451 The terms Failure, Fault, and Defect are intermittently used in the 452 standards. In some standards, such as [IEEE 802.1ag], there is no 453 distinction between these terms, while in other standards each of 454 these terms refers to a different type of malfunction. 456 The ITU-T distinguishes between these terms in [ITU-T G.806]. The 457 term Fault refers to an inability to perform a required action, e.g., 458 an unsuccessful attempt to deliver a packet. The term Defect refers 459 to an interruption in the normal operation, such as a consecutive 460 period of time where no packets are delivered successfully. The term 461 Failure refers to the termination of the required function. While a 462 Defect typically refers to a limited period of time, a failure refers 463 to a long period of time. 465 3.2.5. Connectivity Verification and Continuity Checks 467 Two distinct classes of failure management functions are used in OAM 468 protocols, connectivity verification and continuity checks. The 469 distinction between these terms is defined in [MPLS-TP OAM], and is 470 used similarly in this document. 472 Continuity checks are used to verify the liveness of a link, and are 473 typically sent proactively, though they can be invoked on-demand as 474 well. 476 A connectivity verification function allows an MP to check whether it 477 is connected to a peer MP or not. A connectivity verification (CV) 478 protocol typically uses a CV message, followed by a CV reply that is 479 sent back to the originator. A CV function can be applied proactively 480 or on-demand. 482 Connectivity verification and continuity checks are considered 483 complementary mechanisms, and are often used in conjunction with each 484 other. 486 3.2.6. Summary of OAM Terms used in the Standards 488 Table 2 provides a comparison of the terminology used in different 489 OAM standards. 491 +-----------+-------------+-----------+----------------------------+ 492 | |Maintenance |Maintenance|Link Failure Terminology | 493 | |Point |Entity | | 494 | |Terminology |Terminology| | 495 +-----------+-------------+-----------+----------------------------+ 496 |ICMPv4 Ping|-Host | | | 497 | |-Gateway | | | 498 + --------- + ----------- + --------- + -------------------------- + 499 |ICMPv6 Ping| Node | | | 500 + --------- + ----------- + --------- + -------------------------- + 501 |BFD | System | Session |-Failure | 502 | | | |-Session is declared down | 503 + --------- + ----------- + --------- + -------------------------- + 504 |LSP Ping | LSR | LSP |-Failure | 505 | | | |-Fault = typically a local | 506 | | | | isolated failure | 507 + --------- + ----------- + --------- + -------------------------- + 508 |PW VCCV |-PE | PW |-Failure | 509 | |-LCCE | |-Fault | 510 + --------- + ----------- + --------- + -------------------------- + 511 |IPPM |-Host |-Path | Connectivity is indicated | 512 | |-End system |-Measuremen| by a Boolean value. Thus, | 513 | | | t session | a failure is referred to as| 514 | | | | a path with a measurement | 515 | | | | value "false". | 516 + --------- + ----------- + --------- + -------------------------- + 517 |ITU-T | LSR | LSP |-Fault, Defect, Failure: as | 518 |Y.1711 | | | defined in [ITU-T G.806] | 519 + --------- + ----------- + --------- + -------------------------- + 520 |ITU-T |-MEP | ME |-Fault, Defect, Failure: as | 521 |Y.1731 |-MIP | | defined in [ITU-T G.806] | 522 | | | | | 523 + --------- + ----------- + --------- + -------------------------- + 524 |MPLS-TP |-End Point, |-LSP |-Fault, Defect, Failure: as | 525 |OAM | MEP |-PW | defined in [ITU-T G.806] | 526 | |-Intermediate|-Section | | 527 | | Point, MIP | | | 528 + --------- + ----------- + --------- + -------------------------- + 529 |IEEE |-MEP | ME |-Failure | 530 |802.1ag |-MIP | |-Fault | 531 | |-MP | |-Defect | 532 + --------- + ----------- + --------- + -------------------------- + 533 |IEEE | DTE | Link |-Failure | 534 |802.3ah | | |-Fault | 535 +-----------+-------------+-----------+----------------------------+ 536 Table 2 Summary of OAM Terms 538 4. OAM Functions 540 4.1. ICMP Ping 542 ICMP provides a connectivity verification function for the Internet 543 Protocol. The originator transmits an echo request packet, and the 544 receiver replies with an echo reply. ICMP ping is defined in two 545 variants, [ICMPv4] is used for IPv4, and [ICMPv6] is used for IPv6. 547 4.2. Bidirectional Forwarding Detection (BFD) 549 4.2.1. Overview 551 While multiple OAM mechanisms have been defined for various protocols 552 in the protocol stack, Bidirectional Forwarding Detection [BFD], 553 defined by the IETF BFD working group, is a generic OAM mechanism 554 that can be deployed over various encapsulating protocols, and in 555 various medium types. The IETF has defined variants of the protocol 556 for IP ([BFD IP], [BFD Multi]), for MPLS LSPs [BFD LSP], and for PWE3 557 [BFD VCCV]. BFD for MPLS-TP is currently evolving in the MPLS working 558 group (e.g. [MPLS-TP Ping BFD]). 560 BFD includes two main OAM functions, using two types of BFD packets: 561 BFD Control packets, and BFD Echo packets. 563 4.2.2. BFD Control 565 BFD supports a bidirectional continuity check, using BFD control 566 packets, that are exchanged within a BFD session. BFD sessions 567 operate in one of two modes: 569 o Asynchronous mode: in this mode BFD control packets are sent 570 periodically. When the receiver detects that no BFD control packet 571 have been received during a predetermined period of time, a 572 failure is detected. 574 o Demand mode: in this mode, BFD control packets are sent on-demand. 575 Upon need, a system initiates a series of BFD control packets to 576 verify the link. BFD control packets are sent independently in 577 each direction of the link. 579 Each of the end-points of the monitored path maintains its own 580 session identification, called a Discriminator, both of which are 581 included in the BFD Control Packets that are exchanged between the 582 end-points. At the time of session establishment, the Discriminators 583 are exchanged between the two-end points. In addition, the 584 transmission (and reception) rate is negotiated between the two end- 585 points, based on information included in the control packets. These 586 transmission rates may be renegotiated during the session. 588 During normal operation of the session, i.e. no failures are 589 detected, the BFD session is in the Up state. If no BFD Control 590 packets are received during a fixed period of time, called the 591 Detection Time, the session is declared to be Down. The detection 592 time is a function of the negotiated transmission time, and a 593 parameter called Detect Mult. Detect Mult determines the number of 594 missing BFD Control packets that cause the session to be declared as 595 Down. This parameter is included in the BFD Control packet. 597 4.2.3. BFD Echo 599 The echo function is used for connectivity verification. A BFD echo 600 packet is sent to a peer system, and is looped back to the 601 originator. The echo function can be used proactively, or on-demand. 603 4.3. LSP Ping 605 The IETF MPLS working group has defined OAM for MPLS LSPs. The 606 requirements and framework of this effort was defined in [MPLS OAM 607 FW] and [MPLS OAM], respectively. The corresponding OAM mechanism 608 defined, in this context, is LSP Ping [LSP Ping]. 610 LSP Ping is based on ICMP Ping and just like its predecessor may be 611 used in one of two modes: 613 o "Ping" mode: In this mode LSP ping is used for end-to-end 614 connectivity verification between two LSRs. 616 o "Traceroute" mode: This mode is used for hop-by-hop fault 617 localization. 619 LSP Ping extends the basic ICMP Ping operation (of data-plane 620 connectivity and continuity check) with functionality to verify 621 data-plane vs. control-plane consistency for a Forwarding Equivalence 622 Class (FEC) and also Maximum Transmission Unit (MTU) problems. The 623 traceroute functionality may be used to isolate and localize the MPLS 624 faults, using the Time-to-live (TTL) indicator to incrementally 625 identify the sub-path of the LSP that is successfully traversed 626 before the faulty link or node. 628 It should be noted that LSP Ping does support unique identification 629 of the LSP within an addressing domain. The identification is checked 630 using the full FEC identification. LSP Ping is easily extensible to 631 include additional information needed to support new functionality, 632 by use of Type-Length-Value (TLV) constructs. 634 LSP Ping supports both asynchronous, as well as, on-demand 635 activation. In addition, extensions for LSP Ping are being defined 636 for point-to-multipoint LSPs in [P2MP LSP Ping] and for MPLS Tunnels 637 in [MPLS LSP Ping]. 639 4.4. PWE3 Virtual Circuit Connectivity Verification (VCCV) 641 VCCV, as defined in [VCCV], provides end-to-end fault detection 642 and diagnostics for PWs (regardless of the underlying tunneling 643 technology). The VCCV switching function provides a control channel 644 associated with each PW (based on the PW Associated Channel Header 645 (ACH) which is defined in [PW ACH]), and allows sending OAM packets 646 in-band with PW data (using CC Type 1: In-band VCCV). 648 VCCV currently supports the following OAM mechanisms: ICMP Ping, LSP 649 Ping, and BFD. ICMP and LSP Ping are IP encapsulated before being 650 sent over the PW ACH. BFD for VCCV supports two modes of 651 encapsulation - either IP/UDP encapsulated (with IP/UDP header) or 652 PW-ACH encapsulated (with no IP/UDP header) and provides support to 653 signal the AC status. The use of the VCCV control channel provides 654 the context, based on the MPLS-PW label, required to bind and 655 bootstrap the BFD session to a particular pseudo wire (FEC), 656 eliminating the need to exchange Discriminator values. 658 VCCV consists of two components: (1) signaled component to 659 communicate VCCV capabilities as part of VC label, and (2) switching 660 component to cause the PW payload to be treated as a control packet. 662 VCCV is not directly dependent upon the presence of a control plane. 663 The VCCV capability negotiation may be performed as part of the PW 664 signaling when LDP is used. In case of manual configuration of the 665 PW, it is the responsibility of the operator to set consistent 666 options at both ends. 668 4.5. IP Performance Metrics (IPPM) 670 4.5.1. Overview 672 The IPPM working group [IPPM FW] in the IETF defines common criteria 673 and metrics for measuring performance of IP traffic. Some of the key 674 RFCs published by this working group have defined metrics for 675 measuring connectivity [rfc2678], delay [RFC2679, RFC 2681], and 676 packet loss [RFC2681]. 678 The IPPM working group has defined not only metrics for performance 679 measurement, but also protocols that define how the measurement is 680 carried out. The One-way Active Measurement Protocol [OWAMP] and the 681 Two-Way Active Measurement Protocol [TWAMP] define a method and 682 protocol for measuring delay and packet loss in IP networks. 684 OWAMP [OWAMP] enables measurement of one-way characteristics of IP 685 networks, such as one-way packet loss and one-way delay. For its 686 proper operation OWAMP requires accurate time of day setting at its 687 end points. 689 TWAMP [TWAMP] is a similar protocol that enables measurement of two- 690 way (round trip) characteristics. TWAMP does not require accurate 691 time of day, and, furthermore, allows the use of a simple session 692 reflector, making it an attractive alternative to OWAMP. 694 OWAMP and TWAMP use two separate protocols: a Control plane protocol, 695 and a Test plane protocol. 697 4.5.2. Control and Test Protocols 699 OWAMP and TWAMP control protocols run over TCP, while the test 700 protocols run over UDP. The purpose of the control protocols is to 701 initiate, start, and stop test sessions, and for OWAMP to fetch 702 results. The test protocols introduce test packets (which contain 703 sequence numbers and timestamps) along the IP path under test 704 according to a schedule, and record statistics of packet arrival. 705 Multiple sessions may be simultaneously defined, each with a session 706 identifier, and defining the number of packets to be sent, the amount 707 of padding to be added (and thus the packet size), the start time, 708 and the send schedule (which can be either a constant time between 709 test packets or exponentially distributed pseudo-random). Statistics 710 recorded conform to the relevant IPPM RFCs. 712 OWAMP and TWAMP test traffic is designed with security in mind. Test 713 packets are hard to detect because they are simply UDP streams 714 between negotiated port numbers, with potentially nothing static in 715 the packets. OWAMP and TWAMP also include optional authentication 716 and encryption for both control and test packets. 718 4.5.3. OWAMP 720 OWAMP defines the following logical roles: Session-Sender, Session- 721 Receiver, Server, Control-Client, and Fetch-Client. The Session- 722 Sender originates test traffic that is received by the Session- 723 Receiver. The Server configures and manages the session, as well as 724 returning the results. The Control-Client initiates requests for 725 test sessions, triggers their start, and may trigger their 726 termination. The Fetch-Client requests the results of a completed 727 session. Multiple roles may be combined in a single host - for 728 example, one host may play the roles of Control-Client, Fetch-Client, 729 and Session-Sender, and a second playing the roles of Server and 730 Session-Receiver. 732 In a typical OWAMP session the Control-Client establishes a TCP 733 connection to port 861 of the Server, which responds with a server 734 greeting message indicating supported security/integrity modes. The 735 Control-Client responds with the chosen communications mode and the 736 Server accepts the modes. The Control-Client then requests and fully 737 describes a test session to which the Server responds with its 738 acceptance and supporting information. More than one test session 739 may be requested with additional messages. The Control-Client then 740 starts a test session and the Server acknowledges. The Session- 741 Sender then sends test packets with pseudorandom padding to the 742 Session-Receiver until the session is complete or until the Control- 743 client stops the session. Once finished, the Fetch-Client sends a 744 fetch request to the server, which responds with an acknowledgement 745 and immediately thereafter the result data. 747 4.5.4. TWAMP 749 TWAMP defines the following logical roles: session-sender, session- 750 reflector, server, and control-client. These are similar to the 751 OWAMP roles, except that the Session-Reflector does not collect any 752 packet information, and there is no need for a Fetch-Client. 754 In a typical TWAMP session the Control-Client establishes a TCP 755 connection to port 862 of the Server, and mode is negotiated as in 756 OWAMP. The Control-Client then requests sessions and starts them. 757 The Session-Sender sends test packets with pseudorandom padding to 758 the Session-Reflector which returns them with insertion of 759 timestamps. 761 4.6. ITU-T Y.1711 763 4.6.1. Overview 765 As mentioned above (4.3.), the IETF defined LSP Ping as an OAM 766 mechanism for MPLS. The ITU-T has also defined an OAM protocol for 767 MPLS, defined in recommendation [ITU-T Y.1711]. This recommendation 768 defines mechanisms for connectivity verification and fast failure 769 detection, as well as mechanism for reporting defects that have been 770 identified in an LSP. 772 MPLS OAM packets per Y.1711 are detected by a reserved MPLS label 773 value. The reserved value is 14, and is defined in [OAM Label] as the 774 'OAM Alert Label'. 776 4.6.2. Connectivity Verification (CV) 778 The CV function is used to detect connectivity defects in an LSP. CV 779 frames are sent proactively at a rate of 1 per second. Each frame 780 contains the Trail-Termination Source Identifier (TTSI), indicating 781 the identity of the transmitting LSR. 783 The CV function can detect any of the following defect conditions. 785 o Loss of Connectivity Verification (LOCV): A loss of connectivity 786 is detected when no CV OAM packets are received in a period of 3 787 consecutive transmission periods. 789 o TTSI Mismatch: A TTSI mismatch is detected when a CV frame with an 790 unexpected TTSI is received. 792 o TTSI Mismerge: A TTSI mismerge is detected when the CV frames 793 received in a given LSP contain some frame with an expected TTSI, 794 and some frames with an unexpected TTSI. 796 o Excess: An excess is detected when at least 5 CV frames are 797 received during a period of 3 consecutive transmission periods. 799 4.6.3. Fast Failure Detection (FFD) 801 The FFD function is a proactive function, used for fast detection of 802 connectivity defects. While CV is typically sufficient for path 803 failure detection and reporting, protection switching mechanisms 804 typically require faster detection. FFD is very similar to CV in 805 terms of the packet format, and the possible defect conditions, but 806 FFD allows a configurable transmission frequency. The default 807 transmission rate of FFD frames is 20 per second, i.e., every 50 ms, 808 allowing fast detection for protection switching applications. 810 4.6.4. Forward Defect Indication (FDI) 812 The FDI function is used by an LSR to report a defect to affected 813 client layers, allowing them to suppress alarms about this defect. An 814 FDI packets are sent at a rate of 1 per second. 816 4.6.5. Backward Defect Indication (BDI) 818 The BDI function is used to inform the LSR at an LSP trail 819 termination source point about a defect condition in the forward 820 direction of an LSP. The LSR at the LSP trail termination sink point 821 transmits the BDI to the upstream LSR through the return path. BDI 822 packets are sent at the same transmission rate as FDI. 824 4.7. ITU-T Y.1731 826 4.7.1. Overview 828 The [ITU-T Y.1731] defines a protocol for Ethernet OAM. It is 829 presented in this document as a reference point. Y.1731 defines 830 various OAM functions, including continuity and connectivity 831 verification, and functions for performance monitoring. 833 4.7.2. ETH-CC 835 The Ethernet Continuity Check function is a proactive function that 836 allows a MEP to detect loss of continuity with any of the other MEPs 837 in the MEG. This function also allows detection of other defect 838 conditions, such as unintended connectivity between two MEGs. The 839 ETH-CC function is used for one of three possible applications: fault 840 management, performance monitoring (see 4.6.10.), and protection 841 switching. 843 Continuity Check Messages (CCM) are transmitted periodically at a 844 constant rate. There are 7 possible transmission periods, from 3.33 845 ms to 10 min. When the ETH-CC function detects a defect, it reports 846 one of the following defect conditions: 848 o Loss of continuity (LOC): Occurs when at least when no CCM 849 messages have been received from a peer MEP during a period of 3.5 850 times the configured transmission period. 852 o Unexpected MEG level: The MEG level is a 3-bit number that defines 853 the level of hierarchy of the MEG. This defect condition occurs 854 when a CCM is received from a peer MEP with a MEG level that is 855 lower than the expected MEG level. 857 o Mismerge: Occurs when a CCM is received from a peer MEP with an 858 unexpected MEG ID. 860 o Unexpected MEP: Occurs when a CCM is received from a peer MEP with 861 an unexpected transmitting MEP ID. 863 o Unexpected period: Occurs when the transmission period field in 864 the CCM does not match the expected transmission period value. 866 4.7.3. ETH-LB 868 The Ethernet loopback function verifies connectivity with a peer MEP 869 or MIP. The loopback function is performed on-demand, by sending a 870 loopback message (LBM) to the peer MEP or MIP. The peer node then 871 responds with a loopback reply (LBR). 873 More precisely, it is used for one of two purposes: 875 o Bidirectional connectivity test. 877 o Bidirectional in-service / out-of-service test. The in-service 878 mode refers to a test that is run under traffic, while the out-of- 879 service test requires other traffic to be halted. 881 4.7.4. ETH-TST 883 The test function is very similar to the loopback function, but is 884 unidirectional, i.e., the ETH-TST PDUs are terminated by the receiver 885 rather than being looped back to the sender. 887 4.7.5. ETH-LT 889 The Ethernet linktrace is an on-demand function that is used for path 890 discovery to a given target, or for locating a failure in a broken 891 path. 893 4.7.6. ETH-AIS 895 The Alarm Indication Signal indicates that a MEG should suppress 896 alarms about a defect condition at a lower MEG level, i.e., since a 897 defect has occurred in a lower hierarchy in the network, it should 898 not be reported by the current node. 900 A MEP that detects a failure periodically sends AIS messages to 901 higher hierarchies. AIS messages are sent periodically at a 902 recommended rate of 1 packet per second, until the defect condition 903 is resolved. 905 4.7.7. ETH-LCK 907 The lock function is used for administrative locking. A MEP can 908 initiate administrative locking, resulting in interruption of data, 909 e.g., for out-of-service ETH-LB or ETH-TST. 911 A MEP that initiates an administrative locking notifies its peer MEPs 912 to halt all relevant traffic until administrative/diagnostic 913 condition is removed. ETH-LCK frames are used to report to higher MEG 914 levels about the lock. The LCK frame, much like an AIS frame, 915 indicates to the receiving MEP that it should suppress alarms about 916 the locked link. 918 4.7.8. ETH-RDI 920 The Remote Defect Indication allows the sender to indicate that it 921 encountered a defect conditions. The receiving MEPs are then aware 922 that there is a defect condition in the MEG. 924 4.7.9. ETH-APS 926 The Y.1731 standard defines the frame format for Automatic Protection 927 Switching frames. The protection switching operations are defined in 928 other ITU-T standards. 930 4.7.10. ETH-LM 932 The loss measurement function allows a MEP to measure the packet loss 933 rate from/to a given MEP in the MEG. Each MEP maintains counters of 934 transmitted and received in-profile packets to/from each of its peer 935 MEPs. These counters are incorporated in the ETH-LM frames, allowing 936 the MEPs to compute the packet loss rate. 938 The ETH-LM function measures the far-end loss, referring to traffic 939 FROM the MEP to its peer, as well as the near-end loss, referring to 940 traffic from the peer MEP TO the local MEP. 942 ETH-LM is performed in one of two possible modes: 944 o Single-ended LM: in this mode loss measurement is performed on- 945 demand. The initiator sends an LM message (LMM) to its peer MEP, 946 and the peer responds with an LM reply (LMR). 948 o Dual-ended LM: in this mode loss measurement is performed 949 proactively. The continuity check message (CCM) is used for 950 proactive LM. The LM counters are piggy-backed into the CCM, and 951 allow proactive loss measurement. 953 4.7.11. ETH-DM 955 The delay measurement function is an on-demand function that allows a 956 MEP to measure the frame delay and frame delay variation to a peer 957 MEP. 959 ETH-DM can be performed in one of two modes of operation: 961 o One-way DM: in this mode, a MEP transmits a 1DM frame containing 962 the time of its transmission, TxTimeStampf. The receiving MEP 963 receives the 1DM frame and records the time of reception, RxTimef. 964 The receiving MEP can then compute the one-way delay by: RxTimef - 965 TxTimeStampf. 967 o Two-way DM: in this mode, a MEP transmits a delay measurement 968 message (DMM) containing its transmission time, TxTimeStampf. The 969 peer MEP receives the DMM and responds with a delay measurement 970 reply (DMR). Upon receiving the DMR, the initiating MEP records 971 the time of its reception, RxTimef, and computes the round trip 972 delay by: RxTimef - TxTimeStampf. 974 Each MEP maintains a time-of-day clock that is used for timestamping 975 delay measurement frames. It should be noted that in one-way DM it is 976 implicitly assumed that the clocks of the two peer MEPs are 977 synchronized by a time synchronization protocol. 979 4.8. IEEE 802.1ag 981 4.8.1. Overview 983 While the [ITU-T Y.1731] was defined in the ITU-T, the IEEE defined 984 the [IEEE 802.1ag] as a standard for connectivity fault management in 985 Ethernet based networks. While the two standards are to some extent 986 overlapping, they can also be viewed as two complementary parts of a 987 single Ethernet OAM picture. The two standards use a common packet 988 format. There are a few differences between the two standards in 989 terms of terminology: the term MEG level, used in Y.1731, as referred 990 to as Maintenance Domain level in 802.1ag; the Y.1731 standard uses 991 the term MEG, while the 802.1ag equivalent is Maintenance Association 992 (MA). 994 While Y.1731 defines multiple OAM functions (see section 4.6), the 995 802.1ag standard focuses on three main OAM functions: continuity 996 check, loopback, and linktrace, and defines them with great detail. 998 4.8.2. Continuity Check 1000 See 4.6.2. 1002 4.8.3. Loopback 1004 See 4.6.3. 1006 4.8.4. Linktrace 1008 See 4.6.5. 1010 4.9. IEEE 802.3ah 1012 4.9.1. Overview 1014 The [IEEE 802.3ah] defines an Ethernet link-layer OAM, for single-hop 1015 Ethernet links. The OAM functions in this standard are described 1016 below. 1018 4.9.2. Remote Failure Indication 1020 This function allows a node to notify a peer about a defect in the 1021 receive path. Some physical interfaces allow unidirectional traffic, 1022 where even if one direction of the link fails, the reverse direction 1023 can still be used to convey the remote failure indication. 1025 4.9.3. Remote Loopback 1027 The remote loopback function provides a diagnostic mode that is used 1028 to verify the link connectivity, and to measure the packet loss rate. 1029 When a bridge interface is configured to loopback mode, all incoming 1030 traffic through the interface is looped and sent back to the 1031 originator. 1033 4.9.4. Link Monitoring 1035 Link monitoring provides an event notification function, allowing 1036 peer devices to communicate defect conditions and diagnostic 1037 information. 1039 4.10. MPLS-TP OAM 1041 4.10.1. Overview 1043 The MPLS working group is currently working on defining the OAM 1044 toolset that fulfill the requirements for MPLS-TP OAM. The full set 1045 of requirements for MPLS-TP OAM are defined in [MPLS-TP OAM], and 1046 include both general requirements for the behavior of the OAM 1047 mechanisms and a set of operations that should be supported by the 1048 OAM toolset. The set of mechanisms required are further elaborated 1049 in [MPLS-TP OAM FW], that describes the general architecture of the 1050 OAM system as well as giving overviews of the functionality of the 1051 OAM toolset. 1053 Some of the basic requirements for the OAM toolset for MPLS-TP are: 1055 o MPLS-TP OAM must be able to support both an IP based and non-IP 1056 based environment. If the network is IP based, i.e. IP routing and 1057 forwarding are available, then the MPLS-TP OAM toolset should rely 1058 on the IP routing and forwarding capabilities. On the other hand, 1059 in environments where IP functionality is not available, the OAM 1060 tools must still be able to operate without dependence on IP 1061 forwarding and routing. 1063 o OAM packets and the user traffic are required to be congruent 1064 (i.e. OAM packets are transmitted in-band) and there is a need to 1065 differentiate OAM packets from user-plane ones. Inherent in this 1066 requirement is the principle that MPLS-TP OAM be independent of 1067 any existing control-plane, although it should not preclude use of 1068 the control-plane functionality. 1070 4.10.2. Generic Associated Channel 1072 In order to address the requirement for in-band transmission of MPLS- 1073 TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh), 1074 defined in [G-ACh] for LSP-based OAM traffic. This mechanism is based 1075 on the same concepts as the PWE3 ACH and VCCV mechanisms. However, 1076 to address the needs of LSPs as differentiated from PW, the following 1077 concepts were defined for [G-ACh]: 1079 o An Associated Channel Header (ACH), that uses a format similar to 1080 the PW Control Word, is a 4-byte header that is added to OAM 1081 packets. 1083 o A Generic Associated Label (GAL). The GAL is a reserved MPLS label 1084 value. The reserved value is 13, and indicates the existence of 1085 the ACH immediately after it. 1087 4.10.3. MPLS-TP OAM Toolset 1089 To address the functionality that is required of the OAM toolset, the 1090 MPLS WG conducted an analysis of the existing IETF and ITU-T OAM 1091 mechanisms and their ability to fulfill the required functionality. 1092 The conclusions of this analysis are documented in [OAM Analysis]. 1093 The MPLS working group currently plans to use a mixture of OAM 1094 mechanisms that are based on various existing standards, and adapt 1095 them to the requirements of [MPLS-TP OAM]. Some of the main building 1096 blocks of this solution are based on: 1098 o Bidirectional Forwarding Detection ([BFD], [BFD LSP]) for 1099 proactive continuity check and connectivity verification. 1101 o LSP Ping as defined in [LSP Ping] for on-demand connectivity 1102 verification. 1104 o New protocol packets, using G-ACH, to address different 1105 functionality. 1107 o Performance measurement protocols that are based on the 1108 functionality that is described in [ITU-T Y.1731]. 1110 The following sub-sections describe the OAM tools that will be 1111 defined for MPLS-TP as described in [MPLS-TP OAM FW]. 1113 4.10.3.1. Continuity Check and Connectivity Verification 1115 Continuity Check and Connectivity Verification (CC-V) are OAM 1116 operations generally used in tandem, and compliment each other. These 1117 functions are generally run proactively, but may also be used on- 1118 demand, either due to bandwidth considerations or for diagnoses of a 1119 specific condition. Proactively [MPLS-TP OAM] states that the 1120 function should allow the MEPs to monitor the liveness and 1121 connectivity of a transport path. In on-demand mode, this function 1122 should support monitoring between the MEPs and, in addition, between 1123 a MEP and MIP.[MPLS-TP OAM FW] highlights the need for the CC-V 1124 messages to include unique identification of the MEG that is being 1125 monitored and the MEP that originated the message. The function, both 1126 proactively and in on-demand mode, need to be transmitted at regular 1127 rates pre-configured by the operator. 1129 4.10.3.2. Diagnostic Tests 1131 Diagnostic testing is a protocol that allows a network to send 1132 special test data on a transport path. For example, this could be 1133 used as part of bandwidth utilization measurement. 1135 4.10.3.3. Route Tracing 1137 [MPLS-TP OAM] defines that there is a need for functionality that 1138 would allow a path end-point to identify the intermediate and end- 1139 points of the path. This function would be used in on-demand mode. 1140 Normally, this path will be used for bidirectional PW, LSP, and 1141 sections, however, unidirectional paths may be supported only if a 1142 return path exists. 1144 4.10.3.4. Lock Instruct 1146 The Lock Instruct function is used to notify a transport path end- 1147 point of an administrative need to disable the transport path. This 1148 functionality will generally be used in conjunction with some 1149 intrusive OAM function, e.g. Performance measurement, Diagnostic 1150 testing, to minimize the side-effect on user data traffic. 1152 4.10.3.5. Lock Reporting 1154 Lock Reporting is a function used by an end-point of a path to report 1155 to its far-end end-point that a lock condition has been affected on 1156 the path. 1158 4.10.3.6. Alarm Reporting 1160 Alarm Reporting is a function used by an intermediate point of a 1161 path, that becomes aware of a fault on the path, to report to the 1162 end-points of the path. [MPLS-TP OAM FW] states that this may occur 1163 as a result of a defect condition discovered at a server sub-layer. 1164 This generates an Alarm Indication Signal (AIS) that continues until 1165 the fault is cleared. The consequent action of this function is 1166 detailed in [MPLS-TP OAM FW]. 1168 4.10.3.7. Remote Defect Indication 1170 Remote Defect Indication (RDI) is used proactively by a path end- 1171 point to report to its peer end-point that a defect is detected on a 1172 bidirectional connection between them. [MPLS-TP OAM] points out that 1173 this function may be applied to a unidirectional LSP only if there a 1174 return path exists. [MPLS-TP OAM FW] points out that this function 1175 is associated with the proactive CC-V function. 1177 4.10.3.8. Client Failure Indication 1179 Client Failure Indication (CFI) is defined in [MPLS-TP OAM] to allow 1180 the propagation information from one edge of the network to the 1181 other. The information concerns a defect to a client, in the case 1182 that the client does not support alarm notification. 1184 4.10.3.9. Packet Loss Measurement 1186 Packet Loss Measurement is a function used to verify the quality of 1187 the service. This function indicates the ratio of packets that are 1188 not delivered out of all packets that are transmitted by the path 1189 source. 1191 There are two possible ways of determining this measurement: 1193 o Using OAM packets, it is possible to compute the statistics based 1194 on a series of OAM packets. This, however, has the disadvantage of 1195 being artificial, and may not be representative since part of the 1196 packet loss may be dependent upon packet sizes. 1198 o Sending delimiting messages for the start and end of a measurement 1199 period during which the source and sink of the path count the 1200 packets transmitted and received. After the end delimiter, the 1201 ratio would be calculated by the path OAM entity. 1203 4.10.3.10. Packet Delay Measurement 1205 Packet Delay Measurement is a function that is used to measure one- 1206 way or two-way delay of a packet transmission between a pair of the 1207 end-points of a path (PW, LSP, or Section). Where: 1209 o One-way packet delay is the time elapsed from the start of 1210 transmission of the first bit of the packet by a source node until 1211 the reception of the last bit of that packet by the destination 1212 node. 1214 o Two-way packet delay is the time elapsed from the start of 1215 transmission of the first bit of the packet by a source node until 1216 the reception of the last bit of the loop-backed packet by the 1217 same source node, when the loopback is performed at the packet's 1218 destination node. 1220 Similarly to the packet loss measurement this could be performed in 1221 either of the two ways outlined above. 1223 4.11. Summary of OAM Functions 1225 Table 3 summarizes the OAM functions that are supported in each of 1226 the standards that were analyzed in this section. 1228 +-----------+-------+--------+--------+-----------+-------+--------+ 1229 | Standard |Continu|Connecti|Path |Defect |Perform|Other | 1230 | |ity |vity |Discover|Indications|ance |Function| 1231 | |Check |Verifica|y | |Monitor|s | 1232 | | |tion | | |ing | | 1233 +-----------+-------+--------+--------+-----------+-------+--------+ 1234 |ICMP Ping | |Echo | | | | | 1235 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1236 |BFD |BFD |BFD | | | | | 1237 | |Control|Echo | | | | | 1238 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1239 |LSP Ping | |"Ping" |"Tracero| | | | 1240 | | |mode |ute" | | | | 1241 | | | |mode | | | | 1242 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1243 |PW VCCV | |VCCV | | | | | 1244 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1245 |IPPM | | | | |-Delay | | 1246 | | | | | | measur| | 1247 | | | | | | ement | | 1248 | | | | | |-Packet| | 1249 | | | | | | loss | | 1250 | | | | | | measur| | 1251 | | | | | | ement | | 1252 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1253 |ITU-T |-CV | | | | | | 1254 |Y.1711 |-FFD | | | | | | 1255 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1256 |ITU-T |ETH-CC |ETH-LB |ETH-LT |-ETH-RDI |-ETH-LM|-ETH-LCK| 1257 |Y.1731 | | | |-ETH-AIS |-ETH-DM|-ETH-APS| 1258 | | | | | | |-ETH-TST| 1259 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1260 |IEEE |CC |Loopback|Linktrac| | | | 1261 |802.1ag | | |e | | | | 1262 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1263 |IEEE | |Remote | |-Remote | | | 1264 |802.3ah | |Loopback| | Failure | | | 1265 | | | | | Indication| | | 1266 | | | | |-Link | | | 1267 | | | | | Monitoring| | | 1268 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1269 |MPLS-TP |CC |CV |Route |-Alarm |-LM |-Diagnos| 1270 |OAM | | |Tracing | Reporting |-DM | tic Tes| 1271 | | | | |-Client | | s | 1272 | | | | | Failure | |-Lock | 1273 | | | | | Indication| | | 1274 | | | | |-Remote | | | 1275 | | | | | Defect | | | 1276 | | | | | Indication| | | 1277 +-----------+-------+--------+--------+-----------+-------+--------+ 1278 Table 3 Summary of OAM Functions 1280 4.12. Summary of Continuity Check Mechanisms 1282 A key element in some of the OAM standards that are analyzed in this 1283 document is the continuity check. It is thus interesting to present a 1284 more detailed comparison of the connectivity check mechanisms defined 1285 in OAM standards. Table 4 can be viewed as an extension of Table 3, 1286 but is presented separately for convenience. The table compares the 1287 OAM standards that support a continuity check. MPLS-TP is not 1288 included in the comparison, as the continuity check mechanism in 1289 MPLS-TP has not yet been defined. 1291 The "Tx Interval" column in the table specifies the period between 1292 two consequent message transmissions, while the "Source Identifier" 1293 column specifies the name of the field in the OAM packet that is used 1294 as the identifier of the transmitter. The "Error Codes" column 1295 specifies the possible error codes when the unidirectional 1296 connectivity check detects a failure. 1298 +-----------+-------+--------+---+--------+------------------------+ 1299 | |Mechani|Tx |UC/|Source | Error | 1300 | |sm |Interval|MC |Identifi| Codes | 1301 | | | | |er | | 1302 +-----------+-------+--------+---+--------+------------------------+ 1303 |BFD |BFD |Negotiat|UC |My Discr| Control Detection Time | 1304 | |Control|ed durin| |iminator| Expired | 1305 | | |g sessio| | | | 1306 | | |n | | | | 1307 + --------- + ----- + ------ + - + ------ + ---------------------- + 1308 |ITU-T |CV |CV: 1s |UC |TTSI |-Loss of CV (LOCV) | 1309 |Y.1711 |FFD |FFD: par| | |-TTSI Mismatch | 1310 | | |ameter, | | |-TTSI Mismerge | 1311 | | |default:| | |-Excess | 1312 | | |50 ms | | | | 1313 + --------- + ----- + ------ + - + ------ + ---------------------- + 1314 |ITU-T |CC |7 possib|UC/|MEP ID |-Loss of Continuity(LOC)| 1315 |Y.1731 / | |le perio|MC | |-Unexpected MEG level | 1316 |IEEE | |ds: | | |-Mismerge | 1317 |802.1ag | |3 1/3 ms| | |-Unexpected MEP | 1318 | | |10 ms | | |-Unexpected period | 1319 | | |100 ms | | | | 1320 | | |1 s | | | | 1321 | | |10 s | | | | 1322 | | |1 min | | | | 1323 | | |10 min | | | | 1324 +-----------+-------+--------+---+--------+------------------------+ 1325 Table 4 Summary of OAM Terms 1327 5. Security Considerations 1329 There are no security implications imposed by this document. 1331 6. IANA Considerations 1333 There are no new IANA considerations implied by this document. 1335 7. Acknowledgments 1337 This document was prepared using 2-Word-v2.0.template.dot. 1339 8. References 1341 8.1. Normative References 1343 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1344 Requirement Levels", BCP 14, RFC 2119, March 1997. 1346 [LSP Ping] Kompella, K., Swallow, G., "Detecting Multi-Protocol 1347 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1348 February 2006. 1350 [MPLS OAM] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and 1351 Matsushima, S., "Operations and Management (OAM) 1352 Requirements for Multi-Protocol Label Switched (MPLS) 1353 Networks", RFC 4377, February 2006. 1355 [MPLS OAM FW] Allan, D., Nadeau, T., "A Framework for Multi-Protocol 1356 Label Switching (MPLS) Operations and Management 1357 (OAM)", RFC 4378, February 2006. 1359 [MPLS OAM P2MP] Yasukawa, S., Farrel, A., King, D., and Nadeau, T., 1360 "Operations and Management (OAM) Requirements for 1361 Point-to-Multipoint MPLS Networks", RFC 4687, 1362 September 2006. 1364 [OAM Label] Ohta, H., "Assignment of the 'OAM Alert Label' for 1365 Multiprotocol Label Switching Architecture (MPLS) 1366 Operation and Maintenance (OAM) Functions", RFC 3429, 1367 November 2002. 1369 [MPLS-TP OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements for 1370 OAM in MPLS Transport Networks", RFC 5860, May 2010. 1372 [G-ACh] Bocci, M., Vigoureux, M., Bryant, S., "MPLS Generic 1373 Associated Channel", RFC 5586, June 2009. 1375 [VCCV] Nadeau, T., Pignataro, C., "Pseudowire Virtual Circuit 1376 Connectivity Verification (VCCV): A Control Channel 1377 for Pseudowires", RFC 5085, December 2007. 1379 [ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, 1380 RFC 792, September 1981. 1382 [ICMPv6] Conta, A., Deering, S., and M. Gupta, "Internet Control 1383 Message Protocol (ICMPv6) for the Internet Protocol 1384 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1386 [IPPM FW] Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., 1387 "Framework for IP Performance Metrics", RFC 2330, May 1388 1998. 1390 [IPPM Con] Mahdavi, J., Paxson, V., "IPPM Metrics for Measuring 1391 Connectivity", RFC 2678, September 1999. 1393 [IPPM 1DM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way 1394 Delay Metric for IPPM", RFC 2679, September 1999. 1396 [IPPM 1LM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way 1397 Packet Loss Metric for IPPM", RFC 2680, September 1398 1999. 1400 [IPPM 2DM] Almes, G., Kalidindi, S., Zekauskas, M., "A Round-trip 1401 Delay Metric for IPPM", RFC 2681, September 1999. 1403 [OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and 1404 Zekauskas, M., "A One-way Active Measurement Protocol 1405 (OWAMP)", RFC 4656, September 2006. 1407 [TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and 1408 Babiarz, J., "A Two-Way Active Measurement Protocol 1409 (TWAMP)", RFC 5357, October 2008. 1411 [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection 1412 (BFD)", RFC 5880, June 2010. 1414 [BFD IP] Katz, D., Ward, D., "Bidirectional Forwarding Detection 1415 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 1416 2010. 1418 [BFD Gen] Katz, D., Ward, D., "Generic Application of 1419 Bidirectional Forwarding Detection (BFD)", RFC 5882, 1420 June 2010. 1422 [BFD Multi] Katz, D., Ward, D., "Bidirectional Forwarding Detection 1423 (BFD) for Multihop Paths", RFC 5883, June 2010. 1425 [BFD LSP] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, 1426 G., "Bidirectional Forwarding Detection (BFD) for MPLS 1427 Label Switched Paths (LSPs)", RFC 5884, June 2010. 1429 [BFD VCCV] Nadeau, T., Pignataro, C., "Bidirectional Forwarding 1430 Detection (BFD) for the Pseudowire Virtual Circuit 1431 Connectivity Verification (VCCV)", RFC 5885, June 1432 2010. 1434 [IEEE 802.1ag]"Connectivity Fault Management", December 2007. 1436 [ITU-T Y.1731]"OAM Functions and Mechanisms for Ethernet-based 1437 Networks", February 2008. 1439 [ITU-T Y.1711]"Operation & Maintenance mechanism for MPLS networks", 1440 February 2004. 1442 [IEEE 802.3ah]"Media Access Control Parameters, Physical Layers, and 1443 Management Parameters for Subscriber Access Networks", 1444 clause 57, September 2004. 1446 8.2. Informative References 1448 [OAM Soup] Andersson, L., Van Helvoort, H., Bonica, R., Romascanu, 1449 D., Mansfield, S., "The OAM Acronym Soup", draft-ietf- 1450 opsawg-mpls-tp-oam-def, June 2010. 1452 [OAM Analysis] Sprecher, N., Bellagamba, E., Weingarten, Y., "MPLS-TP 1453 OAM Analysis", draft-ietf-mpls-tp-oam-analysis, July 1454 2010. 1456 [MPLS-TP OAM FW] Busi, I., Niven-Jenkins, B., Allan, D., "MPLS-TP OAM 1457 Framework", work-in-progress, draft-ietf-mpls-tp-oam- 1458 framework, July, 2010. 1460 [MPLS-TP Term]Van Helvoort, H., Andersson, L., Sprecher, N., "A 1461 Thesaurus for the Terminology used in Multiprotocol 1462 Label Switching Transport Profile (MPLS-TP) 1463 drafts/RFCs and ITU-T's Transport Network 1464 Recommendations", draft-ietf-mpls-tp-rosetta-stone, 1465 May 2010. 1467 [MPLS-TP Ping BFD] Bahadur, N., Aggarwal, R., Ward, D., Nadeau, T., 1468 Sprecher, N., Weingarten, Y., "LSP-Ping and BFD 1469 encapsulation over ACH", draft-ietf-mpls-tp-lsp-ping- 1470 bfd-procedures, March 2010. 1472 [P2MP Ping] Saxena, S., Farrel, A. , Yasukawa, S., "Detecting Data 1473 Plane Failures in Point-to-Multipoint Multiprotocol 1474 Label Switching (MPLS) - Extensions to LSP Ping", 1475 draft-ietf-mpls-p2mp-lsp-ping, March 2010. 1477 [ITU-T G.806] "Characteristics of transport equipment - Description 1478 methodology and generic functionality", January 2009. 1480 Authors' Addresses 1482 Tal Mizrahi 1483 Marvell 1484 6 Hamada St. 1485 Yokneam, 20692 1486 Israel 1488 Email: talmi@marvell.com 1490 Nurit Sprecher 1491 Nokia Siemens Networks 1492 3 Hanagar St. Neve Ne'eman B 1493 Hod Hasharon, 45241 1494 Israel 1496 Email: nurit.sprecher@nsn.com 1498 Elisa Bellagamba 1499 Ericsson 1500 6 Farogatan St. 1501 Stockholm, 164 40 1502 Sweden 1503 Phone: +46 761440785 1504 Email: elisa.bellagamba@ericsson.com 1506 Yaacov Weingarten 1507 Nokia Siemens Networks 1508 3 Hanagar St. Neve Ne'eman B 1509 Hod Hasharon, 45241 1510 Israel 1512 Phone: +972-9-775 1827 1513 Email: yaacov.weingarten@nsn.com