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

Versions: 00 01 draft-king-opsawg-lime-multi-layer-oam-use-case

Operations and Management Area Working Group                     D. King
Internet-Draft                                        Old Dog Consulting
Intended status: Informational                              M. Boucadair
Expires: January 5, 2015                                  France Telecom
                                                               S. Aldrin
                                                              Huawei USA
                                                               G. Mirsky
                                                                Ericsson
                                                                   Q. Wu
                                                                  Huawei
                                                            July 4, 2014


Use Cases and Requirements for Transport-Independent Multiple Layer OAM
           draft-king-opsawg-time-multi-layer-oam-use-case-01

Abstract

   This document identifies and discusses use-cases and high level
   requirements for transport technology independent OAM that need to
   interface multi-layer or multi-domain transport networks to cover
   heterogeneous networking technologies.  As providers face multi-layer
   networks and diverse transport technologies, generic and integrated
   OAM is desirable for simplifying network operations and maintenance.

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.





King, et al.             Expires January 5, 2015                [Page 1]


Internet-Draft             Multi-Layer OAM UC                  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.  Multi-Layer OAM use cases illustration  . . . . . . . . . . .   4
     3.1.  Multi-layer multi-domain OAM Consolidated in the Data
           Plane and Management Plane  . . . . . . . . . . . . . . .   4
     3.2.  OAM at Top of Layer 3 . . . . . . . . . . . . . . . . . .   5
     3.3.  Overlay OAM . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   This document discusses use-cases for transport-independent OAM that
   need to interface multi-layer or multi-domain transport networks to
   cover heterogeneous networking technologies.  As providers (e.g.,
   network providers, data center providers, etc.) face multi-layer
   networks and diverse transport technologies, generic and integrated
   OAM is desirable for keeping network complexity down and simplifying
   O&M (OAM and O&M are used as specified in [RFC6291]).

   This document is part of Transport Independent OAM in Multi-Layer
   Environment (TIME) effort which is meant to:

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

   o  OAM consolidations in the data plane:

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



King, et al.             Expires January 5, 2015                [Page 2]


