Internet Working Group L. Niu H. Li Y. Jiang Internet Draft Huawei Intended status: Standards Track Expires: July 2014 January 18, 2014 A Service Function Chaining Header and its Mechanism draft-niu-sfc-mechanism-00.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 July 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 carefully, as they describe your rights and restrictions with respect Niu and et al Expires July 18, 2014 [Page 1] Internet-Draft A SFC Header and its Mechanism January 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. Abstract This document describes a service chaining mechanism in the forwarding plane, by which data packets can be forwarded to multiple Service Processing Entities and processed by them in a preset order. This document also describes a lightweight service chaining header to facilitate packet forwarding in service function chains. Table of Contents 1. Introduction .............................................. 2 2. Conventions used in this document ......................... 3 3. Terminology ............................................... 3 4. Service chaining header ................................... 4 5. Service classification mechanism .......................... 5 6. Service chaining mechanism ................................ 6 6.1. SFE behavior ........................................... 6 6.2. SPE behavior ........................................... 6 7. Underlay network encapsulation ............................ 7 8. Security Considerations ................................... 7 9. IANA Considerations ....................................... 8 10. References ................................................ 8 10.1. Normative References ................................ 8 10.2. Informative References .............................. 8 11. Acknowledgments ........................................... 9 1. Introduction Service function chaining is a technology to direct packets going through one or more Service Processing Entities (SPE). A service chaining network includes one or multiple Service Forwarding Entities (SFE) where SPEs are attached to. Service chaining architecture is defined in [draft-jiang-service-chaining-arch]. SPE provides enhanced service processing such as load balancing, NAT, network firewall, or URL filtering. In this document, a SFE provides the following service chaining functions: Niu and et al Expires July 18, 2014 [Page 2] Internet-Draft A SFC Header and its Mechanism January 2014 - classify original data packet based on service characteristics (may be mapped to tuples of the packet), and add a service chaining header in front of the packet. A packet with a service chaining header is called a service chaining packet. - forward service chaining packets between SPE and SFE or between SFE and SFE, based on the service chaining forwarding table. - remove service chaining header from a service chaining packet after the last SPE finishing service processing, recover the original packet, and send it out based on traditional forwarding mechanism such as IP forwarding. 2. 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]. 3. Terminology Service Processing Entity (SPE): 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 Forwarding Entity (SFE): a logical entity which forwards packets/frames to one or more SPEs in a 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 Chaining Header: a header in front of packet, added by a SFE. SFE uses service chaining header information to forward service chaining packet. Service Chaining Packet: an original packet added with a service chaining header. Niu and et al Expires July 18, 2014 [Page 3] Internet-Draft A SFC Header and its Mechanism January 2014 Underlay Network: a network conveying service chaining packet between SFE and SPE or between SFEs. It may be an IP network, an Ethernet networks, or an MPLS networks, etc. Service Chaining Table: Service chaining table is used to indicate next hop of SFE forwarding service chaining packet. 4. Service chaining header The service chaining header is depicted in Figure 1 below. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous SPE ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next SPE ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SPE Process Result | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 service chaining header o Version: represents the service chaining header version. This field is 4 bits long, and current version is 0x0001. o Reserved: this field is reserved for future extension. o Path ID: the path identifier, assigned for the traffic along the same service path in a service domain. The path ID field is set by SFE based on result of traffic classification or SPE processing result. This field is 32 bits long. Niu and et al Expires July 18, 2014 [Page 4] Internet-Draft A SFC Header and its Mechanism January 2014 o Previous SPE ID: the previous SPE that has handled the packet. Each SPE instance is assigned a unique value for identification in a service chaining domain. After processing the packet, the SPE will replace the previous SPE ID value with its own SPE ID in the service chaining header. This field is 32 bits long. -special value of all zero means no previous SPE for current packet. o Next SPE ID: the next SPE that will handle the packet. When SFE receives the packet from a SPE, it gets the next SPE ID based on path ID, previous SPE ID and SPE Process Result, and fills the next SPE ID value in Next SPE ID field. This field is 32 bits long. -a special value of 0xffffffff means no next SPE for current packet, and the SFE should remove the service chaining header. o SPE Process Result: the SPE process result of a packet. If the SPE has several different processing results for packets with the same Path ID, and packets can go to different next SPEs based on the SPE processing results. These paths are called branch paths. The SPE Process Result field is filled by SPE, which is used to inform the SFE. The SFE then uses this value and other fields in the service chaining header to determine the next action to apply to the packet. This field is 32 bits long. -0x0000, a default value, indicate to SFE that the data packet should be kept in the same service path. 5. Service classification mechanism When a SFE receives an original packet at the boundary of a service chaining domain, it performs service classification function. The result of classification is used to determine the path ID of the service chaining header. The SFE adds a service chaining header for the packet that enters a service chaining domain: - set the same path ID for packets of the same service path. Different service paths will have different service path ID; -set initial SPE Process Result value to 0x00000000, Niu and et al Expires July 18, 2014 [Page 5] Internet-Draft A SFC Header and its Mechanism January 2014 -set the previous SPE ID field to all zero (a special value which means no previous SPE for this data packet currently). The service classification may be based on tuples of a packet, DPI result of a packet, and etc. 6. Service chaining mechanism 6.1. SFE behavior When a SFE receives a service chaining packet from its traffic classifier module, from a SPE or another SFE, it performs following actions: 1 get Path ID, SPE Process Result and Previous SPE ID from the service chaining header in this service chaining packet, 2 look up its Service Chaining Table to get the new Path ID and next SPE ID. The Service Chaining Table should maintain the following information: lookup key: Path ID + Previous SPE ID + SPE Process Result lookup result new Path ID and next SPE ID 3 set Path ID field of the Service Chaining Header with the new Path ID set Next SPE ID field of the Service Chaining Header with next SPE ID. --if next SPE ID=0xffffffff, meaning no next SPE for current packet, the SFE should remove the service chaining header and send the packet out of the service chaining domain; 4) get underlay network address that can reach the next SPE based on the Next SPE ID, encapsulate a underlay network header before its Service Chaining Header, and send out the packet. 6.2. SPE behavior When a SPE receives a packet with underlay network header and service chaining header from a SFE, it performs service processing function, sets SPE Process Result field of the service chaining header based on the processing result, sets the Previous SPE ID of the service Niu and et al Expires July 18, 2014 [Page 6] Internet-Draft A SFC Header and its Mechanism January 2014 chaining header to be the current SPE ID, encapsulates a new underlay network header and send the packet back to the SFE. 7. Underlay network encapsulation Service chaining header can be encapsulated in a UDP header or GRE header. Service chaining header can be encapsulated in a UDP header as following: +--------+--------+------------------+-----------------+ | IP | UDP | Service Chaining | Original Packet | | Header | Header | Header | | +--------+--------+------------------+-----------------+ Figure 2 IP/UDP as underlay network A special UDP port value should be assigned by IANA to identify that the UDP payload is a service chaining packet. Service chaining header can also be encapsulated in a GRE header as following: +------------+-------------------------+----------------------+ | GRE header | Service Chaining Header | original data packet | +------------+-------------------------+----------------------+ Figure 3 GRE as underlay network A special GRE Protocol Type value should be assigned by IANA to identify that the GRE payload is a service chaining packet. 8. Security Considerations It will be considered in a future revision. Niu and et al Expires July 18, 2014 [Page 7] Internet-Draft A SFC Header and its Mechanism January 2014 9. IANA Considerations If using IP/UDP as underlay network, a specific UDP port value should be assigned by IANA to identify the UDP payload is service chaining packet. If using GRE as underlay network, a specific GRE protocol type should be assigned by IANA to identify the GRE payload is service chaining packet. 10. References 10.1. Normative References [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina; Generic Routing Encapsulation (GRE); March 2000 10.2. Informative References [I-D.jiang-service-chaining-arch] Y. Jiang, H. Li; An Architecture of Service Chaining; June, 2013 Niu and et al Expires July 18, 2014 [Page 8] Internet-Draft A SFC Header and its Mechanism January 2014 11. Acknowledgments TBD Authors' Addresses Lehong Niu Huawei Technologies Co., Ltd. Bantian, Longgang district Shenzhen 518129, China Email: niulehong@huawei.com Hongyu Li Huawei Technologies Co., Ltd. Bantian, Longgang district Shenzhen 518129, China Email: hongyu.li@huawei.com Yuanlong Jiang Huawei Technologies Co., Ltd. Bantian, Longgang district Shenzhen 518129, China Email: jiangyuanlong@huawei.com Niu and et al Expires July 18, 2014 [Page 9]