SFC Long-lived Flow Use Cases
draft-krishnan-sfc-long-lived-flow-use-cases-01

SFC Working Group                                           R. Krishnan
Internet Draft                                   Brocade Communications
Category: Informational                                     A. Ghanwani
                                                                   Dell
                                                             J. Halpern
                                                                S. Kini
                                                               Ericsson
                                                            Diego Lopez
                                                             Telefonica

Expires: April 2014                                    February 1, 2014

                      SFC Long-lived Flow Use Cases

             draft-krishnan-sfc-long-lived-flow-use-cases-01

Abstract

   Long-lived flows such as file transfers, video streams are common in
   today's networks. In the context of service function chaining, this
   draft suggests use cases for dynamic bypass of certain service nodes
   for such flows. The benefit of this approach would be to avoid
   expensive Layer 7 service node processing for such flows based on
   dynamic decisions and improve overall performance.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Krishnan                  Expires April 2014                   [Page 1]
Internet-Draft          SFC Long Lived Flow Use Case     September 2013

   This Internet-Draft will expire on April, 2014.

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
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.

Conventions used in this document

   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 RFC-2119 [RFC 2119].

Table of Contents

   1. Introduction...................................................3
      1.1. Acronyms..................................................4
   2. Transparent Firewall Use Case..................................4
      2.1. Event Sequence............................................5
   3. Long-tail content CDN Use Case.................................5
      3.1. Event Sequence............................................6
   4. Operational Considerations.....................................7
   5. IANA Considerations............................................7
   6. Security Considerations........................................7
   7. Acknowledgements...............................................7
   8. References.....................................................7
      8.1. Normative References......................................7
      8.2. Informative References....................................7
   Authors' Addresses................................................8

Krishnan                  Expires April 2014                   [Page 2]
Internet-Draft          SFC Long Lived Flow Use Case     September 2013

1. Introduction

   In the context of service function chaining, this draft suggests use
   cases for dynamic bypass of certain service nodes for long-lived
   flows such as file transfers, video streams. The benefit of this
   approach would be to avoid expensive Layer 4-7 service node
   processing for such flows and improve overall performance. The focus
   would be only on long-lived flows which are observable and
   controllable from a control plane perspective; attempting dynamic
   bypass for short-lived flows would cause excessive control plane
   chattiness without any significant performance benefit.

   For long-lived flows, in order to dynamically bypass certain service
   nodes in the service function chain, the key is to make sure that
   the Layer 7 flow can be identified using Layer 2/3/4 fields in the
   packet. Examples of such flows are file transfers (FTP) and video
   streams (typically use HTTP) which can be mapped to a unique IP 5
   tuple (IP source address, IP destination address, IP protocol,
   TCP/UDP source port, TCP/UDP destination port).  We note that it may
   not always be possible to identify a Layer 7 flow based on L2/L3/L4
   fields in the packet header.  An example of this could be file
   transfers under persistent HTTP sessions where multiple files would
   be transferred using the same fields in the packet headers.

   The definition of long-lived flow in this context can re-use the
   definition in [I2RS-large-flow] and [OPSAWG-large-flow], where flows
   are categorized into 4 types - short-lived small flows, short-lived
   large flows, long-lived small flows and long-lived large flows. In
   this draft we are concerned with the last 2 types -- long-lived
   small flows and long-lived large flows - and we refer to these as
   long-lived flows. This identification of long-lived flows is based
   on L2/L3/L4 fields in the packet header that is consistent with that
   the definition of a flow in IPFIX [RFC 7011].

   The criteria used by the service node for identifying a long-lived
   Layer 4-7 flow can use similar criteria, with appropriate
   modification to account for long-lived small flows, as the
   techniques described in [OPSAWG-large-flow] for large flow
   identification.  The mechanics of dynamic bypass are quite different
   for different service functions and are described in the following
   sections.

   For the mechanisms in this draft, our focus is on the following SFC
   components:

Krishnan                  Expires April 2014                   [Page 3]
Internet-Draft          SFC Long Lived Flow Use Case     September 2013

     .  An SFC Control Plane Application which is responsible for
        implementing the control plane functionality and programming
        the data plane for SFC.

     .  An SFC edge, which is a switch/router responsible for
        adding/removing the service chain header to the packets.

1.1. Acronyms

   COTS: Commercial Off-the-shelf

   DOS: Denial of Service

   DDoS: Distributed Denial of Service

   ECMP: Equal Cost Multi-path

   GRE: Generic Routing Encapsulation

   LAG: Link Aggregation Group

   LSR: Label Switch Router

   MPLS: Multiprotocol Label Switching

   NVGRE: Network Virtualization using Generic Routing Encapsulation

   PBR: Policy Based Routing

   QoS: Quality of Service

   STT: Stateless Transport Tunneling

   TCAM: Ternary Content Addressable Memory

   VXLAN: Virtual Extensible LAN

2. Transparent Firewall Use Case

   A transparent firewall determines that a long-lived flow (e.g. video
   stream, file transfer) has no security issues. This long-lived flow
   is made to dynamically bypass the firewall service function but
   continue to execute the other service functions in the chain (e.g.
   NAPT). The key benefit is overall performance improvement. The event
   sequence for this use case is detailed below. Another point to note
   is that the firewall is transparent and does not perform packet
   modification.

Krishnan                  Expires April 2014                   [Page 4]
Internet-Draft          SFC Long Lived Flow Use Case     September 2013

