Network Service Chaining Problem Statement
draft-quinn-nsc-problem-statement-00

Network Working Group                                        J. Guichard
Internet-Draft                                                  S. Kumar
Intended status: Informational                                  P. Quinn
Expires: December 15, 2013                           Cisco Systems, Inc.
                                                                M. Smith
                                                                N. Yadav
                                                        Insieme Networks
                                                           June 13, 2013

               Network Service Chaining Problem Statement
                draft-quinn-nsc-problem-statement-00.txt

Abstract

   This document provides an overview of the issues associated with the
   deployment of network services (such as firewalls, load balancers) in
   large-scale environments.  The term service chaining is used to
   describe the deployment of such services, and the ability of a
   network operator to specify an ordered list of services that should
   be applied to a deterministic set of traffic flows.  Such service
   chains require integration of service policy alongside the deployment
   of applications, while maintaining optimal use of available network
   capacity and resources.

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 December 15, 2013.

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

Guichard, et al.        Expires December 15, 2013               [Page 1]
Internet-Draft            NSC Problem Statement                June 2013

   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Definition of Terms  . . . . . . . . . . . . . . . . . . .  3
   2.  Problem Areas  . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Service Chaining for Adding Network Services . . . . . . . . .  8
   4.  Related IETF Work  . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14

Guichard, et al.        Expires December 15, 2013               [Page 2]
Internet-Draft            NSC Problem Statement                June 2013

1.  Introduction

   New data center (DC) network and Internet cloud architectures require
   more flexible deployment models that are able to support many
   different forms of applications and related network services.
   Network services include traditional services such as firewalls and
   server load balancer, as well as applications and features that
   operate on network data.  Additionally, these services must be
   delivered in the context of multi-tenancy where each individual
   tenant is an isolated client organization attached to the data
   center, and may require unique capabilities with the ability to
   tailor service characteristics on a per-tenant basis.

   The current network service deployment models are relatively static,
   and bound to topology for insertion and policy selection.
   Furthermore, they do not adapt well to elastic service environments
   enabled by virtualization.  Additionally, the transition to virtual
   platforms requires an agile service insertion model that supports
   elastic service delivery; supports the movement of service functions
   and application workloads in the network while retaining the network
   and service policies and the ability to easily bind service policy to
   granular information such as per-subscriber state.

   This document outlines the problems encountered with existing service
   deployment models for service chaining, as well as the problems of
   service chain creation/deletion, policy selection integration with
   service chains, and policy enforcement within the network
   infrastructure.

1.1.  Definition of Terms

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

   Network Overlay:  Logical network built on top of existing network
      (the underlay).  Packets are encapsulated or tunneled to create
      the overlay network topology.

   Service Chain:  A service chain defines the services required
      (e.g.FW), and their order (service1 --> service2) that must be
      applied to packets and/or frames.

   Service Function:  A L4-L7 service function (NAT, FW, DPI, IDS,
      application based packet treatment), application, compute
      resource, storage, or content used singularly or in collaboration
      with other service functions to enable a service offered by a
      network operator.

Guichard, et al.        Expires December 15, 2013               [Page 3]
Internet-Draft            NSC Problem Statement                June 2013

   Service Node:  Physical or virtual element providing 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.

Guichard, et al.        Expires December 15, 2013               [Page 4]
Internet-Draft            NSC Problem Statement                June 2013

2.  Problem Areas

   The following points describe aspects of existing service deployment
   techniques that are problematic, and are being addressed by the
   network service chaining effort.

   1.   Topological Dependencies: Network service deployments are often
        coupled to the physical network topology creating artificial
        constraints on delivery and inhibiting the network operator from
        sharing service resources and scale capacity/redundancy across
        multiple network devices.  These topologies serve only to
        "insert" the 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 L2
        segments).  As more services are required - often with strict
        ordering - topology changes are needed before and after each
        service resulting in complex network changes and device
        configuration.  In such topologies, all traffic, whether a
        service 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 chains.  Simple actions such
        as changing the order of the service functions in a service
        chain require changes to the topology.  Changes to the topology
        is 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
        models.

   3.   Constrained High Availability: An effect of topological
        dependency is constrained service high availability.  Since
        traffic reaches services 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

