OPSAWG WG M. Georgiades Internet-Draft PrimeTel Intended Status: Informational F.Cugini Expires: 24 November 2012 CNIT D. Berechya NSN O. Gonzalez TID May 23, 2012 Inter-Carrier OAM Requirements draft-georgiades-opsawg-intercar-oam-req-02.txt Abstract This draft specifies requirements for inter-carrier OAM supporting end-to-end OAM functionality and mechanisms development in a multi- operator environment. It reviews the already proposed OAM requirements addressed in IETF [RFC5706, RFC5860], ITU-T [Y.1730], MEF [MEFOAM] and IEEE [IEEE1, IEEE2] which were mainly proposed on a per transport technology basis. This document specifies additional requirements for the inter-carrier OAM operations. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html M.Georgiades Expires 24 November 2012 [Page 1] INTERNET DRAFT Inter-Carrier OAM Requirements 24 November 2011 Copyright and License Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Inter-carrier OAM Gap Analysis . . . . . . . . . . . . . . . . 5 3.1. OAM single region/single carrier transport network requirements . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. OAM for inter-carrier transport networks . . . . . . . . . 9 4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 5.1 List of Contributors . . . . . . . . . . . . . . . . . . . . 11 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 M.Georgiades Expires 24 November 2012 [Page 2] INTERNET DRAFT Inter-Carrier OAM Requirements 24 November 2011 1 Introduction OAM functionality is important in network operation and management for simplifying the operation and to reduce cost. It supports capabilities for fault management (including fault detection, fault notification and fault isolation), as well as performance degradation awareness. A distinction of inter-carrier OAM requirements is made from just the inter-operability requirements between carriers. The first may also cover technological issues and requirements which relate to end-to-end service delivery crossing domains but which could be agnostic to underlying transport technologies. This may also take into account different commercial administration as well as operation policies of carriers. OAM operations have been considered for different data transport technologies by different standard bodies. Some solution examples include ATM OAM ITU-T I.610 [I.610], IEEE 802.3-2008 [IEEE1], ITU-T Y.1730 [Y.1730], IETF RFC 5860, IETF RFC 5706 [RFC5706], IETF RFC 5860 [RFC5860]. These protocols have been designed by different organizations in different standard bodies to handle three main functions namely: (A) Failure Detection and Diagnostics, (B) Recovery, and (C) Performance Monitoring for a particular technology including SONET & SDH, ATM, MPLS and Carrier Ethernet. Inter-working considerations between different OAM mechanisms proposed for the different transport technologies have been left for future studies. Although some of the proposed OAM protocols do mention interoperability considerations, requirement details and solutions for these are usually out of the scope. Moreover considering common syntax among protocols to resolve interoperability issues has proven difficult. OAM functions have been proposed mainly for fault management but also performance monitoring. Y.1731 [Y.1731] and RFC 5860 [RFC5860] list the following functions for Ethernet fault management: Continuity Check, Loopback, Link Trace, Alarm Indication Signal, Remote Defect Indication, Locked Signal, Test Signal, Automatic Protection Switching, Maintenance Communication Channel, Experimental OAM and Vendor Specific OAM. For Ethernet performance monitoring [Y.1731] lists the following necessary functions: loss measurement, delay measurement and throughput measurement. A similar approach was followed for the development of other OAM mechanism mainly on a per transport technology basis. Although for example interworking between such mechanisms have been proposed e.g. MPLS-to-Ethernet OAM, inter-carrier OAM issues and associated service related technological issues due to these have not been addressed thoroughly. The later may result in the proposal of new functionality/mechanisms on a more generic common level (transport M.Georgiades Expires 24 November 2012 [Page 3] INTERNET DRAFT Inter-Carrier OAM Requirements 24 November 2011 technology agnostic) that can become more acceptable by operators for inter-carrier operations. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. OAM Operation, Administration and Maintenance Maintenance Entity (ME) It represents an entity that requires management. MEG Maintenance Entity Group (MEG) consists of the MEs that belong to the same service inside a common OAM domain. For a Point-to-Point EVC, a MEG contains a single ME. For a Multipoint-to-Multipoint EVC of n UNIs, a MEG contains n*(n-1)/2 MEs. OAM transparency This term refers to the ability to allow transparent carrying of OAM packets belonging to higher level MEGs across other lower level MEGs when the MEGs are nested. In-service OAM It refers to OAM actions which are carried out while the data traffic is not interrupted with an expectation that data traffic remains transparent to OAM actions. Out-of-service OAM It refers to OAM actions which are carried out while the data traffic is interrupted. On-demand OAM It refers to OAM actions which are initiated via manual intervention for a limited time to carry out diagnostics. Proactive OAM It refers to OAM actions which are carried out continuously to permit proactive reporting of fault and/or performance results. M.Georgiades Expires 24 November 2012 [Page 4] INTERNET DRAFT Inter-Carrier OAM Requirements 24 November 2011 On-path service NSP A transit NSP who is used as a traffic carrier or service provider of a particular service. Service-based OAM Service Level OAM relates to any operations which are associated with a particular service. A good example is the delivery of the agreed throughput (service issue) as opposed to allocated bandwidth for the link/segment (network resource issue). Network-based OAM Network-based OAM relates to any operations which are associated with a particular network links, network segments, network resources etc. A good example is the delivery of the agreed bandwidth on a network segment (network resource issue) as opposed to the actual throughput delivered (service issue). Carrier A carrier is an organization that provides communications and networking services; Also referred to as a Network Service Provider (NSP) in the draft. Region A region is considered to be a collection of network elements under a single technology. Domain A domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems; 2. Inter-carrier OAM Gap Analysis To handle different possible scenarios for OAM it is important to first categorize the network scope that OAM support will be designed for. The network scope may contain homogenous technological domains (or regions), heterogeneous domains, and even different carriers (network operators). Moreover it may be composed by elements belonging to different technologies and having different switching capabilities. The major data transport technologies are considered M.Georgiades Expires 24 November 2012 [Page 5] INTERNET DRAFT Inter-Carrier OAM Requirements 24 November 2011 including Multi-Protocol Label Switching - Transport Profile (MPLS- TP), Wavelength Switched Optical Networks (WSON) and corresponding switching capabilities like Packet Switching Capability (PSC) and Lambda Switching Capability (LSC) respectively. |<-----------------Inter-Carrier OAM---------------->| |<------------------Inter-Region OAM----------------->| |<----------Inter-Carrier OAM--------->| |<---Inter-Region OAM--->| |<---Intra-Carrier OAM--->| |<--Intra-Carrier OAM--->|<-Intra-C.-->| |<-IntraDom-><-IntraDom-->| |<-IntraDom-><-IntraDom->|<-IntraDom-->| -------------------------- ------------------------ ------------ +---------+ +--------+ | | +--------+ +-----+ | | +-------+ | | | | | | | | | | | | | | -| IP/MPLS |-- |IP/MPLS |-| | |MPLS-TP |--- | ETH |---- | OTN |-- | | | | | | | | | | | | | | +---------+ +--------+ | | +--------+ +-----+ | | +-------+ Operator/Carrier 1 | | Operator/Carrier 2 | | Carrier 3 -------------------------- ------------------------ ------------ Figure 1 End-to-end OAM Operation Areas Definitions Figure 1 shows how in a real end-to-end network scenarios, different OAM areas of operation are depicted and the granularity level can be summarized as follows: i) Inter-Carrier OAM (between different network operators, same or different technologies) ii) Inter-Region OAM (between regions of different technologies, same or different carriers) iii) Intra-Carrier OAM (within a single carrier, between homogenous or heterogeneous regions i.e. different technologies) iv) Intra-Domain OAM (i.e. single technology, single domain) Such identification of the OAM signaling range granularity proves necessary for accommodating for single/multi-operator environment, single/multi-regions or a combination of these. Intra-domain OAM e.g section or link OAM etc. are not in the scope of this draft. It is worth noting that, until now, little attention has been paid to the inter-region/inter-carrier cases and no clear distinction from intra-region/intra-carrier requirements has been made by standardization bodies. Requirements for Operational, Administration and Maintenance have already been defined in detail by ITU-T, IETF and MEF, regarding the single-domain scenario. M.Georgiades Expires 24 November 2012 [Page 6] INTERNET DRAFT Inter-Carrier OAM Requirements 24 November 2011 OAM Requirements considered so far depend mainly on the data transport network technology they aim to support. RFC 5860 [RFC5860] for example has defined OAM requirements for OAM functionality for MPLS networks.Similarly Y.1730 defined requirements for OAM functions in Ethernet-based networks. Different OAM protocols have been recommended and used for different data transport technologies. Also different Networks Service Providers (NSPs) may choose to use different OAM standards to monitor their operation, maintenance and fault detection, checking network devices possibly from different vendors, different models and different releases. This could be due to the fact that an operator may want to monitor different technological domains, different topologies or even multiple heterogeneous domains and hence OAM at a different plane or OSI stack level. Moreover a Network Service Provider may want to achieve service OAM provisioning for reserved resources across multiple-carriers. This gives rise to several considerations when dealing with interconnected heterogeneous networks and inter-NSP scenarios particularly in cases where the end- to-end OAM control information is of interest e.g. for ensuring end- to-end network support for a particular service. Current OAM functionalities do not guarantee network OAM aligned to a associated with a particular service. The majority of OAM standards are there to support network transport technologies and are not sufficient to adequately support end-to-end network services in inter-carrier scenarios. Inter-working between OAM for different technologies may not be sufficient to achieve inter-carrier OAM cooperation. This draft aims to emphasize on end-to-end inter-carrier OAM requirements and the need to consider a twofold set of requirements derived both from technological aspects derived from the need to satisfy network operation associated to a particular service but also technical requirements derived from inter-carrier business considerations associated to a particular service. Inter carrier OAM involves any technological and technical aspects, that once developed will motivate synergy between operators for OAM and will offer more reliable and trustful means for co-operation. Furthermore some network events that are detected and measured by end to end OAM such as failures may require customer compensation and, in consequence, inter carrier reimbursements. The current OAM system does not clearly provide trusted means for determining the location and the duration of failures in the environment of multi carrier where each carrier uses different systems for measuring and logging the events, and one carriers may not rely on the other carrier's measuring. M.Georgiades Expires 24 November 2012 [Page 7] INTERNET DRAFT Inter-Carrier OAM Requirements 24 November 2011 Another important differentiation which is depicted in this draft and it is of great importance particularly in inter-carrier operations is Service Level OAM vs. Network Level OAM. Service Level OAM relates to any operations which are associated with a particular service. A good example will be the delivery of the agreed throughput (service issue) as opposed to allocated bandwidth for the link/segment (network resource issue). Network-based OAM relates to any operations which are associated with a particular network links, network segments, network resources etc. A good example will be the delivery of the agreed bandwidth on a network segment (network resource issue) as opposed to the actual throughput delivered (service issue). 3.1. OAM single region/single carrier transport network requirements Both IETF and ITU-T have identified OAM requirements for a single region transport network, for different technologies. In general the requirements can be grouped under these two main categories:architectural requirements and functional requirements. Most of the single domain OAM requirements are relevant for the inter domain as well. The most important architectural requirements are: a) Independence of the OAM level from service and underlying networks, b) Bidirectional application of OAM mechanisms should be possible, c) Application of OAM functions to unidirectional point-to-point and point-to-multipoint connections should be possible. The functional requirements are split into two further sub-categories with regard to the task they are facing with: fault detection and locating and performance monitoring. The main OAM mechanisms required by the joint ITU-T - IETF working group for fault management are: Continuity check / verification, Alarm suppression, Lock indication, Diagnostic test, Trace-route, Remote defect indication. The main OAM mechanisms required by the joint ITU-T - IEFT working group for performance monitoring are: a) Packet loss measurement, b) Delay and jitter measurement, On the other hand MEF, more focused on service OAM, has specified the following list of requirements: a) Service OAM should discover other elements in the Metro Ethernet Networks (MEN); (b)Service OAM should monitor the connectivity status of other elements (active, not- active, partially active); (c) Performance monitoring should estimate Frame Loss Ratio (FLR) Performance, Frame Delay Performance, and Frame Delay Variation (FDV) Performance; OAM frames should be prevented from "leaking" outside the appropriate OAM domain to which M.Georgiades Expires 24 November 2012 [Page 8] INTERNET DRAFT Inter-Carrier OAM Requirements 24 November 2011 they apply; (e)the OAM frames should traverse the same paths as the service frames, (f)the OAM should be independent of but allow interoperability with the underlying transport layer and its OAM capabilities; (g) the OAM should be independent of the application layer technologies and OAM capabilities. 3.2. OAM for inter-carrier transport networks This subsection deals with inter-carrier and hence also inter-region issues in the existing standards. The goal is to identify gaps and to discuss new requirements to fill these gaps. In many cases network services traverse several carriers and regions, and in long distance services this is the most probable case. A multi-carrier and multi- regional environment poses special technical and commercial OAM requirements that should be defined and addressed. In particular, OAM in multi-carrier networks has commercial aspects that do not exist in single carrier networks. Indeed, in case of failure or out-of-SLA service delivery, the violating carrier should compensate its partner carriers or the end customer. Based on the information made available by the OAM tools, the carriers should agree on the root cause. Unfortunately, at present the existing standards do not have trusted mechanism to support these commercial issues. Furthermore, the out- of-service duration is a significant factor when calculating the compensation/penalty in case of failure. Yet, currently, each service provider measures the out-of-service duration independently; as a result, it is difficult to agree on the out-of-service duration and, as a consequence, on the amount of compensation. The existing standards for OAM in transport networks do not clearly address the above mentioned problems; therefore, in a multi-carrier environment, the following requirements may be specifically defined by considering that Inter-carrier OAM should address or reference how inter-region or inter-technology requirements are addressed. Technological inter- operability issues and inter-region OAM issues should be addressed separately to inter-carrier considerations. The requirements identified for the Inter-carrier OAM system are as follows: A. Inter-carrier OAM system SHOULD be supported by Maintenance Entities (MEs) that are handled by different operators (carriers). B. Inter-carrier OAM system SHOULD be able to discover the MEs involved in the operation and hence the corresponding network elements. M.Georgiades Expires 24 November 2012 [Page 9] INTERNET DRAFT Inter-Carrier OAM Requirements 24 November 2011 C. Inter-carrier OAM system SHOULD provide in-service reliable means to the network service providers (NSPs) to prove, in case of failure, which is the failing transit carrier or transit NSP etc. D. Inter-carrier OAM system SHOULD provide optional in-service notification messages that could be used to inform on-path service NSPs of other on-path NSPs service degradation. This includes for example any deviation from the SLA agreement and related parameters (Jitter, Packet Loss, Throughput etc.). E. Inter-carrier OAM system SHOULD provide reliable means to measure an NSP's out-of-service provisioning duration; such measurement could be agreed by all involved parties. F. Inter-carrier OAM system SHOULD provide means for confidentiality and privacy between involved carriers. G. Inter-carrier OAM system SHOULD have the option of disclosing information forwarded by transit NSPs that are not involved under the same inter-carrier OAM agreement. H. Inter-carrier OAM system MAY have the ability to inter-work with the PCE architecture and traffic engineering databases, aiming at improving reliability and accuracy in path computations, and performing correlation of OAM information for location and tracking of failures. I. Inter-carrier OAM system SHOULD work and react independently to the underlying transport layer technologies (transport technology agnostic) used e.g. Ethernet layer. J. Inter-carrier OAM system SHOULD react within a time frame agreed by the involved carriers. The time frame should be reasonable enough to restore their service in case of failure. 4 Summary The exiting OAM standards do not clearly address the specific needs of: inter-carrier, inter-region (inter-technology) as well as different layer defined OAM requirements such as on the network level, service level etc. This draft aimed to achieve this and focuses on the inter-carrier requirements only. The majority of these requirements were derived from the nature of service provisioning between different network service providers. OAM is an essential tool set for network operation and service provisioning, and in case of inter-carrier it can help to settle responsibility disputes in case of failures and performance M.Georgiades Expires 24 November 2012 [Page 10] INTERNET DRAFT Inter-Carrier OAM Requirements 24 November 2011 degradations. This document reviews the existing OAM standards, identifies gaps, and discusses new requirements for the inter domain and inter carrier scenarios. 5 Acknowledgements This draft has been produced by the following three projects which are funded by the European Union's Seventh Framework Programme (FP7/2007-2013): STRONGEST (FP7-ICT-247674); http://www.ict-strongest.eu/); ETICS (FP7-ICT-248567); http://www.ict-etics.eu/); MAINS (FP7-ICT-247706; http://www.ist-mains.eu/); 5.1 List of Contributors Michael Georgiades, Primetel, Cyprus; Filipo Cugini, CNIT, Italy; David Berechya, NSN, Israel; Oscar Gonzalez, TID (Telefonica), Spain; Nurit Sprecher, NSN, Israel; 6 References [RFC5860] Vigourex, M., Ward, D., Betts, M., Bocci, M., Busi, I., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, May 2010. [I.610] ITU-T Recommendation I.610, "B-ISDN operation and maintenance principles and functions", February 1999. [IEEE1] IEEE 802.3-2008, IEEE Standard for Information technology - Telecommunications and information exchange between systems--Local and metropolitan area networks--Specific requirements Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications. Institute of Electrical and Electronics Engineers, 2977 pages, ISBN: 9730738157979, December 2008. M.Georgiades Expires 24 November 2012 [Page 11] INTERNET DRAFT Inter-Carrier OAM Requirements 24 November 2011 [IEEE2] IEEE 802.1ag, "Virtual Bridged Local Area Networks - Amendment 5: Connectivity Fault Management, IEEE 802.1 Committee", December 2007. [MEFOAM] MEF, "Service OAM Requirements & Framework - Phase 1 Technical Specification, Metro Ethernet Forum", April 2007. [Y1710] ITU-T Recommendation Y.1710(2002), "Requirements for OAM Functionality for MPLS Networks", January 2001. [Y1730] Recommendation Y.1730, "Requirements for OAM functions in Ethernet based networks", January 2004. [Y1731] ITU-T Recommendation Y.1731 - OAM functions and mechanisms for Ethernet based networks, January 2006. [RFC5706] Harringhton, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009. [RFC4378] Allan, D. , Nadeau, T., A framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM), RFC4378, February 2006. Authors' Addresses Michael Georgiades Telecom Researcher (R&D) The Maritime Center, PrimeTel PLC, Omonia Avenue 141, 3045 Limassol, Cyprus Email1: michaelg@prime-tel.com Email2: m.georgiades@ieee.org Filippo Cugini CNIT National Lab of Photonic Networks Scuola Superiore Sant'Anna (SSSUP) via Moruzzi 1, 56124 Pisa, Italy Email: filippo.cugini@cnit.it David Berechya Research, Multi-Layer Networks and Resilience Nokia Siemens Networks 3 Hanagar St. M.Georgiades Expires 24 November 2012 [Page 12] INTERNET DRAFT Inter-Carrier OAM Requirements 24 November 2011 Hod Hasharon 45240, Israel Email: david.berechya@nsn.com Oscar Gonzalez Telefonica I+D Ramon de la Cruz, 82-84 Madrid, 28006 Email: ogondio@tid.es M.Georgiades Expires 24 November 2012 [Page 13]