idnits 2.17.1 draft-sprecher-mpls-tp-oam-analysis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 357: '...uires that MPLS-TP OAM MUST be able to...' RFC 2119 keyword, line 360: '... MUST NOT be dependent on IP rout...' RFC 2119 keyword, line 438: '...eqs] suggests that OAM messages MAY be...' RFC 2119 keyword, line 501: '... mechanisms for MPLS-TP MUST allow the...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 10, 2009) is 5458 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ICMP' is defined on line 902, but no explicit reference was found in the text == Unused Reference: 'PW VCCV' is defined on line 914, but no explicit reference was found in the text == Outdated reference: A later version (-02) exists of draft-katz-ward-bfd-multipoint-01 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-vccv-bfd-01 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Sprecher, Ed. 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational T. Nadeau, Ed. 5 Expires: November 11, 2009 BT 6 H. van Helvoort, Ed. 7 Huawei 8 Y. Weingarten 9 Nokia Siemens Networks 10 May 10, 2009 12 MPLS-TP OAM Analysis 13 draft-sprecher-mpls-tp-oam-analysis-04.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 11, 2009. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 The intention of this document is to analyze the set of requirements 52 for Operations, Administration, and Maintenance (OAM) for the 53 Transport Profile of MPLS(MPLS-TP) as defined in [MPLS-TP OAM Reqs], 54 to evaluate whether existing OAM tools (either from the current MPLS 55 toolset or from the ITU-T documents) can be applied to these 56 requirements. Eventually, the purpose of the document is to 57 recommend which of the existing tools should be extended and what new 58 tools should be defined to support the set of OAM requirements for 59 MPLS-TP. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.2. MPLS BFD . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 1.3. PW VCCV . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 1.4. ITU Recommendation Y.1731 . . . . . . . . . . . . . . . . 7 68 1.5. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 1.6. Organization of the document . . . . . . . . . . . . . . . 8 70 2. Architectural requirements and general principles of 71 operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 2.1. Architectural and Principles of Operation - 73 Recommendations and Guidelines . . . . . . . . . . . . . . 11 74 3. MPLS-TP OAM Functions . . . . . . . . . . . . . . . . . . . . 12 75 3.1. Continuity Check and Connectivity Verification . . . . . . 12 76 3.1.1. Existing tools . . . . . . . . . . . . . . . . . . . . 12 77 3.1.2. Gap analysis . . . . . . . . . . . . . . . . . . . . . 13 78 3.1.3. Recommendations and Guidelines . . . . . . . . . . . . 14 79 3.2. Alarm Notification . . . . . . . . . . . . . . . . . . . . 14 80 3.2.1. Existing tools . . . . . . . . . . . . . . . . . . . . 14 81 3.2.2. Recommendations and Guidelines . . . . . . . . . . . . 14 82 3.3. Diagnostic . . . . . . . . . . . . . . . . . . . . . . . . 15 83 3.3.1. Existing tools . . . . . . . . . . . . . . . . . . . . 15 84 3.3.2. Recommendations and Guidelines . . . . . . . . . . . . 15 85 3.4. Adjacency and Route Tracing . . . . . . . . . . . . . . . 15 86 3.4.1. Existing tools . . . . . . . . . . . . . . . . . . . . 15 87 3.4.2. Recommendations and Guidelines . . . . . . . . . . . . 15 88 3.5. Lock . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 3.5.1. Existing tools . . . . . . . . . . . . . . . . . . . . 16 90 3.5.2. Recommendations and Guidelines . . . . . . . . . . . . 16 91 3.6. Remote Defect Indication . . . . . . . . . . . . . . . . . 16 92 3.6.1. Existing tools . . . . . . . . . . . . . . . . . . . . 16 93 3.6.2. Recommendations and Guidelines . . . . . . . . . . . . 16 94 3.7. Client Fail Indication . . . . . . . . . . . . . . . . . . 17 95 3.7.1. Existing tools . . . . . . . . . . . . . . . . . . . . 17 96 3.7.2. Recommendations and Guidelines . . . . . . . . . . . . 17 97 3.8. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17 98 3.8.1. Existing tools . . . . . . . . . . . . . . . . . . . . 17 99 3.8.2. Recommendations and Guidelines . . . . . . . . . . . . 18 100 3.9. Delay Measurement . . . . . . . . . . . . . . . . . . . . 18 101 3.9.1. Existing tools . . . . . . . . . . . . . . . . . . . . 18 102 3.9.2. Recommendations and Guidelines . . . . . . . . . . . . 19 103 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 19 104 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 105 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 106 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 107 8. Informative References . . . . . . . . . . . . . . . . . . . . 20 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 110 1. Introduction 112 OAM (Operations, Administration, and Maintenance) plays a significant 113 and fundamental role in carrier networks, providing methods for fault 114 management and performance monitoring in both the transport and the 115 service layers in order to improve their ability to support services 116 with guaranteed and strict Service Level Agreements (SLAs) while 117 reducing their operational costs. 119 [MPLS-TP Reqs] in general, and [MPLS-TP OAM Reqs] in particular 120 define a set of requirements for OAM functionality in MPLS-Transport 121 Profile (MPLS-TP) for MPLS-TP Label Switched Paths (LSPs) (network 122 infrastructure) and Pseudowires (PWs) (services). 124 The purpose of this document is to analyze the OAM requirements and 125 evaluate whether existing OAM tools defined for MPLS can be used to 126 meet the requirements, identify which tools need to be extended to 127 comply with the requirements, and which new tools need to be defined. 128 We also take the ITU-T OAM toolset, as defined in [Y.1731], as a 129 candidate to base these new tools upon. The existing tools that are 130 evaluated include LSP Ping (defined in [LSP Ping]), MPLS Bi- 131 directional Forwarding Detection (BFD) (defined in [MPLS BFD]) and 132 Virtual Circuit Connectivity Verification (VCCV) (defined in [PW 133 VCCV] and [VCCV BFD]), and the ITU-T OAM toolset defined in [Y.1731]. 135 1.1. LSP Ping 137 LSP Ping is a variation of ICMP Ping and traceroute [ICMP]] adapted 138 to the different needs of MPLS LSP. Forwarding, of the LSP Ping 139 packets, is based upon the LSP Label and label stack, in order to 140 guarantee that the echo messages are switched in-band (i.e. over the 141 same data route) of the LSP. However, it should be noted that the 142 messages are transmitted using IP/UDP encapsulation and IP addresses 143 in the 127/8 (loopback) range. The use of the loopback range 144 guarantees that the LSP Ping messages will be terminated, by a loss 145 of connectivity or inability to continue on the path, without being 146 transmitted beyond the LSP. The return message of the LSP Ping could 147 be sent either on the return LSP of a corouted bidirectional LSP, or 148 for associated bidirectional LSPs or unidirectional LSPs may be sent 149 using IP forwarding to the IP address of the LSP ingress node. 151 LSP Ping extends the basic ICMP Ping operation (of data-plane 152 connectivity and continuity check) with functionality to verify data- 153 plane vs. control-plane consistency for a Forwarding Equivalence 154 Class (FEC) and also Maximum Transmission Unit (MTU) problems. The 155 traceroute functionality may be used to isolate and localize the MPLS 156 faults, using the Time-to-live (TTL) indicator to incrementally 157 identify the sub-path of the LSP that is succesfully traversed before 158 the faulty link or node. LSP Ping is not dependent on the MPLS 159 control-plane for its operation, i.e. even though the propagation of 160 the LSP label may be performed over the control-plane via the Label 161 Distribution Protocol (LDP). 163 LSP Ping can be activated both in on-demand and pro-active 164 (asynchronous) modes, as defined in [MPLS-TP OAM Reqs]. 166 [P2MP LSP Ping] clarifies the applicability of LSP Ping to MPLS P2MP 167 LSPs, and extends the techniques and mechanisms of LSP Ping to the 168 MPLS P2MP environment. 170 [MPLS LSP Ping] extends LSP Ping to operate over MPLS tunnels or for 171 a stitched LSP. 173 As pointed out above, TTL exhaust is the method used to terminate 174 flows at intermediate LSRs, usually to locate a problem that was 175 discovered previously. 177 Some of the drawbacks identified with LSP Ping include - LSP Ping is 178 considered to be computational intensive as pointed out in [MPLS 179 BFD]. Use of the loopback address range (to protect against leakage 180 outside the LSP) assumes that all of the intermediate nodes support 181 some IP functionality. When LSP bundling is employed in the network, 182 there is no guarantee that the LSP Ping packets will follow the same 183 physical path used by the data traffic. 185 1.2. MPLS BFD 187 BFD (Bidirectional Forwarding Detection) is a mechanism that is 188 defined for fast fault detection for point-to-point connections. BFD 189 defines a simple packet that may be transmitted over any protocol, 190 dependent on the application that is employing the mechanism. BFD is 191 dependent upon creation of a session that is agreed upon by both ends 192 of the link (which may be a single link, LSP, etc.) that is being 193 checked. The session is assigned a separate identifier by each end 194 of the path being monitored. This session identifier is by nature 195 only unique within the context of node that assigned it. As part of 196 the session creation, the end-points negotiate an agreed transmission 197 rate for the BFD packets. BFD supports an echo function to check the 198 continuity, and verify the reachability of the desired destination. 199 BFD does not support neither a discovery mechanism nor a traceroute 200 capability for fault localization, these must be provided by use of 201 other mechanisms. The BFD packets support authentication between the 202 routers being checked. 204 BFD can be used in pro-active (asynchronous) and on-demand modes, as 205 defined in [MPLS-TP OAM Reqs], of operation. 207 [MPLS BFD] defines the use of BFD for P2P LSP end-points and is used 208 to verify data-plane continuity. It uses a simple hello protocol 209 which can be easily implemented in hardware. The end-points of the 210 LSP exchange hello packets at negotiated regular intervals and an 211 end-point is declared down when expected hello packets do not show 212 up. Failures in each direction can be monitored independently using 213 the same BFD session. The use of the BFD echo function and on-demand 214 activation are outside the scope of the MPLS BFD specification. 216 The BFD session mechanism requires an additional (external) mechanism 217 to bootstrap and bind the session to a particular LSP or FEC. LSP 218 Ping is designated by [MPLS BFD] as the bootstrap mechanism for the 219 BFD session in an MPLS environment. The implication is that the 220 session establishment BFD messages for MPLS are transmitted using a 221 IP/UDP encapsulation. 223 In order to be able to identify certain extreme cases of mis- 224 connectivity, it is necessary that each managed connection have its 225 own unique identifiers. BFD uses Discriminator values to identify 226 the connection being verified, at both ends of the path. These 227 discriminator values are set by each end-node to be unique only in 228 the context of that node. This limited scope of uniqueness would not 229 identify a misconnection of crossing paths that could assign the same 230 discriminators to the different sessions. 232 1.3. PW VCCV 234 PW VCCV provides end-to-end fault detection and diagnostics for PWs 235 (regardless of the underlying tunneling technology). The VCCV 236 switching function provides a control channel associated with each PW 237 (based on the PW Associated Channel Header (ACH) which is defined in 238 [PW ACH]), and allows sending OAM packets in-band with PW data (using 239 CC Type 1: In-band VCCV) 241 VCCV currently supports the following OAM mechanisms: ICMP Ping, LSP 242 Ping, and BFD. ICMP and LSP Ping are IP encapsulated before being 243 sent over the PW ACH. BFD for VCCV supports two modes of 244 encapsulation - either IP/UDP encapsulated (with IP/UDP header) or 245 PW-ACH encapsulated (with no IP/UDP header) and provides support to 246 signal the AC status. The use of the VCCV control channel provides 247 the context, based on the MPLS-PW label, required to bind and 248 bootstrap the BFD session to a particular pseudo wire (FEC), 249 eliminating the need to exchange Discriminator values. 251 VCCV consists of two components: (1) signaled component to 252 communicate VCCV capabilities as part of VC label, and (2) switching 253 component to cause the PW payload to be treated as a control packet. 255 VCCV is not directly dependent upon the presence of a control plane. 256 The VCCV capability negotiation may be performed as part of the PW 257 signaling when LDP is used. In case of manual configuration of the 258 PW, it is the responsibility of the operator to set consistent 259 options at both ends. 261 1.4. ITU Recommendation Y.1731 263 [Y.1731] specifies a set of OAM procedures and related packet data 264 unit (PDU) formats that meet the transport network requirements for 265 OAM. These PDU and procedures address similar requirements to those 266 outlined in [MPLS-TP OAM Reqs]. 268 The PDU and procedures are described relative to an Ethernet 269 environment, with the appropriate encapsulation for that environment. 270 However, the actual PDU formats are technology agnostic and could be 271 carried over different encapsulations, e.g. VCCV control channel. 272 The OAM procedures, likewise, could be supported by MPLS-TP nodes 273 just as they are supported by Ethernet nodes. 275 [Y.1731] describes procedures to support the following OAM functions: 277 o Connectivity and Continuity Monitoring - for end-to-end checking 279 o Loopback functionality - to verify connectivity to intermediate 280 nodes 282 o Link trace - provides information on the intermediate nodes of the 283 path being monitored, may be used for fault localization. 285 o Alarm indication signaling - for alarm suppression in case of 286 faults that are detected at the server layer. 288 o Remote defect indication &ndash as part of the Connectivity and 289 Continuity Monitoring packets 291 o Performance monitoring - including measurement of packet delays 292 both uni and bi-directional, measurement of the ratio of lost 293 packets, and the effective bandwidth that is supported without 294 packet loss. 296 It should be noted that the PDU defined in [Y.1731] includes various 297 information elements (fields) that may not be defined in [MPLS-TP OAM 298 Framework]. These fields include information on the MEG-Level, 299 OpCode, and version. Addressing of the PDU as defined in [Y.1731] is 300 based on the MAC Address of the nodes, which would need to be 301 adjusted to support other addressing schemes, length of additional 302 information. The addressing information is carried in (TLV) fields that follow the actual PDU. 305 1.5. Acronyms 307 This draft uses the following acronyms: 309 +---------+------------------------------------------------+ 310 | AC | Attachment Circuit | 311 | ACH | Associated Channel Header | 312 | BFD | Bidirectional Forwarding Detection | 313 | CC-V | Continuity Check and Connectivity Verification | 314 | FEC | Forwarding Equivalence Class | 315 | LDP | Label Distribution Protocol | 316 | LSP | Label Switched Path | 317 | ME | Maintenance Entitity | 318 | MEP | Maintenance End Point | 319 | MIP | Maintenance Intermediate Point | 320 | MPLS-TP | Transport Profile for MPLS | 321 | OAM | Operations, Administration, and Maintenance | 322 | PDU | Packet Data Unit | 323 | PW | Pseudowire | 324 | RDI | Remote Defect Indication | 325 | SLA | Service Level Agreement | 326 | TC | Tandem Connection | 327 | TCME | Tandem Connection Maintenance Entity | 328 | TTL | Time-to-live | 329 | VCCV | Virtual Circuit Connectivity Verification | 330 | VPCV | Virtual Path Connectivity Verification | 331 +---------+------------------------------------------------+ 333 1.6. Organization of the document 335 Section 2 of the document analyzes the requirements that are 336 documented in [MPLS-TP OAM Reqs] and provides basic principles of 337 operation for the OAM functionality that is required. 339 Section 3 evaluates which existing tools can provide coverage for the 340 different OAM functions that are required to support MPLS-TP. 342 Section 4 provides recommendations on what functionality could be 343 covered by the existing toolset and what extensions or new tools 344 would be needed in order to provide full coverage of the OAM 345 functionality for MPLS-TP. 347 2. Architectural requirements and general principles of operation 349 [MPLS-TP OAM Reqs] defines a set of requirements on OAM architecture 350 and general principles of operations which are evaluated below: 352 o [MPLS-TP OAM Reqs] requires that OAM mechanisms in MPLS-TP are 353 independent of the transmission media and of the client service 354 being emulated by the PW. The existing tools comply with this 355 requirement. 357 o [MPLS-TP OAM Reqs] requires that MPLS-TP OAM MUST be able to 358 operate without IP functionality and without relying on control 359 and/or management planes. It is required that OAM functionality 360 MUST NOT be dependent on IP routing and forwarding capabilities. 361 The existing tools do not rely on control and/or management plane, 362 however the following should be observed regarding the reliance on 363 IP functionality: 365 * LSP Ping, VCCV Ping, and MPLS BFD makes use of IP header 366 (UDP/IP) and do not comply with the requirement. In the on- 367 demand mode, LSP Ping also uses IP forwarding to reply back to 368 the source router. This dependence on IP, has further 369 implications concerning the use of LSP Ping as the bootstrap 370 mechanism for BFD for MPLS. 372 * VCCV BFD supports the use of PW-ACH encapsulated BFD sessions 373 for PWs and can comply with the requirement. 375 * Y.1731 PDU are technology agnostic and thereby not dependent on 376 IP functionality. These PDU could be carried by a VCCV control 377 channel. 379 o [MPLS-TP OAM Reqs] requires that OAM tools for fault management do 380 not rely on user traffic, and the existing MPLS OAM tools and 381 Y.1731 already comply with this requirement. 383 o It is also required that OAM packets and the user traffic are 384 congruent (i.e. OAM packets are transmitted in-band) and there is 385 a need to differentiate OAM packets from user-plane ones. 387 * For PWs, VCCV provides a control channel that can be associated 388 with each PW which allows sending OAM packets in band of PWs 389 and allow the receiving end-point to intercept, interpret, and 390 process them locally as OAM messages. VCCV defines different 391 VCCV Connectivity Verification Types for MPLS (like ICMP Ping, 392 LSP Ping and IP/UDP encapsulated BFD and PW-ACH encapsulated 393 BFD). 395 * Currently there is no distinct OAM payload identifier in MPLS 396 shim. BFD and LSP Ping packets for LSPs are carried over 397 UDP/IP and are addressed to the loopback address range. The 398 router at the end-point intercepts, interprets, and processes 399 the packets. 401 * The Y.1731 PDU could be carried over a control channel defined 402 along the data path and the processing of the PDU would occur 403 at the destination indicated in the PDU. 405 o [MPLS-TP OAM Reqs] requires that the MPLS-TP OAM mechanism allows 406 the propagation of AC (Attachment Circuit) failures and their 407 clearance across a MPLS-TP domain 409 * BFD for VCCV supports a mechanism for "Fault detection and 410 AC/PW Fault status signaling." This can be used for both IP/ 411 UDP encapsulated or PW-ACH encapsulated BFD sessions, i.e. by 412 setting the appropriate VCCV Connectivity Verification 413 Type.This mechanism could support this requirement. 415 o [MPLS-TP OAM Reqs] defines Maintenance Domain, Maintenance End 416 Points (MEPs) and Maintenance Intermediate Points (MIPs). Means 417 should be defined to provision these entities, both by static 418 configuration (as it is required to operate OAM in the absence of 419 any control plane or dynamic protocols) and by a control plane. 420 Note that the Y.1731 functionality currently supports these 421 entities. 423 o [MPLS-TP OAM Reqs] requires a single OAM technology and consistent 424 OAM capabilities for LSPs, PWs, MPLS-TP Links, and Tandem 425 Connections. There is currently no mechanism in the IETF to 426 support OAM for Tandem Connections. Also, the existing set of 427 tools defines a different way of operating the OAM functions (e.g. 428 LSP Ping to bootstrap MPLS BFD vs. VCCV). Currently, the Y.1731 429 functionality is defined for Ethernet paths, and the procedures 430 would need to be redefined for the various MPLS-TP path concepts. 432 o [MPLS-TP OAM Reqs] requires allowing OAM packets to be directed to 433 an intermediate node (MIP) of a LSP/PW. Technically, this could 434 be supported by the proper setting of the TTL value. However, the 435 applicability of such a solution needs to be examined per OAM 436 function. For details, see below. 438 o [MPLS-TP OAM Reqs] suggests that OAM messages MAY be 439 authenticated. BFD has a support for authentication. Other tools 440 should support this capability as well. Y.1731 functionality uses 441 the identification of the path for authentication. 443 2.1. Architectural and Principles of Operation - Recommendations and 444 Guidelines 446 Based on the requirements analysis above, the following guidelines 447 should be followed to create an OAM environment that could more fully 448 support the requirements cited: 450 o Extend the PW Associate Channel Header (ACH) to provide a control 451 channel at the path and section levels. This could then be 452 associated with a MPLS-TP Link, LSP, or a Tandem Connection (TC). 453 The ACH should then become a common mechanism for PW, LSP, MPLS-TP 454 Link, and Tandem Connection. 456 o Create a VPCV (Virtual Path Connectivity Verification) definition 457 that would apply the definitions and functionality of VCCV to the 458 MPLS-TP environment for LSP or Tandem Connection. Need a 459 generalized addressing scheme that can also support unique 460 identification of the monitored paths (or connections). 462 o Create or extend the VCCV definition to define a mechanism that 463 would apply the definitions and functionality of VCCV to PW Tandem 464 Connections 466 o Apply BFD to these new mechanisms using the control channel 467 encapsulation, as defined above - allowing use of BFD for MPLS-TP 468 independent of IP functionality. This could be used to address 469 the CC-V functionality 471 o The Y.1731 PDU set could be used as a basis for defining the 472 information units to be transmitted over the VPCV. The actual 473 procedures and addressing schemes would need to be adjusted for 474 the MPLS-TP environment. 476 o Define a mechanism to create TCME and allow transmission of the 477 traffic via the Tandem Connection using label stacking. 479 o Define a mechanism that could be used to address a MIP of a path 480 in a unique way, to support the maintenance functions. This 481 addressing should be flexible to allow support for different 482 addressing schemes, and would supplement the TTL addressing of 483 intermediate points. 485 Creating these extensions/mechanisms would fulfill the following 486 architectural requirements, mentioned above: 488 o Independence of IP forwarding and routing. 490 o OAM packets should be transmitted in-band. 492 o Support a single OAM technology for LSP, PW, MPLS-TP Link, and TC. 494 In addition, the following additional requirements can be satisfied: 496 o Provide the ability to carry other types of communications (e.g., 497 APS, Management Control Channel (MCC), Signalling Control Channel 498 (SCC)), by defining new types of communication channels for PWs, 499 MPLS-TP Links, and LSPs. 501 o The design of the OAM mechanisms for MPLS-TP MUST allow the 502 ability to support vendor specific and experimental OAM functions. 504 3. MPLS-TP OAM Functions 506 The following sections discuss the required OAM functions that were 507 identified in [MPLS-TP OAM Reqs]. 509 LSP Ping is not considered a candidate to fulfill the required 510 functionality, due its failure to comply with the basic architectural 511 requirement for independence from IP routing and forwarding, as 512 documented in Section 2 of this document. However, usage of LSP 513 Ping, in addition to the MPLS-TP OAM tools, or in MPLS-TP deployments 514 with IP functionality is not precluded. 516 3.1. Continuity Check and Connectivity Verification 518 Continuity Check and Connectivity Verification (CC-V) are OAM 519 operations generally used in tandem, and compliment each other. 520 Together they are used to detect loss of traffic continuity and 521 misconnections between MEPs and are useful for applications like 522 Fault Management, Performance Monitoring and Protection Switching, 523 etc. To guarantee that CC-V can identify misconnections from cross- 524 connections it is necessary that the tool use network-wide unique 525 identifiers for the path that is being checked in the session. 527 3.1.1. Existing tools 529 LSP Ping provides much of the functionality required for corouted 530 bidirectional LSPs. As observed above, LSP Ping may be operated in 531 both asynchronous and on-demand mode. Addressing is based on the LSP 532 label and the basic functionality only requires support for the 533 loopback address range in each node on the LSP path. 535 BFD defines functionality that can be used to support the pro-active 536 OAM CC-V function when operated in the asynchronous mode. However, 537 the current definition of basic BFD is dependent on use of LSP Ping 538 to bootstrap the BFD session. Regarding the connectivity functional 539 aspects, basic BFD has a limitation that it uses only locally unique 540 (to each node) session identifiers. 542 VCCV can be used to carry BFD packets that are not IP/UDP 543 encapsulated for CC-V on a PW and use the PW label to identify the 544 path. 546 Y.1731 provides functionality for all aspects of CC-V for an Ethernet 547 environment, this could be translated for the MPLS-TP environment. 548 The CCM PDU defined in [Y.1731] includes the ability to set the 549 frequency of the messages that are transmitted, and provides for 550 attaching the address of the path (in the Ethernet case - the MEG 551 Level) and a sequencing number to verify that CCM messages were not 552 dropped. 554 3.1.2. Gap analysis 556 There is currently no single MPLS tool that gives coverage for all 557 aspects of CC-V functionality. 559 LSP Ping could be used to cover the cases of corouted bidirectional 560 LSPs. However, there is a certain amount of computational overhead 561 involved with use of LSP Ping (as was observed in sec 1.1), the 562 verification of the control-plane, and the need to support the 563 loopback functionality at each intermediate node. 565 BFD could be extended to fill the gaps indicated above. The 566 extension would include: 568 o A mechanism should be defined to carry BFD packets over LSP 569 without reliance on IP functionality. 571 o A mechanism should be defined to bootstrap BFD sessions for MPLS 572 that is not dependent on UDP. 574 o BFD needs to be used in conjunction with "globally" unique 575 identifiers for the path or ME being checked to allow connectivity 576 verfication support. There are two possibilities, to allow BFD to 577 support this new type of identifier - 579 * Change the semantics of the two Discriminator fields that exist 580 in BFD and have each node select the ME unique identifier. 581 This may have backward compatibility implications. 583 * Create a new optional field in the packet carrying the BFD that 584 would identify the path being checked, in addition to the 585 existing session identifiers. 587 o Extensions to BFD would be needed to cover P2MP connections. 589 Use of the Y.1731 functionality is another option that should be 590 considered. The basic PDU for CCM includes (in the flags field) an 591 indication of the frequency of the packets [eliminating the need to 592 "negotiate" the frequency between the end-points], and also a flag 593 used for RDI. The procedure itself would need adaptation to comply 594 with the MPLS environment. 596 An additional option would be to create a new tool that would give 597 coverage for both aspects of CC-V according to the requirements and 598 the principles of operation (see section 2.1). This option is less 599 preferable. 601 3.1.3. Recommendations and Guidelines 603 Extend BFD to resolve the gaps, using a new optional field for the 604 unique path identifier. And optionally support the PDU format 605 defined in [Y.1731] with appropriate adjustments to support the 606 MPLS-TP architecture. 608 Note that [MPLS BFD] defines a method for using BFD to provide 609 verification of multipoint or multicast connectivity. 611 3.2. Alarm Notification 613 Alarm Notification is a function that is used by a server layer MEP 614 to notify a failure condition to its client layer MEP(s) in order to 615 suppress alarms that may be generated by maintenance domains of the 616 client layer as a result of the failure condition in the server 617 layer. This function should also have the capability to 618 differentiate an administrative lock from a failure condition at a 619 different execution level. 621 3.2.1. Existing tools 623 There is no mechanism defined in the IETF to support this function. 624 Y.1731 does define a PDU and procedure for this functionality. 626 3.2.2. Recommendations and Guidelines 628 Define a tool to support Alarm Notification. This tool could be 629 designed around the PDU proposed by [Y.1731] that includes support 630 for an indication of the frequency at which these messages are 631 transmitted after the alarm is raised until it is cleared. 633 3.3. Diagnostic 635 A diagnostic test is a function that is used between MEPs to verify 636 bandwidth throughput, packet loss, bit errors, etc. This is usually 637 performed by sending packets of varying sizes at increasing rates 638 (until the limits of the service level) to measure the actual 639 utilization. 641 3.3.1. Existing tools 643 There is no mechanism defined in the IETF to support this function. 644 [Y.1731] describes a function that is dependent on sending a series 645 of TST packets (this is a PDU whose size can be varied) at differing 646 frequencies. 648 3.3.2. Recommendations and Guidelines 650 Define a tool to support Diagnostic that could be based on the Y.1731 651 function. 653 3.4. Adjacency and Route Tracing 655 Functinality of route determination is used to determine the route of 656 a connection across the MPLS transport network. [MPLS-TP OAM Reqs] 657 defines two closely related operations - one, Adjacency, for 658 discovery of neighboring nodes and the other, Route Tracing, for 659 determination of the path that is being traversed and location of a 660 fault identified by e.g. the CC-V tool. 662 3.4.1. Existing tools 664 LSP Ping supports a trace route function that could be used for co- 665 routed bidirectional paths. This could support the second type of 666 fnctionality. 668 However, the discovery aspect that is described by the Adjacency 669 function does not have any available tools, neither in the IETF 670 toolset nor in the ITU recommendations. 672 3.4.2. Recommendations and Guidelines 674 Define a new tool to support the Adjacency functionality. 676 For the Route Trace functionality, either extend the LSP Ping 677 functionality to support other options, i.e. PW, associated 678 bidirectional LSP, or define a new tool. 680 3.5. Lock 682 The Lock function allows the system to block off transmission of data 683 along a LSP. When a path end-point receives a command, e.g. from the 684 management system, that the path is blocked, the end-point informs 685 the far-end that the path has been locked and that no data should be 686 transmitted. This function is used on-demand. 688 3.5.1. Existing tools 690 There is no mechanism defined in the IETF to support this function. 691 Y.1731 does define a PDU and procedure for this functionality. 693 3.5.2. Recommendations and Guidelines 695 Define a tool to support Lock. This tool could be designed around 696 the procedure proposed by [Y.1731] that includes support for an 697 indication of the frequency at which these messages are transmitted 698 until the lock situation is cleared. 700 3.6. Remote Defect Indication 702 Remote Defect Indication (RDI) is used by a MEP to notify its peer 703 MEP that a defect, usually a unidirectional defect, is detected on a 704 bi-directional connection between them. 706 This function should be supported in pro-active mode. 708 3.6.1. Existing tools 710 There is no mechanism defined in the IETF to fully support this 711 functionality, however BFD supports a mechanism of informing the far- 712 end that the session has gone down, and the Diagnostic field 713 indicates the reason. Similarly, when LSP Ping is used for a 714 corouted bidirectional LSP the far-end LER could notify that there 715 was a misconnectivity. 717 In [Y.1731] this functionality is defined as part of the CC-V 718 function as a flag in the PDU. 720 3.6.2. Recommendations and Guidelines 722 Either create a dedicated mechanism for this functionality or extend 723 the BFD session functionality to support the functionality without 724 disrupting the CC or CV functionality. Such an extension could be 725 similar to that suggested by the ITU recommendation 727 3.7. Client Fail Indication 729 Client Fail Indication (CFI) function is used to propagate an 730 indication of a failure to the far-end sink when alarm suppression in 731 the client layer is not supported. 733 3.7.1. Existing tools 735 There is a possibility of using the BFD over VCCV mechanism for 736 "Fault detection and AC/PW Fault status signalling". However, there 737 is a need to differentiate between faults on the AC and the PW. 739 3.7.2. Recommendations and Guidelines 741 Either extend the BFD tool or define a tool to support Client Fail 742 Indication propagation. 744 3.8. Packet Loss 746 Packet Loss is a function that is used to verify the quality of the 747 service. This function indicates the ratio of packets that are not 748 delivered out of all packets that are transmitted by the path source. 750 There are two possible ways of determining this measurement - 752 o Using OAM packets, it is possible to compute the statistics based 753 on a series of OAM packets. This, however, has the disadvantage 754 of being artificial, and may not be representative since part of 755 the packet loss may be dependent upon packet sizes. 757 o Sending delimiting messages for the start and end of a measurement 758 period during which the source and sink of the path count the 759 packets transmitted and received. After the end delimiter, the 760 ratio would be calculated by the path OAM entity. 762 3.8.1. Existing tools 764 There is no mechanism defined in the IETF to support this function. 765 [Y.1731] describes a function that is based on sending the CCM 766 packets [used for CC-V support (see sec 3.1)] for proactive support 767 and specialized loss-measurement packets for on-demand measurement. 768 These packets include information (in the additional TLV fields) of 769 packet counters that are maintained by each of the end-points of a 770 path. These counters maintain a count of packets transmitted by the 771 ingress end-point and the count of packets received from the far-end 772 of the path by the egress end-point. 774 3.8.2. Recommendations and Guidelines 776 One possibility is to define a mechanism to support Packet Loss 777 Measurement, based on the delimiting messages. This would include a 778 way for delimiting the periods for monitoring the packet 779 transmissions to measure the loss ratios, and computation of the 780 ratio between received and transmitted packets. 782 A second possibility would be to define a functionality based on the 783 description of the loss-measurement function defined in [Y.1731] that 784 is dependent on the counters maintained, by the MPLS LSR (as 785 described in [RFC3813], of received and transmitted octets. 787 3.9. Delay Measurement 789 Delay Measurement is a function that is used to measure one-way or 790 two-way delay of a packet transmission between a pair of MEPs. 791 Where: 793 o One-way packet delay is the time elapsed from the start of 794 transmission of the first bit of the packet by a source node until 795 the reception of the first bit of that packet by the destination 796 node. 798 o Two-way packet delay is the time elapsed from the start of 799 transmission of the first bit of the packet by a source node until 800 the reception of the last bit of the loop-backed packet by the 801 same source node, when the loopback is performed at the packet's 802 destination node. 804 Similarly to the packet loss measurement this could be performed in 805 one of two ways - 807 o Using OAM packets - checking delay (either one-way or two-way) in 808 transmission of OAM packets. May not fully reflect delay of 809 larger packets, however, gives feedback on general service level. 811 o Using delimited periods of transmission - may be too intrusive on 812 the client traffic. 814 3.9.1. Existing tools 816 There is no mechanism defined in the IETF toolset that fulfills all 817 of the MPLS-TP OAM requirements. 819 [Y.1731] describes a function in which specific OAM packets are sent 820 with a transmission time-stamp from one end of the managed path to 821 the other end (these are transparent to the intermediate nodes). The 822 delay measurement is supported for both unidirectional and 823 bidirectional measurement of the delay. 825 3.9.2. Recommendations and Guidelines 827 Define a mechanism that would allow to support Delay Measurement. 828 The mechanism should be based on measurement of the delay in 829 transmission and reception of OAM packets, transmitted in-band with 830 normal traffic. This tool could be based on the tool defined in 831 [Y.1731]. 833 4. Recommendations 835 o Define a maintenance entity that could be applied both to LSPs and 836 PWs that would support management of a sub-path. This entity 837 should allow for transmission of traffic by means of label 838 stacking and proper TTL setting. 840 o Extend the control and the management planes to support the 841 configuration of the OAM maintenance entities and the set of 842 functions to be supported by these entities. 844 o Extend the ACH to provide a control channel for MPLS-TP Links, 845 LSPs, and Tandem Connections. 847 o Define a mechanism that would allow the unique addressing of the 848 elements that need to be monitored, e.g., the connections, MEPs, 849 and MIPs of a path. This mechanism needs to be flexible enough to 850 support different addressing schemes, e.g. IP addresses, NSAP, 851 connection names. 853 o Define a VPCV mechanism for LSP and Tandem Connection. This 854 mechanism should reuse, as much as possible, the same principles 855 of operation as VCCV. The ACH should be extended to support CV 856 types for each of the tools that are defined below, in a way that 857 is consistent for PW, LSP and Tandem Connection. 859 o The appropriate assignment of network-wide unique identifiers 860 needed to support connectivity verification should be considered. 862 o Tools should be defined to support the following functions. The 863 tools could be based on the procedures and PDU format defined by 864 [Y.1731] or extensions to existing MPLS tools: 866 * On-demand connectivity verification 867 * Alarm suppression 869 * Packet loss measurement 871 * Diagnostic test 873 * Route determination 875 * Delay measurement 877 * Remote defect indication 879 * Client fail indication 881 o The tools may have the capability to authenticate the messages. 883 5. IANA Considerations 885 This document makes no request of IANA. 887 Note to RFC Editor: this section may be removed on publication as an 888 RFC. 890 6. Security Considerations 892 This document does not by itself raise any particular security 893 considerations. 895 7. Acknowledgements 897 The authors wish to thank xxxxxxx for his review and proposed 898 enhancements to the text. 900 8. Informative References 902 [ICMP] Postel, J., "Internet Control Message Protocol", STD 5, 903 RFC 792, Sept 1981. 905 [LSP Ping] 906 Kompella, K. and G. Swallow, "Detecting Multi-Protocol 907 Label Switched (MPLS) Data Plane Failures", RFC 4379, 908 February 2006. 910 [PW ACH] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 911 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 912 Use over an MPLS PSN", RFC 4385, February 2006. 914 [PW VCCV] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 915 Connectivity Verification (VCCV): A Control Channel for 916 Pseudowires", RFC 5085, December 2007. 918 [MPLS BFD] 919 Katz, D. and D. Ward, "BFD for Multipoint Networks", 920 ID draft-katz-ward-bfd-multipoint-01.txt, December 2007. 922 [VCCV BFD] 923 Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 924 Detection (BFD) for the Pseudowire Virtual Circuit 925 Connectivity Verification (VCCV)", 926 ID draft-ietf-pwe3-vccv-bfd-01.txt, February 2008. 928 [P2MP LSP Ping] 929 Nadeau, T. and A. Farrel, "Detecting Data Plane Failures 930 in Point-to-Multipoint Multiprotocol Label Switching 931 (MPLS) - Extensions to LSP Ping", 932 ID draft-ietf-mpls-p2mp-lsp-ping-06.txt, June 2008. 934 [MPLS LSP Ping] 935 Bahadur, N. and K. Kompella, "Mechanism for performing 936 LSP-Ping over MPLS tunnels", 937 ID draft-ietf-mpls-lsp-ping-enhanced-dsmap-00, June 2008. 939 [MPLS-TP OAM Reqs] 940 Vigoureux, M., Betts, M., and D. Ward, "Requirements for 941 OAM in MPLS Transport Networks", 942 ID draft-ietf-mpls-tp-oam-requirements-01, April 2009. 944 [MPLS-TP OAM Frwk] 945 Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM Framework and 946 Overview", ID draft-ietf-mpls-tp-oam-requirements-01, 947 March 2009. 949 [MPLS-TP Reqs] 950 Nadeau, T. and C. Pignataro, "Requirements for the 951 Trasport Profile of MPLS", 952 ID draft-ietf-mpls-tp-requirements-06, April 2009. 954 [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, 955 "Multiprotocol Label Switching (MPLS) Label Switching 956 Router (LSR) Management Information Base (MIB)", 957 RFC 3813, June 2004. 959 [Y.1731] International Telecommunications Union - Standardization, 960 "OAM functions and mechanisms for Ethernet based 961 networks", ITU Y.1731, May 2006. 963 Authors' Addresses 965 Nurit Sprecher (editor) 966 Nokia Siemens Networks 967 3 Hanagar St. Neve Ne'eman B 968 Hod Hasharon, 45241 969 Israel 971 Email: nurit.sprecher@nsn.com 973 Tom Nadeau (editor) 974 BT 975 United States 977 Email: tom.nadeau@bt.com 979 Huub van Helvoort (editor) 980 Huawei 981 Kolkgriend 38, 1356 BC Almere 982 Netherlands 984 Phone: +31 36 5316076 985 Email: hhelvoort@huawei.com 987 Yaacov Weingarten 988 Nokia Siemens Networks 989 3 Hanagar St. Neve Ne'eman B 990 Hod Hasharon, 45241 991 Israel 993 Phone: +972-9-775 1827 994 Email: yaacov.weingarten@nsn.com