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

Versions: 00 01

Service function Chaining                                         S. Lee
Internet-Draft                                                      ETRI
Intended status: Informational                                   S. Pack
Expires: April 30, 2015                                               KU
                                                               M-K. Shin
                                                                    ETRI
                                                                 E. Paik
                                                                      KT
                                                        October 27, 2014


                       SFC dynamic instantiation
                 draft-lee-sfc-dynamic-instantiation-01

Abstract

   This document describes a control plane architecture for dynamic
   instantiation of service function chains which dynamically creates
   and adapts service function paths to optimize performance of the
   service function paths.  This document further defines basic
   operations for the dynamic instantiations; and performance metrics of
   service function path components, i.e., service function instances
   and forwarding links among service function forwarders for evaluation
   of the service function path.

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 April 30, 2015.

Copyright Notice

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





Lee, et al.              Expires April 30, 2015                 [Page 1]


Internet-Draft          SFC dynamic instantiation           October 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
   3.  SFC dynamic instantiation . . . . . . . . . . . . . . . . . .   4
   4.  Control plane architecture  . . . . . . . . . . . . . . . . .   6
   5.  Operational procedures  . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The current service delivery model is bound to static topologies and
   manually configured resources.  This has motivated a more flexible
   deployment model which orchestrates the service delivery separated
   from the network.  Service function chaining
   [I-D.ietf-sfc-problem-statement] provides a new service deployment
   model that delivers the traffic along the predefined logical paths of
   service functions (SFs), called service function chains (SFCs) with
   no regard of network topologies or transport mechanisms.

   A SFC is determined by classification of target traffic based on
   operator's policy.  Since it is described with logical SFs, the
   service function chain needs to be instantiated by selecting
   instances of the SFs, which results in a service function path (SFP).
   Performance of a SFP depends on the current state or attributes
   (e.g., availability, topological location, and latency) of SFP
   components (i.e., SF instances (SFIs) and forwarding links among SFFs
   (SFLs)).  Thus, the SFP performance may vary according to which SFIs
   are selected at SFC instantiation; and it may also vary in time with
   the state or attributes of the SFP components.

   This document describes a control plane architecture for dynamic
   instantiation of SFCs which dynamically creates and adapts SFPs to



Lee, et al.              Expires April 30, 2015                 [Page 2]


Internet-Draft          SFC dynamic instantiation           October 2014


   optimize the SFP performance considering the current state and
   attributes of SFIs and SFLs.  This document further defines basic
   operations for the dynamic instantiations and performance metrics of
   SFP components for SFP evaluation.

2.  Terminology

   This document uses the following terms and most of them were
   reproduced from [I-D.ietf-sfc-problem-statement] and
   [I-D.ietf-sfc-architecture].

   o  Classification: Locally instantiated policy and customer/network/
      service profile matching of traffic flows for identification of
      appropriate outbound forwarding actions.

   o  Service Function Chain (SFC): A service function chain defines a
      set of abstract service functions and ordering constraints that
      must be applied to packets and/or frames selected as a result of
      classification.  The implied order may not be a linear progression
      as the architecture allows for SFCs that copy to more than one
      branch, and also allows for ere there is flexibility in the order
      in which service functions need to be applied.  The term service
      chain is often used as shorthand for service function chain.

   o  Service Function (SF): A function that is responsible for specific
      treatment of received packets.  A Service Function can act at
      various layers of a protocol stack (e.g., at the network layer or
      other OSI layers).  As a logical component, a Service Function can
      be realized as a virtual element or be embedded in a physical
      network element.  One or multiple Service Functions can be
      embedded in the same network element.  Multiple occurrences of the
      Service Function can exist in the same administrative domain.

   o  Service Function Instance (SFI): The instantiation of Service
      Function that can be a virtual instance or be embedded in a
      physical network element.  One of multiple Service Functions can
      be embedded in the same network element.  Multiple instances of
      the Service Function can be enabled in the same administrative
      domain.

   o  Service Function Forwarder (SFF): A service function forwarder is
      responsible for delivering traffic received from the network to
      one or more connected service functions according to information
      carried in the SFC encapsulation, as well as handling traffic
      coming back from the SF.  Additionally, a service function
      forwarder is responsible for delivering traffic to a classifier
      when needed and supported, mapping out traffic to another SFF (in
      the same or different type of overlay), and terminating the SFP.



