idnits 2.17.1 draft-georgiades-opsawg-intercar-oam-req-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC5706,RFC5860], [IEEE1,IEEE2], [MEFOAM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 30, 2013) is 3978 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 138, but not defined == Unused Reference: 'Y1710' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'Y1730' is defined on line 564, but no explicit reference was found in the text == Unused Reference: 'Y1731' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'RFC4378' is defined on line 574, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OPSAWG WG M. Georgiades 3 Internet-Draft PrimeTel 4 Intended Status: Informational F.Cugini 5 Expires: 1 December, 2013 CNIT 6 D. Berechya, N. Sprecher 7 NSN 8 O. Gonzalez 9 TID 10 May 30, 2013 12 Inter-Carrier OAM Requirements 13 draft-georgiades-opsawg-intercar-oam-req-04.txt 15 Abstract 17 This draft specifies requirements for inter-carrier OAM supporting 18 end-to-end OAM functionality and mechanisms development in a multi- 19 operator environment. It reviews the already proposed OAM 20 requirements addressed in IETF [RFC5706, RFC5860], ITU-T [Y.1730],MEF 21 [MEFOAM] and IEEE [IEEE1, IEEE2] which were mainly proposed on a per 22 transport technology basis, but aims to differentiate and focus on 23 the requirements and additional requirements resulting from inter- 24 operator considerations only. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 33 other groups may also distribute working documents as 34 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 Copyright and License Notice 49 Copyright (c) 2011 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 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Inter-carrier OAM Gap Analysis . . . . . . . . . . . . . . . . 6 67 3.1. OAM single region/single carrier transport network 68 requirements . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.2. OAM for inter-carrier transport networks . . . . . . . . . 9 70 4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 72 5.1 List of Contributors . . . . . . . . . . . . . . . . . . . . 12 73 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 76 1 Introduction 78 Operation, Administration and Management (or Maintenance) (OAM), 79 functionality is important in network operation and management for 80 simplifying network operations and to reduce cost. It supports 81 capabilities for fault management (including fault detection, fault 82 notification and fault isolation), as well as performance degradation 83 awareness. In this draft a distinction is made with regards to what 84 is considered as a subset of all OAM requirements relating to inter- 85 operator considerations only and we refer to these as inter-carrier 86 OAM requirements. More specifically these relate relate to end-to-end 87 service delivery crossing domains and could be considered as agnostic 88 to underlying transport technologies. Influencing further the 89 requirements could be policies, QoS (SLA) agreements or commercial 90 agreemetns between carriers. 92 OAM operations have been considered for different data transport 93 technologies in by different standardisation bodies. Some solution 94 examples include ATM OAM ITU-T I.610 [I.610] defining the ATM OAM 95 functions, IEEE 802.3-2008 [IEEE1] and ITU-T Y.1730 [Y.1730] 96 defining Ethernet related OAM, IETF RFC 5706 [RFC5706] for OAM 97 protocols extensions, IETF RFC 5860 [RFC5860] defining OAM 98 requirements in MPLS networks. These protocols have been designed by 99 different organizations in different standard bodies proposing either 100 requirements or mechanisms to handle three main functions namely: (A) 101 Failure Detection and Diagnostics, (B)Recovery, and (C) Performance 102 Monitoring for a particular technology including SONET & SDH, ATM, 103 MPLS and Carrier Ethernet. Inter-working considerations between 104 different OAM mechanisms proposed for the different transport 105 technologies have been left for further studies. Although some of the 106 proposed OAM protocols do mention interoperability considerations, 107 requirement details and solutions for these were commonly out of the 108 scope. Moreover considering common syntax among protocols to resolve 109 interoperability issues has proven difficult. 111 OAM functions have been proposed mainly for fault management but also 112 performance monitoring. Y.1731 [Y.1731] and RFC 5860 [RFC5860] list 113 the following functions for Ethernet fault management: Continuity 114 Check, Loopback, Link Trace, Alarm Indication Signal, Remote Defect 115 Indication, Locked Signal, Test Signal, Automatic Protection 116 Switching, Maintenance Communication Channel, Experimental OAM and 117 Vendor Specific OAM. For Ethernet performance monitoring [Y.1731] 118 lists the following necessary functions: loss measurement, delay 119 measurement and throughput measurement. 121 A similar approach was followed for the development of other OAM 122 mechanism mainly on a per transport technology basis. Although for 123 example inter-working between such mechanisms have been proposed e.g. 125 MPLS-to-Ethernet OAM, inter-carrier OAM issues and associated service 126 related technological issues due to these have not been addressed 127 thoroughly. 129 The latter may result in the proposal of new functionality/mechanisms 130 on a more generic common level (transport technology agnostic) that 131 can become more acceptable by operators for inter-carrier operations. 133 1.1 Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in RFC 2119 [RFC2119]. 139 OAM 141 Operation, Administration and Maintenance Maintenance Entity (ME) 142 It represents an entity that requires management. 144 MEG 146 Maintenance Entity Group (MEG) consists of the MEs that belong to 147 the same service inside a common OAM domain. For a Point-to-Point 148 EVC, a MEG contains a single ME. For a Multipoint-to-Multipoint 149 EVC of n UNIs, a MEG contains n*(n-1)/2 MEs. 151 OAM transparency 153 This term refers to the ability to allow transparent carrying of 154 OAM packets belonging to higher level MEGs across other lower 155 level MEGs when the MEGs are nested. 157 In-service OAM 159 It refers to OAM actions which are carried out while the data 160 traffic is not interrupted with an expectation that data traffic 161 remains transparent to OAM actions. 163 Out-of-service OAM 165 It refers to OAM actions which are carried out while the data 166 traffic is interrupted. 168 On-demand OAM 170 It refers to OAM actions which are initiated via manual 171 intervention for a limited time to carry out diagnostics. 173 Proactive OAM 175 It refers to OAM actions which are carried out continuously to 176 permit proactive reporting of fault and/or performance results. 178 In-Service OAM 180 It refers to OAM actions which are carried out while the data 181 traffic is not interrupted with an expectation that data traffic 182 remains transparent to OAM actions. 184 Out-of-service OAM 186 It refers to OAM actions which are carried out while the data 187 traffic is interrupted. 189 On-path service NSP 191 A transit NSP who is used as a traffic carrier or service provider 192 of a particular service. 194 Service-based OAM 196 Service Level OAM relates to any operations which are associated 197 with a particular service. A good example is the delivery of the 198 agreed throughput (service issue) as opposed to allocated 199 bandwidth for the link/segment (network resource issue). 201 Network-based OAM 203 Network-based OAM relates to any operations which are associated 204 with a particular network links, network segments, network 205 resources etc. A good example is the delivery of the agreed 206 bandwidth on a network segment (network resource issue) as opposed 207 to the actual throughput delivered (service issue). 209 Carrier 211 A carrier is an organization that provides communications and 212 networking services; Also referred to as a Network Service 213 Provider (NSP) in the draft. 215 Region 217 A region is considered to be a collection of network elements 218 under a single technology. 220 Domain 221 A domain is considered to be any collection of network elements 222 within a common sphere of address management or path computational 223 responsibility. Examples of such domains include IGP areas and 224 Autonomous Systems; 226 2. Inter-carrier OAM Gap Analysis 228 To handle different possible scenarios for OAM it is important to 229 first categorize the network scope that OAM support will be designed 230 for. The network scope may contain homogenous technological domains 231 (or regions), heterogeneous domains, and even different carriers 232 (network operators). Moreover it may be composed by elements 233 belonging to different technologies and having different switching 234 capabilities. The major data transport technologies are considered 235 including Multi-Protocol Label Switching - Transport Profile (MPLS- 236 TP), Wavelength Switched Optical Networks (WSON) and corresponding 237 switching capabilities like Packet Switching Capability (PSC) and 238 Lambda Switching Capability (LSC) respectively. 240 |<-----------------Inter-Carrier OAM---------------->| 241 |<------------------Inter-Region OAM----------------->| 242 |<----------Inter-Carrier OAM--------->| 243 |<---Inter-Region OAM--->| 244 |<---Intra-Carrier OAM--->| |<--Intra-Carrier OAM--->|<-Intra-C.-->| 245 |<-IntraDom-><-IntraDom-->| |<-IntraDom-><-IntraDom->|<-IntraDom-->| 246 -------------------------- ------------------------ ------------ 247 +---------+ +--------+ | | +--------+ +-----+ | | +-------+ 248 | | | | | | | | | | | | | | 249 -| IP/MPLS |-- |IP/MPLS |-| | |MPLS-TP |--- | ETH |---- | OTN |-- 250 | | | | | | | | | | | | | | 251 +---------+ +--------+ | | +--------+ +-----+ | | +-------+ 252 Operator/Carrier 1 | | Operator/Carrier 2 | | Carrier 3 253 -------------------------- ------------------------ ------------ 254 Figure 1 End-to-end OAM Operation Areas Definitions 256 Figure 1 shows how in a real end-to-end network scenarios, different 257 OAM areas of operation are depicted and the granularity level can be 258 summarized as follows: 260 i) Inter-Carrier OAM (between different network operators, same 261 or different technologies) 262 ii) Inter-Region OAM (between regions of different technologies, 263 same or different carriers) 264 iii) Intra-Carrier OAM (within a single carrier, between 265 homogenous or heterogeneous regions i.e. different technologies) 266 iv) Intra-Domain OAM (i.e. single technology, single domain) 268 Such identification of the OAM signaling range granularity proves 269 necessary for accommodating for single/multi-operator environment, 270 single/multi-regions or a combination of these. Intra-domain OAM e.g. 271 section or link OAM etc. are not in the scope of this draft. 273 It is worth noting that, until now, little attention has been paid to 274 the inter-region/inter-carrier cases and no clear distinction from 275 intra-region/intra-carrier requirements has been made by 276 standardization bodies. 278 Requirements for Operational, Administration and Maintenance have 279 already been defined in detail by ITU-T, IETF and MEF, regarding the 280 single-domain scenario. 282 OAM Requirements considered so far depend mainly on the data 283 transport network technology they aim to support. RFC 5860 [RFC5860] 284 for example has defined OAM requirements for OAM functionality for 285 MPLS networks.Similarly Y.1730 defined requirements for OAM functions 286 in Ethernet-based networks. 288 Different OAM protocols have been recommended and used for different 289 data transport technologies. Also different Networks Service 290 Providers (NSPs) may choose to use different OAM standards to monitor 291 their operation, maintenance and fault detection, checking network 292 devices possibly from different vendors, different models and 293 different releases. This could be due to the fact that an operator 294 may want to monitor different technological domains, different 295 topologies or even multiple heterogeneous domains and hence OAM at a 296 different plane or OSI stack level. Moreover a Network Service 297 Provider may want to achieve service OAM provisioning for reserved 298 resources across multiple-carriers. This gives rise to several 299 considerations when dealing with interconnected heterogeneous 300 networks and inter-NSP scenarios particularly in cases where the end- 301 to-end OAM control information is of interest e.g. for ensuring end- 302 to-end network support for a particular service. 304 Current OAM functionalities do not guarantee network OAM aligned to a 305 associated with a particular service. The majority of OAM standards 306 are there to support network transport technologies and are not 307 sufficient to adequately support end-to-end network services in 308 inter-carrier scenarios. Inter-working between OAM for different 309 technologies may not be sufficient to achieve inter-carrier OAM 310 cooperation. 312 This draft aims to emphasize on end-to-end inter-carrier OAM 313 requirements and the need to consider a twofold set of requirements 314 derived both from technological aspects derived from the need to 315 satisfy network operation associated to a particular service but also 316 technical requirements derived from inter-carrier business 317 considerations associated to a particular service. 319 Inter carrier OAM involves any technological and technical aspects, 320 that once developed will motivate synergy between operators for OAM 321 and will offer more reliable and trustful means for co-operation. 323 Furthermore some network events that are detected and measured by end 324 to end OAM such as failures may require customer compensation and, in 325 consequence, inter carrier reimbursement. The current OAM system does 326 not clearly provide trusted means for determining the location and 327 the duration of failures in the environment of multi carrier where 328 each carrier uses different systems for measuring and logging the 329 events, and one carriers may not rely on the other carrier's 330 measuring. 332 Another important differentiation which is depicted in this draft and 333 it is of great importance particularly in inter-carrier operation is 334 Service Level OAM vs. Network Level OAM. 336 Service Level OAM relates to any operations which are associated with 337 a particular service. A good example will be the delivery of the 338 agreed throughput (service issue) as opposed to allocated bandwidth 339 for the link/segment (network resource issue). 341 Network-based OAM relates to any operations which are associated with 342 a particular network links, network segments, network resources etc. 343 A good example will be the delivery of the agreed bandwidth on a 344 network segment (network resource issue) as opposed to the actual 345 throughput delivered (service issue). 347 3.1. OAM single region/single carrier transport network requirements 349 Both IETF and ITU-T have identified OAM requirements for a single 350 region transport network, for different technologies. In general the 351 requirements can be grouped under these two main 352 categories:architectural requirements and functional requirements. 353 Most of the single domain OAM requirements are relevant for the inter 354 domain as well. The most important architectural requirements are: a) 355 Independence of the OAM level from service and underlying networks, 356 b) Bidirectional application of OAM mechanisms should be possible, c) 357 Application of OAM functions to unidirectional point-to-point and 358 point-to-multipoint connections should be possible. 360 The functional requirements are split into two further sub-categories 361 with regard to the task they are facing with: fault detection and 362 locating and performance monitoring. The main OAM mechanisms required 363 by the joint ITU-T - IETF working group for fault management are: 365 Continuity check / verification, Alarm suppression, Lock indication, 366 Diagnostic test, Trace-route, Remote defect indication. 368 The main OAM mechanisms required by the joint ITU-T - IEFT working 369 group for performance monitoring are: a) Packet loss measurement, b) 370 Delay and jitter measurement. On the other hand MEF, more focused on 371 service OAM, has specified the following list of requirements: a) 372 Service OAM should discover other elements in the Metro Ethernet 373 Networks (MEN); b)Service OAM should monitor the connectivity status 374 of other elements (active, not-active, partially active); (c) 375 Performance monitoring should estimate Frame Loss Ratio (FLR) 376 Performance, Frame Delay Performance, and Frame Delay Variation (FDV) 377 Performance; OAM frames should be prevented from "leaking" outside 378 the appropriate OAM domain to which OAM should be independent of the 379 application layer technologies and OAM capabilities they apply; 380 (e)the OAM frames should traverse the same paths as the service 381 frames, (f)the OAM should be independent of but allow 382 interoperability with the underlying transport layer and its OAM 383 capabilities; (g) the OAM should be independent of the application 384 layer technologies and OAM capabilities. 386 3.2. OAM for inter-carrier transport networks 388 This subsection deals with inter-carrier and hence also inter-region 389 issues in the existing standards. The goal is to identify gaps and to 390 discuss new requirements to fill these gaps. 392 In many cases network services traverse several carriers and regions, 393 and in long distance services this is the most probable case. A 394 multi-carrier and multi-regional environment poses special technical 395 and commercial OAM requirements that should be defined and 396 addressed. 398 In particular, OAM in multi-carrier networks has commercial aspects 399 that do not exist in single carrier networks. Indeed, in case of 400 failure or out-of-SLA service delivery, the violating carrier should 401 compensate its partner carriers or the end customer. Based on the 402 information made available by the OAM tools, the carriers should 403 agree on the root cause. 405 Unfortunately, at present the existing standards do not have trusted 406 mechanism to support these commercial issues. Furthermore, the out- 407 of-service duration is a significant factor when calculating the 408 compensation/penalty in case of failure. Yet, currently, each service 409 provider measures the out-of-service duration independently; as a 410 result, it is difficult to agree on the out-of-service duration and, 411 as a consequence, on the amount of compensation. 413 The existing standards for OAM in transport networks do not clearly 414 address the above mentioned problems; therefore, in a multi-carrier 415 environment, the following requirements may be specifically defined 416 by considering that Inter-carrier OAM should address or reference how 417 inter-region or inter-technology requirements are addressed. 418 Technological inter-operability issues and inter-region OAM issues 419 should be addressed separately to inter-carrier considerations. 421 The requirements identified for the Inter-carrier OAM system are as 422 follows: 424 1. Inter-carrier OAM system SHOULD be supported by Maintenance 425 Entities (MEs) that are handled by different operators 426 (carriers). 428 2. Inter-carrier OAM system SHOULD be able to discover the MEs 429 involved in the operation and hence the corresponding network 430 elements. 432 3. Inter-carrier OAM system SHOULD provide in-service reliable 433 means to the network service providers (NSPs) to prove, in case of 434 failure, which is the failing transit carrier or transit NSP etc. 436 4. Inter-carrier OAM system SHOULD provide optional in-service 437 notification messages that could be used to inform on-path service 438 NSPs of other on-path NSPs service degradation. This includes for 439 example any deviation from the SLA agreement and related 440 parameters (Jitter, Packet Loss, Throughput etc.). 442 5. Inter-carrier OAM system SHOULD provide reliable means to 443 measure an NSP's out-of-service provisioning duration; such 444 measurement could be agreed by all involved parties. 446 6. Inter-carrier OAM system SHOULD provide means for 447 confidentiality and privacy between involved carriers. 449 7. Inter-carrier OAM system SHOULD have the option of disclosing 450 information forwarded by transit NSPs that are not involved under 451 the same inter-carrier OAM agreement. 453 8. Inter-carrier OAM system MAY have the ability to inter-work 454 with the PCE architecture and traffic engineering databases, 455 aiming at improving reliability and accuracy in path computations, 456 and performing correlation of OAM information for location and 457 tracking of failures. 459 9. Inter-carrier OAM system SHOULD work and react independently to 460 the underlying transport layer technologies (transport technology 461 agnostic) used e.g. Ethernet layer. 463 10. Inter-carrier OAM system SHOULD react within a time frame 464 agreed by the involved carriers. The time frame should be 465 reasonable enough to restore their service in case of failure. 467 11. Inter-carrier OAM should be handled using a common management 468 across all transport technologies using the same protocol type. 470 12. Inter-carrier OAM system should be aware when an ME is added 471 or removed from the system. 473 13. Inter-carrier OAM system should support the detection and 474 reporting of faults across heterogeneous administrative domains. 476 14. Inter-carrier OAM system should support the isolation of 477 faults across heterogenous administrative domains. 479 15. Inter-carrier OAM system should support repair of faults 480 across heterogenous adminsitrative domains. 482 16. Inter-carrier OAM system should support the detection and 483 reporting of underperforming regions across heterogeneous 484 administrative domains. 486 17. Inter-carrier OAM system should support the isolation of 487 underperforming regions across heterogenous adminsitrative 488 domains. 490 18. Inter-carrier OAM system should support repair of 491 underperforming regions across heterogenous adminsitrative 492 domains. 494 4 Summary 496 This document reviews the existing OAM standards, identifies gaps, 497 and discusses new requirements for the inter domain and inter 498 carrier scenarios. The exiting OAM standards do not clearly 499 address the specific needs of: inter-carrier, inter-region (inter- 500 technology) as well as cross-layer OAM requirements (network 501 level, service level etc.). This draft aimed to initiate this and 502 focuses on the inter-carrier requirements only. The majority of 503 these requirements were derived from the nature of service 504 provisioning between different network service providers. OAM is 505 an essential tool set for network operation and service 506 provisioning, and in case of inter-carrier it can help to support 507 as well as settle responsibility disputes between operators in 508 case of failures and performance degradations. 510 5 Acknowledgements 512 This draft has been produced by the following three projects which 513 are funded by the European Union's Seventh Framework Program 514 (FP7/2007-2013): 516 STRONGEST (FP7-ICT-247674); http://www.ict-strongest.eu/); 518 ETICS (FP7-ICT-248567); http://www.ict-etics.eu/); 520 MAINS (FP7-ICT-247706; http://www.ist-mains.eu/); 522 5.1 List of Contributors 524 Michael Georgiades, Primetel, Cyprus; 526 Filipo Cugini, CNIT, Italy; 528 David Berechya, NSN, Israel; 530 Oscar Gonzalez, TID (Telefonica), Spain; 532 Nurit Sprecher, NSN, Israel; 534 6 References 536 [RFC5860] Vigourex, M., Ward, D., Betts, M., Bocci, M., Busi, I., 537 "Requirements for Operations, Administration, and 538 Maintenance (OAM) in MPLS Transport Networks", RFC 5860, 539 May 2010. 541 [I.610] ITU-T Recommendation I.610, "B-ISDN operation and maintenance 542 principles and functions", February 1999. 544 [IEEE1] IEEE 802.3-2008, IEEE Standard for Information technology - 545 Telecommunications and information exchange between 546 systems--Local and metropolitan area networks--Specific 547 requirements Part 3: Carrier Sense Multiple Access with 548 Collision Detection (CSMA/CD) Access Method and Physical 549 Layer Specifications. Institute of Electrical and 550 Electronics Engineers, 2977 pages, ISBN: 9730738157979, 551 December 2008. 553 [IEEE2] IEEE 802.1ag, "Virtual Bridged Local Area Networks - 554 Amendment 5: Connectivity Fault Management, IEEE 802.1 555 Committee", December 2007. 557 [MEFOAM] MEF, "Service OAM Requirements & Framework - Phase 1 558 Technical Specification, Metro Ethernet Forum", April 559 2007. 561 [Y1710] ITU-T Recommendation Y.1710(2002), "Requirements for OAM 562 Functionality for MPLS Networks", January 2001. 564 [Y1730] Recommendation Y.1730, "Requirements for OAM functions in 565 Ethernet based networks", January 2004. 567 [Y1731] ITU-T Recommendation Y.1731 - OAM functions and mechanisms 568 for Ethernet based networks, January 2006. 570 [RFC5706] Harringhton, D., "Guidelines for Considering Operations and 571 Management of New Protocols and Protocol Extensions", RFC 572 5706, November 2009. 574 [RFC4378] Allan, D. , Nadeau, T., A framework for Multi-Protocol 575 Label Switching (MPLS) Operations and Management (OAM), 576 RFC4378, February 2006. 578 Authors' Addresses 580 Michael Georgiades 581 R&D Manager 582 The Maritime Center, PrimeTel PLC, 583 Omonia Avenue 141, 3045 Limassol, Cyprus 584 Email: michaelg@prime-tel.com 586 Filippo Cugini 587 CNIT National Lab of Photonic Networks 588 Scuola Superiore Sant'Anna (SSSUP) 589 via Moruzzi 1, 56124 Pisa, Italy 590 Email: filippo.cugini@cnit.it 592 David Berechya 593 Research, Multi-Layer Networks and Resilience 594 Nokia Siemens Networks 595 3 Hanagar St. 596 Hod Hasharon 45240, Israel 597 Email: david.berechya@nsn.com 598 Oscar Gonzalez 599 Telefonica I+D 600 Ramon de la Cruz, 82-84 601 Madrid, 28006 602 Email: ogondio@tid.es