Internet DRAFT - draft-quinn-sfc-problem-statement

draft-quinn-sfc-problem-statement






Network Working Group                                      P. Quinn, Ed.
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Informational                            T. Nadeau, Ed.
Expires: June 12, 2014                                  Juniper Networks
                                                        December 9, 2013


              Service Function Chaining Problem Statement
                draft-quinn-sfc-problem-statement-02.txt

Abstract

   This document provides an overview of the issues associated with the
   deployment of service functions (such as firewalls, load balancers)
   in large-scale environments.  The term service function chaining is
   used to describe the definition and instantiation of an ordered set
   of such service functions, and the subsequent "steering" of traffic
   flows through those service functions.

   The set of enabled service function chains reflect operator service
   offerings and is designed in conjunction with application delivery
   and service and network policy.

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 12, 2014.

Copyright Notice

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



Quinn & Nadeau            Expires June 12, 2014                 [Page 1]

Internet-Draft            SFC Problem Statement            December 2013


   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
     1.1.  Definition of Terms  . . . . . . . . . . . . . . . . . . .  3
   2.  Problem Space  . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Service Function Chaining  . . . . . . . . . . . . . . . . . .  8
   4.  Service Function Chaining Use Cases  . . . . . . . . . . . . . 10
     4.1.  Enterprise Data Center Service Chaining  . . . . . . . . . 10
     4.2.  3GPP Gi Interface Service Function Chaining  . . . . . . . 10
   5.  Related IETF Work  . . . . . . . . . . . . . . . . . . . . . . 12
   6.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
   10. Informative References . . . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18



























Quinn & Nadeau            Expires June 12, 2014                 [Page 2]

Internet-Draft            SFC Problem Statement            December 2013


1.  Introduction

   The delivery of end-to-end services often require various Service
   Functions (SF) including traditional network service functions (for
   example firewalls and server load balancers), as well as application-
   specific features.  Service functions may be delivered within the
   context of an isolated user group, or shared amongst many users/user
   groups

   Current service function deployment models are relatively static in
   that they are tightly coupled to network topology and physical
   resources.  The result of that static nature of existing deployments
   greatly reduces, and in many cases, limits the ability of an operator
   to introduce new services and/or service functions.  Furthermore
   there is a cascading effect: service changes affect other services.

   This document outlines the problems encountered with existing service
   deployment models for Service Function Chaining (SFC) (often referred
   to simply as service chaining; in this document the terms will be
   used interchangeably), as well as the problems of service chain
   creation/ deletion, policy integration with service chains, and
   policy enforcement within the network infrastructure.

1.1.  Definition of Terms

   Classification:  Locally instantiated customer/network/service policy
      used to identify and select traffic flow(s) requiring appropriate
      outbound forwarding actions.

   Network Overlay:  A logical network built, via virtual links or
      packet encapsulation, over an existing network (the underlay).

   Service Function Chain:  A service chain defines an ordered set of
      service functions that must be applied to packets and/or frames
      selected as a result of classification

   Service Function:  A function that is responsible for specific
      treatment of received packets.  A Service Function can act at the
      network layer or other OSI layers.  A Service Function 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.

      A non-exhaustive list of Service Functions includes: firewalls,
      WAN and application acceleration, Deep Packet Inspection (DPI),
      server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID
      injection [RFC6967], HTTP Header Enrichment functions, TCP



Quinn & Nadeau            Expires June 12, 2014                 [Page 3]

Internet-Draft            SFC Problem Statement            December 2013


      optimizer, etc.

      The generic term "L4-L7 services" is often used to describe many
      service functions.

   Service Node:  Physical or virtual element offering one or more
      Service Functions.

   Network Service:  An externally visible service offered by a network
      operator; a service may consist of a single service function or a
      composite built from several service functions executed in one or
      more pre-determined sequences and delivered by one or more service
      nodes.






































Quinn & Nadeau            Expires June 12, 2014                 [Page 4]

Internet-Draft            SFC Problem Statement            December 2013