Lee, et al.              Expires April 30, 2015                 [Page 3]


Internet-Draft          SFC dynamic instantiation           October 2014


   o  Service Function Path (SFP): The SFP provides a level of
      indirection between the fully abstract notion of service chain as
      a sequence of abstract service functions to be delivered, and the
      fully specified notion of exactly which SFF/SFs the packet will
      visit when it actually traverses the network.  By allowing the
      control components to specify this level of indirection, the
      operator may control the degree of SFF/SF selection authority that
      is delegated to the network.

   o  Service Forwarding Link (SFL): An overlay link between two SFFs
      over which the packet will visit SF along the SFP.

3.  SFC dynamic instantiation

   A service function chain is composed of one or more logical service
   functions and it can be further instantiated with a SFP which
   contains physical instances of the logical SFs.  Since multiple
   instances of a SF may be available, different sets of SFI (i.e.,
   SFPs) can be built per SFC.

   For example in Figure 1, a SFC {SF1 -> SF2 -> SF3} selected for a
   traffic flow can be further instantiated with two different SFPs:
   SFP#1 {SF1_a -> SF2_a -> SF3_a} and SFP#2 {SF1_b -> SF2_b -> SF3_b}
   by selecting one of multiple instances of the service functions.


          +------+           +------+           +------+
   SFC    | SF1  |-----------| SF2  |-----------| SF3  |
          +------+           +------+           +------+


          +------+           +------+           +------+
          |SF1_a |           |SF2_a |           |SF3_a |
          +------+           +------+           +------+
   SFP#1     |                   |                  |
          ********           ********           ********
          * SFF  *-----------* SFF  *-----------* SFF  *
          ********    SFL    ********    SFL    ********
   SFP#2     |                   |                  |
          +------+           +------+           +------+
          |SF1_b |           |SF2_b |           |SF3_b |
          +------+           +------+           +------+


                        Figure 1: SFC instantiation

   Under this abstraction, a SFC can be constructed by the following
   operations:



Lee, et al.              Expires April 30, 2015                 [Page 4]


Internet-Draft          SFC dynamic instantiation           October 2014


   o  Classification: One SFC is selected and identified by a
      classification function according to the traffic steering policy
      defined by the network operator.  The policy just logically
      defines which service functions must be applied to traffic flows
      in a specific order.

   o  Re-classification (or branching): According to an intermediate
      result of packet treatment, the current SFC can be updated by
      adding or removing SFs, which results in creation of a new SFP.

   o  SFC instantiation: In order to define the physical forwarding
      paths for the traffic, the SFC needs to be instantiated to a SFP
      by selecting a specific instance of each service function that is
      given in the SFC.  The SFP can be updated by replacing one or more
      conventional SF instances with the other ones at run-time.  Note
      that it does not cause change of a SF but change of a physical
      instance of the same SF.

   The SFC instantiation may be static or dynamic.  In a static
   instantiation, specific SF instances are pre-determined by network
   operator's configuration or policy.  The static instantiation may be
   more convenient for network administrators because they can easily
   expect the result and troubleshooting locations.  However, since it
   does not consider the current state and attribute of SFIs, the static
   instantiation may create more vulnerable SFPs to state changes of the
   SFIs such as failure or overload.

   In a dynamic SFC instantiation, SFIs are selected according to their
   states and attributes at time of demand, specifically at initial
   classification or during intermediate traversal of the SFP.

   o  At classification: SF instances are selected to initially
      construct a SFP before starting to forward the incoming traffic
      flows

   o  At intermediate traversal: One or more SF instances are selected
      and dynamically replaced during traversing the SFP to update the
      SFP

   The example use cases of SFC dynamic instantiation are as follows:

   o  SFP fail-over: re-construct a SFP with replacing the failed SFI
      with new SFI selected

   o  End-to-end service optimization: construct or maintain a SFP with
      a low stretch considering the topological locations of SFI and
      properties (e.g., latency, bandwidth) of SFLs




Lee, et al.              Expires April 30, 2015                 [Page 5]


Internet-Draft          SFC dynamic instantiation           October 2014


   o  Traffic optimization: construct or maintain SFPs to localize the
      traffic in the network considering load and administrative domains
      of SFIs and SFLs.

   o  Load balancing: construct or maintain SFPs to distribute the load
      of shared SFIs and SFLs.

   For more details about the use cases, refer to
   [I-D.lee-nfvrg-resource-management-service-chain].

