Internet Working Group Y. Jiang H. Li Internet Draft Huawei Intended status: Informational Expires: August 2014 February 14, 2014 An Architecture of Service Function Chaining draft-jiang-sfc-arch-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 14, 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 Jiang, et al Expires August 14, 2014 [Page 1] Internet-Draft Service Chaining Architecture 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. Abstract As network virtualization is opening the gate to much more innovative services for service providers, Service Function Chaining (SFC) provides a flexible way of service provisioning and facilitates their deployments. This document provides a general abstract architecture for service chaining. It is a flexible and scalable architecture which can fulfill requirements of SFC. Some solutions based on this architecture are also discussed and compared. This architecture can be used as a guideline and also a criterion for the design of SFC. Table of Contents 1. Conventions used in this document ......................... 3 2. Terminology ............................................... 3 3. Introduction .............................................. 3 4. Service Chaining Architecture ............................. 5 5. Service Chaining Topology ................................. 7 6. Service Chaining Construction ............................. 7 6.1. Service chaining Controller ............................ 8 7. Availability and Scalability of Service Chaining........... 8 8. Service Chaining Solution Considerations .................. 9 8.1. Ethernet compatible solution ........................... 9 8.2. IP/MPLS compatible solution ........................... 10 8.3. Solution of Network-Located Function Chaining (NLFC) .. 10 8.4. Solution with a standalone service header ............. 10 9. Security Considerations .................................. 10 10. IANA Considerations ...................................... 11 11. References ............................................... 11 11.1. Normative References ............................... 11 11.2. Informative References ............................. 11 12. Acknowledgments .......................................... 11 Appendix Change Log .......................................... 11 Authors' Addresses ............................................ 12 Jiang, et al Expires August 14, 2014 [Page 2] Internet-Draft Service Chaining Architecture February 2014 1. Conventions used in this document 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]. 2. Terminology 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 Classifier (SCLA), an entity which can classify incoming packets/frames into different service flows based on their service characteristics or some policies. Service Function (SF): 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. This entity may also provide packet/frame encapsulation/decapsulation capability. Service Chain (SC): one or more service processing functions in a specific order which are chained together to provide a composite service, and packets/frames from one or more service flow should follow and be processed in sequence. Service Chaining Domain: a domain where packet is forwarded using service chaining mechanism. Service Forwarding Entity (SFE): a logical entity which forwards packets/frames to SFs attached to this SFE or other SFEs in the same service chain. Optionally, it provides mapping, insertion and removal of header(s) in packets/frames. Note service forwarding path may not be the shortest path to its destination. Service Function Chaining (SFC): a mechanism of building service chains and forwarding packets/frames of service flows through them. 3. Introduction With the maturity of hardware/software in network virtualization, it is possible for service providers to provide more innovative services. Jiang, et al Expires August 14, 2014 [Page 3] Internet-Draft Service Chaining Architecture February 2014 Service chaining provides a flexible way to construct services, e.g., it is easy to insert/remove, and upgrade service processing functions for a service in this framework. It is thus possible to define very complex services over heterogeneous networks in a consistent way with the help of service chaining. Several drafts have already been proposed for service chaining with different approaches ([NLFC], [NSH] and [L3VPNSC]) and more solutions are expected to emerge in the near future. This document provides architecture and abstraction of the critical components for service function chaining, and it is hoped to shed some lights on the design of service chaining. Possible solutions of service chaining are also outlined and compared in this document so that they can be gauged under the same criterion. Jiang, et al Expires August 14, 2014 [Page 4] Internet-Draft Service Chaining Architecture February 2014 4. Service Chaining Architecture In order to decouple the service from the networks, three layers of protocols are envisioned in the stack of SFC: -Service layer; -SFC forwarding layer; -Network under layer. In the Service Layer, service functions may be provided with metadata capability, but they may also behave like the traditional network devices such as firewall or DPI. Therefore, a null or service layer encapsulation/decapsulation may be needed. In the SFC forwarding layer, a Sevice Chain (SC) can be abstracted to consist of the following components: - At least one Service CLAssifier (SCLA), which classifies incoming packets/frames into different service flows based on their service characteristics or some policies; - One or more Service Forwarding Entities (SFEs), which make up the forwarding path of a SC, and each SFE is attached with one or more Service Functions. - One or more Service Functions (SFs), which are connected with SFEs and provide various service processing functions for a SC. Service chaining architecture with a single SFE is demonstrated in Figure 1. Upon their entry into a service chaining domain, packets/frames are classified by SCLA into different service flows. Then packets/frames from a specific service flow are forwarded by SFE into one or more SFs in a service chain in correct order. Upon completion of all service processing, they exit the service chaining domain. It should be noted that SCLA, SFE, and even SFs can be implemented in a single network element. Jiang, et al Expires August 14, 2014 [Page 5] Internet-Draft Service Chaining Architecture February 2014 SF SF /-\ /-\ SF: Service Function | | ... | | \+/ \+/ SFE: Service Forward Entity | | | | SCLA: Service CLAssifier | | +--------+ +-+---------+--+ ENTRY| | | |EXIT ----+ SCLA +-----+ SFE +---- | | | | +--------+ +--------------+ Figure 1 Service Chain with a single SFE Service chaining architecture with multiple SFEs is further demonstrated in Figure 2. SF SF SF SF /-\ /-\ /-\ /-\ | | ... | | | | ... | | \+/ \+/ \+/ \+/ | | | | | | | | | | | | +--------+ +-+---------+--+ +-+---------+--+ ENTRY| | | | | | EXIT ----+ SCLA +-----+ SFE +---------+ SFE +----- | | | | | | +--------+ +--------------+ +--------------+ Figure 2 Service Chain with Multiple SFEs The Network under layer such as IP, MPLS, and Ethernet provides the traditional transport (routing and switching) capability for the SCs. Interconnections between SFs and their SFEs, and between SFE peers can be a physical/logical link or a network path which may be an Ethernet or IP/MPLS underlay network. Ethernet, IP/MPLS or other Jiang, et al Expires August 14, 2014 [Page 6] Internet-Draft Service Chaining Architecture February 2014 tunneling technologies such as those being in progress in NVO3 workgroup can be used for this underlay network. 5. Service Chaining Topology SCLA, SF and SFE can be implemented as a standalone network entity, or in a network entity combined with other functions (such as one SFE plus one or more SFs, one SCLA plus one SFE, or one SCLA plus one SFE and one or more SFs). Furthermore, they may be implemented as software modules running in a DC, in clouds or as standalone physical equipments. Following service chaining topologies can be supported by this architecture: -Daisy chain This is a type of service chain in the shape of a daisy, as demonstrated in Figure 1, where multiple SFs are attached to a single SFE, and SFs cannot send packets/frames directly to each other but via one shared SFE. -Lily chain This is a type of service chain in the shape of a lily. It can be regarded as a simplified form of Figure 2, where only a single SF is attached to each SFE, and the SFEs are connected from one to another in sequence. -Hybrid chain Part of a hybrid chain may be Daisy chain and other parts may be Lily chain, thus it can be readily combined by the previous two. More complex service chains can be constructed by reclassification of a SC (for example, by providing multiple SCLAs in a SC); or by change of the metadata in a SF (thus enforce a change to its forwarding paradigm). 6. Service Chaining Construction Attachment of SFs onto an SFE could be pre-configured on the SFE; or updated by some auto discovery and registering procedure when an SF first attaches to it. Jiang, et al Expires August 14, 2014 [Page 7] Internet-Draft Service Chaining Architecture February 2014 6.1. Service chaining Controller A service chaining controller which centrally manages service chains (e.g., set up, remove, and monitor service chains) can be implemented together with an SDN controller or a network orchestrator. OSS may also be used as a platform to provide this kind of control function. In service layer, a Service Graph (SG) shall be defined for each Service Chain (SC), which consists of a list of Service Functions and their order, and parameters for the service flow over the SC. In service forwarding layer, a Service Forwarding Graph (SFG) shall be defined for each Service Chain, which consists of a list of Service Functions and SFEs between them. The service chaining controller is responsible for mapping a SG to a SFG, installing/updating/removing classification tables on/from the SCLAs, and installing/updating/removing service forwarding tables on/from the SFEs. A northbound RESTful API can be specified for the SC controller to manage and control SCs over the web. 7. Availability and Scalability of Service Chaining Two options for load balancing are possible: -Load balancing on flows It is very convenient to provide load balancing and make it scalable in this architecture: construct multiple service chains which provide the same set of service processing functions; the SCLA classifies a service flow into sub-flows, and each sub-flow is directed into a different service chain. -Load balancing on SFs/paths It is also possible to provide load balancing in finer granularity. Such as, provide multiple SFs with the same service processing function if a compute bottleneck is expected or found for this service processing function; provide multiple paths between a pair of SFEs if shortage of bandwidth is expected or found for the single path between them. The SFE should be able to load balance a service flow over these SFs or paths with some pre-determined algorithms. Jiang, et al Expires August 14, 2014 [Page 8] Internet-Draft Service Chaining Architecture February 2014 High availability of a service chain will be discussed in a next version. 8. Service Chaining Solution Considerations A solution must be able to classify packets/frames into different service flows. This is done by the Service Classifier (a packet/frame is classified with a tuple of fields in one or more headers or local policy). After the classification, a Service Identification (SID) may be applied to the packet/frame so that no further classification is needed in subsequent SFEs. SID can be mapped to traditional header fields such as a VLAN or an MPLS label (hence VLAN mapping or MPLS label swap is needed), or carried in a new service header (hence an extra header is inserted). A solution must be able to forward packets/frames across all service processing entities in a service chain in a correct sequence. This is done by the service forwarding entity with the help of SID. A solution should support the exchange of information between service processing entity and the service forwarding entity. For example, the processing result of a packet in a service processing entity can be encoded in a service header in the packets. But for long term service states (which can influence the processing of multiple packets/frames), they can be locally stored and/or signaled to service forwarding entity or other service processing entities by some specific control channels (e.g., OpenFlow protocol). [REQ] outlines a suite of requirements for service function chaining. Possible solutions for service chaining are outlined in the following sub-sections. 8.1. Ethernet compatible solution Ethernet technology (IEEE 802.1Q, 802.1ad, and etc.) or DC technology can be used to support service chaining. SCLA maps service ID of a service flow to a VLAN (e.g., C-VLAN and S-VLAN) ID or a VXLAN ID in a frame. SFE then forwards the frame with the VLAN ID to appropriate SFs for service processing (may need to change VLAN ID for each SF). The issue with this solution: its service chaining layer is entangled with its transport layer, thus planning and provisioning of service chains are complex, and it may not be a scalable solution to be used Jiang, et al Expires August 14, 2014 [Page 9] Internet-Draft Service Chaining Architecture February 2014 in a large network since VLAN ID or VXLAN ID space is shared by both service ID and tunnel ID. 8.2. IP/MPLS compatible solution MPLS can be used to support service chaining - only an MPLS label is needed to represent SID of a service flow. Service ID of a service flow is mapped to an MPLS label in the packets by the SCLA. SFE then forwards frames with the label to appropriate SFs for service processing (may need to swap the label for each SF). [L3VPNSC] demonstrates how service topology specific Route Targets can be introduced into BGP/MPLS VPN to support automatic signaling of service chaining. Similarly, L2VPN may be crafted to support service chaining. 8.3. Solution of Network-Located Function Chaining (NLFC) [NLFC] proposes a solution of using NLFC Map (an ordered list of NLF identifiers) for service chaining, where a packet carries a map index of its service chain, then NLF nodes forward the packet by looking up the map index in locally stored NLFC Policy Table for its next NLF node. 8.4. Solution with a standalone service header A standalone service header can provide an independent layer of protocol data unit, so that service specific information such as SID can be carried over all kinds of underlay networks with no need of mapping. [NSH] proposes a new Network Service Header for service chaining, which consists of a Base Header and a Context Header. [SCHM] also introduces a simple service chaining header and how to use it to build service chains. 9. Security Considerations This document proposes architecture for the service chaining, outlines several types of its topology, and discusses possible approaches in this domain, thus no security issue is raised at present. It was expected that further solutions for these requirements will deal with security considerations specifically. Jiang, et al Expires August 14, 2014 [Page 10] Internet-Draft Service Chaining Architecture February 2014 10. IANA Considerations No IANA action is needed for this document. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2. Informative References [NLFC] Boucadair, M., and Jacquenet, C., "Service Function Chaining: Framework & Architecture", draft-boucadair-sfc-framework-02, February 2014. [NSH] Quinn, P., and Fernando, R., and et al, "Network Service Header", draft-quinn-sfc-nsh-01, February 2014. [SCHM] Niu, L., Li, H., and Jiang, Y., "A Service Function Chaining Header and its Mechanism", draft-niu-sfc-mechanism-00, January 2014. [L3VPNSC] Fernando, R., Rao, D., and et al, "Virtual Topologies for Service Chaining in BGP IP VPNs", draft-rfernando-l3vpn- service-chaining-01, June 2013. [REQ] Boucadair, M., and et al, "Requirements for Service Function Chaining", draft-boucadair-sfc-requirements-03, February 2014. [PS] Quinn, P., and et al, "Network Service Header",draft-ietf-sfc- problem-statement 12. Acknowledgments TBD. Appendix Change Log A.1 draft-jiang-service-chaining-arch-00, June 2013 A.2 draft-jiang-sfc-arch-00, October 2013 A.2 draft-jiang-sfc-arch-01, February 2014 Jiang, et al Expires August 14, 2014 [Page 11] Internet-Draft Service Chaining Architecture February 2014 Authors' Addresses Yuanlong Jiang Huawei Technologies Co., Ltd. Bantian, Longgang district Shenzhen 518129, China Email: jiangyuanlong@huawei.com Hongyu Li Huawei Technologies Co., Ltd. Bantian, Longgang district Shenzhen 518129, China Email: hongyu.lihongyu@huawei.com Jiang, et al Expires August 14, 2014 [Page 12]