Problem Statement and Architecture for Transport-Independent Multiple Layer OAM
draft-ww-opsawg-multi-layer-oam-02.txt

Abstract

Operations, Administration, and Maintenance (OAM) mechanisms are critical building blocks in network operations that are used for service assurance, fulfillment, or service diagnosis, troubleshooting, and repair. The current practice is that many technologies rely on their own OAM protocols that are exclusive to a given layer. There is little consolidation of OAM in either data plane or management plane nor well-documented inter-layer OAM operations. Vendors and Operators dedicate significant resources and effort through the whole OAM life-cycle each time when a new technology is (to be) introduced. This is even exacerbated when dealing with integration of OAM across multiple technologies.

This document describes the problem space and defines an architecture for the generic and integrated OAM with a focus of multi-layer and cross-layer considerations.

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 January 5, 2015.

Copyright Notice

Copyright (c) 2014 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
• 2. Terminology
• 2.1. Acronyms and Abbreviations
• 3. Problem Statement
• 3.1. Use of Existing Protocols
• 3.2. Strong Technology dependency
• 3.3. Weakness of Cross-Layer OAM
• 3.4. Lack of OAM above Layer 3
• 3.5. Issues of Abstraction
• 3.6. Issue of OAM Information Gathering from Layers Covering Heterogeneous Network Technologies
• 3.6.1. Focus on Service Function Chaining
• 4. Architecture Overview
• 5. Existing Work
• 6. Architectural Consideration
• 6.1. Basic Components
• 6.1.1. Overlay OAM
• 6.1.2. OAM at the top of Layer 3
• 6.2. OAM Functions in the Data Plane
• 6.2.1. Continuity Check
• 6.2.2. Connectivity Verification
• 6.2.3. Path Discovery
• 6.2.4. Performance Measurement
• 6.2.5. Protection Switching Coordination
• 6.2.6. Alarm/defect Indication
• 6.2.7. Maintenance Commands
• 6.3. OAM in Management Plane
• 7. Building on Existing Protocols
• 8. Scoping Future Work
• 9. Manageability Considerations
• 10. Security Considerations
• 11. Acknowledgements
• 12. References
• 12.1. Normative References
• 12.2. Informative References
• Authors' Addresses

1. Introduction

Operations, Administration, and Maintenance (OAM) mechanisms being understood and used in context of RFC 6291 [RFC6291] are critical building blocks in network operations that are used for service assurance, fulfillment, or service diagnosis, troubleshooting, and repair. The key foundations of OAM and its functional roles in monitoring and diagnosing the behavior of networks have been studied at OSI layers 1, 2 and 3 since a while. As a reminder, OAM functions are used in many management applications for various objectives such as (i) failure detection, (ii) reporting the defect/ failure information, (iii) defect/failure localization, (iv) performance monitoring, and (v) service recovery.

The current practice that consists in enabling OAM techniques for each layer has shown its limits; this is a need for cross-layer and inter-layer OAM considerations [RFC7276]. This need for inter-layer OAM is motivated by the need to achieve: network optimization, efficient enforcement of TE (Traffic Engineering) techniques including ensuring path diversity at distinct layers or computing completely disjoint paths at several layers, fine-grain tweaking, ease of root cause analysis, ability to maintain a network-wise visibility in addition to layer-specific one, etc.

It is worth to mention also that there are two restrictions for multi-layer structure as discussed in [RFC7276]:

• Each layer has its own OAM protocol, OAM should not cross layer boundaries.
• Each layer OAM used at different level of hierarchy in the network.

Moreover, there is little consolidation of OAM in either data plane or management plane. Vendors and operators dedicate a lot resources and effort through the whole OAM life-cycle each time a new technology is (to be) introduced. Integration of OAM across multiple technologies in either data plane or management plane is extremely difficult to achieve.

When operating networks with more than one technology, maintenance and troubleshooting are achieved per technology and per layer, operation process can be very cumbersome since OAM is not defined to cross layer boundaries. Another challenge is presented by use of different technologies and corresponding OAM on the same layer of adjacent network domains. Interworking between different OAM often not defined and are left to proprietary solutions. In many cases when keeping network complexity down and simplifying OAM is needed, it is desirable to have a generic and integrated OAM to cover heterogeneous networking technologies.

