Internet DRAFT - draft-chen-sfc-traffic-offloading
draft-chen-sfc-traffic-offloading
Network Working Group H. Chen, Ed.
Internet-Draft J,. Yang, Ed.
Intended status: Informational Huawei Technologies Co,. Ltd.
Expires: August 18, 2014 February 14, 2014
Utilizing traffic offloading to relieve burden of service node
draft-chen-sfc-traffic-offloading-00
Abstract
This document analysis the possibility to relieve the burden of
service node via introducing the traffic offloading mechanism into
the service function chain scenario, which may ultimately improve the
network efficiency.
Requirements Language
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 [RFC2119]
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 August 18, 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
Chen & Yang Expires August 18, 2014 [Page 1]
Internet-Draft traffic offloading February 2014
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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Concept of traffic offloading . . . . . . . . . . . . . . . . 3
4. Operation of traffic offloading . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Static deployment of service function in traditional network cannot
fulfill nowadays requirement, such as adding and removing new
services/functions elastically. In this case, service function chain
(SFC) was introduced into the current network deployment. It may
realize the end-to-end service functions delivery, including the
traditional functions (e.g. firewalls, NAT, WAN optimization) as well
as the application specific functions.
This document proposes the traffic offloading mechanism, which mainly
exploits the spare capacity of service entities (including the
classifier, the service nodes), to effectively increase the
utilization rate of these devices. This document discusses the
possibility to realize traffic offloading among the service entities
along the same service path, and besides illustrates optional
implementation methods for reference.
2. Terminology
This document makes use of the following terms, additional terms are
defined in [I-D.ietf-sfc-problem-statement].
Service function: A network or application based packet treatment,
application, compute or storage resource, used singularly or in
concert with other service functions within a service chain to enable
a service offered by a network operator.
Chen & Yang Expires August 18, 2014 [Page 2]
Internet-Draft traffic offloading February 2014
Classifier: Locally instantiated policy and customer/network/service
profile matching of traffic flows for identification of appropriate
outbound forwarding actions.
Service node: Physical or virtual element providing one or more
service functions.
Service entity: network device including the classifier and the
service node.
Service function chain: A service chain defines the required
functions and associated order that must be applied to packets and/or
frames. A service chain does not specify the network location or
specific instance of service functions.
Service path: Instance of service function chain.
3. Concept of traffic offloading
A typical service function chain may consist of a classifier node
followed by one or more service nodes in a certain order. Figure.1
shows a simple example of service function chain, where CF represents
the classifier node while SN_1, SN_2 and SN_3 represent three service
nodes respectively. Service node may be any kind of service function
according to the requirement, such as firewall, load balancer, IPS,
IDS or WAN optimizer and so on. In this simple example, traffic
flows firstly come into CF that executes the flow identification
function. CF is responsible for distinguishing and marking flow that
need to be forwarded to the following service entity (e.g. SN_1).
The service path in this example can be indicated as
CF->SN_1->SN_2->SN_3, as the dash line shows in Figure.1.
*********************************************
* *
+-----*----+ +----------+ +-----*----+ +----------+
|****** | | | | *****|**********|**** |
----->| CF |--------->| SN_1 |--------->| SN 2 |--------->| SN 3 |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
flow table entry flow table entry
a,b,c b,c
Figure 1: Traffic offloading example
In some situations, it is possible that the adjacent nodes along the
same service path have some flow table entries in common, or the
upstream service entity is able to support the some flow rules that
hold by the downstream node. The action field of these flow table
Chen & Yang Expires August 18, 2014 [Page 3]
Internet-Draft traffic offloading February 2014
entries could be Drop, Pass-through or Forward. For example,
assuming SN_1 has the flow table entries b and c, CF has the flow
table entries a, b and c. In this case, it is possible to process
this flow traffic according to the action field of flow table entry b
and c on CF instead of on SN_1, which means CF is able to offload
traffic for SN_1. Consequently, the service path will be changed
from previously CF->SN_1->SN_2->SN_3 to CF->SN_2->SN_3, as the star
line shows in Figure.1. The condition to perform traffic offloading
is that CF is capable to perform the same rules.
This situation may also exist between two adjacent service nodes,
such as between SN_1 and SN_2, or between SN_2 and SN_3, as long as
they have flow table entries in common.
Traffic offloading will not degrade the performance significantly,
especially when the upstream node (e.g. CF in Figure.1) implement the
traffic flow processing in hardware fashion, for example, the ASIC
based flow processing. The benefit is obvious: it may relieve the
burden of the downstream service entity by implementing traffic
offloading between the adjacent nodes along the service path.
Considering that the service entity may be implemented by different
venders, it is necessary to find a way to set up the traffic
offloading mechanism among service entities along the same service
path.
4. Operation of traffic offloading
To illustrate, Figure.2 shows one of the possible method to realize
the traffic offloading along the service path.
MS represents the SFC management system. It manages all of the
service entities, including the classifier (CF) and service node
(SN_1, SN_2) within the same autonomous domain. The main function of
MS is to get the requirements from upper application, including the
type of service functions required and their relative order with
which the flow is going to go through. According to this
information, MS begins to configure the service entities within the
same autonomous domain. It creates the service path identifier for
each flow, and then distributes it to the service entities.
Chen & Yang Expires August 18, 2014 [Page 4]
Internet-Draft traffic offloading February 2014
+-----------------------+
+---1-----| MS |----1----+
| | | |
| +-----------+-----------+ |
| 1 |
| | |
+-----V----+ +-----V----+ +-----V----+
| |----2---->| |----2---->| |
| CF | | SN_1 | | SN_2 |
| |<---3-----| |<---3-----| |
+-----+----+ +----------+ +-----^----+
| |
| |
+---------------------4---------------------+
Figure 2: Method A for traffic offloading
1. According to requirements from upper application, MS chose the
proper service nodes to realize corresponding service functions.
MS can be realized in the form of a standalone system or a
component of a large-scale system, for example, component of a
SDN controller. For example, on receiving the requirements from
upper application, MS selects CF, SN_1 and SN_2 to form a
specific service path. The relative order that the flow has to
go through is CF->SN_1->SN_2.
2. After configured by MS, each service entity along the service
function path has to notify its own downstream nodes of its own
support capability of flow table. In figture.2, CF has to notify
its own downstream node SN_1, and SN_1 has to notify its own
downstream node SN_2. The capability of flow table support
refers to the match fields that flow table can support, and the
actions that can be apply to packet flow. If the upstream node
has already notified its downstream node in other service
function path, then there is no need to repeat the notification
process. On receiving the notification from its own upstream
node, the downstream node will make record of the match fields
and actions that upstream node is able to support.
3. When the first packet of flow arrives at CF, CF will forward this
packet to its own downstream node SN_1 according to the generated
flow table entry. On receiving the first packet of flow from CF,
SN_1 generates the corresponding flow table entry. SN_1 will
compare this generated flow table entry with CF's support
capability of flow table that was previously recorded to see if
there is any match entry.
Chen & Yang Expires August 18, 2014 [Page 5]
Internet-Draft traffic offloading February 2014
* If the result is NO, which indicates that CF is not able to
offload the traffic for SN_1, then SN_1 will not reply to CF.
It will forward this first packet to SN_2 according to certain
policy after processing it. SN1 will process the residual
packets of this flow on its own.
* If the result is YES, which indicates that CF is able to
offload the traffic for SN_1, then SN_1 will notify CF the
generated flow table information, including the corresponding
match fields and actions.
4. On receiving the information of flow table entry, CF1 will add it
to its own flow table or update its own flow table. When the
residual packets of this flow arrived, CF will take SN_1's place
to process them instead, and then will forward these packets
directly to SN_2 rather than forward them to SN_1 as before.
Figure.3 shows an alternative method to implement the traffic
offloading in SFC scenario. MS represents the SFC management system.
It manages all of the service entities, including the classifier (CF)
and the service nodes (SN_1 and SN_2).
1. At the network initialization phase, each service entities have
to announce its capability of flow table support to MS
proactively, including the match field of flow table, and the
actions that can be apply to the traffic flow. On receiving
these announcements, MS makes records for each service entity.
For example, CF, SN_1 and SN_2 send the announcement to MS, MS
makes records for each of them.
2. MS pushes each service entity's capability of flow table support
to its downstream service entity. For example, MS pushes CF1's
capability of flow table support to SN_1, and pushes SN_1's
capability of flow table support to SN_2.
The following procedures are the same as steps 3 and 4 in method A.
It is not necessary to describe repeatedly.
Chen & Yang Expires August 18, 2014 [Page 6]
Internet-Draft traffic offloading February 2014
+-----------------------+
+----2----| MS |----2-----+
| +--1--->| |<---1---+ |
| | +-----------+-^---------+ | |
| | 2 1 | |
| | | | | |
+----V-+---+ +----V-+---+ +---+-V----+
| | | | | |
| CF |<---3-----| SN_1 | | SN_2 |
| | | | | |
+-----+----+ +----------+ +-----^----+
| |
| |
+---------------------4---------------------+
Figure 3: Method B for traffic offloading
This document does not specify the concrete formats for the
capability of flow table support. Alternative options may refer to
the flow table's format defined in [Openflow-Specification].
Iteration operation may be applied to the traffic offloading
procedure. It means that after offloading for the downstream service
entity successfully, the upstream service entity may try to offload
traffic for the service entity next to its downstream service entity.
For example, if CF successfully offloads the traffic for SN_1, then
it may try to offload for SN_2. Recursively, if CF has successfully
offloaded traffic for SN_2, it may try to offload for SN_2's
downstream service entity (SN_3).
5. Security Considerations
Security considerations are not addressed in this document.
6. IANA Considerations
No IANA action is needed for this document.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Chen & Yang Expires August 18, 2014 [Page 7]
Internet-Draft traffic offloading February 2014
7.2. Informative References
[I-D.ietf-sfc-problem-statement]
Quinn, P., Ed., "Service Function Chaining Problem
statement, <draft-ietf-sfc-problem-statement-00>", January
2014.
[Openflow-Specification]
"https://onfa.amsl.com/sdn-resources/onf-specifications/
openflow", .
Authors' Addresses
Hao Chen (editor)
Huawei Technologies Co,. Ltd.
101 Software Ave., Yuhuatai Dist.
Nanjing, Jiangsu 210012
China
Phone: +86 025-5662-5335
Email: philips.chenhao@huawei.com
Jishang Yang (editor)
Huawei Technologies Co,. Ltd.
Huawei Base, Bantian, Longgang Dist.
Shenzhen 518129
China
Phone: +86 755-2842-9186
Email: Yangjishang@huawei.com
Chen & Yang Expires August 18, 2014 [Page 8]
