Internet DRAFT - draft-kang-sfc-dynamic-path-selection
draft-kang-sfc-dynamic-path-selection
SFC T. Kang
Internet-Draft Y. Han
Intended status: Informational S. Kim
Expires: April 21, 2016 E. Paik
N. Kim
KT
October 19, 2015
Dynamic Service Path Selection over Multiple Links between SFF and SF
for Enhancing Service Stability
draft-kang-sfc-dynamic-path-selection-01
Abstract
In this document, we use SF classification of 1)indispensible SF for
packet delivery, allegedly mandatory SFs, such as NAT and 2)optional
SFs that a packet can be delivered without them, such as Firewall and
IDS.
The nodes of SFC-enabled domain can be various. Different vendors
make different types of equipments, and this causes performance
issues. Considering this diversity, the kind of SFs can be in myriad
form. Thus, we should distinguish some mandatory SFs from not
mandatory SFs and treat distinctively. Mandatory SFs should be
matched with higher-performance SFF to achieve high availability as
well as lower the probability of failure. Above all, whether each SF
is mandatory or optional should be registered in advance. Mandatory
SFs are to allocated to relatively higher-performance, larger
capacity, more stable SFFs. SFC constructed using this way of
allocation becomes the path for packets and packets are transferred
to classifier through C1 interface, and to SFF through C2 interface,
respectively.
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."
Kang, et al. Expires April 21, 2016 [Page 1]
Internet-Draft SFF-SF Dynamic Path Selection October 2015
This Internet-Draft will expire on April 21, 2016.
Copyright Notice
Copyright (c) 2015 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
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
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Dynamic service path selection between SFF and SF using C1
interface . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Dynamic service path selection between SFF and SF using C2
interface . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Dealing with multiple links of SF using C3 interface . . . . 5
5. Additional considerations . . . . . . . . . . . . . . . . . . 6
5.1. Load balancing and resiliency . . . . . . . . . . . . . . 6
5.2. SFC failover by SFF(local) . . . . . . . . . . . . . . . 7
5.3. SFC failover by control plane(global) . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
SFC(Service Function Chaining) can be explained as an ordered set of
abstract service functions and ordering constraints that must be
applied to packets and flows selected as a result of classification.
These services can operate on physical servers as well as on virtual
machines. Service classifier node at first classifies each traffic
into customer unit or service unit, refering to corresponding
policies. According to customer's profile, path is created passing
SF instances in the SFC-enabled domain after finding out which
customer uses which SF. Then encapsulation is done with Path ID,
Kang, et al. Expires April 21, 2016 [Page 2]
Internet-Draft SFF-SF Dynamic Path Selection October 2015
metadata, and service index are added to the created path. Packet
forwarding is launched by observing SFC header information received
by SFF in service function path.
In SFC-enabled domain, failures may occur at Service Function(SF).
If a failed node is on the path where a packet is delivered, packet
cannot be sent to destination and such situation should be avoided.
To provide highly available services in SFC, we need methods to
recover or bypass service functions from those failures. SFF(best
performance or mediocre) and SF(mandatory or optional) taxonomy is
one of methods.
1.1. Scope
The scope of this document is to treat how dynamic path selection
between SFFs and SFs can be determined to improve service stability
of whole SFC-enabled domain.
1.2. Terminology
Definitions of individual terms used in this documents can be found
in [I-D.ietf-sfc-architecture].
2. Dynamic service path selection between SFF and SF using C1 interface
High availability can be guaranteed by classifier policy using C1
interface. In case of C1 interface, it can deal with changes beyond
more than one SFF. Since control plane periodically monitors SFFs
and SFs, those information can help composing SFPs. These
information(e.g., memory, BW, port number) can figure out which SFF
is desirable to use and has relatively higher performance, larger
capacity, and more stability thereof. In this way, SFC contends
mandatory SFs should be mapped with better-performed SFFs.
Kang, et al. Expires April 21, 2016 [Page 3]
Internet-Draft SFF-SF Dynamic Path Selection October 2015
+------------------------------------------------+
|SFC-enabled Domain |
| |
| +---+ +---+ |
| |SF1| +-----------|SF3| |
| +---+ | +---+ |
| | | | |
| | | | |
| | | | |
| +----------+ +----------+ +----------+ |
| | | | | | | |
-------| SFF1 |---| SFF2 |---| SFF4 |-------
| | | | | | | |
| +----------+ +----------+ +----------+ |
| | | | |
| | | | |
| | | | |
| | +---+ | |
| +-------------|SF2|-----------+ |
| +---+ |
+------------------------------------------------+
Figure 1: Interface between SFF and SF
Moreover, mandatory SF plays a crucial role in SFC service, multi
links from mandatory SF are connected to multi SFFs. In contrast,
optional SF can be connected with single link to single SFF.
However, pursuant to it's importance, optional SF can ramp up the
number of links upon operators' discretion.
SFC: SF1 -> SF2 -> SF3
RSP1: SFF1 -> SF1 -> SFF1 -> SFF2 -> SF2 -> SFF2 -> SF3 -> SFF2 ->
SFF4
RSP2: SFF1 -> SF1 -> SFF1 -> SF2 -> SFF1 -> SFF2 -> SFF4 -> SF3 ->
SFF4
In the figure 1 above, SF1 is optional, and SF2, SF3 are mandatory.
Because SF1 is optional, it consists of a single link, whereas SF2
and SF3 are connected with multi links. Originally, SF2 and SF3 are
linked with relatively smaller capacity SFF2 even they are mandatory,
jeopardizing whole service stability. So it is amended to pass
through SFF1 and SFF4 rather than SFF2 as SFF1 and SFF4 are better-
performed nodes.
Kang, et al. Expires April 21, 2016 [Page 4]
Internet-Draft SFF-SF Dynamic Path Selection October 2015
Bandwidth | Memory | Port
----------------------+-----------------------+------------------
SFF1 10G | 8GB | 48EA
SFF2 1G | 4GB | 24EA
SFF4 1G | 4GB | 48EA
Figure 2: Example of performance features of SFF nodes
3. Dynamic service path selection between SFF and SF using C2 interface
High availability can be guaranteed by forwarding policy using C2
interface. Initial SFP has better-performed SFF1 connected to SF2
which is mandatory. However overall performance of SFF1 temporarily
exacerbates as traffics continuously concentrate on SFF1. In other
words, the performance of SFF1, the most better-performed SFF within
SFC-enabled domain at the very moment, plunges under that of SFF2, a
mediocre SFF having less performance features, SFF2 is entitled to
the most better-performed SFF in that domain, getting a leeway to
accommodate new traffics.
Control plane excerpts such an information and transmits forwarding
policy to let SF2 be treated by SFF2, not SFF1, i.e. it is envisaged
that the next hop of SF2 changes from SFF1 to SFF2. Compared to the
former C1 interface case, more nimble treatment is possible with C2
interface.
Figure 1 above can illustrate C2 interface as well. Previously
mandatory SF2 is allocated to SFF1, but if traffic is concentrated to
SFF1 as time goes, its performance would get aggravated. Control
plane can send forwarding policy to treat SF2 not with SFF1 but with
SFF2.
RSP1: SFF1 -> SF1 -> SFF1 -> SF2 -> SFF1 -> SFF2 -> SFF4 -> SF3 ->
SFF4
RSP2: SFF1 -> SF1 -> SFF1 -> SFF2 -> SF2 -> SFF2 -> SFF4 -> SF3 ->
SFF4
4. Dealing with multiple links of SF using C3 interface
Single SF can be linked with multiple SFF. SFC should include only
best-performed SFF by maintaining its connection, temporarily ceasing
links to other SFFs at the same time to mitigate the risk of
incurring a loop.
For instance, under the situation of mandatory SF2 being connected to
all SFFs(SFF1, SFF2, SFF4), SFC1 chooses SFF2 amongst SFFs based on
performance factors. Severance is treated to links between SF2 and
Kang, et al. Expires April 21, 2016 [Page 5]
Internet-Draft SFF-SF Dynamic Path Selection October 2015
other SFFs through C3 interface. But if SFF2 gets crowded and slow
down, SFC2 newly selects SFF1 or SFF3 because the performance of
those two gets better than that of SFF2.
5. Additional considerations
SFC classifier node as a Service Classification Function treats the
packet entering SFC-enabled domain below process: 1) According to
customer's profile distinguished in traffic classification procedure,
SFP ID is created to provide the series of service used by individual
customer. Furthermore, forwarding rules are added to entry of every
SFF in SFP for packet forwarding. 2) SFP ID created in 1) is added
to SFC header, and the packet is forwarded to subsequent SFF. 3) SFP
ID and index are checked within SFF, then forwarded to next SF or
SFF. 4) In case the SFF is the last node of SFC-enabled domain, SFC
header should be removed before forwarded outside of SFC-enabled
domain.
If one SF in SFP fails, the whole traffic forwarding passing the
failed SF is stopped only because of the SF itself. Currently
failover method like VRRP can recover the failure using High
Availability techniques. However, packet routing in SFC-enable
domain is done only with SFC header information including SFP ID and
index, so it is hard to apply existing L2, L3 failover techniques.
To prevent such a situation of which whole traffic forwarding stops
because of single SF failure, packets are treated in two ways of
failover: 1) in case corresponding backup SF is ready, packets are
forwarded to the backup SF to go through the path as designated in
SFC. 2) In case corresponding backup SF doesn't exist, whether the
failed SF is mandatory or optional is checked. Specifically in case
of 2), packet forwarding should be stopped and an alarm message
should be notified to controller if the SF is mandatory(e.g., NAT).
If optional(e.g., FW, IPS, LB, DPI, Cache, CPE, VPN, Optimizer)
packets should be forwarded to subsequent SF bypassing the failed SF.
SFC failover consists of two steps: step1. In initial SFP setup,
backup path for failover is configured in SFF forwarding rule in
advance. step2. When failure occurs, 1) SFF connected to the failed
SF senses the failure, recovers it by itself using backup path
configured in step1. 2) And the situation is notified to control
plane to let it revise global path of SFC-enabled domain.
5.1. Load balancing and resiliency
The concept of dynamic path selection could be extended for each SF
to have multiple instances. The effect of extension are related to
load balancing and resiliency. As shown in the below figure, for
Kang, et al. Expires April 21, 2016 [Page 6]
Internet-Draft SFF-SF Dynamic Path Selection October 2015
example, SF2 can have three entities(SF2-a, SF2-b, SF2-c). Each
entity may have different connectivity with SFFs according to policy
or performance information. SFC-level load balancing can be done
managing capacity/current load of each instances.
+------------------------------------------------+
|SFC-enabled Domain |
| |
| +---+ +---+ |
| |SF1| +-----------|SF3| |
| +---+ | +---+ |
| | | | |
| | | | |
| | | | |
| +----------+ +----------+ +----------+ |
| | | | | | | |
-------| SFF1 |---| SFF2 |---| SFF4 |-------
| | | | | | | |
| +----------+ +----------+ +----------+ |
| | | | | | | |
| | | | | | +---+ |
| | | | +--------|-----SF2-b |
| +---+ | +---+ | +---+ |
| SF2-c +-----------SF2-a---------+ |
| +---+ +---+ |
+------------------------------------------------+
Figure 3: Multiple entities for load balancing
5.2. SFC failover by SFF(local)
Controller produces classification rules and installs them to
classifier. Classifier adds SFC header to packets and sends to SFF.
SFF can receives packets from classifier node, adjacent SFF, or SF.
Then it checks SFP ID, index of packets whether there exists matched
rule in the forwarding rule entry and the output port thereof. If
output port is in normal operation, packets can pass through the SFC-
enabled domain along with predetermined SFP. Otherwise, two criteria
should be considered; backup path existence and whether mandatory or
not. Firstly, after backup path existence is confirmed, packets can
be forwarded to that backup path without further consideration.
However in case backup path doesn't exist, secondly output port is to
be checked.
When a failure occurs, index of SFC packet header should be revised
accordingly. For instance, if the index of current failed SF is 5
Kang, et al. Expires April 21, 2016 [Page 7]
Internet-Draft SFF-SF Dynamic Path Selection October 2015
and that of subsequent SF is 4, current index should be revised to 4
before being forwarded to next SF along with forwarding rules.
5.3. SFC failover by control plane(global)
As the classifier node detects the failure during processing packets,
firstly it finds out whether the failed SF's property (i.e.,
mandatory or optional) and whether backup path exists or not. If the
property is mandatory and there is no backup path, control plane
should be notified that packets cannot be forwarded from the SFF.
Otherwise, control plane extracts the path list including the failed
SF and recalculates backup path based on this information. Then new
forwarding rules are applied to each SFF.
Acknowledgments
The authors would like to thank Ron Parker and Seungik Lee for the
comments.
7. References
7.1. Normative 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.
7.2. Informative References
[I-D.ietf-sfc-control-plane]
Li, H., Wu, Q., Huang, O., Boucadair, M., Jacquenet, C.,
Haeffner, W., Lee, S., Parker, R., Dunbar, L., Malis, A.,
Halpern, J., Reddy, T., and P. Patil, "Service Function
Chaining (SFC) Control Plane Components & Requirements",
draft-ietf-sfc-control-plane-00 (work in progress), August
2015.
[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
Kang, et al. Expires April 21, 2016 [Page 8]
Internet-Draft SFF-SF Dynamic Path Selection October 2015
Taeho Kang
KT
Infra R&D Lab. KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
EMail: th.kang@kt.com
Young-Tae Han
KT
Infra R&D Lab. KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
EMail: youngtae.han@kt.com
Sungsu Kim
KT
Infra R&D Lab. KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
EMail: sngsu.kim@kt.com
Eunkyoung Paik
KT
Infra R&D Lab. KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
EMail: eun.paik@kt.com
Namgon Kim
KT
Infra R&D Lab. KT
463-1 Jeonmin-dong, Yuseoung-gu
Seoul 137-792
Korea
EMail: ng.kim@kt.com
Kang, et al. Expires April 21, 2016 [Page 9]
