Network Working Group H. Chen, Ed. Internet-Draft J,. Yang, Ed. Intended status: Informational Huawei Technologies Co,. Ltd. Expires: August 18, 2014 February 14, 2014 Utilizing traffic offloading to relieve burden of service node draft-chen-sfc-traffic-offloading-00 Abstract This document analysis the possibility to relieve the burden of service node via introducing the traffic offloading mechanism into the service function chain scenario, which may ultimately improve the network efficiency. Requirements Language 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] 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 August 18, 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 Chen & Yang Expires August 18, 2014 [Page 1] Internet-Draft traffic offloading February 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. Concept of traffic offloading . . . . . . . . . . . . . . . . 3 4. Operation of traffic offloading . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Static deployment of service function in traditional network cannot fulfill nowadays requirement, such as adding and removing new services/functions elastically. In this case, service function chain (SFC) was introduced into the current network deployment. It may realize the end-to-end service functions delivery, including the traditional functions (e.g. firewalls, NAT, WAN optimization) as well as the application specific functions. This document proposes the traffic offloading mechanism, which mainly exploits the spare capacity of service entities (including the classifier, the service nodes), to effectively increase the utilization rate of these devices. This document discusses the possibility to realize traffic offloading among the service entities along the same service path, and besides illustrates optional implementation methods for reference. 2. Terminology This document makes use of the following terms, additional terms are defined in [I-D.ietf-sfc-problem-statement]. Service function: A network or application based packet treatment, application, compute or storage resource, used singularly or in concert with other service functions within a service chain to enable a service offered by a network operator. Chen & Yang Expires August 18, 2014 [Page 2] Internet-Draft traffic offloading February 2014 Classifier: Locally instantiated policy and customer/network/service profile matching of traffic flows for identification of appropriate outbound forwarding actions. Service node: Physical or virtual element providing one or more service functions. Service entity: network device including the classifier and the service node. Service function chain: A service chain defines the required functions and associated order that must be applied to packets and/or frames. A service chain does not specify the network location or specific instance of service functions. Service path: Instance of service function chain. 3. Concept of traffic offloading A typical service function chain may consist of a classifier node followed by one or more service nodes in a certain order. Figure.1 shows a simple example of service function chain, where CF represents the classifier node while SN_1, SN_2 and SN_3 represent three service nodes respectively. Service node may be any kind of service function according to the requirement, such as firewall, load balancer, IPS, IDS or WAN optimizer and so on. In this simple example, traffic flows firstly come into CF that executes the flow identification function. CF is responsible for distinguishing and marking flow that need to be forwarded to the following service entity (e.g. SN_1). The service path in this example can be indicated as CF->SN_1->SN_2->SN_3, as the dash line shows in Figure.1. ********************************************* * * +-----*----+ +----------+ +-----*----+ +----------+ |****** | | | | *****|**********|**** | ----->| CF |--------->| SN_1 |--------->| SN 2 |--------->| SN 3 | | | | | | | | | +----------+ +----------+ +----------+ +----------+ flow table entry flow table entry a,b,c b,c Figure 1: Traffic offloading example In some situations, it is possible that the adjacent nodes along the same service path have some flow table entries in common, or the upstream service entity is able to support the some flow rules that hold by the downstream node. The action field of these flow table Chen & Yang Expires August 18, 2014 [Page 3] Internet-Draft traffic offloading February 2014 entries could be Drop, Pass-through or Forward. For example, assuming SN_1 has the flow table entries b and c, CF has the flow table entries a, b and c. In this case, it is possible to process this flow traffic according to the action field of flow table entry b and c on CF instead of on SN_1, which means CF is able to offload traffic for SN_1. Consequently, the service path will be changed from previously CF->SN_1->SN_2->SN_3 to CF->SN_2->SN_3, as the star line shows in Figure.1. The condition to perform traffic offloading is that CF is capable to perform the same rules. This situation may also exist between two adjacent service nodes, such as between SN_1 and SN_2, or between SN_2 and SN_3, as long as they have flow table entries in common. Traffic offloading will not degrade the performance significantly, especially when the upstream node (e.g. CF in Figure.1) implement the traffic flow processing in hardware fashion, for example, the ASIC based flow processing. The benefit is obvious: it may relieve the burden of the downstream service entity by implementing traffic offloading between the adjacent nodes along the service path. Considering that the service entity may be implemented by different venders, it is necessary to find a way to set up the traffic offloading mechanism among service entities along the same service path. 4. Operation of traffic offloading To illustrate, Figure.2 shows one of the possible method to realize the traffic offloading along the service path. MS represents the SFC management system. It manages all of the service entities, including the classifier (CF) and service node (SN_1, SN_2) within the same autonomous domain. The main function of MS is to get the requirements from upper application, including the type of service functions required and their relative order with which the flow is going to go through. According to this information, MS begins to configure the service entities within the same autonomous domain. It creates the service path identifier for each flow, and then distributes it to the service entities. Chen & Yang Expires August 18, 2014 [Page 4] Internet-Draft traffic offloading February 2014 +-----------------------+ +---1-----| MS |----1----+ | | | | | +-----------+-----------+ | | 1 | | | | +-----V----+ +-----V----+ +-----V----+ | |----2---->| |----2---->| | | CF | | SN_1 | | SN_2 | | |<---3-----| |<---3-----| | +-----+----+ +----------+ +-----^----+ | | | | +---------------------4---------------------+ Figure 2: Method A for traffic offloading 1. According to requirements from upper application, MS chose the proper service nodes to realize corresponding service functions. MS can be realized in the form of a standalone system or a component of a large-scale system, for example, component of a SDN controller. For example, on receiving the requirements from upper application, MS selects CF, SN_1 and SN_2 to form a specific service path. The relative order that the flow has to go through is CF->SN_1->SN_2. 2. After configured by MS, each service entity along the service function path has to notify its own downstream nodes of its own support capability of flow table. In figture.2, CF has to notify its own downstream node SN_1, and SN_1 has to notify its own downstream node SN_2. The capability of flow table support refers to the match fields that flow table can support, and the actions that can be apply to packet flow. If the upstream node has already notified its downstream node in other service function path, then there is no need to repeat the notification process. On receiving the notification from its own upstream node, the downstream node will make record of the match fields and actions that upstream node is able to support. 3. When the first packet of flow arrives at CF, CF will forward this packet to its own downstream node SN_1 according to the generated flow table entry. On receiving the first packet of flow from CF, SN_1 generates the corresponding flow table entry. SN_1 will compare this generated flow table entry with CF's support capability of flow table that was previously recorded to see if there is any match entry. Chen & Yang Expires August 18, 2014 [Page 5] Internet-Draft traffic offloading February 2014 * If the result is NO, which indicates that CF is not able to offload the traffic for SN_1, then SN_1 will not reply to CF. It will forward this first packet to SN_2 according to certain policy after processing it. SN1 will process the residual packets of this flow on its own. * If the result is YES, which indicates that CF is able to offload the traffic for SN_1, then SN_1 will notify CF the generated flow table information, including the corresponding match fields and actions. 4. On receiving the information of flow table entry, CF1 will add it to its own flow table or update its own flow table. When the residual packets of this flow arrived, CF will take SN_1's place to process them instead, and then will forward these packets directly to SN_2 rather than forward them to SN_1 as before. Figure.3 shows an alternative method to implement the traffic offloading in SFC scenario. MS represents the SFC management system. It manages all of the service entities, including the classifier (CF) and the service nodes (SN_1 and SN_2). 1. At the network initialization phase, each service entities have to announce its capability of flow table support to MS proactively, including the match field of flow table, and the actions that can be apply to the traffic flow. On receiving these announcements, MS makes records for each service entity. For example, CF, SN_1 and SN_2 send the announcement to MS, MS makes records for each of them. 2. MS pushes each service entity's capability of flow table support to its downstream service entity. For example, MS pushes CF1's capability of flow table support to SN_1, and pushes SN_1's capability of flow table support to SN_2. The following procedures are the same as steps 3 and 4 in method A. It is not necessary to describe repeatedly. Chen & Yang Expires August 18, 2014 [Page 6] Internet-Draft traffic offloading February 2014 +-----------------------+ +----2----| MS |----2-----+ | +--1--->| |<---1---+ | | | +-----------+-^---------+ | | | | 2 1 | | | | | | | | +----V-+---+ +----V-+---+ +---+-V----+ | | | | | | | CF |<---3-----| SN_1 | | SN_2 | | | | | | | +-----+----+ +----------+ +-----^----+ | | | | +---------------------4---------------------+ Figure 3: Method B for traffic offloading This document does not specify the concrete formats for the capability of flow table support. Alternative options may refer to the flow table's format defined in [Openflow-Specification]. Iteration operation may be applied to the traffic offloading procedure. It means that after offloading for the downstream service entity successfully, the upstream service entity may try to offload traffic for the service entity next to its downstream service entity. For example, if CF successfully offloads the traffic for SN_1, then it may try to offload for SN_2. Recursively, if CF has successfully offloaded traffic for SN_2, it may try to offload for SN_2's downstream service entity (SN_3). 5. Security Considerations Security considerations are not addressed in this document. 6. IANA Considerations No IANA action is needed for this document. 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. Chen & Yang Expires August 18, 2014 [Page 7] Internet-Draft traffic offloading February 2014 7.2. Informative References [I-D.ietf-sfc-problem-statement] Quinn, P., Ed., "Service Function Chaining Problem statement, ", January 2014. [Openflow-Specification] "https://onfa.amsl.com/sdn-resources/onf-specifications/ openflow", . Authors' Addresses Hao Chen (editor) Huawei Technologies Co,. Ltd. 101 Software Ave., Yuhuatai Dist. Nanjing, Jiangsu 210012 China Phone: +86 025-5662-5335 Email: philips.chenhao@huawei.com Jishang Yang (editor) Huawei Technologies Co,. Ltd. Huawei Base, Bantian, Longgang Dist. Shenzhen 518129 China Phone: +86 755-2842-9186 Email: Yangjishang@huawei.com Chen & Yang Expires August 18, 2014 [Page 8]