Internet DRAFT - draft-wei-sfc-re-classification
draft-wei-sfc-re-classification
INTERNET-DRAFT X.Wei
Intended Status: Proposed Standard Huawei Technologies
Expires: January 1, 2015 June 30, 2014
Re-classification analysis in SFC
draft-wei-sfc-re-classification-00
Abstract
Service Function Chaining (SFC) provides the ability to classify and
steer a flow via some network service(s). Some traffic flows require
re-classification to a new service chain. This may be, for example,
the result of further analysis of initial packets, or detection of
multiple types of media. This document discusses re-classification
scenarios in SFC, and several deployment models for the re-classifier
and relevant analysis are provided. The proposal will recommend some
architectural constraints for the SFC design.
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
X.Wei Expires January 1, 2015 [Page 1]
INTERNET DRAFT Re-classification analysis in SFC June 30, 2014
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. 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 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Case 1: Classifier lacks information about the traffic . . 4
2.2 Case 2: Traffic bypasses certain SF . . . . . . . . . . . . 5
2.3 Case 3: Multiple content types in the same flow . . . . . . 5
3 Deployment models of re-classifier . . . . . . . . . . . . . . 6
3.1 Classifier plays the role of re-classifier . . . . . . . . 6
3.2 Re-classifier deployed independent from classifier . . . . 7
3.2.1 Re-classifier integrated with SF . . . . . . . . . . . 7
3.2.2 Re-classifier independent from SF . . . . . . . . . . . 8
4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10
5 Security Considerations . . . . . . . . . . . . . . . . . . . . 10
6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 10
7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1 Normative References . . . . . . . . . . . . . . . . . . . 10
7.2 Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
X.Wei Expires January 1, 2015 [Page 2]
INTERNET DRAFT Re-classification analysis in SFC June 30, 2014
1 Introduction
Service Function Chaining (SFC) provides flexible configuration of
services that are connected through the network. The requirements and
problem space have been widely discussed in [PS], and several
different SFC frameworks have been proposed in [Quinn],[Boucadair]
and [Jiang] etc. These frameworks can be divided into four logical
components: a centralized SFC controller, classifier, Service
Function (SF) instance and SFC forwarding entity. The SFC controller
is in charge of constructing service function chain for network
traffic and certain network configurations; classifier is used to
perform traffic classification, it classifies packets and adds a SFC
ID, which is used to steer the packet along certain service chain,
for each packet; SF instances are deployed to provide network service
functions to traffics; SFC forwarding entities are in charge of
forwarding packets to specific SF instances according to SFC ID
contained in packets.
The concept of SFC ID is used to steering traffic along different
service function chain, and additional information named as
'metadata' could also be used to convey information between SF
instances or between classifier and SF instance.
In SFC network, classifier maintains < match rule, service chain >
pairs for classifying traffic to different service chain, and two of
the most important role of classifier is classifying packets based on
matching rules and tagging the packets with appropriate service chain
ID according to the classification result.
The criteria to classify traffic could be based on different kinds of
information, including simple information such as 5-tuple in IP
header field, or complex information such as the processing result of
DPI function. Because the classifier functional entity is located at
the entrance of SFC domain and all of the traffic enters SFC domain
through classifier, and it's possible for classifier to deal with a
large amount of traffic, so in order to reduce the load of classifier
and to accelerate the processing speed, the match ruling used by
classifier should be simple, for example using 5-tuple of packet
header as match rule. It would be better for classifier only to
implement network logic in dealing with traffic; and leave other
specific SFs to implement service logic.
Normally, classifier is deployed at the boundary of SFC domain, and
traffic is classified when it enters the SFC domain. But in some
cases, it is not possible to classify the traffic properly the first
time traffic enters the SFC domain, because the classifier might not
get sufficient information about the traffic and could only classify
traffic coarsely based on some simple information. In other cases,
X.Wei Expires January 1, 2015 [Page 3]
INTERNET DRAFT Re-classification analysis in SFC June 30, 2014
the traffic flow might need to be steered to a different service
chain, for example, due to the processing result of a certain SF,
after it first classified at the entrance of SFC domain. In these
cases, a re-classification of the traffic flow is needed. By re-
classification, it is meant that the service chain ID of the traffic
is changed to a new one, after it enters SFC domain.
We name the classifier that implements re-classification action as
re-classifier here.
In this document we discuss re-classification scenarios and related
re-classifier deployment models in SFC domain.
1.1 Terminology
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 [RFC2119].
Match rule: The rule that used by classifier to match the traffic to
a specific service chain. For example, match rule
could be in the form of 5-tuple in IP header.
SFE: Service Forwarding Entity. Forwarding entity in SFC domain,
which forwards traffic along the service chain based
on service chain ID.
SFC domain: A network that implements SFC.
2. Scenarios
This section provides several re-classification scenarios in SFC
domain. Based on the scenarios discussed here, analysis of impacts of
re-classification on SFC framework will be provided in the following
section.
2.1 Case 1: Classifier lacks information about the traffic
When a flow enters SFC domain for the first time, SFC domain may have
little or coarse-grained information, about the flow, e.g. which
subscriber the flow belongs to, and more detailed, fine-grained
information such as application type, security status or others may
not be known. So classifier first classifies the packet according to
coarse-grained information to a service chain, and the processing
result of certain SF along the service chain could provide fine-
grained information about the traffic, and then the re-classifier
steers the traffic to another service chain based on the fine-grained
information.
X.Wei Expires January 1, 2015 [Page 4]
INTERNET DRAFT Re-classification analysis in SFC June 30, 2014
There are different SFs that could provide fine-grained information
about the traffic, for instance, DPI (Deep Packet Inspection) can
analyze the content of packet and determine the application type of
the traffic, and then different kind of application traffic for the
same subscriber could be steered to different service chain.
2.2 Case 2: Traffic bypasses certain SF
The use case of long-lived flow is introduced in [Krishnan]. B.
After the long-lived flow has been processed by certain expensive or
highly specialized SF, subsequent packets could be steered to bypass
this SF in order to save processing resource. [Krishnan] also
provides several examples of this kind of SF such as transparent FW,
CDN (Content Delivery Network).
When traffic has to bypass a SF of the service chain, it means the
traffic should go through a different service chain. It thus means
that re-classification of the traffic is needed. Figure 1 shows an
example for this scenario.
service chain 2
+------------+
| |
+----------+ +---+ | +--+ | +---+
traffic| |------| |--+ | | +---| |-----
====> |classifier| |SF1| |FW| |SF3|
| |------| |------| |---------| |-----
+----------+ +---+ +--+ +---+
service chain 1
Figure 1 Traffic bypasses certain SF
In Figure 1, after a long-lived traffic flow enters the SFC domain
for the first time, it is classified to service chain 1, which
consists of a Firewall (FW). When the FW inspects the traffic and
determines that it is from a trusted source, the traffic can
subsequently bypass the FW. This requires re-classification that
allows the flow to go through another service chain, e.g. service
chain 2.
2.3 Case 3: Multiple content types in the same flow
In some applications, such as Web services using HTTP, different
types of content may be transmitted in the same flow, i.e. belonging
to the same TCP session. For example, when a user starts a TCP
connection to YouTube and gets content using HTTP, there will be
different kinds of media such as text, audio and video transmitted
over the same TCP session.
X.Wei Expires January 1, 2015 [Page 5]
INTERNET DRAFT Re-classification analysis in SFC June 30, 2014
For such flows, the content of different kinds might benefit from
different network services, i.e. go through different service chain,
for instance, in the same HTTP session, video may go through video
optimizer, while text doesn't need any optimization. Though the
classifier may determine the application type, e.g., based on port
number, it not viable to assume that the classifier can distinguish
different contents in traffic.
video
+----------+ +---+ +---+ +----------+ +---+
traffic| |--| |--| |-----| |----| |--
====> |classifier| |SF1| |SF3| |video opt.| |SF2|
| |--| |--| |--+ | | +-| |--
+----------+ +---+ +---+ | +----------+ | +---+
+----------------+
non-video
Figure 2 Example of re-classification of HTTP traffic
3 Deployment models of re-classifier
There are two different deployment models for the re-classification
function, and this section will discuss these two models in detail.
3.1 Classifier plays the role of re-classifier
When traffic enters SFC domain through classifier, it will be
classified to certain service chain based on matching rule configured
in classifier. And then traffic is steered to specific SF instances
along the service chain. In this sub-section, we discuss the re-
classification mechanism that classifier plays the role of re-
classifier and used to re-classify traffic to a different service
chain, according to the procession result.
An overview description of this mechanism is depicted in Figure 3. If
the processing result of certain SF would affect the service chain of
a traffic flow, the SF reports processing result to controller to
provide more detailed information about the traffic; after receiving
traffic information from SF, controller could choose to form a new
service chain for the traffic, and then controller updates the <match
rule, service chain> pair in classifier; after updating of <match
rule, service chain> pair, classifier uses the new <match rule,
service chain> pair to classify the traffic. For example, in Figure
3, when traffic passes through classifier at the first time, it is
classified to service chain 1 consisting SF1, SF2 and SF3 by
classifier, the processing result of the traffic by SF2 would affect
the classification behavior of classifier, and then classifier
classifies the traffic to a different service chain 2 consisting of
X.Wei Expires January 1, 2015 [Page 6]
INTERNET DRAFT Re-classification analysis in SFC June 30, 2014
SF4 and SF5.
update <match rule,
service chain> +----------+
+-------------|controller|
| +----------+
| ^reporting of processing
| | result
V |
+----------+ +---+ +---+ +---+
traffic | |---|SF1|----|SF2|----|SF3|---
======>|classifier| +---+ +---+ +---+
| |--+ service chain 1
+----------+ |
|
| +---+ +---+
+-|SF4|-------|SF5|--------
+---+ +---+
service chain 2
Figure 3: Classifier plays the role of re-classifier
Analysis:
- In this case, SF2 could be any kind of Service Function, such as
Firewall, DPI etc, whose processing result of traffic flow could
change the service chain of the traffic.
- This mechanism needs an interface to convey SF's processing result
from SF to controller. The information conveyed from the SF to
controller should at least include flow information and the
processing result information. The protocol used in this interface
could based on the existing protocols, such NetConf [RFC6241],
Diameter [RFC6733] etc, or a new protocol might be needed.
- After the traffic flow is re-classified, the SF that cause the re-
classification, i.e. SF2 in Figure 3, might not be included any
more in the new service chain, so if the SF maintains state for the
traffic flows state information, there should be a mechanism to
release the state.
3.2 Re-classifier deployed independent from classifier
Besides the scheme described in sub-section 3.1, this sub-section
provides another re-classification scheme in which re-classifier
functionality is deployed independent from classifier which is
deployed at the boundary of the SFC domain.
3.2.1 Re-classifier integrated with SF
In this case, the re-classifier is integrated with specific SF,
e.g. FW, DPI etc, and it could re-classify traffic to a different
X.Wei Expires January 1, 2015 [Page 7]
INTERNET DRAFT Re-classification analysis in SFC June 30, 2014
service chain according to the processing result of traffic by the
SF.
The traffic is first classified by classifier at the boundary of
SFC domain, and then forwarded to specific SFs according to service
chain ID encapsulated in traffic. When traffic goes through a SF
which is integrated with re-classifier functionality, and the
traffic needs to go through a different service chain, re-
classifier could re-tag a new service chain ID in the traffic.
traffic---------+ +---+ +---+-------------+ +---+ +---+
==>|classifier|--|SF1|---|SF2|re-classifier|--|SF3|--|SF4|--
+----------+ +---+ +---+-------------+ +---+ +---+
|
|
+---+ +---+
|SF5|----|SF6|--------------
+---+ +---+
Figure 4 Re-classifier integrated with SF
Analysis:
- In this case, an interface between SFC controller and the SF that
integrated with re-classifier functionality is needed to configure
re-classifier with <match rule, service chain> pair. The protocol
used in this interface could be the same as the interface between
SFC controller and classifier.
- The re-classification in this deployment model only impacts the
path that behind the SF which implements re-classification
functionality.
- This scheme provides a more flexible choice to implement traffic
re-classification, one or more re-classifier could be deployed in a
SFC domain.
3.2.2 Re-classifier independent from SF
In cases that SF, which could impact service chain that the traffic
goes through, is not integrated with a re-classifier, especially for
legacy SF, a re-classifier independent from SF could be deployed.
For the re-classifier independent from SF there are also several
deployment choices, for example, re-classifier could be deployed as
an independent entity and attach to the output interface of specific
SF; or re-classifier could be integrated with SFE.
When the traffic is processed by SF, the re-classifier could re-
classify the traffic according to the output interface of SF or
according to processing result information taken in the traffic, e.g.
X.Wei Expires January 1, 2015 [Page 8]
INTERNET DRAFT Re-classification analysis in SFC June 30, 2014
the information in metadata.
service chain 1
traffic---------+ +---+ +---+ +---+ +---+
===>|classifier|->|SF1|-->|SF2| |SF3|--|SF4|----
+----------+ +---+ +-|-+ +|--+ +---+
| |
+----------|--------|------------+
| +-|--------|-+ |
| SFE | classifier| |
| +-----|------+ |
+--------------|-----------------+
|
+-|-+ +---+
|SF5|----|SF6|--------
+---+ +---+
service chain 2
Figure 5: Re-classifier integrated with SFE
Analysis:
- In this case, SF is not required to support re-classification
functionality.
- When integrated with SFE, the re-classifier could be shared by more
than one SF.
- The processing result of SF should be conveyed in certain method to
re-classifier, as discuss above the method used here could be
judging from the output interface of SF or according to processing
result information taken in the traffic, e.g. the information in
metadata (in-band signal).
- An interface between SFC controller and re-classifier is needed to
provision the re-classifier, if the re-classifier is integrated
with SFE, then the interface between SFC controller and SFE could
be used to exchange information between SFC controller and re-
classifier; otherwise an independent interface between SFC
controller and re-classifier should be exist.
X.Wei Expires January 1, 2015 [Page 9]
INTERNET DRAFT Re-classification analysis in SFC June 30, 2014
4 IANA Considerations
This document requires no requirement for IANA.
5 Security Considerations
Security related issues is not involved.
6 Acknowledgments
Many thanks to John Kaippallimalil and Chunshan Xiong (Sam) for their
valuable comments.
7 References
7.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, June 2011.
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
Ed., "Diameter Base Protocol", RFC 6733, October 2012.
7.2 Informative References
[Krishnan] R. Krishnan et al. "draft-krishnan-sfc-long-lived-flow-
use-cases", April 21, 2014
[Quinn] P. Quinn et al. "draft-quinn-sfc-arch-05", May 5, 2014
[Boucadair] M. Boucadair et al. "draft-boucadair-sfc-framework-02",
February 12, 2014
[Jiang] Y. Jiang. "draft-jiang-sfc-arch-01", February 14, 2014
Authors' Addresses
Xinpeng Wei
EMail: weixinpeng@huawei.com
X.Wei Expires January 1, 2015 [Page 10]
