idnits 2.17.1 draft-ietf-opsawg-oam-overview-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (January 24, 2011) is 4834 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ITU-T Y.1731' is mentioned on line 1135, but not defined == Missing Reference: 'ITU-T Y.1711' is mentioned on line 786, but not defined == Missing Reference: 'PW ACH' is mentioned on line 663, but not defined == Missing Reference: 'RFC2679' is mentioned on line 693, but not defined ** Obsolete undefined reference: RFC 2679 (Obsoleted by RFC 7679) == Missing Reference: 'RFC 2681' is mentioned on line 693, but not defined == Missing Reference: 'RFC2681' is mentioned on line 694, but not defined == Unused Reference: 'IPPM 1DM' is defined on line 1421, but no explicit reference was found in the text == Unused Reference: 'IPPM 1LM' is defined on line 1424, but no explicit reference was found in the text == Unused Reference: 'IPPM 2DM' is defined on line 1428, 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: July 2011 Nokia Siemens Networks 5 E. Bellagamba 6 Ericsson 7 Y. Weingarten 8 Nokia Siemens Networks 9 January 24, 2011 11 An Overview of 12 Operations, Administration, and Maintenance (OAM) Mechanisms 13 draft-ietf-opsawg-oam-overview-03.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 July 24, 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)...............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)..........................16 88 4.5.1. Overview.........................................16 89 4.5.2. Control and Test Protocols........................16 90 4.5.3. OWAMP............................................17 91 4.5.4. TWAMP............................................17 92 4.6. ITU-T Y.1711..........................................18 93 4.6.1. Overview.........................................18 94 4.6.2. Connectivity Verification (CV)....................18 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)..................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...........................................21 104 4.7.6. ETH-AIS..........................................21 105 4.7.7. ETH-LCK..........................................21 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..........................................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........................................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...................................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 Verification25 125 4.10.3.2. Diagnostic Tests............................26 126 4.10.3.3. Route Tracing...............................26 127 4.10.3.4. Lock Instruct...............................26 128 4.10.3.5. Lock Reporting..............................26 129 4.10.3.6. Alarm Reporting.............................26 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...................27 134 4.11. Summary of OAM Functions..............................28 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.................................................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 TTSI Trail Termination Source Identifier 394 VCCV Virtual Circuit Connectivity Verification 396 3.2. Terminology used in OAM Standards 398 3.2.1. General Terms 400 A wide variety of terms is used in various OAM standards. Each of the 401 OAM standards listed in the reference section includes a section that 402 defines the relevant terms. A thesaurus of terminology for MPLS-TP 403 terms is presented in [MPLS-TP Term], and provides a good summary of 404 some of the OAM related terminology. 406 This section presents a comparison of the terms used in various OAM 407 standards, without fully quoting the definition of each term. For a 408 formal definition of each term, refer to the references at the end of 409 this document. The comparison focuses on three basic terms, and is 410 summarized in section 3 ..2.6. 412 3.2.2. OAM Maintenance Entities and Communication Links 414 A Maintenance Entity (ME) is a point-to-point relationship between 415 two Maintenance Points (MP). The connectivity between these 416 Maintenance Points is managed and monitored by the OAM protocol. 418 A pair of MPs engaged in an ME are connected by a communication Link. 419 The term "Link" in this context is a generic term that may refer to 420 one of several types of connection, e.g. a single physical 421 connection, a set of physical connections, or a virtual link such as 422 an MPLS LSP. The term Link is used throughout this document to refer 423 to the connection between the MPs that is monitored by an OAM 424 protocol. 426 The term Maintenance Entity (ME) is defined in ITU-T standards (e.g. 427 [ITU-T Y.1731]). Various terms are used to refer to an ME. For 428 example, in MPLS LSP Ping ([LSP Ping]) terminology, an ME is simply 429 referred to as an LSP. BFD does not explicitly use a term that is 430 equivalent to ME, but rather uses the term "session", referring to 431 the relationship between two nodes using a BFD protocol. 433 MPLS-TP has defined the terms ME and Maintenance Entity Group (MEG) 434 in [MPLS-TP OAM FW], similar to the terms defined by ITU-T. 436 3.2.3. OAM Maintenance Points 438 A Maintenance Point (MP) is a functional entity that is defined at a 439 node in the network, and either initiates or reacts to OAM messages. 440 A Maintenance End Point (MEP) is one of the end points of an ME, and 441 can initiate OAM messages and respond to them. A Maintenance 442 Intermediate Point (MIP) is an intermediate point between two MEPs, 443 that does not initiate OAM frames, but is able to respond to OAM 444 frames that are destined to it, and to forward others. 446 The terms MEP and MIP are defined in ITU-T standards (e.g. [ITU-T 447 Y.1731]). The term Maintenance Point is a general term for MEPs and 448 MIPs, and is used in [IEEE 802.1ag]. 450 The 802.1ag defines a finer distinction between Up MPs and Down MPs. 451 An MP is a bridge interface, that is monitored by an OAM protocol 452 either in the direction facing the network, or in the direction 453 facing the bridge. A Down MP is an MP that receives OAM packets from, 454 and transmits them to the direction of the network. An Up MP receives 455 OAM packets from, and transmits them to the direction of the bridging 456 entity. 458 MPLS-TP has defined the terms MEP and MIP and their functional 459 characteristics in [MPLS-TP OAM FW], similar to the terms defined by 460 ITU-T. 462 3.2.4. Connectivity Verification and Continuity Checks 464 Two distinct classes of failure management functions are used in OAM 465 protocols, connectivity verification and continuity checks. The 466 distinction between these terms is defined in [MPLS-TP OAM], and is 467 used similarly in this document. 469 Continuity checks are used to verify the liveness of a link, and are 470 typically sent proactively, though they can be invoked on-demand as 471 well. 473 A connectivity verification function allows an MP to check whether it 474 is connected to a peer MP or not. A connectivity verification (CV) 475 protocol typically uses a CV message, followed by a CV reply that is 476 sent back to the originator. A CV function can be applied proactively 477 or on-demand. 479 Connectivity verification and continuity checks are considered 480 complementary mechanisms, and are often used in conjunction with each 481 other. 483 3.2.5. Link Failures 485 The terms Failure, Fault, and Defect are intermittently used in the 486 standards, referring to a malfunction that can be detected by a 487 connectivity or a continuity check. In some standards, such as [IEEE 488 802.1ag], there is no distinction between these terms, while in other 489 standards each of these terms refers to a different type of 490 malfunction. 492 The ITU-T distinguishes between these terms in [ITU-T G.806]. The 493 term Fault refers to an inability to perform a required action, e.g., 494 an unsuccessful attempt to deliver a packet. The term Defect refers 495 to an interruption in the normal operation, such as a consecutive 496 period of time where no packets are delivered successfully. The term 497 Failure refers to the termination of the required function. While a 498 Defect typically refers to a limited period of time, a failure refers 499 to a long period of time. 501 3.2.6. Summary of OAM Terms used in the Standards 503 Table 2 provides a comparison of the terminology used in different 504 OAM standards. 506 +-----------+-------------+-----------+----------------------------+ 507 | |Maintenance |Maintenance|Link Failure Terminology | 508 | |Point |Entity | | 509 | |Terminology |Terminology| | 510 +-----------+-------------+-----------+----------------------------+ 511 |ICMPv4 Ping|-Host | | | 512 | |-Gateway | | | 513 + --------- + ----------- + --------- + -------------------------- + 514 |ICMPv6 Ping| Node | | | 515 + --------- + ----------- + --------- + -------------------------- + 516 |BFD | System | Session |-Failure | 517 | | | |-Session is declared down | 518 + --------- + ----------- + --------- + -------------------------- + 519 |LSP Ping | LSR | LSP |-Failure | 520 | | | |-Fault = typically a local | 521 | | | | isolated failure | 522 + --------- + ----------- + --------- + -------------------------- + 523 |PW VCCV |-PE | PW |-Failure | 524 | |-LCCE | |-Fault | 525 + --------- + ----------- + --------- + -------------------------- + 526 |IPPM |-Host |-Path | Connectivity is indicated | 527 | |-End system |-Measuremen| by a Boolean value. Thus, | 528 | | | t session | a failure is referred to as| 529 | | | | a path with a measurement | 530 | | | | value "false". | 531 + --------- + ----------- + --------- + -------------------------- + 532 |ITU-T | LSR | LSP |-Fault, Defect, Failure: as | 533 |Y.1711 | | | defined in [ITU-T G.806] | 534 + --------- + ----------- + --------- + -------------------------- + 535 |ITU-T |-MEP | ME |-Fault, Defect, Failure: as | 536 |Y.1731 |-MIP | | defined in [ITU-T G.806] | 537 | | | | | 538 + --------- + ----------- + --------- + -------------------------- + 539 |MPLS-TP |-End Point, |-LSP |-Fault, Defect, Failure: as | 540 |OAM | MEP |-PW | defined in [ITU-T G.806] | 541 | |-Intermediate|-Section | | 542 | | Point, MIP | | | 543 + --------- + ----------- + --------- + -------------------------- + 544 |IEEE |-MP (Down,Up)| ME |-Failure | 545 |802.1ag | -MEP | |-Fault | 546 | | -MIP | |-Defect | 547 | | -MHF | | | 548 + --------- + ----------- + --------- + -------------------------- + 549 |IEEE | DTE | Link |-Failure | 550 |802.3ah | | |-Fault | 551 +-----------+-------------+-----------+----------------------------+ 552 Table 2 Summary of OAM Terms 554 4. OAM Functions 556 4.1. ICMP Ping 558 ICMP provides a connectivity verification function for the Internet 559 Protocol. The originator transmits an echo request packet, and the 560 receiver replies with an echo reply. ICMP ping is defined in two 561 variants, [ICMPv4] is used for IPv4, and [ICMPv6] is used for IPv6. 563 4.2. Bidirectional Forwarding Detection (BFD) 565 4.2.1. Overview 567 While multiple OAM mechanisms have been defined for various protocols 568 in the protocol stack, Bidirectional Forwarding Detection [BFD], 569 defined by the IETF BFD working group, is a generic OAM mechanism 570 that can be deployed over various encapsulating protocols, and in 571 various medium types. The IETF has defined variants of the protocol 572 for IP ([BFD IP], [BFD Multi]), for MPLS LSPs [BFD LSP], and for PWE3 573 [BFD VCCV]. BFD for MPLS-TP is currently evolving in the MPLS working 574 group (e.g. [MPLS-TP Ping BFD]). 576 BFD includes two main OAM functions, using two types of BFD packets: 577 BFD Control packets, and BFD Echo packets. 579 4.2.2. BFD Control 581 BFD supports a bidirectional continuity check, using BFD control 582 packets, that are exchanged within a BFD session. BFD sessions 583 operate in one of two modes: 585 o Asynchronous mode: in this mode BFD control packets are sent 586 periodically. When the receiver detects that no BFD control packet 587 have been received during a predetermined period of time, a 588 failure is detected. 590 o Demand mode: in this mode, BFD control packets are sent on-demand. 591 Upon need, a system initiates a series of BFD control packets to 592 verify the link. BFD control packets are sent independently in 593 each direction of the link. 595 Each of the end-points of the monitored path maintains its own 596 session identification, called a Discriminator, both of which are 597 included in the BFD Control Packets that are exchanged between the 598 end-points. At the time of session establishment, the Discriminators 599 are exchanged between the two-end points. In addition, the 600 transmission (and reception) rate is negotiated between the two end- 601 points, based on information included in the control packets. These 602 transmission rates may be renegotiated during the session. 604 During normal operation of the session, i.e. no failures are 605 detected, the BFD session is in the Up state. If no BFD Control 606 packets are received during a fixed period of time, called the 607 Detection Time, the session is declared to be Down. The detection 608 time is a function of the negotiated transmission time, and a 609 parameter called Detect Mult. Detect Mult determines the number of 610 missing BFD Control packets that cause the session to be declared as 611 Down. This parameter is included in the BFD Control packet. 613 4.2.3. BFD Echo 615 The echo function is used for connectivity verification. A BFD echo 616 packet is sent to a peer system, and is looped back to the 617 originator. The echo function can be used proactively, or on-demand. 619 4.3. LSP Ping 621 The IETF MPLS working group has defined OAM for MPLS LSPs. The 622 requirements and framework of this effort was defined in [MPLS OAM 623 FW] and [MPLS OAM], respectively. The corresponding OAM mechanism 624 defined, in this context, is LSP Ping [LSP Ping]. 626 LSP Ping is based on ICMP Ping and just like its predecessor may be 627 used in one of two modes: 629 o "Ping" mode: In this mode LSP ping is used for end-to-end 630 connectivity verification between two LSRs. 632 o "Traceroute" mode: This mode is used for hop-by-hop fault 633 localization. 635 LSP Ping extends the basic ICMP Ping operation (of data-plane 636 connectivity and continuity check) with functionality to verify 637 data-plane vs. control-plane consistency for a Forwarding Equivalence 638 Class (FEC) and also Maximum Transmission Unit (MTU) problems. The 639 traceroute functionality may be used to isolate and localize the MPLS 640 faults, using the Time-to-live (TTL) indicator to incrementally 641 identify the sub-path of the LSP that is successfully traversed 642 before the faulty link or node. 644 It should be noted that LSP Ping does support unique identification 645 of the LSP within an addressing domain. The identification is checked 646 using the full FEC identification. LSP Ping is easily extensible to 647 include additional information needed to support new functionality, 648 by use of Type-Length-Value (TLV) constructs. The usage of TLVs is 649 typically not easy to perform in hardware, and is thus typically 650 handled by the control plane. 652 LSP Ping supports both asynchronous, as well as, on-demand 653 activation. In addition, extensions for LSP Ping are being defined 654 for point-to-multipoint LSPs in [P2MP LSP Ping] and for MPLS Tunnels 655 in [MPLS LSP Ping]. 657 4.4. PWE3 Virtual Circuit Connectivity Verification (VCCV) 659 VCCV, as defined in [VCCV], provides end-to-end fault detection 660 and diagnostics for PWs (regardless of the underlying tunneling 661 technology). The VCCV switching function provides a control channel 662 associated with each PW (based on the PW Associated Channel Header 663 (ACH) which is defined in [PW ACH]), and allows sending OAM packets 664 in-band with PW data (using CC Type 1: In-band VCCV). 666 VCCV currently supports the following OAM mechanisms: ICMP Ping, LSP 667 Ping, and BFD. ICMP and LSP Ping are IP encapsulated before being 668 sent over the PW ACH. BFD for VCCV supports two modes of 669 encapsulation - either IP/UDP encapsulated (with IP/UDP header) or 670 PW-ACH encapsulated (with no IP/UDP header) and provides support to 671 signal the AC status. The use of the VCCV control channel provides 672 the context, based on the MPLS-PW label, required to bind and 673 bootstrap the BFD session to a particular pseudo wire (FEC), 674 eliminating the need to exchange Discriminator values. 676 VCCV consists of two components: (1) signaled component to 677 communicate VCCV capabilities as part of VC label, and (2) switching 678 component to cause the PW payload to be treated as a control packet. 680 VCCV is not directly dependent upon the presence of a control plane. 681 The VCCV capability negotiation may be performed as part of the PW 682 signaling when LDP is used. In case of manual configuration of the 683 PW, it is the responsibility of the operator to set consistent 684 options at both ends. 686 4.5. IP Performance Metrics (IPPM) 688 4.5.1. Overview 690 The IPPM working group [IPPM FW] in the IETF defines common criteria 691 and metrics for measuring performance of IP traffic. Some of the key 692 RFCs published by this working group have defined metrics for 693 measuring connectivity [rfc2678], delay [RFC2679, RFC 2681], and 694 packet loss [RFC2681]. 696 The IPPM working group has defined not only metrics for performance 697 measurement, but also protocols that define how the measurement is 698 carried out. The One-way Active Measurement Protocol [OWAMP] and the 699 Two-Way Active Measurement Protocol [TWAMP] define a method and 700 protocol for measuring delay and packet loss in IP networks. 702 OWAMP [OWAMP] enables measurement of one-way characteristics of IP 703 networks, such as one-way packet loss and one-way delay. For its 704 proper operation OWAMP requires accurate time of day setting at its 705 end points. 707 TWAMP [TWAMP] is a similar protocol that enables measurement of two- 708 way (round trip) characteristics. TWAMP does not require accurate 709 time of day, and, furthermore, allows the use of a simple session 710 reflector, making it an attractive alternative to OWAMP. 712 OWAMP and TWAMP use two separate protocols: a Control plane protocol, 713 and a Test plane protocol. 715 4.5.2. Control and Test Protocols 717 OWAMP and TWAMP control protocols run over TCP, while the test 718 protocols run over UDP. The purpose of the control protocols is to 719 initiate, start, and stop test sessions, and for OWAMP to fetch 720 results. The test protocols introduce test packets (which contain 721 sequence numbers and timestamps) along the IP path under test 722 according to a schedule, and record statistics of packet arrival. 724 Multiple sessions may be simultaneously defined, each with a session 725 identifier, and defining the number of packets to be sent, the amount 726 of padding to be added (and thus the packet size), the start time, 727 and the send schedule (which can be either a constant time between 728 test packets or exponentially distributed pseudo-random). Statistics 729 recorded conform to the relevant IPPM RFCs. 731 OWAMP and TWAMP test traffic is designed with security in mind. Test 732 packets are hard to detect because they are simply UDP streams 733 between negotiated port numbers, with potentially nothing static in 734 the packets. OWAMP and TWAMP also include optional authentication 735 and encryption for both control and test packets. 737 4.5.3. OWAMP 739 OWAMP defines the following logical roles: Session-Sender, Session- 740 Receiver, Server, Control-Client, and Fetch-Client. The Session- 741 Sender originates test traffic that is received by the Session- 742 Receiver. The Server configures and manages the session, as well as 743 returning the results. The Control-Client initiates requests for 744 test sessions, triggers their start, and may trigger their 745 termination. The Fetch-Client requests the results of a completed 746 session. Multiple roles may be combined in a single host - for 747 example, one host may play the roles of Control-Client, Fetch-Client, 748 and Session-Sender, and a second playing the roles of Server and 749 Session-Receiver. 751 In a typical OWAMP session the Control-Client establishes a TCP 752 connection to port 861 of the Server, which responds with a server 753 greeting message indicating supported security/integrity modes. The 754 Control-Client responds with the chosen communications mode and the 755 Server accepts the modes. The Control-Client then requests and fully 756 describes a test session to which the Server responds with its 757 acceptance and supporting information. More than one test session 758 may be requested with additional messages. The Control-Client then 759 starts a test session and the Server acknowledges. The Session- 760 Sender then sends test packets with pseudorandom padding to the 761 Session-Receiver until the session is complete or until the Control- 762 client stops the session. Once finished, the Fetch-Client sends a 763 fetch request to the server, which responds with an acknowledgement 764 and immediately thereafter the result data. 766 4.5.4. TWAMP 768 TWAMP defines the following logical roles: session-sender, session- 769 reflector, server, and control-client. These are similar to the 770 OWAMP roles, except that the Session-Reflector does not collect any 771 packet information, and there is no need for a Fetch-Client. 773 In a typical TWAMP session the Control-Client establishes a TCP 774 connection to port 862 of the Server, and mode is negotiated as in 775 OWAMP. The Control-Client then requests sessions and starts them. 776 The Session-Sender sends test packets with pseudorandom padding to 777 the Session-Reflector which returns them with insertion of 778 timestamps. 780 4.6. ITU-T Y.1711 782 4.6.1. Overview 784 As mentioned above (4.3.), the IETF defined LSP Ping as an OAM 785 mechanism for MPLS. The ITU-T has also defined an OAM protocol for 786 MPLS, defined in recommendation [ITU-T Y.1711]. This recommendation 787 defines mechanisms for connectivity verification and fast failure 788 detection, as well as mechanism for reporting defects that have been 789 identified in an LSP. 791 MPLS OAM packets per Y.1711 are detected by a reserved MPLS label 792 value. The reserved value is 14, and is defined in [OAM Label] as the 793 'OAM Alert Label'. 795 4.6.2. Connectivity Verification (CV) 797 The CV function is used to detect connectivity defects in an LSP. CV 798 frames are sent proactively at a rate of 1 per second. Each frame 799 contains the Trail-Termination Source Identifier (TTSI), indicating 800 the identity of the transmitting LSR. 802 The CV function can detect any of the following defect conditions. 804 o Loss of Connectivity Verification (LOCV): A loss of connectivity 805 is detected when no CV OAM packets are received in a period of 3 806 consecutive transmission periods. 807 It should be noted that the LOCV defect is in fact loss of 808 continuity when using the terminology defined in 3 ..2.4. 810 o TTSI Mismatch: A TTSI mismatch is detected when a CV frame with an 811 unexpected TTSI is received. 813 o TTSI Mismerge: A TTSI mismerge is detected when the CV frames 814 received in a given LSP contain some frame with an expected TTSI, 815 and some frames with an unexpected TTSI. 817 o Excess: An excess is detected when at least 5 CV frames are 818 received during a period of 3 consecutive transmission periods. 820 4.6.3. Fast Failure Detection (FFD) 822 The FFD function is a proactive function, used for fast detection of 823 connectivity defects. While CV is typically sufficient for path 824 failure detection and reporting, protection switching mechanisms 825 typically require faster detection. FFD is very similar to CV in 826 terms of the packet format, and the possible defect conditions, but 827 FFD allows a configurable transmission frequency. The default 828 transmission rate of FFD frames is 20 per second, i.e., every 50 ms, 829 allowing fast detection for protection switching applications. 831 4.6.4. Forward Defect Indication (FDI) 833 The FDI function is used by an LSR to report a defect to affected 834 client layers, allowing them to suppress alarms about this defect. 835 In MPLS-TP OAM this function is referred to as Client Failure 836 Indication. 838 FDI packets are sent at a rate of 1 per second. 840 4.6.5. Backward Defect Indication (BDI) 842 The BDI function is used by an LSR to inform a peer LSR about a 843 defect condition on an LSP for which they are the end points of. 844 In MPLS-TP OAM this function is referred to as Remote Defect 845 Indication. 847 BDI packets are sent at the same transmission rate as FDI. 849 4.7. ITU-T Y.1731 851 4.7.1. Overview 853 The [ITU-T Y.1731] defines a protocol for Ethernet OAM. It is 854 presented in this document as a reference point. Y.1731 defines 855 various OAM functions, including continuity and connectivity 856 verification, and functions for performance monitoring. 858 4.7.2. ETH-CC 860 The Ethernet Continuity Check function is a proactive function that 861 allows a MEP to detect loss of continuity with any of the other MEPs 862 in the MEG. This function also allows detection of other defect 863 conditions, such as unintended connectivity between two MEGs (also 864 known as a mismerge). The ETH-CC function is used for one of three 865 possible applications: fault management, performance monitoring (see 866 4.6.10.), and protection switching. 868 Continuity Check Messages (CCM) are transmitted periodically at a 869 constant rate. There are 7 possible transmission periods, from 3.33 870 ms to 10 min. When the ETH-CC function detects a defect, it reports 871 one of the following defect conditions: 873 o Loss of continuity (LOC): Occurs when at least when no CCM 874 messages have been received from a peer MEP during a period of 3.5 875 times the configured transmission period. 877 o Unexpected MEG level: The MEG level is a 3-bit number that defines 878 the level of hierarchy of the MEG. This defect condition occurs 879 when a CCM is received from a peer MEP with a MEG level that is 880 lower than the expected MEG level. 882 o Mismerge: Occurs when a CCM is received from a peer MEP with an 883 unexpected MEG ID. 885 o Unexpected MEP: Occurs when a CCM is received from a peer MEP with 886 an unexpected transmitting MEP ID. 888 o Unexpected period: Occurs when the transmission period field in 889 the CCM does not match the expected transmission period value. 891 4.7.3. ETH-LB 893 The Ethernet loopback function verifies connectivity with a peer MEP 894 or MIP. The loopback function is performed on-demand, by sending a 895 loopback message (LBM) to the peer MEP or MIP. The peer node then 896 responds with a loopback reply (LBR). 898 More precisely, it is used for one of two purposes: 900 o Bidirectional connectivity test. 902 o Bidirectional in-service / out-of-service test. The in-service 903 mode refers to a test that is run under traffic, while the out-of- 904 service test requires other traffic to be halted. 906 4.7.4. ETH-TST 908 The test function is very similar to the loopback function, but is 909 unidirectional, i.e., the ETH-TST PDUs are terminated by the receiver 910 rather than being looped back to the sender. 912 4.7.5. ETH-LT 914 The Ethernet linktrace is an on-demand function that is used for path 915 discovery to a given target, or for locating a failure in a broken 916 path. 918 4.7.6. ETH-AIS 920 The Alarm Indication Signal indicates that a MEG should suppress 921 alarms about a defect condition at a lower MEG level, i.e., since a 922 defect has occurred in a lower hierarchy in the network, it should 923 not be reported by the current node. 925 A MEP that detects a failure periodically sends AIS messages to 926 higher hierarchies. AIS messages are sent periodically at a 927 recommended rate of 1 packet per second, until the defect condition 928 is resolved. 930 4.7.7. ETH-LCK 932 The lock function is used for administrative locking. A MEP can 933 initiate administrative locking, resulting in interruption of data, 934 e.g., for out-of-service ETH-LB or ETH-TST. 936 A MEP that initiates an administrative locking notifies its peer MEPs 937 to halt all relevant traffic until administrative/diagnostic 938 condition is removed. ETH-LCK frames are used to report to higher MEG 939 levels about the lock. The LCK frame, much like an AIS frame, 940 indicates to the receiving MEP that it should suppress alarms about 941 the locked link. 943 4.7.8. ETH-RDI 945 The Remote Defect Indication allows the sender to indicate that it 946 encountered a defect conditions. The receiving MEPs are then aware 947 that there is a defect condition in the MEG. 949 4.7.9. ETH-APS 951 The Y.1731 standard defines the frame format for Automatic Protection 952 Switching frames. The protection switching operations are defined in 953 other ITU-T standards. 955 4.7.10. ETH-LM 957 The loss measurement function allows a MEP to measure the packet loss 958 rate from/to a given MEP in the MEG. Each MEP maintains counters of 959 transmitted and received in-profile packets to/from each of its peer 960 MEPs. These counters are incorporated in the ETH-LM frames, allowing 961 the MEPs to compute the packet loss rate. 963 The ETH-LM function measures the far-end loss, referring to traffic 964 FROM the MEP to its peer, as well as the near-end loss, referring to 965 traffic from the peer MEP TO the local MEP. 967 ETH-LM is performed in one of two possible modes: 969 o Single-ended LM: in this mode loss measurement is performed on- 970 demand. The initiator sends an LM message (LMM) to its peer MEP, 971 and the peer responds with an LM reply (LMR). 973 o Dual-ended LM: in this mode loss measurement is performed 974 proactively. The continuity check message (CCM) is used for 975 proactive LM. The LM counters are piggy-backed into the CCM, and 976 allow proactive loss measurement. 978 4.7.11. ETH-DM 980 The delay measurement function is an on-demand function that allows a 981 MEP to measure the frame delay and frame delay variation to a peer 982 MEP. 984 ETH-DM can be performed in one of two modes of operation: 986 o One-way DM: in this mode, a MEP transmits a 1DM frame containing 987 the time of its transmission, TxTimeStampf. The receiving MEP 988 receives the 1DM frame and records the time of reception, RxTimef. 989 The receiving MEP can then compute the one-way delay by: RxTimef - 990 TxTimeStampf. 992 o Two-way DM: in this mode, a MEP transmits a delay measurement 993 message (DMM) containing its transmission time, TxTimeStampf. The 994 peer MEP receives the DMM and responds with a delay measurement 995 reply (DMR). Upon receiving the DMR, the initiating MEP records 996 the time of its reception, RxTimef, and computes the round trip 997 delay by: RxTimef - TxTimeStampf. 999 Each MEP maintains a time-of-day clock that is used for timestamping 1000 delay measurement frames. It should be noted that in one-way DM it is 1001 implicitly assumed that the clocks of the two peer MEPs are 1002 synchronized by a time synchronization protocol. 1004 4.8. IEEE 802.1ag 1006 4.8.1. Overview 1008 While the [ITU-T Y.1731] was defined in the ITU-T, the IEEE defined 1009 the [IEEE 802.1ag] as a standard for connectivity fault management in 1010 Ethernet based networks. While the two standards are to some extent 1011 overlapping, they can also be viewed as two complementary parts of a 1012 single Ethernet OAM picture. The two standards use a common packet 1013 format. There are a few differences between the two standards in 1014 terms of terminology: the term MEG level, used in Y.1731, as referred 1015 to as Maintenance Domain level in 802.1ag; the Y.1731 standard uses 1016 the term MEG, while the 802.1ag equivalent is Maintenance Association 1017 (MA). 1019 While Y.1731 defines multiple OAM functions (see section 4.6), the 1020 802.1ag standard focuses on three main OAM functions: continuity 1021 check, loopback, and linktrace, and defines them with great detail. 1023 4.8.2. Continuity Check 1025 See 4.6.2. 1027 4.8.3. Loopback 1029 See 4.6.3. 1031 4.8.4. Linktrace 1033 See 4.6.5. 1035 4.9. IEEE 802.3ah 1037 4.9.1. Overview 1039 The [IEEE 802.3ah] defines Ethernet for the Last Mile (EFM). With 1040 respect to OAM, this standard was designed as an Ethernet link-layer 1041 OAM, for single-hop Ethernet links, allowing to monitor remote 1042 networking devices that are not managed by a centralized management 1043 system. The OAM functions in this standard are described below. 1045 4.9.2. Remote Failure Indication 1047 This function allows a node to notify a peer about a defect in the 1048 receive path. Some physical interfaces allow unidirectional traffic, 1049 where even if one direction of the link fails, the reverse direction 1050 can still be used to convey the remote failure indication. 1052 4.9.3. Remote Loopback 1054 The remote loopback function provides a diagnostic mode that is used 1055 to verify the link connectivity, and to measure the packet loss rate. 1056 When a bridge interface is configured to loopback mode, all incoming 1057 traffic through the interface is looped and sent back to the 1058 originator. 1060 4.9.4. Link Monitoring 1062 Link monitoring provides an event notification function, allowing 1063 peer devices to communicate defect conditions and diagnostic 1064 information. 1066 4.10. MPLS-TP OAM 1068 4.10.1. Overview 1070 The MPLS working group is currently working on defining the OAM 1071 toolset that fulfill the requirements for MPLS-TP OAM. The full set 1072 of requirements for MPLS-TP OAM are defined in [MPLS-TP OAM], and 1073 include both general requirements for the behavior of the OAM 1074 mechanisms and a set of operations that should be supported by the 1075 OAM toolset. The set of mechanisms required are further elaborated 1076 in [MPLS-TP OAM FW], that describes the general architecture of the 1077 OAM system as well as giving overviews of the functionality of the 1078 OAM toolset. 1080 Some of the basic requirements for the OAM toolset for MPLS-TP are: 1082 o MPLS-TP OAM must be able to support both an IP based and non-IP 1083 based environment. If the network is IP based, i.e. IP routing and 1084 forwarding are available, then the MPLS-TP OAM toolset should rely 1085 on the IP routing and forwarding capabilities. On the other hand, 1086 in environments where IP functionality is not available, the OAM 1087 tools must still be able to operate without dependence on IP 1088 forwarding and routing. 1090 o OAM packets and the user traffic are required to be congruent 1091 (i.e. OAM packets are transmitted in-band) and there is a need to 1092 differentiate OAM packets from user-plane ones. Inherent in this 1093 requirement is the principle that MPLS-TP OAM be independent of 1094 any existing control-plane, although it should not preclude use of 1095 the control-plane functionality. 1097 4.10.2. Generic Associated Channel 1099 In order to address the requirement for in-band transmission of MPLS- 1100 TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh), 1101 defined in [G-ACh] for LSP-based OAM traffic. This mechanism is based 1102 on the same concepts as the PWE3 ACH and VCCV mechanisms. However, 1103 to address the needs of LSPs as differentiated from PW, the following 1104 concepts were defined for [G-ACh]: 1106 o An Associated Channel Header (ACH), that uses a format similar to 1107 the PW Control Word, is a 4-byte header that is added to OAM 1108 packets. 1110 o A Generic Associated Label (GAL). The GAL is a reserved MPLS label 1111 value. The reserved value is 13, and indicates the existence of 1112 the ACH immediately after it. 1114 4.10.3. MPLS-TP OAM Toolset 1116 To address the functionality that is required of the OAM toolset, the 1117 MPLS WG conducted an analysis of the existing IETF and ITU-T OAM 1118 mechanisms and their ability to fulfill the required functionality. 1119 The conclusions of this analysis are documented in [OAM Analysis]. 1120 The MPLS working group currently plans to use a mixture of OAM 1121 mechanisms that are based on various existing standards, and adapt 1122 them to the requirements of [MPLS-TP OAM]. Some of the main building 1123 blocks of this solution are based on: 1125 o Bidirectional Forwarding Detection ([BFD], [BFD LSP]) for 1126 proactive continuity check and connectivity verification. 1128 o LSP Ping as defined in [LSP Ping] for on-demand connectivity 1129 verification. 1131 o New protocol packets, using G-ACH, to address different 1132 functionality. 1134 o Performance measurement protocols that are based on the 1135 functionality that is described in [ITU-T Y.1731]. 1137 The following sub-sections describe the OAM tools that will be 1138 defined for MPLS-TP as described in [MPLS-TP OAM FW]. 1140 4.10.3.1. Continuity Check and Connectivity Verification 1142 Continuity Check and Connectivity Verification (CC-V) are OAM 1143 operations generally used in tandem, and compliment each other. These 1144 functions are generally run proactively, but may also be used on- 1145 demand, either due to bandwidth considerations or for diagnoses of a 1146 specific condition. Proactively [MPLS-TP OAM] states that the 1147 function should allow the MEPs to monitor the liveness and 1148 connectivity of a transport path. In on-demand mode, this function 1149 should support monitoring between the MEPs and, in addition, between 1150 a MEP and MIP.[MPLS-TP OAM FW] highlights the need for the CC-V 1151 messages to include unique identification of the MEG that is being 1152 monitored and the MEP that originated the message. The function, both 1153 proactively and in on-demand mode, need to be transmitted at regular 1154 rates pre-configured by the operator. 1156 4.10.3.2. Diagnostic Tests 1158 Diagnostic testing is a protocol that allows a network to send 1159 special test data on a transport path. For example, this could be 1160 used as part of bandwidth utilization measurement. 1162 4.10.3.3. Route Tracing 1164 [MPLS-TP OAM] defines that there is a need for functionality that 1165 would allow a path end-point to identify the intermediate and end- 1166 points of the path. This function would be used in on-demand mode. 1167 Normally, this path will be used for bidirectional PW, LSP, and 1168 sections, however, unidirectional paths may be supported only if a 1169 return path exists. 1171 4.10.3.4. Lock Instruct 1173 The Lock Instruct function is used to notify a transport path end- 1174 point of an administrative need to disable the transport path. This 1175 functionality will generally be used in conjunction with some 1176 intrusive OAM function, e.g. Performance measurement, Diagnostic 1177 testing, to minimize the side-effect on user data traffic. 1179 4.10.3.5. Lock Reporting 1181 Lock Reporting is a function used by an end-point of a path to report 1182 to its far-end end-point that a lock condition has been affected on 1183 the path. 1185 4.10.3.6. Alarm Reporting 1187 Alarm Reporting is a function used by an intermediate point of a 1188 path, that becomes aware of a fault on the path, to report to the 1189 end-points of the path. [MPLS-TP OAM FW] states that this may occur 1190 as a result of a defect condition discovered at a server sub-layer. 1192 This generates an Alarm Indication Signal (AIS) that continues until 1193 the fault is cleared. The consequent action of this function is 1194 detailed in [MPLS-TP OAM FW]. 1196 4.10.3.7. Remote Defect Indication 1198 Remote Defect Indication (RDI) is used proactively by a path end- 1199 point to report to its peer end-point that a defect is detected on a 1200 bidirectional connection between them. [MPLS-TP OAM] points out that 1201 this function may be applied to a unidirectional LSP only if there a 1202 return path exists. [MPLS-TP OAM FW] points out that this function 1203 is associated with the proactive CC-V function. 1205 4.10.3.8. Client Failure Indication 1207 Client Failure Indication (CFI) is defined in [MPLS-TP OAM] to allow 1208 the propagation information from one edge of the network to the 1209 other. The information concerns a defect to a client, in the case 1210 that the client does not support alarm notification. 1212 4.10.3.9. Packet Loss Measurement 1214 Packet Loss Measurement is a function used to verify the quality of 1215 the service. This function indicates the ratio of packets that are 1216 not delivered out of all packets that are transmitted by the path 1217 source. 1219 There are two possible ways of determining this measurement: 1221 o Using OAM packets, it is possible to compute the statistics based 1222 on a series of OAM packets. This, however, has the disadvantage of 1223 being artificial, and may not be representative since part of the 1224 packet loss may be dependent upon packet sizes. 1226 o Sending delimiting messages for the start and end of a measurement 1227 period during which the source and sink of the path count the 1228 packets transmitted and received. After the end delimiter, the 1229 ratio would be calculated by the path OAM entity. 1231 4.10.3.10. Packet Delay Measurement 1233 Packet Delay Measurement is a function that is used to measure one- 1234 way or two-way delay of a packet transmission between a pair of the 1235 end-points of a path (PW, LSP, or Section). Where: 1237 o One-way packet delay is the time elapsed from the start of 1238 transmission of the first bit of the packet by a source node until 1239 the reception of the last bit of that packet by the destination 1240 node. 1242 o Two-way packet delay is the time elapsed from the start of 1243 transmission of the first bit of the packet by a source node until 1244 the reception of the last bit of the loop-backed packet by the 1245 same source node, when the loopback is performed at the packet's 1246 destination node. 1248 Similarly to the packet loss measurement this could be performed in 1249 either of the two ways outlined above. 1251 4.11. Summary of OAM Functions 1253 Table 3 summarizes the OAM functions that are supported in each of 1254 the standards that were analyzed in this section. 1256 +-----------+-------+--------+--------+-----------+-------+--------+ 1257 | Standard |Continu|Connecti|Path |Defect |Perform|Other | 1258 | |ity |vity |Discover|Indications|ance |Function| 1259 | |Check |Verifica|y | |Monitor|s | 1260 | | |tion | | |ing | | 1261 +-----------+-------+--------+--------+-----------+-------+--------+ 1262 |ICMP Ping | |Echo | | | | | 1263 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1264 |BFD |BFD |BFD | | | | | 1265 | |Control|Echo | | | | | 1266 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1267 |LSP Ping | |"Ping" |"Tracero| | | | 1268 | | |mode |ute" | | | | 1269 | | | |mode | | | | 1270 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1271 |PW VCCV | |VCCV | | | | | 1272 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1273 |IPPM | | | | |-Delay | | 1274 | | | | | | measur| | 1275 | | | | | | ement | | 1276 | | | | | |-Packet| | 1277 | | | | | | loss | | 1278 | | | | | | measur| | 1279 | | | | | | ement | | 1280 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1281 |ITU-T |-CV | | | | | | 1282 |Y.1711 |-FFD | | | | | | 1283 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1284 |ITU-T |ETH-CC |ETH-LB |ETH-LT |-ETH-RDI |-ETH-LM|-ETH-LCK| 1285 |Y.1731 | | | |-ETH-AIS |-ETH-DM|-ETH-APS| 1286 | | | | | | |-ETH-TST| 1287 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1288 |IEEE |CC |Loopback|Linktrac| | | | 1289 |802.1ag | | |e | | | | 1290 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1291 |IEEE | |Remote | |-Remote | | | 1292 |802.3ah | |Loopback| | Failure | | | 1293 | | | | | Indication| | | 1294 | | | | |-Link | | | 1295 | | | | | Monitoring| | | 1296 + --------- + ----- + ------ + ------ + --------- + ----- + ------ + 1297 |MPLS-TP |CC |CV |Route |-Alarm |-LM |-Diagnos| 1298 |OAM | | |Tracing | Reporting |-DM | tic Tes| 1299 | | | | |-Client | | s | 1300 | | | | | Failure | |-Lock | 1301 | | | | | Indication| | | 1302 | | | | |-Remote | | | 1303 | | | | | Defect | | | 1304 | | | | | Indication| | | 1305 +-----------+-------+--------+--------+-----------+-------+--------+ 1306 Table 3 Summary of OAM Functions 1308 4.12. Summary of Continuity Check Mechanisms 1310 A key element in some of the OAM standards that are analyzed in this 1311 document is the continuity check. It is thus interesting to present a 1312 more detailed comparison of the connectivity check mechanisms defined 1313 in OAM standards. Table 4 can be viewed as an extension of Table 3, 1314 but is presented separately for convenience. The table compares the 1315 OAM standards that support a continuity check. MPLS-TP is not 1316 included in the comparison, as the continuity check mechanism in 1317 MPLS-TP has not yet been defined. 1319 The "Tx Interval" column in the table specifies the period between 1320 two consequent message transmissions, while the "Source Identifier" 1321 column specifies the name of the field in the OAM packet that is used 1322 as the identifier of the transmitter. The "Error Codes" column 1323 specifies the possible error codes when the unidirectional 1324 connectivity check detects a failure. 1326 +-----------+-------+--------+---+--------+------------------------+ 1327 | |Mechani|Tx |UC/|Source | Error | 1328 | |sm |Interval|MC |Identifi| Codes | 1329 | | | | |er | | 1330 +-----------+-------+--------+---+--------+------------------------+ 1331 |BFD |BFD |Negotiat|UC |My Discr| Control Detection Time | 1332 | |Control|ed durin| |iminator| Expired | 1333 | | |g sessio| | | | 1334 | | |n | | | | 1335 + --------- + ----- + ------ + - + ------ + ---------------------- + 1336 |ITU-T |CV |CV: 1s |UC |TTSI |-Loss of CV (LOCV) | 1337 |Y.1711 |FFD |FFD: par| | |-TTSI Mismatch | 1338 | | |ameter, | | |-TTSI Mismerge | 1339 | | |default:| | |-Excess | 1340 | | |50 ms | | | | 1341 + --------- + ----- + ------ + - + ------ + ---------------------- + 1342 |ITU-T |CC |7 possib|UC/|MEP ID |-Loss of Continuity(LOC)| 1343 |Y.1731 / | |le perio|MC | |-Unexpected MEG level | 1344 |IEEE | |ds: | | |-Mismerge | 1345 |802.1ag | |3 1/3 ms| | |-Unexpected MEP | 1346 | | |10 ms | | |-Unexpected period | 1347 | | |100 ms | | | | 1348 | | |1 s | | | | 1349 | | |10 s | | | | 1350 | | |1 min | | | | 1351 | | |10 min | | | | 1352 +-----------+-------+--------+---+--------+------------------------+ 1353 Table 4 Summary of OAM Terms 1355 5. Security Considerations 1357 There are no security implications imposed by this document. 1359 6. IANA Considerations 1361 There are no new IANA considerations implied by this document. 1363 7. Acknowledgments 1365 This document was prepared using 2-Word-v2.0.template.dot. 1367 8. References 1369 8.1. Normative References 1371 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1372 Requirement Levels", BCP 14, RFC 2119, March 1997. 1374 [LSP Ping] Kompella, K., Swallow, G., "Detecting Multi-Protocol 1375 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1376 February 2006. 1378 [MPLS OAM] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and 1379 Matsushima, S., "Operations and Management (OAM) 1380 Requirements for Multi-Protocol Label Switched (MPLS) 1381 Networks", RFC 4377, February 2006. 1383 [MPLS OAM FW] Allan, D., Nadeau, T., "A Framework for Multi-Protocol 1384 Label Switching (MPLS) Operations and Management 1385 (OAM)", RFC 4378, February 2006. 1387 [MPLS OAM P2MP] Yasukawa, S., Farrel, A., King, D., and Nadeau, T., 1388 "Operations and Management (OAM) Requirements for 1389 Point-to-Multipoint MPLS Networks", RFC 4687, 1390 September 2006. 1392 [OAM Label] Ohta, H., "Assignment of the 'OAM Alert Label' for 1393 Multiprotocol Label Switching Architecture (MPLS) 1394 Operation and Maintenance (OAM) Functions", RFC 3429, 1395 November 2002. 1397 [MPLS-TP OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements for 1398 OAM in MPLS Transport Networks", RFC 5860, May 2010. 1400 [G-ACh] Bocci, M., Vigoureux, M., Bryant, S., "MPLS Generic 1401 Associated Channel", RFC 5586, June 2009. 1403 [VCCV] Nadeau, T., Pignataro, C., "Pseudowire Virtual Circuit 1404 Connectivity Verification (VCCV): A Control Channel 1405 for Pseudowires", RFC 5085, December 2007. 1407 [ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, 1408 RFC 792, September 1981. 1410 [ICMPv6] Conta, A., Deering, S., and M. Gupta, "Internet Control 1411 Message Protocol (ICMPv6) for the Internet Protocol 1412 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1414 [IPPM FW] Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., 1415 "Framework for IP Performance Metrics", RFC 2330, May 1416 1998. 1418 [IPPM Con] Mahdavi, J., Paxson, V., "IPPM Metrics for Measuring 1419 Connectivity", RFC 2678, September 1999. 1421 [IPPM 1DM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way 1422 Delay Metric for IPPM", RFC 2679, September 1999. 1424 [IPPM 1LM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way 1425 Packet Loss Metric for IPPM", RFC 2680, September 1426 1999. 1428 [IPPM 2DM] Almes, G., Kalidindi, S., Zekauskas, M., "A Round-trip 1429 Delay Metric for IPPM", RFC 2681, September 1999. 1431 [OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and 1432 Zekauskas, M., "A One-way Active Measurement Protocol 1433 (OWAMP)", RFC 4656, September 2006. 1435 [TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and 1436 Babiarz, J., "A Two-Way Active Measurement Protocol 1437 (TWAMP)", RFC 5357, October 2008. 1439 [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection 1440 (BFD)", RFC 5880, June 2010. 1442 [BFD IP] Katz, D., Ward, D., "Bidirectional Forwarding Detection 1443 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 1444 2010. 1446 [BFD Gen] Katz, D., Ward, D., "Generic Application of 1447 Bidirectional Forwarding Detection (BFD)", RFC 5882, 1448 June 2010. 1450 [BFD Multi] Katz, D., Ward, D., "Bidirectional Forwarding Detection 1451 (BFD) for Multihop Paths", RFC 5883, June 2010. 1453 [BFD LSP] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, 1454 G., "Bidirectional Forwarding Detection (BFD) for MPLS 1455 Label Switched Paths (LSPs)", RFC 5884, June 2010. 1457 [BFD VCCV] Nadeau, T., Pignataro, C., "Bidirectional Forwarding 1458 Detection (BFD) for the Pseudowire Virtual Circuit 1459 Connectivity Verification (VCCV)", RFC 5885, June 1460 2010. 1462 [IEEE 802.1ag]"Connectivity Fault Management", December 2007. 1464 [ITU-T Y.1731]"OAM Functions and Mechanisms for Ethernet-based 1465 Networks", February 2008. 1467 [ITU-T Y.1711]"Operation & Maintenance mechanism for MPLS networks", 1468 February 2004. 1470 [IEEE 802.3ah]"Media Access Control Parameters, Physical Layers, and 1471 Management Parameters for Subscriber Access Networks", 1472 clause 57, September 2004. 1474 8.2. Informative References 1476 [OAM Soup] Andersson, L., Van Helvoort, H., Bonica, R., Romascanu, 1477 D., Mansfield, S., "The OAM Acronym Soup", draft-ietf- 1478 opsawg-mpls-tp-oam-def, June 2010. 1480 [OAM Analysis] Sprecher, N., Bellagamba, E., Weingarten, Y., "MPLS-TP 1481 OAM Analysis", draft-ietf-mpls-tp-oam-analysis, July 1482 2010. 1484 [MPLS-TP OAM FW] Busi, I., Niven-Jenkins, B., Allan, D., "MPLS-TP OAM 1485 Framework", work-in-progress, draft-ietf-mpls-tp-oam- 1486 framework, July, 2010. 1488 [MPLS-TP Term]Van Helvoort, H., Andersson, L., Sprecher, N., "A 1489 Thesaurus for the Terminology used in Multiprotocol 1490 Label Switching Transport Profile (MPLS-TP) 1491 drafts/RFCs and ITU-T's Transport Network 1492 Recommendations", draft-ietf-mpls-tp-rosetta-stone, 1493 May 2010. 1495 [MPLS-TP Ping BFD] Bahadur, N., Aggarwal, R., Ward, D., Nadeau, T., 1496 Sprecher, N., Weingarten, Y., "LSP-Ping and BFD 1497 encapsulation over ACH", draft-ietf-mpls-tp-lsp-ping- 1498 bfd-procedures, March 2010. 1500 [P2MP Ping] Saxena, S., Farrel, A. , Yasukawa, S., "Detecting Data 1501 Plane Failures in Point-to-Multipoint Multiprotocol 1502 Label Switching (MPLS) - Extensions to LSP Ping", 1503 draft-ietf-mpls-p2mp-lsp-ping, March 2010. 1505 [ITU-T G.806] "Characteristics of transport equipment - Description 1506 methodology and generic functionality", January 2009. 1508 Authors' Addresses 1510 Tal Mizrahi 1511 Marvell 1512 6 Hamada St. 1513 Yokneam, 20692 1514 Israel 1516 Email: talmi@marvell.com 1518 Nurit Sprecher 1519 Nokia Siemens Networks 1520 3 Hanagar St. Neve Ne'eman B 1521 Hod Hasharon, 45241 1522 Israel 1524 Email: nurit.sprecher@nsn.com 1526 Elisa Bellagamba 1527 Ericsson 1528 6 Farogatan St. 1529 Stockholm, 164 40 1530 Sweden 1532 Phone: +46 761440785 1533 Email: elisa.bellagamba@ericsson.com 1535 Yaacov Weingarten 1536 Nokia Siemens Networks 1537 3 Hanagar St. Neve Ne'eman B 1538 Hod Hasharon, 45241 1539 Israel 1541 Phone: +972-9-775 1827 1542 Email: yaacov.weingarten@nsn.com