4.  Control plane architecture

   In order to instantiate a SFC dynamically according to the state and
   attributes of SFP components, the following functional building
   blocks are required in a SFC control plane architecture.

   SFC instantiation

   o  Evaluate SFIs and SFLs based on the measurements obtained from SFP
      component management building block

   o  Select SFIs to construct a SFP optimized according to the
      evaluation results

   o  Enforce the constructed SFP for incoming traffic to the
      classification node via interface-(a)

   o  Replace SFIs to update a SFP adapted to changes of state or
      attributes of SFIs and SFLs

   o  Enforce the updated SFP for upcoming SFC traversal to SFFs via
      interface-(b)

   SFP component management

   o  Collect and monitor state and attributes of SFIs and SFLs via
      interface-(d) and interface-(c), respectively

   o  Provide the collected state and attributes of SFIs and SFLs to SFC
      instantiation building block for evaluation











Lee, et al.              Expires April 30, 2015                 [Page 6]


Internet-Draft          SFC dynamic instantiation           October 2014


   #=================================================#
   #                                                 #
   #       +---------------+      +---------------+  #
   #   ____|      SFC      |______| SFP component |  #
   #   |   | instantiation |      |   management  |  #
   #   |   +---------------+      +---------------+  #
   #   |             |                 ^     ^       #
   #===|=============|=================|=====|=======#
       |             |                 |     |
       |(a)          |(b)              |(c)  |(d)
       |             |                 |     |
       |             |  +------+       |  +------+
       |             |  | SFI  |       |  | SFI  |
       |             |  +------+       |  +------+
       V             V   |             |    |
    ********       ********           ********
   -* CLSF *-------* SFF  *-----------* SFF  *--------
    ********       ********           ********


    Figure 2: Control plane architecture for SFC dynamic instantiation

   The state and attributes of SFP components for SFP evaluation can be
   obtained via interface-(c) and interface-(d).  Examples of the state
   and attributes of SFP components are as follows:

   o  availability (or failure) of a SFI and a SFL

   o  a topological location of a SFI

   o  a utilization rate of a SFI

   o  a throughput of a SFI

   o  energy consumption of SFI

   o  bandwidth of a SFL

   o  latency of a SFL

5.  Operational procedures

   (TBD)








Lee, et al.              Expires April 30, 2015                 [Page 7]


Internet-Draft          SFC dynamic instantiation           October 2014


6.  Security Considerations

   (TBD)

7.  IANA Considerations

   (TBD)

8.  References

8.1.  Normative References

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

   [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.lee-nfvrg-resource-management-service-chain]
              Lee, S., Pack, S., Shin, M., and E. Paik, "Resource
              Management for Dynamic Service Chain Adaptation", draft-
              lee-nfvrg-resource-management-service-chain-00 (work in
              progress), October 2014.

   [I-D.ww-sfc-control-plane]
              Li, H., Wu, Q., Boucadair, M., Jacquenet, C., and W.
              Haeffner, "Service Function Chaining (SFC) Control Plane
              Achitecture", draft-ww-sfc-control-plane-03 (work in
              progress), September 2014.

Authors' Addresses











Lee, et al.              Expires April 30, 2015                 [Page 8]


Internet-Draft          SFC dynamic instantiation           October 2014


   Seung-Ik Lee
   ETRI
   218 Gajeong-ro Yuseung-Gu
   Daejeon  305-700
   Korea

   Phone: +82 42 860 1483
   Email: seungiklee@etri.re.kr


   Sangheon Pack
   Korea University
   145 Anam-ro, Seongbuk-gu
   Seoul  136-701
   Korea

   Phone: +82 2 3290 4825
   Email: shpack@etri.re.kr


   Myung-Ki Shin
   ETRI
   218 Gajeong-ro Yuseung-Gu
   Daejeon  305-700
   Korea

   Phone: +82 42 860 4847
   Email: mkshin@etri.re.kr


   EunKyoung Paik
   KT
   17 Woomyeon-dong, Seocho-gu
   Seoul  137-792
   Korea

   Phone: +82 2 526 5233
   Email: eun.paik@kt.com













Lee, et al.              Expires April 30, 2015                 [Page 9]


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