This document defines the problem space and describes an architecture for the generic and integrated OAM in the multi-layer and multi-domain networks. In particular, it outlines the problems encountered with existing OAM protocols and their impact on introduction of new technologies (see Section 3).

This document covers the following:

• Data plane OAM consolidation by looking at the common active OAM functions (including, Connectivity Verification (CV), Path Verification and Continuity Checks (CC), Path Discovery, Performance Measurement) necessary to monitor and diagnose a network;
• Management plane consolidation by interacting with data plane OAM and abstracting OAM information common to different layer via uniformed interface.

2. Terminology

This document defines the following terms:

Transport Independent Multi-Layer OAM:

In an multi-layer network, transport independent OAM is OAM that can be deployed independent of media, data protocols, and routing protocols It denotes the ability to exchange OAM information across layers and domains between nodes along forwarding path, and gather OAM information that are common to different layers and expose it to the management application through a unified interface. These aspects are not specific to a given transport technology.

OAM function:

Refers to the atomic building blocks of OAM; an OAM function defines an OAM capability (See section 2.2.3 of [RFC7276]).

OAM protocol:

Refers to a protocol used for implementing one or more OAM functions (See section 2.2.3 of [RFC7276]).

OAM tool:

Denotes a specific means of applying one or more OAM functions. An OAM protocol can be an OAM tool. An OAM tool can use a set of OAM protocols or a set of protocols that are not strictly OAM related (See section 2.2.3 of [RFC7276]).

OAM packet:

Refers to a packet generated at Maintenance Point using an OAM protocol. An OAM packet, which carries OAM information, is usually forwarded through the same route/path as the data traffic and receive the same (forwarding) treatment.

Maintenance Domain (MD):

Refers to the part of a network where OAM function is performed (initiated).

Maintenance Point (MP):

Is a generic functional entity that is associated with a particular MD, defined at a specific layer of a network and can initiate and/or react to OAM packets.

Maintenance Endpoint (MEP):

Is an endpoint MP that initiates OAM packets and responds to them.

Maintenance Intermediary Point(MIP):

In between MEPs, there are zero or more intermediate points, called Maintenance Intermediary Point. A Maintenance Intermediary Point (MIP) is an intermediate MP that does not generally initiate OAM packets but is able to respond to OAM packets that are destined to it.

Maintenance Association (MA):

The relationship between a set of MEPs to which maintenance and monitoring operations apply.

Network Element (NE):

Denotes a physical or virtual network device/function that connects directly to the network. NE can host MPs and provide network connectivity to one or many MPs.

2.1. Acronyms and Abbreviations

• CC - Continuity Check
• CV - Connectivity Verification
• SNMP - Simple Network Management Protocol
• NETCONF - Network Configuration
• ETH - Ethernet
• APS - Automatic Protection Switching
• LT - LinkTrace
• RDI - Remote Defect Indication
• AIS - Alarm indication Signal
• OWAMP - One Way Active Measurement Protocol
• TWAMP - Two Way Active Measurement Protocol
• CFM - Connectivity Fault Management

3. Problem Statement

OAM mechanisms are usually oriented toward a single network technology or a single layer. Each technology or layer has its best suited OAM tools. Some of them providing rich functionality rely on the capabilities of one protocol, while the others provide each function with a different protocol; In the current situation, there is little, or no re-use, of software and hardware for each OAM protocol.

Integration of OAM across multiple technologies is extremely difficult. Vendors and operators waste a lot through the whole OAM life-cycle when a new technology is introduced:

• (1) Design and development: For every new protocol there is a need to invest in complete life-cycle (i.e.,the design and development of data, control and management planes). In some cases, even adding a single OAM function requires the above complete life-cycle.
• (2) Operation and Maintenance: There is a need to re-train operation people for almost every newly introduced technology or feature. The above causes a slow time-to-market and a waste of time and effort for any new technology and/or OAM function.

