[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-edprop-opsawg-multi-layer-oam-ps

Operations and Management Area Working Group                       Q. Wu
Internet-Draft                                                 M. Wexler
Intended status: Informational                                    Huawei
Expires: December 31, 2014                                  M. Boucadair
                                                          France Telecom
                                                               S. Aldrin
                                                              Huawei USA
                                                               G. Mirsky
                                                                Ericsson
                                                                 P. Jain
                                                          Nuage Networks
                                                           June 29, 2014


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

Abstract

   Operations, Administration, and Maintenance (OAM) mechanismsare
   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



Wu, et al.              Expires December 31, 2014               [Page 1]


Internet-Draft               Multi-Layer OAM                   June 2014


   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 December 31, 2014.

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



Wu, et al.              Expires December 31, 2014               [Page 2]


Internet-Draft               Multi-Layer OAM                   June 2014


     6.3.  OAM in Management Plane . . . . . . . . . . . . . . . . .  14
   7.  Building on Existing Protocols  . . . . . . . . . . . . . . .  15
   8.  Scoping Future Work . . . . . . . . . . . . . . . . . . . . .  15
   9.  Manageability Considerations  . . . . . . . . . . . . . . . .  16
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  16
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  16
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  16
     12.2.  Informative References . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

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]:

   o  Each layer has its own OAM protocol, OAM should not cross layer
      boundaries.

   o  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



Wu, et al.              Expires December 31, 2014               [Page 3]


Internet-Draft               Multi-Layer OAM                   June 2014


   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:

   o  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;

   o  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 :



Wu, et al.              Expires December 31, 2014               [Page 4]


Internet-Draft               Multi-Layer OAM                   June 2014


      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 whereOAM 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.

   Network Element (NE) :





Wu, et al.              Expires December 31, 2014               [Page 5]


Internet-Draft               Multi-Layer OAM                   June 2014


      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




Wu, et al.              Expires December 31, 2014               [Page 6]


Internet-Draft               Multi-Layer OAM                   June 2014


      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




Wu, et al.              Expires December 31, 2014               [Page 7]


Internet-Draft               Multi-Layer OAM                   June 2014


   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 OAM protocols.

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

                Figure 1.Examples of OAM tools

3.3.  Weakness of Cross-Layer OAM

   Troubleshooting is cumbersome due to protocol variety and lack of
   multi-layer OAM.  Usually OAM messages should not cross layer
   boundaries.  Each of the service, network and transport layers
   possesses its well-discernable and native OAM stream.  In addition,
   OAM messages should not be leaked outside of a management domain



Wu, et al.              Expires December 31, 2014               [Page 8]


Internet-Draft               Multi-Layer OAM                   June 2014


   within a layer, where a management domain is governed by a single
   business organization.  When having networks with more than one
   technology, maintenance and troubleshooting are done per technology
   and layer.

   These rules could in some cases ease the understanding in which
   technology the operation is done or fault is located.  In some cases,
   when one layer OAM fails, it may be desirable to drop down to the
   another layer OAM and issue the corresponding OAM command, using the
   same APIs, if OAM in multiple layers can be supported.  However, in
   most cases switching tools and layers in the same operation process
   is cumbersome and not serving the main idea - to find the root cause
   location.  It would be very helpful to have a generic mechanisms that
   is end to end basis, allow management application interact with data
   plane OAM and can ping IPv4 host by an IPv6 source or having one tool
   to troubleshoot combined IP, MPLS, Ethernet, GRE and VXLAN network.

   In Service Function Chaining environment, it is necessary to provide
   end-to-end OAM across certain or all entities and involving many
   layers.  Inter-layer OAM considerations are key in an SFC context
   because problems may occur at the network layer or at the service
   chaining layer.

3.4.  Lack of OAM above Layer 3

   The Layer 2/3 OAM protocols are quite rich in their functionality,
   well defined, standardized and heavily used.  In the last years a lot
   of work was conducted to consider maintenance domains and levels in
   order to better handle the issues of technology re-use, smooth
   interoperability and interworking between domains.

   The above mechanisms are not defined for the technologies above Layer
   3.  Therefore, in the SFC environment where a Service Function
   Chaining is composed by a set of Service Functions, but providing an
   end-to-end chain or path from a source to destination in a given
   order [I.D-ietf-sfc- problem- statement], no standard exists as a
   reference for OAM since when the service packets is steered through a
   set of service nodes distributed in the network, each service node
   may act at different layers above layer 3.

3.5.  Issues of Abstraction

   In multi-layer network, OAM functions are enabled at different layers
   and various OAM information needs to be gathered from various layers.
   Without multi-layer OAM in place, it is hard for management
   applications to understand what information at different layers
   stands for.  One possible solution to these issues is to abstract the
   OAM information shared across layers, i.e., using the same tool or