2.  Problem Space

   The following points describe aspects of existing service deployments
   that are problematic, and are being addressed by the Service Function
   Chaining effort.

   1.   Topological Dependencies: Network service deployments are often
        coupled to network topology.  Such dependency imposes
        constraints on the service delivery, potentially inhibiting the
        network operator from optimally utilizing service resources, and
        reduces the flexibility.  This limits scale, capacity, and
        redundancy across network resources.

        These topologies serve only to "insert" the service function
        (i.e., ensure that traffic traverses a service function); they
        are not required from a native packet delivery perspective.  For
        example, firewalls often require an "in" and "out" layer-2
        segment and adding a new firewall requires changing the topology
        (i.e., adding new layer-2 segments).

        As more service functions are required - often with strict
        ordering - topology changes are needed before and after each
        service function resulting in complex network changes and device
        configuration.  In such topologies, all traffic, whether a
        service function needs to be applied or not, often passes
        through the same strict order.

        A common example is web servers using a server load balancer as
        the default gateway.  When the web service responds to non-load
        balanced traffic (e.g., administrative or backup operations) all
        traffic from the server must traverse the load balancer forcing
        network administrators to create complex routing schemes or
        create additional interfaces to provide an alternate topology.

   2.   Configuration complexity: A direct consequence of topological
        dependencies is the complexity of the entire configuration,
        specifically in deploying service function chains.  Simple
        actions such as changing the order of the service functions in a
        service function chain require changes to the topology.  Changes
        to the topology are avoided by the network operator once
        installed, configured and deployed in production environments
        fearing misconfiguration and downtime.  All of this leads to
        very static service delivery deployments.  Furthermore, the
        speed at which these topological changes can be made is not
        rapid or dynamic enough as it often requires manual
        intervention, or use of slow provisioning systems.

        The service itself can contribute to the complexity: it may



Quinn & Nadeau            Expires June 12, 2014                 [Page 5]

Internet-Draft            SFC Problem Statement            December 2013


        require an intricate combination of very different capabilities,
        regardless of the underlying topology.  QoS-based, resilient VPN
        service offerings are a typical example of such complex service
        offerings.

   3.   Constrained High Availability: An effect of topological
        dependency is constrained service function high availability.
        Worse, when modified, inadvertent non-high availability or
        downtime can result.

        Since traffic reaches many service functions based on network
        topology, alternate, or redundant service functions must be
        placed in the same topology as the primary service.

   4.   Consistent Ordering of Service Functions: Service functions are
        typically independent; service function_1 (SF1)...service
        function_n (SFn) are unrelated and there is no notion at the
        service layer that SF1 occurs before SF2.  However, to an
        administrator many service functions have a strict ordering that
        must be in place, yet the administrator has no consistent way to
        impose and verify the ordering of the functions that are used to
        deliver a given service.

   5.   Service Chain Construction: Service function chains today are
        most typically built through manual configuration processes.
        These are slow and error prone.  With the advent of newer
        service deployment models the control/management planes provide
        not only connectivity state, but will also be increasingly
        utilized for the creation of network services.  Such a control/
        management planes could be centralized, or be distributed.

   6.   Application of Service Policy: Service functions rely on
        topology information such as VLANs or packet (re) classification
        to determine service policy selection, i.e. the service function
        specific action taken.  Topology information is increasingly
        less viable due to scaling, tenancy and complexity reasons.  The
        topological information is often stale, providing the operator
        with inaccurate placement that can result in suboptimal resource
        utilization.  Furthermore topology-centric information often
        does not convey adequate information to the service functions,
        forcing functions to individually perform more granular
        classification.

   7.   Transport Dependence: Service functions can and will be deployed
        in networks with a range of transports, including under and
        overlays.  The coupling of service functions to topology
        requires service functions to support many transports or for a
        transport gateway function to be present.



Quinn & Nadeau            Expires June 12, 2014                 [Page 6]

