idnits 2.17.1 draft-sprecher-mpls-tp-oam-analysis-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Oct 18, 2009) is 5301 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-bfd-base-09 Summary: 1 error (**), 0 flaws (~~), 2 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 H. van Helvoort, Ed. 5 Expires: April 21, 2010 Huawei 6 E. Bellagamba 7 Ericsson 8 Y. Weingarten 9 Nokia Siemens Networks 10 Oct 18, 2009 12 MPLS-TP OAM Analysis 13 draft-sprecher-mpls-tp-oam-analysis-07.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. This document may contain material 19 from IETF Documents or IETF Contributions published or made publicly 20 available before November 10, 2008. The person(s) controlling the 21 copyright in some of this material may not have granted the IETF 22 Trust the right to allow modifications of such material outside the 23 IETF Standards Process. Without obtaining an adequate license from 24 the person(s) controlling the copyright in such materials, this 25 document may not be modified outside the IETF Standards Process, and 26 derivative works of it may not be created outside the IETF Standards 27 Process, except to format it for publication as an RFC or to 28 translate it into languages other than English. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 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 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on April 21, 2010. 48 Copyright Notice 49 Copyright (c) 2009 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents in effect on the date of 54 publication of this document (http://trustee.ietf.org/license-info). 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. 58 Abstract 60 This document analyzes the set of requirements for Operations, 61 Administration, and Maintenance (OAM) for the Transport Profile of 62 MPLS(MPLS-TP) as defined in [MPLS-TP OAM Reqs], to evaluate whether 63 existing OAM tools (either from the current MPLS toolset or from the 64 ITU-T documents) can be applied to these requirements. Eventually, 65 the purpose of the document is to recommend which of the existing 66 tools should be extended and what new tools should be defined to 67 support the set of OAM requirements for MPLS-TP. This document 68 reports the conclusions of the MPLS-TP design team discussions 69 concerning the MPLS-TP OAM tools at IETF75. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 76 1.3. Organization of the document . . . . . . . . . . . . . . . 6 77 1.4. LSP Ping . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 1.5. MPLS BFD . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 1.6. PW VCCV . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 1.7. ITU Recommendation Y.1731 . . . . . . . . . . . . . . . . 9 81 1.8. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 2. Architectural requirements and general principles of 83 operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 2.1. Architectural and Principles of Operation - 85 Recommendations and Guidelines . . . . . . . . . . . . . . 13 86 3. MPLS-TP OAM Functions . . . . . . . . . . . . . . . . . . . . 14 87 3.1. Continuity Check and Connectivity Verification . . . . . . 14 88 3.1.1. Existing tools . . . . . . . . . . . . . . . . . . . . 14 89 3.1.2. Gap analysis . . . . . . . . . . . . . . . . . . . . . 15 90 3.1.3. Recommendations and Guidelines . . . . . . . . . . . . 16 91 3.2. Alarm Reporting . . . . . . . . . . . . . . . . . . . . . 16 92 3.2.1. Existing tools . . . . . . . . . . . . . . . . . . . . 16 93 3.2.2. Recommendations and Guidelines . . . . . . . . . . . . 16 94 3.3. Diagnostic . . . . . . . . . . . . . . . . . . . . . . . . 17 95 3.3.1. Existing tools . . . . . . . . . . . . . . . . . . . . 17 96 3.3.2. Recommendations and Guidelines . . . . . . . . . . . . 17 97 3.4. Route Tracing . . . . . . . . . . . . . . . . . . . . . . 17 98 3.4.1. Existing tools . . . . . . . . . . . . . . . . . . . . 17 99 3.4.2. Recommendations and Guidelines . . . . . . . . . . . . 17 100 3.5. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 18 101 3.5.1. Existing tools . . . . . . . . . . . . . . . . . . . . 18 102 3.5.2. Recommendations and Guidelines . . . . . . . . . . . . 18 103 3.6. Lock Reporting . . . . . . . . . . . . . . . . . . . . . . 18 104 3.6.1. Existing tools . . . . . . . . . . . . . . . . . . . . 18 105 3.6.2. Recommendations and Guidelines . . . . . . . . . . . . 18 106 3.7. Remote Defect Indication . . . . . . . . . . . . . . . . . 18 107 3.7.1. Existing tools . . . . . . . . . . . . . . . . . . . . 19 108 3.7.2. Recommendations and Guidelines . . . . . . . . . . . . 19 109 3.8. Client Failure Indication . . . . . . . . . . . . . . . . 19 110 3.8.1. Existing tools . . . . . . . . . . . . . . . . . . . . 19 111 3.8.2. Recommendations and Guidelines . . . . . . . . . . . . 19 112 3.9. Packet Loss Measurement . . . . . . . . . . . . . . . . . 19 113 3.9.1. Existing tools . . . . . . . . . . . . . . . . . . . . 20 114 3.9.2. Recommendations and Guidelines . . . . . . . . . . . . 20 115 3.10. Packet Delay Measurement . . . . . . . . . . . . . . . . . 20 116 3.10.1. Existing tools . . . . . . . . . . . . . . . . . . . . 21 117 3.10.2. Recommendations and Guidelines . . . . . . . . . . . . 21 118 4. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 21 119 5. MPLS-TP OAM Documents Organization . . . . . . . . . . . . . . 23 120 5.1. Document 1: "Encapsulation of BFD and LspPing in ACH" . . 24 121 5.2. Document 2: "Extended BFD" . . . . . . . . . . . . . . . . 24 122 5.3. Document 3: "Extended LSP Ping" . . . . . . . . . . . . . 24 123 5.4. Document 4: "Extensions for Lock Instruct" . . . . . . . . 25 124 5.5. Document 5: "AIS and Lock Reporting" . . . . . . . . . . . 25 125 5.6. Document 6: "Client Fault Indication" . . . . . . . . . . 25 126 5.7. Document 7: "Packet Loss" . . . . . . . . . . . . . . . . 26 127 5.8. Document 8: "Packet Delay" . . . . . . . . . . . . . . . . 26 128 5.9. Document 9: "Diagnostic Tests" . . . . . . . . . . . . . . 26 129 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 130 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 131 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 132 9. Informative References . . . . . . . . . . . . . . . . . . . . 26 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 135 1. Introduction 137 1.1. Scope 139 OAM (Operations, Administration, and Maintenance) plays a significant 140 role in carrier networks, providing methods for fault management and 141 performance monitoring in both the transport and the service layers 142 in order to improve their ability to support services with guaranteed 143 and strict Service Level Agreements (SLAs) while reducing their 144 operational costs. 146 [MPLS-TP Reqs] in general, and [MPLS-TP OAM Reqs] in particular 147 define a set of requirements for OAM functionality in MPLS-Transport 148 Profile (MPLS-TP) for MPLS-TP Label Switched Paths (LSPs) (network 149 infrastructure) and Pseudowires (PWs) (services). 151 The purpose of this document is to analyze the OAM requirements and 152 evaluate whether existing OAM tools defined for MPLS can be used to 153 meet the requirements, identify which tools need to be extended to 154 comply with the requirements, and which new tools need to be defined. 155 We also take the ITU-T OAM toolset, as defined in [Y.1731], as a 156 candidate to base these new tools upon. The existing tools that are 157 evaluated include LSP Ping (defined in [LSP Ping]), MPLS Bi- 158 directional Forwarding Detection (BFD) (defined in [BASE BFD]) and 159 Virtual Circuit Connectivity Verification (VCCV) (defined in [PW 160 VCCV] and [VCCV BFD]), and the ITU-T OAM toolset defined in [Y.1731]. 162 This document reports the conclusions of the MPLS-TP design team 163 discussions on the MPLS-TP OAM tools at IETF75 and the guidelines 164 that were agreed. The guidelines refer to a set of existing OAM 165 tools that need to be enhanced to fully support the MPLS-TP OAM 166 requirements and identify new tools that need to be defined. The 167 organizational structure of the documents on MPLS-TP OAM tools was 168 also discussed and agreed at IETF75 and is described later in this 169 document. 171 1.2. Requirements Language 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC 2119]. Although 176 this document is not a protocol specification, the use of this 177 language clarifies the instructions to protocol designers producing 178 solutions that satisfy the requirements set out in this document. 180 1.3. Organization of the document 182 Sections 1.3 - 1.6 provide an overview of the existing MPLS tools. 184 Section 2 of the document analyzes the requirements that are 185 documented in [MPLS-TP OAM Reqs] and provides basic principles of 186 operation for the OAM functionality that is required. 188 Section 3 evaluates which existing tools can provide coverage for the 189 different OAM functions that are required to support MPLS-TP. 191 The recommendations are summarized in section 4, and reflect the 192 guidelines which were agreed by the MPLS-TP design team during the 193 meetings at IETF 75. These guidelines relate to the functionality 194 could be covered by the existing toolset and what extensions or new 195 tools would be needed in order to provide full coverage of the OAM 196 functionality for MPLS-TP. 198 The OAM tools for MPLS-TP OAM will be defined in a set of documents. 199 Section 5 describes the organization of this set of documents as 200 agreed by the MPLS-TP design team at IETF75. 202 1.4. LSP Ping 204 LSP Ping is a variation of ICMP Ping and traceroute [ICMP] adapted to 205 the needs of MPLS LSP. Forwarding, of the LSP Ping packets, is based 206 upon the LSP Label and label stack, in order to guarantee that the 207 echo messages are switched in-band (i.e. over the same data route) of 208 the LSP. However, it should be noted that the messages are 209 transmitted using IP/UDP encapsulation and IP addresses in the 127/8 210 (loopback) range. The use of the loopback range guarantees that the 211 LSP Ping messages will be terminated, by a loss of connectivity or 212 inability to continue on the path, without being transmitted beyond 213 the LSP. For a bi-directional LSP (either associated or co-routed) 214 the return message of the LSP Ping could be sent on the return LSP. 215 For unidirectional LSPs and in some case for bi-directional LSPs, the 216 return message may be sent using IP forwarding to the IP address of 217 the LSP ingress node. 219 LSP Ping extends the basic ICMP Ping operation (of data-plane 220 connectivity and continuity check) with functionality to verify data- 221 plane vs. control-plane consistency for a Forwarding Equivalence 222 Class (FEC) and also Maximum Transmission Unit (MTU) problems. The 223 traceroute functionality may be used to isolate and localize the MPLS 224 faults, using the Time-to-live (TTL) indicator to incrementally 225 identify the sub-path of the LSP that is successfully traversed 226 before the faulty link or node. 228 As mentioned above, LSP Ping requires the presenece of the MPLS 229 control plane when verifying the consistency of the data-plane 230 against the control-plane. However, LSP Ping is not dependent on the 231 MPLS control-plane for its operation, i.e. even though the 232 propagation of the LSP label may be performed over the control-plane 233 via the Label Distribution Protocol (LDP). 235 It should be noted that LSP Ping does support unique identification 236 of the LSP within an addressing domain. The identification is 237 checked using the full FEC identification. LSP Ping is easily 238 extensible to include additional information needed to support new 239 functionality, by use of Type-Length-Value (TLV) constructs. 241 LSP Ping can be activated both in on-demand and pro-active 242 (asynchronous) modes, as defined in [MPLS-TP OAM Reqs]. 244 [P2MP LSP Ping] clarifies the applicability of LSP Ping to MPLS P2MP 245 LSPs, and extends the techniques and mechanisms of LSP Ping to the 246 MPLS P2MP environment. 248 [MPLS LSP Ping] extends LSP Ping to operate over MPLS tunnels or for 249 a stitched LSP. 251 As pointed out above, TTL exhaust is the method used to terminate 252 flows at intermediate LSRs. This is used as part of the traceroute 253 of a path and to locate a problem that was discovered previously. 255 Some of the drawbacks identified with LSP Ping include - LSP Ping is 256 considered to be computational intensive as pointed out in [MPLS 257 BFD]. The applicability for a pro-active mode of operation is 258 analyzed in the sections below. Use of the loopback address range 259 (to protect against leakage outside the LSP) assumes that all of the 260 intermediate nodes support some IP functionality. Note that ECMP is 261 not supported in MPLS-TP, therefore its implication on OAM 262 capabilities is not analyzed in this document. 264 1.5. MPLS BFD 266 BFD (Bidirectional Forwarding Detection) [BASE BFD] is a mechanism 267 that is defined for fast fault detection for point-to-point 268 connections. BFD defines a simple packet that may be transmitted 269 over any protocol, dependent on the application that is employing the 270 mechanism. BFD is dependent upon creation of a session that is 271 agreed upon by both ends of the link (which may be a single link, 272 LSP, etc.) that is being checked. The session is assigned a separate 273 identifier by each end of the path being monitored. This session 274 identifier is by nature only unique within the context of node that 275 assigned it. As part of the session creation, the end-points 276 negotiate an agreed transmission rate for the BFD packets. BFD 277 supports an echo function to check the continuity, and verify the 278 reachability of the desired destination. BFD does not support 279 neither a discovery mechanism nor a traceroute capability for fault 280 localization, these must be provided by use of other mechanisms. The 281 BFD packets support authentication between the routers being checked. 283 BFD can be used in pro-active (asynchronous) and on-demand modes, as 284 defined in [MPLS-TP OAM Reqs], of operation. 286 [MPLS BFD] defines the use of BFD for P2P LSP end-points and is used 287 to verify data-plane continuity. It uses a simple hello protocol 288 which can be easily implemented in hardware. The end-points of the 289 LSP exchange hello packets at negotiated regular intervals and an 290 end-point is declared down when expected hello packets do not show 291 up. Failures in each direction can be monitored independently using 292 the same BFD session. The use of the BFD echo function and on-demand 293 activation are outside the scope of the MPLS BFD specification. 295 The BFD session mechanism requires an additional (external) mechanism 296 to bootstrap and bind the session to a particular LSP or FEC. LSP 297 Ping is designated by [MPLS BFD] as the bootstrap mechanism for the 298 BFD session in an MPLS environment. The implication is that the 299 session establishment BFD messages for MPLS are transmitted using a 300 IP/UDP encapsulation. 302 In order to be able to identify certain extreme cases of mis- 303 connectivity, it is necessary that each managed connection have its 304 own unique identifiers. BFD uses Discriminator values to identify 305 the connection being verified, at both ends of the path. These 306 discriminator values are set by each end-node to be unique only in 307 the context of that node. This limited scope of uniqueness would not 308 identify a misconnection of crossing paths that could assign the same 309 discriminators to the different sessions. 311 1.6. PW VCCV 313 [PW VCCV] provides end-to-end fault detection and diagnostics for PWs 314 (regardless of the underlying tunneling technology). The VCCV 315 switching function provides a control channel associated with each PW 316 (based on the PW Associated Channel Header (ACH) which is defined in 317 [PW ACH]), and allows sending OAM packets in-band with PW data (using 318 CC Type 1: In-band VCCV) 320 VCCV currently supports the following OAM mechanisms: ICMP Ping, LSP 321 Ping, and BFD. ICMP and LSP Ping are IP encapsulated before being 322 sent over the PW ACH. BFD for VCCV supports two modes of 323 encapsulation - either IP/UDP encapsulated (with IP/UDP header) or 324 PW-ACH encapsulated (with no IP/UDP header) and provides support to 325 signal the AC status. The use of the VCCV control channel provides 326 the context, based on the MPLS-PW label, required to bind and 327 bootstrap the BFD session to a particular pseudo wire (FEC), 328 eliminating the need to exchange Discriminator values. 330 VCCV consists of two components: (1) signaled component to 331 communicate VCCV capabilities as part of VC label, and (2) switching 332 component to cause the PW payload to be treated as a control packet. 334 VCCV is not directly dependent upon the presence of a control plane. 335 The VCCV capability negotiation may be performed as part of the PW 336 signaling when LDP is used. In case of manual configuration of the 337 PW, it is the responsibility of the operator to set consistent 338 options at both ends. 340 1.7. ITU Recommendation Y.1731 342 [Y.1731] specifies a set of OAM procedures and related packet data 343 unit (PDU) formats that meet the transport network requirements for 344 OAM. These PDU and procedures address similar requirements to those 345 outlined in [MPLS-TP OAM Reqs]. 347 The PDU and procedures defined in [Y.1731] are described for an 348 Ethernet environment, with the appropriate encapsulation for that 349 environment. However, the actual PDU formats are technology agnostic 350 and could be carried over different encapsulations, e.g. VCCV 351 control channel. The OAM procedures, likewise, could be supported by 352 MPLS-TP nodes just as they are supported by Ethernet nodes. 354 [Y.1731] describes procedures to support the following OAM functions: 356 o Connectivity and Continuity Monitoring - for pro-active mode end- 357 to-end checking 359 o Loopback functionality - to verify connectivity to intermediate 360 nodes in an on-demand mode 362 o Link Trace - provides information on the intermediate nodes of the 363 path being monitored, may be used for fault localization. This is 364 activated in an on-demand mode. 366 o Alarm Indication Signaling - for alarm suppression in case of 367 faults that are detected at the server layer, activated pro- 368 actively. 370 o Remote Defect Indication - as part of the Connectivity and 371 Continuity Monitoring packets, performed pro-actively 373 o Locked Signal - for alarm suppression in case of administrative 374 locking at the server layer. This function is performed pro- 375 actively. 377 o Performance monitoring - including measurement of packet delays 378 both uni and bi-directional (on-demand), measurement of the ratio 379 of lost packets (pro-active), the effective bandwidth that is 380 supported without packet loss, and throughput measurement. 382 The PDU defined in [Y.1731] includes various information elements 383 (fields) including information on the MEG-Level, etc. Addressing of 384 the PDU as defined in [Y.1731] is based on the MAC Address of the 385 nodes, which would need to be adjusted to support other addressing 386 schemes. The addressing information is carried in (TLV) fields that follow the actual PDU. In the LBM PDU the 388 MAC address is used to identify the MIP to which the message is 389 intended 391 1.8. Acronyms 393 This draft uses the following acronyms: 395 +---------+------------------------------------------------+ 396 | AC | Attachment Circuit | 397 | ACH | Associated Channel Header | 398 | BFD | Bidirectional Forwarding Detection | 399 | CC-V | Continuity Check and Connectivity Verification | 400 | FEC | Forwarding Equivalence Class | 401 | G-ACH | Generic Associated Channel Header | 402 | LDP | Label Distribution Protocol | 403 | LSP | Label Switched Path | 404 | MPLS-TP | Transport Profile for MPLS | 405 | OAM | Operations, Administration, and Maintenance | 406 | PDU | Packet Data Unit | 407 | PW | Pseudowire | 408 | RDI | Remote Defect Indication | 409 | SLA | Service Level Agreement | 410 | TLV | Type, Length, Value | 411 | TTL | Time-to-live | 412 | VCCV | Virtual Circuit Connectivity Verification | 413 +---------+------------------------------------------------+ 415 2. Architectural requirements and general principles of operation 417 [MPLS-TP OAM Reqs] defines a set of requirements on OAM architecture 418 and general principles of operations which are evaluated below: 420 o [MPLS-TP OAM Reqs] requires that OAM mechanisms in MPLS-TP are 421 independent of the transmission media and of the client service 422 being emulated by the PW. The existing tools comply with this 423 requirement. 425 o [MPLS-TP OAM Reqs] requires that the MPLS-TP OAM MUST be able to 426 support both an IP based and non-IP based environment. If the 427 network is IP based, i.e. IP routing and forwarding are 428 available, then the MPLS-TP OAM toolset MUST be able to operate by 429 relying on the IP routing and forwarding capabilities. All of the 430 existing MPLS tools (i.e. LSP Ping, VCCV Ping, MPLS BFD, and VCCV 431 BFD) can support this functionality. The Y.1731 toolset does not 432 specifically support this functionality, but rather relies on 433 underlying technologies for forwarding this could also be over IP, 434 e.g. by using a VCCV extension. Note that some of the MPLS-TP 435 tools such as Alarm Report are very transport oriented and may not 436 support IP functionality. 438 o [MPLS-TP OAM Reqs] requires that MPLS-TP OAM MUST be able to 439 operate without IP functionality and without relying on control 440 and/or management planes. It is required that OAM functionality 441 MUST NOT be dependent on IP routing and forwarding capabilities. 442 Except for the LSP Ping operation of verifying the data-plane vs. 443 the control-plane, the existing tools do not rely on control 444 and/or management plane, however the following should be observed 445 regarding the reliance on IP functionality: 447 * LSP Ping, VCCV Ping, and MPLS BFD makes use of IP header 448 (UDP/IP) and do not completely comply with the requirement. In 449 the on-demand mode, LSP Ping also may use IP forwarding to 450 reply back to the source router. This dependence on IP, has 451 further implications concerning the use of LSP Ping as the 452 bootstrap mechanism for BFD for MPLS. There are extensions to 453 LSP-Ping that are under discussion that allow LSP-Ping to 454 restrict replies to the backside of a bidirectional LSP. 456 * VCCV BFD supports the use of PW-ACH encapsulated BFD sessions 457 for PWs and can comply with the requirement. 459 * Y.1731 PDU are technology agnostic and thereby not dependent on 460 IP functionality. These PDU could be carried by VCCV or G-ACH 461 control channels. 463 o [MPLS-TP OAM Reqs] requires that OAM tools for fault management do 464 not rely on user traffic, and the existing MPLS OAM tools and 465 Y.1731 already comply with this requirement. 467 o It is also required that OAM packets and the user traffic are 468 congruent (i.e. OAM packets are transmitted in-band) and there is 469 a need to differentiate OAM packets from user-plane ones. 471 * For PWs, VCCV provides a control channel that can be associated 472 with each PW which allows sending OAM packets in band of PWs 473 and allow the receiving end-point to intercept, interpret, and 474 process them locally as OAM messages. VCCV defines different 475 VCCV Connectivity Verification Types for MPLS (like ICMP Ping, 476 LSP Ping and IP/UDP encapsulated BFD and PW-ACH encapsulated 477 BFD). 479 * Currently there is no distinct OAM payload identifier in MPLS 480 shim. BFD and LSP Ping packets for LSPs are carried over 481 UDP/IP and are addressed to the loopback address range. The 482 router at the end-point intercepts, interprets, and processes 483 the packets. [MPLS G-ACH] generalizes the use of the PW ACH 484 and enables provision of control channels at the MPLS LSP and 485 sections levels. This new mechanism would support carrying the 486 existing MPLS OAM messages or the Y.1731 messages at the LSP 487 and the section levels to be transmitted over the G-ACH. 489 o [MPLS-TP OAM Reqs] requires that the MPLS-TP OAM mechanism allows 490 the propagation of AC (Attachment Circuit) failures and their 491 clearance across a MPLS-TP domain 493 * BFD for VCCV supports a mechanism for "Fault detection and 494 AC/PW Fault status signaling." This can be used for both IP/ 495 UDP encapsulated or PW-ACH encapsulated BFD sessions, i.e. by 496 setting the appropriate VCCV Connectivity Verification 497 Type.This mechanism could support this requirement. Note that 498 in the PWE3 WG there are two proposals regarding how to 499 transmit the AC failures over an ACH that may be applicable to 500 this requirement. 502 o [MPLS-TP OAM Reqs] requires a single OAM technology and consistent 503 OAM capabilities for LSPs, PWs, and Sections. The existing set of 504 tools defines a different way of operating the OAM functions (e.g. 505 LSP Ping to bootstrap MPLS BFD vs. VCCV). Currently, the Y.1731 506 functionality is defined for Ethernet paths, and the procedures 507 could readily be redefined for the various MPLS-TP path concepts. 509 o [MPLS-TP OAM Reqs] requires allowing OAM packets to be directed to 510 an intermediate point of a LSP/PW. Technically, this could be 511 supported by the proper setting of the TTL value. It is also 512 recommended to include the identifier of the intermediate point 513 within the OAM message to allow the intermediate point to validate 514 that the message is really intended for it. The information can 515 be included in an ACH-TLV according to the definitions in [MPLS-TP 516 ACH TLV]. The applicability of such a solution needs to be 517 examined per OAM function. For details, see below. 519 o [MPLS-TP OAM Reqs] suggests that OAM messages MAY be 520 authenticated. BFD defines support for optional authentication 521 fields using different authentication methods as defined in [BASE 522 BFD]. Other tools should support this capability as well. Y.1731 523 functionality uses the identification of the path for 524 authentication. Authentication information could be included in 525 an optional TLV field according to the definitions in [MPLS-TP ACH 526 TLV] when not available in the OAM PDU. 528 2.1. Architectural and Principles of Operation - Recommendations and 529 Guidelines 531 Based on the requirements analysis above, the following guidelines 532 should be followed to create an OAM environment that could more fully 533 support the requirements cited: 535 o Define a generalized addressing scheme that can also support 536 unique identification of the monitored paths (or connections). 538 o Use G-ACH for LSP and section levels. 540 o Define architectural element that is based on LSP hierarchy to 541 apply the mechanisms to segments and concatenated segments. 543 o Apply BFD to these new mechanisms using the control channel 544 encapsulation, as defined above - allowing use of BFD for MPLS-TP 545 independent of IP functionality. This could be used to address 546 the CC-V functionality, described below. 548 o Similarly, LSP Ping could be extended to use only the LSP path (in 549 both directions) without IP Forwarding. Addressing for PW can be 550 included by using the VCCV mechanism. LSP Ping could be used to 551 address the CC-V, Route Tracing, RDI, and Lock/Alarm Reporting 552 functionality cited in the requirements. 554 o The Y.1731 PDU set could be used as a basis for defining the 555 information units to be transmitted over the G-ACH. The actual 556 procedures and addressing schemes would need to be adjusted for 557 the MPLS-TP environment. 559 o Define a mechanism that could be used to idnetify an intermediate 560 point of a path in a unique way, to support the maintenance 561 functions. This addressing should be flexible to allow support 562 for different addressing schemes, and would supplement the TTL 563 exception mechanism to allow an OAM packet to be intercepted by 564 intermediate nodes. 566 Creating these extensions/mechanisms would fulfill the following 567 architectural requirements, mentioned above: 569 o Independence of IP forwarding and routing, when needed. 571 o OAM packets should be transmitted in-band. 573 o Support a single OAM technology for LSP, PW, and Sections. 575 In addition, the following additional requirements can be satisfied: 577 o Provide the ability to carry other types of communications (e.g., 578 APS, Management Control Channel (MCC), Signaling Control Channel 579 (SCC)), by defining new types of communication channels for PWs, 580 Sections, and LSPs. 582 o The design of the OAM mechanisms for MPLS-TP MUST allow the 583 ability to support vendor specific and experimental OAM functions. 585 3. MPLS-TP OAM Functions 587 The following sections discuss the required OAM functions that were 588 identified in [MPLS-TP OAM Reqs]. 590 3.1. Continuity Check and Connectivity Verification 592 Continuity Check and Connectivity Verification (CC-V) are OAM 593 operations generally used in tandem, and compliment each other. 594 These functions may be split into separate mechanisms. Together they 595 are used to detect loss of traffic continuity and misconnections 596 between path end-points and are useful for applications like Fault 597 Management, Performance Monitoring and Protection Switching, etc. To 598 guarantee that CC-V can identify misconnections from cross- 599 connections it is necessary that the tool use network-wide unique 600 identifiers for the path that is being checked in the session. 602 3.1.1. Existing tools 604 LSP Ping provides much of the functionality required for co-routed 605 bidirectional LSPs. As observed above, LSP Ping may be operated in 606 both asynchronous and on-demand mode. Addressing is based on the 607 full FEC identification that provides a unique identifier, and the 608 basic functionality only requires support for the loopback address 609 range in each node on the LSP path. 611 BFD defines functionality that can be used to support the pro-active 612 OAM CC-V function when operated in the asynchronous mode. However, 613 the current definition of basic BFD is dependent on use of LSP Ping 614 to bootstrap the BFD session. Regarding the connectivity functional 615 aspects, basic BFD has a limitation that it uses only locally unique 616 (to each node) session identifiers. 618 VCCV can be used to carry either LSP Ping or BFD packets that are not 619 IP/UDP encapsulated for CC-V on a PW. Note that PW termination/ 620 switching points use only locally unique (to each node) labels. The 621 PW label identifies the path uniquely only at the LSP level. 623 Y.1731 provides functionality for all aspects of CC-V for an Ethernet 624 environment, this could be translated for the MPLS-TP environment. 625 The CCM PDU defined in [Y.1731] includes the ability to set the 626 frequency of the messages that are transmitted, and provides for 627 attaching the address of the path (in the Ethernet case - the MEG 628 Level) and a sequencing number to verify that CCM messages were not 629 dropped. 631 3.1.2. Gap analysis 633 LSP Ping could be used to cover the cases of co-routed bidirectional 634 LSPs. However, there is a certain amount of computational overhead 635 involved with use of LSP Ping (as was observed in sec 1.1), the 636 verification of the control-plane, and the need to support the 637 loopback functionality at each intermediate node. LSP Ping uses a 638 fully qualified LSP identifier, and when used in conjunction with 639 VCCV would use the PW label to identify the transport path. LSP Ping 640 can be extended to bypass the verification of the control plane 642 BFD could be extended to fill the gaps indicated above. The 643 extension would include: 645 o A mechanism should be defined to carry BFD packets over LSP 646 without reliance on IP functionality. 648 o A mechanism should be defined to bootstrap BFD sessions for MPLS 649 that is not dependent on UDP. 651 o BFD needs to be used in conjunction with "globally" unique 652 identifiers for the path or ME being checked to allow connectivity 653 verfication support. There are two possibilities, to allow BFD to 654 support this new type of identifier - 656 * Change the semantics of the two Discriminator fields that exist 657 in BFD and have each node select the ME unique identifier. 658 This may have backward compatibility implications. 660 * Create a new optional field in the packet carrying the BFD that 661 would identify the path being checked, in addition to the 662 existing session identifiers. 664 o Extensions to BFD would be needed to cover P2MP connections. 666 Use of the Y.1731 functionality is another option that could be 667 considered. The basic PDU for CCM includes (in the flags field) an 668 indication of the frequency of the packets [eliminating the need to 669 "negotiate" the frequency between the end-points], and also a flag 670 used for RDI. The procedure itself would need adaptation to comply 671 with the MPLS environment. 673 An additional option would be to create a new tool that would give 674 coverage for both aspects of CC-V according to the requirements and 675 the principles of operation (see section 2.1). This option is less 676 preferable. 678 3.1.3. Recommendations and Guidelines 680 Extend LSP Ping to fully support the on-demand Connectivity 681 Verification function resolving the gaps described above. Extend BFD 682 to support proactive Continuity Check & Connectivity Verification 683 (CC-V) resolving the gaps described above. 685 Note that [MPLS BFD] defines a method for using BFD to provide 686 verification of multipoint or multicast connectivity. 688 3.2. Alarm Reporting 690 Alarm Reporting is a function that is used by an intermediate point 691 in a path to notify the end-points of the path of a fault or defect 692 condition indirectly affecting that path. Such information may be 693 used by the endpoints, for example, to suppress alarms that may be 694 generated by maintenance end-points of the path. This function 695 should also have the capability to differentiate an administrative 696 lock from a failure condition at a different execution level. 698 3.2.1. Existing tools 700 There is no mechanism defined in the IETF to support this function. 701 Y.1731 does define a PDU and procedure for this functionality. 703 3.2.2. Recommendations and Guidelines 705 Define a new tool and PDU to support Alarm Reporting. The PDU should 706 be transmitted over a G-ACH. The frequency of transmision after the 707 alarm is raised and the continued frequency until it is cleared 708 should be indicated in the definition. 710 Describe also how the Alarm Reporting functionality may be supported 711 in the control-plane and management-plane. 713 3.3. Diagnostic 715 A diagnostic test is a function that is used between path end-points 716 to verify bandwidth throughput, packet loss, bit errors, etc. This 717 is usually performed by sending packets of varying sizes at 718 increasing rates (until the limits of the service level) to measure 719 the actual utilization. 721 3.3.1. Existing tools 723 There is no mechanism defined in the IETF to support this function. 724 [Y.1731] describes a function that is dependent on sending a series 725 of TST packets (this is a PDU whose size can be varied) at differing 726 frequencies. 728 3.3.2. Recommendations and Guidelines 730 Define a new tool and PDU to support Diagnostic. 732 3.4. Route Tracing 734 Functionality of route determination is used to determine the route 735 of a connection across the MPLS transport network. [MPLS-TP OAM 736 Reqs] defines that this functionality MUST allow a path end-point to 737 identify the intermediate and end-points of the path. This 738 functionality MUST support co-routed bidirectional paths, and MAY 739 support associated bidirectional and unidirectional p2p paths, as 740 well as p2mp unidirectional paths. Unidirectional path support is 741 dependent on the existence of a return path to allow the original 742 end-point to receive the trace information. 744 3.4.1. Existing tools 746 LSP Ping supports a trace route function that could be used for 747 bidirectional paths. Support of unidirectional paths would be 748 dependent on the ability of identifying a return path. 750 3.4.2. Recommendations and Guidelines 752 Extend LSP Ping to support the Route Trace functionality and to 753 address additional options, i.e. PW and p2mp unidirectional LSP. 755 3.5. Lock Instruct 757 The Lock instruct function allows the system to block off 758 transmission of data along a LSP. When a path end-point receives a 759 command, e.g. from the management system, that the path is blocked, 760 the end-point informs the far-end that the path has been locked and 761 that no data should be transmitted. This function is used on-demand. 763 3.5.1. Existing tools 765 There is no mechanism defined in the IETF to support this function, 766 but LSP Ping could be extended to support this functionality between 767 the path endpoints. Y.1731 does define a PDU and procedure for this 768 functionality. 770 3.5.2. Recommendations and Guidelines 772 Extend LSP Ping to support Lock instruct. The frequency at which 773 these messages are transmitted until the lock situation is cleared, 774 should be clearly indicated. 776 3.6. Lock Reporting 778 Lock reporting is used by an intermediate point to notify the end 779 points of a transport path (that the intermediate point is a member 780 of) that an external lock condition exits for this transport path. 781 This function is used proactively. 783 3.6.1. Existing tools 785 There is no mechanism defined in neither the IETF nor in Y.1731 to 786 support this function. 788 3.6.2. Recommendations and Guidelines 790 Define a new tool and PDU to support Lock reporting. This tool could 791 be designed similarly to the Alarm Reporting tool (described above), 792 but would need to be initiated by an intermediate point of the 793 transport path. 795 3.7. Remote Defect Indication 797 Remote Defect Indication (RDI) is used by a path end-point to notify 798 its peer end-point that a defect, usually a unidirectional defect, is 799 detected on a bi-directional connection between them. 801 This function should be supported in pro-active mode. 803 3.7.1. Existing tools 805 There is no mechanism defined in the IETF to fully support this 806 functionality, however BFD supports a mechanism of informing the far- 807 end that the session has gone down, and the Diagnostic field 808 indicates the reason. Similarly, when LSP Ping is used for a co- 809 routed bidirectional LSP the far-end LER could notify that there was 810 a misconnectivity. 812 In [Y.1731] this functionality is defined as part of the CC-V 813 function as a flag in the PDU. 815 3.7.2. Recommendations and Guidelines 817 Extend BFD (which is recommended to be used for proactive CC-V) to 818 transmit the signal of Remote Defect Indication without disrupting 819 the CC-V functionality. Such an extension could be similar to that 820 suggested by the ITU recommendation. 822 3.8. Client Failure Indication 824 Client Failure Indication (CFI) function is used to propagate an 825 indication of a failure to the far-end sink when alarm suppression in 826 the client layer is not supported. 828 3.8.1. Existing tools 830 There is a possibility of using the BFD over VCCV mechanism for 831 "Fault detection and AC/PW Fault status signaling". However, there 832 is a need to differentiate between faults on the AC and the PW. In 833 the PWE3 WG there are some proposals regarding how to transmit the 834 CFI over an ACH. 836 3.8.2. Recommendations and Guidelines 838 Use PWE3 tool to propagate Client Fail Indication via an ACH. 840 3.9. Packet Loss Measurement 842 Packet Loss Measurement is a function that is used to verify the 843 quality of the service. This function indicates the ratio of packets 844 that are not delivered out of all packets that are transmitted by the 845 path source. 847 There are two possible ways of determining this measurement - 849 o Using OAM packets, it is possible to compute the statistics based 850 on a series of OAM packets. This, however, has the disadvantage 851 of being artificial, and may not be representative since part of 852 the packet loss may be dependent upon packet sizes. 854 o Sending delimiting messages for the start and end of a measurement 855 period during which the source and sink of the path count the 856 packets transmitted and received. After the end delimiter, the 857 ratio would be calculated by the path OAM entity. 859 3.9.1. Existing tools 861 There is no mechanism defined in the IETF to support this function. 862 [Y.1731] describes a function that is based on sending the CCM 863 packets [used for CC-V support (see sec 3.1)] for proactive support 864 and specialized loss-measurement packets for on-demand measurement. 865 These packets include information (in the additional TLV fields) of 866 packet counters that are maintained by each of the end-points of a 867 path. These counters maintain a count of packets transmitted by the 868 ingress end-point and the count of packets received from the far-end 869 of the path by the egress end-point. 871 3.9.2. Recommendations and Guidelines 873 One possibility is to define a mechanism to support Packet Loss 874 Measurement, based on the delimiting messages. This would include a 875 way for delimiting the periods for monitoring the packet 876 transmissions to measure the loss ratios, and computation of the 877 ratio between received and transmitted packets. 879 A second possibility would be to define a functionality based on the 880 description of the loss-measurement function defined in [Y.1731] that 881 is dependent on the counters maintained, by the MPLS LSR (as 882 described in [RFC3813], of received and transmitted octets. Define a 883 new PDU for the message that utilizes G-ACH. This option appears 884 more suitable for performance monitoring statistics, which in 885 transport applications are based on the continuous monitoring of the 886 traffic interested (100 ms gating). 888 3.10. Packet Delay Measurement 890 Packet Delay Measurement is a function that is used to measure one- 891 way or two-way delay of a packet transmission between a pair of the 892 end-points of a path (PW, LSP, or Section). Where: 894 o One-way packet delay is the time elapsed from the start of 895 transmission of the first bit of the packet by a source node until 896 the reception of the last bit of that packet by the destination 897 node. 899 o Two-way packet delay is the time elapsed from the start of 900 transmission of the first bit of the packet by a source node until 901 the reception of the last bit of the loop-backed packet by the 902 same source node, when the loopback is performed at the packet's 903 destination node. 905 Similarly to the packet loss measurement this could be performed in 906 one of two ways - 908 o Using OAM packets - checking delay (either one-way or two-way) in 909 transmission of OAM packets. May not fully reflect delay of 910 larger packets, however, gives feedback on general service level. 912 o Using delimited periods of transmission - may be too intrusive on 913 the client traffic. 915 3.10.1. Existing tools 917 There is no mechanism defined in the IETF toolset that fulfills all 918 of the MPLS-TP OAM requirements. 920 [Y.1731] describes a function in which specific OAM packets are sent 921 with a transmission time-stamp from one end of the managed path to 922 the other end (these are transparent to the intermediate nodes). The 923 delay measurement is supported for both one-way and two-way 924 measurement of the delay. It should be noted that the functionality 925 on the one-way delay measurement is dependent upon a certain degree 926 of synchronization between the time clocks of the two-ends of the 927 transport path. 929 3.10.2. Recommendations and Guidelines 931 Define a mechanism that would support Packe Delay Measurement, based 932 on the procedures defined in [Y.1731]. The mechanism should be based 933 on measurement of the delay in transmission and reception of OAM 934 packets, transmitted in-band with normal traffic. Define an 935 appropriate PDU that would utilize the G-ACH. 937 4. Recommendations 939 As indicated above, LSP-Ping could easily be extended to support some 940 of the functionality between the path end-points and between an end- 941 point of a path and an intermediate point. BFD could also be 942 extended to support some of the functions between the end-points of a 943 path. Some of the OAM functions defined in [Y.1731] (especially for 944 performance monitoring) could also be adapted. 946 The guidelines that are used in this document are as follows: 948 o Re-use/extend existing IETF protocols wherever applicable. 950 o Define new message format for each of the rest of the OAM 951 functions, which are aligned with the ACH and ACH-TLV definitions, 952 and includes only relevant information. 954 o Adapt Y.1731 functionality where applicable (mainly for 955 performance monitoring). 957 The recommendations on the MPLS-TP OAM tools are as follows: 959 o Define a maintenance entity that could be applied both to LSPs and 960 PWs that would support management of a sub-path. This entity 961 should allow for transmission of traffic by means of label 962 stacking and proper TTL setting. 964 o Extend the control and the management planes to support the 965 configuration of the OAM maintenance entities and the set of 966 functions to be supported by these entities. 968 o Define a mechanism that would allow the unique addressing of the 969 elements that need to be monitored, e.g., the connections, end- 970 points, and intermediate points of a path. This mechanism needs 971 to be flexible enough to support different addressing schemes, 972 e.g. IP addresses, NSAP, connection names. As pointed out above, 973 LSP Ping uses the full FEC identifier for the LSP - this could 974 easily be applied to Section OAM since this would be considered as 975 a stacked LSP. 977 o The appropriate assignment of network-wide unique identifiers for 978 transport paths, needed to support connectivity verification, 979 should be considered. 981 o Extend existing MPLS tools to disengage from IP forwarding 982 mechanisms. 984 o Extend BFD to support the proactive CC-V functionalities. The 985 extensions should address the gaps described above. 987 o Extend LSP Ping to support the on-demand Connectivity Verification 988 functionality. The extensions should address the gaps described 989 above. 991 o Define a new PDU which will be transmitted over G-ACH to support 992 the Alarm Reporting functionality for data-plane implementations. 993 Describe how Alarm Reporting can be supported by a control-plane 994 and by a management-plane. 996 o Define a new PDU which will be transmitted over G-ACH to support 997 the Lock Reporting functionality. Use the same procedures as for 998 Alarm Reporting. 1000 o Extend BFD to support the Remote Defect Indication (RDI) 1001 functionality. The extensions should address the gaps described 1002 above. 1004 o Extend LSP-Ping to support the Route tracing functionality. The 1005 extensions should address the gaps described above. 1007 o Extend LSP-Ping to support the Lock Instruct functionality between 1008 end-points of a path. The extensions should address the gaps 1009 described above. 1011 o Use PWE3 tool to transmit Client Fault Indication (CFI) via ACH. 1012 There are already some proposals in the PWE3 WG. 1014 o Define a new PDU which will be transmitted over G-ACH to support 1015 the Packet Loss Measurement functionality. Base the functionality 1016 on the procedures defined in Y.1731. 1018 o Define a new PDU which be transmitted over G-ACH to support the 1019 Packet Delay Measurement functionality. Base the functionality on 1020 the procedures defined in Y.1731. For one-way delay measurement 1021 define mechanisms to ensure a certain degree of synchronization 1022 between the time clocks of the two-ends of the transport path. 1024 o Define a new PDU which be transmitted over G-ACH to support the 1025 Diagnostic functionality. 1027 o The tools may have the capability to authenticate the messages. 1028 The information may be carried in a G-ACH TLV. 1030 5. MPLS-TP OAM Documents Organization 1032 The following paragraphs list the set of documents necessary to cover 1033 the OAM functionalities analyzed above. This compilation of 1034 documents is one of the outcomes of the MEAD team discussions that 1035 took place during IETF75 in Stockholm. 1037 It should be noted that the various document titles listed here may 1038 not reflect the draft titles that will be chosen at the time that the 1039 drafts are written, but they serve just as a topic pointer from the 1040 current analysis. 1042 5.1. Document 1: "Encapsulation of BFD and LspPing in ACH" 1044 The scope of the document is to define the usage of LSP Ping and BFD 1045 in both IP and IP-less environments. As described in the following 1046 paragraphs, BFD and Lsp Ping need to be extended in order to be 1047 compliant with [MPLS-TP OAM Reqs]. However, this document should be 1048 focused on the existing Lsp Ping and BFD, without necessarily 1049 referring to their extended versions. 1051 The draft "nitinb-mpls-tp-lsp-ping-bfd-procedures" will be considered 1052 as the starting point for this definition. 1054 In particular, the following sections will be taken into account for 1055 the scope: 1057 o nitinb-mpls-tp-lsp-ping-bfd-procedures section 2 ("LSP-Ping 1058 extensions") for addressing the "Lsp Ping encapsulation in ACH" 1060 o nitinb-mpls-tp-lsp-ping-bfd-procedures section 5 ("Running BFD 1061 over MPLS-TP LSPs") for addressing the "BFD encapsulation in ACH" 1063 5.2. Document 2: "Extended BFD" 1065 The scope of the document is to define the BFD extension and behavior 1066 to meet the requirements for MPLS-TP proactive Continuity Check and 1067 Connectivity Verification functionality and the RDI functionality as 1068 defined in [MPLS-TP OAM Reqs]. 1070 The document will likely take the name 1071 "draft-asm-mpls-tp-bfd-cc-cv-00" and will be formed by the merging of 1072 the following two drafts: 1074 o draft-fulignoli-mpls-tp-bfd-cv-proactive-and-rd 1076 o draft-boutros-mpls-tp-cc-cv-01.txt 1078 5.3. Document 3: "Extended LSP Ping" 1080 The scope of the document is to define: 1082 o A place holder for On Demand Connectivity Verification if LSP Ping 1083 needs to be enhanced over and above the encapsulations changes 1084 (defined in Document 1 "Encapsulation of BFD and LSP Ping in 1085 ACH"). 1087 o Usage of LSP Ping with MIPs and MEPs, which is partially covered 1088 in nitinb-mpls-tp-lsp-ping-bfd-procedures. 1090 o Route Trace. This topic has already been partially covered in 1091 "draft-boutros-mpls-tp-path-trace-00" and "nitinb-mpls-tp-lsp- 1092 ping-bfd-procedures", which will be considered as starting point 1093 for the Route Trace functionality included in Document 3. The 1094 Route Trace section should also cover these aspects: 1096 * LSP Ping Loose ends. This section will describe what to do 1097 when receiving an LSP Ping with MIP and MEP ids. 1099 * In an IP-Less environment Route Trace works only in co-routed 1100 bidirectional LSP. 1102 * In Y.1731 the CV function is separate from the Route Trace 1103 function, it should be captured how LSP Ping works for Route 1104 Trace using TTL. 1106 5.4. Document 4: "Extensions for Lock Instruct" 1108 A new document describing the LSP Ping extensions to accomplish the 1109 Lock Instruct desired behavior is needed. Some material useful for 1110 this scope can be found in "draft-boutros-mpls-tp-loopback-02". 1112 5.5. Document 5: "AIS and Lock Reporting" 1114 A new document is need for the definition of the AIS and Lock 1115 Reporting, however the document definition has been temporarily 1116 deferred by the MEAD team. Therefore this paragraph will be updated 1117 in future versions. 1119 5.6. Document 6: "Client Fault Indication" 1121 A new document describing Client Fault Indication procedure needs to 1122 be defined. 1124 The following two drafts indicating a client fault indication 1125 transported across MPLS-TP network will be compared and merged in the 1126 new document: 1128 o "draft-he-mpls-tp-csf", which describes a tool to propagate a 1129 client failure indication across an MPLS-TP network in case the 1130 propagation of failure status in the client layer is not 1131 supported. 1133 o "draft-martini-pwe3-static-pw-status", which describes the usage 1134 of PW associated channel to signal PW status messages in case a 1135 static PW is used without a control plane 1137 It is worth noting that a Client Failure Indication is used if the 1138 client does not support its own OAM (IP and MPLS as clients use their 1139 own). It has been also agreed that CFI is used on PW and not on 1140 client directly mapped on LSP MPLS-TP. 1142 5.7. Document 7: "Packet Loss" 1144 A new document needs to be defined in order to describe a stand alone 1145 tool for Packet Loss measurements that can work both proactively and 1146 on demand. The tool will be functionally based on Y.1731. 1148 5.8. Document 8: "Packet Delay" 1150 A new document needs to be defined about the Packet Delay measurement 1151 which will be based on Y.1731 from the functionality point of view. 1152 Moreover, [MPLS-TP OAM Frwk] needs to be updated in order to clarify 1153 the functionality behavior expected from this tool. 1155 5.9. Document 9: "Diagnostic Tests" 1157 One or more new documents are needed for the tools definition for 1158 Diagnostic Tests. However, the documents definition has been 1159 temporarily deferred by the MEAD team until a clearer definition of 1160 "diagnostic test" in [MPLS-TP OAM Reqs]. 1162 6. IANA Considerations 1164 This document makes no request of IANA. 1166 Note to RFC Editor: this section may be removed on publication as an 1167 RFC. 1169 7. Security Considerations 1171 This document does not by itself raise any particular security 1172 considerations. 1174 8. Acknowledgements 1176 The authors wish to thank the MEAD team for their review and proposed 1177 enhancements to the text. 1179 9. Informative References 1181 [RFC 2119] 1182 Bradner, S., "Internet Control Message Protocol", BCP 14, 1183 RFC 2119, March 1997. 1185 [ICMP] Postel, J., "Internet Control Message Protocol", STD 5, 1186 RFC 792, Sept 1981. 1188 [LSP Ping] 1189 Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1190 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1191 February 2006. 1193 [PW ACH] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1194 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1195 Use over an MPLS PSN", RFC 4385, February 2006. 1197 [PW VCCV] Nadeau, T. and C. Pignataro, "Pseudowire Virtual Circuit 1198 Connectivity Verification (VCCV): A Control Channel for 1199 Pseudowires", RFC 5085, December 2007. 1201 [BASE BFD] 1202 Katz, D. and D. Ward, "Bidirectional Forwarding 1203 Detection", ID draft-ietf-bfd-base-09.txt, February 2009. 1205 [MPLS BFD] 1206 Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 1207 "BFD For MPLS LSPs", ID draft-ietf-bfd-mpls-07.txt, 1208 June 2008. 1210 [VCCV BFD] 1211 Nadeau, T. and C. Pignataro, "Bidirectional Forwarding 1212 Detection (BFD) for the Pseudowire Virtual Circuit 1213 Connectivity Verification (VCCV)", 1214 ID draft-ietf-pwe3-vccv-bfd-07.txt, February 2008. 1216 [P2MP LSP Ping] 1217 Nadeau, T. and A. Farrel, "Detecting Data Plane Failures 1218 in Point-to-Multipoint Multiprotocol Label Switching 1219 (MPLS) - Extensions to LSP Ping", 1220 ID draft-ietf-mpls-p2mp-lsp-ping-06.txt, June 2008. 1222 [MPLS LSP Ping] 1223 Bahadur, N. and K. Kompella, "Mechanism for performing 1224 LSP-Ping over MPLS tunnels", 1225 ID draft-ietf-mpls-lsp-ping-enhanced-dsmap-00, June 2008. 1227 [MPLS-TP OAM Reqs] 1228 Vigoureux, M., Betts, M., and D. Ward, "Requirements for 1229 OAM in MPLS Transport Networks", 1230 ID draft-ietf-mpls-tp-oam-requirements-01, April 2009. 1232 [MPLS-TP OAM Frwk] 1233 Busi, I. and B. Niven-Jenkins, "MPLS-TP OAM Framework and 1234 Overview", ID draft-ietf-mpls-tp-oam-requirements-01, 1235 March 2009. 1237 [MPLS-TP Reqs] 1238 Niven-Jenkins, B., Nadeau, T., and C. Pignataro, 1239 "Requirements for the Trasport Profile of MPLS", 1240 ID draft-ietf-mpls-tp-requirements-06, April 2009. 1242 [MPLS G-ACH] 1243 Bocci, M., Bryant, S., and M. Vigoureux, "MPLS Generic 1244 Associated Channel", RFC 5586, June 2009. 1246 [MPLS-TP ACH TLV] 1247 Boutros, S., Bryant, S., Sivabalan, S., Swallow, G., and 1248 D. Ward, "Definition of ACH TLV Structure", 1249 ID draft-ietf-mpls-tp-ach-tlv-00, June 2009. 1251 [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, 1252 "Multiprotocol Label Switching (MPLS) Label Switching 1253 Router (LSR) Management Information Base (MIB)", 1254 RFC 3813, June 2004. 1256 [Y.1731] International Telecommunications Union - Standardization, 1257 "OAM functions and mechanisms for Ethernet based 1258 networks", ITU Y.1731, May 2006. 1260 Authors' Addresses 1262 Nurit Sprecher (editor) 1263 Nokia Siemens Networks 1264 3 Hanagar St. Neve Ne'eman B 1265 Hod Hasharon, 45241 1266 Israel 1268 Email: nurit.sprecher@nsn.com 1269 Huub van Helvoort (editor) 1270 Huawei 1271 Kolkgriend 38, 1356 BC Almere 1272 Netherlands 1274 Phone: +31 36 5316076 1275 Email: hhelvoort@huawei.com 1277 Elisa Bellagamba 1278 Ericsson 1279 6 Farogatan St 1280 Stockholm, 164 40 1281 Sweden 1283 Phone: +46 761440785 1284 Email: elisa.bellagamba@ericsson.com 1286 Yaacov Weingarten 1287 Nokia Siemens Networks 1288 3 Hanagar St. Neve Ne'eman B 1289 Hod Hasharon, 45241 1290 Israel 1292 Phone: +972-9-775 1827 1293 Email: yaacov.weingarten@nsn.com