Network Working Group H. Zhang Internet-Draft L. Fourie Intended Status: Proposed Standard Huawei R. Parker Affirmed Networks M. Zarny Goldman Sachs Expires: September 25, 2014 March 24, 2014 Service Chain Header draft-zhang-sfc-sch-00 Abstract This document describes a service chaining header format and encapsulation mechanism that is used to facilitate the forwarding of data packets along the service function chain path. This header also allows for the transport of metadata to support various service chain related functionality. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2014 IETF Trust and the persons identified as the Zhang, et al Expires September 25, 2014 [Page 1] Internet-Draft Service Chain Header March 24, 2014 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Service Chain Header . . . . . . . . . . . . . . . . . . . . . 5 4.1 Header Format . . . . . . . . . . . . . . . . . . . . . . . 5 4.2 Mandatory Fields . . . . . . . . . . . . . . . . . . . . . . 6 4.3 Optional Metadata Fields . . . . . . . . . . . . . . . . . . 8 4.4 Header Associated Operations . . . . . . . . . . . . . . . . 9 5. SCH Encapsulation . . . . . . . . . . . . . . . . . . . . . . . 10 5.1 SCH in Overlay GRE Encapsulation . . . . . . . . . . . . . . 10 5.2 SCH in MAC Encapsulation . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA and IEEE Considerations . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1 Normative References . . . . . . . . . . . . . . . . . . . 11 8.2 Informative References . . . . . . . . . . . . . . . . . . 12 9. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1 OAM Operation . . . . . . . . . . . . . . . . . . . . . . . 13 9.2 Service Function Selector . . . . . . . . . . . . . . . . . 13 9.3 Target Address . . . . . . . . . . . . . . . . . . . . . . . 13 9.4 OAM Service Function Trace . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Zhang, et al Expires September 25, 2014 [Page 2] Internet-Draft Service Chain Header March 24, 2014 1. Introduction Service chaining is a traffic steering technology for applying an ordered set of network service functions to traffic flows between two endpoints. Network service functions may include NAT, firewall, server load balancing, WAN optimization, and others, many of which can operate up to OSI Layer 7, and run on hardware appliances or virtual machines. Service function chaining is an enabling technology for providing more agile service delivery required by cloud computing and network functions virtualization. (See [SFC-PS] and [SFC-ARCH] for more detailed discussions on service chaining.) In order to support service function chaining, a mechanism is needed to carry service function chain (SFC) path and optional metadata information across various SFC entities. Ideally, the mechanism imposes minimal network overhead, works over various transport technologies at different OSI layers, and can accommodate future services. Given the likelihood of innovation in existing and future service functions and the impossibility of predicting what form every type of metadata will take, the mechanism should allow for the flexibility of carrying different types and lengths of metadata for different usage scenarios, and accommodate the addition of new types of service metadata. (See [SFC-META] for metadata considerations for service function chains.) It is acknowledged that either out-of-band or inband mechanism or a combination of both may be utilized to transfer metadata in service function chains. This document describes only an inband mechanism. This document proposes the use of the Service Chain Header (SCH), which comprises a fixed-length mandatory portion used for steering purposes and an optional variable-length TLV (Type-Length-Value) approach to carry inband metadata between service function chaining entities. 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 RFC 2119 [RFC2119]. 3. Terminology Zhang, et al Expires September 25, 2014 [Page 3] Internet-Draft Service Chain Header March 24, 2014 Most of the terminologies used in this document are from [SFC-ARCH], [SFC-FWK] and [SFC-META], and are summarized here for convenience: Service Function (SF): A network function that provides a value-added service to packet flows. A service function can act at any OSI layer. Service functions include: firewall, DPI (Deep Packet Inspection), NAT, HTTP Header Enrichment function, TCP optimizer, load-balancer, etc. SF Chain: An ordered list of Service Function instances. See SF Map. SF Chain Identifier: Identifies an SF Chain (SF Map Index). SFC-enabled domain: Denotes a network (or a region thereof) that implements SFC. SF Identifier: A unique identifier that unambiguously identifies an SF within an SFC-enabled domain. SF Identifiers are assigned, configured and managed by the administrative entity that operates the SFC-enabled domain. SF identifiers can be structured as strings, or in other formats. SF Identifiers are not required to be globally unique nor be exposed to or used by another SF-enabled domain. Service Function Forwarder (SFF): Provides service layer forwarding. An SFF receives frames/packets from an SFC Network Forwarder and forwards the traffic to the associated SF(s) using information contained in the SCH. SFC Network Forwarder (SNF): Forwards traffic flows along the SFPs they belong to based on the information contained in the SFC encapsulation. SF Map: Refers to an ordered list of SF identifiers. Each SF Map is identified with a unique identifier called SF Map Index. This is referred to as a service function chain in this document. SF Locator: An SF Node identifier used to reach the said SF node. A locator is typically an IP address or a FQDN. Legacy Node: Refers to any node that is not an SF Node nor an SFC Boundary Node. This node can be located within an SFC-enabled domain or outside an SFC-enabled domain. SF Proxy Node: A Network Element along the data path, to enforce SFC functions on behalf of legacy SF nodes. SFC Boundary Node (or Boundary Node): Denotes a node that connects Zhang, et al Expires September 25, 2014 [Page 4] Internet-Draft Service Chain Header March 24, 2014 one SFC-enabled domain to a node either located in another SFC- enabled domain or in a domain that is SFC-unaware. SFC Egress Node (or Egress Node): Denotes an SFC Boundary Node that handles traffic which leaves the SFC-enabled domain the Egress Node belongs to. SFC Ingress Node (or Ingress Node): Denotes an SFC Boundary Node that handles the traffic entering the SFC-enabled domain the Ingress Node belongs to. SF Node: Denotes any node within an SFC-enabled domain that embeds one or multiple SFs. Service Instance (SI): Denotes an instantiation of a service function on a service node, such as a FW instance. A service function can have multiple service instances running on the same SF node with each service instance having its own service profile. SFC Classifier (or Classifier): An entity that classifies frames or packets for service chaining according to classification rules defined in an SFC Policy Table. Frames/packets are then marked with the corresponding SF Chain Identifier. SFC Classifier can be embedded in an SFC Boundary (Ingress) Node or SF proxy node in which case the Classifier will do the encapsulation after getting the L2/L3 frame/packet from a Legacy SN. The SFC Classifier can also run on an independent (physical or virtual) platform. Metadata: Provides contextual information about the data packets which traverse a service chain. Metadata can be used to convey contextual information not available at one location in the network to another location in the network where that information is not readily available. While primarily intended for consumption by SF(s), metadata MAY also be interpreted by other SFC entities. 4. Service Chain Header 4.1 Header Format The Service Chain Header (SCH) consists of a mandatory fixed length part followed by a number of optional variable length metadata as shown in Figure 1. The mandatory fields carry "SFC path" information, which is used to steer the frames or packets through an ordered set of service function instances along the service function chain. The optional variable length fields carry application/service/content related metadata information which can be used by any SFC entities. The optional fields are formatted as Type-Length-Value structures. If any field in the header is not in use, the value of that field MUST Zhang, et al Expires September 25, 2014 [Page 5] Internet-Draft Service Chain Header March 24, 2014 be set to zero. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver |O|R|R|R|R|Metadata Length| Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Identifier | SF Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optional Metadata TLVs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Service Chain Header 4.2 Mandatory Fields Ver: Represents the Service Chain Header version. This field is 3 bits long, and the current version is 0. O bit: Indicates that this frame/packet is an operations and management (OAM) packet. SF nodes MUST examine the payload and take appropriate action (i.e. return status information). OAM message specifics and handling details are outside the scope of this document. R bits: Reserved bits for future extensions. These bits MUST be set to zero on transmit, and ignored on receive. Metadata length: The total length of all of the optional Metadata TLVs, in 4 octet units. Protocol type: The 2-octet IEEE EtherType of the packet or frame immediately following the entire SCH header [ETYPES]. Path Identifier: Identifies a fully instantiated service function path. It represents a sequence of network locators, one for each service function that is to be invoked. Participating SFC entities MUST use this identifier when selecting the next hop for the packet or frame. The path identifier can also be used for diagnostics and trouble-shooting associated with a service chain. Service Function Index: An index to each service function instance associated with the service path. The service path index can be used to handle loop detection, flow reentry into a previous SF node of the SFC requiring another different service instance treatment, etc. The first service function instance in the path is identified with service index 1. Zhang, et al Expires September 25, 2014 [Page 6] Internet-Draft Service Chain Header March 24, 2014 Zhang, et al Expires September 25, 2014 [Page 7] Internet-Draft Service Chain Header March 24, 2014 4.3 Optional Metadata Fields Optional metadata are added after the fixed part of the SCH. Each option is of variable length and has a minimum length of four octets. An optional 3-octet Organizational Unique Identifier (OUI) may be provided to differentiate multiple private number spaces for the Type field. If the OUI is not provided, the Type is assumed to be a registered globally unique type. Any SFC entities MAY add, modify, or remove metadata TLVs. The Appendix provides some examples of potential metadata TLV types and usage for reference. Figure 2 shows the format of the TLV: 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|R|R|R|R|R|R|R| Type | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | OUI (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: TLV format I bit: I=1 indicates that the optional OUI word (8-bit Reserved and 24-bit OUI) is present in this TLV. I=0 indicates that the the optional OUI word is not present. R bits: Reserved bits for future extensions. These bits MUST be set to zero on transmit and ignored on receive. Type: The type of the TLV, interpreted globally or per the OUI if present. A maximum of 256 types may be expressed within any particular number space. Length: The total length of the TLV in 4-octet units. A maximum length of 1024 octets may be expressed. OUI: The 24-bit Organizational Unique Identifier [IEEE-OUI], present only if the I bit is set. Value: Usage of the the 8-bit value in the first word is purely optional and may be useful for certain types of metadata, allowing registered types to fit into one 32-bit word and OUI-based types Zhang, et al Expires September 25, 2014 [Page 8] Internet-Draft Service Chain Header March 24, 2014 to fit into two 32-bit words. When the 8-bit value is insufficient, additional words for the value are added to the end of the TLV. The existence of optional value words is inferred from the value of the Length field and the value of the I bit. 4.4 Header Associated Operations The Service Chain Header is processed by SFC-aware entities. These entities include but are not limited to the SFC classifiers, SF nodes, SF forwarding nodes, SFC boundary nodes, and SF proxy nodes. The SCH can be used by any SFC entities. Its use between the SFF and SF is optional and in many cases will be implementation dependent. The typical SFF behavior is simplified due to the presence of the metadata length field in the fixed portion of the header. These entities can perform the following operations related to the SCH: 1. Insertion of the Service Chain Header. This occurs at the start of a service chain. An SFC classifier determines which frames/packets are associated with which service chain. The classifier performs this task by matching the incoming frames/packets against certain flow descriptors and assigning them to specific chains. The service classifier MUST then insert appropriate SCH in the frames/packets of a flow that has been assigned to a service chain. 2. Removal of the Service Chain Header. This occurs at the end of the service path. The last Service Network Forwarder (SNF) in the service path MUST remove the SCH from the frames/packets and then forward them to their final destination using its existing transport mechanism. This MUST also be performed by an SF Proxy Node if it is the last forwarding node. 3. Service Path Selection. The Service Network Forwarder (SNF) uses the Service Chain Identification information in the SCH to steer the traffic flow along the SFC path. 4. Service Function Instance Selection. The Service Function Forwarder (SFF) uses the Service Chain Identification information in the SCH to locate the service instance and forward the traffic flow to the service instance. The mapping of the Service Chain Identification to a service instance can be established through the management/control plane, which is out of scope of this document. 5. Service Treatment. The Service Node could use the Service Chain Identification information as well as service metadata in the SCH Zhang, et al Expires September 25, 2014 [Page 9] Internet-Draft Service Chain Header March 24, 2014 to locate the service instance associated with the service chain and apply appropriate service treatment. 5. SCH Encapsulation The SFC classifier adds the SCH to the original frame or packet, and then adds the transport header used to forward the frame/packet through the service chain. The SCH is independent of the underlying transport used. It can be encapsulated inside any transport mechanism. The following examples illustrate how the SCH can be encapsulated in typical transport mechanisms. 5.1 SCH in Overlay GRE Encapsulation The SCH can be encapsulated in a GRE header as follows: +-----------------------------+ | Outer MAC Header | +-----------------------------+ | Outer IP Header (proto=47) | +-----------------------------+ | GRE Header (proto=SCH) | +-----------------------------+ | SCH (proto=GRE Payload Type)| +-----------------------------+ | GRE Payload | +-----------------------------+ Figure 3: SCH Encapsulation in GRE Header Set GRE Protocol = SCH Ethertype SCH inserted between the GRE header and GRE Payload 5.2 SCH in MAC Encapsulation The SCH can be encapsulated in a MAC header as follows: +-----------------------------+ | MAC Header (etype=SCH) | +-----------------------------+ | SCH (proto=MAC Payload Type)| +-----------------------------+ | MAC Payload | Zhang, et al Expires September 25, 2014 [Page 10] Internet-Draft Service Chain Header March 24, 2014 +-----------------------------+ Figure 4: SCH Encapsulation in MAC Header Set MAC Ethertype = SCH Ethertype SCH inserted between the MAC header and MAC Payload 6. Security Considerations Although the SCH can be modified or spoofed by an unauthorized party, various options are available to avoid this. Existing security protocols RFC 6071 [RFC6071] may be used to encrypt the content of a packet that includes the SCH. It should be noted that encryption and decryption of the SCH will impose a performance penalty. Existing security protocols that provide authenticity and authorization (e.g., RFC 2119 [RFC6071]) can be used. If possible, the SCH should be used in a controlled network with trusted devices, for example, a data center or a Gi-LAN network, thus reducing the risk of unauthorized header manipulation. 7. IANA and IEEE Considerations Non-OUI TLV types shall be assigned by IANA. An EtherType assignment for the SCH will be requested from IEEE. 8. References 8.1 Normative References [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC0781] Su, Z., "Specification of the Internet Protocol (IP) timestamp option", RFC 781, May 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC6071] Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", RFC 6071, Zhang, et al Expires September 25, 2014 [Page 11] Internet-Draft Service Chain Header March 24, 2014 February 2011. [ETYPES] The IEEE Registration Authority, "IEEE 802 Numbers", 2012, . [IEEE-OUI] IEEE Standard 802-2001 8.2 Informative References [SFC-ARCH] Quinn, P. et al, Service Function Chaining (SFC) Architecture . [SFC-FWK] Boucadair, M. et al, Service Function Chaining: Framework & Architecture, 2014, . [SFC-META] Rijsman, B. and J. Moisand, Metadata Considerations . [SFC-PS] Quinn, P., Ed. and T. Nadeau, Ed., "Service Function Chaining Problem Statement", 2014, . Zhang, et al Expires September 25, 2014 [Page 12] Internet-Draft Service Chain Header March 24, 2014 9. Appendix The Appendix gives some examples of potential metadata TLV types and usage. It is out of scope of the document to define the list of types and usage. For exemplary purposes only, the formats assume globally registered types (i.e., the OUI word is not present). 9.1 OAM Operation The OAM Operation TLV allows a service function to specify an action to be taken by a downstream service function as a result of its service processing. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|R|R|R|R|R|R|R| Type=1 | Length=1 | Action | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Service actions could include the following: 1 = drop packet 2 = redirect flow 3 = mirror flow 4 = terminate connection 9.2 Service Function Selector The Service Function Identifier TLV allows a service function to select a specific service function to be used on a downstream service node. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|R|R|R|R|R|R|R| Type=2 | Length=2 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Function Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9.3 Target Address The Target Address TLV allows an original destination IP address to be transported across the service chain to the last service function which restores that IP address to the destination IP address of the original packet. Zhang, et al Expires September 25, 2014 [Page 13] Internet-Draft Service Chain Header March 24, 2014 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|R|R|R|R|R|R|R| Type=3 | Length=3 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Function Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9.4 OAM Service Function Trace The OAM Service Function List TLV supports OAM functionality and is used to obtain a list of service functions that have been traversed by the packet. Each service function adds its service function identifier to this list if the OAM Operation TLV indicates an SF Identifier. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|R|R|R|R|R|R|R| Type=4 | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Function Identifiers | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authors' Addresses Hong (Cathy) Zhang Huawei US R&D EMail: cathy.h.zhang@huawei.com Louis Fourie Huawei US R&D EMail: louis.fourie@huawei.com Ron Parker Affirmed Networks EMail: ron_parker@affirmednetworks.com Zhang, et al Expires September 25, 2014 [Page 14] Internet-Draft Service Chain Header March 24, 2014 Myo Zarny Goldman Sachs EMail: myo.zarny@gs.com Zhang, et al Expires September 25, 2014 [Page 15]