Internet-Draft            SFC Problem Statement            December 2013


   8.   Elastic Service Delivery: Given the current state of the art for
        adding/removing service functions largely centers around VLANs
        and routing changes, rapid changes to the service deployment can
        be hard to realize due to the risk and complexity of such
        changes.

   9.   Traffic Selection Criteria: Traffic selection is coarse, that
        is, all traffic on a particular segment traverse service
        functions whether the traffic requires service enforcement or
        not.  This lack of traffic selection is largely due to the
        topological nature of service deployment since the forwarding
        topology dictates how (and what) data traverses service
        function(s).  In some deployments, more granular traffic
        selection is achieved using policy routing or access control
        filtering.  This results in operationally complex configurations
        and is still relatively inflexible.

   10.  Limited End-to-End Service Visibility: Troubleshooting service
        related issues is a complex process that involve both network-
        specific and service-specific expertise.  This is especially the
        case when service function chains span multiple DCs, or across
        administrative boundaries.  Furthermore, the physical and
        virtual environments (network and service), can be highly
        divergent in terms of topology and that topological variance
        adds to these challenges.

   11.  Per-Service (re)Classification: Classification occurs at each
        service function independent from previously applied service
        functions.  More importantly, the classification functionality
        often differs per service function and service functions may not
        leverage the results from other service functions.

   12.  Symmetric Traffic Flows: Service function chains may be
        unidirectional or bidirectional; unidirectional is one where
        traffic is passed through a set of service functions in one
        forwarding direction only.  Bidirectional is one where traffic
        is passed through a set of service functions in both forwarding
        directions.  Existing service deployment models provide a static
        approach to realizing forward and reverse service function chain
        association most often requiring complex configuration of each
        network device throughout the forwarding path.

   13.  Multi-vendor Service Functions: Deploying service functions from
        multiple vendors often require per-vendor expertise: insertion
        models differ, there are limited common attributes and inter-
        vendor service functions do not share information.





Quinn & Nadeau            Expires June 12, 2014                 [Page 7]

Internet-Draft            SFC Problem Statement            December 2013


3.  Service Function Chaining

   Service Function Chaining aims to address the aforementioned problems
   associated with service deployment.  Concretely, SFC will investigate
   solutions that address the following elements:

   1.  Service Overlay: Service function chaining utilizes a service
       specific overlay that creates the service topology.  The service
       overlay is independent of the network topology and allows
       operators to use whatever overlay or underlay they prefer to
       create a path between Service nodes, and to locate service
       functions in the network as needed.

       Within the service topology, service functions can be viewed as
       resources for consumption and an arbitrary topology constructed
       to connect those resources in a required order.  Adding new
       service functions to the topology is easily accomplished, and no
       underlying network changes are required.

       Lastly, the service overlay can provide service specific
       information needed for troubleshooting service-related issues.

   2.  Control Plane: Service aware control plane(s) provide information
       about the available service functions on a network.  The
       information provided by the control plane includes service
       network location (for topology creation), service type (e.g.
       firewall, load balancer, etc.) and, optionally, administrative
       information about the service functions such as load, capacity
       and operating status.  The service aware control plane allows for
       the formulation of service function chains and exchanges
       requisite information needed to instantiate the service function
       chains in the network.

   3.  Service Classification: Classification is used to select which
       traffic enters a service overlay.  The granularity of the
       classification varies based on device capabilities, customer
       requirements, and service offered.  Initial classification is
       used to start the service function chain.  Subsequent
       classification can be used within a given service function chain
       to alter the sequence of service functions applied.  Symmetric
       classification ensures that forward and reverse chains are in
       place.

   4.  Dataplane Metadata: Data plane metadata provides the ability to
       exchange information between the network and service functions,
       between service functions, and service functions and the network.
       Metadata can include the result of antecedent classification,
       information from external sources or forwarding related data.



Quinn & Nadeau            Expires June 12, 2014                 [Page 8]

