Network Working Group H. Li Internet-Draft Y. Jiang Intended status: Informational Huawei Technologies Expires: December 29, 2013 June 27, 2013 Requirements for Service Chaining draft-li-service-chaining-requirements-00 Abstract Chaining some service processing functions may provide services in a flexible way. Such a method is called service chaining. This document presents a list of general requirements service chaining should support. Solutions of service chaining are not presented in this document. 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 December 29, 2013. Copyright Notice Copyright (c) 2013 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. Li & Jiang Expires December 29, 2013 [Page 1] Internet-Draft Service Chaining Requirements June 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Basic Requirements . . . . . . . . . . . . . . . . . . . 3 3.2. Enhanced Requirements . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction Chaining some service processing functions may provide services in a flexible way. There are many type of service processing functions, which have different ways of processing packets. For example, firewall may transparently forward or drop a packet, while NAT changes the IP header of a packet. A service chain may consist of several types of service processing functions. One service processing function may be shared by multiple service chains. A packet must be correctly identified and forwarded after being processed by such a shared service processing function. Service chain may be implemented in different environment, e.g. in physical networks, in a Datacenter, etc. There are some necessary requirements for a service chain to be constructed and work properly. 2. Terminology The following terms are used in this document: Service Processing Function: a logical entity which can provide one or more service processing functions for packets/frames such as firewall, DPI (Deep Packet Inspection), LI (Lawful Intercept) and etc. Usually these processing functions are computation intensive. Service Flow: packets/frames with specific service characteristics (e.g., packets matching a specific tuple of fields in Ethernet, IP, TCP, HTTP headers and etc.) or determined by some service policies (such as access port and etc.) Service Chain: one or more service processing functions in a specific order which are chained to provide a composite service, and packets/ frames from one or more service flow should follow. Service Chaining: a mechanism of building service chains and forwarding packets/frames of service flows through them. Li & Jiang Expires December 29, 2013 [Page 2] Internet-Draft Service Chaining Requirements June 2013 3. Requirements Service chains exist in many different scenarios, and have some requirements in common, which are basic requirements and must be supported. In some scenarios, more complex service chains are constructed and some enhanced requirements should be satisfied. 3.1. Basic Requirements - Service chaining MUST support classifying traffic and direct it into a service chain. Service chain may be a bypass and different from normal L2 or L3 forwarding. Service chaining needs a traffic classification function to identify traffic needs to be directed into a service chain. - Service chaining MUST be able to forward traffic through service processing functions in a sequence without relying on destination address of packets. This means service chaining must support forwarding packets to a path where they will not go through in case of normal switching or routing per destination addresses. Service chain is usually a bypass different from normal forwarding path of switching or routing. Traffic is redirected into a chain of service processing functions for service processing purpose when necessary. Therefore, such redirection is based on policy or service characteristics of traffic or policy. - Service chaining MUST be able to forward service flow traffic through various forms of service processing functions. Service processing functions could be implemented as physical nodes, virtual machines, or even processes in a server. Service chaining must support all these implementations and allow different implementations co-exist in a same chain. -Service chaining MUST support coexistence of different types of service processing functions in a same service chain. Some service processing functions forward traffic transparently, e.g. load balancer, some service processing functions forward and modify traffic, e.g. NAT, while some other service processing functions terminate traffic, e.g. cache. - Service chaining MUST be able to support multiple service chains/ paths share the same group of service processing functions. With a group of service processing functions available, more than one service chain can be built with same or different subset of service processing functions in any reasonable sequence. - Service Chaining MUST support multiple service chains sharing one or more service processing function(s). For given several service Li & Jiang Expires December 29, 2013 [Page 3] Internet-Draft Service Chaining Requirements June 2013 chains, they may have different service processing functions, while sharing one or more service processing functions, or , they may have same service processing functions but in different order. Service chaining must be able to identify service flows of these different service chains and forward them correctly, after the flow is processed by a shared service processing function. - Service chaining MUST support statically configuring forwarding path of a service chain. Purpose of a service chain is to build a service, which is usually designed in advance. Sequence of service processing functions, the path, is part of the design of a service. To direct traffic through this path, forwarding functions in a service chain must be configured of forwarding path in advance, which could be done statically. - Service chaining MUST be able to identify a flow and forward it to the correct next hop in the service chain it belongs to, even if it is changed by a service processing function. An example of this is a flow going through a NAT, where IP headers of packets in this flow are changed. The flow MUST be correctly identified after been processed by NAT and forwarded to its next hop in the service chain. 3.2. Enhanced Requirements - Service chaining SHOULD support forwarding traffic across various underlay networks. Service processing functions may exist in different forms and underlay network providing connection between them may vary. Service chaining should support forwarding traffic through service chains over L2, L3 and VPN networks. - Service chaining SHOULD support service chains over heterogeneous underlay networks. A service chain may chain service processing functions located in different types of networks, e.g. L2 or L3. Service chaining should be able to transport traffic through these service processing functions even if they are in different types of underlay networks. - Service chaining SHOULD support forwarding traffic to different paths according to process result of a service processing function. In case DPI is in a service chain, the next service processing function after DPI may be selected according to the result of DPI. Thus, traffic after DPI may be directed to different paths accordingly. 4. IANA Considerations This document makes no request for IANA action. Li & Jiang Expires December 29, 2013 [Page 4] Internet-Draft Service Chaining Requirements June 2013 5. Security Considerations Service chaining should consider security issues and will be discussed in future revisions. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Hongyu Li Huawei Technologies Huawei Industrial Base Shenzhen China Email: hongyu.li@huawei.com Yuanlong Huawei Technologies Huawei Industrial Base Shenzhen China Email: jiangyuanlong@huawei.com Li & Jiang Expires December 29, 2013 [Page 5]