Wu, et al.              Expires December 31, 2014               [Page 9]


Internet-Draft               Multi-Layer OAM                   June 2014


   API to activate the OAM functions at different layers and retrieve
   the results.

   The challenge is to abstract in a way that retains as much useful
   information as possible while filtering the data that is not needed
   to be leaked to other layers.  An important part of this effort is a
   clear understanding of what information is actually needed.

3.6.  Issue of OAM Information Gathering from Layers Covering
      Heterogeneous Network Technologies

   In SFC, the service packets are steered through a set of service
   nodes distributed in the network.  In the NVO3 network, the data
   packet may also traverse a set of overlay nodes distributed in the
   network.  Overlay technologies or other tunneling technologies can be
   used to stitch these service nodes or overlay node in order to form
   end to end path.

   When any overlay Segment or segment of service chain fails to deliver
   user traffic, there is a need to provide a tool that would enable
   users to detect such failures, and a mechanism to isolate faults.  It
   may also be desirable to test the data path before mapping user
   traffic to the Overlay Segment or segment of service chain.

3.6.1.  Focus on Service Function Chaining

   When the service packets are steered through a set of service nodes
   distributed in the network, each service node may work at different
   layer above layer 3 and may have several SFs collocated with itself.
   When OAM mechanism is applied, it is necessary to allow OAM packet To
   be exchanged between these service nodes or service function at
   different layers.  When Service functions that are part of the SFC
   doesn't support OAM capability(e.g., an SFC-unaware service
   function), service node should be responsible for monitoring and
   diagnosing and reporting service availability to the service
   function.  It is more desirable to allow a service function register
   with service node.  Either service function reports status to service
   node or service node performs live check of the service function.

   In addition, service functions usually don't have Layer 2-3
   switching/routing capability and therefore are not aware of any OAM
   function at Layer 2-3.  Also when there are no OAM functions at
   service Layers above layer 3, it is hard to identify layer that can
   be used to gather OAM information when it comes to a fault situation
   or degradation of performance.  For example, when a data packet is
   transmitted from one service function to another service function and
   the data packet may be lost between two service functions or
   discarded by either of them.  Consider when two service functions are



Wu, et al.              Expires December 31, 2014              [Page 10]


Internet-Draft               Multi-Layer OAM                   June 2014


   embedded in (associated with) two different service nodes, how to
   detect the fault between them and how to isolate problem to that
   layer?

   Editor's Note: Section 3.6.1 is too specific.  This text can be
   presented as an example to illustrate a problem not a problem per se
   or moved to a use case draft.

4.  Architecture Overview

   Figure 2 shows the reference architecture for Layering OAM.  This
   reference architecture assumes that

   o  Any network element can use different technologies and
      corresponding OAM on the same layer at the boundary of two
      adjacent domains

   o  Any two network element may provide service delivery at different
      layer

   o  Management entity can manage network devices in more than one
      maintenance domains.

   In this architecture, three layers are defined:

      M1: "Data Plane layer"

      M2: "Management Plane layer"

      M3: "Service Plane layer"

   In the M1 layer, a typical network can be partitioned into several
   domains.  Each domain has at least two MEPs and none or one to more
   MIPs.  MEP is a maintenance functional entity that is implemented
   into a Network Element either at the maintenance domain boundary or
   in the maintenance domain and can generate, send and receive OAM
   packets.  MIP is a maintenance functional entity that is implemented
   into a Network Element in the maintenance domain and can forward OAM
   packets.  Either MEP or MIP may be at different layer and use various
   different encapsulating protocols.

   The M2 contains the interface which management entity uses to manage
   individual network devices.  In this document, we further require
   management entities to use this interface as uniform interface (API
   and or UI) to gather OAM information from MEP and MIP in the network
   devices(either physical or virtual entity) and execute transactions
   or operations on MEP and MIP across domains, layers and vendors.
   Protocols that can be used to manipulate the configuration of a



Wu, et al.              Expires December 31, 2014              [Page 11]


Internet-Draft               Multi-Layer OAM                   June 2014


   network device include SNMP [RFC1157], Command Line Interfaces,
   NETCONF [RFC6241], and other protocols.

   On the M3 layer, there is a uniform interface (API and/or UI) that
   covers all the managed devices and can execute network-wide
   transactions.  This layer allows applications and operators to
   execute configuration, monitoring and action tasks across multiple
   network devices, from a mix of domains, layers, vendors.  Still the
   abstraction level is that of the network elements themselves, so
   whatever configuration, status, actions and notifications they
   provide, that is what you get here, but without having to worry about
   the location and the protocol to reach the device.

       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                          |    |                     |
           +----------------------------+    +---------------------+

        Figure 2 Architecture for Layering OAM in the management plane

   An example of service-specific that depicts OAM layers can be found
   in [RFC4176] (L3VPN case).