Internet-Draft            SFC Problem Statement            December 2013


       For example, service functions utilize metadata, as required, for
       localized policy decisions.

       In addition to sharing of information, the use of metadata
       addresses several of the issues raised in section 2, most notably
       the de-coupling of policy from the topology, and the need for
       per-service classification (and re-classification).

       A common approach to service metadata creates a common foundation
       for interoperability between service functions, regardless of
       vendor.








































Quinn & Nadeau            Expires June 12, 2014                 [Page 9]

Internet-Draft            SFC Problem Statement            December 2013


4.  Service Function Chaining Use Cases

   The following sections provide high level overviews of several common
   service chaining deployments.

4.1.  Enterprise Data Center Service Chaining

   TBD

4.2.  3GPP Gi Interface Service Function Chaining

   3GPP defines the Gi interface as the reference point between the GGSN
   (Gateway GPRS Support Node) and an external PDN (Packet Domain
   Network) [RFC6459].  This interface reference point is called SGi in
   4G networks (i.e., between the PDN Gateway and an external PDN)
   [RFC6459].  Note, there is no standard specification of such
   reference points (i.e., Gi and SGi) in terms of functions to be
   located in that segment.

   In light of current deployments, plenty of Service Functions are
   enabled in the Gi Interface (e.g., DPI, billing and charging, TCP
   optimization, web optimization, video optimization, header
   enrichment, etc.).  Some of these Service Functions are co-located on
   the same device while others are enabled in standalone boxes.  In
   order to fulfill new business needs, especially to offer innovative
   added-value services, the number of enabled Service Functions in the
   Gi Interface is still growing.

   Several (S)Gi Interfaces can be deployed within the same PLMN (Public
   Land Mobile Network).  This depends mainly on the number of PDNs and
   other factors.  Each of these interfaces may involve a differentiated
   set of Service Functions to be involved.

   The current model that consists of adding new "boxes" to fulfill new
   business guidelines has shown its limit.  Concretely, current
   deployments suffer from the following problems:

   o  Complexity to introduce new Service Functions because of the
      constraint on the underlying topology.

   o  Lack of visibility on dependency between Service Functions.

   o  Lack of automated and flexible means to assess the impact of
      withdrawing a Service Function or a feature offered by a Service
      Function from the traffic forwarding path.

   o  The connectivity service logic may be stalled because of the
      dependency on the physical topology.



Quinn & Nadeau            Expires June 12, 2014                [Page 10]

Internet-Draft            SFC Problem Statement            December 2013


   o  Lack of deterministic means to:

      *  Improve service provisioning and delivery.

      *  Ease the manageability of the SGi/Gi Interface.














































Quinn & Nadeau            Expires June 12, 2014                [Page 11]

Internet-Draft            SFC Problem Statement            December 2013


5.  Related IETF Work

   The following subsections discuss related IETF work and are provided
   for reference.  This section is not exhaustive, rather it provides an
   overview of the various initiatives and how they relate to network
   service chaining.

   1.  [L3VPN]: The L3VPN working group is responsible for defining,
       specifying and extending BGP/MPLS IP VPNs solutions.  Although
       BGP/MPLS IP VPNs can be used as transport for service chaining
       deployments, the service chaining WG focuses on the service
       specific protocols, not the general case of VPNs.  Furthermore,
       BGP/MPLS IP VPNs do not address the requirements for service
       chaining.

   2.  [LISP]: LISP provides locator and ID separation.  LISP can be
       used as an L3 overlay to transport service chaining data but does
       not address the specific service chaining problems highlighted in
       this document.

   3.  [NVO3]: The NVO3 working group is chartered with creation of
       problem statement and requirements documents for multi-tenant
       network overlays.  NVO3 WG does not address service chaining
       protocols.

   4.  [ALTO]: The Application Layer Traffic Optimization Working Group
       is chartered to provide topological information at a higher
       abstraction layer, which can be based upon network policy, and
       with application-relevant service functions located in it.  The
       mechanism for ALTO obtaining the topology can vary and policy can
       apply to what is provided or abstracted.  This work could be
       leveraged and extended to address the need for services
       discovery.

   5.  [I2RS]: The Interface to the Routing System Working Group is
       chartered to investigate the rapid programming of a device's
       routing system, as well as the service of a generalized, multi-
       layered network topology.  This work could be leveraged and
       extended to address some of the needs for service chaining in the
       topology and device programming areas.











