Skip to main content

Multi-Layering OAM for Service function Chaining
draft-wang-sfc-multi-layer-oam-06

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Cui Wang , Wei Meng , Bhumip Khasnabish
Last updated 2017-02-09
Replaced by draft-ietf-sfc-multi-layer-oam, draft-ietf-sfc-multi-layer-oam, draft-ietf-sfc-multi-layer-oam, RFC 9516
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-wang-sfc-multi-layer-oam-06
SFC WG                                                           C. Wang
Internet-Draft                                                   W. Meng
Intended status: Standards Track                         ZTE Corporation
Expires: August 13, 2017                                   B. Khasnabish
                                                            ZTE TX, Inc.
                                                        February 9, 2017

            Multi-Layering OAM for Service function Chaining
                   draft-wang-sfc-multi-layer-oam-06

Abstract

   This document tries to discuss some problems in SFC OAM framework
   document and proposes the SFC OAM multi-layering requirements in SFC
   domain to improve the troubleshooting efficiency.

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 August 13, 2017.

Copyright Notice

   Copyright (c) 2017 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.

Wang, et al.             Expires August 13, 2017                [Page 1]
Internet-Draft           Multi-Layer OAM for SFC           February 2017

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Convention and Terminology  . . . . . . . . . . . . . . . . .   3
   3.  SFC Layering model  . . . . . . . . . . . . . . . . . . . . .   3
   4.  Requirements for SFC OAM multi-layering model . . . . . . . .   3
   5.  SFC OAM multi-layering model  . . . . . . . . . . . . . . . .   4
   6.  Gap analysis  . . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   In [SFC-arch], it defines several requisite components to implement
   SFC, including classifier, which performs classification for incoming
   packets, and Service Function Forwarder/SFF, which is responsible for
   forwarding traffic to one or more connected service functions
   according to the information carried in the SFC encapsulation, as
   well as handling traffic coming back from the SF and transporting
   traffic to another SFF and terminating the SFP.  And what!_s more,
   another significant component is Service Function/SF, which is
   responsible for specific treatment of received packets.

   Based on these SFC components, there are different notions for
   differentiated level of service chains, such as fully abstract notion
   named SFC, which defines an ordered set of service functions that
   must be applied to packets selected as a result of classification.
   But, SFC doesn!_t define the exactly SFFs/SFs.  And another notion is
   half-fully abstraction notion named SFP, which is the instantiation
   of a SFC in the network and provides a level of indirection between
   the fully abstract SFC and a fully specified RSP.  The mean is that
   SFP defines some SFFs/SFs, not every SFFs/SFs.  As well, there is a
   fully specific notion named RSP, which defines exactly which SFFs/SFs
   the packet will visit when it actually traverses the network.  The
   main difference between SFP and RSP is that whether delegate the SFF/
   SF selection authority to the network or not.

   This document tries to discuss some problems in basic SFC OAM
   framework document and proposes the SFC OAM multi-layering
   requirements to improve the troubleshooting efficiency.

Wang, et al.             Expires August 13, 2017                [Page 2]
Internet-Draft           Multi-Layer OAM for SFC           February 2017

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

3.  SFC Layering model

   As described in [I-D.ietf-sfc-oam-framework], multiple layers come
   into play for implementing the SFC, including the Service layer at
   SFC layer and the underlying Network layer, Transport layer, as well
   as Link layer, which are depicted in Figure 1.

   As for the Service layer in Figure 1, it consists of classifiers and/
   or service functions/SFs.

   Concerning Network layer and Transport Layer in Figure 1, it
   leverages various overlay network technologies interconnecting
   service functions and allows establishing of service function paths.

   As for the Link layer in Figure 1, it is dependent on the physical
   technology used.  Such as, Ethernet, POS etc..)

      +-----------+   +---+   +---+   +---+   +---+   +---+
      |Classifier |---|SF1|---|SF2|---|SF3|---|SF4|---|SF5|
      +-----------+   +---+   +---+   +---+   +---+   +---+
          0------------SFC Service layer OAM------------0
          0----------------0--------------0-------------0  Network layer
          0-------------0-------0-------0--------0------0  Link Layer

                       Figure 1: SFC Layering model

