SFC WG T. Ao
Internet-Draft ZTE Corporation
Intended status: Informational G. Mirsky
Expires: September 14, 2017 ZTE Corp.
March 13, 2017
Analysis of the SFC scalability
draft-ao-sfc-scalability-analysis-02
Abstract
SFC is an ordered set of service function, should be scalable to meet
numerous requirements. The scalability of SFC can be interpreted as
ability of the SFC to accommodate one or more SFs joining the SFC ,
or leaving the SFC without significant impact to SFC performance.
This document presents four use cases on SFC scale-out and scale-in,
and analysis of the requirements to support such capability.
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 September 14, 2017.
Copyright Notice
Copyright (c) 2017 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. Code Components extracted from this document must
Ao & Mirsky Expires September 14, 2017 [Page 1]
Internet-Draft Analysis of the SFC scalability March 2017
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. Four Use cases for scale-out/scale-in . . . . . . . . . . . . 3
3.1. Join . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Redundancy . . . . . . . . . . . . . . . . . . . . . . . 3
3.3. By-pass . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.4. Failure or Remove . . . . . . . . . . . . . . . . . . . . 4
4. Data Plane Requirements . . . . . . . . . . . . . . . . . . . 4
5. Control Plane Requirements . . . . . . . . . . . . . . . . . 5
5.1. Centralized CP . . . . . . . . . . . . . . . . . . . . . 5
5.2. Distributed CP . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Information References . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
Service Function Chain (SFC) is the chain with a series of ordered
Service Functions(SF). The SFC maybe changed because of load balance
, failure, or other management requirement. We call it SFC
scalability. The SFC being scalable means that the Service Functions
can be added or removed from the path of this SFC. With this
capability, SFC is more flexible and elastic to adapt all kinds of
requirements.
In this document, we will present four use cases on SFC scale-out and
scale-in, and analysis some requirements to support such capability.
2. Terminology
SFC(Service Function Chain): An ordered set of some abstract SFs.
SFC Scale-out: One or more SFs are added into the path of the SFC for
the sake of load balance, protection or other new services
requirement.
SFC Scale-in: One or more SFs are removed from the path of the SFC
for the sake of the SFs are by-passed or the SFs are failed.
Ao & Mirsky Expires September 14, 2017 [Page 2]
Internet-Draft Analysis of the SFC scalability March 2017
3. Four Use cases for scale-out/scale-in
Following describe four use cases to illustrate the scalability of
the SFC.
3.1. Join
This is SFC horizontal scale-out use case. One or more new SFs must
be added to a certain SFC for the traffic that has been classified to
require application of new SF(s). This case is the reverse scenario
to the by-pass. In this case one or more SFs that were by-passed
need to be re-inserted into the SFC. And the SFC itself can be
characterized as being scaled out.
There are two sub-cases of an SF joining the SFC. One when both the
SF and corresponding SFF are new to the SFC. The second is when the
SF attaches to an existing SFF. In the first scenario, control plane
needs to notify the upstream SFF to modify its next hop to point to
the new SFF and configure the new SFF's forwarding information. In
the second scenario control plane needs to configure the existing
SFF's forwarding information. In this scenario, SFF forwards the
packets not only according to the SFPID but also according to the
metadata in the SFC header.
3.2. Redundancy
This is an example of SFC vertical scale-out use case. One or more
SFs are added into the SFC to meet the redundancy or load balance
requirements. This case is different with the Join case (section
3.1) in that the SF is the same with one of the SF that is on the
path of the SFC. The new SF have the same function with the existing
SF, and the new SF is added into the SFC to protect the existing
corresponding SF and to load balance the existing corresponding SF.
In this case, control plane need to notify the upstream SFF that the
new SF joins the SFC as a redundancy SF for protection or load
balance, and its next hop should be a protection group or ECMP group.
For the purpose of load balance to ensure proper forwarding, the Flow
Id field MUST be present in the NSH as expression of entropy so that
SFF can select an SF from the group according to the Flow Id.
3.3. By-pass
This is a horizontal scale-in case. In this scenario some SFs are
not removed from the SFC but just by-passed by the traffic so that
the packets will not be processed by these SFs. Use cases for this
scenario are described in [draft-ietf-sfc-long-lived-flow-use-cases]
and [draft-kumar-sfc-offloads] . In these two drafts, the SF is
Ao & Mirsky Expires September 14, 2017 [Page 3]
Internet-Draft Analysis of the SFC scalability March 2017
offloaded because it is not necessary to steer the traffic to the SFs
to improve the forwarding performance.
The corresponding solution is also provided in the above drafts.
3.4. Failure or Remove
This is a vertical SFC scale-in case. This happens when the SFC is
being protected or load balanced. When SF in one SFC has failed or
needs to be removed because it is no longer needed the ability of the
SFC to scale-in is excercised.
For this case the upstream SFF must be notified that its next hop
must be changed to the next SF of the SF.
From the cases described we can conclude that no matter if is SFC
scale-out case or scale-in cases, there are some requirements to SFC
control protocol. And for some cases, there are requirements to data
plane as well.
4. Data Plane Requirements
For the cases of load balancing or protection switch it is highly
beneficial to have an entropy field in the SFC header to be used by
the. The entropy field can be named as Flow ID which should be in
SFC header.
This means that Classifier not only classifies the traffic based on
different SFPID, but using Flow ID as well.
According to the NSH draft in draft--ietf-sfc-nsh-12, we propose to
extend NSH to include the entropy field. Two options can be
considered. One is to use existing field, for example, some reserved
bits. Extended field in NSH Service Path Header is showed below as
an example.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path Identifier (SPI) | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flow ID |
+-----------------------------------------------+---------------+
Another is to extend a new metadata to meet the requirement. Which
has been described in draft draft-quinn-sfc-nsh-tlv-02 section 8.
Ao & Mirsky Expires September 14, 2017 [Page 4]
Internet-Draft Analysis of the SFC scalability March 2017
5. Control Plane Requirements
Another is to extend a new metadata to meet the requirement. Which
has been described in draft draft-quinn-sfc-nsh-tlv-02 section 8.
5.1. Centralized CP
Controller is required to:
a) Send a message to SFF that the joined SF connected to set the
correct SFPID and its next hop.
b) Send register message to previous SFF with some information. Such
information not only includes next hop locator, but also includes an
indicator that if the next hop is a new joined SF or the next hop is
a new SF that added into a group. If the indicator is a new joined
SF, it means a new SF will join the SFC. If the indicator is a group
SF, it means a new SF will be added into a group for load balance or
protection.
c) Send de-register message to previous SFF with some information.
Such information not only includes next hop locator, but also
includes an indicator that if the next hop is the next SF because the
current SF is by-passed, or the next hop is the SF that is removed
from a group. If the indicator is the by-passed SF, it means the
current SF is by-passed or is leaving from the SFC. If the indicator
is group SF, it means the current SF will be removed into a
protection group that is for load balance or protection.
5.2. Distributed CP
Distributed CP can be used in Plug-and-Play scenario. Distributed CP
requires:
a) The SF that needs to join the SFC or by-pass from the SFC should
notify the SFF it connects by a message.
b) The SFF should send a register message to the previous SFF with
some information. Such information not only includes next hop
locator, but also includes an indicator that if the next hop is a new
joined SF or the next hop is a new SF that added into a group. If
the indicator is a new joined SF, it means a new SF will join the
SFC. If the indicator is a group SF, it means a new SF will be added
into a group for load balance or protection.
c) The SFF send de-register message to previous SFF with some
information. Such information not only includes next hop locator,
but also includes an indicator that if the next hop is the next SF
Ao & Mirsky Expires September 14, 2017 [Page 5]
Internet-Draft Analysis of the SFC scalability March 2017
because the current SF is by-passed, or the next hop is the SF that
is removed from a group. If the indicator is the by-passed SF, it
means the current SF is by-passed or is leaving from the SFC. If the
indicator is group SF, it means the current SF will be removed into a
protection group that is for load balance or protection.
6. Security Considerations
For the scalability of the SFC, security is very important to be
considered. Before allow the SF to join to the SFC, it is required
to make sure the SF's security first.
7. IANA Considerations
TBD
8. Information References
[I-D.ietf-sfc-architecture]
Halpern, J. and C. Pignataro, "Service Function Chaining
(SFC) Architecture", draft-ietf-sfc-architecture-11 (work
in progress), July 2015.
[I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header", draft-
ietf-sfc-nsh-12 (work in progress), February 2017.
[RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for
Service Function Chaining", RFC 7498,
DOI 10.17487/RFC7498, April 2015,
<http://www.rfc-editor.org/info/rfc7498>.
Authors' Addresses
Ting Ao
ZTE Corporation
No.889, BiBo Road
Shanghai 201203
China
Phone: +86 21 68897642
Email: ao.ting@zte.com.cn
Ao & Mirsky Expires September 14, 2017 [Page 6]
Internet-Draft Analysis of the SFC scalability March 2017
Greg Mirsky
ZTE Corp.
1900 McCarthy Blvd. #205
Milpitas, CA 95035
USA
Email: gregimirsky@gmail.com
Ao & Mirsky Expires September 14, 2017 [Page 7]