Service function Chaining S. Lee Internet-Draft ETRI Intended status: Informational S. Pack Expires: April 30, 2015 KU M-K. Shin ETRI E. Paik KT October 27, 2014 SFC dynamic instantiation draft-lee-sfc-dynamic-instantiation-01 Abstract This document describes a control plane architecture for dynamic instantiation of service function chains which dynamically creates and adapts service function paths to optimize performance of the service function paths. This document further defines basic operations for the dynamic instantiations; and performance metrics of service function path components, i.e., service function instances and forwarding links among service function forwarders for evaluation of the service function path. 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. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Lee, et al. Expires April 30, 2015 [Page 1] Internet-Draft SFC dynamic instantiation October 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. SFC dynamic instantiation . . . . . . . . . . . . . . . . . . 4 4. Control plane architecture . . . . . . . . . . . . . . . . . 6 5. Operational procedures . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The current service delivery model is bound to static topologies and manually configured resources. This has motivated a more flexible deployment model which orchestrates the service delivery separated from the network. Service function chaining [I-D.ietf-sfc-problem-statement] provides a new service deployment model that delivers the traffic along the predefined logical paths of service functions (SFs), called service function chains (SFCs) with no regard of network topologies or transport mechanisms. A SFC is determined by classification of target traffic based on operator's policy. Since it is described with logical SFs, the service function chain needs to be instantiated by selecting instances of the SFs, which results in a service function path (SFP). Performance of a SFP depends on the current state or attributes (e.g., availability, topological location, and latency) of SFP components (i.e., SF instances (SFIs) and forwarding links among SFFs (SFLs)). Thus, the SFP performance may vary according to which SFIs are selected at SFC instantiation; and it may also vary in time with the state or attributes of the SFP components. This document describes a control plane architecture for dynamic instantiation of SFCs which dynamically creates and adapts SFPs to Lee, et al. Expires April 30, 2015 [Page 2] Internet-Draft SFC dynamic instantiation October 2014 optimize the SFP performance considering the current state and attributes of SFIs and SFLs. This document further defines basic operations for the dynamic instantiations and performance metrics of SFP components for SFP evaluation. 2. Terminology This document uses the following terms and most of them were reproduced from [I-D.ietf-sfc-problem-statement] and [I-D.ietf-sfc-architecture]. o Classification: Locally instantiated policy and customer/network/ service profile matching of traffic flows for identification of appropriate outbound forwarding actions. o Service Function Chain (SFC): A service function chain defines a set of abstract service functions and ordering constraints that must be applied to packets and/or frames selected as a result of classification. The implied order may not be a linear progression as the architecture allows for SFCs that copy to more than one branch, and also allows for ere there is flexibility in the order in which service functions need to be applied. The term service chain is often used as shorthand for service function chain. o Service Function (SF): A function that is responsible for specific treatment of received packets. A Service Function can act at various layers of a protocol stack (e.g., at the network layer or other OSI layers). As a logical component, a Service Function can be realized as a virtual element or be embedded in a physical network element. One or multiple Service Functions can be embedded in the same network element. Multiple occurrences of the Service Function can exist in the same administrative domain. o Service Function Instance (SFI): The instantiation of Service Function that can be a virtual instance or be embedded in a physical network element. One of multiple Service Functions can be embedded in the same network element. Multiple instances of the Service Function can be enabled in the same administrative domain. o Service Function Forwarder (SFF): 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, as well as handling traffic coming back from the SF. Additionally, a service function forwarder is responsible for delivering traffic to a classifier when needed and supported, mapping out traffic to another SFF (in the same or different type of overlay), and terminating the SFP. Lee, et al. Expires April 30, 2015 [Page 3] Internet-Draft SFC dynamic instantiation October 2014 o Service Function Path (SFP): The SFP provides a level of indirection between the fully abstract notion of service chain as a sequence of abstract service functions to be delivered, and the fully specified notion of exactly which SFF/SFs the packet will visit when it actually traverses the network. By allowing the control components to specify this level of indirection, the operator may control the degree of SFF/SF selection authority that is delegated to the network. o Service Forwarding Link (SFL): An overlay link between two SFFs over which the packet will visit SF along the SFP. 3. SFC dynamic instantiation A service function chain is composed of one or more logical service functions and it can be further instantiated with a SFP which contains physical instances of the logical SFs. Since multiple instances of a SF may be available, different sets of SFI (i.e., SFPs) can be built per SFC. For example in Figure 1, a SFC {SF1 -> SF2 -> SF3} selected for a traffic flow can be further instantiated with two different SFPs: SFP#1 {SF1_a -> SF2_a -> SF3_a} and SFP#2 {SF1_b -> SF2_b -> SF3_b} by selecting one of multiple instances of the service functions. +------+ +------+ +------+ SFC | SF1 |-----------| SF2 |-----------| SF3 | +------+ +------+ +------+ +------+ +------+ +------+ |SF1_a | |SF2_a | |SF3_a | +------+ +------+ +------+ SFP#1 | | | ******** ******** ******** * SFF *-----------* SFF *-----------* SFF * ******** SFL ******** SFL ******** SFP#2 | | | +------+ +------+ +------+ |SF1_b | |SF2_b | |SF3_b | +------+ +------+ +------+ Figure 1: SFC instantiation Under this abstraction, a SFC can be constructed by the following operations: Lee, et al. Expires April 30, 2015 [Page 4] Internet-Draft SFC dynamic instantiation October 2014 o Classification: One SFC is selected and identified by a classification function according to the traffic steering policy defined by the network operator. The policy just logically defines which service functions must be applied to traffic flows in a specific order. o Re-classification (or branching): According to an intermediate result of packet treatment, the current SFC can be updated by adding or removing SFs, which results in creation of a new SFP. o SFC instantiation: In order to define the physical forwarding paths for the traffic, the SFC needs to be instantiated to a SFP by selecting a specific instance of each service function that is given in the SFC. The SFP can be updated by replacing one or more conventional SF instances with the other ones at run-time. Note that it does not cause change of a SF but change of a physical instance of the same SF. The SFC instantiation may be static or dynamic. In a static instantiation, specific SF instances are pre-determined by network operator's configuration or policy. The static instantiation may be more convenient for network administrators because they can easily expect the result and troubleshooting locations. However, since it does not consider the current state and attribute of SFIs, the static instantiation may create more vulnerable SFPs to state changes of the SFIs such as failure or overload. In a dynamic SFC instantiation, SFIs are selected according to their states and attributes at time of demand, specifically at initial classification or during intermediate traversal of the SFP. o At classification: SF instances are selected to initially construct a SFP before starting to forward the incoming traffic flows o At intermediate traversal: One or more SF instances are selected and dynamically replaced during traversing the SFP to update the SFP The example use cases of SFC dynamic instantiation are as follows: o SFP fail-over: re-construct a SFP with replacing the failed SFI with new SFI selected o End-to-end service optimization: construct or maintain a SFP with a low stretch considering the topological locations of SFI and properties (e.g., latency, bandwidth) of SFLs Lee, et al. Expires April 30, 2015 [Page 5] Internet-Draft SFC dynamic instantiation October 2014 o Traffic optimization: construct or maintain SFPs to localize the traffic in the network considering load and administrative domains of SFIs and SFLs. o Load balancing: construct or maintain SFPs to distribute the load of shared SFIs and SFLs. For more details about the use cases, refer to [I-D.lee-nfvrg-resource-management-service-chain]. 4. Control plane architecture In order to instantiate a SFC dynamically according to the state and attributes of SFP components, the following functional building blocks are required in a SFC control plane architecture. SFC instantiation o Evaluate SFIs and SFLs based on the measurements obtained from SFP component management building block o Select SFIs to construct a SFP optimized according to the evaluation results o Enforce the constructed SFP for incoming traffic to the classification node via interface-(a) o Replace SFIs to update a SFP adapted to changes of state or attributes of SFIs and SFLs o Enforce the updated SFP for upcoming SFC traversal to SFFs via interface-(b) SFP component management o Collect and monitor state and attributes of SFIs and SFLs via interface-(d) and interface-(c), respectively o Provide the collected state and attributes of SFIs and SFLs to SFC instantiation building block for evaluation Lee, et al. Expires April 30, 2015 [Page 6] Internet-Draft SFC dynamic instantiation October 2014 #=================================================# # # # +---------------+ +---------------+ # # ____| SFC |______| SFP component | # # | | instantiation | | management | # # | +---------------+ +---------------+ # # | | ^ ^ # #===|=============|=================|=====|=======# | | | | |(a) |(b) |(c) |(d) | | | | | | +------+ | +------+ | | | SFI | | | SFI | | | +------+ | +------+ V V | | | ******** ******** ******** -* CLSF *-------* SFF *-----------* SFF *-------- ******** ******** ******** Figure 2: Control plane architecture for SFC dynamic instantiation The state and attributes of SFP components for SFP evaluation can be obtained via interface-(c) and interface-(d). Examples of the state and attributes of SFP components are as follows: o availability (or failure) of a SFI and a SFL o a topological location of a SFI o a utilization rate of a SFI o a throughput of a SFI o energy consumption of SFI o bandwidth of a SFL o latency of a SFL 5. Operational procedures (TBD) Lee, et al. Expires April 30, 2015 [Page 7] Internet-Draft SFC dynamic instantiation October 2014 6. Security Considerations (TBD) 7. IANA Considerations (TBD) 8. References 8.1. Normative References [I-D.ietf-sfc-architecture] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", draft-ietf-sfc-architecture-02 (work in progress), September 2014. [I-D.ietf-sfc-problem-statement] Quinn, P. and T. Nadeau, "Service Function Chaining Problem Statement", draft-ietf-sfc-problem-statement-10 (work in progress), August 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.lee-nfvrg-resource-management-service-chain] Lee, S., Pack, S., Shin, M., and E. Paik, "Resource Management for Dynamic Service Chain Adaptation", draft- lee-nfvrg-resource-management-service-chain-00 (work in progress), October 2014. [I-D.ww-sfc-control-plane] Li, H., Wu, Q., Boucadair, M., Jacquenet, C., and W. Haeffner, "Service Function Chaining (SFC) Control Plane Achitecture", draft-ww-sfc-control-plane-03 (work in progress), September 2014. Authors' Addresses Lee, et al. Expires April 30, 2015 [Page 8] Internet-Draft SFC dynamic instantiation October 2014 Seung-Ik Lee ETRI 218 Gajeong-ro Yuseung-Gu Daejeon 305-700 Korea Phone: +82 42 860 1483 Email: seungiklee@etri.re.kr Sangheon Pack Korea University 145 Anam-ro, Seongbuk-gu Seoul 136-701 Korea Phone: +82 2 3290 4825 Email: shpack@etri.re.kr Myung-Ki Shin ETRI 218 Gajeong-ro Yuseung-Gu Daejeon 305-700 Korea Phone: +82 42 860 4847 Email: mkshin@etri.re.kr EunKyoung Paik KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792 Korea Phone: +82 2 526 5233 Email: eun.paik@kt.com Lee, et al. Expires April 30, 2015 [Page 9]