SFC T. Kang Internet-Draft S. Kim Expires: April 27, 2015 E. Paik KT October 24, 2014 Failover for Service Function Chaining draft-kang-sfc-failover-00.txt Abstract In the Software-Defined Networking (SDN) architecture, a SDN controller establishes flow paths. SDN controller, classifier, and SFF(Service Function Forwarder) do closely interact for SFC packet transmission. However, failure can happen at some nodes in SFC- enabled domain preventing packet forwarding, and such situation should be avoided. Backup SF(Service Function) can be one of solutions. Additionally, mandatory/optional criterion can decide whether to bypass the failed SF. In this document, we illustrate failover method locally by SFF and globally by controller. 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 27, 2015. 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 Kang, et al. Expires April 27, 2015 [Page 1] Internet-Draft SFC Failover October 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. Failover considerations . . . . . . . . . . . . . . . . . . . 3 4. SFC Failover . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Failover by SFF(local) . . . . . . . . . . . . . . . . . 4 4.2. Failover by controller(global) . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Normative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 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: 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. Kang, et al. Expires April 27, 2015 [Page 2] Internet-Draft SFC Failover October 2014 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. 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 27, 2015 [Page 3] Internet-Draft SFC Failover October 2014 +--------------------------------------------------+ |Controller | | +------------------+ +----------+ +----------+ | | |Path determination| |Monitoring| |Path setup| | | +------------------+ +----------+ +----------+ | +--------------------------------------------------+ +--------------------------------------------------+ |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. 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 Kang, et al. Expires April 27, 2015 [Page 4] Internet-Draft SFC Failover October 2014 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 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 Kang, et al. Expires April 27, 2015 [Page 5] Internet-Draft SFC Failover October 2014 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 27, 2015 [Page 6]