idnits 2.17.1 draft-ietf-opsawg-oam-overview-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 28, 2014) is 3681 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2679 (ref. 'IPPM-1DM') (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 2680 (ref. 'IPPM-1LM') (Obsoleted by RFC 7680) -- Obsolete informational reference (is this intentional?): RFC 4379 (ref. 'LSP-Ping') (Obsoleted by RFC 8029) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Operations and Management Area Working Group T. Mizrahi 2 Internet Draft Marvell 3 Intended status: Informational N. Sprecher 4 Expires: September 2014 Nokia Solutions and Networks 5 E. Bellagamba 6 Ericsson 7 Y. Weingarten 9 March 28, 2014 11 An Overview of 12 Operations, Administration, and Maintenance (OAM) Tools 13 draft-ietf-opsawg-oam-overview-16.txt 15 Abstract 17 Operations, Administration, and Maintenance (OAM) is a general term 18 that refers to a toolset for fault detection and isolation, and for 19 performance measurement. Over the years various OAM tools have been 20 defined for various layers in the protocol stack. 22 This document summarizes some of the OAM tools defined in the IETF in 23 the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP), 24 pseudowires, and TRILL. This document focuses on tools for detecting 25 and isolating failures in networks and for performance monitoring. 26 Control and management aspects of OAM are outside the scope of this 27 document. Network repair functions such as Fast Reroute (FRR) and 28 protection switching, which are often triggered by OAM protocols, are 29 also out of the scope of this document. 31 The target audience of this document includes network equipment 32 vendors, network operators and standards development organizations, 33 and can be used as an index to some of the main OAM tools defined in 34 the IETF. This document provides a brief description of each of the 35 OAM tools in the IETF. At the end of the document a list of the OAM 36 toolsets and a list of the OAM functions are presented as a summary. 38 Status of this Memo 40 This Internet-Draft is submitted to IETF in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF), its areas, and its working groups. Note that 45 other groups may also distribute working documents as Internet- 46 Drafts. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 The list of current Internet-Drafts can be accessed at 54 http://www.ietf.org/ietf/1id-abstracts.txt. 56 The list of Internet-Draft Shadow Directories can be accessed at 57 http://www.ietf.org/shadow.html. 59 This Internet-Draft will expire on September 28, 2014. 61 Copyright Notice 63 Copyright (c) 2014 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents 68 (http://trustee.ietf.org/license-info) in effect on the date of 69 publication of this document. Please review these documents 70 carefully, as they describe your rights and restrictions with respect 71 to this document. Code Components extracted from this document must 72 include Simplified BSD License text as described in Section 4.e of 73 the Trust Legal Provisions and are provided without warranty as 74 described in the Simplified BSD License. 76 Table of Contents 78 1. Introduction ................................................. 4 79 1.1. Background .............................................. 4 80 1.2. Target Audience.......................................... 5 81 1.3. OAM-related Work in the IETF ............................ 6 82 1.4. Focusing on the Data Plane .............................. 7 83 2. Terminology .................................................. 7 84 2.1. Abbreviations ........................................... 7 85 2.2. Terminology used in OAM Standards ....................... 9 86 2.2.1. General Terms ...................................... 9 87 2.2.2. Operations, Administration and Maintenance ......... 9 88 2.2.3. Functions, Tools and Protocols .................... 10 89 2.2.4. Data Plane, Control Plane and Management Plane .... 11 90 2.2.5. The Players ....................................... 12 91 2.2.6. Proactive and On-demand Activation ................ 12 92 2.2.7. Connectivity Verification and Continuity Checks ... 13 93 2.2.8. Connection Oriented vs. Connectionless Communication14 94 2.2.9. Point-to-point vs. Point-to-multipoint Services ... 14 95 2.2.10. Failures ......................................... 15 96 3. OAM Functions ............................................... 16 97 4. OAM Tools in the IETF - a Detailed Description .............. 16 98 4.1. IP Ping ................................................ 17 99 4.2. IP Traceroute .......................................... 17 100 4.3. Bidirectional Forwarding Detection (BFD) ............... 18 101 4.3.1. Overview .......................................... 18 102 4.3.2. Terminology ....................................... 19 103 4.3.3. BFD Control ....................................... 19 104 4.3.4. BFD Echo .......................................... 19 105 4.4. MPLS OAM ............................................... 20 106 4.4.1. LSP Ping .......................................... 20 107 4.4.2. BFD for MPLS ...................................... 21 108 4.4.3. OAM for Virtual Private Networks (VPN) over MPLS .. 21 109 4.5. MPLS-TP OAM ............................................ 21 110 4.5.1. Overview .......................................... 21 111 4.5.2. Terminology ....................................... 22 112 4.5.3. Generic Associated Channel ........................ 24 113 4.5.4. MPLS-TP OAM Toolset ............................... 24 114 4.5.4.1. Continuity Check and Connectivity Verification 25 115 4.5.4.2. Route Tracing ................................ 25 116 4.5.4.3. Lock Instruct ................................ 25 117 4.5.4.4. Lock Reporting ............................... 25 118 4.5.4.5. Alarm Reporting .............................. 26 119 4.5.4.6. Remote Defect Indication ..................... 26 120 4.5.4.7. Client Failure Indication .................... 26 121 4.5.4.8. Performance Monitoring ....................... 26 122 4.5.4.8.1. Packet Loss Measurement (LM) ............ 26 123 4.5.4.8.2. Packet Delay Measurement (DM) ........... 27 124 4.6. Pseudowire OAM ......................................... 27 125 4.6.1. Pseudowire OAM using Virtual Circuit Connectivity 126 Verification (VCCV) ...................................... 27 127 4.6.2. Pseudowire OAM using G-ACh ........................ 29 128 4.6.3. Attachment Circuit - Pseudowire Mapping ........... 29 129 4.7. OWAMP and TWAMP......................................... 29 130 4.7.1. Overview .......................................... 29 131 4.7.2. Control and Test Protocols ........................ 30 132 4.7.3. OWAMP ............................................. 31 133 4.7.4. TWAMP ............................................. 31 134 4.8. TRILL .................................................. 32 135 5. Summary ..................................................... 32 136 5.1. Summary of OAM Tools ................................... 32 137 5.2. Summary of OAM Functions ............................... 35 138 5.3. Guidance to Network Equipment Vendors .................. 36 139 6. Security Considerations ..................................... 36 140 7. IANA Considerations ......................................... 37 141 8. Acknowledgments ............................................. 37 142 9. References .................................................. 37 143 9.1. Normative References ................................... 37 144 9.2. Informative References ................................. 37 145 Appendix A. List of OAM Documents .............................. 43 146 A.1. List of IETF OAM Documents ............................. 43 147 A.2. List of Selected Non-IETF OAM Documents ................ 48 149 1. Introduction 151 OAM is a general term that refers to a toolset for detecting, 152 isolating and reporting failures and for monitoring the network 153 performance. 155 There are several different interpretations to the "OAM" acronym. 156 This document refers to Operations, Administration and Maintenance, 157 as recommended in Section 3 of [OAM-Def]. 159 This document summarizes some of the OAM tools defined in the IETF in 160 the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP), 161 pseudowires, and TRILL. 163 This document focuses on tools for detecting and isolating failures 164 and for performance monitoring. Hence, this document focuses on the 165 tools used for monitoring and measuring the data plane; control and 166 management aspects of OAM are outside the scope of this document. 167 Network repair functions such as Fast Reroute (FRR) and protection 168 switching, which are often triggered by OAM protocols, are also out 169 of the scope of this document. 171 1.1. Background 173 OAM was originally used in traditional communication technologies 174 such as E1 and T1, evolving into PDH and then later in SONET/SDH. ATM 175 was probably the first technology to include inherent OAM support 176 from day one, while in other technologies OAM was typically defined 177 in an ad hoc manner after the technology was already defined and 178 deployed. Packet-based networks were traditionally considered 179 unreliable and best-effort. As packet-based networks evolved, they 180 have become the common transport for both data and telephony, 181 replacing traditional transport protocols. Consequently, packet-based 182 networks were expected to provide a similar "carrier grade" 183 experience, and specifically to support more advanced OAM functions, 184 beyond ICMP and router hellos, that were traditionally used for fault 185 detection. 187 As typical networks have a multi-layer architecture, the set of OAM 188 protocols similarly take a multi-layer structure; each layer has its 189 own OAM protocols. Moreover, OAM can be used at different levels of 190 hierarchy in the network to form a multi-layer OAM solution, as shown 191 in the example in Figure 1. 193 Figure 1 illustrates a network in which IP traffic between two 194 customer edges is transported over an MPLS provider network. MPLS OAM 195 is used at the provider-level for monitoring the connection between 196 the two provider edges, while IP OAM is used at the customer-level 197 for monitoring the end-to-end connection between the two customer 198 edges. 200 |<-------------- Customer-level OAM -------------->| 201 IP OAM (Ping, Traceroute, OWAMP, TWAMP) 203 |<- Provider-level OAM ->| 204 MPLS OAM (LSP Ping) 206 +-----+ +----+ +----+ +-----+ 207 | | | |========================| | | | 208 | |-------| | MPLS | |-------| | 209 | | IP | | | | IP | | 210 +-----+ +----+ +----+ +-----+ 211 Customer Provider Provider Customer 212 Edge Edge Edge Edge 214 Figure 1 Example: Multi-layer OAM 216 1.2. Target Audience 218 The target audience of this document includes: 220 o Standards development organizations - both IETF working groups and 221 non-IETF organizations can benefit from this document when 222 designing new OAM protocols, or when looking to reuse existing OAM 223 tools for new technologies. 225 o Network equipment vendors and network operators - can use this 226 document as an index to some of the common IETF OAM tools. 228 It should be noted that some background in OAM is necessary in order 229 to understand and benefit from this document. Specifically, the 230 reader is assumed to be familiar with the term OAM [OAM-Def], the 231 motivation for using OAM, and the distinction between OAM and network 232 management [OAM-Mng]. 234 1.3. OAM-related Work in the IETF 236 This memo provides an overview of the different sets of OAM tools 237 defined by the IETF. The set of OAM tools described in this memo are 238 applicable to IP unicast, MPLS, pseudowires, MPLS Transport Profile 239 (MPLS-TP), and TRILL. While OAM tools that are applicable to other 240 technologies exist, they are beyond the scope of this memo. 242 This document focuses on IETF documents that have been published as 243 RFCs, while other ongoing OAM-related work is outside the scope. 245 The IETF has defined OAM protocols and tools in several different 246 contexts. We roughly categorize these efforts into a few sets of OAM- 247 related RFCs, listed in Table 1. Each set defines a logically-coupled 248 set of RFCs, although the sets are in some cases intertwined by 249 common tools and protocols. 251 The discussion in this document is ordered according to these sets 252 (the acronyms and abbreviations are listed in Section 2.1.). 254 +--------------+------------+ 255 | Toolset | Transport | 256 | | Technology | 257 +--------------+------------+ 258 |IP Ping | IPv4/IPv6 | 259 +--------------+------------+ 260 |IP Traceroute | IPv4/IPv6 | 261 +--------------+------------+ 262 |BFD | generic | 263 +--------------+------------+ 264 |MPLS OAM | MPLS | 265 +--------------+------------+ 266 |MPLS-TP OAM | MPLS-TP | 267 +--------------+------------+ 268 |Pseudowire OAM| Pseudowires| 269 +--------------+------------+ 270 |OWAMP and | IPv4/IPv6 | 271 |TWAMP | | 272 +--------------+------------+ 273 |TRILL OAM | TRILL | 274 +--------------+------------+ 275 Table 1 OAM Toolset Packages in the IETF Documents 277 This document focuses on OAM tools that have been developed in the 278 IETF. A short summary of some of the significant OAM standards that 279 have been developed in other standard organizations is presented in 280 Appendix A.2. 282 1.4. Focusing on the Data Plane 284 OAM tools may, and quite often do, work in conjunction with a control 285 plane and/or management plane. OAM provides instrumentation tools 286 for measuring and monitoring the data plane. OAM tools often use 287 control plane functions, e.g., to initialize OAM sessions and to 288 exchange various parameters. The OAM tools communicate with the 289 management plane to raise alarms, and often OAM tools may be 290 activated by the management (as well as by the control plane), e.g., 291 to locate and localize problems. 293 The considerations of the control plane maintenance tools and the 294 functionality of the management plane are out of scope for this 295 document, which concentrates on presenting the data plane tools that 296 are used for OAM. Network repair functions such as Fast Reroute (FRR) 297 and protection switching, which are often triggered by OAM protocols, 298 are also out of the scope of this document. 300 Since OAM protocols are used for monitoring the data plane, it is 301 imperative for OAM tools to be capable of testing the actual data 302 plane with as much accuracy as possible. Thus, it is important to 303 enforce fate-sharing between OAM traffic that monitors the data plane 304 and the data plane traffic it monitors. 306 2. Terminology 308 2.1. Abbreviations 310 ACH Associated Channel Header 312 AIS Alarm Indication Signal 314 ATM Asynchronous Transfer Mode 316 BFD Bidirectional Forwarding Detection 318 CC Continuity Check 320 CV Connectivity Verification 322 DM Delay Measurement 323 ECMP Equal Cost Multiple Paths 325 FEC Forwarding Equivalence Class 327 FRR Fast Reroute 329 G-ACh Generic Associated Channel 331 GAL Generic Associated Label 333 ICMP Internet Control Message Protocol 335 L2TP Layer Two Tunneling Protocol 337 L2VPN Layer Two Virtual Private Network 339 L3VPN Layer Three Virtual Private Network 341 LCCE L2TP Control Connection Endpoint 343 LDP Label Distribution Protocol 345 LER Label Edge Router 347 LM Loss Measurement 349 LSP Label Switched Path 351 LSR Label Switched Router 353 ME Maintenance Entity 355 MEG Maintenance Entity Group 357 MEP MEG End Point 359 MIP MEG Intermediate Point 361 MP Maintenance Point 363 MPLS Multiprotocol Label Switching 365 MPLS-TP MPLS Transport Profile 367 MTU Maximum Transmission Unit 369 OAM Operations, Administration, and Maintenance 370 OWAMP One-way Active Measurement Protocol 372 PDH Plesiochronous Digital Hierarchy 374 PE Provider Edge 376 PSN Public Switched Network 378 PW Pseudowire 380 PWE3 Pseudowire Emulation Edge-to-Edge 382 RBridge Routing Bridge 384 RDI Remote Defect Indication 386 SDH Synchronous Digital Hierarchy 388 SONET Synchronous Optical Networking 390 TRILL Transparent Interconnection of Lots of Links 392 TTL Time To Live 394 TWAMP Two-way Active Measurement Protocol 396 VCCV Virtual Circuit Connectivity Verification 398 VPN Virtual Private Network 400 2.2. Terminology used in OAM Standards 402 2.2.1. General Terms 404 A wide variety of terms is used in various OAM standards. This 405 section presents a comparison of the terms used in various OAM 406 standards, without fully quoting the definition of each term. 408 An interesting overview of the term OAM and its derivatives is 409 presented in [OAM-Def]. A thesaurus of terminology for MPLS-TP terms 410 is presented in [TP-Term], and provides a good summary of some of the 411 OAM related terminology. 413 2.2.2. Operations, Administration and Maintenance 415 The following definition of OAM is quoted from [OAM-Def]: 417 The components of the "OAM" acronym (and provisioning) are defined as 418 follows: 420 o Operations - Operation activities are undertaken to keep the 421 network (and the services that the network provides) up and 422 running. It includes monitoring the network and finding problems. 423 Ideally these problems should be found before users are affected. 425 o Administration - Administration activities involve keeping track 426 of resources in the network and how they are used. It includes 427 all the bookkeeping that is necessary to track networking 428 resources and the network under control. 430 o Maintenance - Maintenance activities are focused on facilitating 431 repairs and upgrades -- for example, when equipment must be 432 replaced, when a router needs a patch for an operating system 433 image, or when a new switch is added to a network. Maintenance 434 also involves corrective and preventive measures to make the 435 managed network run more effectively, e.g., adjusting device 436 configuration and parameters. 438 2.2.3. Functions, Tools and Protocols 440 OAM Function 442 An OAM function is an instrumentation measurement type or diagnostic. 444 OAM functions are the atomic building blocks of OAM, where each 445 function defines an OAM capability. 447 Typical examples of OAM functions are presented in Section 3. 449 OAM Protocol 451 A protocol used for implementing one or more OAM functions. 453 The OWAMP-Test [OWAMP] is an example of an OAM protocol. 455 OAM Tool 457 An OAM tool is a specific means of applying one or more OAM 458 functions. 460 In some cases an OAM protocol *is* an OAM tool, e.g., OWAMP-Test. In 461 other cases an OAM tool uses a set of protocols that are not strictly 462 OAM-related; for example, Traceroute (Section 4.2.) can be 463 implemented using UDP and ICMP messages, without using an OAM 464 protocol per se. 466 2.2.4. Data Plane, Control Plane and Management Plane 468 Data Plane 470 The data plane is the set of functions used to transfer data in the 471 stratum or layer under consideration [ITU-Terms]. 473 The Data Plane is also known as the Forwarding Plane or the User 474 Plane. 476 Control Plane 478 The control plane is the set of protocols and mechanisms that enable 479 routers to efficiently learn how to forward packets towards their 480 final destination (based on [Comp]). 482 Management Plane 484 The term Management Plane, as described in [Mng], is used to describe 485 the exchange of management messages through management protocols 486 (often transported by IP and by IP transport protocols) between 487 management applications and the managed entities such as network 488 nodes. 490 Data Plane vs. Control Plane vs. Management Plane 492 The distinction between the planes is at times a bit vague. For 493 example, the definition of "Control Plane" above may imply that OAM 494 tools such as ping, BFD and others are in fact in the control plane. 496 This document focuses on tools used for monitoring the data plane. 497 While these tools could arguably be considered to be in the control 498 plane, these tools monitor the data plane, and hence it is imperative 499 to have fate-sharing between OAM traffic that monitors the data plane 500 and the data plane traffic it monitors. 502 Another potentially vague distinction is between the management plane 503 and control plane. The management plane should be seen as separate 504 from, but possibly overlapping with, the control plane (based on 505 [Mng]). 507 2.2.5. The Players 509 An OAM tool is used between two (or more) peers. Various terms are 510 used in IETF documents to refer to the players that take part in OAM. 511 Table 2 summarizes the terms used in each of the toolsets discussed 512 in this document. 514 +--------------------------+--------------------------+ 515 | Toolset | Terms | 516 +--------------------------+--------------------------+ 517 | Ping / Traceroute |-Host | 518 | ([ICMPv4], [ICMPv6], |-Node | 519 | [TCPIP-Tools]) |-Interface | 520 | |-Gateway | 521 + ------------------------ + ------------------------ + 522 | BFD [BFD] | System | 523 + ------------------------ + ------------------------ + 524 | MPLS OAM [MPLS-OAM-FW] | LSR | 525 + ------------------------ + ------------------------ + 526 | MPLS-TP OAM [TP-OAM-FW] |-End Point - MEP | 527 | |-Intermediate Point - MIP | 528 + ------------------------ + ------------------------ + 529 | Pseudowire OAM [VCCV] |-PE | 530 | |-LCCE | 531 + ------------------------ + ------------------------ + 532 | OWAMP and TWAMP |-Host | 533 | ([OWAMP], [TWAMP]) |-End system | 534 + ------------------------ + ------------------------ + 535 | TRILL OAM [TRILL-OAM] |-RBridge | 536 +--------------------------+--------------------------+ 537 Table 2 Maintenance Point Terminology 539 2.2.6. Proactive and On-demand Activation 541 The different OAM tools may be used in one of two basic types of 542 activation: 544 Proactive 545 Proactive activation - indicates that the tool is activated on a 546 continual basis, where messages are sent periodically, and errors are 547 detected when a certain number of expected messages are not received. 549 On-demand 551 On-demand activation - indicates that the tool is activated 552 "manually" to detect a specific anomaly. 554 2.2.7. Connectivity Verification and Continuity Checks 556 Two distinct classes of failure management functions are used in OAM 557 protocols, connectivity verification and continuity checks. The 558 distinction between these terms is defined in [MPLS-TP-OAM], and is 559 used similarly in this document. 561 Continuity Check 563 Continuity checks are used to verify that a destination is reachable, 564 and are typically sent proactively, though they can be invoked on- 565 demand as well. 567 Connectivity Verification 569 A connectivity verification function allows Alice to check whether 570 she is connected to Bob or not. It is noted that while the CV 571 function is performed in the data plane, the "expected path" is 572 predetermined either in the control plane or in the management plane. 573 A connectivity verification (CV) protocol typically uses a CV 574 message, followed by a CV reply that is sent back to the originator. 575 A CV function can be applied proactively or on-demand. 577 Connectivity verification tools often perform path verification as 578 well, allowing Alice to verify that messages from Bob are received 579 through the correct path, thereby verifying not only that the two MPs 580 are connected, but also that they are connected through the expected 581 path, allowing detection of unexpected topology changes. 583 Connectivity verification functions can also be used for checking the 584 MTU of the path between the two peers. 586 Connectivity verification and continuity checks are considered 587 complementary mechanisms, and are often used in conjunction with each 588 other. 590 2.2.8. Connection Oriented vs. Connectionless Communication 592 Connection Oriented 594 In Connection Oriented technologies an end-to-end connection is 595 established (by a control protocol or provisioned by a management 596 system) prior to the transmission of data. 598 Typically a connection identifier is used to identify the connection. 599 In connection oriented technologies it is often the case (although 600 not always) that all packets belonging to a specific connection use 601 the same route through the network. 603 Connectionless 605 In Connectionless technologies data is typically sent between end 606 points without prior arrangement. Packets are routed independently 607 based on their destination address, and hence different packets may 608 be routed in a different way across the network. 610 Discussion 612 The OAM tools described in this document include tools that support 613 connection oriented technologies, as well as tools for connectionless 614 technologies. 616 In connection oriented technologies OAM is used to monitor a 617 *specific* connection; OAM packets are forwarded through the same 618 route as the data traffic and receive the same treatment. In 619 connectionless technologies, OAM is used between a source and 620 destination pair without defining a specific connection. Moreover, in 621 some cases the route of OAM packets may differ from the one of the 622 data traffic. For example, the connectionless IP Ping (Section 4.1.) 623 tests the reachability from a source to a given destination, while 624 the connection oriented LSP Ping (Section 4.4.) is used for 625 monitoring a specific LSP (connection), and provides the capability 626 to monitor all the available paths used by an LSP. 628 It should be noted that in some cases connectionless protocols are 629 monitored by connection oriented OAM protocols. For example, while IP 630 is a connectionless protocol, it can monitored by BFD (Section 4.3. 631 ), which is connection oriented. 633 2.2.9. Point-to-point vs. Point-to-multipoint Services 635 Point-to-point (P2P) 636 A P2P service delivers data from a single source to a single 637 destination. 639 Point-to-multipoint (P2MP) 641 A P2MP service delivers data from a single source to a one or more 642 destinations (based on [Signal]). 644 An MP2MP service is a service that delivers data from more than one 645 source to one or more receivers (based on [Signal]). 647 Note: the two definitions for P2MP and MP2MP are quoted from 648 [Signal]. Although [Signal] describes a specific case of P2MP and 649 MP2MP which is MPLS-specific, these two definitions also apply to 650 non-MPLS cases. 652 Discussion 654 The OAM tools described in this document include tools for P2P 655 services, as well as tools for P2MP services. 657 The distinction between P2P services and P2MP services affects the 658 corresponding OAM tools. A P2P service is typically simpler to 659 monitor, as it consists of a single pair of end points. P2MP and 660 MP2MP services present several challenges. For example, in a P2MP 661 service, the OAM mechanism not only verifies that each of the 662 destinations is reachable from the source, but also verifies that the 663 P2MP distribution tree is intact and loop-free. 665 2.2.10. Failures 667 The terms Failure, Fault, and Defect are used interchangeably in the 668 standards, referring to a malfunction that can be detected by a 669 connectivity or a continuity check. In some standards, such as 670 802.1ag [IEEE802.1Q] , there is no distinction between these terms, 671 while in other standards each of these terms refers to a different 672 type of malfunction. 674 The terminology used in IETF MPLS-TP OAM is based on the ITU-T 675 terminology, which distinguishes between these three terms in 676 [ITU-T-G.806]; 678 Fault 680 The term Fault refers to an inability to perform a required action, 681 e.g., an unsuccessful attempt to deliver a packet. 683 Defect 685 The term Defect refers to an interruption in the normal operation, 686 such as a consecutive period of time where no packets are delivered 687 successfully. 689 Failure 691 The term Failure refers to the termination of the required function. 692 While a Defect typically refers to a limited period of time, a 693 failure refers to a long period of time. 695 3. OAM Functions 697 This subsection provides a brief summary of the common OAM functions 698 used in OAM-related standards. These functions are used as building 699 blocks in the OAM standards described in this document. 701 o Connectivity Verification (CV), Path Verification and Continuity 702 Checks (CC): 703 As defined in Section 2.2.7. 705 o Path Discovery / Fault Localization: 706 This function can be used to trace the route to a destination, 707 i.e., to identify the nodes along the route to the destination. 708 When more than one route is available to a specific destination, 709 this function traces one of the available routes. When a failure 710 occurs, this function attempts to detect the location of the 711 failure. 712 Note that the term route tracing (or Traceroute) that is used in 713 the context of IP and MPLS, is sometimes referred to as path 714 tracing in the context of other protocols, such as TRILL. 716 o Performance Monitoring: 717 Typically refers to: 719 o Loss Measurement (LM) - monitors the packet loss rate. 721 o Delay Measurement (DM) - monitors the delay and delay 722 variation (jitter). 724 4. OAM Tools in the IETF - a Detailed Description 726 This section presents a detailed description of the sets of OAM- 727 related tools in each of the toolsets in Table 1. 729 4.1. IP Ping 731 Ping is a common network diagnosis application for IP networks that 732 uses ICMP. According to [NetTerms], 'Ping' is an abbreviation for 733 Packet internet groper, although the term has been so commonly used 734 that it stands on its own. As defined in [NetTerms], it is a program 735 used to test reachability of destinations by sending them an ICMP 736 echo request and waiting for a reply. 738 The ICMP Echo request/reply exchange in Ping is used as a continuity 739 check function for the Internet Protocol. The originator transmits an 740 ICMP Echo request packet, and the receiver replies with an Echo 741 reply. ICMP ping is defined in two variants, [ICMPv4] is used for 742 IPv4, and [ICMPv6] is used for IPv6. 744 Ping can be invoked either to a unicast destination or to a multicast 745 destination. In the latter case, all members of the multicast group 746 send an Echo reply back to the originator. 748 Ping implementations typically use ICMP messages. UDP Ping is a 749 variant that uses UDP messages instead of ICMP echo messages. 751 Ping is a single-ended continuity check, i.e., it allows the 752 *initiator* of the Echo request to test the reachability. If it is 753 desirable for both ends to test the reachability, both ends have to 754 invoke Ping independently. 756 Note that since ICMP filtering is deployed in some routers and 757 firewalls, the usefulness of Ping is sometimes limited in the wider 758 internet. This limitation is equally relevant to Traceroute. 760 4.2. IP Traceroute 762 Traceroute ([TCPIP-Tools], [NetTools]) is an application that allows 763 users to discover a path between an IP source and an IP destination. 765 The most common way to implement Traceroute [TCPIP-Tools] is 766 described as follows. Traceroute sends a sequence of UDP packets to 767 UDP port 33434 at the destination. By default, Traceroute begins by 768 sending three packets (the number of packets is configurable in most 769 Traceroute implementations), each with an IP Time-To-Live (or Hop 770 Limit in IPv6) value of one to the destination. These packets expire 771 as soon as they reach the first router in the path. Consequently, 772 that router sends three ICMP Time Exceeded Messages back to the 773 Traceroute application. Traceroute now sends another three UDP 774 packets, each with the TTL value of 2. These messages cause the 775 second router to return ICMP messages. This process continues, with 776 ever increasing values for the TTL field, until the packets actually 777 reach the destination. Because no application listens to port 33434 778 at the destination, the destination returns ICMP Destination 779 Unreachable Messages indicating an unreachable port. This event 780 indicates to the Traceroute application that it is finished. The 781 Traceroute program displays the round-trip delay associated with each 782 of the attempts. 784 While Traceroute is a tool that finds *a* path from A to B, it should 785 be noted that traffic from A to B is often forwarded through Equal 786 Cost Multiple Paths (ECMP). Paris Traceroute [PARIS] is an extension 787 to Traceroute that attempts to discovers all the available paths from 788 A to B by scanning different values of header fields (such as UDP 789 ports) in the probe packets. 791 It is noted that Traceroute is an application, and not a protocol. As 792 such, it has various different implementations. One of the most 793 common ones uses UDP probe packets, as described above. Other 794 implementations exist that use other types of probe messages, such as 795 ICMP or TCP. 797 Note that IP routing may be asymmetric. While Traceroute discovers a 798 path between a source and destination, it does not reveal the reverse 799 path. 801 A few ICMP extensions ([ICMP-MP], [ICMP-Int]) have been defined in 802 the context of Traceroute. These documents define several extensions, 803 including extensions to the ICMP Destination Unreachable message, 804 that can be used by Traceroute applications. 806 Traceroute allows path discovery to *unicast* destination addresses. 807 A similar tool [mtrace] was defined for multicast destination 808 addresses, allowing to trace the route that a multicast IP packet 809 takes from a source to a particular receiver. 811 4.3. Bidirectional Forwarding Detection (BFD) 813 4.3.1. Overview 815 While multiple OAM tools have been defined for various protocols in 816 the protocol stack, Bidirectional Forwarding Detection [BFD], defined 817 by the IETF BFD working group, is a generic OAM tool that can be 818 deployed over various encapsulating protocols, and in various medium 819 types. The IETF has defined variants of the protocol for IP ([BFD- 820 IP], [BFD-Multi]), for MPLS LSPs [BFD-LSP], and for pseudowires [BFD- 821 VCCV]. The usage of BFD in MPLS-TP is defined in [TP-CC-CV]. 823 BFD includes two main OAM functions, using two types of BFD packets: 824 BFD Control packets, and BFD Echo packets. 826 4.3.2. Terminology 828 BFD operates between *systems*. The BFD protocol is run between two 829 or more systems after establishing a *session*. 831 4.3.3. BFD Control 833 BFD supports a bidirectional continuity check, using BFD control 834 packets, that are exchanged within a BFD session. BFD sessions 835 operate in one of two modes: 837 o Asynchronous mode (i.e., proactive): in this mode BFD control 838 packets are sent periodically. When the receiver detects that no 839 BFD control packets have been received during a predetermined 840 period of time, a failure is reported. 842 o Demand mode: in this mode, BFD control packets are sent on-demand. 843 Upon need, a system initiates a series of BFD control packets to 844 check the continuity of the session. BFD control packets are sent 845 independently in each direction. 847 Each of the end-points (referred to as systems) of the monitored path 848 maintains its own session identification, called a Discriminator, 849 both of which are included in the BFD Control Packets that are 850 exchanged between the end-points. At the time of session 851 establishment, the Discriminators are exchanged between the two-end 852 points. In addition, the transmission (and reception) rate is 853 negotiated between the two end-points, based on information included 854 in the control packets. These transmission rates may be renegotiated 855 during the session. 857 During normal operation of the session, i.e., when no failures have 858 been detected, the BFD session is in the Up state. If no BFD Control 859 packets are received during a period of time called the Detection 860 Time, the session is declared to be Down. The detection time is a 861 function of the pre-configured or negotiated transmission rate, and a 862 parameter called Detect Mult. Detect Mult determines the number of 863 missing BFD Control packets that cause the session to be declared as 864 Down. This parameter is included in the BFD Control packet. 866 4.3.4. BFD Echo 868 A BFD echo packet is sent to a peer system, and is looped back to the 869 originator. The echo function can be used proactively, or on-demand. 871 The BFD echo function has been defined in BFD for IPv4 and IPv6 872 ([BFD-IP]), but is not used in BFD for MPLS LSPs, PWs, or in BFD for 873 MPLS-TP. 875 4.4. MPLS OAM 877 The IETF MPLS working group has defined OAM for MPLS LSPs. The 878 requirements and framework of this effort are defined in 879 [MPLS-OAM-FW] and [MPLS-OAM], respectively. The corresponding OAM 880 tool defined, in this context, is LSP Ping [LSP-Ping]. OAM for P2MP 881 services is defined in [MPLS-P2MP]. 883 BFD for MPLS [BFD-LSP] is an alternative means for detecting data- 884 plane failures, as described below. 886 4.4.1. LSP Ping 888 LSP Ping is modeled after the Ping/Traceroute paradigm and thus it 889 may be used in one of two modes: 891 o "Ping" mode: In this mode LSP Ping is used for end-to-end 892 connectivity verification between two LERs. 894 o "Traceroute" mode: This mode is used for hop-by-hop fault 895 isolation. 897 LSP Ping is based on ICMP Ping operation (of data-plane connectivity 898 verification) with additional functionality to verify data-plane vs. 899 control-plane consistency for a Forwarding Equivalence Class (FEC) 900 and also identify Maximum Transmission Unit (MTU) problems. 902 The Traceroute functionality may be used to isolate and localize MPLS 903 faults, using the Time-to-live (TTL) indicator to incrementally 904 identify the sub-path of the LSP that is successfully traversed 905 before the faulty link or node. 907 The challenge in MPLS networks is that the traffic of a given LSP may 908 be load balanced across Equal Cost Multiple paths (ECMP). LSP Ping 909 monitors all the available paths of an LSP by monitoring its 910 different Forwarding Equivalence Classes (FEC). Note that MPLS-TP 911 does not use ECMP, and thus does not require OAM over multiple paths. 913 Another challenge is that an MPLS LSP does not necessarily have a 914 return path; traffic that is sent back from the egress LSR to the 915 ingress LSR is not necessarily sent over an MPLS LSP, but can be sent 916 through a different route, such as an IP route. Thus, responding to 917 an LSP Ping message is not necessarily as trivial as in IP Ping, 918 where the responder just swaps the source and destination IP 919 addresses. Note that this challenge is not applicable to MPLS-TP, 920 where a return path is always available. 922 It should be noted that LSP Ping supports unique identification of 923 the LSP within an addressing domain. The identification is checked 924 using the full FEC identification. LSP Ping is extensible to include 925 additional information needed to support new functionality, by use of 926 Type-Length-Value (TLV) constructs. The usage of TLVs is typically 927 handled by the control plane, as it is not easy to implement in 928 hardware. 930 LSP Ping supports both asynchronous, as well as, on-demand 931 activation. 933 4.4.2. BFD for MPLS 935 BFD [BFD-LSP] can be used to detect MPLS LSP data plane failures. 937 A BFD session is established for each MPLS LSP that is being 938 monitored. BFD Control packets must be sent along the same path as 939 the monitored LSP. If the LSP is associated with multiple FECs, a BFD 940 session is established for each FEC. 942 While LSP Ping can be used for detecting MPLS data plane failures and 943 for verifying the MPLS LSP data plane against the control plane, BFD 944 can only be used for the former. BFD can be used in conjunction with 945 LSP Ping, as is the case in MPLS-TP (see Section 4.5.4.). 947 4.4.3. OAM for Virtual Private Networks (VPN) over MPLS 949 The IETF has defined two classes of VPNs, Layer 2 VPNs (L2VPN) and 950 Layer 3 VPNs (L3VPN). [L2VPN-OAM] provides the requirements and 951 framework for OAM in the context of Layer 2 Virtual Private Networks 952 (L2VPN), and specifically it also defines the OAM layering of L2VPNs 953 over MPLS. [L3VPN-OAM] provides a framework for the operation and 954 management of Layer 3 Virtual Private Networks (L3VPNs). 956 4.5. MPLS-TP OAM 958 4.5.1. Overview 960 The MPLS working group has defined the OAM toolset that fulfills the 961 requirements for MPLS-TP OAM. The full set of requirements for MPLS- 962 TP OAM are defined in [MPLS-TP-OAM], and include both general 963 requirements for the behavior of the OAM tools and a set of 964 operations that should be supported by the OAM toolset. The set of 965 mechanisms required are further elaborated in [TP-OAM-FW], which 966 describes the general architecture of the OAM system as well as 967 giving overviews of the functionality of the OAM toolset. 969 Some of the basic requirements for the OAM toolset for MPLS-TP are: 971 o MPLS-TP OAM must be able to support both an IP based and non-IP 972 based environment. If the network is IP based, i.e., IP routing 973 and forwarding are available, then the MPLS-TP OAM toolset should 974 rely on the IP routing and forwarding capabilities. On the other 975 hand, in environments where IP functionality is not available, the 976 OAM tools must still be able to operate without dependence on IP 977 forwarding and routing. 979 o OAM packets and the user traffic are required to be congruent 980 (i.e., OAM packets are transmitted in-band) and there is a need to 981 differentiate OAM packets from ordinary user packets in the data 982 plane. Inherent in this requirement is the principle that MPLS-TP 983 OAM be independent of any existing control-plane, although it 984 should not preclude use of the control-plane functionality. 985 OAM packets are identified by the Generic Associated Label (GAL), 986 which is a reserved MPLS label value (13). 988 4.5.2. Terminology 990 Maintenance Entity (ME) 992 The MPLS-TP OAM tools are designed to monitor and manage a 993 Maintenance Entity (ME). An ME, as defined in [TP-OAM-FW], defines a 994 relationship between two points of a transport path to which 995 maintenance and monitoring operations apply. 997 The term Maintenance Entity (ME) is used in ITU-T Recommendations 998 (e.g., [ITU-T-Y1731]), as well as in the MPLS-TP terminology 999 ([TP-OAM-FW]). 1001 Maintenance Entity Group (MEG) 1003 The collection of one or more MEs that belongs to the same transport 1004 path and that are maintained and monitored as a group are known as a 1005 Maintenance Entity Group (based on [TP-OAM-FW]). 1007 Maintenance Point (MP) 1009 A Maintenance Point (MP) is a functional entity that is defined at a 1010 node in the network, and can initiate and/or react to OAM messages. 1011 This document focuses on the data-plane functionality of MPs, while 1012 MPs interact with the control plane and with the management plane as 1013 well. 1015 The term MP is used in IEEE 802.1ag, and was similarly adopted in 1016 MPLS-TP ([TP-OAM-FW]). 1018 Maintenance End Point (MEP) 1020 A Maintenance End Point (MEP) is one of the end points of an ME, and 1021 can initiate OAM messages and respond to them (based on [TP-OAM-FW]). 1023 Maintenance Intermediate Point (MIP) 1025 In between MEPs, there are zero or more intermediate points, called 1026 Maintenance Entity Group Intermediate Points (based on [TP-OAM-FW]). 1028 A Maintenance Intermediate Point (MIP) is an intermediate point that 1029 does not generally initiate OAM frames (one exception to this is the 1030 use of AIS notifications), but is able to respond to OAM frames that 1031 are destined to it. A MIP in MPLS-TP identifies OAM packets destined 1032 to it by the expiration of the TTL field in the OAM packet. The term 1033 Maintenance Point is a general term for MEPs and MIPs. 1035 Up and Down MEPs 1037 The IEEE 802.1ag [IEEE802.1Q] defines a distinction between Up MEPs 1038 and Down MEPs. A MEP monitors traffic either in the direction facing 1039 the network, or in the direction facing the bridge. A Down MEP is a 1040 MEP that receives OAM packets from, and transmits them to the 1041 direction of the network. An Up MEP receives OAM packets from, and 1042 transmits them to the direction of the bridging entity. MPLS-TP ([TP- 1043 OAM-FW]) uses a similar distinction on the placement of the MEP - 1044 either at the ingress, egress, or forwarding function of the node 1045 (Down / Up MEPs). This placement is important for localization of a 1046 failure. 1048 Note that the terms Up and Down MEPs are entirely unrelated to the 1049 conventional up/down terminology, where down means faulty, and up is 1050 nonfaulty. 1052 The distinction between Up and Down MEPs was defined in [TP-OAM-FW], 1053 but has not been used in other MPLS-TP RFCs, as of the writing of 1054 this document. 1056 4.5.3. Generic Associated Channel 1058 In order to address the requirement for in-band transmission of MPLS- 1059 TP OAM traffic, MPLS-TP uses a Generic Associated Channel (G-ACh), 1060 defined in [G-ACh] for LSP-based OAM traffic. This mechanism is based 1061 on the same concepts as the PWE3 ACH [PW-ACH] and VCCV [VCCV] 1062 mechanisms. However, to address the needs of LSPs as differentiated 1063 from PW, the following concepts were defined for [G-ACh]: 1065 o An Associated Channel Header (ACH), that uses a format similar to 1066 the PW Control Word [PW-ACH], is a 4-byte header that is prepended 1067 to OAM packets. 1069 o A Generic Associated Label (GAL). The GAL is a reserved MPLS label 1070 value (13) that indicates that the packet is an ACH packet and the 1071 payload follows immediately after the label stack. 1073 It should be noted that while the G-ACh was defined as part of the 1074 MPLS-TP definition effort, the G-ACh is a generic tool that can be 1075 used in MPLS in general, and not only in MPLS-TP. 1077 4.5.4. MPLS-TP OAM Toolset 1079 To address the functionality that is required of the OAM toolset, the 1080 MPLS WG conducted an analysis of the existing IETF and ITU-T OAM 1081 tools and their ability to fulfill the required functionality. The 1082 conclusions of this analysis are documented in [OAM-Analys]. MPLS-TP 1083 uses a mixture of OAM tools that are based on previous standards, and 1084 adapted to the requirements of [MPLS-TP-OAM]. Some of the main 1085 building blocks of this solution are based on: 1087 o Bidirectional Forwarding Detection ([BFD], [BFD-LSP]) for 1088 proactive continuity check and connectivity verification. 1090 o LSP Ping as defined in [LSP-Ping] for on-demand connectivity 1091 verification. 1093 o New protocol packets, using G-ACH, to address different 1094 functionality. 1096 o Performance measurement protocols that are based on the 1097 functionality that is described in [ITU-T-Y1731]. 1099 The following sub-sections describe the OAM tools defined for MPLS-TP 1100 as described in [TP-OAM-FW]. 1102 4.5.4.1. Continuity Check and Connectivity Verification 1104 Continuity Check and Connectivity Verification are presented in 1105 Section 2.2.7. of this document. As presented there, these tools may 1106 be used either proactively or on-demand. When using these tools 1107 proactively, they are generally used in tandem. 1109 For MPLS-TP there are two distinct tools, the proactive tool is 1110 defined in [TP-CC-CV] while the on-demand tool is defined in 1111 [OnDemand-CV]. In on-demand mode, this function should support 1112 monitoring between the MEPs and, in addition, between a MEP and MIP. 1113 [TP-OAM-FW] highlights, when performing Connectivity Verification, 1114 the need for the CC-V messages to include unique identification of 1115 the MEG that is being monitored and the MEP that originated the 1116 message. 1118 The proactive tool [TP-CC-CV] is based on extensions to BFD (see 1119 Section 4.3.) with the additional limitation that the transmission 1120 and receiving rates are based on configuration by the operator. The 1121 on-demand tool [OnDemand-CV] is an adaptation of LSP Ping (see 1122 Section 4.4.) for the required behavior of MPLS-TP. 1124 4.5.4.2. Route Tracing 1126 [MPLS-TP-OAM] defines that there is a need for functionality that 1127 would allow a path end-point to identify the intermediate and end- 1128 points of the path. This function would be used in on-demand mode. 1129 Normally, this path will be used for bidirectional PW, LSP, and 1130 sections, however, unidirectional paths may be supported only if a 1131 return path exists. The tool for this is based on the LSP Ping (see 1132 Section 4.4.) functionality and is described in [OnDemand-CV]. 1134 4.5.4.3. Lock Instruct 1136 The Lock Instruct function [Lock-Loop] is used to notify a transport 1137 path end-point of an administrative need to disable the transport 1138 path. This functionality will generally be used in conjunction with 1139 some intrusive OAM function, e.g., Performance measurement, 1140 Diagnostic testing, to minimize the side-effect on user data traffic. 1142 4.5.4.4. Lock Reporting 1144 Lock Reporting is a function used by an end-point of a path to report 1145 to its far-end end-point that a lock condition has been affected on 1146 the path. 1148 4.5.4.5. Alarm Reporting 1150 Alarm Reporting [TP-Fault] provides the means to suppress alarms 1151 following detection of defect conditions at the server sub-layer. 1152 Alarm reporting is used by an intermediate point of a path, that 1153 becomes aware of a fault on the path, to report to the end-points of 1154 the path. [TP-OAM-FW] states that this may occur as a result of a 1155 defect condition discovered at a server sub-layer. This generates an 1156 Alarm Indication Signal (AIS) that continues until the fault is 1157 cleared. The consequent action of this function is detailed in 1158 [TP-OAM-FW]. 1160 4.5.4.6. Remote Defect Indication 1162 Remote Defect Indication (RDI) is used proactively by a path end- 1163 point to report to its peer end-point that a defect is detected on a 1164 bidirectional connection between them. [MPLS-TP-OAM] points out that 1165 this function may be applied to a unidirectional LSP only if a return 1166 path exists. [TP-OAM-FW] points out that this function is associated 1167 with the proactive CC-V function. 1169 4.5.4.7. Client Failure Indication 1171 Client Failure Indication (CFI) is defined in [MPLS-TP-OAM] to allow 1172 the propagation information from one edge of the network to the 1173 other. The information concerns a defect to a client, in the case 1174 that the client does not support alarm notification. 1176 4.5.4.8. Performance Monitoring 1178 The definition of MPLS performance monitoring was motivated by the 1179 MPLS-TP requirements [MPLS-TP-OAM], but was defined generically for 1180 MPLS in [MPLS-LM-DM]. An additional document [TP-LM-DM] defines a 1181 performance monitoring profile for MPLS-TP. 1183 4.5.4.8.1. Packet Loss Measurement (LM) 1185 Packet Loss Measurement is a function used to verify the quality of 1186 the service. Packet loss, as defined in [IPPM-1LM] and [MPLS-TP-OAM], 1187 indicates the ratio of the number of user packets lost to the total 1188 number of user packets sent during a defined time interval. 1190 There are two possible ways of determining this measurement: 1192 o Using OAM packets, it is possible to compute the statistics based 1193 on a series of OAM packets. This, however, has the disadvantage of 1194 being artificial, and may not be representative since part of the 1195 packet loss may be dependent upon packet sizes and upon the 1196 implementation of the MEPs that take part in the protocol. 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.5.4.8.2. Packet Delay Measurement (DM) 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, as defined in [IPPM-1DM], is the time 1210 elapsed from the start of transmission of the first bit of the 1211 packet by a source node until the reception of the last bit of 1212 that packet by the destination node. Note that one-way delay 1213 measurement requires the clocks of the two end-points to be 1214 synchronized. 1216 o Two-way packet delay, as defined in [IPPM-2DM], is the time 1217 elapsed from the start of transmission of the first bit of the 1218 packet by a source node until the reception of the last bit of the 1219 loop-backed packet by the same source node, when the loopback is 1220 performed at the packet's destination node. Note that due to 1221 possible path asymmetry, the one-way packet delay from one end- 1222 point to another is not necessarily equal to half of the two-way 1223 packet delay. 1224 As opposed to one-way delay measurement, two-way delay measurement 1225 does not require the two end-points to be synchronized. 1227 For each of these two metrics, the DM function allows the MEP to 1228 measure the delay, as well as the delay variation. Delay measurement 1229 is performed by exchanging timestamped OAM packets between the 1230 participating MEPs. 1232 4.6. Pseudowire OAM 1234 4.6.1. Pseudowire OAM using Virtual Circuit Connectivity Verification 1235 (VCCV) 1237 VCCV, as defined in [VCCV], provides a means for end-to-end fault 1238 detection and diagnostics tools to be used for PWs (regardless of the 1239 underlying tunneling technology). The VCCV switching function 1240 provides a control channel associated with each PW. [VCCV] defines 1241 three Control Channel (CC) types, i.e., three possible methods for 1242 transmitting and identifying OAM messages: 1244 o CC Type 1: In-band VCCV, as described in [VCCV], is also referred 1245 to as "PWE3 Control Word with 0001b as first nibble". It uses the 1246 PW Associated Channel Header [PW-ACH]. 1248 o CC Type 2: Out-of-band VCCV [VCCV], is also referred to as "MPLS 1249 Router Alert Label". In this case the control channel is created 1250 by using the MPLS router alert label [MPLS-ENCAPS] immediately 1251 above the PW label. 1253 o CC Type 3: TTL expiry VCCV [VCCV], is also referred to as "MPLS PW 1254 Label with TTL == 1", i.e., the control channel is identified when 1255 the value of the TTL field in the PW label is set to 1. 1257 VCCV currently supports the following OAM tools: ICMP Ping, LSP Ping, 1258 and BFD. ICMP and LSP Ping are IP encapsulated before being sent over 1259 the PW ACH. BFD for VCCV [BFD-VCCV] supports two modes of 1260 encapsulation - either IP/UDP encapsulated (with IP/UDP header) or 1261 PW-ACH encapsulated (with no IP/UDP header) and provides support to 1262 signal the AC status. The use of the VCCV control channel provides 1263 the context, based on the MPLS-PW label, required to bind and 1264 bootstrap the BFD session to a particular pseudo wire (FEC), 1265 eliminating the need to exchange Discriminator values. 1267 VCCV consists of two components: (1) signaled component to 1268 communicate VCCV capabilities as part of VC label, and (2) switching 1269 component to cause the PW payload to be treated as a control packet. 1271 VCCV is not directly dependent upon the presence of a control plane. 1272 The VCCV capability advertisement may be performed as part of the PW 1273 signaling when LDP is used. In case of manual configuration of the 1274 PW, it is the responsibility of the operator to set consistent 1275 options at both ends. The manual option was created specifically to 1276 handle MPLS-TP use cases where no control plane was a requirement. 1277 However, new use cases such as pure mobile backhaul find this 1278 functionality useful too. 1280 The PWE3 working group has conducted an implementation survey of VCCV 1281 [VCCV-SURVEY], which analyzes which VCCV mechanisms are used in 1282 practice. 1284 4.6.2. Pseudowire OAM using G-ACh 1286 As mentioned above, VCCV enables OAM for PWs by using a control 1287 channel for OAM packets. When PWs are used in MPLS-TP networks, 1288 rather than the control channels defined in VCCV, the G-ACh can be 1289 used as an alternative control channel. The usage of the G-ACh for 1290 PWs is defined in [PW-G-ACh]. 1292 4.6.3. Attachment Circuit - Pseudowire Mapping 1294 The PWE3 working group has defined a mapping and notification of 1295 defect states between a pseudowire (PW) and the Attachment Circuits 1296 (ACs) of the end-to-end emulated service. This mapping is of key 1297 importance to the end-to-end functionality. Specifically, the mapping 1298 is provided by [PW-MAP], by [L2TP-EC] for L2TPv3 pseudowires, and 1299 Section 5.3 of [ATM-L2] for ATM. 1301 [L2VPN-OAM] provides the requirements and framework for OAM in the 1302 context of Layer 2 Virtual Private Networks (L2VPN), and specifically 1303 it also defines the OAM layering of L2VPNs over pseudowires. 1305 The mapping defined in [Eth-Int] allows an end-to-end emulated 1306 Ethernet service over pseudowires. 1308 4.7. OWAMP and TWAMP 1310 4.7.1. Overview 1312 The IPPM working group in the IETF defines common criteria and 1313 metrics for measuring performance of IP traffic ([IPPM-FW]). Some of 1314 the key RFCs published by this working group have defined metrics for 1315 measuring connectivity [IPPM-Con], delay ([IPPM-1DM], [IPPM-2DM]), 1316 and packet loss [IPPM-1LM]. It should be noted that the work of the 1317 IETF in the context of performance metrics is not limited to IP 1318 networks; [PM-CONS] presents general guidelines for considering new 1319 performance metrics. 1321 The IPPM working group has defined not only metrics for performance 1322 measurement, but also protocols that define how the measurement is 1323 carried out. The One-way Active Measurement Protocol [OWAMP] and the 1324 Two-Way Active Measurement Protocol [TWAMP] define a method and 1325 protocol for measuring performance metrics in IP networks. 1327 OWAMP [OWAMP] enables measurement of one-way characteristics of IP 1328 networks, such as one-way packet loss and one-way delay. For its 1329 proper operation OWAMP requires accurate time of day setting at its 1330 end points. 1332 TWAMP [TWAMP] is a similar protocol that enables measurement of both 1333 one-way and two-way (round trip) characteristics. 1335 OWAMP and TWAMP are both comprised of two separate protocols: 1337 o OWAMP-Control/TWAMP-Control: used to initiate, start, and stop 1338 test sessions and to fetch their results. Continuity Check and 1339 Connectivity Verification are tested and confirmed by establishing 1340 the OWAMP/TWAMP Control Protocol TCP connection. 1342 o OWAMP-Test/TWAMP-Test: used to exchange test packets between two 1343 measurement nodes. Enables the loss and delay measurement 1344 functions, as well as detection of other anomalies, such as packet 1345 duplication and packet reordering. 1347 It should be noted that while [OWAMP] and [TWAMP] define tools for 1348 performance measurement, they do not define the accuracy of these 1349 tools. The accuracy depends on scale, implementation and network 1350 configurations. 1352 Alternative protocols for performance monitoring are defined, for 1353 example, in MPLS-TP OAM ([MPLS-LM-DM], [TP-LM-DM]), and in Ethernet 1354 OAM [ITU-T-Y1731]. 1356 4.7.2. Control and Test Protocols 1358 OWAMP and TWAMP control protocols run over TCP, while the test 1359 protocols run over UDP. The purpose of the control protocols is to 1360 initiate, start, and stop test sessions, and for OWAMP to fetch 1361 results. The test protocols introduce test packets (which contain 1362 sequence numbers and timestamps) along the IP path under test 1363 according to a schedule, and record statistics of packet arrival. 1364 Multiple sessions may be simultaneously defined, each with a session 1365 identifier, and defining the number of packets to be sent, the amount 1366 of padding to be added (and thus the packet size), the start time, 1367 and the send schedule (which can be either a constant time between 1368 test packets or exponentially distributed pseudo-random). Statistics 1369 recorded conform to the relevant IPPM RFCs. 1371 From a security perspective, OWAMP and TWAMP test packets are hard to 1372 detect because they are simply UDP streams between negotiated port 1373 numbers, with potentially nothing static in the packets. OWAMP and 1374 TWAMP also include optional authentication and encryption for both 1375 control and test packets. 1377 4.7.3. OWAMP 1379 OWAMP defines the following logical roles: Session-Sender, Session- 1380 Receiver, Server, Control-Client, and Fetch-Client. The Session- 1381 Sender originates test traffic that is received by the Session- 1382 Receiver. The Server configures and manages the session, as well as 1383 returning the results. The Control-Client initiates requests for 1384 test sessions, triggers their start, and may trigger their 1385 termination. The Fetch-Client requests the results of a completed 1386 session. Multiple roles may be combined in a single host - for 1387 example, one host may play the roles of Control-Client, Fetch-Client, 1388 and Session-Sender, and a second playing the roles of Server and 1389 Session-Receiver. 1391 In a typical OWAMP session the Control-Client establishes a TCP 1392 connection to port 861 of the Server, which responds with a server 1393 greeting message indicating supported security/integrity modes. The 1394 Control-Client responds with the chosen communications mode and the 1395 Server accepts the mode. The Control-Client then requests and fully 1396 describes a test session to which the Server responds with its 1397 acceptance and supporting information. More than one test session 1398 may be requested with additional messages. The Control-Client then 1399 starts a test session and the Server acknowledges, and instructs the 1400 Session-Sender to start the test. The Session-Sender then sends test 1401 packets with pseudorandom padding to the Session-Receiver until the 1402 session is complete or until the Control-client stops the session. 1403 Once finished, the Session-Sender reports to the Server which 1404 recovers data from the Session-Receiver. The Fetch-Client can then 1405 send a fetch request to the Server, which responds with an 1406 acknowledgement and immediately thereafter the result data. 1408 4.7.4. TWAMP 1410 TWAMP defines the following logical roles: session-sender, session- 1411 reflector, server, and control-client. These are similar to the 1412 OWAMP roles, except that the Session-Reflector does not collect any 1413 packet information, and there is no need for a Fetch-Client. 1415 In a typical TWAMP session the Control-Client establishes a TCP 1416 connection to port 862 of the Server, and mode is negotiated as in 1417 OWAMP. The Control-Client then requests sessions and starts them. 1418 The Session-Sender sends test packets with pseudorandom padding to 1419 the Session-Reflector which returns them with insertion of 1420 timestamps. 1422 4.8. TRILL 1424 The requirements of OAM in TRILL are defined in [TRILL-OAM]. The 1425 challenge in TRILL OAM, much like in MPLS networks, is that traffic 1426 between RBridges RB1 and RB2 may be forwarded through more than one 1427 path. Thus, an OAM protocol between RBridges RB1 and RB2 must be able 1428 to monitor all the available paths between the two RBridge. 1430 During the writing of this document the detailed definition of the 1431 TRILL OAM tools are still work in progress. This subsection presents 1432 the main requirements of TRILL OAM. 1434 The main requirements defined in [TRILL-OAM] are: 1436 o Continuity Checking (CC) - the TRILL OAM protocol must support a 1437 function for CC between any two RBridges RB1 and RB2. 1439 o Connectivity Verification (CV) - connectivity between two RBridges 1440 RB1 and RB2 can be verified on a per-flow basis. 1442 o Path Tracing - allows an RBridge to trace all the available paths 1443 to a peer RBridge. 1445 o Performance monitoring - allows an RBridge to monitor the packet 1446 loss and packet delay to a peer RBridge. 1448 5. Summary 1450 This section summarizes the OAM tools and functions presented in this 1451 document. This summary is an index to some of the main OAM tools 1452 defined in the IETF. This compact index that can be useful to all 1453 readers from network operators to standards development 1454 organizations. The summary includes a short subsection that presents 1455 some guidance to network equipment vendors. 1457 5.1. Summary of OAM Tools 1459 This subsection provides a short summary of each of the OAM toolsets 1460 described in this document. 1462 A detailed list of the RFCs related to each toolset is given in 1463 Appendix A.1. 1465 +-----------+------------------------------------------+------------+ 1466 | Toolset | Description | Transport | 1467 | | | Technology | 1468 +-----------+------------------------------------------+------------+ 1469 |IP Ping | Ping ([IntHost], [NetTerms]) is a simple | IPv4/IPv6 | 1470 | | application for testing reachability that| | 1471 | | uses ICMP Echo messages ([ICMPv4], | | 1472 | | [ICMPv6]). | | 1473 +-----------+------------------------------------------+------------+ 1474 |IP | Traceroute ([TCPIP-Tools], [NetTools]) is| IPv4/IPv6 | 1475 |Traceroute | an application that allows users to trace| | 1476 | | the path between an IP source and an IP | | 1477 | | destination, i.e., to identify the nodes | | 1478 | | along the path. If more than one path | | 1479 | | exists between the source and destination| | 1480 | | Traceroute traces *a* path. The most | | 1481 | | common implementation of Traceroute | | 1482 | | uses UDP probe messages, although there | | 1483 | | are other implementations that use | | 1484 | | different probes, such as ICMP or TCP. | | 1485 | | Paris Traceroute [PARIS] is an extension | | 1486 | | that attempts to discovers all the | | 1487 | | available paths from A to B by scanning | | 1488 | | different values of header fields. | | 1489 +-----------+------------------------------------------+------------+ 1490 |BFD | Bidirectional Forwarding Detection (BFD) | generic | 1491 | | is defined in [BFD] as a framework for a | | 1492 | | lightweight generic OAM tool. The | | 1493 | | intention is to define a base tool | | 1494 | | that can be used with various | | 1495 | | encapsulation types, network | | 1496 | | environments, and in various medium | | 1497 | | types. | | 1498 +-----------+------------------------------------------+------------+ 1499 |MPLS OAM | MPLS LSP Ping, as defined in [MPLS-OAM], | MPLS | 1500 | | [MPLS-OAM-FW] and [LSP-Ping], is an OAM | | 1501 | | tool for point-to-point and | | 1502 | | point-to-multipoint MLPS LSPs. | | 1503 | | It includes two main functions: Ping and | | 1504 | | Traceroute. | | 1505 | | BFD [BFD-LSP] is an alternative means for| | 1506 | | detecting MPLS LSP data plane failures. | | 1507 +-----------+------------------------------------------+------------+ 1508 |MPLS-TP OAM| MPLS-TP OAM is defined in a set of RFCs. | MPLS-TP | 1509 | | The OAM requirements for MPLS Transport | | 1510 | | Profile (MPLS-TP) are defined in | | 1511 | | [MPLS-TP-OAM]. Each of the tools in the | | 1512 | | OAM toolset is defined in its own RFC, as| | 1513 | | specified in Section A.1. | | 1514 +-----------+------------------------------------------+------------+ 1515 |Pseudowire | The PWE3 OAM architecture defines control| Pseudowire | 1516 |OAM | channels that support the use of existing| | 1517 | | IETF OAM tools to be used for a pseudo- | | 1518 | | wire (PW). The control channels that are| | 1519 | | defined in [VCCV] and [PW-G-ACh] may be | | 1520 | | used in conjunction with ICMP Ping, LSP | | 1521 | | Ping, and BFD to perform CC and CV | | 1522 | | functionality. In addition the channels | | 1523 | | support use of any of the MPLS-TP based | | 1524 | | OAM tools for completing their respective| | 1525 | | OAM functionality for a PW. | | 1526 +-----------+------------------------------------------+------------+ 1527 |OWAMP and | The One Way Active Measurement Protocol | IPv4/IPv6 | 1528 |TWAMP | [OWAMP] and the Two Way Active Measure- | | 1529 | | ment Protocols [TWAMP] are two protocols | | 1530 | | defined in the IP Performance Metrics | | 1531 | | (IPPM) working group in the IETF. These | | 1532 | | protocols allow various performance | | 1533 | | metrics to be measured, such as packet | | 1534 | | loss, delay and delay variation, | | 1535 | | duplication and reordering. | | 1536 +-----------+------------------------------------------+------------+ 1537 |TRILL OAM | The requirements of OAM in TRILL are | TRILL | 1538 | | defined in [TRILL-OAM]. These | | 1539 | | requirements include continuity checking,| | 1540 | | connectivity verification, path tracing | | 1541 | | and performance monitoring. During the | | 1542 | | writing of this document the detailed | | 1543 | | definition of the TRILL OAM tools | | 1544 | | is work in progress. | | 1545 +-----------+------------------------------------------+------------+ 1546 Table 3 Summary of OAM-related IETF Tools 1548 5.2. Summary of OAM Functions 1550 Table 4 summarizes the OAM functions that are supported in each of 1551 the toolsets that were analyzed in this section. The columns of this 1552 tables are the typical OAM functions described in Section 1.3. 1554 +-----------+-------+--------+--------+-------+----------+ 1555 | |Continu|Connecti|Path |Perform|Other | 1556 | |ity |vity |Discover|ance |Function | 1557 | |Check |Verifica|y |Monitor|s | 1558 | Toolset | |tion | |ing | | 1559 +-----------+-------+--------+--------+-------+----------+ 1560 |IP Ping |Echo | | | | | 1561 + --------- + ----- + ------ + ------ + ----- + -------- + 1562 |IP | | |Tracerou| | | 1563 |Traceroute | | |te | | | 1564 + --------- + ----- + ------ + ------ + ----- + -------- + 1565 |BFD |BFD |BFD | | |RDI usi- | 1566 | |Control|Control | | |ng BFD | 1567 | |/ Echo | | | |Control | 1568 + --------- + ----- + ------ + ------ + ----- + -------- + 1569 |MPLS OAM | |"Ping" |"Tracero| | | 1570 |(LSP Ping) | |mode |ute" | | | 1571 | | | |mode | | | 1572 + --------- + ----- + ------ + ------ + ----- + -------- + 1573 |MPLS-TP |CC |CV/pro- |Route |-LM |-Diagnos- | 1574 |OAM | |active |Tracing |-DM | tic Test | 1575 | | |or on- | | |-Lock | 1576 | | |demand | | |-Alarm | 1577 | | | | | |Reporting | 1578 | | | | | |-Client | 1579 | | | | | |Failure | 1580 | | | | | |Indication| 1581 | | | | | |-RDI | 1582 + --------- + ----- + ------ + ------ + ----- + -------- + 1583 |Pseudowire |BFD |-BFD |LSP-Ping| | | 1584 |OAM | |-ICMP | | | | 1585 | | | Ping | | | | 1586 | | |-LSP- | | | | 1587 | | | Ping | | | | 1588 + --------- + ----- + ------ + ------ + ----- + -------- + 1589 |OWAMP and | - control | |-Delay | | 1590 |TWAMP | protocol | | measur| | 1591 | | | | ement | | 1592 | | | |-Packet| | 1593 | | | | loss | | 1594 | | | | measur| | 1595 | | | | ement | | 1596 + --------- + ----- + ------ + ------ + ----- + -------- + 1597 |TRILL OAM |CC |CV |Path |-Delay | | 1598 | | | |tracing | measur| | 1599 | | | | | ement | | 1600 | | | | |-Packet| | 1601 | | | | | loss | | 1602 | | | | | measur| | 1603 | | | | | ement | | 1604 +-----------+-------+--------+--------+-------+----------+ 1605 Table 4 Summary of the OAM Functionality in IETF OAM Tools 1607 5.3. Guidance to Network Equipment Vendors 1609 As mentioned in Section 1.4. , it is imperative for OAM tools to be 1610 capable of testing the actual data plane in as much accuracy as 1611 possible. While this guideline may appear obvious, it is worthwhile 1612 to emphasize the key importance of enforcing fate-sharing between OAM 1613 traffic that monitors the data plane and the data plane traffic it 1614 monitors. 1616 6. Security Considerations 1618 OAM is tightly coupled with the stability of the network. A 1619 successful attack on an OAM protocol can create a false illusion of 1620 non-existent failures, or prevent the detection of actual ones. In 1621 both cases the attack may result in denial of service. 1623 Some of the OAM tools presented in this document include security 1624 mechanisms that provide integrity protection, thereby preventing 1625 attackers from forging or tampering with OAM packets. For example, 1626 [BFD] includes an optional authentication mechanism for BFD Control 1627 packets, using either SHA1, MD5, or a simple password. [OWAMP] and 1628 [TWAMP] have 3 modes of security: unauthenticated, authenticated, 1629 and encrypted. The authentication uses SHA1 as the HMAC algorithm, 1630 and the encrypted mode uses AES encryption. 1632 Confidentiality is typically not considered a requirement for OAM 1633 protocols. However, the use of encryption (e.g., [OWAMP] and 1635 [TWAMP]) can make it difficult for attackers to identify OAM 1636 packets, thus making it more difficult to attack the OAM protocol. 1638 OAM can also be used as a means for network reconnaissance; 1639 information about addresses, port numbers and about the network 1640 topology and performance can be gathered either by passively 1641 eavesdropping to OAM packets, or by actively sending OAM packets and 1642 gathering information from the respective responses. This 1643 information can then be used maliciously to attack the network. Note 1644 that some of this information, e.g., addresses and port numbers, can 1645 be gather even when encryption is used ([OWAMP], [TWAMP]). 1647 For further details about the security considerations of each OAM 1648 protocol, the reader is encouraged to review the Security 1649 Considerations section of each document referenced by this memo. 1651 7. IANA Considerations 1653 There are no new IANA considerations implied by this document. 1655 8. Acknowledgments 1657 The authors gratefully acknowledge Sasha Vainshtein, Carlos 1658 Pignataro, David Harrington, Dan Romascanu, Ron Bonica, Benoit 1659 Claise, Stewart Bryant, Tom Nadeau, Elwyn Davies, Al Morton, Sam 1660 Aldrin, Thomas Narten, and other members of the OPSA WG for their 1661 helpful comments on the mailing list. 1663 This document was prepared using 2-Word-v2.0.template.dot. 1665 9. References 1667 9.1. Normative References 1669 [OAM-Def] Andersson, L., Van Helvoort, H., Bonica, R., Romascanu, 1670 D., Mansfield, S., "Guidelines for the use of the OAM 1671 acronym in the IETF ", RFC 6291, June 2011. 1673 9.2. Informative References 1675 [ATM-L2] Singh, S., Townsley, M., and C. Pignataro, 1676 "Asynchronous Transfer Mode (ATM) over Layer 2 1677 Tunneling Protocol Version 3 (L2TPv3)", RFC 4454, May 1678 2006. 1680 [BFD] Katz, D., Ward, D., "Bidirectional Forwarding Detection 1681 (BFD)", RFC 5880, June 2010. 1683 [BFD-Gen] Katz, D., Ward, D., "Generic Application of 1684 Bidirectional Forwarding Detection (BFD)", RFC 5882, 1685 June 2010. 1687 [BFD-IP] Katz, D., Ward, D., "Bidirectional Forwarding Detection 1688 (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 1689 2010. 1691 [BFD-LSP] Aggarwal, R., Kompella, K., Nadeau, T., and Swallow, 1692 G., "Bidirectional Forwarding Detection (BFD) for MPLS 1693 Label Switched Paths (LSPs)", RFC 5884, June 2010. 1695 [BFD-Multi] Katz, D., Ward, D., "Bidirectional Forwarding Detection 1696 (BFD) for Multihop Paths", RFC 5883, June 2010. 1698 [BFD-VCCV] Nadeau, T., Pignataro, C., "Bidirectional Forwarding 1699 Detection (BFD) for the Pseudowire Virtual Circuit 1700 Connectivity Verification (VCCV)", RFC 5885, June 1701 2010. 1703 [Comp] Bonaventure, O., "Computer Networking: Principles, 1704 Protocols and Practice", 2008. 1706 [Dup] Uijterwaal, H., "A One-Way Packet Duplication Metric", 1707 RFC 5560, May 2009. 1709 [Eth-Int] Mohan, D., Bitar, N., Sajassi, A., Delord, S., Niger, 1710 P., Qiu, R., "MPLS and Ethernet Operations, 1711 Administration, and Maintenance (OAM) Interworking", 1712 RFC 7023, October 2013. 1714 [G-ACh] Bocci, M., Vigoureux, M., Bryant, S., "MPLS Generic 1715 Associated Channel", RFC 5586, June 2009. 1717 [ICMP-Ext] Bonica, R., Gan, D., Tappan, D., Pignataro, C., "ICMP 1718 Extensions for Multiprotocol Label Switching", RFC 1719 4950, August 2007. 1721 [ICMP-Int] Atlas, A., Bonica, R., Pignataro, C., Shen, N., Rivers, 1722 JR., "Extending ICMP for Interface and Next-Hop 1723 Identification", RFC 5837, April 2010. 1725 [ICMP-MP] Bonica, R., Gan, D., Tappan, D., Pignataro, C., 1726 "Extended ICMP to Support Multi-Part Messages", RFC 1727 4884, April 2007. 1729 [ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, 1730 RFC 792, September 1981. 1732 [ICMPv6] Conta, A., Deering, S., and M. Gupta, "Internet Control 1733 Message Protocol (ICMPv6) for the Internet Protocol 1734 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1736 [IEEE802.1Q] IEEE 802.1Q, "IEEE Standard for Local and metropolitan 1737 area networks - Media Access Control (MAC) Bridges and 1738 Virtual Bridged Local Area Networks", October 2012. 1740 [IEEE802.3ah] IEEE 802.3, "IEEE Standard for Information technology - 1741 Local and metropolitan area networks - Carrier sense 1742 multiple access with collision detection (CSMA/CD) 1743 access method and physical layer specifications", 1744 clause 57, December 2008. 1746 [IntHost] Braden, R., "Requirements for Internet Hosts -- 1747 Communication Layers", RFC 1122, October 1989. 1749 [IPPM-1DM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way 1750 Delay Metric for IPPM", RFC 2679, September 1999. 1752 [IPPM-1LM] Almes, G., Kalidindi, S., Zekauskas, M., "A One-way 1753 Packet Loss Metric for IPPM", RFC 2680, September 1754 1999. 1756 [IPPM-2DM] Almes, G., Kalidindi, S., Zekauskas, M., "A Round-trip 1757 Delay Metric for IPPM", RFC 2681, September 1999. 1759 [IPPM-Con] Mahdavi, J., Paxson, V., "IPPM Metrics for Measuring 1760 Connectivity", RFC 2678, September 1999. 1762 [IPPM-FW] Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., 1763 "Framework for IP Performance Metrics", RFC 2330, May 1764 1998. 1766 [ITU-G8113.1] ITU-T Recommendation G.8113.1/Y.1372.1, "Operations, 1767 Administration and Maintenance mechanism for MPLS-TP 1768 in Packet Transport Network (PTN)", November 2012. 1770 [ITU-G8113.2] ITU-T Recommendation G.8113.2/Y.1372.2, "Operations, 1771 administration and maintenance mechanisms for MPLS-TP 1772 networks using the tools defined for MPLS", November 1773 2012. 1775 [ITU-T-CT] Betts, M., "Allocation of a Generic Associated Channel 1776 Type for ITU-T MPLS Transport Profile Operation, 1777 Maintenance, and Administration (MPLS-TP OAM)", RFC 1778 6671, November 2012. 1780 [ITU-T-G.806] ITU-T Recommendation G.806, "Characteristics of 1781 transport equipment - Description methodology and 1782 generic functionality", January 2009. 1784 [ITU-T-Y1711] ITU-T Recommendation Y.1711, "Operation & Maintenance 1785 mechanism for MPLS networks", February 2004. 1787 [ITU-T-Y1731] ITU-T Recommendation G.8013/Y.1731, "OAM Functions and 1788 Mechanisms for Ethernet-based Networks", July 2011. 1790 [ITU-Terms] ITU-R/ITU-T Terms and Definitions, online, 2013. 1792 [L2TP-EC] McGill, N. and C. Pignataro, "Layer 2 Tunneling 1793 Protocol Version 3 (L2TPv3) Extended Circuit Status 1794 Values", RFC 5641, August 2009. 1796 [L2VPN-OAM] Sajassi, A., Mohan, D., "Layer 2 Virtual Private 1797 Network (L2VPN) Operations, Administration, and 1798 Maintenance (OAM) Requirements and Framework", RFC 1799 6136, March 2011. 1801 [L3VPN-OAM] El Mghazli, Y., Nadeau, T., Boucadair, M., Chan, K., 1802 Gonguet, A., "Framework for Layer 3 Virtual Private 1803 Networks (L3VPN) Operations and Management", RFC 4176, 1804 October 2005. 1806 [Lock-Loop] Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, 1807 M., Dai, X., "MPLS Transport Profile Lock Instruct and 1808 Loopback Functions", RFC 6435, November 2011. 1810 [LSP-Ping] Kompella, K., Swallow, G., "Detecting Multi-Protocol 1811 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1812 February 2006. 1814 [Mng] Farrel, A., "Inclusion of Manageability Sections in 1815 Path Computation Element (PCE) Working Group Drafts", 1816 RFC 6123, February 2011. 1818 [MPLS-ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1819 Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack 1820 Encoding", RFC 3032, January 2001. 1822 [MPLS-LM-DM] Frost, D., Bryant, S., "Packet Loss and Delay 1823 Measurement for MPLS Networks", RFC 6374, September 1824 2011. 1826 [MPLS-OAM] Nadeau, T., Morrow, M., Swallow, G., Allan, D., 1827 Matsushima, S., "Operations and Management (OAM) 1828 Requirements for Multi-Protocol Label Switched (MPLS) 1829 Networks", RFC 4377, February 2006. 1831 [MPLS-OAM-FW] Allan, D., Nadeau, T., "A Framework for Multi-Protocol 1832 Label Switching (MPLS) Operations and Management 1833 (OAM)", RFC 4378, February 2006. 1835 [MPLS-P2MP] Yasukawa, S., Farrel, A., King, D., Nadeau, T., 1836 "Operations and Management (OAM) Requirements for 1837 Point-to-Multipoint MPLS Networks", RFC 4687, 1838 September 2006. 1840 [MPLS-TP-OAM] Vigoureux, M., Ward, D., Betts, M., "Requirements for 1841 OAM in MPLS Transport Networks", RFC 5860, May 2010. 1843 [mtrace] Fenner, W., Casner, S., "A "traceroute" facility for IP 1844 Multicast", draft-ietf-idmr-traceroute-ipm-07 1845 (expired), July 2000. 1847 [NetTerms] Jacobsen, O., Lynch, D., "A Glossary of Networking 1848 Terms", RFC 1208, March 1991. 1850 [NetTools] Enger, R., Reynolds, J., "FYI on a Network Management 1851 Tool Catalog: Tools for Monitoring and Debugging 1852 TCP/IP Internets and Interconnected Devices", RFC 1853 1470, June 1993. 1855 [OAM-Analys] Sprecher, N., Fang, L., "An Overview of the OAM Tool 1856 Set for MPLS based Transport Networks", RFC 6669, 1857 July 2012. 1859 [OAM-Label] Ohta, H., "Assignment of the 'OAM Alert Label' for 1860 Multiprotocol Label Switching Architecture (MPLS) 1861 Operation and Maintenance (OAM) Functions", RFC 3429, 1862 November 2002. 1864 [OAM-Mng] Ersue, M., Claise, B., "An Overview of the IETF Network 1865 Management Standards", RFC 6632, June 2012. 1867 [OnDemand-CV] Gray, E., Bahadur, N., Boutros, S., Aggarwal, R. "MPLS 1868 On-Demand Connectivity Verification and Route 1869 Tracing", RFC 6426, November 2011. 1871 [OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and 1872 Zekauskas, M., "A One-way Active Measurement Protocol 1873 (OWAMP)", RFC 4656, September 2006. 1875 [PARIS] Brice Augustin, Timur Friedman and Renata Teixeira, 1876 "Measuring Load-balanced Paths in the Internet", IMC, 1877 2007. 1879 [PM-CONS] Clark, A. and B. Claise, "Guidelines for Considering 1880 New Performance Metric Development", BCP 170, RFC 1881 6390, October 2011. 1883 [PW-ACH] Bryant, S., Swallow, G., Martini, L., McPherson, D., 1884 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word 1885 for Use over an MPLS PSN", RFC 4385, February 2006. 1887 [PW-G-ACh] Li, H., Martini, L., He, J., Huang, F., "Using the 1888 Generic Associated Channel Label for Pseudowire in the 1889 MPLS Transport Profile (MPLS-TP)", RFC 6423, November 1890 2011. 1892 [PW-MAP] Aissaoui, M., Busschbach, P., Martini, L., Morrow, M., 1893 Nadeau, T., and Y(J). Stein, "Pseudowire (PW) 1894 Operations, Administration, and Maintenance (OAM) 1895 Message Mapping", RFC 6310, July 2011. 1897 [Reorder] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 1898 S., and J. Perser, "Packet Reordering Metrics", RFC 1899 4737, November 2006. 1901 [Signal] Yasukawa, S., "Signaling Requirements for Point-to- 1902 Multipoint Traffic-Engineered MPLS Label Switched 1903 Paths (LSPs)", RFC 4461, April 2006. 1905 [TCPIP-Tools] Kessler, G., Shepard, S., "A Primer On Internet and 1906 TCP/IP Tools and Utilities", RFC 2151, June 1997. 1908 [TP-CC-CV] Allan, D., Swallow, G., Drake, J., "Proactive 1909 Connectivity Verification, Continuity Check and Remote 1910 Defect indication for MPLS Transport Profile", RFC 1911 6428, November 2011. 1913 [TP-Fault] Swallow, G., Fulignoli, A., Vigoureux, M., Boutros, S., 1914 "MPLS Fault Management Operations, Administration, and 1915 Maintenance (OAM)", RFC 6427, November 2011. 1917 [TP-LM-DM] Frost, D., Bryant, S., "A Packet Loss and Delay 1918 Measurement Profile for MPLS-Based Transport 1919 Networks", RFC 6375, September 2011. 1921 [TP-OAM-FW] Busi, I., Allan, D., "Operations, Administration and 1922 Maintenance Framework for MPLS-based Transport 1923 Networks ", RFC 6371, September 2011. 1925 [TP-Term] Van Helvoort, H., Andersson, L., Sprecher, N., "A 1926 Thesaurus for the Terminology used in MPLS Transport 1927 Profile (MPLS-TP) Internet-Drafts and RFCs in the 1928 Context of the ITU-T's Transport Network 1929 Recommendations", RFC 7087, December 2013. 1931 [TRILL-OAM] Senevirathne, T., Bond, D., Aldrin, S., Li, Y., Watve, 1932 R., "Requirements for Operations, Administration, and 1933 Maintenance (OAM) in Transparent Interconnection of 1934 Lots of Links (TRILL)", RFC 6905, March 2013. 1936 [TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and 1937 Babiarz, J., "A Two-Way Active Measurement Protocol 1938 (TWAMP)", RFC 5357, October 2008. 1940 [VCCV] Nadeau, T., Pignataro, C., "Pseudowire Virtual Circuit 1941 Connectivity Verification (VCCV): A Control Channel 1942 for Pseudowires", RFC 5085, December 2007. 1944 [VCCV-SURVEY] Del Regno, N., Malis, A., "The Pseudowire (PW) and 1945 Virtual Circuit Connectivity Verification (VCCV) 1946 Implementation Survey Results", RFC 7079, November 1947 2013. 1949 Appendix A. List of OAM Documents 1951 A.1. List of IETF OAM Documents 1953 Table 5 summarizes the OAM related RFCs published by the IETF. 1955 It is important to note that the table lists various RFCs that are 1956 different by nature. For example, some of these documents define OAM 1957 tools or OAM protocols (or both), while others define protocols that 1958 are not strictly OAM-related, but are used by OAM tools. The table 1959 also includes RFCs that define the requirements or the framework of 1960 OAM in a specific context (e.g., MPLS-TP). 1962 The RFCs in the table are categorized in a few sets as defined in 1963 Section 1.3. 1965 +-----------+--------------------------------------+----------+ 1966 | Toolset | Title | RFC | 1967 +-----------+--------------------------------------+----------+ 1968 |IP Ping | Requirements for Internet Hosts -- | RFC 1122 | 1969 | | Communication Layers [IntHost] | | 1970 | +--------------------------------------+----------+ 1971 | | A Glossary of Networking Terms | RFC 1208 | 1972 | | [NetTerms] | | 1973 | +--------------------------------------+----------+ 1974 | | Internet Control Message Protocol | RFC 792 | 1975 | | [ICMPv4] | | 1976 | +--------------------------------------+----------+ 1977 | | Internet Control Message Protocol | RFC 4443 | 1978 | | (ICMPv6) for the Internet Protocol | | 1979 | | Version 6 (IPv6) Specification | | 1980 | | [ICMPv6] | | 1981 +-----------+--------------------------------------+----------+ 1982 |IP | A Primer On Internet and TCP/IP | RFC 2151 | 1983 |Traceroute | Tools and Utilities [TCPIP-Tools] | | 1984 | +--------------------------------------+----------+ 1985 | | FYI on a Network Management Tool | RFC 1470 | 1986 | | Catalog: Tools for Monitoring and | | 1987 | | Debugging TCP/IP Internets and | | 1988 | | Interconnected Devices [NetTools] | | 1989 | +--------------------------------------+----------+ 1990 | | Internet Control Message Protocol | RFC 792 | 1991 | | [ICMPv4] | | 1992 | +--------------------------------------+----------+ 1993 | | Internet Control Message Protocol | RFC 4443 | 1994 | | (ICMPv6) for the Internet Protocol | | 1995 | | Version 6 (IPv6) Specification | | 1996 | | [ICMPv6] | | 1997 | +--------------------------------------+----------+ 1998 | | Extended ICMP to Support Multi-Part | RFC 4884 | 1999 | | Messages [ICMP-MP] | | 2000 | +--------------------------------------+----------+ 2001 | | Extending ICMP for Interface and | RFC 5837 | 2002 | | Next-Hop Identification [ICMP-Int] | | 2003 +-----------+--------------------------------------+----------+ 2004 |BFD | Bidirectional Forwarding Detection | RFC 5880 | 2005 | | [BFD] | | 2006 | +--------------------------------------+----------+ 2007 | | Bidirectional Forwarding Detection | RFC 5881 | 2008 | | (BFD) for IPv4 and IPv6 (Single Hop) | | 2009 | | [BFD-IP] | | 2010 | +--------------------------------------+----------+ 2011 | | Generic Application of Bidirectional | RFC 5882 | 2012 | | Forwarding Detection [BFD-Gen] | | 2013 | +--------------------------------------+----------+ 2014 | | Bidirectional Forwarding Detection | RFC 5883 | 2015 | | (BFD) for Multihop Paths [BFD-Multi] | | 2016 | +--------------------------------------+----------+ 2017 | | Bidirectional Forwarding Detection | RFC 5884 | 2018 | | for MPLS Label Switched Paths (LSPs) | | 2019 | | [BFD-LSP] | | 2020 | +--------------------------------------+----------+ 2021 | | Bidirectional Forwarding Detection | RFC 5885 | 2022 | | for the Pseudowire Virtual Circuit | | 2023 | | Connectivity Verification (VCCV) | | 2024 | | [BFD-VCCV] | | 2025 +-----------+--------------------------------------+----------+ 2026 |MPLS OAM | Operations and Management (OAM) | RFC 4377 | 2027 | | Requirements for Multi-Protocol Label| | 2028 | | Switched (MPLS) Networks [MPLS-OAM] | | 2029 | +--------------------------------------+----------+ 2030 | | A Framework for Multi-Protocol | RFC 4378 | 2031 | | Label Switching (MPLS) Operations | | 2032 | | and Management (OAM) [MPLS-OAM-FW] | | 2033 | +--------------------------------------+----------+ 2034 | | Detecting Multi-Protocol Label | RFC 4379 | 2035 | | Switched (MPLS) Data Plane Failures | | 2036 | | [LSP-Ping] | | 2037 | +--------------------------------------+----------+ 2038 | | Operations and Management (OAM) | RFC 4687 | 2039 | | Requirements for Point-to-Multipoint | | 2040 | | MPLS Networks [MPLS-P2MP] | | 2041 | +--------------------------------------+----------+ 2042 | | ICMP Extensions for Multiprotocol | RFC 4950 | 2043 | | Label Switching [ICMP-Ext] | | 2044 | +--------------------------------------+----------+ 2045 | | Bidirectional Forwarding Detection | RFC 5884 | 2046 | | for MPLS Label Switched Paths (LSPs) | | 2047 | | [BFD-LSP] | | 2048 +-----------+--------------------------------------+----------+ 2049 |MPLS-TP | Requirements for OAM in MPLS-TP | RFC 5860 | 2050 |OAM | [MPLS-TP-OAM] | | 2051 | +--------------------------------------+----------+ 2052 | | MPLS Generic Associated Channel | RFC 5586 | 2053 | | [G-ACh] | | 2054 | +--------------------------------------+----------+ 2055 | | MPLS-TP OAM Framework | RFC 6371 | 2056 | | [TP-OAM-FW] | | 2057 | +--------------------------------------+----------+ 2058 | | Proactive Connectivity Verification, | RFC 6428 | 2059 | | Continuity Check, and Remote Defect | | 2060 | | Indication for the MPLS Transport | | 2061 | | Profile [TP-CC-CV] | | 2062 | +--------------------------------------+----------+ 2063 | | MPLS On-Demand Connectivity | RFC 6426 | 2064 | | Verification and Route Tracing | | 2065 | | [OnDemand-CV] | | 2066 | +--------------------------------------+----------+ 2067 | | MPLS Fault Management Operations, | RFC 6427 | 2068 | | Administration, and Maintenance (OAM)| | 2069 | | [TP-Fault] | | 2070 | +--------------------------------------+----------+ 2071 | | MPLS Transport Profile Lock Instruct | RFC 6435 | 2072 | | and Loopback Functions [Lock-Loop] | | 2073 | +--------------------------------------+----------+ 2074 | | Packet Loss and Delay Measurement for| RFC 6374 | 2075 | | MPLS Networks [MPLS-LM-DM] | | 2076 | +--------------------------------------+----------+ 2077 | | A Packet Loss and Delay Measurement | RFC 6375 | 2078 | | Profile for MPLS-Based Transport | | 2079 | | Networks [TP-LM-DM] | | 2080 +-----------+--------------------------------------+----------+ 2081 |Pseudowire | Pseudowire Virtual Circuit | RFC 5085 | 2082 |OAM | Connectivity Verification (VCCV): | | 2083 | | A Control Channel for Pseudowires | | 2084 | | [VCCV] | | 2085 | +--------------------------------------+----------+ 2086 | | Bidirectional Forwarding Detection | RFC 5885 | 2087 | | for the Pseudowire Virtual Circuit | | 2088 | | Connectivity Verification (VCCV) | | 2089 | | [BFD-VCCV] | | 2090 | +--------------------------------------+----------+ 2091 | | Using the Generic Associated Channel | RFC 6423 | 2092 | | Label for Pseudowire in the MPLS | | 2093 | | Transport Profile (MPLS-TP) | | 2094 | | [PW-G-ACh] | | 2095 | +--------------------------------------+----------+ 2096 | | Pseudowire (PW) Operations, | RFC 6310 | 2097 | | Administration, and Maintenance (OAM)| | 2098 | | Message Mapping [PW-MAP] | | 2099 | +--------------------------------------+----------+ 2100 | | MPLS and Ethernet Operations, | RFC 7023 | 2101 | | Administration, and Maintenance (OAM)| | 2102 | | Interworking [Eth-Int] | | 2103 +-----------+--------------------------------------+----------+ 2104 |OWAMP and | A One-way Active Measurement Protocol| RFC 4656 | 2105 |TWAMP | [OWAMP] | | 2106 | +--------------------------------------+----------+ 2107 | | A Two-Way Active Measurement Protocol| RFC 5357 | 2108 | | [TWAMP] | | 2109 | +--------------------------------------+----------+ 2110 | | Framework for IP Performance Metrics | RFC 2330 | 2111 | | [IPPM-FW] | | 2112 | +--------------------------------------+----------+ 2113 | | IPPM Metrics for Measuring | RFC 2678 | 2114 | | Connectivity [IPPM-Con] | | 2115 | +--------------------------------------+----------+ 2116 | | A One-way Delay Metric for IPPM | RFC 2679 | 2117 | | [IPPM-1DM] | | 2118 | +--------------------------------------+----------+ 2119 | | A One-way Packet Loss Metric for IPPM| RFC 2680 | 2120 | | [IPPM-1LM] | | 2121 | +--------------------------------------+----------+ 2122 | | A Round-trip Delay Metric for IPPM | RFC 2681 | 2123 | | [IPPM-2DM] | | 2124 | +--------------------------------------+----------+ 2125 | | Packet Reordering Metrics | RFC 4737 | 2126 | | [Reorder] | | 2127 | +--------------------------------------+----------+ 2128 | | A One-Way Packet Duplication Metric | RFC 5560 | 2129 | | [Dup] | | 2130 +-----------+--------------------------------------+----------+ 2131 |TRILL OAM | Requirements for Operations, | RFC 6905 | 2132 | | Administration, and Maintenance (OAM)| | 2133 | | in Transparent Interconnection of | | 2134 | | Lots of Links (TRILL) | | 2135 +-----------+--------------------------------------+----------+ 2136 Table 5 Summary of IETF OAM Related RFCs 2138 A.2. List of Selected Non-IETF OAM Documents 2140 In addition to the OAM tools defined by the IETF, the IEEE and ITU-T 2141 have also defined various OAM tools that focus on Ethernet, and 2142 various other transport network environments. These various tools, 2143 defined by the three standard organizations, are often tightly 2144 coupled, and have had a mutual effect on each other. The ITU-T and 2145 IETF have both defined OAM tools for MPLS LSPs, [ITU-T-Y1711] and 2146 [LSP-Ping]. The following OAM standards by the IEEE and ITU-T are to 2147 some extent linked to IETF OAM tools listed above and are mentioned 2148 here only as reference material: 2150 o OAM tools for Layer 2 have been defined by the ITU-T in 2151 [ITU-T-Y1731], and by the IEEE in 802.1ag [IEEE802.1Q] . The IEEE 2152 802.3 standard defines OAM for one-hop Ethernet links 2153 [IEEE802.3ah]. 2155 o The ITU-T has defined OAM for MPLS LSPs in [ITU-T-Y1711], and 2156 MPLS-TP OAM in [ITU-G8113.1] and [ITU-G8113.2]. 2158 It should be noted that these non-IETF documents deal in many cases 2159 with OAM functions below the IP layer (Layer 2, Layer 2.5) and in 2160 some cases operators use a multi-layered OAM approach, which is a 2161 function of the way their networks are designed. 2163 Table 6 summarizes some of the main OAM standards published by non- 2164 IETF standard organizations. This document focuses on IETF OAM 2165 standards, but these non-IETF standards are referenced in this 2166 document where relevant. 2168 +-----------+--------------------------------------+---------------+ 2169 | | Title |Standard/Draft | 2170 +-----------+--------------------------------------+---------------+ 2171 |ITU-T | Operation & Maintenance mechanism | ITU-T Y.1711 | 2172 |MPLS OAM | for MPLS networks [ITU-T-Y1711] | | 2173 | +--------------------------------------+---------------+ 2174 | | Assignment of the 'OAM Alert Label' | RFC 3429 | 2175 | | for Multiprotocol Label Switching | | 2176 | | Architecture (MPLS) Operation and | | 2177 | | Maintenance (OAM) Functions | | 2178 | | [OAM-Label] | | 2179 | | | | 2180 | | Note: although this is an IETF | | 2181 | | document, it is listed as one of the| | 2182 | | non-IETF OAM standards, since it | | 2183 | | was defined as a complementary part | | 2184 | | of ITU-T Y.1711. | | 2185 +-----------+--------------------------------------+---------------+ 2186 |ITU-T | Operations, administration and |ITU-T G.8113.2 | 2187 |MPLS-TP OAM| Maintenance mechanisms for MPLS-TP | | 2188 | | networks using the tools defined for | | 2189 | | MPLS [ITU-G8113.2] | | 2190 | | | | 2191 | | Note: this document describes the | | 2192 | | OAM toolset defined by the IETF for | | 2193 | | MPLS-TP, whereas ITU-T G.8113.1 | | 2194 | | describes the OAM toolset defined | | 2195 | | by the ITU-T. | | 2196 | +--------------------------------------+---------------+ 2197 | | Operations, Administration and |ITU-T G.8113.1 | 2198 | | Maintenance mechanism for MPLS-TP in | | 2199 | | Packet Transport Network (PTN) | | 2200 | +--------------------------------------+---------------+ 2201 | | Allocation of a Generic Associated | RFC 6671 | 2202 | | Channel Type for ITU-T MPLS Transport| | 2203 | | Profile Operation, Maintenance, and | | 2204 | | Administration (MPLS-TP OAM) | | 2205 | | [ITU-T-CT] | | 2206 | | | | 2207 | | Note: although this is an IETF | | 2208 | | document, it is listed as one of the| | 2209 | | non-IETF OAM standards, since it | | 2210 | | was defined as a complementary part | | 2211 | | of ITU-T G.8113.1. | | 2212 +-----------+--------------------------------------+---------------+ 2213 |ITU-T | OAM Functions and Mechanisms for | ITU-T Y.1731 | 2214 |Ethernet | Ethernet-based Networks | | 2215 |OAM | [ITU-T-Y1731] | | 2216 +-----------+--------------------------------------+---------------+ 2217 |IEEE | Connectivity Fault Management | IEEE 802.1ag | 2218 |CFM | [IEEE802.1Q] | | 2219 | | | | 2220 | | Note: CFM was originally published | | 2221 | | as IEEE 802.1ag, but is now | | 2222 | | incorporated in the 802.1Q standard.| | 2223 +-----------+--------------------------------------+---------------+ 2224 |IEEE | Management of Data Driven and Data | IEEE 802.1ag | 2225 |DDCFM | Dependent Connectivity Faults | | 2226 | | [IEEE802.1Q] | | 2227 | | | | 2228 | | Note: DDCFM was originally published| | 2229 | | as IEEE 802.1Qaw, but is now | | 2230 | | incorporated in the 802.1Q standard.| | 2231 +-----------+--------------------------------------+---------------+ 2232 |IEEE | Media Access Control Parameters, | IEEE 802.3ah | 2233 |802.3 | Physical Layers, and Management | | 2234 |link level | Parameters for Subscriber Access | | 2235 |OAM | Networks [IEEE802.3ah] | | 2236 | | | | 2237 | | Note: link level OAM was originally | | 2238 | | defined in IEEE 802.3ah, and is now | | 2239 | | incorporated in the 802.3 standard. | | 2240 +-----------+--------------------------------------+---------------+ 2241 Table 6 Non-IETF OAM Standards Mentioned in this Document 2243 Authors' Addresses 2245 Tal Mizrahi 2246 Marvell 2247 6 Hamada St. 2248 Yokneam, 20692 2249 Israel 2251 Email: talmi@marvell.com 2253 Nurit Sprecher 2254 Nokia Solutions and Networks 2255 3 Hanagar St. Neve Ne'eman B 2256 Hod Hasharon, 45241 2257 Israel 2259 Email: nurit.sprecher@nsn.com 2261 Elisa Bellagamba 2262 Ericsson 2263 6 Farogatan St. 2264 Stockholm, 164 40 2265 Sweden 2267 Phone: +46 761440785 2268 Email: elisa.bellagamba@ericsson.com 2270 Yaacov Weingarten 2271 34 Hagefen St. 2272 Karnei Shomron, 4485500 2273 Israel 2275 Email: wyaacov@gmail.com