idnits 2.17.1 draft-sprecher-mpls-tp-oam-analysis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 703. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 714. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 721. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 727. 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 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 (July 07, 2008) is 5772 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ICMP' is mentioned on line 131, but not defined == Missing Reference: 'MPLS BFD' is mentioned on line 184, but not defined == Missing Reference: 'PW-ACH' is mentioned on line 195, but not defined == Unused Reference: 'PW ACH' is defined on line 621, 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: 1 error (**), 0 flaws (~~), 7 warnings (==), 7 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: January 8, 2009 BT 6 H. van Helvoort, Ed. 7 Huawei 8 Y. Weingarten 9 Nokia Siemens Networks 10 July 07, 2008 12 MPLS-TP OAM Analysis 13 draft-sprecher-mpls-tp-oam-analysis-00.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 8, 2009. 40 Abstract 42 The intention of this document is to analyze the set of requirements 43 for OAM in MPLS-TP as defined in [MPLS-TP OAM Requirements], to 44 verify whether the existing MPLS OAM tools can be applied to these 45 requirements, identify which of the existing tools need to be 46 extended, and which new tools should be defined. Eventually, the 47 purpose of the document is to recommend which of the existing tools 48 should be extended and what new tools should be defined to support 49 the set of OAM requirements for MPLS-TP. 51 Requirements Language 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in [RFC2119]. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. MPLS BFD . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1.3. PW VCCV . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 1.4. Organization of the document . . . . . . . . . . . . . . . 6 64 2. Architectural requirements and general principles of 65 operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 2.1. Recommendations and Guidelines . . . . . . . . . . . . . . 8 67 3. MPLS-TP OAM Functions . . . . . . . . . . . . . . . . . . . . 9 68 3.1. Continuity Check . . . . . . . . . . . . . . . . . . . . . 9 69 3.1.1. Existing tools . . . . . . . . . . . . . . . . . . . . 9 70 3.1.2. Gaps . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.1.3. Recommendations and Guidelines . . . . . . . . . . . . 9 72 3.2. Connectivity Verification . . . . . . . . . . . . . . . . 9 73 3.2.1. Existing tools . . . . . . . . . . . . . . . . . . . . 10 74 3.2.2. Gaps . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 3.2.3. Recommendations and Guidelines . . . . . . . . . . . . 10 76 3.3. Alarm Suppression . . . . . . . . . . . . . . . . . . . . 10 77 3.3.1. Existing tools . . . . . . . . . . . . . . . . . . . . 10 78 3.3.2. Recommendations and Guidelines . . . . . . . . . . . . 10 79 3.4. Lock Indication . . . . . . . . . . . . . . . . . . . . . 10 80 3.4.1. Existing tools . . . . . . . . . . . . . . . . . . . . 10 81 3.4.2. Recommendations and Guidelines . . . . . . . . . . . . 11 82 3.5. Packet Loss Measurement . . . . . . . . . . . . . . . . . 11 83 3.5.1. Existing tools . . . . . . . . . . . . . . . . . . . . 11 84 3.5.2. Recommendations and Guidelines . . . . . . . . . . . . 11 85 3.6. Diagnostic Test . . . . . . . . . . . . . . . . . . . . . 11 86 3.6.1. Existing tools . . . . . . . . . . . . . . . . . . . . 11 87 3.6.2. Recommendations and Guidelines . . . . . . . . . . . . 11 88 3.7. Trace Route . . . . . . . . . . . . . . . . . . . . . . . 11 89 3.7.1. Existing tools . . . . . . . . . . . . . . . . . . . . 11 90 3.7.2. Recommendations and Guidelines . . . . . . . . . . . . 11 91 3.8. Delay Measurment . . . . . . . . . . . . . . . . . . . . . 12 92 3.8.1. Existing tools . . . . . . . . . . . . . . . . . . . . 12 93 3.8.2. Recommendations and Guidelines . . . . . . . . . . . . 12 94 3.9. Remote Defect Indication . . . . . . . . . . . . . . . . . 12 95 3.9.1. Existing tools . . . . . . . . . . . . . . . . . . . . 12 96 3.9.2. Recommendations and Guidelines . . . . . . . . . . . . 12 97 3.10. Client Signal Fail . . . . . . . . . . . . . . . . . . . . 13 98 3.10.1. Existing tools . . . . . . . . . . . . . . . . . . . . 13 99 3.10.2. Recommendations and Guidelines . . . . . . . . . . . . 13 100 4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 13 101 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 102 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 103 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 104 8. Informative References . . . . . . . . . . . . . . . . . . . . 14 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 106 Intellectual Property and Copyright Statements . . . . . . . . . . 17 108 1. Introduction 110 OAM (Operations, Administration, and Maintenance) plays a significant 111 and fundamental role in carrier networks, providing methods for fault 112 management and performance monitoring in both the transport and the 113 service layers on order to improve their ability to support services 114 with guaranteed and strict SLAs while reducing their operational 115 costs. 117 [MPLS-TP Requirements] in general and [MPLS-TP OAM Requirements] in 118 particular define a set of requirements on OAM functionality in 119 MPLS-TP for MPLS-TP LSPs (network infrastructure) and PWs (services). 121 The purpose of this document is to analyze the OAM requirements and 122 verify whether the existing OAM tools defined for MPLS can be used to 123 fulfill the requirements, identify which tools need to be extended to 124 comply with the requirements, and which new tools need to be defined. 125 The existing tools that are evaluated include LSP Ping (defined in 126 [LSP Ping]), MPLS BFD (defined in [ MPLS BFD ]) and Virtual Circuit 127 Connectivity Verification (defined in [PW VCCV] and [VCCV BFD]). 129 1.1. LSP Ping 131 LSP Ping is a variation of ICMP Ping and Traceroute [ICMP] that is 132 adapted to MPLS LSP. Addressing is based upon the LSP Label and 133 label stack in order to guarantee that the echo messages are switched 134 in-band of the LSP. The messages are transmitted using IP/UDP 135 encapsulation and IP addresses in the 127/8 (loopback) range. The 136 use of the loopback range guarantees that the LSP Ping messages will 137 not be transmitted outside the LSP. 139 LSP Ping extends the basic ICMP Ping operation (of data-plane 140 connectivity and continuity check) with functionality to verify data- 141 plane vs. control-plane consistency for a FEC and also MTU problems. 142 The traceroute functionality is used to isolate and localize the MPLS 143 faults, using the TTL to incrementally verify the path. While LSP 144 Ping is dependent upon the label propogation that may be performed 145 over the control-plane via LDP, there is no direct dependence of LSP 146 Ping on the control-plane. 148 LSP Ping can be activated both in on-demand and pro-active modes. 150 [P2MP LSP Ping] clarifies the applicability of LSP Ping to MPLS P2MP 151 LSPs, and extends the techniques and mechanisms of LSP Ping to the 152 MPLS P2MP environment. 154 [LSP Ping over MPLS Tunnels] extends LSP Ping to operate over MPLS 155 tunnels or for a stitched LSP. 157 TTL exhaust is the method for terminating flows at intermediate LSRs. 159 LSP Ping is considered to be computational intensive and does not 160 guarantee verification of the same data path in case of bundling. 162 1.2. MPLS BFD 164 BFD (Bidirectional Forwarding Detection) is a mechanism that is 165 defined for fast fault detection. BFD defines a simple packet that 166 may be transmitted over any protocol, dependent on the application 167 that is employing the mechanism. BFD does not support a discovery 168 mechanism nor support a traceroute capability for fault localization, 169 these must be provided by use of other mechanisms. BFD is dependent 170 upon creation of a session that is agreed upon by both ends of the 171 link (which may be a single link, LSP, etc.) that is being checked. 172 The BFD packets support authentication between the routers being 173 checked. 175 [MPLS BFD] defines the use of BFD for P2P LSP end-points and is used 176 to verify data-plane connectivity and to check continuity. It uses a 177 simple hello protocol which can be easily implemented in hardware. 178 The end-points of the LSP exchange hello packets at negotiated 179 regular intervals and an end-point is declared down when expected 180 hello packets do not show up. Failures in each direction can 181 independently be monitored using the same BFD session. 183 There is a need for a mechanism to bootstrap a BFD session and LSP 184 Ping is designated by [MPLS BFD] to bootstrap the BFD session in an 185 MPLS environment. The session BFD messages for MPLS are transmitted 186 using a IP/UDP encapsulation. 188 BFD can work in pro-active and on-demand modes of operation. 190 1.3. PW VCCV 192 PW VCCV provides end-to-end fault detection and diagnostics for PWs 193 (regardless of the underlying tunneling technology). It provides a 194 control channel associated with each PW (based on the PW Associated 195 Channel Header which is defined in [PW-ACH], and allows sending OAM 196 packets in-band with PW data (using CC Type 1: In-band VCCV) 198 VCCV supports the following OAM mechanisms: ICMP Ping, LSP Ping and 199 BFD. BFD for VCCV supports two modes of encapsulation - either IP/ 200 UDP encapsulated (with IP/UDP header) or PW-ACH encapsulated (with no 201 IP/UDP header) and provides support to signal the AC status.. The 202 use of the control channel provides the context required to bind the 203 BFD session to a particular pseudo wire (FEC). 205 VCCV consists of two components: (1) signaled component to 206 communicate VCCV capabilities as part of VC label, and (2) switching 207 component to cause the PW payload to be treated as a control packet. 209 VCCV is not directly dependent upon the presence of a control plane. 210 The VCCV capability negotiation may be performed as part of the PW 211 signaling when LDP is used. In case of manual configuration of the 212 PW, it is the responsibility of the operator to set consistent 213 options at both ends. 215 1.4. Organization of the document 217 The analysis of the architectural requirements and the general 218 principles of operations are discussed first and then the 219 requirements on the set of OAM functions. 221 Eventually, the purpose of the document is to recommend which of the 222 existing tools should be extended and what new tools should be 223 defined to support the set of OAM requirements in MPLS-TP. 225 2. Architectural requirements and general principles of operation 227 [MPLS-TP OAM Requirements] defines a set of requirements on OAM 228 architecture and general principles of operations which are evaluated 229 below: 231 o [MPLS-TP OAM Requirements] requires that OAM mechanisms in MPLS-TP 232 are independent of the transmission media and of the client 233 service being emulated by the PW. The existing tools comply with 234 this requirement. 236 o [MPLS-TP OAM Requirements] requires that MPLS-TP OAM MUST be able 237 to operate without IP functionality and without relying on control 238 and/or management planes. It is required that OAM functionality 239 MUST NOT be dependent on IP routing and forwarding capabilities. 240 The existing tools do not rely on control and/or management plane, 241 however the following should be observed regarding the reliance on 242 IP. 244 * LSP Ping makes use of IP header (UDP/IP) and does not comply 245 with the requirement. This has further implications concerning 246 the use of LSP Ping as the bootstrap mechanism for BFD for 247 MPLS. 249 * VCCV supports the use of PW-ACH encapsulated BFD sessions for 250 PWs and can comply with the requirement. 252 o [MPLS-TP OAM Requirements] requires that OAM tools for fault 253 management do not rely on user traffic, and the existing MPLS OAM 254 tools already comply with this requirement. It is also required 255 that OAM packets and the user traffic are congruent (i.e. OAM 256 packets are transmitted in-band) ad there is a need to 257 differentiate OAM packets from user-plane ones. 259 * For PWs, VCCV provides a control channel associated with each 260 PW which allows sending OAM packets in band of PWs and allow 261 the receiving end-point to intercept, interpret, and process 262 them locally as OAM messages. VCCV defines different VCCV 263 Connectivity Verification Types for MPLS (like ICMP Ping, LSP 264 Ping and IP/UD encapsulated BFD and PW-ACH encapsulated BFD). 266 * Currently there is no distinct OAM payload identifier in MPLS 267 shim. BFD and LSP Ping packets for LSPs are carried over 268 UDP/IP and are addressed to the loopback address range. The 269 router at the end-point intercepts, interprets, and processes 270 the packets. 272 o [MPLS-TP OAM Requirements] requires that the MPLS-TP OAM mechanism 273 allows the propagation of AC (Attachment Circuit) failures and 274 their clearance across a MPLS-TP domain 276 * BFD for VCCV supports a mechanism for "Fault detection and 277 AC/PW Fault status signaling." This can be used for both IP/ 278 UDP encapsulated or PW-ACH encapsulated BFD sessions, i.e. by 279 setting the appropriate VCCV Connectivity Verification 280 Type.This mechanism could support this requirement. 282 o [MPLS-TP OAM Requirements] defines Maintenance Domain, Maintenance 283 End Points (MEPs) and Maintenance Intermediate Points (MIPs). 284 Means should be defined to provision these entities, both by 285 static configuration (as it is required to operate OAM in the 286 absence of any control plane or dynamic protocols) and by a 287 control plane. 289 o [MPLS-TP OAM Requirements] requires a single OAM technology and 290 consistent OAM capabilities for LSPs, PWs and Tandem Connections. 291 There is currently no mechanism to support OAM for Tandem 292 Connections. Also, the existing set of tools defines a different 293 way of operating the OAM functions (e.g. LSP Ping to bootstrap 294 MPLS BFD vs. VCCV) and provide incomplete coverage of OAM 295 capabilities. 297 o [MPLS-TP OAM Requirements] requires allowing OAM packets to be 298 directed to an intermediate node on a LSP/PW. Technically this 299 can be supported by the proper setting of the TTL value, but it is 300 need to be examined per OAM function. For details, see below. 302 o [MPLS-TP OAM Requirements] suggests that OAM messages MAY be 303 authenticated. BFD has a support for authentication. Other tools 304 should support this capability as well. 306 2.1. Recommendations and Guidelines 308 Based on the requirements analysis above, the following guidelines 309 should be followed to create an OAM environment that could more fully 310 comply with the requirements cited: 312 o Extend the Associate Channel (AC) to provide a control channel at 313 the path level. This could then be associated with a LSP or a 314 Tandem Connection (TC). The ACH should then become a common 315 mechanism for PW, LSP, and Tandem Connection. 317 o Create a VPCV (Virtual Path Connectivity Verification) definition 318 that would apply the definitions and functionality of VCCV to the 319 MPLS-TP environment for LSP or Tandem Connection. 321 o Apply BFD to this new mechanism using the control channel 322 encapsulation, as defined above - allowing use of BFD for MPLS-TP 323 independent of IP routing. 325 o A mechanism that be defined to create TCME and allow transmission 326 of the traffic via the Tandem Connection using label stacking and 327 proper TTL settings (having the knowledge of the necessary hop 328 count). 330 Creating these extensions/mechanisms would fulfil the following 331 requirements, mentioned above: 333 o Independence of IP forwarding and routing. 335 o OAM packets should be transmitted in-band. 337 o Support a single OAM technology for LSP, PW, and TC. 339 In addition, the following additional requirements: 341 o Provide the ability to carry other types of communications (e.g., 342 APS, Management Control Channel (MCC), Signalling Control Channel 343 (SCC)). New types of communication channels and CV can be defined 344 for both PWs and LSPs. 346 o The design of the OAM mechanisms for MPLS-TP MUST allow the 347 ability to support vendor specific and experimental OAM functions. 349 3. MPLS-TP OAM Functions 351 The following sections discuss the required OAM functions that were 352 identified in [MPLS-TP OAM Requirements]. 354 LSP Ping is not considered a candidate to fulfil the required 355 functionality, due its failure to comply with the basic requirement 356 of independence from IP routing and forwarding, as documented in the 357 Section 4 of this document. 359 3.1. Continuity Check 361 Continuity Check (CC) is used to detect loss of continuity between 362 MEPs, or a MEP and MIP, and is useful for applications like Fault 363 Management, Performance Monitoring and Protection Switching, etc. 365 3.1.1. Existing tools 367 MPLS BFD can be used to support the OAM Continuity Check function. 368 It can be operated in a pro-active mode. However, the current 369 definition is dependent on LSP Ping to bootstrap the BFD session. 371 VCCV can be used as a platform for CC - using BFD packets that are 372 not IP/UDP encapsulated in pro-active mode. 374 3.1.2. Gaps 376 The following gaps are identified for support of CC in MPLS-TP 377 environment: 379 o A mechanism should be defined to bootstrap BFD sessions for MPLS 380 that is not dependent on UDP. 382 o Need extensions to BFD to cover P2MP connections. 384 3.1.3. Recommendations and Guidelines 386 Extend BFD to resolve the gaps. 388 Note that [MP BFD] defines a method for using BFD to provide 389 verification of multipoint or multicast connectivity. 391 3.2. Connectivity Verification 393 Connectivity Verification is a function that is used to check 394 connectivity between MEPs in a maintenance domain. This function may 395 be activated on-demand in reaction to a fault discovered in CC or for 396 more thorough testing of the connections. 398 3.2.1. Existing tools 400 MPLS BFD supports OAM Connectivity Verification and it can be 401 operated in both pro-active and on-demand modes. 403 3.2.2. Gaps 405 The following gaps are identified: 407 o See section 5.1.2 409 o BFD supports verification between MEP to MEP only. 411 3.2.3. Recommendations and Guidelines 413 As BFD works on a session basis, it seems complicated to extend it to 414 work also between MEP and MIP. It is recommended to define a new 415 simpler tool to support Connectivity Verification. 417 3.3. Alarm Suppression 419 Alarm Suppression is a function that is used by a server layer MEP to 420 notify a failure condition to its client layer MEP(s) in order to 421 suppress alarms that may be generated by maintenance domains of the 422 client layer as a result of the failure condition in the server 423 layer. 425 3.3.1. Existing tools 427 There is no mechanism defined in the IETF to support this function. 429 3.3.2. Recommendations and Guidelines 431 Define a tool to support Alarm Suppression. 433 3.4. Lock Indication 435 Lock Indication is a function that is used to indicate an 436 administrative locking of a server layer MEP which may result in 437 consequential interruption of data traffic forwarding towards the 438 client layer MEP(s) expecting this traffic. The reception of a Lock 439 Indication allows a MEP to differentiate between a defect condition 440 and an administrative locking action at the server layer MEP. 442 3.4.1. Existing tools 444 There is no mechanism defined in the IETF to support this function. 446 3.4.2. Recommendations and Guidelines 448 Define a tool to support Lock Indication. 450 3.5. Packet Loss Measurement 452 Continuity Check (CC) is used to detect loss of continuity between 453 MEPs, or a MEP and MIP, and is useful for applications like Fault 454 Management, Performance Monitoring and Protection Switching, etc. 456 3.5.1. Existing tools 458 There is no mechanism defined in the IETF to support this function. 460 3.5.2. Recommendations and Guidelines 462 Define a tool to support Packet Loss Measurement. 464 3.6. Diagnostic Test 466 A diagnostic test is a function that is used between MEPs to verify 467 bandwidth throughput, packet loss, bit errors, etc. 469 3.6.1. Existing tools 471 There is no mechanism defined in the IETF to support this function. 473 3.6.2. Recommendations and Guidelines 475 Define a tool to support Diagnostic Test. 477 3.7. Trace Route 479 Trace route is a function that is used to determine the route of a 480 connection across the MPLS transport network. 482 3.7.1. Existing tools 484 LSP Ping supports trace route but as it does not comply with the 485 requirement for OAM functions to be independent on IP routing and 486 forwarding capabilities, it can not be utilized for MPLS-TP 488 3.7.2. Recommendations and Guidelines 490 Define a new tool to support Trace Route. 492 3.8. Delay Measurment 494 Delay Measurement is a function that is used to measure one-way or 495 two-way delay of a packet transmission between a pair of MEPs. 496 Where: 498 o One-way packet delay is the time elapsed from the start of 499 transmission of the first bit of the packet by a source node until 500 the reception of the first bit of that packet by the destination 501 node. 503 o Two-way packet delay is the time elapsed from the start of 504 transmission of the first bit of the packet by a source node until 505 the reception of the last bit of the loop-backed packet by the 506 same source node, when the loopback is performed at the packet's 507 destination node. 509 3.8.1. Existing tools 511 There is no mechanism defined in the IETF to support this function. 513 3.8.2. Recommendations and Guidelines 515 Define a tool to support Delay Measurment. 517 3.9. Remote Defect Indication 519 Remote Defect Indication (RDI) is used by a MEP to notify its peer 520 MEP that a defect is detected on a bi-directional connection between 521 them. 523 This function should be supported in pro-active mode. 525 3.9.1. Existing tools 527 There is no mechanism defined in the IETF to fully support this 528 functionality, however BFD supports a mechanism of informing the far- 529 end that the session has gone down, and the Diagnostic field 530 indicates the reason. 532 3.9.2. Recommendations and Guidelines 534 Either create a dedicated mechanism for this functionality or extend 535 the BFD session functionality to support the functionality without 536 disrupting the CC or CV functionality. 538 3.10. Client Signal Fail 540 Client Signal Fail function (CSF) is used to propagate a Client 541 Failure indication to the far-end sink when alarm suppression in the 542 client layer is not supported. 544 3.10.1. Existing tools 546 There is no mechanism defined in the IETF to support this function. 548 3.10.2. Recommendations and Guidelines 550 Define a tool to support Delay Measurment. 552 4. Recommendation 554 o Define a Tandem Connection entity and allow the transmission of 555 traffic by means of label stacking and proper TTL setting. 557 o Extend ACH to provide a control channel for LSPs and Tandem 558 Connections. 560 o Define a VPCV mechanism for LSP and Tandem Connection. This 561 mechanism will use the same principles of operation as VCCV. The 562 ACH should be extended to support CV types for each of the tool 563 that are defined below, in a way that is consistent for PW, LSP 564 and Tandem Connection. 566 o Extend the control and the management planes to support the 567 configuration of the OAM maintenance entities and the set of 568 functions to be supported by these entities. 570 o Tools should be defined to support the following functions: 572 * Connectivity verification 574 * Alarm suppression 576 * Lock indication 578 * Packet loss measurement 580 * Diagnostic test 582 * Trace-route 583 * Delay measurement 585 * Remote defect indication 587 * Client signal fail 589 o The tools should have the capability to authenticate the messages. 591 Note:We may consider having a document to define common CC and CV 592 types of ACH for the use of VCCV and VPCV. 594 5. IANA Considerations 596 This document makes no request of IANA. 598 Note to RFC Editor: this section may be removed on publication as an 599 RFC. 601 6. Security Considerations 603 This document does not by itself raise any particular security 604 considerations. 606 7. Acknowledgements 608 The authors wish to thank xxxxxxx for his review and proposed 609 enhancements to the text. 611 8. Informative References 613 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 614 Requirement Levels", BCP 14, RFC 2119, March 1997. 616 [LSP Ping] 617 Kompella, K. and G. Swallow, "Detecting Multi-Protocol 618 Label Switched (MPLS) Data Plane Failures", RFC 4379, 619 February 2006. 621 [PW ACH] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 622 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 623 Use over an MPLS PSN", RFC 4385, February 2006. 625 [PW VCCV] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 626 Connectivity Verification (VCCV): A Control Channel for 627 Pseudowires", RFC 5085, December 2007. 629 [MP BFD] Katz, D. and D. Ward, "BFD for Multipoint Networks", 630 ID draft-katz-ward-bfd-multipoint-01.txt, December 2007. 632 [VCCV BFD] 633 Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 634 Detection (BFD) for the Pseudowire Virtual Circuit 635 Connectivity Verification (VCCV)", 636 ID draft-ietf-pwe3-vccv-bfd-01.txt, February 2008. 638 [P2MP LSP Ping] 639 Nadeau, T. and A. Farrel, "Detecting Data Plane Failures 640 in Point-to-Multipoint Multiprotocol Label Switching 641 (MPLS) - Extensions to LSP Ping", 642 ID draft-ietf-mpls-p2mp-lsp-ping-06.txt, June 2008. 644 [MPLS LSP Ping] 645 Bahadur, N. and K. Kompella, "Mechanism for performing 646 LSP-Ping over MPLS tunnels", 647 ID draft-ietf-mpls-lsp-ping-enhanced-dsmap-00, June 2008. 649 [MPLS-TP OAM Requirements] 650 Vigoreux, M. and M. Betts, "Requirements for OAM in MPLS 651 Transport Networks", 652 ID draft-author-mpls-tp-oam-requirements-00, July 2008. 654 [MPLS-TP Requirments] 655 Nadeau, T. and C. Pignataro, "Requirements for the 656 Trasport Profile of MPLS", 657 ID draft-jenkins-mpls-mplstp-requirements-00, July 2008. 659 Authors' Addresses 661 Nurit Sprecher (editor) 662 Nokia Siemens Networks 663 3 Hanagar St. Neve Ne'eman B 664 Hod Hasharon, 45241 665 Israel 667 Email: nurit.sprecher@nsn.com 668 Tom Nadeau (editor) 669 BT 670 United State 672 Email: tom.nadeau@bt.com 674 Huub van Helvoort (editor) 675 Huawei 676 B 677 Netherlands 679 Email: hhelvoort@huawei.com 681 Yaacov Weingarten 682 Nokia Siemens Networks 683 3 Hanagar St. Neve Ne'eman B 684 Hod Hasharon, 45241 685 Israel 687 Email: yaacov.weingarten@nsn.com 689 Full Copyright Statement 691 Copyright (C) The IETF Trust (2008). 693 This document is subject to the rights, licenses and restrictions 694 contained in BCP 78, and except as set forth therein, the authors 695 retain all their rights. 697 This document and the information contained herein are provided on an 698 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 699 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 700 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 701 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 702 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 703 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 705 Intellectual Property 707 The IETF takes no position regarding the validity or scope of any 708 Intellectual Property Rights or other rights that might be claimed to 709 pertain to the implementation or use of the technology described in 710 this document or the extent to which any license under such rights 711 might or might not be available; nor does it represent that it has 712 made any independent effort to identify any such rights. Information 713 on the procedures with respect to rights in RFC documents can be 714 found in BCP 78 and BCP 79. 716 Copies of IPR disclosures made to the IETF Secretariat and any 717 assurances of licenses to be made available, or the result of an 718 attempt made to obtain a general license or permission for the use of 719 such proprietary rights by implementers or users of this 720 specification can be obtained from the IETF on-line IPR repository at 721 http://www.ietf.org/ipr. 723 The IETF invites any interested party to bring to its attention any 724 copyrights, patents or patent applications, or other proprietary 725 rights that may cover technology that may be required to implement 726 this standard. Please address the information to the IETF at 727 ietf-ipr@ietf.org.