5.  Existing Work

   The following discuss related IETF work and is provided for
   reference.  This section is not exhaustive, rather it provides an
   overview of few initiatives focusing on the pain-points of OAM:





Wu, et al.              Expires December 31, 2014              [Page 12]


Internet-Draft               Multi-Layer OAM                   June 2014


   1.  [I-D.tissa-netmod-oam] is an important work that creates a YANG
       unified data model for OAM that is based on IEEE CFM model.  This
       model may be used also for IP OAM functionality.  This effort is
       focused on the management plane of OAM and should be complemented
       by an accompanying data-plane and/or control-plane work.  It may
       require also some extensions to address wider variety of
       functions and technologies.

   2.  Several contributions conducted in the past years, had tried to
       address new technologies using existing mechanisms.  [I-D.jain-
       nvo3-overlay- oam] and MPLS-TP OAM documents are only examples
       for such efforts.

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

   Many OAM functions may require protocol extensions or new protocol
   development to meet the transport requirements.  In the existing OAM
   tools, Some of them providing rich functionality in one protocol,the
   other providing each function with a different protocol and each
   technology is developed independently.

   To consolidate OAM in the data plane, the OAM in multi-layer
   Environment is expect to support the following common OAM functions
   used in OAM-related standards.  These functions are used as building
   blocks in the data plane OAM standards described in this document.

6.2.1.  Continuity Check

   This type of mechanisms check that the monitored layer and/or entity
   are alive and providing path from specific point(s) to other
   point(s).  Some examples are IP Ping, BFD [RFC5880] and ETH CC.

6.2.2.  Connectivity Verification

   Verifying that the actual connection is consistent with the required
   connection and no misconnection occurred.  Some examples are IP Ping,
   and ETH loopback.






Wu, et al.              Expires December 31, 2014              [Page 13]


Internet-Draft               Multi-Layer OAM                   June 2014


6.2.3.  Path Discovery

   Used to discover the path that specific service traverses in the
   network.  Some examples are LSP Traceroute, IP Traceroute and ETH-LT/
   linktrace.

6.2.4.  Performance Measurement

   A function that monitors the performance parameters of a network
   entity.  Such parameters could be Delay, Delay-variation, loss,
   availability of services and class of services.  Examples are
   TWAMP[RFC5357]/ OWAMP[RFC4656] and Y.1731,MPLS Loss and Delay
   Measurement [RFC6374].

6.2.5.  Protection Switching Coordination

   A function that is used to signal protection switching states and
   commands.  Examples are ETH APS messages and MPLS-TP Protection
   Switching Coordination OAM [RFC6378].

6.2.6.  Alarm/defect Indication

   A function that is used to indicate that a failure occurred
   downstream or upstream within a connection/service.  Used also to
   trigger fast protection or to suppress alarms.  Examples are ETH AIS
   and ETH RDI, MPLS-TP RDI [RFC6428].

6.2.7.  Maintenance Commands

   A function that is used to signal a maintenance state or command
   within a connection/service.  Examples can be ETH Lockout.

6.3.  OAM in Management Plane

   Management systems play an important role in configuring or
   provisioning OAM functionality consistently across all devices in the
   network, and for automating the monitoring and troubleshooting of
   network faults.  However OAM is not provision.  In general,
   provisioning is used to configure the network to provide new
   services, whereas OAM is used to keep the network in a state that it
   can support already existing services.

   As we know each layer has its own OAM protocols.  OAM can be used at
   different levels of hierarchy in the network to form a multi-layer
   OAM solution [RFC7276].  To support multi-layer OAM covering various
   heterogeneous transport technologies, the OAM in the management needs
   to be consolidated as follows:




Wu, et al.              Expires December 31, 2014              [Page 14]


Internet-Draft               Multi-Layer OAM                   June 2014


   o  OAM information needs to be abstracted that are common to
      different layer and different domain.

   o  Support customized OAM service, e.g., customized service diagnose.

   o  OAM information is provided to management entity from managed
      device via a uniform interface (API and/or UI)

   o  Sets up MD MEP and MIP in the network provision phase

   o  Enables basic OAM functionality(e.g., enable the origin of ping
      and trace packets or configure Connectivity Fault Management
      (CFM)) on the managed devices in the service activation phase.

   The different OAM tools may be used in one of two basic types of
   activation:

   o  Proactive activation - indicates that the tool is activated on a
      continual basis, where messages are sent periodically, and errors
      are detected when a certain number of expected messages are not
      received.

   o  On-demand activation - indicates that the tool is activated
      "manually" to detect a specific anomaly.