Specifically, in Service Function Chaining environment, every Service Function may operate at a different layer and may use different encapsulation and tunneling techniques. When taking into account virtualization related technologies, the number of encapsulation and tunneling options increase even more. Still, end-to-end service OAM mechanisms and information exchanges between Service Functions should be provided to operate and maintain the network as a whole. This requires a generic toolkit that can provide all necessary tools in context of multi-technology, multi-layer, physical and virtual environments.

A particular problem is how OAM information at different layer is made available to a management application for use and learnt via the unified management interface. For example, in the case of an multi- layer network, OAM information needs to be imposed to the packet and injected into the network and at last abstracted from various layers and expose them to the management application.

3.1. Use of Existing Protocols

OAM information resides at each layer and may currently be exchanged at each network layer in a domain by using various encapsulation technologies at the Layer 2 & Layer 3 levels. OAM information may be gathered and exported from a domain (for example, northbound) using SNMP [RFC3411]or NETCONF/YANG [RFC6241].

It is desirable that a solution to the problem described in this document does not require the implementation of a new, network-wide protocol or introduce a shim layer to carry OAM information. Instead, it would be advantageous to make use of an existing protocols or functionalities that are commonly implemented and are currently deployed in operational networks. This has many benefits in network stability, time to deployment, and operator training.

It is recognized, however, that existing protocols or functionalities are unlikely to be immediately suitable to this problem space without some protocol extensions. Extending protocols must be done with care and with consideration for the stability of existing deployments. In extreme cases, when there is a lack of functionality, although similar mechanisms exist in other technologies, a new protocol can be preferable to a "messy" hack of an existing protocol.

3.2. Strong Technology dependency

OAM protocols are relying heavily on the specific network technology they are associated with. For example, ICMP, LSP Ping are using different network technologies but provide the same OAM functionality, i.e., Path Discovery. Another example is BFD,LSP Ping are using different network technologies but provide the same functionality, i.e., Continuity Verification. Figure 1 shows common OAM functionalities shared by various existing IETF OAM protocols.

|--------+------------+--------------+--------------+------------+
|        |Continuity  |  Connectivity|    Path      | Performance|
|        |  Check     |  Verification|  Discovery   | Measurement|
+--------+------------+--------------+--------------+------------+
|        |            |              |              |-Delay      |
| ICMP   | Echo(Ping) |              |  Traceroute  |-Loss rough |
|        |            |              |              | measurement|
+--------+------------+--------------+--------------+------------+
|        |  BFD       |              |              |            |
| BFD    | Control    | BFD Control  |              |            |
|        | /Echo      |              |              |            |
+--------+------------+--------------+--------------+------------+
| LSP    |            |              |              | - Delay    |
| Ping   |            |   Ping       |  Traceroute  | - Packet   |
|        |            |              |              |    Loss    |
+--------+------------+--------------+--------------+------------+
|        |            |              |              | -OWAMP     |
| IPPM   |            |              |              | -TWAMP     |
|        |            |              |              |            |
|--------+------------+--------------+--------------+------------+
| MPLS-TP|            |              |              |            |
| OAM    |     CC     |   CV         |  Traceroute  | -Delay     |
|        |(use of BFD)|(use of BFD)  |              | -Packet    |
|        |            | or LSP Ping) |              |   Loss     |
+--------+------------+--------------+--------------+------------+
            

    Service                  +-------------------+
---- Plane                   |     Customer      |
  ^  Layer                   +-------------------+
  |
  |                  +-------------+          +-------------+
  V                  |  Management |          |  Management |
 ---Management       |   Entity    |          |   Entity    |
  ^   Plane          +-------------+          +-------------+
  |   Layer
  |
  |
  |     |----------------------------+    +---------------------+
  |     |Maintenance Domain 1        |    |Maintenance Domain 2 |
  |     |                            |    |                     |
  |     |                            |    |                     |
  |   NE|        NE       NE       NE|    |      NE          NE |
  V  +-----+    +-----+  +-----+    +------+     +-----+     +--+--+
---- | MEP +----+ MIP +--| MIP +----|  MEP +-----| MIP +-----+ MEP |
     +-----+    +-----+  +-----+    ++----++     +-----+     +-----+
    Data Plane                       |    |                     |
      Layer                          |    |                     |
        +----------------------------+    +---------------------+