2.1. Event Sequence

   1. The firewall examines packets of a flow and deems that it is
     benign. This can be based on many factors such as

        a.  The packets are encrypted packets which cannot be decrypted
          and examined further

        b.  The packets are from a trusted source

        c.  The packets are from a trusted application

   2. The firewall determines that the flow can be identified using a
     Layer 2/3/4 rule in the fast path.  The firewall moves the flow
     from the internal slow path (which inspects every packet) to the
     fast path (which does only switching and skips the detailed
     inspection of every packet).

   3. Based on the above criteria and also having identified the flow
     as a long-lived flow, the firewall determines that the flow is a
     benign one and does not need to be processed by the firewall any
     more.

   4. The firewall signals this information to the SFC Control Plane
     Application.

   5. The SFC Control Plane Application assigns the flow to a different
     service function chain that excludes the firewall.

   6. The flow continues to be monitored by the SFC edge switch/router
     for activity.

   7. Once the flow is detected as having become inactive, the flow is
     aged out by the SFC edge switch/router.

   8. The SFC edge switch/router signals a flow age event to the SFC
     Control Plane Application.

   9. The SFC Control Plane Application removes the dynamic service
     chain association created for the flow.

3. Long-tail content CDN Use Case

   Most popular content is of interest to a number of users; typical
   examples are newly released movies, latest television episodes, etc.
   Such content is very amenable to caching.  A single copy of the

Krishnan                  Expires April 2014                   [Page 5]
Internet-Draft          SFC Long Lived Flow Use Case     September 2013

   content is delivered to the cache; the content is delivered to
   multiple users from the cache.

   Long-tail personalized content is of interest to only a few users;
   typical examples are documentaries, older movies etc. Long-tail
   personalized content is typically not shared by many users and is
   not amenable to caching [CDNI-long-tail].  Caching of such content,
   could cause excessive thrashing of the cache.

   The idea is to improve performance by identifying such long-tail
   content and bypassing the CDN cache in the service chain for such
   content. This would be dynamic in nature, since content which is not
   so popular can become popular and vice versa. The focus will be on
   long-lived content such as movies, catch up episodes which generate
   long-lived flows. The key benefit is overall performance
   improvement. The event sequence for this use case is detailed below.

   For the purpose of this draft, our focus is on the following
   components in the CDN:

     .  CDN Monitoring System: The CDN Monitoring System monitors
        various aspects of the content such as

          o Dynamic Content Usage: Number of users simultaneously
             viewing the same content.

          o Content Life: If the content is long-lived or short-lived.
             Examples of long-lived content are movies, catch up
             episodes, etc., while examples of short-lived content are
             video clips, advertisements, etc.

     .  CDN Cache: This is the node in the network where the content
        is cached.

   For a general overview of CDNs, see [CDN-overview].

3.1. Event Sequence

   1. The CDN Monitoring System monitors the numbers of users and type
     of content being accessed. By default, we assume the CDN Cache is
     bypassed.

   2. If the number of users viewing the same content exceeds a pre-
     programmed threshold and the content is long-lived, the CDN
     Monitoring System instructs the SFC Control Plane Application to
     dynamically add a CDN Cache to the service chain for that content.

Krishnan                  Expires April 2014                   [Page 6]
Internet-Draft          SFC Long Lived Flow Use Case     September 2013

     This is done by installing a rule for that flow in the SFC edge
     switch/router.

   3. If the number of users viewing the same content falls below a
     pre-programmed threshold and the content is long-lived, the
     monitoring server instructs the SFC Control Plane Application to a
     dynamically remove a CDN Cache from the service chain for the
     content. This is done by removing the rule for that flow from the
     SFC edge switch/router.

4. Operational Considerations

   Any modification to the SFC path (due to insertion or removal of a
   service function) could result in temporary mis-ordering in the
   delivery of packets.

5. IANA Considerations

   None.

6. Security Considerations

   This draft specifies a use case for SFC and does not introduce any
   new security requirements beyond those already under consideration
   for SFC.

7. Acknowledgements

8. References

8.1. Normative References

8.2. Informative References

   [OPSAWG-large-flow] Krishnan, R. et al., "Mechanisms for Optimal
   LAG/ECMP Component Link Utilization in Networks," February 2014.

   [I2RS-large-flow] Krishnan, R. et al., "I2RS Large Flow Use Case,"
   November 2013.

   [CDNI-long-tail] Krishnan, R. et al., "Best practices and
   Requirements for delivering Long Tail personalized content delivery
   over CDN Interconnections," work in progress, May 2013.

   [CDN-overview] Dilley, J. et al., "Globally distributed content
   delivery," IEEE Internet Computing, September-October 2002.

Krishnan                  Expires April 2014                   [Page 7]
Internet-Draft          SFC Long Lived Flow Use Case     September 2013

   [RFC 7011] Claise, B., "Specification of the IP Flow Information
   Export (IPFIX) Protocol for the Exchange of Flow Information,"
   September 2013.

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

Authors' Addresses

   Ram Krishnan
   Brocade Communications
   ramk@brocade.com

   Anoop Ghanwani
   Dell
   anoop@alumni.duke.edu

   Joel Halpern
   Ericsson
   joel.halpern@ericsson.com

   Sriganesh Kini
   Ericsson
   Sriganesh.kini@ericsson.com

   Diego Lopez
   Telefonica
   diego@tid.es

Krishnan                  Expires April 2014                   [Page 8]