Internet DRAFT - draft-kang-sfc-failover
draft-kang-sfc-failover
SFC T. Kang
Internet-Draft S. Kim
Expires: April 30, 2015 E. Paik
KT
October 27, 2014
Failover for Service Function Chaining
draft-kang-sfc-failover-01.txt
Abstract
In SFC-enabled domain, failures can occur at Service Function(SF).
If the failed node is on the path where a packet is delivered, packet
cannot be sent to destination and such situation should be avoided.
Currently, there are many ways to provide redundancy of SFs, such as
VRRP. However, legacy redundancy method may not be used in SFC as
Service Function Forwarders(SFFs) do not use IP or MAC address in
their FIBs. In SFC, traffic is steered based on Service Function
Path ID and Service Index. Therefore controller, which is
responsible for a control plane function in SFC, can manage path of
SFC. In this document, we illustrate failover method specifically
for SFC which uses SFC encapsulation. We describe bypass mechanism
to avoid failures in SFs and redirect traffic to backup SFs. For
bypass mechanism, we propose SF classification of 1)mandatory SFs
that function indispensible for packet delivery, such as NAT and
2)optional SFs that a packet can be delivered without them, such as
Firewall and IDS.
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 April 30, 2015.
Kang, et al. Expires April 30, 2015 [Page 1]
Internet-Draft SFC Failover October 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. 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. Failover considerations . . . . . . . . . . . . . . . . . . . 3
4. SFC Failover . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Failover by SFF(local) . . . . . . . . . . . . . . . . . 6
4.2. Failover by controller(global) . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Normative References . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
SFC(Service Function Chaining) can be explained as packets pass
through only network services selected by network users' needs.
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,
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.
2. 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 [RFC2119].
The following terms are defined:
Kang, et al. Expires April 30, 2015 [Page 2]
Internet-Draft SFC Failover October 2014
Service Function: A function that is responsible for specific
treatment of received packets. As a logical component, a Service
Function can be realized as a virtual element or be embedded in a
physical network element.
Service Function Chaining: Abstract set of service functions and
ordering constraints that must be applied to packets selected as a
result of classification.
Service Function Forwarder: A service function forwarder is
responsible for delivering traffic received from the network to
one or more connected service functions according to information
carried in the SFC encapsulation.
SFC encapsulation: The SFC encapsulation is used by the SFC-aware
functions, such as the SFF and SFC-aware SFs.
Classification: Instantiated policy and customer/network/service
profile matching of traffic flows for identification of
appropriate outbound forwarding actions.
Service Classifier Node: An element doing the role of classification
3. Failover 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.
Kang, et al. Expires April 30, 2015 [Page 3]
Internet-Draft SFC Failover October 2014
4. SFC Failover
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.
Kang, et al. Expires April 30, 2015 [Page 4]
Internet-Draft SFC Failover October 2014
+----------------------------------------------------+
|Controller |
| +---------------+ +--------------+ +-----------+ |
| |Chain Selection| |Chain Mapping | |External SF| |
| |Policy Control | |and Forwarding| |Management | |
| | | |Control | | | |
| +---------------+ +--------------+ +-----------+ |
| |
| +----------------+ +-------------------+ |
| |Chain Management| |Service Overlay | |
| |Policy Control | |Topology Management| |
| +----------------+ +-------------------+ |
+----------------------------------------------------+
+--------------------------------------------------+
|SFC-enabled Domain |
| +---+ |
| |SF | |
| +---+ |
| | |
| | |
| | |
| +----------+ +-----+ +-----+ +-----+ |
| |SFC | | | | | | | |
-------|Classifier|---| SFF |---| SFF |---| SFF |---------
| |Node | | | | | | | |
| +----------+ +-----+ +-----+ +-----+ |
| | | |
| ------- | |
| | | | |
| +---+ +---+ +---+ |
| |SF | |SF | |SF | |
| +---+ +---+ +---+ |
+--------------------------------------------------+
Figure 1: Service Chaining Architecture
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 controller
to let controller revise global path of SFC-enabled domain.
Kang, et al. Expires April 30, 2015 [Page 5]
Internet-Draft SFC Failover October 2014
4.1. Failover by SFF(local)
Controller produces classification rules and installs them to
classifier. Classifier adds SFC header to packets and sends to SFF.
Figure1 illustrates how SFF forwards packets. 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
and that of subsequent SF is 4, current index should be revised to 4
before being forwarded to next SF along with forwarding rules.
4.2. Failover by controller(global)
As classifier node senses the failure during communication process,
firstly it finds out whether the failed SF is mandatory or optional
and whether backup path exists or not. If mandatory and no backup
path, controller should be notified that packets cannot be forwarded.
If not the case, controller 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.
5. Security Considerations
TBD.
6. Normative References
[I.D-ww-sfc-control-plane]
Li, H., Wu, Q., Huang, O., Boucadair, M., Jacquenet, C.,
and W. Haeffner, "Service Function Chaining (SFC) Control
Plane Architecture", September 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Kang, et al. Expires April 30, 2015 [Page 6]
Internet-Draft SFC Failover October 2014
Authors' Addresses
Taeho Kang
KT
Infra R&D Lab. KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
Phone: +82-2-526-6688
Fax: +82-2-526-5200
Email: th.kang@kt.com
Sungsu Kim
KT
Infra R&D Lab. KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
Phone: +82-2-526-6688
Fax: +82-2-526-5200
Email: sngsu.kim@kt.com
EunKyoung Paik
KT
Infra R&D Lab. KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
Phone: +82-2-526-5233
Fax: +82-2-526-5200
Email: eun.paik@kt.com
URI: http://mmlab.snu.ac.kr/~eun/
Kang, et al. Expires April 30, 2015 [Page 7]
