Operations and Management Area Working Group D. King Internet-Draft Lancaster University Intended status: Informational M. Boucadair Expires: March 25, 2014 France Telecom S. Aldrin Huawei USA G. Mirsky Ericsson Mishael Wexler Huawei September 25, 2014 Use Cases and Requirements for Layer Independent OAM Management in multi-layer environments draft-king-opsawg-lime-multi-layer-oam-use-case-00 Abstract As operators deploy and operate multi-layer networks and diverse transport technologies, layer independent Operations, Maintenance & Administration Management (OAM) would be beneficial for monitoring and troubleshooting operations of network and service infrastructure. This document identifies and discusses the key use-cases and high- level requirements for layer independent Operations, Administration, and Maintenance management to facilitate operations and maintenance in multi-layer and multi-domain networks utilizing a wide variety of heterogeneous networking technologies. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on March 25, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. King, et al. Expires March, 2015 [Page 1] Internet-Draft OAM Use Cases July 2014 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 . . . . . . . . . . . . . . . . . . . . . . . .2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . .3 2.1. Conventions used in this document . . . . . . . . . . . .3 2.2. Acronyms and Abbreviations . . . . . . . . . . . . . . .3 3. Layer Independent OAM Management Use Cases . . . . . . . . .5 3.1. Multi-layer multi-region OAM Consolidation in the Management Plane . . . . . . . . . . . . . . . . . . . .5 3.2. Multiple layer OAMs stitching in different part of the network . . . . . . . . . . . . . . . . . . . . . . . . .6 3.3. Stitching OAM at layer requiring L4 to L7 service . . . .8 3.4. Multi-Region Overlay OAM Stitching . . . . . . . . . . .10 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . .11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . .12 6. Security Considerations . . . . . . . . . . . . . . . . . . .12 7. References . . . . . . . . . . . . . . . . . . . . . . . . .12 7.1. Normative References . . . . . . . . . . . . . . . . . .12 7.2. Informative References . . . . . . . . . . . . . . . . .12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .13 Contributor's Addresses . . . . . . . . . . . . . . . . . . . . .14 1. Introduction This document discusses use-cases for layer independent OAM management that would interface to multi-layer or multi-domain networks to cover various heterogeneous networking technologies. As operators and providers (e.g., network operators, data center operators, service providers, etc.) continue to deploy and operate multi-layer networks using a wide range of transport technologies, layer independent OAM Management for stitching different layer OAMs is desirable to minimise operational complexity and simplifying O&M (OAM and O&M are used as specified in [RFC6291]). This document discusses Layer Independent OAM in Multi-Layer Environment (LIME), and is intended to: o outline use cases for layer independent OAM management and highlight the issues encountered with existing OAM protocols; King, et al. Expires March, 2015 [Page 2] Internet-Draft OAM Use Cases July 2014 o discuss OAM requirements for when designing and deploying new technologies; o outline eixsting technologies to facilitate layer independent OAM management, including MEF work, ITU-T work, IETF related work; o discuss how OAM might be configured via a unified management interface: * Establishment of OAM Entities(e.g., MEG, ME,MIP,MEP) and Functions(e.g.,CC,CV) * Adjustment of OAM Parameters * Deleting OAM Entities o highlight a generic OAM Management model that may be applied to various OAM technologies: * Defining common objects and relationships model for various technologies * Defining a common set of methods/calls to use for the various functions * Defining a common set of attributes per object * Defining a common set of alarms and notifications Specific OAM technology models will augment the basic OAM management model defined by the LIME Group. o detail OAM fault management(e.g., fault location, path discovery) data model using layer independent OAM Management: * Propose means to help during service diagnosis; these means may rely on filtering information so that time recovery can be optimized. A typical example would be efficient root cause analysis that is fed with input from various layers. * Propose means that would help to optimize a network as a whole instead of the monolithic approach that is specific to a given layer. For example, investigate means that would help in computing diverse and completely disjoint paths, not only at the overlay but also at the underlay. o discuss the security model for layer independent OAM management: * Propose means to avoid leaking OAM information to no authorized entities, and to avoid altering OAM information exposed by each King, et al. Expires March, 2015 [Page 3] Internet-Draft OAM Use Cases July 2014 layer. * Propose means to ensure reliability of OAM information exposed by each layer. These requirements are not frozen; further discussion is required to target key issues and scope the work to be conducted within IETF accordingly. The problem statement and architecture is discussed in [LIME-PS]. 2. Terminology 2.1. Conventions used in this document 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 RFC2119 [RFC2119]. 2.2. Acronyms and Abbreviations LIME - Layer Independent OAM in Multi-Layer Environment OAM - Operations, Administration, and Maintenance O&M - OAM and Management ABNO -Application Based Network Operation MEG - Maintenance Entity Group [RFC6371] MEP - Maintenance Entity Group End Point [RFC6371] MIP - Maintenance Entity Group Intermediate Point [RFC6371] CC -Continuity Check [RFC7276] CV - Connectivity Verification [RFC7276] CFM -Connectivity Fault Management EFM - Ethernet In the First Mile BFD -Bidirectional Forwarding Detect LBM -Loopback Message LBR -Loopback Reply LTM -Linktrace Message King, et al. Expires March, 2015 [Page 4] Internet-Draft OAM Use Cases July 2014 LTR -Linktrace Reply OSS -Operation Support System NMS -Network Management System SFC -Service Function Chain [I-D.ietf-sfc-problem-statement] SF - Service Function [I-D.ietf-sfc-problem-statement] TES -Tenant End System [I-D.ietf-nvo3-framework ] NVO3 -Network Virtualization Overlay [I-D.ietf-nvo3-overlay- problem-statement] WAN -Wide Area Network VXLAN -Virtual eXtensible Local Area Network [RFC7348] NVGRE -Network Virtualization using Generic Routing Encapsulation [I-D.sridharan-virtualization-nvgre] PW -Pseudowire LSP -Label Switching Path MPLS -Multi-Protocol Label Switching 3. Layer Independent OAM Management Use Cases 3.1. Multi-layer multi-region OAM Consolidation in the Management Plane A multi-layer multi-region network will often require data traffic between two customer edges to be transported across two regions, as illustrated in figure 2. In this scenario the same domain and multiple layer OAMs(i.e.,PW OAM,end to end LSP OAM, segment LSP OAM) are used. For PW OAM is used at the customer level for monitoring the end-to -end connection between the two Provider edges(PEs), while end to end LSP OAM and segment LSP OAM is used at the provider level for monitoring the segment LSP and end to end LSP respectively. A segment is between MEPs and The OAM in each segment is independent of any other segment. King, et al. Expires March, 2015 [Page 5] Internet-Draft OAM Use Cases July 2014 +--------------------------------------------------+ | Carrier 1 | |+---------------------+ +---------------------+| || Region1 | | Region2 || +----+ || +----+ +-+ +----+ | | +----+ +-+ +----+|| +----+ | PE ------| PE --|P|--| PE ----------| PE ----|P|--| PE ------| PE | +----+ || +----+ +-+ +----+ | | +----+ +-+ +----+|| +----+ || | | || |+---------------------+ +---------------------+| +--------------------------------------------------+ End to end LSP OAM o----------D----------------------------------------D----------D Segment LSP Carrier 1 LSP OAM segment OAM o------------D-------------D-------------o-o--------o Carrier1 Region 1 Carrier1 Region 2 LSP OAM segment LSP OAM segment o----D-------o o-------D------o o Maintenance Endpoint(MEP) D Maintenance Intermediary point (MIP) Figure 1: Multi-Region Multi-Layer OAM With single OSS/NMS in the management plane, customized service diagnose can be provided, e.g., o initiating tests on any layer in the multi-layer network o initiating test on any segment of the end to end path o initiate test on end to end path o check end-to-end connectivity test results across a multi-layer network even when each layer runs a different technology. 3.2. Multiple layer OAMs stitching in different part of the network Figure 2 illustrates a multi-layer network in which data traffic between two access nodes is transported through access section between access node(AN) and aggregation node(AGG Node) and aggregation section between aggregation node and edge node and even core section from edge node to Internet or WAN. EFM OAM is used at the access section for monitoring the access connection between the access node and aggregation node, CFM OAM and IP OAM is used at the aggregation section for monitoring end to end connection between aggregation node and edge node. BFD is used at the core section for monitoring end to end connection from edge node to Internet or WAN. King, et al. Expires March, 2015 [Page 6] Internet-Draft OAM Use Cases July 2014 | | | | ----EFM---------CFM/IP-----------BFD---------| | | | | +---|----------|---+ | | | +----+ +-----+| | | | | AN | |AGG +---+ | | | +----+ |Node || | | | | +-----+| | +------+ +-----+ /-----\ +------------------+ | | Edge +---+Core |++|Internet| ---| Node | |Node | | | +------------------+ | +------+ +-----+ \-----/ | ------ |AGG || | | | AN | |Node +---+ | +----+ +-----+| | | +----+ +-----+| | | | AN | |AGG || | | +----+ |Node +---- +-------+ +-----+ /----\ | +-----+| | | Edge +--+Core |+-+| WAN || +------------------+ --- Node | |Node | | | +------------------+ | +-------+ +-----+ \----/ | +-----+| | | | | +----+ |AGG +---+ | | | | AN | |Node || | | | +----+ +-----+| | | +---|----------|---+ | | | | | | ----Access---Aggregation-| -----Core---------- | | | | Figure 2 With single OSS/NMS in the management plane, different layer OAM at the different part of the network can be stitching together to provide unified view for network problem reporting by consuming all status reports from the network, aggregating them, correlating them. In addition, a user who wishes to issue a IP Ping Command or use connectivity verification command in the Ethernet layer can do so in the same manner regardless of the underlying protocol or transport technology. This can be achieved by invoking IP Ping Command or connectivity verification command through uniform interface between management plane and data plane. Consider a scenario where an IP ping to Edge node B from Aggregation node A failed. Between AGG node A and Edge Node B there are IEEE 802.1 [IEEE-802.1Q] bridges a,b and c. Let's assume a,b and c are using [IEEE-802.1ag] CFM. IP layer Ping can be invoked using uniform interface between single OSS/NMS and AGG node A. Upon detecting IP layer ping failure, the user may wish to "go down" to the Ethernet layer and issue the corresponding fault verification (LBM/LBR) and fault isolation (LTM/LTR) tools, using the same uniform interface used by IP Layer Ping. King, et al. Expires March, 2015 [Page 7] Internet-Draft OAM Use Cases July 2014 3.3. Stitching OAM at layer requiring L4 to L7 service In Service Function Chain ([I-D.ietf-sfc-problem-statement]), the service packets are steered through a set of Service Function distributed in the network. Overlay technologies and other tunneling techniques can be used to stitch these Service Function Nodes in order to form end to end path (see Figure 3). +---------+ | Single | |----------------------| OSS/NMS ------------------------- | +---------+ | | | | ---------------------- | | /////-- --\\\\\ | | ///// \\\\\ | | //// |->SF1 SF2-+ SF3----+ +->Proxy-SF4 \\\\ | |/ | | ^ | ^ | | \| | V | | | | | +-------+ | +---+-+ | +-+---+ | | +-----+ +-----+ | SFC | |--| +<+ | |<- |->| | | | |Ingress|------ NE-a -------+NE-b +------- NE-c --------+NE-d | | Node | | | | | | | | | +-------+ +-----+ +-----+ +-----+ +-----+ \\\\ //// \\\\\ ///// \\\\\-- --///// ---------------------- SF OAM o o o o D SFC OAM o-------------D---D-----------D-------------D NVO3 OAM o---------------o----------------D----------D----------------o Link OAM o--o---o--o- o---o o--o--o--o o Maintenance Endpoint(MEP) D Maintenance Intermediary point (MIP) Layer7- SF1 --------------------------------------------------- Layer6------------------------F4 -------------------------------- Layer5------------ SF3------------------------------------------- Layer4---SF2 ---------------------------------- ----------------- Figure 3: Stitching OAM at layer requiring L4 to L7 service King, et al. Expires March, 2015 [Page 8] Internet-Draft OAM Use Cases July 2014 In figure 3, Link OAM is used between any two adjacent SFs hosted in the same service node in the SFC layer or between a SF and the service node hosting that SF. NVO3 OAM is used between SFC ingress node and NVO3-enabled Network element or any two NVO3-enabled network element in the SFC domain. SFC OAM is used between a set of Service Functions belong to the same service function chain in the SFC domain. SF OAM is used between SF and SF Controller. When the service packet enters into the network, OAM information needs to be imposed by ingress node of the network into the OAM packet (e.g., packet header extension or TLV extension in the overlay header) and pass through the network in the same path as the service traffic and processed by a set of Service Functions that are hosted in Service Nodes and located in different layers requiring L4-L7 service. When any Service Nodes or any service segment between two Service Nodes fails to deliver user traffic, there is a need to provide a tool that would enable users to detect such failures (e.g., fault element in the path), and a mechanism to isolate faults. In case of several SFs co-located in the same Service Node, the packet is processed by all SFs in the Service Node, Once the packet is successfully handled by one SF, the packet is forwarded to the next SF that is in the same Service Node. When the packet leaves the network, the OAM information needs to be stripped out from the packet. To provide unified view of OAM information from different layers and different segment of the Service Function Path, these OAM information needs to gathered from various layer using different encapsulation and tunneling techniques and abstracted and provided to the management application via the uniform management interface. As indicated in [I-D.boucadair-sfc-requirements], the following OAM functions are to be supported: o Support means to verify the completion of the forwarding actions until the SFC Border Node is reached (see Section 3.4.1 of [RFC5706]). o Support means to ensure coherent classification rules are installed in and enforced by all the Classifiers of the SFC- enabled domain. o Support means to correlate classification policies with observed forwarding actions. King, et al. Expires March, 2015 [Page 9] Internet-Draft OAM Use Cases July 2014 o Support in-band liveliness and functionality checking mechanisms for the instantiated Service Function Chains and the Service Functions that belong to these chains. Other service diagnosis and troubleshooting requirements are discussed in [I-D.boucadair-sfc-requirements]. 3.4. Multi-Operator OAM Stitching Multi-operator networks can be abstracted, virtualized and shared by several tenants. A tenant has an end-to-end view of its virtual network. Figure 5 illustrates an example of multi-layer multi-operator network in which data traffic between two tenant systems is transported across three operators. +--------+ -----------------------------+ Tenant +----------------------------- | | | | | +--------+ | | | | | + - - - - - - + | | | Abstraction | | | - - - --- - - - - | Layer (opt.)| - - - - - - - - | | | + - - - - - - + | | | | | | | | +--------+ +--------+ +--------+ | | + Single + + Single + + Single + | | |OSS/NMS | |OSS/NMS | |OSS/NMS | | | +--------+ +--------+ +--------+ | | --------- --------- --------- | | /// \\\ /// \\\ /// \\\ | | / \ / \ / \ | | | | | | | | | +-----+ +-----+ +-----+ +----+ +-----+ +-----+ | A1 | | A2 | | B1 | | B2 | | C1 | | C2 | +-----+ +-----+ +-----+ +----+ +-----+ +-----+ | | | | | | \ / \ / \ / \\\ /// \\\ /// \\\ /// --------- --------- --------- Oper A Oper B Oper C o-------------D----------D---------------D----D-----------------o Figure 4: Multi-Operator OAM Stitching Each operator is using a different management system and is handling only a segment of the whole end-to-end service. Each operator can also use a different technology to transport the clients over its King, et al. Expires March, 2015 [Page 10] Internet-Draft OAM Use Cases July 2014 segment. Within one operator region, multi-layers acn be used, e.g. IP over WDM to transport L3VPN service. The tenants has to view an end-to-end OAM model via abstraction of each region and/or using abstraction layer between tenants and the OSS/NMSs. 4. Requirements This section identifies high-level requirements to fulfill layer independent OAM management in Multi-layer Environment to support various use cases discussed in the previous sections. o The interfaces between the management entity and each Managed device in one administrative domain SHOULD support standards- based abstraction with a common information/data model. o The management entity should be able to create a single unified view of OAM information that is common to various layers, various segment of the same domain. o The management entity should provide an unified management interface for multiple OAM technologies that will expose a common set of management interface capabilities for different OAM technologies (e.g. Continuity Check(CC),Connectivity Verification(CV)). The management interface implementation will convert the defined common management capabilities to the OAM technology specific operations. o The management entity should Model OAM operations management and represent OAM information and mechanisms in the same way using YANG at the management plane to provide consistent configuration, reporting, and presentation for the OAM mechanisms. Specific OAM technology models will augment the basic OAM management model defined by the LIME Group. o The following capability for layer independent OAM management entity should be supported: * Support customized service diagnostic. * Support diagnose the availability of a end-to-end path. * Support diagnose the availability of a segment Path that is sub-path of end to end path. * Support verification on the correct value of Path ID between any two pair of overlay nodes or any two pair of service nodes. King, et al. Expires March, 2015 [Page 11] Internet-Draft OAM Use Cases July 2014 * Support out-band liveliness and functionality checking mechanisms for the overlay node or service node. 5. IANA Considerations This memo includes no request to IANA. 6. Security Considerations TBD. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. 7.2. Informative References [I-D.boucadair-sfc-requirements] Boucadair, M., Jacquenet, C., Jiang, Y., Parker, R., Pignataro, C., and K. Kengo, "Requirements for Service Function Chaining (SFC)", draft-boucadair-sfc- requirements-05 (work in progress), July 2014. [I-D.ietf-sfc-problem-statement] Quinn, P. and T. Nadeau, "Service Function Chaining Problem Statement", draft-ietf-sfc-problem-statement-10 (work in progress), August 2014. [IEEE-802.1Q] IEEE 802.1Q-2011, "IEEE standard for local and metropolitan area networks: Media access control (MAC) bridges and virtual bridged local area networks", August 2011. [IEEE-802.1ag] IEEE 802.1ag-2007, "IEEE Standard for Local and Metropolitan Area Networks Virtual Bridged Local Area Networks Amendment 5: Connectivity Fault Management", December 2007. [LIME-PS] Taylor, T. and Q. Wu, "Problem Statement and Architecture for Layer-Independent OAM in Multi-Layer Environment", ID draft-edprop-opsawg-multi-layer-oam-ps-01, (work in progress). [RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, November 2009. King, et al. Expires March, 2015 [Page 12] Internet-Draft OAM Use Cases July 2014 [RFC6291] Andersson, L., Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", RFC 6291, June 2011. [RFC6371] Busi, I. and D. Allan, "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, September 2011. [RFC7276] Mizrahi, T. et al., "An Overview of Operations, Administration, and Maintenance (OAM) Tools," June 2014 [RFC7348] [I-D.sridharan-virtualization-nvgre] Sridharan, M., Greenberg, A., Venkataramaiah, N., Wang, Y., Duda, K., Ganga, I., Lin, G., Pearson, M., Thaler, P., and C. Tumuluri, "NVGRE: Network Virtualization using Generic Routing Encapsulation", draft-sridharan- virtualization-nvgre-05 (work in progress). Authors' Addresses Daniel King Lancaster University UK Email: d.king@lancaster.ac.uk Mohamed Boucadair France Telecom Rennes 35000 France Email: mohamed.boucadair@orange.com Sam Aldrin Huawei Technologies USA 2330 Central Expressway NSanta Clara, CA 95051 USA Email: aldrin.ietf@gmail.com Greg Mirsky Ericsson Email: gregory.mirsky@ericsson.com King, et al. Expires March, 2015 [Page 13] Internet-Draft OAM Use Cases July 2014 Mishael Wexler Huawei Riesstr. 25 Munich 80992 Germany Email: mishael.wexler@huawei.com Contributors' Addresses Qin Wu Huawei 101 Software Avenue, Yuhua District Nanjing, Jiangsu 210012 China Email: bill.wu@huawei.com King, et al. Expires March, 2015 [Page 14] Internet-Draft OAM Use Cases July 2014