SFC T. Kang Internet-Draft Y. Han Intended status: Informational S. Kim Expires: January 7, 2016 E. Paik N. Kim KT July 6, 2015 Dynamic Service Path Selection over Multiple Links between SFF and SF for Enhancing Service Stability draft-kang-sfc-dynamic-path-selection-00 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 January 7, 2016 [Page 1] Internet-Draft SFF-SF Dynamic Path Selection July 2015 This Internet-Draft will expire on January 7, 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. SFC failover by SFF(local) . . . . . . . . . . . . . . . 6 5.2. SFC failover by control plane(global) . . . . . . . . . . 7 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Normative References . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . 7 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, metadata, and service index are added to the created path. Packet Kang, et al. Expires January 7, 2016 [Page 2] Internet-Draft SFF-SF Dynamic Path Selection July 2015 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 January 7, 2016 [Page 3] Internet-Draft SFF-SF Dynamic Path Selection July 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 SFP1: SFF1 -> SF1 -> SFF1 -> SFF2 -> SF2 -> SFF2 -> SF3 -> SFF2 -> SFF4 SFP2: 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 January 7, 2016 [Page 4] Internet-Draft SFF-SF Dynamic Path Selection July 2015 Bandwidth | Memory | Port ----------------------+-----------------------+------------------ SFF1 10G | 8GB | 48EA SFF2 1G | 4GB | 24EA SFF3 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. SFP1: SFF1 -> SF1 -> SFF1 -> SF2 -> SFF1 -> SFF2 -> SFF4 -> SF3 -> SFF4 SFP2: 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 January 7, 2016 [Page 5] Internet-Draft SFF-SF Dynamic Path Selection July 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. 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. Kang, et al. Expires January 7, 2016 [Page 6] Internet-Draft SFF-SF Dynamic Path Selection July 2015 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. 5.2. 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. 6. References 6.1. Normative References [I-D.ietf-sfc-architecture] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", draft-ietf-sfc-architecture-09 (work in progress), June 2015. 6.2. Informative References [I-D.dunbar-sfc-path-control] Dunbar, L. and A. Malis, "Framework for Service Function Path Control", draft-dunbar-sfc-path-control-01 (work in progress), March 2015. [I-D.ww-sfc-control-plane] Li, H., Wu, Q., 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-ww- sfc-control-plane-06 (work in progress), June 2015. Kang, et al. Expires January 7, 2016 [Page 7] Internet-Draft SFF-SF Dynamic Path Selection July 2015 Authors' Addresses 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 Kang, et al. Expires January 7, 2016 [Page 8] Internet-Draft SFF-SF Dynamic Path Selection July 2015 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 January 7, 2016 [Page 9]