[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 draft-ietf-sfc-multi-layer-oam

SFC WG                                                             C. Wu
Internet-Draft                                       Zhejiang University
Intended status: Standards Track                                 C. Wang
Expires: June 6, 2015                                            W. Meng
                                                         ZTE Corporation
                                                           B. Khasnabish
                                                            ZTE TX, Inc.
                                                        December 3, 2014


             Multi-Layer OAM for Service function Chaining
                   draft-wang-sfc-multi-layer-oam-01

Abstract

   Since there are different notions of service chain, such as fully
   abstract notion named SFC, half-fully abstraction notion named SFP
   and fully specific notion named RSP, and there are different
   components defined in SFC architecture, it seems reasonable to define
   differentiated OAM for these different service chains.  This document
   tries to discuss the multi-layer OAM requirements in SFC domain and
   provides a multi-layer OAM solution for different service chains.

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 June 6, 2015.

Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of



Wu, et al.                Expires June 6, 2015                  [Page 1]


Internet-Draft           Multi-Layer OAM for SFC           December 2014


   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.  Convention and Terminology . . . . . . . . . . . . . . . . . .  4
   3.  Requirement  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Multi-layer SFC OAM architecture . . . . . . . . . . . . . . .  7
   5.  Solution . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 11
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12






























Wu, et al.                Expires June 6, 2015                  [Page 2]


Internet-Draft           Multi-Layer OAM for SFC           December 2014


1.  Introduction

   Since there are different notions of service chain, such as fully
   abstract notion named SFC, half-fully abstraction notion named SFP
   and fully specific notion named RSP, and there are different
   components defined in SFC architecture, it seems reasonable to define
   differentiated OAM for these different service chains.  This document
   tries to discuss the multi-layer OAM requirements in SFC domain and
   provides a multi-layer OAM solution for different service chains.










































Wu, et al.                Expires June 6, 2015                  [Page 3]


Internet-Draft           Multi-Layer OAM for SFC           December 2014


2.  Convention and Terminology

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

   The terms are all defined in [I-D.ietf-sfc-architecture].












































Wu, et al.                Expires June 6, 2015                  [Page 4]


Internet-Draft           Multi-Layer OAM for SFC           December 2014


3.  Requirement

   In fact, besides the link layer OAM, network layer OAM, SFC service
   layer OAM is requisite in SFC Domain, which may be typically
   illustrated in Figure 1.


      +-----------+   +---+   +---+   +---+   +---+   +---+
      |Classifier |---|SF1|---|SF2|---|SF3|---|SF4|---|SF5|
      +-----------+   +---+   +---+   +---+   +---+   +---+
          |------------SFC Service layer OAM------------|


                  Figure 1: typical SFC service layer OAM

   Currently, according to the latest SFC architecture, we know that
   there are several components defined in the SFC architecture, such as
   SN, SFF, SF,etc, and the relationship between them like this:
   serveral SFs may share the same SFF, and furthermore, serveral SFFs
   may share the same SN(e.g, different SFFs residented in one service
   node belong to different VPNs).  As a result of that, multiple RSPs,
   such as RSP1(SF1--SF3--SF5) and RSP2(SF2--SF4--SF6) in Figure 2, may
   not share the same transmitting path, but they may share the same
   SFFs path.


                    +---+  +---+     +---+  +---+     +---+  +---+
                    |SF1|  |SF2|     |SF3|  |SF4|     |SF5|  |SF6|
                    +---+  +---+     +---+  +---+     +---+  +---+
                       \   /            \  /             \  /
      +-----------+   +----+           +----+           +----+
      |Classifier |---|SFF1|-----------|SFF2|-----------|SFF3|
      +-----------+   +----+           +----+           +----+


             Figure 2: different RSPs share the same SFFs path

   And also, multiple SFPs, such as SFP1(SFF1--SFF3--SFF5)(e.g, VPN1)
   and SFP2(SFF2--SFF4--SFF6)(e.g, VPN2) in Figure 3, may not share the
   same SFFs, but they may share the same SNs path.











Wu, et al.                Expires June 6, 2015                  [Page 5]


Internet-Draft           Multi-Layer OAM for SFC           December 2014


                   +----+   +----+    +----+  +----+     +----+  +----+
                   |SFF1|   |SFF2|    |SFF3|  |SFF4|     |SFF5|  |SFF6|
                   +----+   +----+    +----+  +----+     +----+  +----+
                        \   /             \  /               \  /
       +-----------+   +----+            +----+             +----+
       |Classifier |---|SN1 |------------|SN2 |-------------|SN3 |
       +-----------+   +----+            +----+             +----+


             Figure 3: different SFPs share the same SNs path

   As for users who want to diagnose, troubleshoot a set of RSPs which
   transmit the same SFFs, or a set of SFPs which transmit the same SNs,
   there is an aggregative method which can aggregate a set of RSPs or a
   set of SFPs into one, then, users only need to diagnose, troubleshoot
   the aggregative one, rather than the separated one by one.  And also,
   if users are willing to diagnose and troubleshoot one by one, once
   the connectivity between different SFs is not OK, users can detect
   the connectivity between different SFFs where the SFs resident
   instead to narrow the failure coverage.  In other words, if the
   connectivity between the detected SFFs is not OK, then the
   connectivity problem is located. if the connectivity betwwen the
   detected SFFs is OK, then the connectivity problem should be between
   the detected SFs and the detected SFFs, which can help to improve the
   efficiency of target location remarkably.  Obviously, they can be
   diagnosed, troubleshooted one by one or aggregatively according to
   preferance.

   As follow, this document tries to provide an architecture and a
   solution for differentiated layer OAM for this requirement.





















Wu, et al.                Expires June 6, 2015                  [Page 6]


Internet-Draft           Multi-Layer OAM for SFC           December 2014


4.  Multi-layer SFC OAM architecture

   Figure 4 is a possible architecture for multi-layer SFC OAM.  In this
   figure, it tries to figure out three possible layers.  The layer 1 is
   the most aggregative layer for service chain.  It stretches the path
   which SNs go through according to the sets of RSPs or SFPs or SFCs.
   The layer 2 is the medium aggregative layer for service chain.  It
   outlines the path which SFFs go though according to the sets of RSPs
   or SFPs or SFCs.  The layer 3 is the specific path for service chain.
   It is exactly the path which SFs go though according to the sets of
   RSPs or SFPs or SFCs.


               +---+  +---+  +----+  +----+    +-----+  +-----+  +------+  +------+
               |SF1|..|SFn|  |SF1'|..|SFn'|    |SF1''|..|SFn''|  |SF1'''|..|SFn'''|
               +---+  +---+  +----+  +----+    +-----+  +-----+  +------+  +------+
                 \   /        \   /    |           \     /           \    /   |
                +----+       +----+    |           +-----+          +-----+   |
                |SFF1|  ...  |SFFn|    |           |SFF1'|   ...    |SFFn'|   |
                +----+       +----+    |           +-----+          +-----+   |
                    \       /   |      |                  \        /    |     |
 +-----------+      +-------+   |      |                  +-------+     |     |
 |Classifier |------|  SN1  |---|------|------------------|  SNn  |     |     |
 +-----------+      +-------+   |      |                  +-------+     |     |
                         |      |      |                       |        |     |
                         |------|------|-Layer 1---------------|        |     |
                                |      |                                |     |
                                |------|--------Layer 2-----------------|     |
                                       |                                      |
                                       |--------------Layer 3-----------------|
                                       |                                      |


         Figure 4: a possible architecture for multi-layer SFC OAM

















Wu, et al.                Expires June 6, 2015                  [Page 7]


Internet-Draft           Multi-Layer OAM for SFC           December 2014


5.  Solution

   If anyone is interested in this requirement, I will update the
   solution in the next version.















































Wu, et al.                Expires June 6, 2015                  [Page 8]


Internet-Draft           Multi-Layer OAM for SFC           December 2014


6.  Security Considerations

   It will be considered in a future revision.
















































Wu, et al.                Expires June 6, 2015                  [Page 9]


Internet-Draft           Multi-Layer OAM for SFC           December 2014


7.  IANA Considerations

   It will be considered in a future revision.
















































Wu, et al.                Expires June 6, 2015                 [Page 10]


Internet-Draft           Multi-Layer OAM for SFC           December 2014


8.  References

8.1.  Normative References

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

8.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-architecture]
              Halpern, J. and C. Pignataro, "Service Function Chaining
              (SFC) Architecture", draft-ietf-sfc-architecture-02 (work
              in progress), September 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.

   [I-D.krishnan-sfc-oam-req-framework]
              Krishnan, R., Ghanwani, A., Gutierrez, P., Lopez, D.,
              Halpern, J., Kini, S., and A. Reid, "SFC OAM Requirements
              and Framework", draft-krishnan-sfc-oam-req-framework-00
              (work in progress), July 2014.




















Wu, et al.                Expires June 6, 2015                 [Page 11]


Internet-Draft           Multi-Layer OAM for SFC           December 2014


Authors' Addresses

   Wu Chunming
   Zhejiang University
   No.38 Zheda Road, Xihu District
   Hangzhou
   China

   Email: wuchunming@zju.edu.cn


   Cui Wang
   ZTE Corporation
   No.50 Software Avenue, Yuhuatai District
   Nanjing
   China

   Email: wang.cui1@zte.com.cn


   Wei Meng
   ZTE Corporation
   No.50 Software Avenue, Yuhuatai District
   Nanjing
   China

   Email: meng.wei2@zte.com.cn,vally.meng@gmail.com


   Bhumip Khasnabish
   ZTE TX, Inc.
   55 Madison Avenue, Suite 160
   Morristown, New Jersey  07960
   USA

   Email: bhumip.khasnabish@ztetx.com















Wu, et al.                Expires June 6, 2015                 [Page 12]


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