idnits 2.17.1 draft-ietf-mpls-tp-oam-analysis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, 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 (January 2, 2011) is 4862 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-ietf-mpls-tp-cc-cv-rdi-00 == Outdated reference: A later version (-07) exists of draft-ietf-mpls-tp-on-demand-cv-00 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-tp-li-lb-00 == Outdated reference: A later version (-03) exists of draft-he-mpls-tp-csf-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Sprecher 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational E. Bellagamba 5 Expires: July 6, 2011 Ericsson 6 Y. Weingarten 7 Nokia Siemens Networks 8 January 2, 2011 10 OAM functions in MPLS based transport network 11 draft-ietf-mpls-tp-oam-analysis-03.txt 13 Abstract 15 This document describes the outcome of the discussions on the 16 necessary OAM functionality for the first release of MPLS based 17 transport networks. The discussion is based on the set of 18 requirements for Operations, Administration, and Maintenance (OAM) 19 for MPLS based transport networks as defined in [MPLS-TP OAM Reqs]. 20 An important aspect was to evaluate whether existing OAM tools from 21 the current MPLS protocol suite can be used to fulfill these 22 requirements. Eventually, the purpose of the document is to map the 23 set of functions to a set of tools based on the existing OAM tool- 24 set. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 6, 2011. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.2. Organization of the document . . . . . . . . . . . . . . . 5 75 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 5 76 1.4. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 2. Basic OAM infrastructure functionality . . . . . . . . . . . . 5 78 3. MPLS-TP OAM Functions . . . . . . . . . . . . . . . . . . . . 7 79 3.1. Continuity Check and Connectivity Verification . . . . . . 7 80 3.1.1. Documents for CC-V tools . . . . . . . . . . . . . . . 7 81 3.2. Remote Defect Indication . . . . . . . . . . . . . . . . . 7 82 3.2.1. Documents for RDI . . . . . . . . . . . . . . . . . . 8 83 3.3. Route Tracing . . . . . . . . . . . . . . . . . . . . . . 8 84 3.3.1. Documents for Route Tracing . . . . . . . . . . . . . 8 85 3.4. Alarm Reporting . . . . . . . . . . . . . . . . . . . . . 8 86 3.4.1. Documents for Alarm Reporting . . . . . . . . . . . . 8 87 3.5. Lock Reporting . . . . . . . . . . . . . . . . . . . . . . 8 88 3.5.1. Documents for Lock Reporting . . . . . . . . . . . . . 8 89 3.6. Lock Instruct . . . . . . . . . . . . . . . . . . . . . . 9 90 3.6.1. Documents for Lock Instruct . . . . . . . . . . . . . 9 91 3.7. Client Failure Indication . . . . . . . . . . . . . . . . 9 92 3.7.1. Documents for CFI . . . . . . . . . . . . . . . . . . 9 93 3.8. Packet Loss Measurement . . . . . . . . . . . . . . . . . 9 94 3.8.1. Documents for Packet Loss Measurement . . . . . . . . 9 95 3.9. Packet Delay Measurement . . . . . . . . . . . . . . . . . 10 96 3.9.1. Documents for Delay Measurement . . . . . . . . . . . 10 97 4. MPLS-TP OAM documents guide . . . . . . . . . . . . . . . . . 10 98 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 100 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 101 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 104 1. Introduction 106 1.1. Scope 108 OAM (Operations, Administration, and Maintenance) plays a significant 109 role in carrier networks, providing methods for fault management and 110 performance monitoring in both the transport and the service layers 111 in order to improve their ability to support services with guaranteed 112 and strict Service Level Agreements (SLAs) while reducing their 113 operational costs. 115 [MPLS-TP Reqs] in general, and [MPLS-TP OAM Reqs] in particular 116 define a set of requirements for OAM functionality in MPLS-Transport 117 Profile (MPLS-TP) for MPLS-TP Segments, Label Switched Paths (LSPs) 118 (network infrastructure) and Pseudowires (PWs) (services). 120 The OAM solution developed by the joint IETF and ITU-T MPLS-TP 121 project has three objectives: 123 o The OAM tool-set should be developed based on existing MPLS 124 architecture, technology, and tool-sets. 126 o It should be verified that the OAM tool-set for MPLS transport 127 networks should be aligned with the comparable tool-set in legacy 128 transport networks as much as possible. 130 o The OAM tool-set developed for MPLS based transport networks needs 131 to be fully inter-operable with existing MPLS OAM tools as 132 documented in [MPLS-TP OAM Reqs]. 134 The discussion on the needed OAM tool-set took place, mainly, in the 135 MPLS Interoperability Design Team (the MEAD). A tool-set was agreed 136 upon and was reported to the MPLS working group in Stockholm (July 137 2009) during the IETF meetings. This was also judged to be the 138 working group consensus. 140 This document outlines these recommendations for the tool-set that 141 should be defined to fulfill the OAM functionality requirements as 142 documented in [MPLS-TP OAM Reqs] and [MPLS-TP OAM Frwk]. Based on 143 the objectives cited above, it was determined to base the MPLS-TP OAM 144 tool-set on the following existing MPLS tools: 146 o LSP-Ping as defined in [LSP Ping]. 148 o Bidirectional Forwarding Detection (BFD) as defined in [BASE BFD] 149 and refined in [MPLS BFD]. 151 o ITU-T OAM for Ethernet tool-set as defined in [Y.1731] this will 152 be used for functionality guidelines for the performance 153 measurement tools that are not currently supported in MPLS. 155 It should be noted that certain extensions and adjustments may be 156 made to the existing MPLS tools, in order to conform to the transport 157 environment and the requirements of MPLS based transport networks. 159 1.2. Organization of the document 161 Section 2 of the document reviews the requirements for MPLS-TP OAM 162 and shows how they are addressed by the top-level architectural RFCs 164 Section 3 outlines the different functional tools that are required 165 for MPLS-TP OAM and references the documents that define the 166 appropriate tools based on the principles outlined above. 168 Section 4 provides the user with a cross-reference, pointing out 169 which tools are addressed by each of the OAM solutions RFCs. 171 1.3. Contributing Authors 173 Yaakov Stein (Rad), Annamaria Fulignoli (Ericsson), Italo Busi 174 (Alcatel Lucent), Huub van Helvoort (Huawei) 176 1.4. Acronyms 178 This draft uses the following acronyms: 180 ACH Associated Channel Header 181 BFD Bidirectional Forwarding Detection 182 CC-V Continuity Check and Connectivity Verification 183 G-ACH Generic Associated Channel Header 184 LSP Label Switched Path 185 MPLS-TP Transport Profile for MPLS 186 OAM Operations, Administration, and Maintenance 187 PW Pseudowire 188 RDI Remote Defect Indication 189 SLA Service Level Agreement 190 TLV Type, Length, Value 191 VCCV Virtual Circuit Connectivity Verification 193 2. Basic OAM infrastructure functionality 195 [MPLS-TP OAM Reqs] defines a set of requirements on OAM architecture 196 and general principles of operations which are evaluated below: 198 [MPLS-TP OAM Reqs] requires that 200 o OAM mechanisms in MPLS-TP are independent of the transmission 201 media and of the client service being emulated by the PW. 203 o the MPLS-TP OAM must be able to support both an IP based and 204 non-IP based environment. If the network is IP based, i.e. IP 205 routing and forwarding are available, then the MPLS-TP OAM tool- 206 set should rely on the IP routing and forwarding capabilities. On 207 the other hand, in environments where IP functionality is not 208 available, the OAM tools must still be able to operate without 209 dependence on IP forwarding and routing. 211 o all OAM protocols support identification information, at least in 212 the form of IP addressing structure and be extensible to support 213 additional identification schemes. 215 o OAM packets and the user traffic are congruent (i.e. OAM packets 216 are transmitted in-band) and there is a need to differentiate OAM 217 packets from user-plane ones. Inherent in this requirement is the 218 principle that MPLS-TP OAM be independent of any existing control- 219 plane, although it should not preclude use of the control-plane 220 functionality. 222 o a single OAM technology and consistent OAM capabilities for LSPs, 223 PWs, and Sections. 225 o OAM packets may be directed to an intermediate point of a LSP/PW. 227 The following comprise the document-set that addresses the basic 228 requirements listed above: 230 o The [MPLS-TP OAM Frwk] document describes the architectural 231 framework for conformance to the basic requirements listed above. 232 It also defines the basic relationships between the MPLS 233 structures, e.g. LSP, PW, and the structures necessary for OAM 234 functionality, i.e. the Managed Entity Group, its End-points, and 235 Intermediate Points. 237 o The [MPLS G-ACH] document specifies the use of the MPLS-TP in- 238 band control channel. This is modeled after the VCCV channel 239 described in [PW ACH] and allows transporting the OAM messages 240 congruently with the data traffic while allowing the required 241 identification of the packets. It is expected that all of the OAM 242 protocols will be used in conjunction with this Generic Associated 243 Channel. 245 o The [MPLS TP Idents] document addresses the need of MPLS-TP to 246 support different addressing spaces. This document describes 247 different formats for addresses that could be used to identify the 248 transport entities in the network and referenced by the different 249 OAM protocols. 251 3. MPLS-TP OAM Functions 253 The following sections discuss the OAM functions that are required in 254 [MPLS-TP OAM Reqs] and expanded upon in [MPLS-TP OAM Frwk]. 256 3.1. Continuity Check and Connectivity Verification 258 Continuity Check and Connectivity Verification (CC-V) are OAM 259 operations generally used in tandem, and compliment each other. 260 These functions are generally run pro-actively, but may also be used 261 on-demand, either due to bandwidth considerations or for diagnoses of 262 a specific condition. Pro-actively [MPLS-TP OAM Reqs] states that 263 the function should allow the MEPs to monitor the liveness and 264 connectivity of a transport path. In on-demand mode, this function 265 should support monitoring between the MEPs and, in addition, between 266 a MEP and MIP. 268 The [MPLS-TP OAM Frwk] highlights the need for the CC-V messages to 269 include unique identification of the MEG that is being monitored and 270 the MEP that originated the message. The function, both pro-actively 271 and in on-demand mode, needs to be transmitted at regular 272 transmission rates pre-configured by the operator. 274 3.1.1. Documents for CC-V tools 276 [Pro CC-V] defines the BFD extensions that will be used for proactive 277 CC-V applications. While [Demand CV] provides the LSP-Ping 278 extensions that will be used to implement on-demand Connectivity 279 Verification. Both of these tools will be used together with the 280 basic tools mentioned above in section 2. 282 3.2. Remote Defect Indication 284 Remote Defect Indication (RDI) is used by a path end-point to report 285 to its peer end-point that a defect is detected on a bi-directional 286 connection between them. [MPLS-TP OAM Reqs] points out that this 287 function may be applied to a unidirectional LSP only if there a 288 return path exists. [MPLS-TP OAM Frwk] points out that this function 289 is associated with the proactive CC-V function. 291 3.2.1. Documents for RDI 293 The [Pro CC-V] document includes an extension for BFD that would 294 include the RDI indication in the BFD format, and a specification of 295 how this indication is to be used. 297 3.3. Route Tracing 299 [MPLS-TP OAM Reqs] defines that there is a need for functionality 300 that would allow a path end-point to identify the intermediate and 301 end-points of the path. This function would be used in on-demand 302 mode. Normally, this path will be used for bidirectional PW, LSP, 303 and sections, however, unidirectional paths may be supported only if 304 a return path exists. 306 3.3.1. Documents for Route Tracing 308 The [Demand CV] document that specifies the LSP-Ping enhancements for 309 MPLS-TP on-demand Connectivity Verification includes information on 310 the use of LSP-Ping for route tracing of a MPLS-TP transport path. 312 3.4. Alarm Reporting 314 Alarm Reporting is a function used by an intermediate point of a 315 path, that becomes aware of a fault on the path, to report to the 316 end-points of the path. [MPLS-TP OAM Frwk] states that this may 317 occur as a result of a defect condition discovered at a server sub- 318 layer. This generates an Alarm Indication Signal (AIS) that 319 continues until the fault is cleared. The consequent action of this 320 function is detailed in [MPLS-TP OAM Frwk]. 322 3.4.1. Documents for Alarm Reporting 324 MPLS-TP defines a new protocol to address this functionality that is 325 documented in [Fault Mng]. This protocol uses all of the basic 326 mechanisms detailed in Section 2. 328 3.5. Lock Reporting 330 Lock reporting, defined in [MPLS-TP OAM Reqs], is similar to the 331 Alarm Reporting function described above. It is used by an 332 intermediate point to notify the end points of a transport path that 333 an administrative lock condition exists for this transport path. 335 3.5.1. Documents for Lock Reporting 337 MPLS-TP defines a new protocol to address this functionality that is 338 documented in [Fault Mng]. This protocol uses all of the basic 339 mechanisms detailed in Section 2. 341 3.6. Lock Instruct 343 The Lock Instruct function is an administrative control tool that 344 allows a path end-point to instruct its peer end-point to lock the 345 path. The tool is necessary to support single-side provisioning for 346 administrative locking, according to [MPLS-TP OAM Frwk]. This 347 function is used on-demand. 349 3.6.1. Documents for Lock Instruct 351 The [LiLoopback] document describes the details of a new ACH based 352 protocol format for this functionality. 354 3.7. Client Failure Indication 356 Client Failure Indication (CFI) is defined in [MPLS-TP OAM Reqs] to 357 allow the propagation information from one edge of the network to the 358 other. The information concerns a defect to a client, in the case 359 that the client does not support alarm notification. 361 3.7.1. Documents for CFI 363 A new ACH-based protocol is described in [MPLS-TP CSF] that addresses 364 the functionality defined for client failure indication. 366 3.8. Packet Loss Measurement 368 Packet Loss Measurement is required, by [MPLS-TP OAM Reqs] to provide 369 a quantification of the packet loss ratio on a transport path. This 370 is the ratio of the number of user packets lost to the total number 371 of user packets during a defined time interval. To employ this 372 function, [MPLS-TP OAM Frwk] defines that the two end-points of the 373 transport path should exchange counters of messages transmitted and 374 received within a time period bounded by loss-measurement messages. 375 The framework warns that there may be small errors in the computation 376 that result from various issues. 378 3.8.1. Documents for Packet Loss Measurement 380 The [Loss-Delay] document describes the protocol formats and 381 procedures for using the tool. The tool logic is based on the 382 behavior of the parallel function described in [Y.1731]. 384 3.9. Packet Delay Measurement 386 Packet Delay Measurement is a function that is used to measure one- 387 way or two-way delay of a packet transmission between a pair of the 388 end-points of a path (PW, LSP, or Section), as described in [MPLS-TP 389 OAM Reqs]. Where: 391 o One-way packet delay is the time elapsed from the start of 392 transmission of the first bit of the packet by a source node until 393 the reception of the last bit of that packet by the destination 394 node. 396 o Two-way packet delay is the time elapsed from the start of 397 transmission of the first bit of the packet by a source node until 398 the reception of the last bit of the loop-backed packet by the 399 same source node, when the loopback is performed at the packet's 400 destination node. 402 [MPLS-TP OAM Frwk] describes how the tool could be performed (both in 403 proactive and on-demand modes) for either one-way or two-way 404 measurement. However, it warns that the one-way delay option 405 requires precise time synchronization between the end-points. 407 3.9.1. Documents for Delay Measurement 409 The [Loss-Delay] document describes the protocol formats and 410 procedures for using the tool. The tool logic is based on the 411 behavior of the parallel function described in [Y.1731]. 413 4. MPLS-TP OAM documents guide 415 The complete MPLS-TP OAM protocol suite is covered by a small set of 416 existing IETF documents. This set of documents may be expanded in 417 the future to cover additional OAM functionality. in order, to allow 418 the reader to understand this set of documents a cross-reference of 419 the existing documents for the initial phase of the specification of 420 MPLS based transport networks is provided. 422 [MPLS G-ACH] provides a specification of the basic structure of 423 protocol messages for in-band data plane OAM in an MPLS environment. 425 [MPLS TP Idents] provides definitions of different formats that may 426 be used within OAM protocol messages to identify the network elements 427 of a MPLS based transport network. 429 [Pro CC-V] addresses the requirements for proactive use of Continuity 430 Check, Connectivity Verification, and Remote Defect Indication 431 functionality for MPLS transport networks. 433 [Demand CV] addresses the requirements for activation of the 434 Connectivity Verification functionality between endpoints or between 435 an endpoint and intermediate point of a monitored domain of a 436 transport path. 438 [Fault Mng] specifies protocol messages that support the 439 functionality required to support Alarm Indication Signal and Lock 440 Reporting required for MPLS transport networks. 442 [MPLS-TP CSF] addresses the requirements to support a Client Signal 443 Fail indication by clients that are being emulated by the MPLS 444 transport services. 446 [LiLoopback] specifies protocol messages that support the 447 functionality required for the Lock Instruct command and activation 448 of the Loopback functionality for transport paths in MPLS networks. 450 [Loss-Delay] addresses the requirements for performance measurement 451 functionality for MPLS transport networks. The protocol defined 452 supports both loss and delay measurement functions for the transport 453 paths. 455 5. IANA Considerations 457 This document makes no request of IANA. 459 Note to RFC Editor: this section may be removed on publication as an 460 RFC. 462 6. Security Considerations 464 This document does not by itself raise any particular security 465 considerations. Security considerations for each function in the OAM 466 tool-set need to be documented in the document that specifies the 467 particular functionality. 469 7. Acknowledgements 471 The editors wish to thank the MPLS-TP Design Team members, from both 472 the IETF and ITU-T leadership teams, in formulating the 473 recommendations documented here. In particular, we would like to 474 thank Loa Andersson, Huub van Helvoort, and the Area Directors for 475 their suggestions and enhancements to the text. 477 8. Normative References 479 [LSP Ping] 480 Kompella, K. and G. Swallow, "Detecting Multi-Protocol 481 Label Switched (MPLS) Data Plane Failures", RFC 4379, 482 February 2006. 484 [PW ACH] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 485 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 486 Use over an MPLS PSN", RFC 4385, February 2006. 488 [BASE BFD] 489 Katz, D. and D. Ward, "Bidirectional Forwarding 490 Detection", RFC 5880, February 2009. 492 [MPLS BFD] 493 Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 494 "BFD For MPLS LSPs", RFC 5884, June 2008. 496 [MPLS TP Idents] 497 Bocci, M. and G. Swallow, "MPLS-TP Identifiers", 498 ID draft-ietf-mpls-tp-identifiers-01.txt, March 2010. 500 [Pro CC-V] 501 Allan, D. and G. Swallow, "Proactive Connection 502 Verification, Continuity Check and Remote Defect 503 indication for MPLS Transport Profile", 504 ID draft-ietf-mpls-tp-cc-cv-rdi-00.txt, June 2010. 506 [Demand CV] 507 Bahadur, N., Aggarwal, R., Boutros, S., and E. Gray, "MPLS 508 on-demand Connectivity Verification, Route Tracing and 509 Adjacency Verification", 510 ID draft-ietf-mpls-tp-on-demand-cv-00, June 2010. 512 [MPLS-TP OAM Reqs] 513 Vigoureux, M., Betts, M., and D. Ward, "Requirements for 514 OAM in MPLS Transport Networks", 515 ID draft-ietf-mpls-tp-oam-requirements-05, April 2009. 517 [MPLS-TP OAM Frwk] 518 Busi, I., Niven-Jenkins, B., and D. Allan, "MPLS-TP OAM 519 Framework and Overview", 520 ID draft-ietf-mpls-tp-oam-framework-07, July 2010. 522 [MPLS-TP Reqs] 523 Niven-Jenkins, B., Nadeau, T., and C. Pignataro, 524 "Requirements for the Transport Profile of MPLS", 525 ID draft-ietf-mpls-tp-requirements-06, April 2009. 527 [MPLS G-ACH] 528 Bocci, M., Bryant, S., and M. Vigoureux, "MPLS Generic 529 Associated Channel", RFC 5586, June 2009. 531 [Fault Mng] 532 Swallow, G., Fulignoli, A., and M. Vigoureux, "MPLS Fault 533 Management OAM", ID draft-ietf-mpls-tp-fault-00, 534 March 2010. 536 [LiLoopback] 537 Boutros, S., Sivabalan, S., Aggarwal, R., Vigoureux, M., 538 and X. Dai, "MPLS Transport Profile Lock Instruct and 539 Loopback Functions", ID draft-ietf-mpls-tp-li-lb-00, 540 September 2010. 542 [MPLS-TP CSF] 543 He, J., LI, H., and E. Bellagamba, "Indication of Client 544 Failure in MPLS-TP", ID draft-he-mpls-tp-csf-00, 545 July 2010. 547 [Loss-Delay] 548 Frost, D. and S. Bryant, "Packet Loss and Delay 549 Measurement for the MPLS Transport Profile", 550 ID draft-ietf-mpls-tp-loss-delay-00, April 2010. 552 [Y.1731] International Telecommunications Union - Standardization, 553 "OAM functions and mechanisms for Ethernet based 554 networks", ITU Y.1731, May 2006. 556 Authors' Addresses 558 Nurit Sprecher 559 Nokia Siemens Networks 560 3 Hanagar St. Neve Ne'eman B 561 Hod Hasharon, 45241 562 Israel 564 Email: nurit.sprecher@nsn.com 565 Elisa Bellagamba 566 Ericsson 567 6 Farogatan St 568 Stockholm, 164 40 569 Sweden 571 Phone: +46 761440785 572 Email: elisa.bellagamba@ericsson.com 574 Yaacov Weingarten 575 Nokia Siemens Networks 576 3 Hanagar St. Neve Ne'eman B 577 Hod Hasharon, 45241 578 Israel 580 Phone: +972-9-775 1827 581 Email: yaacov.weingarten@nsn.com