Internet-Draft             Multi-Layer OAM UC                  July 2014


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

   o  OAM consolidations 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.

   These objectives 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 [TIME-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

      TIME - Transport Independent OAM in Multi-Layer Environment

      OAM - Operations, Administration, and Maintenance

      O&M - OAM and Management




King, et al.             Expires January 5, 2015                [Page 3]


Internet-Draft             Multi-Layer OAM UC                  July 2014


3.  Multi-Layer OAM use cases illustration

3.1.  Multi-layer multi-domain OAM Consolidated in the Data Plane and
      Management Plane

   Figure 1 illustrates a multi-layer network in which IP traffic
   between two customer edges is transported over both an IP/MPLS
   provider network and an Ethernet/MPLS provider network and multiple
   layers OAM are used.  Ethernet OAM is used at the customer level for
   monitoring the end-to-end connection between the two customer edges,
   while IP OAM and MPLS OAM is used at the provider level for
   monitoring the connection between any two provider edges in each
   network.  In addition to Ethernet OAM, transport independent OAM is
   also used for monitor end to end connection between the two customer
   edges at the abstract level.

                Domain A                   Domain B
                ----------                   ----------
              //-IP/MPLS   -\\             //Ethernet/MPLS
            //                \\         //                \\
           /                    \       /                    \
         ||                      ||   ||                      ||
         |                        |   |                        |
 +---+  +----+      +----+      +-------+       +----+     +----+  +---+
 |CE |--| PE |------|  P +----  |  PE   |  ---- | P  |-----| PE |--|CE |
 +-+-+  +--+-+      +--+-+      +---+---+       +--+-+     +-+--+  +-+-+
   |     | |           |          | | |            |         | |     |
   |     |||           |         || | ||           |         |||     |
   |       |           |        |   |   |          |         |       |
   |       |\\         |      //    |    \\        |       //|       |
   |       |  \\-      |   -//      |      \\-     |    -//  |       |
   |       |     ------+---         |         -----+----     |       |
 L1        |           |Ethernet OAM(CC,CV,etc.)   |         |       |
   o-------D-----------+--------+---o---+----------+---------D-------o
   |       |           |            |              |         |       |
 L2|       |           |IP OAM(Ping,|Traceroute, etc.)       |       |
   o-------o-----------D-------- ---o--- ----------D---------o-------o
   |       |           |            |              |         |       |
 L?|      Transport Independent OAM(Integrated Ethernet with IP OAM  |
   o-------o-----------D-------- ---o--- ----------D---------o-------o
   |       |           |            |              |         |       |
   |       |           |            |              |         |       |

                  o  Maintenance Endpoint(MEP)
                  D  Maintenance Intermediary point (MIP)

                  Figure 1: Multi-Domain Multi-Layer OAM




King, et al.             Expires January 5, 2015                [Page 4]


Internet-Draft             Multi-Layer OAM UC                  July 2014


   With transport independent OAM in the data plane, a user who wishes
   to issue a IP Ping Command or use connectivity verification command
   can do so in the same manner regardless of the underlying protocol or
   transport technology.  Consider a scenario where both Ethernet OAM
   and IP OAM can be decomposed into a set of various OAM functions and
   an Ethernet OAM can be integrated with IP OAM in one protocol.  When
   one OAM function is invoked, it will be invoked in the same way as
   the other OAM function regardless of the underlying protocol.

   Alternatively, when Ethernet OAM and IP OAM can be consolidated
   through uniformed interface at the management plane, A user who
   wishes to issue a IP Ping command or a IP Traceroute or initiate a
   session monitoring can also do so in the same manner regardless of
   the underlying protocol or technology.

   Consider a scenario where an IP ping to PE B from CE A failed.
   Between CE A and PE 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.  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 API.

3.2.  OAM at Top of Layer 3

   In Service Function Chain ([I-D.ietf-sfc-problem-statement]), the
   service packets are steered through a set of Service Function Nodes
   distributed in the network.  Overlay technologies (or tunneling
   techniques in general) can be used to stitch these Service Function
   Nodes in order to form end to end path (see Figure 2).






















King, et al.             Expires January 5, 2015                [Page 5]


Internet-Draft             Multi-Layer OAM UC                  July 2014


                               +--------+
                               |Unified |
   +---------------------------+OSS/NMS +---------------------------+
   |                           +--------+                           |
   |      SFC-enabled Domain A            SFC-enabled Domain B      |
   |            ----------                    ----------            |
   |          //  IP/MPLS  -\\             //- IP/MPLS  -\\         |
  +----+    //                \\         //                \\       |
  |SF- | SN1          SN2      SN3     SN4       SN5        SN6   +-+--+
  |    |+++--+      +----|    +--+++ +++--+     +----+     +--+++-|SF- |
  |Ingr||SF1 |      |    |    |SF4|| ||   |     |SF7 |     |   || |Egr |
  |    ++    +------|    +----+    +-+    +-----|    +-----|    +-+    |
  |ess ||SF2 |      | SF3|    |SF5 | |SF6 |     |SF8 |     |SF9 | |ess |
  +-+-+|+--+-+      +--+-+    +-+--+ +--+-+     +--+-+     +-+--+ |+-+-+
   |     | |           |        | |   | |          |         | |     |
   |     |||           |        |||   |||          |         |||     |
   |       |           |        |       |          |         |       |
   |       |\\         |      //|       |\\        |       //|       |
   |       |  \\-      |   -//  |       |  \\-     |    -//  |       |
   |       |     ------+---     |       |     -----+----     |       |
   L1      |           |Ethernet OAM(CC,CV, etc.)  |         |       |
   o-------D-----------+--------+-------+----------+---------D-------o
   |       |           |        |       |          |         |       |
   L2      |           |IP OAM(Ping, Traceroute, etc.)       |       |
   o-------o-----------D--------o-------o----------D---------o-------o
   |       |           |        |       |          |         |       |
   L3     Transport Independent OAM(Integrated Ethernet with IP OAM  |
   o-------o-----------D--------o-------o----------D---------o-------o
   |       |           |        |       |          |         |       |
   |       |           |        |       |          |         |       |

                  o  Maintenance Endpoint(MEP)
                  D  Maintenance Intermediary point (MIP)

   Layer7-  SF1  --------------------- SF6  ------- SF7-------------
   Layer6------------------------F4 --------------------------------
   Layer5------------ SF3-------SF5------------------------- SF9----
   Layer4---SF2 ---------------------------------- SF8--------------

                      Figure 2: OAM at Top of Layer 3

   When the service packet enters into the network, OAM information
   needs to be imposed by ingress node of the network into the 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 at the top of layer
   3.



King, et al.             Expires January 5, 2015                [Page 6]


Internet-Draft             Multi-Layer OAM UC                  July 2014


   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, 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 common to different layers
   and different domains, 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
   unified 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.

   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.3.  Overlay OAM

   Overlay network is referred to a network that is built on top of
   another underlying network and provides various services to tenant
   system.  With the growth of network virtualization technology, the
   needs for inter-connection between various overlay technologies/
   networks (e.g., VXLAN or NVGRE) in the Wide Area Network (WAN) become
   important since it can provide end-to-end connectivity.



King, et al.             Expires January 5, 2015                [Page 7]


Internet-Draft             Multi-Layer OAM UC                  July 2014


                Domain A                       Domain B
                ----------                    ----------
              //- IP/MPLS  -\\             //- IP/MPLS   -\\
            //                \\         //                \\
           /                    \       /                    \
         ||                      ||   ||                      ||
         |                        |   |                        |
 +---+  +----+      +----+    +----+ +----+     +----+     +----+  +---+
 |CE |--| PE +------|  P +----| PE +-+ PE +-----+ P  +-----+ PE +--|CE |
 +-+-+  +--+-+      +--+-+    +-+--+ +--+-+     +--+-+     +-+--+  +-+-+
   |     | |           |        | |   | |          |         | |     |
   |     |||           |        |||   |||          |         |||     |
   |       |           |        |       |          |         |       |
   |       |\\         |      //|       |\\        |       //|       |
   |       |  \\-      |   -//  |       |  \\-     |    -//  |       |
   |       |     ------+---     |       |     -----+----     |       |
 L1        |           |Ethernet OAM(CC,CV,etc)    |         |       |
   o-------D-----------+--------+-------+----------+---------D-------o
   |       |           |        |       |          |         |       |
   |    L2 |           |IP OAM(Ping, Traceroute, etc.)       |
           o-----------D--------o-------o----------D---------o-
           |           |        |       |          |         |

                 o  Maintenance Endpoint(MEP)
                 D  Maintenance Intermediary point (MIP)

                           Figure 3: Overlay OAM

   When a packet traverses a set of overlay networks in the data path,
   each overlay network will comprise an overlay segment used to connect
   overlay nodes in the same network and these overlay segment are
   stitched together to form end to end data path (Figure 3).

   When any Overlay Segment 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.

4.  Requirements

   This section identifies high-level requirements to fulfill transport
   independent OAM 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 the transport network domain SHOULD support standards-
      based abstraction with a common information/data model.



King, et al.             Expires January 5, 2015                [Page 8]


Internet-Draft             Multi-Layer OAM UC                  July 2014


   o  The management entity should be able to create a single unified
      view of OAM information that is common to various layers, various
      domain and various operators.

   o  The following capability 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.

      *  Support verifying Overlay Control Plane and Data Plane
         consistency at either two overlay nodes or two service nodes.

      *  Support local diagnostic procedures specific to each Service
         Node.

      *  Support in-band liveliness and functionality checking
         mechanisms for the overlay node or service node.

      *  Support Trace on the underlying network.

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.

   [TIME-PS]  Wu, Q., "Problem Statement and Architecture for Transport-
              Independent Multiple Layer OAM", ID draft-ww-opsawg-multi-
              layer-oam-01, June 2014.






King, et al.             Expires January 5, 2015                [Page 9]


Internet-Draft             Multi-Layer OAM UC                  July 2014


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-07
              (work in progress), June 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.

   [RFC5706]  Harrington, D., "Guidelines for Considering Operations and
              Management of New Protocols and Protocol Extensions", RFC
              5706, November 2009.

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

Authors' Addresses

   Daniel King
   Old Dog Consulting
   UK

   Email: daniel@olddog.co.uk


   Mohamed Boucadair
   France Telecom
   Rennes 35000
   France

   Email: mohamed.boucadair@orange.com



King, et al.             Expires January 5, 2015               [Page 10]


Internet-Draft             Multi-Layer OAM UC                  July 2014


   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


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

   Email: bill.wu@huawei.com





























King, et al.             Expires January 5, 2015               [Page 11]


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