Internet DRAFT - draft-king-opsawg-lime-multi-layer-oam-use-case

draft-king-opsawg-lime-multi-layer-oam-use-case




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