One document matched: draft-boucadair-sfc-framework-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>
<rfc category="std" docName="draft-boucadair-sfc-framework-02"
ipr="trust200902" updates="">
<front>
<title abbrev="SFC Framework & Architecture">Service Function
Chaining: Framework & Architecture</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>christian.jacquenet@orange.com</email>
</address>
</author>
<author fullname="Ron Parker" initials="R." surname="Parker">
<organization>Affirmed Networks</organization>
<address>
<postal>
<street></street>
<city>Acton,</city>
<region></region>
<code>MA</code>
<country>USA</country>
</postal>
<email>Ron_Parker@affirmednetworks.com</email>
</address>
</author>
<author fullname="Diego R. Lopez" initials="D. R." surname="Lopez">
<organization>Telefonica I+D</organization>
<address>
<postal>
<street>Don Ramon de la Cruz, 82</street>
<!-- Reorder these if your country does things differently -->
<city>Madrid</city>
<region></region>
<code>28006</code>
<country>Spain</country>
</postal>
<phone>+34 913 129 041</phone>
<email>diego@tid.es</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Jim Guichard" initials="J." surname="Guichard">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street></street>
<city></city>
<country>USA</country>
</postal>
<email>jguichar@cisco.com</email>
</address>
</author>
<author fullname="Carlos Pignataro " initials="C." surname="Pignataro">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street></street>
<country>USA</country>
</postal>
<email>cpignata@cisco.com</email>
</address>
</author>
<date day="12" month="February" year="2014" />
<workgroup>SFC</workgroup>
<keyword>overlay, flexibility, adaptability, elasticity</keyword>
<abstract>
<t>IP networks rely more and more on the combination of advanced
functions (besides the basic routing and forwarding functions) for the
delivery of added value services. This document defines a reference
architecture and a framework to enforce Service Function Chaining (SFC)
with minimum requirements on the physical topology of the network.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t></t>
<section title="On the Proliferation of Service Functions">
<t>IP networks rely more and more on the combination of advanced
functions (besides the basic routing and forwarding functions) for the
delivery of added value services. Typical examples of such functions
include firewall (e.g., <xref target="RFC6092"></xref>), DPI (Deep
Packet Inspection), LI (Lawful Intercept) module, NAT44 <xref
target="RFC3022"></xref>, NAT64 <xref target="RFC6146"></xref>,
DS-Lite AFTR <xref target="RFC6333"></xref>, NPTv6 <xref
target="RFC6296"></xref>, HOST_ID injection, HTTP Header Enrichment
function, TCP tweaking and optimization function, transparent caching,
charging function, load-balancer, etc.</t>
<t>Such advanced functions are denoted SF (Service Function) in this
document.</t>
<t>The dynamic enforcement of a SF-derived, adequate forwarding policy
for packets entering a network that supports such advanced Service
Functions has become a key challenge for operators and service
providers. SF-inferred differentiated forwarding is ensured by
tweaking the set of Service Functions to be invoked. How to bind a
flow of packets that share at least one common characteristic to a
forwarding plane is policy-based, and subject to the set of SF
functions that need to be solicited for the processing of this
specific flow.</t>
<t>Service Providers need to rationalize their service delivery logics
and master its underlying complexity.</t>
<t>The overall problem space is described in <xref
target="I-D.ietf-sfc-problem-statement"></xref>. A companion document
that lists a set of requirements is available at <xref
target="I-D.boucadair-sfc-requirements"></xref>.</t>
</section>
<section title="Scope">
<t>This document defines a framework to enforce Service Function
Chaining (SFC) with minimum requirements on the physical topology of
the network. The proposed solution allows for differentiated
forwarding: packets are initially classified at the entry point of an
SFC-enabled network, and are then forwarded according to the ordered
set of SF functions that need to be activated to process these packets
in the SFC-enabled domain.</t>
<t>This document does not make any assumption on the deployment
context. The proposed framework covers both fixed and mobile networks
(e.g., to rationalize the proliferation of advanced features at the Gi
Interface <xref target="RFC6459"></xref>).</t>
<t>Considerations related to the chaining of Service Functions that
span domains owned by multiple administrative entities is out of
scope. Note, a single administrative entity may manage multiple
domains.</t>
</section>
<section title="Objectives">
<t>The main objectives of the proposed framework are listed
below:<?rfc subcompact="yes" ?><list style="symbols">
<t>Create service-inferred forwarding planes.</t>
<t>Efficiently master the chained activation of Service functions,
regardless of the network topology and routing policies.</t>
<t>Allow packets to be forwarded to the required Service Functions
without changing the network topology or overlay transports
necessary for packet delivery to/from Service Functions.</t>
<t>Allow for differentiated packet forwarding by selecting the set
of Service functions to be invoked.</t>
<t>Allow to easily change the sequentiality of the activation of
Service functions to be invoked.</t>
<t>Allow to easily change the set of Service functions to be
invoked.</t>
<t>Ease management (including withdrawal) of Service functions and
minimize any subsequent topology update.</t>
<t>Automate the overall process of generating and enforcing
policies to accommodate a set of network connectivity service
objectives.<?rfc subcompact="no" ?></t>
</list></t>
</section>
<section anchor="assumptions" title="Assumptions">
<t>The following assumptions are made:<?rfc subcompact="yes" ?><list
style="symbols">
<t>Not all SFs can be characterized with a standard definition in
terms of technical description, detailed specification,
configuration, etc.</t>
<t>There is no global nor standard list of SFs enabled in a given
administrative domain. The set of SFs varies as a function of the
service to be provided and according to the networking
environment.</t>
<t>There is no global nor standard SF chaining logic. The ordered
set of SFs that need to be activated to deliver a given
connectivity service is specific to each administrative
entity.</t>
<t>The chaining of SFs and the criteria to invoke some of them are
specific to each administrative entity that operates the
SF-enabled network (also called administrative domain).</t>
<t>SF chaining logic and related policies should not be exposed
outside a given administrative domain.</t>
<t>Several SF chaining logics can be simultaneously enforced
within an administrative domain to meet various business
requirements.</t>
<t>No assumption is made on how FIBs and RIBs of involved nodes
are populated.</t>
<t>How to bind the traffic to a given SF chaining is
policy-based.<?rfc subcompact="no" ?></t>
</list></t>
</section>
<section title="Rationale">
<t>Given the assumptions listed in <xref target="assumptions"></xref>,
the rationale of the framework is as follows:<?rfc subcompact="yes" ?><list
style="symbols">
<t>The framework separates the dynamic provisioning of required SF
functions from packet handling operations (e.g., forwarding
decisions).</t>
<t>The technical characterization of each SF is not required to
design the SFC architecture and SFC operations.</t>
<t>No IANA registry is required to store the list of SFs. In
particular, assignment of identifiers, header fields, or any other
indication of the Service Function Chain, are all strictly local
in scope. An identifier assigned in one administrative domain will
not indicate the same set of SFs in another administrative
domain.</t>
<t>No IANA registry is required to store the SF chaining
candidates. The set of SFCs are local to each administrative
domain, and are as such not global.</t>
<t>No specific SF chaining is assumed. The description of SF
chains is an information that will be processed by the nodes that
participate to the delivery of a network service. The set of
listed/chained SF functions is generated by each administrative
entity operating the network.</t>
<t>SF handling is policy-based: SF chains can be updated or
deleted, new SFs can be added without any impact on existing SFs,
etc. In particular, this design is compliant with the global
framework discussed in <xref
target="I-D.sin-sdnrg-sdn-approach"></xref>.</t>
<t>For the sake of efficiency, policy enforcement is automated
(but policies can be statically enforced, for example).</t>
<t>To minimize fragmentation, a minimal set of information needs
to be signaled (possibly in data packets).</t>
<t>Advanced features (e.g., load balancing) are also described and
may be configured according to policies that can be
service-specific. Policy decisions are made by a Policy Decision
Point <xref target="RFC2753"></xref> and the solicited enforcement
points are responsible for applying these decisions, whatever the
objective to achieve.</t>
<t>SFs can be embedded in nodes that intervene in the transport
service or supported by dedicated nodes (e.g., dedicated servers).
The decision to implement one of these two models (or a
combination thereof) is deployment-specific and it is orthogonal
to the overall procedure.</t>
<t>Multiple SFC-enabled domains can be deployed within the same
administrative domain. Nodes are provisioned with the policy table
of the SFC-enabled domain they belong to.</t>
<t>The overall consistency of the differentiated forwarding policy
is ensured by the PDP.</t>
<t>The PDP can be responsible to enforce other policies than those
described in the SFC Policy Tables. <?rfc subcompact="no" ?></t>
</list></t>
</section>
</section>
<section title="Terminology">
<t>This document makes use of the following terms:<?rfc subcompact="no" ?><list
style="symbols">
<t>SF (Service Function): refers to a function which is enabled in
the network operated by an administrative entity. One or many
Service Functions can be involved in the delivery of added-value
services. A non-exhaustive list of Service Functions include:
firewall (e.g., <xref target="RFC6092"></xref>), DPI (Deep Packet
Inspection), LI (Lawful Intercept) module, NAT44 <xref
target="RFC3022"></xref>, NAT64 <xref target="RFC6146"></xref>,
DS-Lite AFTR <xref target="RFC6333"></xref>, NPTv6 <xref
target="RFC6296"></xref>, HOST_ID injection, HTTP Header Enrichment
function, TCP optimizer, load-balancer, etc. This document does not
make any assumption in the OSI Layer on which the Service Function
acts on; the exact definition of each Service Function is
deployment-specific.</t>
<t>SFC-enabled domain: denotes a network (or a region thereof) that
implements SFC.</t>
<t>SF Identifier: is a unique identifier that unambiguously
identifies a SF within a 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; other formats can be used. SF Identifiers are not required
to be globally unique nor be exposed to or used by another
SF-enabled domain.</t>
<t>SF Map: refers to an ordered list of SF identifiers. Each SF Map
is identified with a unique identifier called SF Map Index.</t>
<t>SFC Policy Table: is a table containing a list of SF Maps, SFC
classification rules and Locators for all SF Nodes. A SFC Policy
Table may contain a default SF Map.</t>
<t>SF Locator: A SF Node identifier used to reach the said SF node.
A locator is typically an IP address or a FQDN.</t>
<t>Legacy Node (Node for short): refers to any node that is not a SF
Node nor a SFC Boundary Node. This node can be located within a
SFC-enabled domain or outside a SFC-enabled domain.</t>
<t>SF Proxy Node: a Network Element along the data path, to enforce
SFC functions on behalf of legacy SF nodes.</t>
</list></t>
</section>
<section title="Functional Elements">
<t>The following functional elements are defined in this document:<list
style="symbols">
<t>SFC Boundary Node (or Boundary Node): denotes a node that
connects one SFC-enabled domain to a node either located in another
SFC-enabled domain or in a domain that is SFC-unaware.</t>
<t>SFC Egress Node (or Egress Node): denotes a SFC Boundary Node
that handles traffic which leaves the SFC-enabled domain the Egress
Node belongs to.</t>
<t>SFC Ingress Node (or Ingress Node): denotes a SFC Boundary Node
that handles traffic which enters the SFC-enabled domain the ingress
Node belongs to.</t>
<t>SF Node: denotes any node within an SFC-enabled domain that
embeds one or multiple SFs.</t>
<t>SFC Classifier (or Classifier): an entity that classifiers
packets for service chaining according to classification rules
defined in a SFC Policy Table. Packets are then marked with the
corresponding SF Map Index. SFC Classifier is embedded in a SFC
boundary (Ingress) Node. A SFC Classifier may be considered as a
Service Function, and therefore be uniquely identified by a
dedicated SF Identifier.</t>
</list></t>
<t></t>
</section>
<section anchor="boot" title="SFC Provisioning">
<t>It is out of scope of this document to discuss SF-specific policy
enforcement; only SFC considerations are elaborated.</t>
<section title="Assign Service Function Identifiers">
<t>The administrative entity that operates a SFC-enabled domain
maintains a local repository that lists the enabled SFs. This
administrative entity assigns a unique SF identifier for each SF
type.</t>
<t>SF identifiers are structured as character strings. SF identifiers
are case-sensitive.</t>
<t>The main constraint on the format is that two SFs MUST be assigned
with different SF identifiers if they do not provide the exact same
function, or do provide the same function but are unable to
differentiation packets based on policies provisioned to the SF using
an appropriate mechanism.</t>
</section>
<section title="Service Function Locator">
<t>A SF may be embedded in one or several SF Nodes. The SF locator is
typically the IP address or the FQDN to reach a given SF.</t>
<t>The use of an IP address is RECOMMENDED to avoid any extra
complexity related to the support of name resolution capabilities in
SF Nodes. Resolution capabilities are supported by the PDP (Policy
Decision Point). In the rest of the document, we assume a SF locator
is structured as an IP address (IPv4 or IPv6).</t>
<t>A SF can be reached by one or more locators. When multiple SF
locators are in use, the locator to be used to reach a given SF can be
driven by the PDP, a SF in a SFC, result of a load-balancing
heuristic, etc.</t>
</section>
<section title="Service Function Discovery">
<t>The local repository that lists the enabled SFs within an
SFC-enabled domain may be built as a direct input from the
administrative entity, or they may be discovered dynamically through
appropriate protocol discovery means.</t>
<t>Whichever method is selected by the administrative entity is a
local decision and is therefore outside the scope of this document.
Any Service Function Discovery solution must comply with the
requirements identified in <xref
target="I-D.boucadair-sfc-requirements"></xref>.</t>
</section>
<section title="Building Service Function Maps">
<t>Added-value services delivered to the end-user rely on the
invocation of several SFs. For each of these services, the
administrative entity that operates an SFC-enabled domain builds one
or several SF Maps. Each of these maps characterizes the list of SFs
to be invoked with their exact invocation order.</t>
<t>Each SF Map is unambiguously identified with a unique identifier
called the SF Map Index. The SF Map Index MUST be described as an
unsigned integer.</t>
<t>Distinct chains can be applied for inbound and outbound traffic.
The directionality of traffic is not included as an attribute of the
SF Map, but it may be implicitly described by using two SF Maps
installed and maintained in the SFC Policy Table. In such case,
incoming packets would be marked with Index_1 for example, while
outgoing packets would be forwarded according to a distinct SF Map
identified with Index_2.</t>
<t>An example of SF Map to handle IPv6 traffic destined to an IPv4
remote server is defined as follows: <list style="empty">
<t>{15, {IPv6_Firewall, HOST_ID_Inject, NAT64}}.</t>
</list>To handle incoming packets destined to the same IPv6 host,
the following SF Map can be defined:<list style="empty">
<t>{10, {IPv4_Firewall, NAT64}}.</t>
</list></t>
</section>
<section title="Building Service Function Chaining (SFC) Policy Tables">
<t>A PDP (Policy Decision Point, <xref target="RFC2753"></xref>) is
the central entity which is responsible for maintaining SFC Policy
Tables (Figure 1), and enforcing appropriate policies in SF Nodes and
SFC Boundary Nodes (Figure 1). PDP-made decisions can be forwarded to
the participating nodes by using a variety of protocols (e.g., NETCONF
<xref target="RFC6241"></xref>).</t>
<t>One or multiple SFC-enabled domains may be under the responsibility
of the same PDP. Delimiting the scope of each SFC-enabled domain is
under the responsibility of the administrative entity that operates
the SF-enabled network.</t>
<t><figure align="center"
title="Figure 1: SFC Policy Enforcement Scheme. ">
<artwork><![CDATA[o . . . . . . . . . . . . . . . . . . . . . . . o
. SFC Policy Enforcement .
. +-------+ .
. | |-----------------+ .
. +-------| PDP | | .
. | | |-------+ | .
. | +-------+ | | .
o . . | . . . . . | . . . . . | . . . . | . . . o
o . . | . . . . . | . . . . . | . . . . | . . . o
. | | | | .
. v v v v .
. +---------+ +---------+ +-------+ +-------+ .
. |SFC_BN_1 | |SFC_BN_n | | SF_1 | | SF_m | .
. +---------+ +---------+ +-------+ +-------+ .
. SFC-enabled Domain .
o . . . . . . . . . . . . . . . . . . . . . . . o
]]></artwork>
</figure></t>
<t>The SF Node MUST be provisioned with the following
information:<?rfc subcompact="yes" ?><list style="symbols">
<t>Local SF Identifier(s): This information is required for an SF
to identify itself within an SF Map.</t>
<t>List of SF Maps: The PDP may configure the full list (default
mode) or only as subset of SF Maps in which SF(s) supported by the
SF Node is involved (see <xref target="litePT"></xref>).</t>
<t>List of SF Locators: The PDP may configure the full list of
locators (default mode) or only the locators of next hop SFs of SF
Maps in which SF(s) supported by the local SF node is involved
(see <xref target="litePT"></xref>).<?rfc subcompact="no" ?></t>
</list></t>
<t><list style="empty">
<t>[DISCUSSION NOTE: Discuss if we maintain both forms of the SFC
Policy table (full and lite) or select only one of them.]</t>
</list></t>
<t>Likewise, the SFC Boundary Node MUST be provisioned with the
following information:<?rfc subcompact="yes" ?><list style="symbols">
<t>List of SF Maps</t>
<t>List of SF Locators</t>
<t>List of SF Map Classification Rules (see <xref
target="classifier"></xref>).<?rfc subcompact="no" ?></t>
</list></t>
<t>In addition to the SFC Policy Table, other SF-specific policies can
be installed by the PDP (e.g., configure distinct user profiles,
activate specific traffic filters, configure traffic conditioners,
etc.).</t>
<t>Policies managed by the PDP may be statically instantiated or
dynamically triggered by external means (e.g., a AAA server).</t>
<t>In the event of any update (e.g., define a new SF Map, delete an SF
Map, add a new SF Locator, update classification policy), the PDP MUST
forward the updated policy configuration information in all relevant
SF Nodes and SFC Boundary Nodes.</t>
<t>Distributing the load among several SF Nodes supporting the same SF
can be driven by the PDP. Indeed, the PDP can generate multiple
classification rules and SF Maps to meet some load-balancing
objectives.</t>
<t>Load balancing may also be achieved locally by an SF Node. If the
SF Node, SF Classifier, or SF Boundary Node has a table that provides
the SF locator(s) of SF Nodes that provide a particular SF then it is
possible to make that local load balancing decision.</t>
<t>The processing of packets by the nodes that belong to a SFC-enabled
domain does not necessarily require any interaction with the PDP,
depending on the nature of the SF supported by the nodes and the
corresponding policies to be enforced. For example, traffic
conditioning capabilities <xref target="RFC2475"></xref> are typical
SF functions that may require additional solicitation of the PDP for
the SF node to decide what to do with some out-of-profile traffic.</t>
</section>
</section>
<section anchor="overview" title="Theory Of Operation">
<t>The behavior of each node of a SFC-enabled domain is specified in the
following sections. We assume that the provisioning operations discussed
in <xref target="boot"></xref> have been successful (i.e., SF functions
have been adequately configured according to the SFC-specific policy to
be enforced).</t>
<section title="SFC Boundary Node">
<t>SFC Boundary Nodes act both as a SFC Ingress Node and as a SFC
Egress Node for the respective directions of the traffic.</t>
<t>Traffic enters a SFC-enabled domain at a SFC Ingress Node (<xref
target="ingress"></xref>) and exits the domain at a SFC Egress Node
(<xref target="egress"></xref>).</t>
</section>
<section anchor="classifier" title="SFC Classifier">
<t>The SFC Classifier classifies packets based on (some of) the
contents of the packet. Particularly, it classifies packets based on
the possible combination of one or more header fields, such as source
address, destination address, DS field, protocol ID, source port and
destination port numbers, and any other information.</t>
<t>Each SF Map Classification Rule MUST be bound to one single SF Map
(i.e., the classification rule must include only one SF Map
Index).</t>
</section>
<section anchor="ingress" title="SFC Ingress Node">
<t>When a packet is received through an interface of the SFC Ingress
Node that connects to the outside of the SFC domain, the Ingress Node
MUST:<?rfc subcompact="yes" ?><list style="symbols">
<t>Inspect the received packet and check whether any existing SF
Map Index is included in the packet. <list style="symbols">
<t>The SFC Ingress Node SHOULD be configurable with a
parameter to indicate whether received SF Map Index is to be
preserved or striped. The default behavior is to strip any
received SF Map Index.</t>
<t>Unless explicitly configured to trust SF Map index, The SFC
Ingress Node MUST strip any existing SF Map Index if the
packet is received from an SFC-enabled domain that has not
explicitly been designated as "trusted".</t>
</list></t>
<t>Check whether the received packet matches an existing
classification rule (see <xref target="classifier"></xref>).</t>
<t>If no rule matches, forward the packet to the next hop
according to legacy forwarding behavior (e.g., based upon the IP
address conveyed in the DA field of the header).</t>
<t>If a rule matches, proceed with the following operations:<list
style="symbols">
<t>Retrieve the locator of the first SF as indicated in the SF
Map entry the rule matches. If multiple locators are
available, the selection can be based on local criteria (e.g.,
the closest/best path).</t>
<t>Check whether the corresponding SF node is an immediate
(L3) neighbor. <list style="symbols">
<t>If so, update the packet with the SF Map Index of SF
Map entry it matches and then forward the packet to the
corresponding SF Node.</t>
<t>If not, (1) encapsulate the original packet into a new
one that will be forwarded to the corresponding SF node,
(2) update the encapsulated packet with the SF Map Index
of SF Map entry it matches, and (3) forward the packet to
the next hop to reach the first SF node.<?rfc subcompact="no" ?></t>
</list></t>
</list></t>
</list>As a result of this process, the packet will be sent to an SF
Node or an Intermediate Node.</t>
</section>
<section anchor="egress" title="SFC Egress Node">
<t>When a packet is received through an interface that connects the
SFC Egress Node to its SFC domain, the Egress Node MUST:<?rfc subcompact="yes" ?><list
style="symbols">
<t>Strip any existing SF Map Index.</t>
<t>Forward the packet according to legacy forwarding policies.</t>
</list></t>
<t><?rfc subcompact="no" ?></t>
</section>
<section title="SF Node">
<t>This section assumes the default behavior is each SF Node does not
embed a Classifier as discussed in <xref
target="nlfclass"></xref>.</t>
<t>When a packet is received by a SF Node, the SF Node MUST:<?rfc subcompact="yes" ?></t>
<t><list style="symbols">
<t>Check whether the packet conveys a SF Map Index.</t>
<t>If no SF Map Index is included, forward the packet according to
legacy forwarding policies.</t>
<t>If the packet conveys a SF Map Index, <list style="symbols">
<t>Retrieve the corresponding SF Map from the SFC Policy
Table. If no entry is found in the table, forward the packet
according to legacy forwarding policies.<list style="empty">
<t>[DISCUSSION NOTE: Another design choice is to drop the
packet and send a notification to the PDP. The
justification for avoiding to drop the packet is that an
SF can be part of the forwarding path of an SFC to which
it does not belong to.]</t>
</list></t>
<t>If an entry is found in the SFC Policy Table, check whether
the local SF Identifier is present in the SF Map:<list
style="symbols">
<t>If not, forward the packet according to legacy
forwarding policies.<list style="empty">
<t>[DISCUSSION NOTE: One would argue the packet should
be dropped. The justification for avoiding to drop the
packet is that an SF can be part of the forwarding
path of an SFC to which it does not belong to + the SF
node is provisioned with the full SFC Policy
Table.]</t>
</list></t>
<t>If so, the packet is decapsulated (if needed) and then
presented as an input to the local SF. In case several SFs
are co-located in the same node, the packet is processed
by all SFs indicated in the SF Map. Once the packet is
successfully handled by local SF(s), the packet is
forwarded to the next SF Node in the list or to an
intermediate node (if the local SF Node is the last
element in the SF Map). If the local SF node is not the
last one in the SF Map, it retrieves the next SF Node from
the list, retrieve its locator for the SFC Policy Table,
and forwards the packet to the next hop. If the local SF
Node is the last element in the SF Map, it forwards the
packet to the next hop according to legacy forwarding
policies.<?rfc subcompact="no" ?></t>
</list></t>
</list></t>
</list></t>
</section>
<section title="Intermediate Nodes">
<t>An Intermediate Node is any node that does not support any Service
Function and which is located within a SFC-enabled domain.</t>
<t>No modification is required to intermediate nodes to handle
incoming packets. In particular, routing and forwarding are achieved
using legacy procedures.</t>
</section>
</section>
<section title="Fragmentation Considerations">
<t>If adding the Service Chaining Header would result in a fragmented
packet, the classifier should include a Service Chaining Header in each
fragment. Doing so would prevent SF Nodes to dedicate resource to handle
fragments.</t>
</section>
<section title="Differentiated Services">
<t>When encapsulating an IP packet, the Ingress Node and each SF Node
SHOULD use its Diffserv Codepoint (DSCP, <xref target="RFC2474"></xref>)
to derive the DSCP (or MPLS Traffic-Class Field) of the encapsulated
packet.</t>
<t>Generic considerations related to Differentiated Services and tunnels
are further detailed in <xref target="RFC2983"></xref>.</t>
</section>
<section title="ECN (Explicit Congestion Notification) Considerations">
<t>When encapsulating an IP packet, the Ingress Node and each SF Node
SHOULD follow <xref target="RFC6040"></xref> for ECN re-marking
purposes.</t>
</section>
<section anchor="design" title="Design Considerations">
<t>This section discusses two main protocol issues to be handled in
order to deploy SFC.</t>
<t>A detailed design analysis is documented in <xref
target="I-D.boucadair-sfc-design-analysis"></xref>.</t>
<section anchor="index" title="Transmit A SFC Map Index In A Packet">
<t></t>
<section title="SFC Map Index">
<t>A SF Map Index is an integer that points to a SF Map.</t>
<t>In order to avoid all nodes of a SFC-enabled domain to be
SF-aware, this specification recommends to undertake classifiers at
boundary nodes while intermediate nodes forward the packets
according to the SF Map Index conveyed in the packet (SF Node) or
according to typical forwarding policies (any SF-unaware node).</t>
<t>An 8-bit field would be sufficient to accommodate deployment
contexts that assume a reasonable set of SF Maps. A 16-bit (or
32-bit) field would be more flexible (e.g., to accommodate the
requirement discussed in <xref target="profile"></xref>).</t>
</section>
<section title="Where To Store SFC Map Indexes In A Packet?">
<t>SF Map Indexes can be conveyed in various locations of a
packet:<?rfc subcompact="yes" ?><list style="symbols">
<t>At L2 level</t>
<t>Define a new IP option or a new IPv6 extension header</t>
<t>Use IPv6 Flow Label</t>
<t>Use MPLS Label</t>
<t>Re-use an existing field (e.g., DS field)</t>
<t>TCP option</t>
<t>GRE Key</t>
<t>Define a new shim</t>
<t>Etc.<?rfc subcompact="no" ?></t>
</list></t>
</section>
</section>
<section title="Steer Paths To Cross Specific SF Nodes">
<t>A SFC Ingress Node or a SF Node MUST be able to forward a packet
that matches an existing SF Map to the relevant next hop SF Node. The
locator of the next SF is retrieved from the SFC Policy Table. In case
the next SF Node in the list is not an immediate (L3) neighbor, a
solution to force the packet to cross that SF Node MUST be
supported.</t>
</section>
</section>
<section anchor="depl" title="Deployment Considerations">
<t></t>
<section anchor="req" title="Generic Requirements">
<t>The following deployment considerations should be taken into
account:<?rfc subcompact="yes" ?><list style="symbols">
<t>Avoid inducing severe path stretch compared to the path
followed if no SF is involved.</t>
<t>Minimize path computation delays: due to the enforcement of
classification rules in all participating nodes, misconception of
Service function chaining, inappropriate choice of nodes elected
to embed Service functions, etc., must be avoided.</t>
<t>Avoid SF invocation loops: the design of SF chainings should
minimize as much as possible SF invocation loops. In any case,
forwarding loops must be avoided.<?rfc subcompact="no" ?></t>
</list></t>
</section>
<section title="Deployment Models">
<t>Below are listed some deployment model examples:</t>
<t><list style="numbers">
<t>A full marking mechanism: Ingress nodes perform the
classification and marking functions. Then, involved SF Nodes
process received packets according to their marking.</t>
<t>SF node mechanism, in which every SF Node embeds also a
classifier, and the ingress node only decides the first node to
forward to. Packets are forwarded at each node according to local
policies. No marking is required when all SFs are co-located with
a classifier. This model suffers from some limitations (see <xref
target="nlfclass"></xref>).</t>
<t>A router-based mechanism: All SF Nodes forward packets once
processed to their default router. This default routes is
responsible for deciding how the packet should be progressed at
each step in the chain. One or multiple routers can be involved in
the same Service Function Chain.</t>
<t>A combination thereof.</t>
</list></t>
<t></t>
<section title="1.1. Proxy Node for Legacy Service Functions">
<t>It is not uncommon to have multiple legacy service nodes located
in close vicinity with a service chain proxy node, or one to two
links away. The following figure depicts typical network
architecture for chaining those service nodes that are not aware of
service layer encapsulation.</t>
<t><figure>
<artwork><![CDATA[ |1 ----- |n |21 ---- |2m
+---+---+ +---+---+ +-+---+ +--+----+
| SF1 | | SF2 | | SF3 | | SF4 |
+---+---+ +---+---+ +--+--+ +--+--+-+
: : : : :
: : : : :
\ / \ /
+--------------+ +--------+ +---------+
-- >| SFC | ->| Proxy |---------> | Proxy | ---->
| Classifier | | Node-1 | | Node-i |
+--------------+ +----+---+ +----+--+-+
|-- | |
V +--->
+--------+
| Proxy |
| -j |----->
+--------+
]]></artwork>
</figure></t>
<t>Various deployment options can be envisaged:<list style="numbers">
<t>Upgrade legacy service nodes to support required SFC
functionalities.</t>
<t>Enable Proxy Service Nodes to involve these legacy nodes in
instantiated SFCs.</t>
<t>Exclude legacy service nodes from a SFC domain.</t>
</list></t>
<t>It is up to the responsibility of each Service Provider to decide
which option to deploy within its networks.</t>
</section>
</section>
<section anchor="profile"
title="On Service Function Profiles (a.k.a., Contexts)">
<t>Service Functions may often enforce multiple differentiated policy
sets. These policy sets may be coarsely-grained or fine-grained. An
example of coarsely-grained policy sets would be an entity that
performs HTTP content filtering where one policy set may be
appropriate for child users whereas another is appropriate for adult
users. An example of finely-grained policy sets would be PCEF (3GPP
Policy Control Enforcement Function) that has a large number of
differentiated QoS and charging profiles that are mapped on a
per-subscriber basis.</t>
<t>The Service Function Chaining mechanism directly support
coarsely-grained differentiated policy sets and indirectly support
finely-grained differentiated policy sets.</t>
<t>From a Service Function Chaining perspective, each coarsely-grained
policy set for a Service Function will be considered as a distinct
logical instance of that Service Function. Consider the HTTP content
filtering example where one physical or virtual entity provides both
child and adult content filtering. The single entity is represented as
two distinct logical Service Functions, each with their own Service
Function Identifier from a chaining perspective. The two (logical)
Service Functions may share the same IP address or may have distinct
IP addresses.</t>
<t>Finely-grained policy sets, on the other hand, would unacceptably
explode the number of distinct Service Chains that were required with
an administrative domain. For this reason, Service Functions that
utilize finely-grained policy sets are represented as a single Service
Function that has its own internal classification mechanism in order
to determine which of its differentiated policy sets to apply. Doing
so avoids from increasing the size of the SFC Policy Table.</t>
<t>The threshold, in terms of number of policies, between choosing the
coarsely-grained policy or finely-grained policy technique is left to
the administrative entity managing a given domain.<list style="empty">
<t>[DISCUSSION NOTE: This section will be updated to reflect the
conclusions of the discussions from the design analysis
draft.]</t>
</list></t>
</section>
<section anchor="nlfclass" title="SF Node is also a Classifier">
<t>If SF Nodes are also configured to behave as Classifiers, the SF
Map Index is not required to be explicitly signalled in each packet.
Concretely, the SFC Policy Table maintained by the SF Node includes
classification rules. These classification rules are enforced to
determine whether the local SF must be involved. If an incoming packet
matches at least one classification rule pointing to an SF Map in
which the SF Identifier is listed, the SF Node retrieves the next hop
SF from the SF Map indicated in the classification rule.</t>
<t>The packet is then handled by the local SF, and the SF Node
subsequently forwards the packet to the next hop SF. If not, the
packet is forwarded to the next hop according to a typical IP
forwarding policy.</t>
<t>Let us consider the example shown in Figure 2. The local SF Node
embeds SFa. Once classification rules and the SF Maps are checked, the
SF Node concludes SFa must be invoked only when a packet matches Rules
1 and 3. If a packet matches Rule 1, the next SF is SFC. If a packet
matches Rule 3, the next SF is SFh.</t>
<t><figure align="center" title="Figure 2: SFC Policy Table Example.">
<artwork><![CDATA[+-----------------------------------------------+
| SFC Policy Table |
+-----------------------------------------------+
|Local SF Identifier: SFa |
+-----------------------------------------------+
|Classification Rules |
| Rule 1: If DEST=IP1; then SFC_MAP_INDEX1 |
| Rule 2: If DEST=IP2; then SFC_MAP_INDEX2 |
| Rule 3: IF DEST=IP3; then SFC_MAP_INDEX3 |
+-----------------------------------------------+
|SF Maps |
| SFC_MAP_INDEX1: {SFa, SFc} |
| SFC_MAP_INDEX2: {SFd, SFb} |
| SFC_MAP_INDEX3: {SFa, SFh} |
+-----------------------------------------------+
]]></artwork>
</figure></t>
</section>
<section anchor="adj" title="SFs within the Same Subnet">
<t>SF Nodes may be enabled in a SFC-enabled domain so that each of
them has a direct L3 adjacency with other SF Nodes. In such
configuration, no encapsulation scheme is required to exchange traffic
between these nodes.</t>
</section>
<section anchor="loops" title="Service Function Loops">
<t>SF Nodes use the SFC Policy Table to detect whether the local SF
was already applied to the received packet (i.e., detect SF Loop). The
SF Node MUST invoke the local SF only if the packet is received from a
SFC Boundary Node or a SF Node having an identifier listed before the
local SF in the SF Map matched by the packet. SF Loop detection SHOULD
be a configurable feature.</t>
<t>Figure 3 shows an example of a SFC Policy Table of a SF Node
embedding SFa. Assume a packet received from Locb that matches Rule 2.
SFa must not be invoked because SFb is listed after SFa (see the SF
Map list). That packet will be forwarded without invoking SFa.</t>
<t><figure align="center" title="Figure 3: Dealing With SF Loops.">
<artwork><![CDATA[+-----------------------------------------------+
| SFC Policy Table |
+-----------------------------------------------+
|Local SF Identifier: SFa |
+-----------------------------------------------+
|SF Maps |
| SFC_MAP_INDEX1: {SFa, SFc} |
| SFC_MAP_INDEX2: {SFd, SFa, SFb, SFh} |
+-----------------------------------------------+
|SFC Locators |
| Locator_SFb: Locb |
| Locator_SFC: Locc |
| Locator_SFd: Locd |
| Locator_SFh: Loch |
+-----------------------------------------------+
]]></artwork>
</figure></t>
<t></t>
</section>
<section anchor="litePT" title="Lightweight SFC Policy Table">
<t>If SF loop detection is not activated in an SFC-enabled domain, the
PDP may provision SF nodes with a "lightweight" SFC Policy Table. A
lightweight SFC Policy Table is a subset of the full SFC Policy Table
that includes:<?rfc subcompact="yes" ?><list style="symbols">
<t>Only the SF Maps in which the local SF is involved.</t>
<t>Only the next hop SF instead of the full SF chain.<?rfc subcompact="no" ?></t>
</list></t>
<t>An example of a lightweight SFC Policy Table is shown in Figure
4.</t>
<t><figure align="center"
title="Figure 4: Lightweight SFC Policy Table.">
<artwork><![CDATA[+-----------------------------------------------+
| SFC Policy Table |
+-----------------------------------------------+
|Local SF Identifier: SFa |
+-----------------------------------------------+
|Lite SF Maps |
| SFC_MAP_INDEX1, Next_Hop_SF = SFc |
| SFC_MAP_INDEX2, Next_Hop_SF = SFb |
+-----------------------------------------------+
|SFC Locators |
| Locator_SFb: Locb |
| Locator_SFC: Locc |
+-----------------------------------------------+
]]></artwork>
</figure></t>
</section>
<section title="Liveness Detection Of SFs By The PDP">
<t>The ability of the PDP to check the liveness of each SF invoked in
a service chain has several advantages, including:<?rfc subcompact="yes" ?><list
style="symbols">
<t>Enhanced status reporting by the PDP (i.e., an operational
status for any given service chain derived from liveness state of
its SFs).</t>
<t>Ability to support various resiliency policies (i.e., bypass SF
Node, use alternate SF Node, use alternate chain, drop traffic,
etc.) .</t>
<t>Ability to support load balancing capabilities to solicit
multiple SF instances that provide equivalent functions.<?rfc subcompact="no" ?></t>
</list></t>
<t>In order to determine the liveness of any particular SF Node,
standard protocols such as ICMP or BFD (both single-hop <xref
target="RFC5881"></xref> and multi-hop <xref target="RFC5883"></xref>)
may be utilized between the PDP and the SF Nodes.</t>
<t>Because an SF Node can be responsive from a reachability standpoint
(e.g., IP level) while the function its provides may be broken (e.g.,
a NAT module may be down), additional means to assess whether an SF is
up and running are required. These means may be service-specific
(e.g., <xref target="RFC6849"></xref>, <xref
target="I-D.tsou-softwire-bfd-ds-lite"></xref>).</t>
<t>For more sophisticated load-balancing support, protocols that allow
for both liveness determination and the transfer of
application-specific data, such as SNMP and NETCONF may be utilized
between the PDP and the SF Nodes.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document does not require any IANA actions.<?rfc subcompact="no" ?></t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Means to protect SFC Boundary Nodes and SF Nodes against various
forms of DDoS attacks MUST be supported. For example, mutual PDP and SF
node authentication should be supported. Means to protect SF nodes
against malformed, poorly configured (deliberately or not) SFC Policy
Tables should be supported.</t>
<t>SFC Boundary Nodes MUST strip any existing SF Map Index when handling
an incoming packet. A list of authorized SF Map Indexes are configured
in the SFC elements.</t>
<t>NETCONF-related security considerations are discussed in <xref
target="RFC6146"></xref>.</t>
<t>Means to prevent SF loops should be supported.</t>
<t>Nodes involved in the same SFC-enabled domain MUST be provisioned
with the same SFC Policy Table. Possible table inconsistencies may
result in forwarding errors.</t>
</section>
<section title="Contributors">
<t>The following individuals contributed to the document:</t>
<t><figure>
<artwork><![CDATA[ Parviz Yegani
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
USA
Email: pyegani@juniper.net
Paul Quinn
Cisco Systems, Inc.
USA
Email: paulq@cisco.com
Linda Dunbar
Huawei Technologies
1700 Alma Drive, Suite 500
Plano, TX 75075, USA
Phone: (469) 277 5840
Email: ldunbar@huawei.com]]></artwork>
</figure></t>
<t></t>
</section>
<section title="Acknowledgments">
<t>Many thanks to D. Abgrall, D. Minodier, Y. Le Goff, D. Cheng, R.
White, and B. Chatras for their review and comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"
?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.2475'?>
<?rfc include='reference.RFC.2474'?>
<?rfc include='reference.RFC.6241'?>
<?rfc include='reference.I-D.sin-sdnrg-sdn-approach'?>
<?rfc include='reference.I-D.ietf-sfc-problem-statement'?>
<?rfc include='reference.I-D.boucadair-sfc-design-analysis'?>
<?rfc include='reference.I-D.boucadair-sfc-requirements'?>
<?rfc include='reference.RFC.6459'?>
<?rfc include='reference.RFC.2983'?>
<?rfc include='reference.RFC.5881'?>
<?rfc include='reference.RFC.5883'?>
<?rfc include='reference.RFC.6333'?>
<?rfc include='reference.RFC.6146'?>
<?rfc include='reference.RFC.3022'?>
<?rfc include='reference.RFC.2753'?>
<?rfc include='reference.RFC.6296'?>
<?rfc include='reference.RFC.6092'?>
<?rfc include='reference.RFC.6040'?>
<?rfc include='reference.RFC.6849'?>
<?rfc include='reference.I-D.tsou-softwire-bfd-ds-lite'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:04:19 |