Guichard, et al.        Expires December 15, 2013               [Page 5]
Internet-Draft            NSC Problem Statement                June 2013

        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 deployed service ordering.

   5.   Service Chain Construction: Service chains today are most
        typically built through manual configuration processes.  With
        the advent of newer service deployment models the control plane
        will provide not only connectivity state and membership
        distribution across tenants, but will also be increasingly
        utilized for the formation of services.  Such a control plane
        could be centrally controlled and managed, or be distributed
        between a subset of end-systems.  Formation of closed user
        groups that are able to maintain separation of forwarding and
        connectivity state, while at the same time be independently
        identified and directed through appropriate services, requires
        the ability to create "zones" of awareness and "chained"
        services.

   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 action
        taken.  Topology information is increasingly less viable due to
        scaling, tenancy and complexity reasons.  Per-service function
        packet classification is inefficient and prone to errors,
        duplicating functionality across services.  Furthermore packet
        classification is often too coarse lacking the ability to
        determine class of traffic with enough detail.

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

   8.   Elastic Service Delivery: Given the current state of the art for
        adding/removing services largely centers around VLANs and
        routing changes, rapid changes to the service layer 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 is sent to a service
        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 the service(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

Guichard, et al.        Expires December 15, 2013               [Page 6]
Internet-Draft            NSC Problem Statement                June 2013

        inflexible.

   10.  Limited End-to-End Service Visibility: Troubleshooting service
        related issues is a complex process that involve network and
        service expertise.

   11.  Per-Service (re)Classification: Classification occurs at each
        service, independently from previous service functions.  These
        unrelated classification events consume resources per service.
        More importantly, the classification functionality often differs
        per service and services cannot leverage the results from other
        deployed network or service.

   12.  Symmetric Traffic Flows: Service 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 chain association most
        often requiring complex configuration of each network device
        throughout the forwarding path.

Guichard, et al.        Expires December 15, 2013               [Page 7]
Internet-Draft            NSC Problem Statement                June 2013

3.  Service Chaining for Adding Network Services

   Service chaining provides a framework to address the aforementioned
   problems associated with service deployments:

   1.  Service Overlay: Service chaining utilizes a service specific
       overlay that creates the service topology: the overlay creates a
       path between service nodes.  The service overlay is independent
       of the network topology and allows operators to use whatever
       overlay or underlay they prefer and to place services in the
       network as needed.  Within the service topology, services can be
       viewed as resources for consumption and an arbitrary topology
       constructed to connect those resources in a required order.
       Furthermore, additional service instances, for redundancy or load
       distribution, can be added or removed to the service topology as
       required.  Lastly, the service overlay can provide service
       specific information needed for troubleshooting service-related
       issues.

   2.  Generic Service Control Plane (GSCP): GSCP provides information
       about the available services on a network.  The information
       provided by the control plane includes service network location
       (for topology creation), service type (e.g. firewall vs. load
       balancer) and, optionally, administrative information about the
       services such as load, capacity and operating status.  GSCP
       allows for the formulation of service chains and disseminates the
       service chains to 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 functionality.  Initial classification
       is used to start the service chain.  Subsequent classification
       can be used within a given service chain to alter the sequence of
       services applied.  Symmetric classification ensures that forward
       and reverse chains are in place.

   4.  Dataplane Metadata: Dataplane metadata provides the ability to
       exchange information between the network and services, services
       and services and services and the network.  Metadata can include
       the result of antecedent classification, information from
       external sources or forwarding related data.  For example,
       services utilize metadata, as required, for localized policy
       decision.

Guichard, et al.        Expires December 15, 2013               [Page 8]
Internet-Draft            NSC Problem Statement                June 2013

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

Guichard, et al.        Expires December 15, 2013               [Page 9]
Internet-Draft            NSC Problem Statement                June 2013

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

Guichard, et al.        Expires December 15, 2013              [Page 10]
Internet-Draft            NSC Problem Statement                June 2013

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

Guichard, et al.        Expires December 15, 2013              [Page 11]
Internet-Draft            NSC Problem Statement                June 2013

7.  Acknowledgments

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

Guichard, et al.        Expires December 15, 2013              [Page 12]
Internet-Draft            NSC Problem Statement                June 2013

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

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

Guichard, et al.        Expires December 15, 2013              [Page 13]
Internet-Draft            NSC Problem Statement                June 2013

Authors' Addresses

   Jim Guichard
   Cisco Systems, Inc.

   Email: jguichar@cisco.com

   Surendra Kumar
   Cisco Systems, Inc.

   Email: smkumar@cisco.com

   Paul Quinn
   Cisco Systems, Inc.

   Email: paulq@cisco.com

   Michael Smith
   Insieme Networks

   Email: michsmit@insiemenetworks.com

   Navindra Yadav
   Insieme Networks

   Email: nyadav@insiemenetworks.com

Guichard, et al.        Expires December 15, 2013              [Page 14]