Network Working Group S. Lee Internet-Draft M-K. Shin Intended status: Informational ETRI Expires: January 5, 2015 July 4, 2014 SFC dynamic instantiation draft-lee-sfc-dynamic-instantiation-00 Abstract SFC instantiation may be static or dynamic. In a static instantiation, specific SF instances are predetermined by network operator's configuration or policy. However, since it does not consider the current state of network resources such as availability of the SF instances, the static instantiation may create more vulnerable SFPs to state changes of the network resources such as failure or overload. This document specifies SFC dynamic instantiation capability to create and update SFPs considering traffic optimization, failover of SFIs, and load balancing. 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 January 5, 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 carefully, as they describe your rights and restrictions with respect Lee & Shin Expires January 5, 2015 [Page 1] Internet-Draft SFC dynamic instantiation July 2014 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 instantiation . . . . . . . . . . . . . . . . . . . . . . 3 4. Dynamic instantiation of SFC . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 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 and customer 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). The SFC remains still if there are no changes in the operator's policies for the target traffic. However, the SFP may vary in time with resource state of SF instances and underlying transport at the instantiation to support traffic optimization, failover of service function instances (SFIs), or load balancing. For example, an instance of SF_A can be replaced by another instance of SF_A deployed at a different service node (SN) when the former one fails to function. This document specifies SFC dynamic instantiation capability to create and update SFPs considering traffic optimization, failover of SFIs, and load balancing. Based on the capability and the use cases, SFC architecture needs to consider the attributes of resources for SF instances at control plane. Lee & Shin Expires January 5, 2015 [Page 2] Internet-Draft SFC dynamic instantiation July 2014 2. Terminology This document uses the following terms and most of them were reproduced from [I-D.ietf-sfc-problem-statement] and [I-D.quinn-sfc-arch]. o Classification: Locally instantiated policy and customer/network/ service profile matching of traffic flows for identification of appropriate outbound forwarding actions. o Service Function (SF): A function that is responsible for specific treatment of received packets. A Service Function can act at the network layer or other OSI layers. 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: An offering provided by an operator that is delivered using one or more service functions. This may also be referred to as a composite service. o Service Node (SN): Physical or virtual element that hosts one or more service functions and has one or more network locators associated with it for reachability and service delivery. o Service Function Chain (SFC): A service Function chain defines an ordered set of service functions 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 nodes that copy to more than one branch. The term service chain is often used as shorthand for service function chain. o Service Function Path (SFP): The instantiation of a SFC in the network. Packets follow a service function path from a classifier through the requisite service functions. 3. SFC instantiation Service function chaining provides 3-level abstraction of the network for service delivery: SFC overlay, Service Function Path (SFP), and Service Function Chain (SFC). The physical resources for Service Functions and their connectivity are abstracted as a SFC overlay. Lee & Shin Expires January 5, 2015 [Page 3] Internet-Draft SFC dynamic instantiation July 2014 An ordered set of service functionalities per traffic is specified by a SFC. The SFC can be further deployed by a SFP which specifies the logical functions with their physical instances. Under this abstraction, the traffic flows are forwarded along the SFPs which can be obtained by two separate steps: classification and SFC instantiation. o Classification: SFCs are selected and identified by a classification function according to the traffic steering policy defined by network operators. The policy just defines which service functions must be applied to traffic flows in specific orders. It does not consider which network resources are available or ready for the service functions. o SFC instantiation: In order to forward the traffic flows along the SFC, it needs to be instantiated to a SFP by selecting the specific instances of the service functions given in the SFC considering the state of resources and transport. +------+ +------+ +------+ SFC | SF1 |-----------| SF2 |-----------| SF3 | +------+ +------+ +------+ +------+ +------+ +------+ SFP#1 |SF1_a |-----------|SF2_b |-----------|SF3_a | +------+ +------+ +------+ +------+ +------+ +------+ SFP#2 |SF1_a |-----------|SF2_a |-----------|SF3_b | +------+ +------+ +------+ +-------+ | SF2_a | +-------+ +-------+ +-------+ | SF1_a | ___/ | SF3_a | +-------+ (___) +-------+ ___/ / \ ___/ SFC overlay (___)+-----------+ +-----------+(___) \ ___ / \ (___) +-------+ \ | SF3_b | +-------+ +-------+ | SF2_b | +-------+ Figure 1: SFC instantiation Lee & Shin Expires January 5, 2015 [Page 4] Internet-Draft SFC dynamic instantiation July 2014 For example as depicted in Figure 1, {SFC: SF1 -> SF2 -> SF3} is selected for a traffic flow by the classification function. This SFC can be further instantiated to two different SFPs: {SFP#1: SF1_a -> SF2_b -> SF3_a} and {SFP#2: SF1_a -> SF2_a -> SF3_b} by selecting one of multiple instances of the service functions. The SFC instantiation may be static or dynamic. In a static instantiation, specific SF instances are predetermined 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 of network resources such as availability of the SF instances, the static instantiation may create more vulnerable SFPs to state changes of the network resources such as failure or overload. 4. Dynamic instantiation of SFC In a dynamic SFC instantiation, SF instances are selected considering attribute of the network resources at time of demand, specifically: o SF instances for every SF given are selected to construct a complete SFP before starting to forward traffic flows along the SFP o SF instance is selected or replaced at time of delivering the traffic flow to the SF The use of two different methods for creating SFPs depends on use cases of the dynamic SFC instantiation as follows: o Traffic optimization: constructs SFPs with low stress and stretch considering the different locations of multiple SF instances. o Load balancing: selects SF instances to distribute load for the traffic considering the current status of SF instances or service nodes where the instances are embedded. o Failover of SF instance: selects live SF instances and replaces SF instances in failure by checking their availability. In order to support those use cases, the criteria to select one of multiple service function instances (SFIs) may vary but mainly from state of network resources and attributes of traffic flow such as: o Availability, load, performance of SF instances, service nodes, SFP transport links (among SF instances) Lee & Shin Expires January 5, 2015 [Page 5] Internet-Draft SFC dynamic instantiation July 2014 o Topological location of source and destination o Volume of traffic flow 5. Security Considerations TBD. 6. IANA Considerations TBD. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [I-D.ietf-sfc-problem-statement] Quinn, P. and T. Nadeau, "Service Function Chaining Problem Statement", draft-ietf-sfc-problem-statement-07, June 2014. [I-D.quinn-sfc-arch] Quinn, P. and J. Halpern, "Service Function Chaining (SFC) Architecture", draft-quinn-sfc-arch-05, May 2014. Authors' Addresses Seung-Ik Lee ETRI 218 Gajeong-ro Yuseung-Gu Daejeon 305-700 Korea Phone: +82 42 860 1483 Email: seungiklee@etri.re.kr Lee & Shin Expires January 5, 2015 [Page 6] Internet-Draft SFC dynamic instantiation July 2014 Myung-Ki Shin ETRI 218 Gajeong-ro Yuseung-Gu Daejeon 305-700 Korea Phone: +82 42 860 4847 Email: mkshin@etri.re.kr Lee & Shin Expires January 5, 2015 [Page 7]