Internet DRAFT - draft-krishnan-sfc-long-lived-flow-use-cases
draft-krishnan-sfc-long-lived-flow-use-cases
SFC Working Group R. Krishnan
Internet Draft Brocade Communications
Category: Informational A. Ghanwani
Dell
J. Halpern
S. Kini
Ericsson
D. R. Lopez
Telefonica I+D
Expires: October 2014 April 21, 2014
SFC Long-lived Flow Use Cases
draft-krishnan-sfc-long-lived-flow-use-cases-02
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. IPsec Management in Mobile Environments........................7
4.1. Event Sequence............................................7
5. Operational Considerations.....................................8
6. IANA Considerations............................................8
7. Security Considerations........................................8
8. Acknowledgements...............................................8
9. References.....................................................8
9.1. Normative References......................................8
9.2. Informative References....................................8
Authors' Addresses................................................9
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. IPsec Management in Mobile Environments
Existing security procedures for flow protection in LTE are based on
the use of IPsec tunnels between the radio base stations (eNodeBs)
and some central node in the core, where a security gateway (SecGW)
is deployed. The eNodeB device located on the cell site initiates
the IPSec tunnel through the backhaul network to the SecGW, where
the tunnel is terminated and the traffic is forwarded towards its
final destination. IPsec ESP is the method that LTE standards use
for achieving the required levels of security [TS33.401].
To avoid traffic bottlenecks and in order to guarantee a high level
of service availability, a recommended practice is the concurrent
use of several SecGW devices. The one that is to be used for a
given traffic flow may be determined by several criteria such as the
origin of the traffic (user traffic vs network control), flows with
well-known characteristics, e.g. security properties (HTTPS, secure
VPNs), etc. In this way, more critical traffic can be prioritized,
and different levels of security can be applied depending of payload
characteristics.
Such an optimization could be applied as well to long-lived flows in
a dynamic way, relaxing security procedures for non-sensitive ones,
e.g. it may not be necessary to secure a well-known video stream
that is openly available, applying differentiated policies to avoid
congestion, or even hardening the security procedures according to
the user's data profile.
4.1. Event Sequence
1. A monitoring element such as a DPI appliance analyzes the new
flows arriving at the default SecGW device used by a given eNodeB
device according to criteria such as:
. Security payload protection;
. Application and transport protocol(s) in use;
Krishnan Expires April 2014 [Page 7]
Internet-Draft SFC Long Lived Flow Use Case September 2013
. Relevant parameters in those protocols (URL, content-transfer
declarations, etc.).
2. If the monitoring element identifies a long-lived flow that
matches its differentiating criteria, it signals the flow to the
SFC Control Plane Application.
3. The SFC Control Plane Application assigns the flow to a different
service function chain that makes the eNodeB device use a
different SecGW device.
4. Once the flow is becomes inactive, it is aged out by the eNodeB
device and signaled as such to the SFC Control Plane Application.
5. The SFC Control Plane Application removes the dynamic service
chain association that was created for the flow.
5. 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.
6. IANA Considerations
None.
7. 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.
8. Acknowledgements
9. References
9.1. Normative References
9.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.
Krishnan Expires April 2014 [Page 8]
Internet-Draft SFC Long Lived Flow Use Case September 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.
[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.
[TS33.401] 3GPP Technical Specification 33.401, "Security
Architecture," December 2013.
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 I+D
Don Ramon de la Cruz, 82 Street
Madrid, 28006, Spain
+34 913 129 041
diego@tid.es
Krishnan Expires April 2014 [Page 9]
Internet-Draft SFC Long Lived Flow Use Case September 2013
Krishnan Expires April 2014 [Page 10]
