| SFC | M. Boucadair |
| Internet-Draft | C. Jacquenet |
| Intended status: Informational | France Telecom |
| Expires: August 16, 2014 | R. Parker |
| Affirmed Networks | |
| L. Dunbar | |
| Huawei Technologies | |
| February 12, 2014 |
Service Function Chaining: Design Considerations, Analysis & Recommendations
draft-boucadair-sfc-design-analysis-02
This document aims at analyzing the various design options and providing a set of recommendations for the design of Service Function Chaining solution(s). Note:
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].
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 August 16, 2014.
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 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.
This document aims at analyzing the various design options and providing a set of recommendations for the design of Service Function Chaining solution(s). The conclusions of this analysis, once stable, will be recorded in the framework document.
The overall problem space is described in [I-D.ietf-sfc-problem-statement]. A list of requirements is available at [I-D.boucadair-sfc-requirements].
The reader should be familiar with the terms defined in [I-D.boucadair-sfc-framework].
This document identifies potential solutions to fulfill the design requirements documented in [I-D.boucadair-sfc-requirements]. Particularly, it focuses on the following design objectives:
Other design issues will be documented in future versions if required.
This section identifies the main design points to be agreed upon so as to guide the forthcoming specification effort of the Service Function Chaining Header.
Current deployment practices rely on per-subscriber policies enforcement on few service nodes (especially in the access network segment). If the same design approach is preserved when SFC is in use, per-subscriber policies are likely to not be supported by all involved (SF) nodes.
Conveying the SF Map Index, that is an unique value to represent different service chains, is sufficient to guide specific sequence of Service Functions for a given packet that belongs to a flow. Some of involved Service Functions may enforce a per-subscriber policy. The enforcement of such policies can be driven by a subset of the information contained in the packets (e.g., source IP address, IPv6 prefix, etc.).
In some deployment contexts implying a correlation between the assigned IP address and a subscriber identifier, complications may arise in the following cases:
Enforcing for instance per-subscriber port quota requires an additional information to uniquely disambiguate hosts having the same address (called HOST_ID, [RFC6967]). This problem is not specific to the Service Function Chaining, but it is encountered in many other use cases ([I-D.boucadair-intarea-host-identifier-scenarios]).
Within the context of SFC, two solutions can be adopted:
+-------------------------------------------------------------------+ | Proposed Recommendation | +-------------------------------------------------------------------+ | It is NOT RECOMMENDED to encode a subscriber-ID | | as a mandatory field of the SFC header. | +-------------------------------------------------------------------+
The number of Service Chains to be instantiated is deployment-specific. It depends on the business context and engineering practices that are internal to each administrative entity. To ensure a better flexibility as a function of the service chains that are theoretically supported, a first design consideration is to decide whether there is a need for a fixed field or a variable length field.
A field with a variable length is flexible enough to accommodate as many Service Function Chains as required for each deployment context. An administrative entity will need to tweak the length of this field to meet its own deployment requirements (e.g., set the length in all involved nodes to 8 bits, 16 bits, 32 bits or even more).
A field with a fixed length would lead to a better performance (mainly because of a simplified processing).
An 8-bit field would be sufficient to accommodate deployment contexts that assume a reasonable set of SF Maps. A 16-bit field would be more flexible and would allow to enable large service chains (e.g., to accommodate the requirement discussed in [I-D.boucadair-sfc-requirements]). A 32-bit field would fulfill the needs for deployments with very large Service Function Chains.
+-------------------------------------------------------------------+ | Proposed Recommendation | +-------------------------------------------------------------------+ | It is RECOMMENDED to use a 32-bit field to encode | | the SF Map Index | +-------------------------------------------------------------------+
The header can be extended in the future, based on the experience that will be gained during operational deployments. As such, the header does not need to include any protocol version field nor any reserved bits to disambiguate between two variants of the header.
Implementations supporting the service chaining solution can be upgraded following current best practices in the field.
+-------------------------------------------------------------------+ | Proposed Recommendation | +-------------------------------------------------------------------+ | It is NOT RECOMMENDED to reserve bits to anticipate future | | extension needs. Backward compatibility between two versions of | | the header can be ensured by consistent system | | setup & configuration. | +-------------------------------------------------------------------+
This section proposes and discusses some formats to encode the Service Chaining Header. An analysis is also included in this section.
The RBNF format [RFC5511] of the header is shown in Figure 1:
<SFC Header> ::= <SF Map Index>
Figure 1: Single Marking Code Point
This format is characterized as follows:
The RBNF format of the header is shown in Figure 2:
<SFC Header> ::= <SF Map Index>
<Service Function Map>
<Service Function Map> ::= <Service Function> ...
<Service Function> ::= <Service Function Identifier>
<Profile Identifier>
Figure 2: Marking Code Point & Profile Index
The RBNF format of the header is shown in Figure 3:
<SFC Header> ::= <Total number of Service Function hops>
<Current hop Index>
<Service Function Map>
<Service Function Map> ::= <Service Function> ...
<Service Function> ::= <IP ADDRESS>
<Profile Identifier>
Figure 3: Explicit Route List
The procedure at a non-reclassifying node is to validate that the IP address of the SF at the current index matches one of the SF's own IP addresses and then to find the profile identifier by its indicated identifier. Once the local Service Function is invoked, if the packet needs to be forwarded to the next Service Function hop, the local node simply increments the current hop index and rewrites the outer IP header with the next hop's IP address.
This format is characterized as follows:
<SFC Header> ::= <Total number of Service Function hops>
<Current hop Index>
<Service Function List>
<Service Function List> ::= <Service Function> ...
<Service Function> ::= <IP Address ID>
<Profile Identifier>
Figure 4: Compact Explicit Route List
A variant of the previous format is depicted in the RBNF format of the header shown in Figure 4. Instead of including the explicit route list (Figure 3), IP addresses of SFs are configured out of band but each of these addresses is identified with a unique identifier. These identifiers are indicated in the Service Chaining Header.
This proposal suffers from the same drawbacks as the previous format.
Given the design motto that says:
the proposed format must be as simple as possible while meeting the requirements discussed in [I-D.boucadair-sfc-requirements]. The simplicity argument is further discussed in [RFC3439] and [Robust].
Based on the above analysis, the proposal that is simple, minimizes fragmentation, optimizes the behavior of the classifier and SF Nodes, and that prevents potential DDoS attacks is the one discussed in Section 5.1.
This section lists a set of candidate solutions to convey the Service Chaining Header.
The use of the 20-bit Flow Label field in the IPv6 header [RFC6437] can be considered as a candidate solution to convey the SF Map Index.
The following comments can be made for this candidate solution:
+-------------------------------------------------------------------+ | Proposed Recommendation | +-------------------------------------------------------------------+ | It is tempting to use the Flow Label, but the 20-bit length of | | the Flow Label field is conflicting with the recommended 32-bit | | length discussed in Section 4.3. | | | | The use of Flow Label is NOT RECOMMENDED. | +-------------------------------------------------------------------+
Another alternative to convey the SF Map Index is to use the Differentiated Services (DS) field [RFC2474] [RFC2475] (for both IPv4 and IPv6).
The following comments can be made for this proposal:
+-------------------------------------------------------------------+ | Proposed Recommendation | +-------------------------------------------------------------------+ | The use of DS field is NOT RECOMMENDED. | +-------------------------------------------------------------------+
The IPv4 ID (Identification field of IP header, i.e., IP-ID) can be used to insert the SF Map Index. The classifier rewrites the IP-ID field to insert the SF Map Index (16 bits). The classifier must follow the rules defined in [RFC6864]; in particular, the same SF Map Index is not reassigned during a given time interval. Note:
+-------------------------------------------------------------------+ | Proposed Recommendation | +-------------------------------------------------------------------+ | Using the IP-ID as a channel to convey the SF Map Index is NOT | | RECOMMENDED. | +-------------------------------------------------------------------+
Another candidate channel to convey the Service Chaining Header is to use the IPv4 SSRR/LSRR options [RFC0791]. These options can be inserted by the classifier following the pre-configured classification rules. Note:
+-------------------------------------------------------------------+ | Proposed Recommendation | +-------------------------------------------------------------------+ | Using the IPv4 SSRR/LSRR options as a channel to convey | | the Service Chaining Header is NOT RECOMMENDED. | +-------------------------------------------------------------------+
+-------------------------------------------------------------------+ | Proposed Recommendation | +-------------------------------------------------------------------+ | Define a new IPv4 option and IPv6 extension header | | as an Experimental track RFC document. This approach is pragmatic,| | assuming further experiments can be conducted to: | | | | 1. Assess the impact on performance. | | | | 2. Compare the impact of using the IPv4 option and the IPv6 | | extension header vs. an encapsulation mode (i.e., in contexts | | where no encapsulation is required to reach the next SF hop). | | | | 3. Assess to what extent the use of an IPv4 option/IPv6 extension | | header simplify internal tagging mechanisms specific to each SF| +-------------------------------------------------------------------+
Another candidate solution to convey the Service Chaining Header is to define a new IPv4 option [RFC0791] and a new IPv6 extension header [RFC6564]. The IPv4 option/IPv6 extension header can be inserted by the classifier following the pre-configured classification rules. Note:
This proposal consists in defining a new TCP option to convey the Service Chaining Header. The drawbacks of this proposal are listed below:
+-------------------------------------------------------------------+ | Proposed Recommendation | +-------------------------------------------------------------------+ | Defining a new TCP option as a channel to convey the Service | | Chaining Header is NOT RECOMMENDED. | +-------------------------------------------------------------------+
[RFC2890] defines key and security extensions to GRE (Generic Routing Encapsulation, [RFC2784]). GRE Key and sequence number fields are optional. This section investigates how a GRE Key optional field can be used to convey a 32-bit SF Map Index.
+-------------------------------------------------------------------+ | Proposed Recommendation | +-------------------------------------------------------------------+ | To be completed | +-------------------------------------------------------------------+
This proposal is compliant with [RFC1853]. It consists in adding a fixed header as shown in Figure 5:
+---------------------------+
| Outer IP Header |
+---------------------------+
| SFC Header |
+---------------------------+ +---------------------------+
| IP Header | | Inner IP Header |
+---------------------------+ ====> +---------------------------+
| | | |
| IP Payload | | IP Payload |
| | | |
+---------------------------+ +---------------------------+
Figure 5
+-------------------------------------------------------------------+ | Proposed Recommendation | +-------------------------------------------------------------------+ | To be completed | +-------------------------------------------------------------------+
The SFC Classifier capability introduced in [I-D.boucadair-sfc-framework] can be for instance supported by a GGSN node of a mobile network that also embeds the PCEF (Policy Charging Enforcement Function) function. A generic description of the related Gi Interface use case is discussed in [I-D.liu-sfc-use-cases].
This candidate solution assumes the following:
This proposal is a particular case of the "Router-based mechanism" defined in Section 10.2 of [I-D.boucadair-sfc-framework].
The following comments can be made for this candidate solution:
+-------------------------------------------------------------------+ | Proposed Recommendation | +-------------------------------------------------------------------+ | The MAC-based SFC forwarding is designed for specific topologies | | and assumes strong requirements on the SFC Classifier Node. | | | | The use of MAC-based SFC forwarding is NOT RECOMMENDED as a | | generic SFC mechanism that would remove dependency on the | | underlying physical topology. | +-------------------------------------------------------------------+
For interoperability reasons, one encapsulation mode MUST be defined. Refer to [RFC3439] for more discussion on the design principles.
Given the requirements identified in [I-D.boucadair-sfc-requirements], IP-based encapsulation schemes should be considered. From this standpoint, the following encapsulation candidate solutions are identified so far:
The following table summarizes the main characteristics for each mode:
| Mode | Simple IP-in-IP & a SFC header in the inner packet | IP-in-IP with a fixed SFC header | GRE & GRE Key |
|---|---|---|---|
| Encapsulation overhead when the next hop SF is in the same subnet | No | Yes | Yes |
| A proprietary internal tagging mechanism is required | No | Yes | Yes |
| Natural extensibility | Yes | Yes | No |
| Risk to strip the header by intermediate nodes | Yes | No | No |
| Possible Impact on Performance | Med to High | Low to Med | Med |
The following comments can be made:
| Proposed Recommendations |
|---|
| (1) Adopt the IP-in-IP with a fixed SFC header solution (Section 6.8). This mode is to be used as the MANDATORY encapsulation scheme for service chaining purposes. The main selection criteria for this proposed recommendation is to minimize performance impacts on involved nodes. |
| (2) To accommodate deployment cases where encapsulation is not required, allow to rely exclusively on a dedicated tagging field in the inner packet. This extension is to be defined in the EXPERIMENTAL track (e.g., Section 6.5). |
| (3) Experimental specifications can be obsoleted or promoted to be in the Standard Tracks based on the conclusions from significant experiments. |
As a consequence of the above analysis, the following recommendations are made:
Authors of this document do not require any action from IANA.
Security considerations related to Service Function Chaining are discussed in [I-D.boucadair-sfc-framework].
Thanks to J. Halpern and P.Chuong for the coments on the subscriber-ID.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC5511] | Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009. |
| [RFC0791] | Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. |