Internet Working Group L. Niu H. Li Y. Jiang L.Yong Internet Draft Huawei Intended status: Standards Track Expires: October 2014 April 11, 2014 A Service Function Chaining Header and Forwarding Mechanism draft-niu-sfc-mechanism-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 October 11, 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 Niu and et al Expires October 11, 2014 [Page 1] Internet-Draft SFC Header and Forwarding Mechanism April 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 This document proposes a service function chain header and describes forwarding mechanism, including processing procedures for each component in a generic service function chain. Table of Contents 1. Introduction .............................................. 2 2. Conventions used in this document ......................... 3 3. Terminology ............................................... 3 4. Design Principles.......................................... 4 5. SFC Header ................................................ 4 5.1. Metadata ............................................... 6 6. Service Function Chain Process Procedures ................. 7 6.1. Classifier ............................................. 9 6.2. Service Forwarding Entity (SFE) ........................ 9 6.3. Service Function (SF) .................................. 9 7. Underlay Network Interconnection ......................... 10 7.1 SF Attachment .......................................... 11 8. Underlay network encapsulation ........................... 11 9. Security Considerations .................................. 12 10. IANA Considerations ...................................... 12 11. References ............................................... 12 11.1. Normative References ............................... 12 11.2. Informative References ............................. 12 12. Acknowledgments .......................................... 13 1. Introduction Service Function Chain (SFC) is an abstracted view of required service functions in a specific order that packets pass through for a given service. Service function chain network architecture contains three components that packets will traverse: classifier, service functions (SFs), and Service Forwarding Entities (SFEs) as described in [draft-jiang-sfc-arch]. Niu and et al Expires October 11, 2014 [Page 2] Internet-Draft SFC Header and Forwarding Mechanism April 2014 This document proposes a Service Function Chain header format and describes forwarding mechanism and the processing procedure on each component following the architecture [I-D.jiang-sfc-arch]. 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 Function (SF): a logical entity which provides 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. It can be realized as a dedicated hardware device, a server or a virtual machine hosted in a server. Service Forwarding Entity (SFE): a logical entity that forwards service packets between SFs through service chain forwarding mechanism. Optionally, it provides mapping, insertion and removal of header(s) in packets/frames. SFE may be implemented as dedicated hardware, or as virtual functions embedded in physical IT servers in NFV(network function virtualization) deployment situation. SFC Header: a header added specifically for a service function chain, and it is used by SFEs in forwarding packets. SFC Packet: a packet that encapsulated with an SFC header. Service Function Chain (SFC): an abstracted view of required service functions in a specific order that packets pass through for a given service. Service Path: a data plane mapping of a service function chain. A service path consists of a sequence of SF instances and SFEs which SFC packets in a service function chain pass through. Note service path may not be the shortest path for packets to its destination. Classifier (CLF): a logical entity classifies packets/frames based on service characteristics or policies and encapsulates them with SFC Niu and et al Expires October 11, 2014 [Page 3] Internet-Draft SFC Header and Forwarding Mechanism April 2014 headers. A classifier may reclassify SFC packets based on the SFC header information, and generating a new SFC header for these packets. Underlay Network: a network that transports SFC packets between SFE and SF or between SFEs. It may be an IP network, an Ethernet network, or an MPLS network, etc. SFC Forwarding Table: a forwarding table that is used by an SFE to look up the next SF for an SFC packet. It indicates the next SF to be associated with a certain Service chain in a service path. 4. Design Principles SFC header and forwarding mechanism in this draft are designed to fulfill following SFC requirements as described in [SFCREQ]: 1) Ability to convey path information of SFC via SFC packets. 2) Ability to convey metadata via SFC packets. 3) A Service Function may serve for one or more SFCs. 4) Decouple the functionality of SF from service chain forwarding function. 5) Decouple the underlay network transport function from the Service chain forwarding function. 6) Ability to support SFC OAM. 5. SFC Header An SFC header is proposed and depicted in Figure 1. Niu and et al Expires October 11, 2014 [Page 4] Internet-Draft SFC Header and Forwarding Mechanism April 2014 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|M|O| Reserved | Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SF ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Metadata (Optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OAM (Optional) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 SFC header o Version: version of the SFC header. This field is 4 bits long, and it MUST be set to 0x1 for this version. o M: value 1 indicates that metadata is present following the basic header, and value 0 indicates otherwise. o O: value 1 indicates that OAM is present following the basic header, and value 0 indicates otherwise. o Reserved: this field is reserved for future extension, and MUST be set to zero for this version. o Protocol Type: indicate the protocol type of the original packet in the SFC packet per IANA definition. o Path ID: the Service Path identifier, assigned for the traffic along the same Service Path in a service domain. The path ID field is set or changed by Classifier. This field is 32 bits long. o SF ID: This field is used to carry the previous SF or next SF ID in an SFC header. Each SF instance is assigned a unique value for its identification in an SFC domain. This field is usually set by an SFE before sending an SFC packet to its local SF. It may also be a Classifier ID when the SFC header is added by a classifier. Each SFE can look up its SFC Forwarding Table by use of the SF ID and Path ID in an SFC packet to get the next SF in the service path. o Metadata: optional, its format is defined in Section 5.1. o OAM: optional, its format will be specified in another document. Niu and et al Expires October 11, 2014 [Page 5] Internet-Draft SFC Header and Forwarding Mechanism April 2014 5.1. Metadata 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|S| Reserved | Metadata Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MetaData ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Basic metadata o F: FORWARDING type metadata, indicates there is metadata after the basic metadata header which can be used by an SFE in forwarding decision. o S: SERVICE type metadata, indicates there is metadata inserted by one or more SFs after the basic metadata header which can be used by other SFs in their service processing. o Reserved bits: 8 bits reserved for future extension, must be set to zero. o Metadata Length, the total length of Metadata in terms of a unit of 4 bytes. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SF Process Result | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 FORWARDING type metadata o SF Process Result: the SF processing result of an SFC packet. This field is 32 bits long. SFC packets may be forwarded by an SFE to different next SFs based on the SF processing results. Note only one FORWARDING type metadata can be appended in an SFC header. Niu and et al Expires October 11, 2014 [Page 6] Internet-Draft SFC Header and Forwarding Mechanism April 2014 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SF ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SERVICE MetaData( TLV ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 SERVICE type metadata o SF ID, identifies the SF that adds the SERVICE type metadata. o Length, length of SERVICE Metadata. o SERVICE MetaData (TLV), Type-length-value form metadata parameters, detailed information of this TLV will be specified in a future version. 6. Service Function Chain Process Procedures In general, there are three types of components in a service function chain, i.e. classier, SFE and SF, and each component is configured with a unique identifier. A classifier may be integrated in SFE or individual implemented, which performs: -classifying original data packets based on service characteristics (may be mapped to a tuple of fields in the packet), and building SFC packets by encapsulating these packets with an SFC header. Or -reclassifying SFC packets based on the SFC header information, and generating a new SFC header for the packets. An SF in SFC provides a specific service to the original packets encapsulated in Service Function Chain Header. Examples of SFs are firewall, load balancer, Intrusion detection system (IDS), etc. An SF may utilize SERVICE type metadata carried in the SFC packets for service processing. For example, SERVICE type metadata may be a subscriber ID that the packets are associated with. An SFE provides following functions: Niu and et al Expires October 11, 2014 [Page 7] Internet-Draft SFC Header and Forwarding Mechanism April 2014 - based on the SFC forwarding table configured in the SFE, forwarding SFC packets to next SF attached to it or to another SFE which next SF is attached to. - insert a transport header on SFC packets and send the packets to attached SFs or to other SFEs; process received packets from the transport network. - remove SFC header from an SFC packet, and send the original packet out of the SFC network. For example, two service paths are illustrated in Fig.5: Service Path 1: CLF1 -> A1 -> B1 -> C1. Service Path 2: CLF1 -> A1 -> B1 -> C2. In this example, CLF1 is a classifier; Service Function A1 and B1 are attached to SFE 1, and Service Function C1 and C2 are attached to SFE 2. Furthermore, A1 and B1 are local SFs to SFE1, while C1 and C2 are not. ............................................. . +----+ +----+ +----+ +----+ . . | SF | | SF | | SF | | SF | . . | A1 | | B1 | | C1 | | C2 | . . +-+--+ +-+--+ +--+-+ +-+--+ . . | | | | . . | | | | . . | | | | . +-----+ pkt +-----+ +-+------+--+ +--+-----+--+ . pkt +-----+ |Orig-| in | | | | | | . out |Orig-| |inal |---->| CLF1+----+ SFE 1 +----+ SFE 2 +--------->|inal | |Net- | | | | | | | . >|Net- | |work | +-----+ +-----------+ +-----------+ . |work | +-----+ . . +-----+ . SFC domain . .................... ........................ Figure 5 An Example of Service Path Niu and et al Expires October 11, 2014 [Page 8] Internet-Draft SFC Header and Forwarding Mechanism April 2014 Following sections describe the processing procedures for each type of SFC component. 6.1. Classifier Upon receiving a packet from a non-SFC network, the classifier performs the traffic classification on packets based on locally configured policy, and determines which service function chain it should pass through. Based on the classification result, an SFC header is appended. Parameters set in this SFC header include: - The Path ID field MUST be filled with a value that represents a particular service path corresponds to this service function chain. - The SF ID field MUST be set to the ID of this Classifier. - If metadata is needed, a metadata field can be added to the SFC header and the M flag MUST be set. - Protocol Type, MUST be set to correctly identify the original packet type. 6.2. Service Forwarding Entity (SFE) Upon receiving an SFC packet, an SFE looks up its SFC Forwarding Table with the Path ID and SF ID in the SFC header. If the lookup result points to a next SF that is local, the SF ID field of the SFC header is updated with the result, and the updated SFC packet is sent to the next SF; if the lookup result points to a next SF that is not local, the SFC packet is sent to the SFE with which the SF is attached to and with no change on the SF-ID; if the result is NULL, the SFC header is removed from the SFC packet, and the original packet is sent to the non-SFC network. 6.3. Service Function (SF) Upon receiving an SFC packet from an SFE, an SF retrieves the original packets carried in the SFC packet and performs service processing; and then adds the same SFC header to the original packets and sends the SFC packet back to the SFE where it came from. If an SF requires use of metadata in service processing, it SHOULD retrieve SERVICE type metadata from SFC packets. Niu and et al Expires October 11, 2014 [Page 9] Internet-Draft SFC Header and Forwarding Mechanism April 2014 If an SF needs to pass metadata to other SFs, it MUST append the specific SERVICE type metadata to the SFC header and set SF ID to itself. 7. Underlay Network Interconnection The underlay network is used to transport SFC packets between SFC components. Underlay networks between SFEs or between an SF and an SFE may be the same or different from one another. Figure 6 depicts an example of underlay network used to connect SFC components. CLF1 is connected to SFE1 with a GRE tunnel. Other local components are connected with IP network or Ethernet network. ............................................ . +----+ +----+ +----+ +----+ . . | SF | | SF | | SF | | SF | . . | A1 | | B1 | | C1 | | C2 | . . +--+-+ ++---+ +--+-+ ++---+ . . | | | | . . +-+----+-+ +-+----+-+ . . | IP | |Ethernet| . . |Network | |Network | . . +---+----+ +---+----+ . . | | . +-----+ +--+--+ +----+------+ +----+------+ . +-----+ |Orig-| | | | | | | . |Orig-| |inal |---->| CLF1| | SFE1 | | SFE2 +-------->|inal | |Net- | | | | | | | . |Net- | |work | +--+--+ +-+------+--+ +-----+-----+ . |work | +-----+ . | | | | . +-----+ . | +-----+--+ | +--------+ | . . +---+ GRE | +--+ IP +-+ . . | Tunnel | |Network | . . +--------+ +--------+ . . . . SFC domain . ............................................ Figure 6 SFC underlay network interconnection Niu and et al Expires October 11, 2014 [Page 10] Internet-Draft SFC Header and Forwarding Mechanism April 2014 7.1 SF Attachment In order to transport SFC packets over various underlay networks, SFC components need to maintain necessary information, for example, underlay network type, underlay network addresses and etc. The information is obtained by an SF attachment procedure. In the SF attachment procedure, SFEs get the following SF information: -SF ID, identifier of the attached SF. -Local flag: indicate whether or not packets can be forwarded to an SF from this SFE without going through another SFE. -underlay network type: if the SF is locally attached, this field is the underlay network type connecting to this SF; otherwise, it is the underlay network type connecting to another SFE which the SF is locally attached to. -underlay network address: if the SF is locally attached, this field is the underlay network address of this SF; otherwise, it is the underlay network address of another SFE which the SF is locally attached to. The SF attachment procedure MAY be done by management provisioning, or dynamic signaling. 8. Underlay network encapsulation SFC packets can be transported over any underlay network. Two examples are shown here. UDP encapsulated SFC packet is formatted as following: +--------+--------+------------------+-----------------+ | IP | UDP | SFC | Original Packet | | Header | Header | Header | | +--------+--------+------------------+-----------------+ Figure 7 IP/UDP as underlay network A special UDP port value should be assigned by IANA to identify that the UDP payload is an SFC packet. Niu and et al Expires October 11, 2014 [Page 11] Internet-Draft SFC Header and Forwarding Mechanism April 2014 SFC header can also be encapsulated in a GRE header as following: +------------+-------------------------+----------------------+ | GRE header | SFC Header | original data packet | +------------+-------------------------+----------------------+ Figure 8 GRE as underlay network A special GRE Protocol Type value should be assigned by IANA to identify that the GRE payload is an SFC packet. 9. Security Considerations It will be considered in a future revision. 10. IANA Considerations For IP/UDP underlay network, a specific UDP port value should be assigned by IANA to identify the UDP payload is service chaining packet. For GRE underlay network, a specific GRE protocol type should be assigned by IANA to identify the GRE payload is service chaining packet. 11. References 11.1. Normative References [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina; Generic Routing Encapsulation (GRE); March 2000 11.2. Informative References [I-D.jiang-sfc-arch] Y. Jiang, H. Li; An Architecture of Service Function Chaining; February, 2014 [SFCREQ] Boucadair, M., and et al, "Requirements for Service Function Chaining", draft-boucadair-sfc-requirements-03, February 2014. Niu and et al Expires October 11, 2014 [Page 12] Internet-Draft SFC Header and Forwarding Mechanism April 2014 12. 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 Lucy Yong Huawei Technologies Co., Ltd. 1700 Alma Drive, Suite 100 Plano, TX USA Email: lucy.yong@huawei.com Niu and et al Expires October 11, 2014 [Page 13]