Quinn & Nadeau            Expires June 12, 2014                [Page 12]

Internet-Draft            SFC Problem Statement            December 2013


6.  Summary

   This document highlights problems associated with network service
   deployment today and identifies several key areas that will be
   addressed by the service chaining working group.  Furthermore, this
   document identifies four components that are the basis for serice
   chaining.  These components will form the areas of focus for the
   working group.











































Quinn & Nadeau            Expires June 12, 2014                [Page 13]

Internet-Draft            SFC Problem Statement            December 2013


7.  Security Considerations

   Security considerations are not addressed in this problem statement
   only document.  Given the scope of service chaining, and the
   implications on data and control planes, security considerations are
   clearly important and will be addressed in the specific protocol and
   deployment documents created by the service chaining working group.












































Quinn & Nadeau            Expires June 12, 2014                [Page 14]

Internet-Draft            SFC Problem Statement            December 2013


8.  Contributors

   The following people are active contributors to this document and
   have provided review, content and concepts (listed alphabetically by
   surname):

   Puneet Agarwal (pagarwal@broadcom.com), Mohamed Boucadair
   (mohamed.boucadair@orange.com), Abhishek Chauhan
   (Abhishek.Chauhan@citrix.com), Uri Elzur (uri.elzur@intel.com), Kevin
   Glavin (Kevin.Glavin@riverbed.com), Ken Gray (kgray@juniper.net), Jim
   Guichard (jguichar@cisco.com), Christian Jacquenet
   (christian.jacquenet@orange.com), Surendra Kumar (smkumar@cisco.com),
   Nic Leymann (n.leymann@telekom.de), Darrel Lewis
   (darlewis@cisco.com), Rajeev Manur (rmanur@broadcom.com), Brad
   McConnell (bmcconne@rackspace.com), Carlos Pignataro
   (cpignata@cisco.com), Michael Smith (michsmit@insiemenetworks.com),
   Navindra Yadav (nyadav@insiemenetworks.com).


































Quinn & Nadeau            Expires June 12, 2014                [Page 15]

Internet-Draft            SFC Problem Statement            December 2013


9.  Acknowledgments

   The authors would like to thank David Ward, Rex Fernando and Jim
   French for their contributions.















































Quinn & Nadeau            Expires June 12, 2014                [Page 16]

Internet-Draft            SFC Problem Statement            December 2013


10.  Informative References

   [ALTO]     "Application-Layer Traffic Optimization (alto)",
              <http://datatracker.ietf.org/wg/alto/>.

   [I2RS]     "Interface to the Routing System (i2rs)",
              <http://datatracker.ietf.org/wg/i2rs/>.

   [L3VPN]    "Layer 3 Virtual Private Networks (l3vpn)",
              <http://datatracker.ietf.org/wg/l3vpn/>.

   [LISP]     "Locator/ID Separation Protocol (lisp)",
              <http://datatracker.ietf.org/wg/lisp/>.

   [NVO3]     "Network Virtualization Overlays (nvo3)",
              <http://datatracker.ietf.org/wg/nvo3/>.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              January 2001.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, April 2011.

   [RFC6967]  Boucadair, M., Touch, J., Levis, P., and R. Penno,
              "Analysis of Potential Solutions for Revealing a Host
              Identifier (HOST_ID) in Shared Address Deployments",
              RFC 6967, June 2013.






















Quinn & Nadeau            Expires June 12, 2014                [Page 17]

Internet-Draft            SFC Problem Statement            December 2013


Authors' Addresses

   Paul Quinn (editor)
   Cisco Systems, Inc.

   Email: paulq@cisco.com


   Thomas Nadeau (editor)
   Juniper Networks

   Email: tnadeau@juniper.net







































Quinn & Nadeau            Expires June 12, 2014                [Page 18]