7.  Building on Existing Protocols

8.  Scoping Future Work

   This section includes a set of candidate items for activities to be
   conducted within IETF.

   These objectives are not frozen; further discussion is required to
   target key issues and scope the work to be conducted within IETF
   accordingly.

   Candidate investigation items are listed below:

   o  Understand and discuss situations where an OAM protocol can be
      tuned and optimized for a specific data plane.

   o  OAM consolidation in the data plane:

      *  Exchange OAM information at the service layer atop of layer 3.

      *  Deployed over various encapsulating protocols, and in various
         medium types




Wu, et al.              Expires December 31, 2014              [Page 15]


Internet-Draft               Multi-Layer OAM                   June 2014


   o  OAM consolidation in the management plane:

      *  Abstract OAM information common to different layers.

      *  Expose OAM information via unified interface to management
         entities, independently of the layer they belong to.

      *  Discuss how information gathered from various layers can be
         correlated for the sake of network operations optimization
         purposes.

      *  Propose means to help during service diagnosis; these means may
         rely on filtering information to be leaked to other layers 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
         layer 3 but also at the physical layer.

9.  Manageability Considerations

10.  Security Considerations

   Security considerations are not addressed in this problem statement
   only document.  Given the scope of OAM, and the implications on data
   and control planes, security considerations are clearly important and
   will be addressed in the specific protocol and deployment documents.

11.  Acknowledgements

   The authors would like to thank Romascanu, Dan, Tissa Senevirathne
   for their valuable reviews and suggestions.

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

   [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.




Wu, et al.              Expires December 31, 2014              [Page 16]


Internet-Draft               Multi-Layer OAM                   June 2014


   [RFC7276]  Mizrahi, T. and N. Sprecher, "An Overview of Operations,
              Administration, and Maintenance (OAM) Tools", RFC 7276,
              June 2014.

12.2.  Informative References

   [I-D.ietf-sfc-problem-statement]
              Quinn, P., Guichard, J., and S. Surendra, "Network Service
              Chaining Problem Statement", ID draft-ietf-sfc-problem-
              statement, August 2013.

   [I-D.jain-nvo3-overlay-oam]
              Jain, P., "Generic Overlay OAM and Datapath Failure
              Detection", ID draft-jain-nvo3-overlay-oam-01, February
              2014.

   [I-D.tissa-netmod-oam]
              Senevirathne , T., Finn, N., Kumar , D., and S. Salam ,
              "YANG Data Model for Operations Administration and
              Maintenance (OAM)", ID draft-tissa-netmod-oam-00, March
              2014.

   [RFC3411]  Harrington, D. and R. Presuhn, "An Architecture for
              Describing Simple Network Management Protocol (SNMP)
              Management Frameworks", RFC 3411, December 2002.

   [RFC4656]  Shalunov, S., Karp, A., Boote, J., and M. Zekauskas, "A
              One-way Active Measurement Protocol (OWAMP)", RFC 4656,
              September 2006.

   [RFC5357]  Hedeyat, K., Krzanowski, R., Morton, A., Yum, K., and J.
              Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)",
              RFC 5357, October 2008.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, June 2010.

   [RFC6241]  Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)", RFC
              6241, June 2011.

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374, September 2011.

   [RFC6378]  Weingarten, Y., Bryant, S., Osborne, E., Sprecher, N., and
              A. Fuligoli, "Packet Loss and Delay Measurement for MPLS
              Networks", RFC 6378, October 2011.




Wu, et al.              Expires December 31, 2014              [Page 17]


Internet-Draft               Multi-Layer OAM                   June 2014


   [RFC6428]  Allan, D., Swallow, G., and J. Drake, "Proactive
              Connectivity Verification, Continuity Check, and Remote
              Defect Indication for the MPLS Transport Profile", RFC
              6428, November 2011.

Authors' Addresses

   Qin Wu
   Huawei
   101 Software Avenue, Yuhua District
   Nanjing, Jiangsu  210012
   China

   Email: bill.wu@huawei.com


   Mishael Wexler
   Huawei
   Riesstr. 25
   Munich  80992
   Germany

   Email: mishael.wexler@huawei.com


   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





Wu, et al.              Expires December 31, 2014              [Page 18]


Internet-Draft               Multi-Layer OAM                   June 2014


   Pradeep Jain
   Nuage Networks
   755 Ravendale Drive
   Mountain View, CA  94043
   USA

   Email: pradeep@nuagenetworks.net












































Wu, et al.              Expires December 31, 2014              [Page 19]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/