Service Function Chaining: Design
Considerations, Analysis & RecommendationsFrance TelecomRennes35000Francemohamed.boucadair@orange.comAffirmed NetworksActon,MAUSARon_Parker@affirmednetworks.comThe objectives of this document are to analyze the various design
options, and provide a set of recommendations to be followed during the
design phase of the Service Function Chaining solution(s). Note:The analysis does not claim to be exhaustive. The list includes a
preliminary set of potential solutions; other proposals can be added
to the analysis if required.The analysis is still ongoing. The analysis text will be updated
to integrate received comments and inputs.Sketched recommendations are not frozen. These recommendations
are provided as proposals to kick-off the discussion and to
challenge them.The analysis does not cover any application-specific solution
(e.g., HTTP header) because of the potential issues inherent to
(TLS) encrypted traffic.The analysis will be updated to take into account the full set of
SFC requirements.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.The objectives of this document are to analyze the various design
options, and (hopefully) provide a set of recommendations to be followed
by individual specification document(s). The conclusions of this
analysis, once stable, will be recorded in the framework document.The overall problem space is described in . A list of requirements
is available at .The reader should be familiar with the terms defined in .This document identifies potential solutions to fulfill the design
requirements documented in . Particularly, it
focuses on the following design objectives:Which information to include in the SFC header? (see )How to mark packets to indicate they belong to a given Service
Function Chain (SFC) (see ) and in
which channel the SFC header is to be conveyed (see )?How to select a differentiated set of policies at a given Service
Function (SF)? (see )How to select the forwarding path of a given flow that needs to
be processed according to a set of Service Functions which must be
invoked in a given order? (see )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.Injecting (or leaking a Subscriber Identifier (subscriber-ID)) in
the Service Function Chaining Header is not motivated by current
deployment practices which consider that per-subscriber policies are
enforced in few nodes (especially in the access network segment). As
such, the service chaining solution does not require per-subscriber
policies to be supported by all involved (SF) nodes. Moreover, the
enforcement of some policies can be driven by a subset of the
information contained in the packets (e.g., source IP address, IPv6
prefix, etc.). Conveying the SF Map Index is sufficient to guide a
Service Function to select the set of policies to be enforced for a
given packet that belongs to a flow .Note, current deployments may require an explicit subscriber-ID
only during the authentication and authorization phases. These
deployments do not require explicit subscriber-ID information to be
conveyed when sending actual data traffic.The Service Chaining approach does not aim to change how
authorization and per-subscriber policies are enforced. As a
consequence, explicit Subscriber-ID is not required to be included in
the Service Chaining Header. The SF Map Index is sufficient to
identify the set of policies to be applied in case differentiated
polices are supported by a given Service Function. If needed,
per-subscriber considerations can be taken into account during the
design of the Service Function Chaining logics.The number of Service Chains to be instantiated is
deployment-specific. It depends on the business context and
engineering practices internal to each administrative entity. To
ensure a better flexibility as a function of the service chains that
are theoretically supported, a first design point is to decide whether
a fixed field or a variable length field is to be adopted.A field with a variable length is flexible enough to accommodate as
many Service 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 owing to 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 ). A 32-bit field
would fulfill the needs for deployments with very large Service
Function Chains.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 flavors of the header.Implementations supporting the service chaining solution can be
upgraded following current best practices in the field.This section proposes and discusses some formats to encode the
Service Chaining Header. An analysis is also included in this section.
[NOTE: Other proposals (if any) will be added to this
section.]The RBNF format of the header is
shown in :This format is characterized as follows:A policy table is provisioned to each SF Node. This policy
table includes the locator(s) of the possible SF next hop and the
SF Map Index list to help detect any Service Function Loop.Classifiers are provisioned with classification rules to decide
which code point is to be used for a received packet.Fragmentation risk is minimized because the header is
compacted.Multiple profiles can be supported per SF Node; each profile is
identified with a Service Function Identifier.The classifier behavior is simplified.Separating the policies channel from the marking behavior
prevents potential DDoS (e.g., common to any source routing
scheme.)The lookup in the SFC Policy Table is not a concern because it
is not expected to provision SFC Policy Tables with an amount of
information (e.g., like the size of the global routing table).The RBNF format of the header is shown in :This format is characterized as follows:The list of SF Locator(s) is provisioned out of band to each SF
Node.Classifiers are provisioned with classification rules to decide
which code point is to be used for a received packet.Fragmentation risks are not minimized.The classifier needs to be configured with a list of
profiles/contexts per Service Function.The classifier behavior is not simplified since it must also
encode in each incoming packet the full list of functions to be
performed by each Service Function hop.The RBNF format of the header is shown in :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
is to be propagated 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:Classifiers are provisioned with classification rules to decide
which code point is to be used for a received packet.Fragmentation risks are not minimized.The classifier needs to be configured with a list of
profiles/contexts per Service Function.The classifier is also responsible for load-balancing. This
makes the classifier more complex.The classifier behavior is not simplified since it must also
encode in each incoming packet the full list of policies to be
performed by each Service Function node.A variant of the previous format is depicted in the RBNF format of
the header shown in . Instead of including
the explicit route list (), 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 downsides as the previous
format.Given the design motto that says: "A protocol design is complete not when you can't think of any
more things to add, but when you have removed everything you can
and you can’t see how to remove any more", the proposed format must be as simple as possible while meeting the
requirements discussed in . The simplicity
argument is further discussed in and
.Based on the analysis detailed above, 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 .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 can be considered as a candidate solution to
convey the SF Map Index.The following comments can be made for this candidate
solution:This proposal requires all packets are transported over IPv6.
This should not be considered as a limitation for some
deployments.Intermediate Nodes must not alter the content of the Flow Label
field.This proposal can apply to any transport protocol.The use of the IPv6 Flow Label may interfere with other usages
of the flow label such as Equal Cost Multipath (ECMP) or Link
Aggregation (LAG) . The Flow Label
bits need to be combined at least with bits from other sources
within the packet, so as to produce a constant hash value for each
flow and a suitable distribution of hash values across flows .A 20-bit field to convey the SF Map Index allows to enable
Service Function Chains of a large size range.This proposal does not allow to convey additional information
than the SF Map Index (if needed).The Flow Label is present in all fragments, SF Nodes do not
need to maintain any state to handle a fragmented packet.Altering the value of the Flow Label field does not interfere
with the use of IPsec .Carrying the SF Map Index in the IPv6 Flow Label allows
to:De-correlate packet marking from forwarding
constraints.Avoid requiring an internal tagging mechanism to each SF
Node to preserve the same marking in the outgoing interface as
the one received in an incoming interface.Another alternative to convey the SF Map Index is to use the
Differentiated Services (DS) field (for both IPv4 and IPv6).The following comments can be made for this proposal:This proposal overloads the semantics of the DS field.Having 64 possible values may not accommodate deployments with
a large number of service chains (see ).This proposal can apply to any transport protocol.The use of the DS field for service chaining purposes may
interfere with other usages such as Traffic Engineering (TE) or
Quality of Service (QoS).This issue can be mitigated by fragmenting the DS space
into to distinct set of values; each set dedicated for a
specific usage. An administrative entity can use the first
bits for service chaining and other remaining bits for QoS for
instance.Splitting the DS space reduces the number of possible
service chains to be configured per administrative
domain.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 ; in particular,
the same SF Map Index is not reassigned during a given time interval.
Note:This usage is not consistent with the fragment reassembly use
of the Identification field or the
updated handling rules for the Identification field .Complications may arise if the packet is fragmented before
reaching the Classifier. To appropriately handle those packet
fragments, the classifier will need to maintain a lot of
state.Preserving the same value when crossing all intermediate SFs
may be difficult (e.g., an invoked SF can be a NAT).This proposal assumes packets are transported over IPv4 (plain
or encapsulated mode). This may not be considered as a limitation
for some deployments.Another candidate channel to convey the Service Chaining Header is
to use the IPv4 SSRR/LSRR option . This
IP option can be inserted by the classifier following the
pre-configured classification rules. Note:Some general recommendations documented in and are to be taken into account.This proposal assumes packets are transported over IPv4 (plain
or encapsulated mode). This may not be considered as a limitation
for some deployments.This proposal can apply to any transport protocol.Encoding the full list of intermediate SF nodes will exacerbate
fragmentation issues.Injecting an additional IP option by the classifier introduces
some implementation complexity in the following cases: The packet
is at or close to the MTU size, and the option space is
exhausted.Legacy nodes must be configured to not strip this option.Processing the IP option may degrade the performance of
involved SF nodes.Another candidate solution to convey the Service Chaining Header is
to define a new IPv4 option and a new
IPv6 extension header . The IPv4
option/IPv6 extension header can be inserted by the classifier
following the pre-configured classification rules. Note:This proposal is valid for any transport protocol.This proposal offers the same functionality in both IPv4 and
IPv6.Some general recommendations documented at , , and are to be taken into
account. Nevertheless, these security threats do not apply for
this usage since the Ingress Node is the entity that is
responsible for injecting the new option. Therefore, malicious
usage of this option is unlikely.Injecting an additional IP option by the classifier introduces
some implementation complexity in the following cases: The packet
is at or close to the MTU size, and the option space is
exhausted.The option can be designed to be compact and therefore avoid
inducing fragmentation.Despite it is widely known that routers and middleboxes filter
IP options (e.g., drop IP packets with unknown IP options, strip
unknown IP options, etc.), this concern does not apply for the
Service Function Chaining case because the support of new IP
options can be enabled within a domain operated by the same
administrative domain.Intermediary Nodes must not strip this IPv4 option/IPv6
extension header.The use of an IPv4 option or IPv6 Extension Header to drive the
processing of an incoming packet may alter the performance of SF
Nodes.Some vendors claim the use of Extension Headers (other than
Hop-by-Hop) does not impact the overall performance of their
IPv6 implementation (e.g., ).Some studies revealed an increase of the single-hop delay
when IP options are included (e.g., ).The severity of the overall performance degradation is to
be further assessed ().Carrying the Service Chaining Header as an IPv4 option/IPv6
extension header allows to:De-correlate packet marking from forwarding
constraints.Avoid requiring an internal tagging mechanism to each SF
Node to preserve the same marking in the outgoing interface as
the one received through the incoming interface.This proposal consists in defining a new TCP option to convey the
Service Chaining Header. The drawbacks of this proposal are listed
below:Encapsulating every received packet in TCP SYN messages may
impact the performance of SF nodes.Injecting a TCP option by intermediate nodes will interfere
with end-to-end (E2E) issues. One example of such interference
would be terminating and re-originating TCP connections not
belonging to the transit device.Injecting this TCP option introduces some implementation
complexity if the options space is exhausted. TCP option space is
limited and might be consumed by the TCP client.SF Nodes may need to maintain a lot of state entries to handle
fragments. defines key and security extensions
to GRE (Generic Routing Encapsulation, ). 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.GRE Checksum and Sequence Number fields are not required. These
fields must not be included.Relying on GRE optional field to drive the processing of
received packets may impact the performance of SF Nodes.This proposal does not allow to convey additional information
than the SF Map Index (if needed).In cases where GRE would already have been used, it is
preferable to rely on this scheme and avoid yet another
encapsulation overhead.An SF Node must rely on an internal tagging procedure to
preserve the same header be positioned at the outgoing interface
of an SF node.Further experiments may be required to compare the performance
that would result in activating this solution vs. the performance
observed when an IPv4 option or IPv6 extension header is used
jointly with IP-in-IP encapsulation .This proposal is compliant with . It
consists in adding a fixed header as shown in :The following comments can be made:This proposal covers both IPv4 and IPv6 deployment cases.An SF Node must rely on an internal tagging procedure to
preserve the same header be positioned at the outgoing interface
of an SF node.This header can be extended easily to accommodate new
requirements.Because the SFC Header is part of the mandatory header, the
performance are likely to not be severely impacted compared to
other tunneling modes such as the joint use of IP-in-IP and an
IPv4 option/IPv6 extension header.For interoperability reasons, one encapsulation mode MUST be
defined. Refer to for more discussion
on the design principles.Given the requirements identified in , IP-based
encapsulation schemes should be considered. From this standpoint, the
following encapsulation candidate solutions are identified so
far:Simple IP-in-IP & a SFC header in the inner packet (e.g.,
IPv4 option, IPv6 extension header)IP-in-IP with a fixed SFC header ().GRE & GRE Key as a channel to convey the SF Map Index
()The following table summarizes the main characteristics for each
mode:ModeSimple IP-in-IP & a SFC header in the
inner packetIP-in-IP with a fixed SFC headerGRE & GRE KeyEncapsulation overhead when the next hop SF is in the same
subnetNoYesYesA proprietary internal tagging mechanism is requiredNoYesYesNatural extensibilityYesYesNoRisk to strip the header by intermediate nodesYesNoNoPossible Impact on PerformanceMed to HighLow to MedMedThe following comments can be made:Both "IP-in-IP with a fixed SFC header" and "GRE & GRE Key"
present almost the same characteristics except "IP-in-IP with a
fixed SFC header" can be easily extended. Note, "GRE & GRE
Key" can also be extended with new optional fields but this may
induce some performance degradation."Simple IP-in-IP & a SFC header in the inner packet" is
more flexible:It allows to convey the SFC header separately from the
encapsulation header.It allows to avoid encapsulation overhead when adjacent SFs
in a SFC sequence are in the same subnet.No internal tagging is needed within a SF Node.The SFC header can be extended in the future (if
needed).Indicated values for "Possible Impact on Performance" are
hypothetical. These values are inspired from some experiments such
as . Ideally, further testings should
be conducted to better qualify the impact on performance of these
proposals under the same configuration and setup. Proposed Recommendations(1) Adopt the IP-in-IP with a fixed SFC header solution (). 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., ).(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:**** TO BE COMPLETED ONCE THE ANALYSIS IS STABLE ****Authors of this document do not require any action from IANA.Security considerations related to Service Function Chaining are
discussed in .Many Thanks for C. Jacquenet for his review.IPv6 Extension Headers Review and ConsiderationsCiscoMeasurement and Analysis of Single-Hop Delay on an IP
Backbone NetworkRobustness and the Internet: Design and evolution