idnits 2.17.1 draft-ietf-mpls-tp-oam-analysis-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 3 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 17, 2012) is 4386 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Sprecher 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational L. Fang 5 Expires: October 18, 2012 Cisco 6 April 17, 2012 8 An Overview of the OAM Tool Set for MPLS based Transport Networks 9 draft-ietf-mpls-tp-oam-analysis-09.txt 11 Abstract 13 This document provides an overview of the OAM toolset for MPLS based 14 Transport Networks (MPLS-TP). The toolset consists of a comprehensive 15 set of fault management and performance monitoring capabilities 16 (operating in the data-plane) which are appropriate for transport 17 networks as required in RFC 5860 and support the network and services 18 at different nested levels. This overview includes a brief recap of 19 MPLS-TP OAM requirements and functions, and of generic mechanisms 20 created in the MPLS data plane to allow the OAM packets run in-band 21 and share their fate with data packets. The protocol definitions for 22 each of the MPLS-TP OAM tools are defined in separate documents (RFCs 23 or Working Group drafts) which are referenced by this document. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 18, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. Contributing Authors . . . . . . . . . . . . . . . . . . . 5 62 1.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2. Basic OAM Infrastructure Functionality . . . . . . . . . . . . 6 64 3. MPLS-TP OAM Functions . . . . . . . . . . . . . . . . . . . . 8 65 3.1. Continuity Check and Connectivity Verification . . . . . . 8 66 3.1.1. Documents for CC-CV tools . . . . . . . . . . . . . . 9 67 3.2. Remote Defect Indication . . . . . . . . . . . . . . . . . 9 68 3.2.1. Documents for RDI . . . . . . . . . . . . . . . . . . 9 69 3.3. Route Tracing . . . . . . . . . . . . . . . . . . . . . . 9 70 3.3.1. Documents for Route Tracing . . . . . . . . . . . . . 10 71 3.4. Alarm Reporting . . . . . . . . . . . . . . . . . . . . . 10 72 3.4.1. Documents for Alarm Reporting . . . . . . . . . . . . 10 73 3.5. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 10 74 3.5.1. Documents for Lock Instruct . . . . . . . . . . . . . 10 75 3.6. Lock Reporting . . . . . . . . . . . . . . . . . . . . . . 10 76 3.6.1. Documents for Lock Reporting . . . . . . . . . . . . . 10 77 3.7. Diagnostic . . . . . . . . . . . . . . . . . . . . . . . . 11 78 3.7.1. Documents for Diagnostic Testing . . . . . . . . . . . 11 79 3.8. Packet Loss Measurement . . . . . . . . . . . . . . . . . 11 80 3.8.1. Documents for Packet Loss Measurement . . . . . . . . 11 81 3.9. Packet Delay Measurement . . . . . . . . . . . . . . . . . 12 82 3.9.1. Documents for Delay Measurement . . . . . . . . . . . 12 83 4. MPLS-TP OAM documents guide . . . . . . . . . . . . . . . . . 12 84 5. OAM Toolset Applicability and Utilization . . . . . . . . . . 14 85 5.1. Connectivity Check and Connectivity Verification . . . . . 14 86 5.2. Diagnostic Tests and Lock Instruct . . . . . . . . . . . . 15 87 5.3. Lock Reporting . . . . . . . . . . . . . . . . . . . . . . 16 88 5.4. Alarm Reporting and Link Down Indication . . . . . . . . . 16 89 5.5. Remote Defect Indication . . . . . . . . . . . . . . . . . 17 90 5.6. Packet Loss and Delay Measurement . . . . . . . . . . . . 17 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 96 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 99 1. Introduction 101 1.1. Scope 103 The MPLS Transport Profile (MPLS-TP) architectural framework is 104 defined in [RFC 5921], and it describes common set of protocol 105 functions that supports the operational models and capabilities 106 typical of such networks. 108 OAM (Operations, Administration, and Maintenance) plays a significant 109 role in carrier networks, providing methods for fault management and 110 performance monitoring in both the transport and the service layers 111 in order to improve their ability to support services with guaranteed 112 and strict Service Level Agreements (SLAs) while reducing their 113 operational costs. 115 [RFC 5654], in general, and [RFC 5860], in particular, define a set 116 of requirements for OAM functionality for MPLS-Transport Profile 117 (MPLS-TP)Label Switched Paths (LSPs) ), Pseudowires (PWs) and 118 sections. 120 The OAM solution, developed by the joint IETF and ITU-T MPLS-TP 121 project, has three objectives: 123 o The OAM toolset should be developed based on existing MPLS 124 architecture, technology, and toolsets. 126 o The OAM operational experience should be similar to that in other 127 transport networks. 129 o The OAM toolset developed for MPLS based transport networks needs 130 to be fully inter-operable with existing MPLS OAM tools as 131 documented in [RFC 5860]. 133 The MPLS-TP OAM toolset is based on the following existing tools: 135 o LSP-Ping as defined in [RFC 4379]. 137 o Bidirectional Forwarding Detection (BFD) as defined in [RFC 5880] 138 and refined in [RFC 5884]. 140 o ITU-T OAM for Ethernet toolset as defined in [Y.1731]. This has 141 been used for functionality guidelines for the performance 142 measurement tools that were not previously supported in MPLS. 144 It should be noted that certain extensions and adjustments have been 145 specified relative to the existing MPLS tools, in order to conform to 146 the transport environment and the requirements of MPLS-TP. However, 147 compatibility with the existing tools has been maintained. 149 This document provides an overview of the MPLS-TP OAM toolset, which 150 consists of tools for MPLS-TP fault management and performance 151 monitoring. This overview includes a brief recap of MPLS-TP OAM 152 requirements and functions, and of the generic mechanisms used to 153 support the MPLS-TP OAM operation. 155 The protocol definitions for each individual MPLS-TP OAM tool are 156 specified in separate RFCs (or Working Group documents while this 157 document is work in progress), which are referenced by this document. 159 In addition, the document includes a table that cross-references the 160 solution documents to the OAM functionality supported. Finally, the 161 document presents the applicability and utilization of each tool in 162 the MPLS-TP OAM toolset. 164 1.2. Contributing Authors 166 Elisa Bellagamba Ericsson 167 Yaacov Weingarten Nokia Siemens Networks 168 Dan Frost Cisco 169 Nabil Bitar Verizon 170 Raymond Zhang Alcatel Lucent 171 Lei Wang Telenor 172 Kam Lee Yap XO Communications 173 John Drake Juniper 174 Yaakov Stein RAD 175 Anamaria Fulignoli Ericsson 176 Italo Busi Alcatel Lucent 177 Huub van Helvoort Huawei 178 Thomas Nadeau Computer Associate 179 Henry Yu TW Telecom 180 Mach Chen Huawei 181 Manuel Paul Deutsche Telekom 183 1.3. Acronyms 185 This document uses the following acronyms: 187 ACH Associated Channel Header 188 AIS Alarm Indication Signal 189 BFD Bidirectional Forwarding Detection 190 CC-CV Continuity Check and Connectivity Verification 191 DM Delay Measurement 192 FM Fault Management 193 G-ACh Generic Associated Channel 194 GAL G-ACh Label 195 GMPLS Generalized Multi-Protocol Label Switching 196 IANA Internet Assigned Names Authority 197 LDI Link Down Indication 198 LKR Lock Report 199 LM Loss Measurement 200 LOC Loss of Continuity 201 LSP Label Switched Path 202 MEP Maintenance Entity Group End Point 203 MEG Maintenance Entity Group 204 MIP Maintenance Entity Group Intermediate Point 205 MPLS MultiProtocol Label Switching 206 MPLS-TP Transport Profile for MPLS 207 OAM Operations, Administration, and Maintenance 208 PM Performance Monitoring 209 PW Pseudowire 210 RDI Remote Defect Indication 211 SLA Service Level Agreement 212 TLV Type, Length, Value 213 VCCV Virtual Circuit Connectivity Verification 215 2. Basic OAM Infrastructure Functionality 217 [RFC 5860] defines a set of requirements on OAM architecture and 218 general principles of operations, which are evaluated below: 220 [RFC 5860] requires that -- 222 o OAM mechanisms in MPLS-TP are independent of the transmission 223 media and of the client service being emulated by the PW ([RFC 224 5860], section 2.1.2). 226 o MPLS-TP OAM must be able to support both an IP based and non-IP 227 based environment. If the network is IP based, i.e. IP routing 228 and forwarding are available, then it must be possible to choose 229 to make use of IP capabilities. On the other hand, in 230 environments where IP functionality is not available, the OAM 231 tools must still be able to operate independent of IP forwarding 232 and routing ([RFC 5860], section 2.1.4). It is required to have 233 OAM interoperability between distinct domains materializing the 234 environments ([RFC 5860], section 2.1.5). 236 o all OAM protocols support identification information, at least in 237 the form of IP addressing structure and be extensible to support 238 additional identification schemes ([RFC 5860], section 2.1.4). 240 o OAM packets and the user traffic are congruent (i.e. OAM packets 241 are transmitted in-band) and there is a need to differentiate OAM 242 packets from user-plane packets ([RFC 5860], section 2.1.3). 243 Inherent in this requirement is the principle that full operation 244 of the MPLS-TP OAM must be possible independently of the control 245 or management plane used to operate the network ([RFC 5860], 246 section 2.1.3). 248 o MPLS-TP OAM supports point-to-point bidirectional PWs, point-to- 249 point co-routed bidirectional LSPs, point-to-point bidirectional 250 Sections ([RFC 5860], section 2.1.1). The applicability of 251 particular MPLS-TP OAM functions to point-to-point associated 252 bidirectional LSPs, point-to-point unidirectional LSPs, and point- 253 to-multipoint LSPs, is described in ([RFC 5860], section 2.2)). 254 In addition, MPLS-TP OAM supports these LSPs and PWs when they 255 span either a single or multiple domains ([RFC 5860], section 256 2.1.1). 258 o OAM packets may be directed to an intermediate point of a LSP/PW 259 ([RFC 5860], sections 2.2.3, 2.2.4 and 2.2.5). 261 [RFC 5860] recommends that any protocol solution, meeting one or more 262 functional requirement(s), be the same for PWs, LSPs, and Sections 263 (section 2.2). 265 The following document-set addresses the basic requirements listed 266 above: 268 o The [RFC 6371] document describes the architectural framework for 269 conformance to the basic requirements listed above. It also 270 defines the basic relationships between the MPLS structures, e.g. 271 LSP, PW, and the structures necessary for OAM functionality, i.e. 272 the Managed Entity Group, its End-points, and Intermediate Points. 274 o The [RFC 5586] document specifies the use of the MPLS-TP in-band 275 control channels. It generalizes the applicability of the 276 Pseudowire (PW) Associated Channel Header (ACH) to MPLS LSPs and 277 Sections, by defining a Generic Associated Channel (G-ACh). The 278 G-ACh allows control packets to be multiplexed transparently over 279 LSPs and sections, similar to that of PW VCCV [RFC 5085]. The 280 Generic Association Label (GAL) is defined by assigning a reserved 281 MPLS label value and is used to identify the OAM control packets. 282 The value of the ACH Channel Type field indicates the specific 283 protocol carried on the associated control channel. Each MPLS-TP 284 OAM protocol has an IANA assigned channel type allocated to it. 286 [RFC 5085] defines an Associated Channel Header (ACH) which 287 provides a PW associated control channel between a PW's endpoints, 288 over which OAM and other control messages can be exchanged. [RFC 289 5586] generalizes MPLS-TP generalized the PW Associated Channel 290 Header (ACH) to provide common in-band control channels also at 291 the LSP and MPLS-TP link levels. The G-ACh allows control packets 292 to be multiplexed transparently over the same LSP or MPLS-TP link 293 as in PW VCCV. Multiple control channels can exist between end 294 points. 296 [RFC 5085] also defines a label-based exception mechanism that 297 helps an LSR to identify the control packets and direct them to 298 the appropriate entity for processing. The use of G-ACh and GAL 299 provides the necessary mechanisms to allow OAM packets run in-band 300 and share their fate with data packets. It is expected that all 301 of the OAM protocols will be used in conjunction with this Generic 302 Associated Channel. 304 o The [RFC 6370] document provides an IP-based identifier set for 305 MPLS-TP that can be used to identify the transport entities in the 306 network and referenced by the different OAM protocols. 307 [MPLS TP ITU Idents] augments that set of identifiers to include 308 identifier information in a format used by the ITU-T. Other 309 identifier sets may be defined as well. 311 3. MPLS-TP OAM Functions 313 The following sections discuss the OAM functions that are required in 314 [RFC 5860] and expanded upon in [RFC 6371]. 316 3.1. Continuity Check and Connectivity Verification 318 Continuity Check and Connectivity Verification (CC-CV) are OAM 319 operations generally used in tandem, and complement each other. 320 These functions are generally run proactively, but may also be used 321 on-demand for diagnoses of a specific condition. Proactively [RFC 322 5860] states that the function should allow the MEPs to monitor the 323 liveliness and connectivity of a transport path (LSP, PW or a 324 section) between them. In on-demand mode, this function should 325 support monitoring between the MEPs and, in addition, between a MEP 326 and MIP. Note that as specified in sections 3.3 and 3.4 of [RFC 327 6371], a MEP and a MIP can reside in an unspecified location within a 328 node, or in a particular interface on a specific side of the 329 forwarding engine. 331 The [RFC 6371] highlights the need for the CC-CV messages to include 332 unique identification of the MEG that is being monitored and the MEP 333 that originated the message. The function, both proactively and in 334 on-demand mode, needs to be transmitted at regular transmission rates 335 pre-configured by the operator. 337 3.1.1. Documents for CC-CV tools 339 [RFC 6428] defines BFD extensions to support proactive CC-CV 340 applications. 342 [RFC 6426] provides LSP-Ping extensions that are used to implement 343 on-demand Connectivity Verification. 345 Both of these tools will be used within the framework of the basic 346 tools described above, in section 2. 348 3.2. Remote Defect Indication 350 Remote Defect Indication (RDI) is used by a path end-point to report 351 that a defect is detected on a bi-directional connection to its peer 352 end-point. [RFC 5860] points out that this function may be applied 353 to a unidirectional LSP only if a return path exists. [RFC 6371] 354 points out that this function is associated with the proactive CC-CV 355 function. 357 3.2.1. Documents for RDI 359 The [RFC 6428] document includes an extension for BFD that would 360 include the RDI indication in the BFD format, and a specification of 361 how this indication is to be used. 363 3.3. Route Tracing 365 [RFC 5860] defines that there is a need for functionality that would 366 allow a path end-point to identify the intermediate (if any) and end- 367 points of the path (LSP, PW or a section). This function would be 368 used in on-demand mode. Normally, this path will be used for 369 bidirectional PW, LSP, and sections, however, unidirectional paths 370 may be supported only if a return path exists. 372 3.3.1. Documents for Route Tracing 374 The [RFC 6426] document that specifies the LSP-Ping enhancements for 375 MPLS-TP on-demand Connectivity Verification includes information on 376 the use of LSP-Ping for route tracing of a MPLS-TP transport path. 378 3.4. Alarm Reporting 380 Alarm Reporting is a function used by an intermediate point of a path 381 (LSP or PW), that becomes aware of a fault on the path, to report to 382 the end-points of the path. [RFC 6371] states that this may occur as 383 a result of a defect condition discovered at a server layer. The 384 intermediate point generates an Alarm Indication Signal (AIS) that 385 continues until the fault is cleared. The consequent action of this 386 function is detailed in [RFC 6371]. 388 3.4.1. Documents for Alarm Reporting 390 MPLS-TP defines a new protocol to address this functionality that is 391 documented in [RFC 6427]. This protocol uses all of the basic 392 mechanisms detailed in Section 2. 394 3.5. Lock Instruct 396 The Lock Instruct function is an administrative control tool that 397 allows a path end-point to instruct its peer end-point to lock the 398 path (LSP, PW or section). The tool is necessary to support single- 399 side provisioning for administrative locking, according to [RFC 400 6371]. This function is used on-demand. 402 3.5.1. Documents for Lock Instruct 404 The [RFC 6435] document describes the details of a new ACH based 405 protocol format for this functionality. 407 3.6. Lock Reporting 409 Lock reporting, defined in [RFC 5860], is similar to the Alarm 410 Reporting function described above. It is used by an intermediate 411 point to notify the end points of a transport path (LSP or PW) that 412 an administrative lock condition exists for this transport path. 414 3.6.1. Documents for Lock Reporting 416 MPLS-TP defines a new protocol to address this functionality that is 417 documented in [RFC 6427]. This protocol uses all of the basic 418 mechanisms detailed in Section 2. 420 3.7. Diagnostic 422 The [RFC 5860] indicates that there is need to provide a OAM function 423 that would enable conducting different diagnostic tests on a PW, LSP, 424 or Section. The [RFC 6371] provides two types of specific tests to 425 be used through this functionality: 427 o Throughput Estimation - allowing the provider to verify the 428 bandwidth/throughput of a transport path. This is an out-of- 429 service tool, that uses special packets of varying sizes to test 430 the actual bandwidth and/or throughput of the path. 432 o Data-plane loopback - this out-of-service tool causes all traffic 433 that reaches the target node, either a MEP or MIP, to be looped 434 back to the originating MEP. For targeting MIPs, a co-routed bi- 435 directional path is required. 437 3.7.1. Documents for Diagnostic Testing 439 The [RFC 6435] document describes the details of a new ACH based 440 protocol format for the Data-plane loopback functionality. 442 The tool for Throughput Estimation tool is under study. 444 3.8. Packet Loss Measurement 446 Packet Loss Measurement is required by [RFC 5860] to provide a 447 quantification of the packet loss ratio on a transport path. This is 448 the ratio of the number of user packets lost to the total number of 449 user packets during a defined time interval. To employ this 450 function, [RFC 6371] defines that the two end-points of the transport 451 path should exchange counters of messages transmitted and received 452 within a time period bounded by loss-measurement messages. The 453 framework warns that there may be small errors in the computation 454 that result from various issues. 456 3.8.1. Documents for Packet Loss Measurement 458 The [RFC 6374] document describes the protocol formats and procedures 459 for using the tool and enable efficient and accurate measurement of 460 packet loss, delay, and throughput in MPLS networks. [RFC 6375] 461 describes a profile of the general MPLS loss, delay, and throughput 462 measurement techniques that suffices to meet the specific 463 requirements of MPLS-TP. Note that the tool logic is based on the 464 behavior of the parallel function described in [Y.1731]. 466 3.9. Packet Delay Measurement 468 Packet Delay Measurement is a function that is used to measure one- 469 way or two-way delay of a packet transmission between a pair of the 470 end-points of a path (PW, LSP, or Section), as described in [RFC 471 5860]. Where: 473 o One-way packet delay is the time elapsed from the start of 474 transmission of the first bit of the packet by a source node until 475 the reception of the last bit of that packet by the destination 476 node. 478 o Two-way packet delay is the time elapsed from the start of 479 transmission of the first bit of the packet by a source node until 480 the reception of the last bit of the loop-backed packet by the 481 same source node, when the loopback is performed at the packet's 482 destination node. 484 [RFC 6371] describes how the tool could be performed (both in 485 proactive and on-demand modes) for either one-way or two-way 486 measurement. However, it warns that the one-way delay option 487 requires precise time synchronization between the end-points. 489 3.9.1. Documents for Delay Measurement 491 The [RFC 6374] document describes the protocol formats and procedures 492 for using the tool and enable efficient and accurate measurement of 493 packet loss, delay, and throughput in MPLS networks. [RFC 6375] 494 describes a profile of the general MPLS loss, delay, and throughput 495 measurement techniques that suffices to meet the specific 496 requirements of MPLS-TP. Note that the tool logic is based on the 497 behavior of the parallel function described in [Y.1731]. 499 4. MPLS-TP OAM documents guide 501 The complete MPLS-TP OAM protocol suite is covered by a small set of 502 existing IETF documents. This set of documents may be expanded in 503 the future to cover additional OAM functionality. In order to allow 504 the reader to understand this set of documents, a cross-reference of 505 the existing documents (IETF RFCs or Internet drafts while this 506 document is work in progress) for the initial phase of the 507 specification of MPLS based transport networks is provided below. 509 [RFC 5586] provides a specification of the basic structure of 510 protocol messages for in-band data plane OAM in an MPLS environment. 512 [RFC 6370] provides definitions of different formats that may be used 513 within OAM protocol messages to identify the network elements of a 514 MPLS based transport network. 516 The following table (Table 1) provides the summary of proactive 517 MPLS-TP OAM Fault Management toolset functions, associated tool/ 518 protocol, and the corresponding IETF RFCs where they are defined. 520 +--------------------------+-------------------------------+--------+ 521 | OAM Functions | OAM Tools/Protocols | RFCs | 522 +--------------------------+-------------------------------+--------+ 523 | Continuity Check and | Bidirectional Forwarding | [RFC | 524 | Connectivity | Detection (BFD) | 6428] | 525 | Verification | | | 526 +--------------------------+-------------------------------+--------+ 527 | Remote Defect Indication | Flag in Bidirectional | [RFC | 528 | (RDI) | Forwarding Detection (BFD) | 6428] | 529 | | message | | 530 +--------------------------+-------------------------------+--------+ 531 | Alarm Indication Signal | G-ACh bases AIS message | [RFC | 532 | (AIS) | | 6427] | 533 +--------------------------+-------------------------------+--------+ 534 | Link Down Indication | Flag in AIS message | [RFC | 535 | (LDI) | | 6427] | 536 +--------------------------+-------------------------------+--------+ 537 | Lock Reporting (LKR) | G-ACh bases LKR message | [RFC | 538 | | | 6427] | 539 +--------------------------+-------------------------------+--------+ 541 Proactive Fault Management OAM Toolset 543 Table 1 545 The following table (Table 2) provides an overview of the on-demand 546 MPLS-TP OAM Fault Management toolset functions, associated tool/ 547 protocol, and the corresponding IETF RFCs they are defined. 549 +------------------------+---------------------------------+--------+ 550 | OAM Functions | OAM Tools/Protocols | RFCs | 551 +------------------------+---------------------------------+--------+ 552 | Connectivity | LSP Ping | [RFC | 553 | Verification | | 6426] | 554 +------------------------+---------------------------------+--------+ 555 | Diagnostic: Loopback | (1) G-ACh based Loopback and | [RFC | 556 | and Lock Instruct | Lock Instruct, (2) LSP Ping | 6435] | 557 +------------------------+---------------------------------+--------+ 558 +------------------------+---------------------------------+--------+ 559 | Lock Instruct(LI) | Flag in AIS message | [RFC | 560 | | | 6427] | 561 +------------------------+---------------------------------+--------+ 563 On Demand Fault Management OAM Toolset 565 Table 2 567 The following table (Table 3) provides the Performance Monitoring 568 Fuctions, asscociated tool/protocol definitions, and corresponding 569 RFCs. 571 +----------------------+--------------------------+-----------------+ 572 | OAM Functions | OAM Tools/Protocols | RFCs | 573 +----------------------+--------------------------+-----------------+ 574 | Packet Loss | G-ACh based LM & DM | [RFC 6374] [RFC | 575 | Measurement (LM) | query messages | 6375] | 576 +----------------------+--------------------------+-----------------+ 577 | Packet Delay | G-ACh based LM & DM | [RFC 6374] [RFC | 578 | Measurement (DM) | query messages | 6375] | 579 +----------------------+--------------------------+-----------------+ 580 | Throughput | derived from Loss | [RFC 6374] [RFC | 581 | Measurement | Measurement | 6375] | 582 +----------------------+--------------------------+-----------------+ 583 | Delay Variation | derived from Delay | [RFC 6374] [RFC | 584 | Measurement | Measurement | 6375] | 585 +----------------------+--------------------------+-----------------+ 587 Performance Monitoring OAM Toolset 589 Table 3 591 5. OAM Toolset Applicability and Utilization 593 The following subsections present the MPLS-TP OAM toolset from the 594 perspective of the specified protocols and identifies which of the 595 required functionality is supported by the particular protocol. 597 5.1. Connectivity Check and Connectivity Verification 599 Proactive Continuity Check and Connectivity Verification (CC-CV) 600 functions are used to detect loss of continuity (LOC), and unintended 601 connectivity between two MEPs. Loss of connectivity, mis-merging, 602 mis-connectivity, or unexpected Maintenance Entity Group End Points 603 (MEPs) can be detected using the CC-CV tools. See Section 3.1, 3.2, 604 3.3 in this document for CC-CV protocol references. 606 The CC-CV tools are used to support MPLS-TP fault management, 607 performance management, and protection switching. Proactive CC-CV 608 control packets are sent by the source MEP to sink MEP. The sink MEP 609 monitors the arrival of the CC-CV control packets and detects the 610 defect. For bidirectional transport paths, the CC-CV protocol is, 611 usually, transmitted simultaneously in both directions. 613 The transmission interval of CC-CV control packet can be configured. 614 For example: 616 o 3.3ms is the default interval for protection switching. 618 o 100ms is the default interval for performance monitoring. 620 o 1s is the default interval for fault management. 622 5.2. Diagnostic Tests and Lock Instruct 624 [RFC 6435] describes a protocol that provides a mechanism is provided 625 to Lock and unlock traffic (e.g. data and control traffic) or 626 specific OAM traffic at a specific LSR on the path of the MPLS-TP LSP 627 to allow loop back of the traffic to the source. 629 These diagnostic functions apply to associated bidirectional MPLS-TP 630 LSPs, including MPLS-TP LSPs, bi-directional RSVP-TE tunnels (which 631 is relevant for MPLS-TP dynamic control plane option with GMPLS), and 632 single segment and multi-segment pseudowires. [RFC 6435] provides 633 the protocol definition for diagnostic tests functions. 635 The Lock operation instruction is carried in an MPLS Loopback request 636 message sent from a MEP to a trail-end MEP of the LSP to request that 637 the LSP be taken out of service. In response, the Lock operation 638 reply is carried in a Loopback response message sent from the trail- 639 end MEP back to the originating MEP to report the result. 641 The loopback operations include: 643 o Lock: take an LSP out of service for maintenance. 645 o Unlock: Restore a previously locked LSP to service. 647 o Set_Full_Loopback and Set_OAM_Loopback 649 o Unset_Full_Loopback and Set_OAM_Loopback 651 Operators can use the loopback mode to test the connectivity or 652 performance (loss, delay, delay variation, and throughput) of given 653 LSP up to a specific node on the path of the LSP. 655 5.3. Lock Reporting 657 The Lock Report (LKR) function is used to communicate to the client 658 (sub-) layer MEPs the administrative locking of a server (sub-) layer 659 MEP, and consequential interruption of data traffic forwarding in the 660 client (sub-) layer. See Section 3.6 in this document for Lock 661 Reporting protocol references. 663 When operator is taking the LSP out of service for maintenance or 664 other operational reason, using the LKR function can help to 665 distinguish the condition as administrative locking from defect 666 condition. 668 The Lock Report function would also serve the purpose of alarm 669 suppression in the MPLS-TP network above the level at which the Lock 670 has occurred. The receipt of an LKR message may be treated as the 671 equivalent of loss of continuity at the client layer. 673 5.4. Alarm Reporting and Link Down Indication 675 Alarm Indication Signal (AIS) message serves the purpose of alarm 676 suppression upon the failure detection in the server (-sub) layer. 677 When the Link Down Indication (RDI) is set, the AIS message may be 678 used to trigger recovery mechanisms. 680 When a server MEP detects the failure, it asserts Loss of Continuity 681 (LOC) or signal fail which sets the flag up to generate OAM packet 682 with AIS message. The AIS message is forwarded to downstream sink 683 MEP in the client layer. This would enable the client layer to 684 suppress the generation of secondary alarms. 686 A Link Down Indication (LDI) flag is defined in the AIS message. The 687 LDI flag is set in the AIS message in response to detecting a fatal 688 failure in the server layer. Receipt of an AIS message with this 689 flag set may be interpreted by a MEP as an indication of signal fail 690 at the client layer. 692 The protocols for Alarm Indication Signal (AIS) and Link Down 693 Indication (LDI) are defined in [RFC 6427]. 695 Fault OAM messages are generated by intermediate nodes where an LSP 696 is switched, and propagated to the end points (MEPs). 698 From a practical point of view, when both proactive Continuity Check 699 functions and LDI are used, one may consider running the proactive 700 Continuity Check functions at a slower rate (e.g. longer BFD hello 701 intervals), and reply on LDI to trigger fast protection switch over 702 upon failure detection in a given LSP. 704 5.5. Remote Defect Indication 706 Remote Defect Indication (RDI) function enables an End Point to 707 report to the other End Point that a fault or defect condition is 708 detected on the PW, LSP, or Section for which they are the End 709 Points. 711 The RDI OAM function is supported by the use of Bidirectional 712 Forwarding Detection (BFD) Control Packets [RFC 6428]. RDI is only 713 used for bidirectional connections and is associated with proactive 714 CC-CV activation. 716 When an end point (MEP) detects a signal failure condition, it sets 717 the flag up by setting the diagnostic field of the BFD control packet 718 to a particular value to indicate the failure condition on the 719 associated PW, LSP, or Section, and transmitting the BFD control 720 packet with the failure flag up to the other end point (its peer 721 MEP). 723 The RDI function can be used to facilitate protection switching by 724 synchronizing the two end points when unidirectional failure occurs 725 and is detected by one end. 727 5.6. Packet Loss and Delay Measurement 729 The packet loss and delay measurement toolset enables operators to 730 measure the quality of the packet transmission over a PW, LSP, or 731 Section. Section 3.8 in this document defined the protocols for 732 packet loss measurement and 3.9 in defined the protocols for packet 733 delay measurement. 735 The loss and delay protocols have the following characteristics and 736 capabilities: 738 o They support measurement of packet loss, delay and throughput over 739 Label Switched Paths (LSPs), pseudowires, and MPLS sections. 741 o The same LM and DM protocols can be used for both continuous/ 742 proactive and selective/on-demand measurement. 744 o The LM and DM protocols use a simple query/response model for 745 bidirectional measurement that allows a single node - the querier 746 - to measure the loss or delay in both directions. 748 o The LM and DM protocols use query messages for unidirectional loss 749 and delay measurement. The measurement can either be carried out 750 at the downstream node(s) or at the querier if an out-of-band 751 return path is available. 753 o The LM and DM protocols do not require that the transmit and 754 receive interfaces be the same when performing bidirectional 755 measurement. 757 o The LM supports test-message-based measurement (i.e. inferred 758 mode) as well as measurement based on data-plane counters (i.e. 759 direct mode). 761 o The LM protocol supports both 32-bit and 64-bit counters. 763 o The LM protocol supports measurement in terms of both packet 764 counts and octet counts although for simplicity only packet 765 counters are currently included in the MPLS-TP profile. 767 o The LM protocol can be used to measure channel throughput as well 768 as packet loss. 770 o The DM protocol supports varying the measurement message size in 771 order to measure delays associated with different packet sizes. 773 o The DM protocol uses IEEE 1588 timestamps by default but also 774 supports other timestamp formats such as NTP. 776 6. IANA Considerations 778 This document makes no request of IANA. 780 The OAM tools and functions defined under G-ACh use IANA assigned 781 code points. the codes are defined in the corresponding IETF RFCs 783 Note to RFC Editor: 785 this section may be removed on publication as an RFC. 787 7. Security Considerations 789 This document as an overview of MPLS OAM tools does not by itself 790 raise any particular security considerations. 792 The general security considerations are provided in [RFC 6920] and 793 [MPLS-TP Security Frwk]. Security considerations for each function 794 in the OAM toolset have been documented in each document that 795 specifies the particular functionality. 797 OAM in general is always an area where the security risk is high, 798 e.g. confidential information may be intercepted for attackers to 799 again access to the networks, therefore authentication, 800 authorization, and encryption need to be enforced for prevent 801 security breach. 803 In addition to implement security protocol, tools, and mechanisms, 804 following strict operation security procedures is very important, 805 especially MPSL-TP static provisioning processes involve operator 806 direct interactions with NMS and devices, its critical to prevent 807 human errors and malicious attacks. 809 Since MPLS-TP OAM uses G-ACh, the security risks and mitigation 810 described in [RFC 5085] apply here. In short, the G-ACh could be 811 intercepted, or false G-ACh packets could be inserted. DoS attack 812 could happen by flooding G-ACh messages to peer devices. To mitigate 813 this type of attacks, throttling mechanisms can be used. For more 814 details, please see [RFC 5085]. 816 8. Acknowledgements 818 The authors would like to thank the MPLS-TP experts from both the 819 IETF and ITU-T for their helpful comments. In particular, we would 820 like to thank Loa Andersson, and the Area Directors for their 821 suggestions and enhancements to the text. 823 Thanks to Tom Petch for useful comments and discussions. 825 Thanks to Rui Costa for his review and comments which helped improve 826 this doecument. 828 9. References 830 9.1. Normative References 832 [RFC 4379] 833 Kompella, K. and G. Swallow, "Detecting Multi-Protocol 834 Label Switched (MPLS) Data Plane Failures", RFC 4379, 835 February 2006. 837 [RFC 5085] 838 Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 839 Connectivity Verification (VCCV): A Control Channel for 840 Pseudowires", RFC 5085, December 2007. 842 [RFC 5586] 843 Bocci, M., Bryant, S., and M. Vigoureux, "MPLS Generic 844 Associated Channel", RFC 5586, June 2009. 846 [RFC 5654] 847 Niven-Jenkins, B., Nadeau, T., and C. Pignataro, 848 "Requirements for the Transport Profile of MPLS", 849 RFC 5654, April 2009. 851 [RFC 5860] 852 Vigoureux, M., Betts, M., and D. Ward, "Requirements for 853 OAM in MPLS Transport Networks", RFC 5860, April 2009. 855 [RFC 5880] 856 Katz, D. and D. Ward, "Bidirectional Forwarding 857 Detection", RFC 5880, February 2009. 859 [RFC 5884] 860 Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 861 "BFD For MPLS LSPs", RFC 5884, June 2008. 863 [RFC 5921] 864 Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 865 Berger, "A Framework for MPLS in Transport Networks", 866 RFC 5921, July 2010. 868 [RFC 6370] 869 Bocci, M., Swallow, G., and E. Gray, "MPLS-TP 870 Identifiers", RFC 6370, September 2011. 872 [RFC 6371] 873 Busi, I., Niven-Jenkins, B., and D. Allan, "MPLS-TP OAM 874 Framework and Overview", RFC 6371, September 2011. 876 [RFC 6374] 877 Frost, D. and S. Bryant, "Packet Loss and Delay 878 Measurement for MPLS Networks", RFC 6374, September 2011. 880 [RFC 6375] 881 Frost, D. and S. Bryant, "A Packet Loss and Delay 882 Measurement Profile for MPLS-based Transport Networks", 883 RFC 6375, September 2011. 885 [RFC 6426] 886 Bahadur, N., Aggarwal, R., Boutros, S., and E. Gray, "MPLS 887 on-demand Connectivity Verification, Route Tracing and 888 Adjacency Verification", RFC 6426, August 2011. 890 [RFC 6427] 891 Swallow, G., Fulignoli, A., and M. Vigoureux, "MPLS Fault 892 Management OAM", RFC 6427, September 2011. 894 [RFC 6428] 895 Allan, D. and G. Swallow, "Proactive Connectivity 896 Verification, Continuity Check and Remote Defect 897 indication for MPLS Transport Profile", RFC 6428, 898 August 2011. 900 [RFC 6435] 901 Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., 902 and X. Dai, "MPLS Transport Profile Lock Instruct and 903 Loopback Functions", RFC 6435, September 2011. 905 9.2. Informative References 907 [MPLS-TP Security Frwk] 908 Fang, L., Niven-Jenkins, B., and S. Mansfield, "MPLS-TP 909 Security Framework", 910 ID draft-ietf-mpls-tp-security-framework-02, May 2011. 912 [RFC 6920] 913 Fang, L., "Security Framework for MPLS and GMPLS 914 Networks", RFC 5920, July 2010. 916 [Y.1731] International Telecommunications Union - Standardization, 917 "OAM functions and mechanisms for Ethernet based 918 networks", ITU Y.1731, May 2006. 920 [MPLS TP ITU Idents] 921 Winter, R., van Helvoort, H., and M. Betts, "MPLS-TP 922 Identifiers Following ITU-T Conventions", 923 ID draft-ietf-mpls-tp-itu-t-identifiers-02, July 2011. 925 Authors' Addresses 927 Nurit Sprecher 928 Nokia Siemens Networks 929 3 Hanagar St. Neve Ne'eman B 930 Hod Hasharon, 45241 931 Israel 933 Email: nurit.sprecher@nsn.com 934 Luyuan Fang 935 Cisco 936 111 Wood Avenue South 937 Iselin, NJ 08830 938 USA 940 Email: lufang@cisco.com