4.  Requirements for SFC OAM multi-layering model

   As for the SFC service layer OAM, except the service layer defined in
   Figure 1 which focuses on the SFC OAM between classifier and/or SFs,
   here tries to propose the SFC OAM between classifier and SFFs or SFFs
   which go through the path along the SFP/RSP, to improve the
   efficiency when diagnosing.

   With regard to how to use this proposal and diagnose efficiently,
   here is an example illustrated as follow.

Wang, et al.             Expires August 13, 2017                [Page 3]
Internet-Draft           Multi-Layer OAM for SFC           February 2017

   Currently, according to the latest SFC architecture, we know that
   there are several components defined in the SFC architecture, such as
   Classifier, SFF, SF, etc, and the relationship between them like
   this: several SFs may share the same SFF.  In some circumstances, one
   SFP1(one service) includes two RSPs(two differentiated services),
   such as RSP1(SF1--SF3--SF5) and RSP2(SF2--SF4--SF6) in Figure 2.  As
   illustrated, SFFs make the decision whether forwarding the traffic to
   RSP1 or RSP2.

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

             Figure 2: different RSPs share the same SFFs path

   As for customers who want to diagnose, troubleshoot a set of RSPs
   which share the same SFP, here can diagnose or troubleshoot the SFFs
   path along the SFP first without forwarding the traffic to the SFs.
   Once the connectivity between the SFFs are all OK, then diagnose or
   troubleshoot the separated RSP one by one.  Otherwise, we know
   clearly that the connectivity of two RSPs are failure.

   And also, for example, if users are willing to or have to diagnose
   and troubleshoot every one, once the connectivity between different
   SFs is not OK, users can detect the connectivity between different
   SFFs along the SFP where the SFs connecting 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 between 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 remarkably of target failure
   location.

5.  SFC OAM multi-layering model

   Figure 3 is a possible architecture for SFC OAM multi-layering model.
   In this figure, it tries to figure out two possible layers
   information.  The layer 1 outlines the SFFs path along the SFP.  The
   layer 2 outlines the SFs path along the RSP.  When trying to do SFC
   OAM, classifier or service nodes select and confirm which SFC OAM
   layering they plan to do, then encapsulate the layering information
   in the SFC OAM packets, and send the SFC OAM packets along the

Wang, et al.             Expires August 13, 2017                [Page 4]
Internet-Draft           Multi-Layer OAM for SFC           February 2017

   service function paths to the destination.  When receiving the SFC
   OAM packets, service nodes analyze the layering information and then
   decide whether sending these packets to next SFFs directly without
   being processed by SFs for layer 1 process or sending to SFs for
   layer 2 process.

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

                  Figure 3: SFC OAM multi-layering model

6.  Gap analysis

   This document tries to complement the SFC OAM framework and all the
   SFC OAM functions are accordance with the SFC OAM framework.  But
   this proposal may be more applicable for connectivity chech and
   continuity check.

7.  Security Considerations

   It will be considered in a future revision.

8.  IANA Considerations

   It will be considered in a future revision.

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

Wang, et al.             Expires August 13, 2017                [Page 5]
Internet-Draft           Multi-Layer OAM for SFC           February 2017

   [RFC7498]  Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
              Service Function Chaining", RFC 7498,
              DOI 10.17487/RFC7498, April 2015,
              <http://www.rfc-editor.org/info/rfc7498>.

   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
              Chaining (SFC) Architecture", RFC 7665,
              DOI 10.17487/RFC7665, October 2015,
              <http://www.rfc-editor.org/info/rfc7665>.

9.2.  Informative References

   [I-D.ietf-sfc-oam-framework]
              Aldrin, S., Krishnan, R., Akiya, N., Pignataro, C., and A.
              Ghanwani, "Service Function Chaining Operation,
              Administration and Maintenance Framework", draft-ietf-sfc-
              oam-framework-01 (work in progress), February 2016.

Authors' Addresses

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

   Email: wang.cui1@zte.com.cn, lindawangjoy@gmail.com

   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

Wang, et al.             Expires August 13, 2017                [Page 6]