One document matched: draft-ietf-sfc-control-plane-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc strict="no"?>
<?rfc iprnotified="yes"?>
<?rfc tocdepth="3"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc comments="yes"?>
<rfc category="info" docName="draft-ietf-sfc-control-plane-00"
ipr="trust200902">
<front>
<title abbrev="SFC Control Plane">Service Function Chaining (SFC) Control
Plane Components & Requirements</title>
<author fullname="Hongyu Li" initials="H." surname="Li">
<organization>Huawei</organization>
<address>
<postal>
<street>Huawei Industrial Base,Bantian,Longgang</street>
<region>Shenzhen</region>
<country>China</country>
</postal>
<email>hongyu.li@huawei.com</email>
</address>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>bill.wu@huawei.com</email>
</address>
</author>
<author fullname="Yong(Oliver) Huang" initials="O." surname="Huang">
<organization>Huawei</organization>
<address>
<postal>
<street>Huawei Industrial Base,Bantian,Longgang</street>
<region>Shenzhen</region>
<country>China</country>
</postal>
<email>oliver.huang@huawei.com</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M" role="editor"
surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street>Rennes 35000</street>
<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>Rennes 35000</street>
<country>France</country>
</postal>
<email>christian.jacquenet@orange.com</email>
</address>
</author>
<author fullname="Walter Haeffner" initials="W." surname="Haeffner">
<organization abbrev="Vodafone">Vodafone D2 GmbH</organization>
<address>
<postal>
<street>Ferdinand-Braun-Platz 1</street>
<region>Duesseldorf</region>
<code>40549</code>
<country>DE</country>
</postal>
<email>walter.haeffner@vodafone.com</email>
</address>
</author>
<author fullname="Seungik Lee" initials="S. " surname="Lee">
<organization abbrev="ETRI">ETRI</organization>
<address>
<postal>
<street>218 Gajeong-ro Yuseung-Gu</street>
<!-- Reorder these if your country does things differently -->
<city>Daejeon</city>
<region></region>
<code>305-700</code>
<country>Korea</country>
</postal>
<phone>+82 42 860 1483</phone>
<email>seungiklee@etri.re.kr</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Ron Parker" initials="R." surname="Parker">
<organization>Affirmed Networks</organization>
<address>
<postal>
<street>Acton</street>
<region>MA</region>
<code>01720</code>
<country>USA</country>
</postal>
<email>ron_parker@affirmednetworks.com</email>
</address>
</author>
<author fullname="Linda Dunbar" initials="L." surname="Dunbar">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>USA</country>
</postal>
<email>ldunbar@huawei.com</email>
</address>
</author>
<author fullname="Andrew Malis" initials="A." surname="Malis">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>USA</country>
</postal>
<email>agmalis@gmail.com</email>
</address>
</author>
<author fullname="Joel M. Halpern" initials="J." surname="Halpern">
<organization>Ericsson</organization>
<address>
<postal>
<street></street>
</postal>
<email>joel.halpern@ericsson.com</email>
</address>
</author>
<author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Cessna Business Park, Varthur Hobli</street>
<street>Sarjapur Marathalli Outer Ring Road</street>
<city>Bangalore</city>
<region>Karnataka</region>
<code>560103</code>
<country>India</country>
</postal>
<email>tireddy@cisco.com</email>
</address>
</author>
<author fullname="Prashanth Patil" initials="P." surname="Patil">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address>
<postal>
<street></street>
<city>Bangalore</city>
<country>India</country>
</postal>
<email>praspati@cisco.com</email>
</address>
</author>
<date year="" />
<workgroup>Service Function Chaining (sfc)</workgroup>
<keyword>differentiated services</keyword>
<keyword>differentiated forwarding</keyword>
<keyword>traffic steering</keyword>
<keyword>classification</keyword>
<keyword>service delivery</keyword>
<keyword>service operation</keyword>
<keyword>service innovation</keyword>
<keyword>service agility</keyword>
<keyword>flexible service</keyword>
<keyword>service provisioning</keyword>
<abstract>
<t>This document describes requirements for conveying information
between Service Function Chaining (SFC) control elements (including
management components) and SFC functional elements. Also, this document
identifies a set of control interfaces to interact with SFC-aware
elements to establish, maintain or recover service function chains. This
document does not specify protocols nor extensions to existing
protocols.</t>
<t>This document exclusively focuses on SFC deployments that are under
the responsibility of a single administrative entity. Inter-domain
considerations are out of scope.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The dynamic enforcement of a service-derived forwarding policy for
packets entering a network that supports advanced Service Functions
(SFs) has become a key challenge for operators. Typically, many advanced
Service Functions (e.g., Performance Enhancement Proxies (<xref
target="RFC3135"></xref>), NATs <xref target="RFC3022"></xref><xref
target="RFC6333"></xref><xref target="RFC6146"></xref>, firewalls <xref
target="I-D.ietf-opsawg-firewalls"></xref>, etc.) are solicited for the
delivery of value-added services, particularly to meet various service
objectives such as IP address sharing, avoiding covert channels,
detecting and protecting against ever increasing Denial-of-Service (DoS)
attacks, etc.</t>
<t>Because of the proliferation of such advanced service functions
together with complex service deployment constraints that demand more
agile service delivery procedures, operators need to rationalize their
service delivery logics and master their complexity while optimising
service activation time cycles. The overall problem space is described
in <xref target="RFC7498"></xref>. A more in-depth discussion on use
cases can be found in <xref
target="I-D.ietf-sfc-use-case-mobility"></xref> and <xref
target="I-D.ietf-sfc-dc-use-cases"></xref>.</t>
<t><xref target="I-D.ietf-sfc-architecture"></xref> presents a model
addressing the problematic aspects of existing service deployments,
including topological dependence and configuration complexity. It also
describes an architecture for the specification, creation, and ongoing
maintenance of Service Function Chains (SFC) within a network. That is,
how to define an ordered set of Service Functions and ordering
constraints that must be applied to packets and/or frames and/or flows
selected as a result of classification.</t>
<section title="Scope">
<t>While <xref target="I-D.ietf-sfc-architecture"></xref> focuses on
data plane considerations, this document describes requirements for
conveying information between SFC control elements (including
management components) and SFC functional elements. Also, this
document identifies a set of control interfaces to interact with
SFC-aware elements to establish, maintain or recover service function
chains.</t>
<t>Both distributed and centralized control plane schemes to install
SFC-related state and influence forwarding policies are discussed.</t>
<t>This document does not make any assumption on the deployment use
cases. In particular, the document implicitly covers fixed, mobile,
data center networks and any combination thereof.</t>
<t>This document does not make any assumption about which control
protocol to use, whether one or multiple control protocols are
required, or whether the same or distinct control protocols will be
invoked for each of the control interfaces. It is out of scope of this
document to specify a profile for an existing protocol, to define
protocol extensions, or to select a protocol.</t>
<t>Considerations related to the chaining of Service Functions that
span domains owned by multiple administrative entities are out of
scope.</t>
<t>It is out of scope of this document to discuss SF-specific control
and policy enforcement schemes; only SFC considerations are
elaborated, regardless of the various connectivity services that may
be supported in the SFC domain. Likewise, only the control of
SFC-aware elements is discussed.</t>
<t>Service catalogue (including guidelines for deriving service
function chains) is out of scope.</t>
</section>
<section title="Terminology">
<t>The reader should be familiar with the terms defined in <xref
target="RFC7498"></xref> and <xref
target="I-D.ietf-sfc-architecture"></xref>.</t>
<t>The document makes use of the following terms:<?rfc subcompact="yes" ?><list
style="symbols">
<t>SFC data plane functional element: Refers to SFC-aware Service
Function, Service Function Forwarder (SFF), SFC Proxy, or SFC
Classifier as defined in the SFC data plane architecture <xref
target="I-D.ietf-sfc-architecture"></xref>.</t>
<t>SFC Control Element: A logical entity that instructs one or
more SFC data plane functional elements on how to process packets
within an SFC-enabled domain.</t>
<t>SFC Classification entry: Refers to an entry maintained by an
SFC Classifier that reflects the policies for binding an incoming
flow/packet to a given SFC. Actions are associated with matching
criteria. For example, packets can be marked with the appropriate
SFC-related information to differentiate flows so that subsequent
SFFs can forward the flows to a sequence of SFs in a given order.
The set of classification entries maintained by a Classifier are
referred to as in the classification policy table.</t>
<t>SFC Forwarding Policy Table: this table reflects the
SFC-specific traffic forwarding policy enforced by SFF components
for every relevant incoming packet that is associated to one of
the existing SFCs.<list style="empty">
<t>[[Note: The question of whether the data plane operates
just in terms of SFP IDs or needs SFC IDs, as described in
this version of the draft, is still under discussion among the
authors.]]</t>
</list><?rfc subcompact="no" ?></t>
</list></t>
</section>
<section title="Assumptions">
<t>This document adheres to the assumptions listed in Section 1.2 of
<xref target="I-D.ietf-sfc-architecture"></xref>.</t>
<t>This document does not make any assumptions about the co-location
of SFC data plane functional elements; this is deployment-specific.
This document can accommodate a variety of deployment contexts such as
(but not limited to): <?rfc subcompact="yes" ?></t>
<t><list style="symbols">
<t>A Service Function Forwarder (SFF) can connect instances of the
same or distinct SFs.</t>
<t>A SF instance can be serviced by one or multiple SFFs.</t>
<t>One or multiple SFs can be co-located with a SFF.</t>
<t>A boundary 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) can act as an egress node and an ingress node for
the same flow.</t>
<t>Distinct ingress and egress nodes may be crossed by a packet
when forwarded in an SFC-enabled domain.</t>
<t>Distinct ingress nodes may be solicited for each traffic
direction (e.g., upstream and downstream).</t>
<t>An ingress node can embed a Classifier.</t>
<t>An ingress node may not embed a Classifier, but it can be
responsible for dispatching flows among a set of Classifiers.</t>
<t>The same boundary node may act as an ingress node, an egress
node, and also embed a Classifier.</t>
<t>A Classifier can be hosted in a node that embeds one or more
SFs.</t>
<t>Many network elements within an SFC-enabled domain may behave
as egress/ingress nodes.<?rfc subcompact="no" ?></t>
</list></t>
<t>Furthermore, the following assumptions are made:<?rfc subcompact="yes" ?><list
style="symbols">
<t>A Control Element can be co-located with a Classifier, SFF or
SF.</t>
<t>One or multiple Control Elements can be deployed in an
SFC-enabled domain.</t>
<t>State synchronization between Control Elements is out of
scope.<?rfc subcompact="no" ?></t>
</list></t>
</section>
</section>
<section title="Generic Considerations">
<t></t>
<section title="Generic Requirements">
<t>For deployments that would require so, SFC forwarding must be
allowed even if no control protocols are enabled. Static configuration
must be allowed.</t>
<t>A permanent association between an SFC data plane element with a
Control Element must not be required; specifically, the SFC-enabled
domain must keep on processing incoming packets according to the SFC
instructions even during temporary unavailability events of control
plane components. SFC implementations that do not meet this
requirement will suffer from another flavor of the constrained high
availability issue, discussed in Section 2.3 of <xref
target="RFC7498"></xref>, supposed to be solved by SFC designs.</t>
</section>
<section title="SFC Control Plane Bootstrapping">
<t>The interface that is used to feed the SFC control plane with
service objectives and guidelines is not part of the SFC control plane
itself. Therefore, this document assumes the SFC control plane is
provided with a set of information that is required for proper SFC
operation with no specific assumption about how this information is
collected/provisioned, nor about the structure of such information.
The following information that is likely to be provided to the SFC
control plane at bootstrapping includes (non-exhaustive list): <?rfc subcompact="yes" ?></t>
<t><list style="symbols">
<t>Locators for Classifiers/SFF/SFs/Proxies, etc.</t>
<t>SFs serviced by each SFF.</t>
<t>A list of service function chains, including how they are
structured and unambiguously identified.</t>
<t>Status of each SFC: active/pre-deployment phase/etc. A SFC can
be defined at the management level and instantiated in an
SFC-enabled domain for pre-deployment purposes (e.g., testing).
Actions to activate, modify or withdraw an SFC are triggered by
the control plane. Nevertheless, this document does not make any
assumption about how an operator instructs the control plane.</t>
<t>A list of classification guidelines and/or rules to bind flows
to SFCs/SFPs.</t>
<t>Optionally, (traffic/CPU/memory) load balancing objectives at
the SFC level or on a per node (e.g., per-SF/SFF/Proxy) basis.</t>
<t>Security credentials.</t>
<t>Context information that needs to be shared on a per SFC
basis.<?rfc subcompact="no" ?></t>
</list></t>
<t>Also, the SFC control plane may gather the following information
from an SFC-enabled domain at bootstrapping (non-exhaustive list). How
this information is collected is left unspecified in this document:
<?rfc subcompact="yes" ?></t>
<t><list style="symbols">
<t>The list of active SFC-aware SFs (including their
locators).</t>
<t>The list of SFFs and the SFs that are attached to.</t>
<t>The list of enabled SFC Proxies, and the list of SFC-unware SFs
attached to.</t>
<t>The list of active SFCs/SFPs as enabled in an SFC-enabled
domain.</t>
<t>The list of Classifiers and their locators, so as to retrieve
the classification policy table for each Classifier, in
particular.</t>
<t>The SFC forwarding policy tables maintained by SFFs.<?rfc subcompact="no" ?></t>
</list></t>
<t>During the bootstrapping phase, a Control Element may detect a
conflict between the running configuration in an SFC data plane
element and the information maintained by the control plane.
Consequently, the control plane undertakes appropriate actions to fix
those conflicts. This is typically achieved by invoking one of the
interfaces defined in <xref target="refint"></xref>.</t>
</section>
<section title="Coherent Setup of an SFC-enabled Domain">
<t>Various transport encapsulation schemes and/or variations of SFC
header implementations may be supported by one or several nodes of an
SFC-enabled domain. For the sake of coherent configuration, the SFC
control plane is responsible for instructing all the involved SFC data
plane functional elements about the behavior to adopt to select the
transport encapsulation scheme(s), the version of the SFC header to
enable, etc.</t>
</section>
</section>
<section title="SFC Control Plane: Reference Architecture & Interfaces">
<t></t>
<section title="Reference Architecture">
<t>The SFC control plane is responsible for the following:<?rfc subcompact="yes" ?><list
style="symbols">
<t>Build and monitor the service-aware topology. For example, this
can be achieved by means of dynamic SF discovery techniques. Those
means are out of scope of this document.</t>
<t>Maintain a repository of service function chains, SFC matching
criteria to bind flows to a given service function chain, and
mapping between service function chains and SFPs.</t>
<t>Guarantee the coherency of the configuration and the operation
of an SFC-enabled domain.</t>
<t>Dynamically compute a service-aware forwarding path
(distributed model, see <xref target="cd"></xref>)</t>
<t>Determine a forwarding path in the context of a centralized
deployment model (see <xref target="cd"></xref>).</t>
<t>Update service function chains or adjust SFPs (e.g., for
restoration purposes) based on various inputs (e.g., external
policy context, path alteration, SF unavailability, SF withdrawal,
service decommissioning, etc.).</t>
<t>Populate SFC forwarding policy tables of involved SFC data
plane elements and provides Classifiers with traffic
classification rules.<?rfc subcompact="no" ?></t>
</list></t>
<t><xref target="arch"></xref> shows the overall SFC control plane
architecture, including interface reference points.</t>
<t>This document does not elaborate on the internal decomposition of
the SFC Control & Management Plane functional blocks. The
components within the SFC Control & Management Planes and their
interactions are out of scope.</t>
<t>As discussed in <xref target="cd"></xref>, the SFC control plane
can be implemented in a (logically) centralized or distributed
fashion.</t>
<t><figure align="left" anchor="arch"
title="SFC Control Plane: Overview">
<artwork><![CDATA[
+----------------------------------------------+
| |
| SFC Control & Management Planes |
+-------| |
| | |
C1 +------^-----------^-------------^-------------+
+---------------------|C3---------|-------------|-------------+
| | +----+ | | |
| | | SF | |C2 |C2 |
| | +----+ | | |
| +----V--- --+ | | | |
| | SFC | +----+ +-|--+ +----+ |
| |Classifier |---->|SFF |----->|SFF |------->|SFF | |
| | Node |<----| |<-----| |<-------| | |
| +-----------+ +----+ +----+ +----+ |
| | | | |
| |C2 ------- | |
| | | | +-----------+ C4 |
| V +----+ +----+ | SFC Proxy |--> |
| | SF | |SF | +-----------+ |
| +----+ +----+ |
| |C3 |C3 |
| SFC Data Plane Components V V |
+-------------------------------------------------------------+
]]></artwork>
</figure></t>
<t>Note, the SFC control plane must be able to invoke SFC OAM
mechanisms, and to determine the results of OAM operations. </t>
</section>
<section anchor="cd" title="Centralized vs. Distributed">
<t>The SFC control plane can be (logically) centralized, distributed
or a combination thereof. Whether one or multiple SFC Control Elements
are enabled is deployment-specific. Nevertheless, the following
comments can be made:</t>
<t><list style="hanging">
<t
hangText="SFC management (including SFC monitoring and supervision):">is
likely to be centralized.</t>
<t hangText="SFC Mapping Rules:">i.e., service instructions to
bind a flow to a service function chain are likely to be managed
by a central SFC Control Element, but the resulting policies can
be shared among several Control Elements. Note, these policies can
be complemented with local information (e.g., an IPv4 address/IPv6
prefix assigned to a customer) because such information may not be
available to the central entity but known only during network
attachment phase.</t>
<t hangText="Path computation:">can be either distributed or
centralized. Distributed path computation means that the selection
of the exact sequence of SF functions that a packet needs to
invoke (along with instances and/or SFF locator information) is a
result of a distributed path selection algorithm executed by
involved nodes. For some traffic engineering proposes, the SFP may
be constrained by the control plane; as such, some SFPs can be
fully specified (i.e., list all the SFF/SFs that need to be
solicited) or partially specified (e.g., exclude some nodes,
explicitly select which instance of a given SF needs to be
invoked, etc.).</t>
<t hangText="SFC Resiliency (including restoration)">refers to
mechanisms to ensure high available service function chains. It
includes means to detect node/link/path failures. Both centralized
and distributed mechanism to ensure SFC resiliency can be
envisaged.</t>
</list></t>
<t>Implementing a (logically) centralized path computation engine
requires information to be dynamically communicated to the central SFC
Control Element, such as the list of available SF instances, SFF
locators, load status, SFP availability, etc.</t>
</section>
<section anchor="refint" title="Interface Reference Points">
<t>The following sub-sections describe the interfaces between the SFC
Control & Management Planes, as well as various SFC data plane
elements. </t>
<section anchor="c1"
title="C1: Interface between SFC Control Plane & SFC Classifier">
<t>As a reminder, a Classifier is a function that is responsible for
classifying traffic based on (pre-defined) rules.</t>
<t>This interface is used to install SFC classification rules in
Classifiers. Once classification rules are populated, SFC
Classifiers are responsible for binding incoming traffic to service
function chains according to these classification rules. Note, the
SFC control plane must not make any assumption on how the traffic is
to be bound to a given SFC. In other words, classification rules are
deployment-specific. For instance, classification can rely on a
subset of the information carried in a received packet such as
5-tuple classification, be subscriber-aware, be driven by traffic
engineering considerations, or any combination thereof.</t>
<t>The SFC control plane should be responsible for removing invalid
(and stale) mappings from the classification tables maintained by
the classifiers. Also, local sanity checks mechanisms may be
supported locally by the Classifiers, but those are out of
scope.</t>
<t>The Classifier may be notified by the control plane about the
available SFs (including their locators) or be part of the service
function discovery procedure.</t>
<t>Classification rules may be updated, deleted or disabled by the
control plane. Criteria that would trigger those operations are
deployment-specific.</t>
<t>Given that service function chaining solutions may be applied to
very large sets of traffic, any control solution should take scaling
issues into consideration as part of the design.</t>
<t>Below are listed some functional objectives for this interface:
<?rfc subcompact="yes" ?><list style="symbols">
<t>Rationalize the management of classification rules.</t>
<t>Maintain a global view of instantiated rules in all
Classifiers in an SFC-enabled domain.</t>
<t>Check the consistency of instantiated classification rules
within the same Classifier or among multiple Classifier.</t>
<t>Assess the impact of removing or modifying a classification
entry on packets entering an SFC-enabled domain.</t>
<t>Aggregate classification rules for the sake of performance
optimization (mainly reduce lookup delays).</t>
<t>Adjust classification rules when rules are based on volatile
identifiers (e.g., an IPv4 address, IPv6 prefix).</t>
<t>Allow to rapidly restore SFC states during failure events
that occurred at a Classifier (or a Control Element).<?rfc subcompact="no" ?></t>
</list></t>
<t>The control plane must instruct the Classifier whether it can
trust an existing SFC marking of an incoming packet or whether it
must be ignored.</t>
<t>For bidirectional packet processing purposes (e.g., full or
partial path symmetry), the control plane invokes this interface to
configure the appropriate classification entries.</t>
<t>A Classifier can send unsolicited messages through this interface
to notify the SFC Control & Management Planes about specific
events.</t>
<t>When re-classification is allowed in an SFC-enabled domain, this
interface can be used to control Classifiers co-resident with
SFC-aware SFs, SFC Proxies, or SFFs to manage re-classification
rules .</t>
<t>SFC Classification policy entry should be bound to one single
service function chain (or one single SFP); when an incoming packet
matches more than one classification entry, tie-breaking criteria
should be specified (e.g., priority). Such tie-breaking criteria
should be instructed by the control plane.</t>
<t>The identification of instantiated SFCs/SFPs is local to each
administrative domain; it is policy-based and
deployment-specific.</t>
</section>
<section anchor="c2"
title="C2: Interface between SFC Control Plane & SFF">
<t>SFFs make traffic forwarding decisions according to the entries
maintained in their SFC forwarding policy table. Such table is
populated by the SFC control plane through the C2 interface.</t>
<t>This interface is used to instruct a SFF about the SFC-aware SFs
that it can service. This interface is also used by the SFF to
report the connectivity to their attached (including embedded) SFs.
Local means may be enabled between the SFC-aware SFs and SFFs to
allow for the dynamic attachment of SFs to a SFF and/or discovery of
SFs by a SFF but those means are unspecified in this document.</t>
<t>The C2 interface is also used for collecting states of attributes
(e.g., availability, workload, latency), for example, to dynamically
adjust Service Function Paths.</t>
</section>
<section anchor="c3"
title="C3: Interface between SFC Control Plane & SFC-aware SFs">
<t>The SFC control plane uses this interface to interact with
SFC-aware SFs.</t>
<t>SFs may need to output some processing results of packets to the
SFC control plane. This information can be used by the SFC control
plane to update the SFC classification rules and the SFC forwarding
policy table entries.</t>
<t>This Interface is used to collect such kind of feedback
information from SFs. For example, the following information can be
exchanged between a SF and the SFC control plane: <list
style="symbols">
<t>SF execution status: Some SFs may need to send information to
the control plane to fine tune SFPs. For example, a
threat-detecting SF can periodically send the threat
characteristics via this interface, such as high probability of
threat with packet of a given size. The control plane can then
add an appropriate matching criteria to SFF to steer traffic to
a scrubbing center.</t>
<t>SF load update: When SFs are under stress that yielded the
crossing of some performance thresholds, the SFC control plane
needs to be notified to adjust SFPs accordingly (especially when
the centralized path computation mode is enabled). It is out of
scope of this document to specify the exact methods to monitor
the performance threshold or stress level of SFs, nevertheless
the SFC control plane can invoke those methods for its
operations.</t>
</list></t>
<t>The SFC control needs the above status information for various
tasks it undertakes, but this information may be acquired directly
from SFs or indirectly from other management and control systems in
the operational environment.</t>
<t>This interface is also used to instruct an SFC-aware SF about any
context information it needs to supply in the context of a given
SFC.</t>
<t>Also, this interface informs the SFC-aware SF about the semantics
of a context information, which would otherwise have opaque meaning.
Several attributes may be associated with a context information such
as (but not limited to) the "scope" (e.g., per-packet, per-flow or
per host), whether it is "mandatory" or "optional" to process flows
bound to a given chain, etc. Note that a context may be mandatory
for "chain 1", but optional for "chain 2".</t>
<t>The control plane may indicate, for a given service function
chain, an order for consuming a set of contexts supplied in a
packet.</t>
<t>A SFC-aware SF can also be instructed about the behavior is
should adopt after consuming a context information that was supplied
in the SFC header. For example, the context can be maintained or
stripped. The SFC-aware SF can be instructed to inject a new context
header into the SFC header.</t>
<t>Multiple SFs may be located within the same physical node, and no
SFF is enabled in that same node, means to unambiguously forward the
traffic to the appropriate SF must be supported.</t>
<t>An SF can be instructed to strip the SFC information for the
chains it terminates.</t>
</section>
<section anchor="c4"
title="C4: Interface between SFC Control Plane & SFC Proxy">
<t>The SFC control plane uses this interface to interact with an SFC
Proxy.</t>
<t>The SFC proxy can be instructed about authorized SFC-unware SFs
it can service. A SFC Proxy can be instructed about the behavior it
should adopt to process the context information that was supplied in
the SFC header on behalf of a SFC-unware SF, e.g., the context can
be maintained or stripped.</t>
<t>The SFC proxy is also instructed about the semantics of a context
information, which would otherwise have opaque meaning. Several
attributes may be associated with a context information such as (but
not limited to) the "scope" (e.g., per-packet, per-flow or per
host), whether it is "mandatory" or "optional" to process flows
bound to a given chain, etc.</t>
<t>The SFC Proxy can also be instructed to add SF some new context
information into the SFC header on behalf of a SFC-unaware SF.</t>
<t>The C4 interface is also used for collecting attribute states
(e.g., availability, workload, latency), for example, to dynamically
adjust Service Function Paths.</t>
</section>
</section>
</section>
<section title="Additional Considerations">
<t></t>
<section title="Discovery of the SFC Control Element">
<t>SFC data plane functional elements need to be provisioned with the
locators of the Control Elements. This can be achieved using a variety
if mechanisms such as static configuration or the activation of a
service discovery mechanism. The exact specification of how this
provisioning is achieved is out of scope.</t>
</section>
<section title="SF Symmetry">
<t>Some SFs require both directions of a flow to traverse. Some
service function chains require full symmetry. If a SF (e.g., stateful
firewall or NAT) needs both direction of a flow, it is the SF
instantiation that needs both direction of a flow to traverse, not the
abstract SF (which can have many instantiations spread across the
network).</t>
</section>
<section title="Pre-deploying SFCs">
<t>Enabling service function chains should preserve some deployment
practices adopted by Operators. Particularly, installing a service
function chain (and its associated SFPs) should allow for
pre-deployment testing and validation purposes (that is a restricted
and controlled usage of such service function chain (and associated
SFPs)).</t>
</section>
<section title="Withraw a Service Function (SF)">
<t>During the lifetime of a SFC, a given SF can be decommissioned. To
accommodate such context and any other case where a SF is to be
withdrawn, the control plane should instruct the SFC data plane
functional element about the behavior to adopt. Particularly: <list
style="numbers">
<t>a first approach would be to update the service function chains
(and associated SFPs) where that SF is present by removing any
reference to that SF. Doing so avoids to induce service failures
for end users.</t>
<t>a second approach would be to delete/deactivate any service
function chain (and its associated SFPs) that involves that SF but
install new service function chains.</t>
</list></t>
</section>
<section title="SFC/SFP Operations">
<t>Various actions can be executed on a service function chain (and
associated SFPs) that is structured by the SFC Control &
Management planes. Indeed, a service function chain (and associated
SFPs) can be enabled, disabled, its structure modified by adding a new
SF hop or remove an SF from the sequence of SFs to be invoked, its
classification rules modified, etc.</t>
<t>A modification of a service function chain can trigger control
messages with the appropriate SFC-aware nodes accordingly.</t>
</section>
<section title="Unsolicited (Notification) Messages">
<t>Involved SFC data plane functional element must be instructed to
send unsolicited notifications when loops are detected, a problem in
the structure of a service function chain is encountered, a long
unavailable forwarding path time is observed, etc.</t>
<t>Specific criteria to send unsolicited notifications to a Control
Element should be fine tuned by the control plane using the interface
defined in <xref target="refint"></xref>.</t>
</section>
<section anchor="LiveD" title="SF Liveness Detection">
<t>The control plane must allow to detect the liveliness of SFs of an
SFC-enabled domain. In particular, it must allow to dynamically detect
that a SF instance is out of service and notify the relevant Control
Element elements accordingly. The liveness information may be acquired
directly from SFs or indirectly from other management and control
systems in the operational environment.</t>
<t>Liveness status records for all SF instances, and service function
chains (including the SFPs bound to a given chain) are maintained by
the SFC Control & Management.</t>
<t>The Classifier may be notified by the control plane or be part of
the liveness detection procedure.</t>
<t>The ability of a SFC Control Element to check the liveness of each
SF present in service function chain has several advantages,
including:<?rfc subcompact="yes" ?><list style="symbols">
<t>Enhanced status reporting by the control & management
planes (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 a
node embedding an SF, use alternate 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>Because a node embedding a SF 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.</t>
</section>
<section title="Monitoring & Counters">
<t>SFC-specific counters and statistics must be provided using the
interfaces defined in <xref target="refint"></xref>. These data
include (but not limited to): <?rfc subcompact="yes" ?><list
style="symbols">
<t>Number of flows ever and currently assigned to a given service
function chain and a given SFP.</t>
<t>Number of flows, packets, bytes dropped due to policy.</t>
<t>Number of packets and bytes in/out per service function
chain.</t>
<t>Number of flows, packets, bytes dropped due to unknown service
function chain (this is valid in particular for a SF node).<?rfc subcompact="no" ?></t>
</list></t>
</section>
<!-- <section title="SFC/SFP Diagnosis">
<t><list style="empty">
<t>[[Note: This section is expected to be removed once the working
group adopts a document on OAM.]]</t>
</list>The Control & Management planes should allow for the
following:<?rfc subcompact="yes" ?></t>
<t><list hangIndent="11" style="symbols">
<t>Assess the status of the serviceability of a SF (i.e., the SF
provides the service(s) it is configured for). Obviously, this
assessment must not rely only on IP reachability to decide whether
a SF is up and running.</t>
<t>Diagnose the availability of a SFC (including the availability
of a particular SFP bound to a given SFC).</t>
<t>Retrieve the set of service function chains that are enabled
within a domain.</t>
<t>Assess whether an SFC-enabled domain is appropriately
configured (including, check the configured chains are matching
what should be configured in that domain, and ensure coherent
classification rules are installed in and enforced by all the
Classifiers of the SFC-enabled domain).</t>
<t>Correlate classification policies with observed forwarding
actions (including, assess the output of the classification rule
applied on a packet presented to a Classifier of an SFC-enabled
domain).</t>
<t>Support the correlation between a service function chain and
the actual forwarding path followed by a packet matching that
service function chain.</t>
<t>Notify the SFC Control Element whenever some (critical) events
occur (for example, a malfunctioning SF instance).</t>
<t>Re-use SF built-in diagnostic procedures specific to each
SF.<?rfc subcompact="no" ?></t>
</list></t>
<t>The SFC control plane must be able to invoke SFC OAM mechanisms,
and to determine the results of OAM operations.</t>
</section>
-->
<section title="Validity Lifetime">
<t>SFC instructions communicated via the various interfaces introduced
in <xref target="refint"></xref> may be associated with validity
lifetimes, in which case classification entries will be automatically
removed upon the expiry of the validity lifetime without requiring an
explicit action from a Control Element.</t>
<t>Lifetimes are used in particular by an SFC data plane element to
clear invalid control entries that would be maintained in the system
if, for some reason, no appropriate action was undertaken by the
control plane to clear such entries.</t>
<t>Both short and long lifetimes may be assigned.</t>
</section>
<section title="Considerations Specific to the Centralized Path Computation Model">
<t>This section focuses on issues that are specific to the centralized
deployment model (<xref target="cd"></xref>).</t>
<section title="Service Function Path Adjustment">
<t>A SFP is determined by composing SF instances and overlay links
among SFFs. Thus, the status of a SFP depends on the states or
attributes (e.g., availability, topological location, latency,
workload, etc.) of its components. For example, failure of a single
SF instance results in failure of the whole SFP. Since these states
or attributes of SFP components may vary in time, their changes
should monitored and SFPs should be dynamically adjusted.</t>
<t>Examples of use cases for SFP adjustment are listed below:<?rfc subcompact="yes" ?></t>
<t><list style="hanging">
<t hangText="SFP fail-over: ">re-construct a SFP with replacing
the failed SF instance with another instance of the same SF.</t>
<t hangText="SFP with better latency experience:">re-construct a
SFP with a low path stretch considering the changes in
topological locations of SF instances and the latency induced by
the (overlay) connectivity among SFFs.</t>
<t hangText="Traffic engineered SFC:">re-construct SFPs to
localize the traffic in the network considering various TE goals
such as bypass a node, bypass a link, etc. These techniques may
be used for planned maintenance operations on a SFC-enabled
domain.</t>
<t hangText="SF/SFC Load balancing: ">re-construct SFPs to
distribute the workload among various SF instances.<?rfc subcompact="no" ?></t>
</list></t>
<t>For more details about the use cases, refer to <xref
target="I-D.lee-nfvrg-resource-management-service-chain"></xref>.</t>
<t>The procedures for SFP adjustment may be handled by the SFC
control plane as follows:<?rfc subcompact="yes"?></t>
<t><list style="symbols">
<t>Collect and monitor states and attributes of SF instances and
overlay links via the C2 interface (<xref target="c2"></xref>)
and the C3 interface (<xref target="c3"></xref>).</t>
<t>Evaluate SF instances and overlay links based on the
monitoring results.</t>
<t>Select SF instances to re-determine a SFP according to the
evaluation results.</t>
<t>Replace target SF instances (e.g., in a failure or overladed)
with newly selected ones.</t>
<t>Enforce the updated SFP for upcoming SFC traversal to SFFs
via the C1 interface (<xref target="c1"></xref>) or the C2
interface (<xref target="c2"></xref>).<?rfc subcompact="no"?></t>
</list></t>
</section>
<section title="Head End Initiated SFP Establishment">
<t>In some scenarios where a SFC Control Element is not connected to
all SFFs in a SFC-enabled domain, the SFC control plane can send the
explicit SFF-SF-sequence or SF-sequence to the SFC head-end, e.g.,
the SFC Classifier via the C1 interface (<xref target="c1"></xref>).
SFC head-end can use a signaling protocol to establish the
SFF-SF-sequence based on the SF-sequence.</t>
</section>
<section title="(Regional) Restoration of Service Functions">
<t>There are situations that it might not be feasible for the
Classifier to be notified of the changes of SFF-sequence or
SFF-SF-Sequence for a given SFP because of the time taken for the
notification and the limited capability of the Classifiers.</t>
<t>If a SF has a large number of instantiations, it scales better if
the Classifier doesn't need to be notified with status of visible
instantiations of SFs on a SFP.</t>
<t>It might not be always feasible for the Classifier to be aware of
the exact SF instances selected for a given SFP due to too many
instances for each SF, notifications not being promptly sent to the
Classifier, or other reasons. This is about multiple instances of
the same SF attached to one SFF node; those instances can be handled
by the SFF via local load balancing schemes.</t>
<t>Regional restoration can take the similar approach as the global
restoration: choosing a regional ingress node that can take over the
responsibility of installing the new steering policies to the
involved SFFs or network nodes. Typically, the regional ingress node
should be:<?rfc subcompact="yes" ?><list style="symbols">
<t>on the data path of the flow of the given SFC;</t>
<t>in front of the relevant SFFs or network nodes that are
impacted by the change of the SFP;</t>
<t>capable of encoding the detailed SFP to the Service Chain
Header of data packets of the identified flow; and</t>
<t>capable of removing the detailed SFP encoding in data packets
after all the impacted SFFs and network nodes completed the
policy installation. <?rfc subcompact="no" ?></t>
</list></t>
</section>
</section>
</section>
<section title="Security Considerations">
<t></t>
<section title="Secure Communications">
<t>The SFC Control Elements and the participating SFC data plane
elements must mutually authenticate. SFC data plane elements must
ignore instructions received from unauthenticated SFC Control
Elements. The credentials details used during authentication can be
used by the SFC control plane to decide whether specific authorization
may be granted to a Service Function with regards to some specific
operations (e.g., authorize a given SF to access specific context
information).</t>
<t>In case multiple SFC data plane elements are embedded in the same
node, the authentication mechanism may be executed as a whole; not for
each instance.</t>
<t>A SFC data plane element must be able to send authenticated
unsolicited notifications to a SFC Control Element.</t>
<t>The communication between a Control Element and SFC data plane
elements must provide integrity and replay protection.</t>
<t>An SFC Control Element may instruct a Service Function to include
specific security token(s) that may be used to decrypt traffic
upstream. The security token may be supplied by the SFC control plane
or by an authorized Service Function (e.g., TLS proxy). The exact
details on how authorization is granted to a specific SF, including
via a control plane interface, should be specified.</t>
<t>A Service Function must by default discard any action from a SFC
Control Element that requires specific right privileges (e.g., access
to a legal intercept log, mirror the traffic, etc.).</t>
</section>
<section title="Pervasive Monitoring">
<t>The authentication mechanism should be immune to pervasive
monitoring <xref target="RFC7258"></xref>. An attacker can intercept
traffic by installing classification rules that would lead to redirect
all or part of the traffic to an illegitimate network node. Means to
protect against attacks that would lead to install, remove, or modify
classification rules must be supported.</t>
</section>
<section title="Privacy">
<t>The SFC control plane must be able to instruct SFC data plane
elements about the information to be leaked outside an SFC-enabled
domain. Particularly, the SFC control plane must support means to
preserve privacy <xref target="RFC6973"></xref>. Context headers may
indeed reveal privacy information (e.g., IMSI, user name, user
profile, location, etc.). Those headers must not be exposed outside
the operator's domain.</t>
</section>
<section title="Denial-of-Service (DoS)">
<t>In order to protect against denial of service that would be caused
by a misbehaving trusted SFC Control Element, SFC data plane elements
should rate limit the messages received from an SFC Control
Element.</t>
</section>
<section title="Illegitimate Discovery of SFs and SFC Control Elements">
<t>Means to defend against soliciting illegitimate SFs/SFFs that do
not belong to the SFC-enabled domain must be enabled. Such means must
be defined in service function discovery and SFC Control Element
discovery specification documents.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document does not require any IANA actions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.I-D.ietf-sfc-architecture'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.7498'?>
<?rfc include='reference.I-D.lee-nfvrg-resource-management-service-chain'?>
<?rfc include='reference.I-D.lee-sfc-dynamic-instantiation'?>
<?rfc include='reference.I-D.ietf-sfc-use-case-mobility'?>
<?rfc include='reference.I-D.ietf-opsawg-firewalls'?>
<?rfc include='reference.I-D.ietf-sfc-dc-use-cases'?>
<?rfc include='reference.RFC.3135'?>
<?rfc include='reference.RFC.3022'?>
<?rfc include='reference.RFC.6333'?>
<?rfc include='reference.RFC.6146'?>
<?rfc include='reference.RFC.7258'?>
<?rfc include='reference.RFC.6973'?>
</references>
<section title="RSP-related Considerations">
<t>NOTE: This section records some contributions proposed by L. Dunbar
and A. Malis, but have not been discussed yet among authors.</t>
<section title="Encoding the Exact SFF-SF-sequence in Data Packets">
<t>Encoding the exact RSP in every packet has the benefit and the
issues associated with source routing. This approach may not be
optimal when the SFP doesn't change very frequently, as in minutes or
hours.</t>
<t>There are contexts that it might not be feasible for the head end
Classifier to be notified of the changes of SFF-sequence or
SFF-SF-Sequence for a given SFP because of the time taken for the
notification and the limited capability of the Classifier nodes.</t>
</section>
<section title="Fully Controlled SFF-SF-Sequence for a SFP">
<t>This section describes the information that can be exchanged over
C2 interface (<xref target="c2"></xref>) when the SFC Control Element
explicitly passes the steering policies to all SFFs for the
SFF-SF-Sequence of a given SFC. In this model, each SFF doesn't need
to signal other SFFs for the SFP.</t>
<t>Suppose the SFC ID for this SFP is “yellow”, an example
of policy to “sff-a” is depicted in <xref
target="rsp"></xref> (for illustration proposes)</t>
<t><figure anchor="rsp"
title="Example of Traffic Steering Policy to a SFF node">
<artwork><![CDATA[ Matching | Action
----------------------------------------+-------------------------
SFC ID = "yellow" & ingress = sffx-port | next-hop: "sf2" & VID
SFC ID = "yellow" & ingress = sf2-port | next-hop: "sf3" & VID
SFC ID = "yellow" & ingress = sf3-port | next-hop: sff-b ]]></artwork>
</figure></t>
<t>The SFF nodes may not be directly adjacent to each other. They can
be interconnected by tunnels, such as GRE, VxLAN, etc. SFs are
attached to a SFF node or SFC Proxy node via Ethernet link or other
link types. Therefore, the steering policies to a SFF node for service
function chain depends on if the packet comes from previous SFF or
comes from a specific SF, i.e., the SFC Forwarding Policy Table
entries have to be ingress port specific. There are multiple different
steering policies for one flow within one SFF and each set of steering
policies is specific for an ingress port.</t>
<t>The semantics of traffic steering rules can be "Match" and
"Action", similar to the "route" described in
[I-D.ietf-i2rs-rib-info-model]. The “match” and
“action” for distinct ports can be different. The matching
criteria for SFF can be more sophisticated. For example, the matching
criteria could be any fields in the data packets: <?rfc subcompact="yes"?><list
style="symbols">
<t>Ingress port</t>
<t>Destination MAC address</t>
<t>Source MAC address</t>
<t>VLAN_id,</t>
<t>Destination IP address</t>
<t>Source IP address</t>
<t>Source port number</t>
<t>Destination port number</t>
<t>DSCP</t>
<t>Packet size, etc., or any combination thereof.</t>
</list></t>
<t><?rfc subcompact="no"?>A SFF node may not support some of the
matching criteria listed above. It is important that SFC control plane
can retrieve the supported matching criteria by SFF nodes. The
“Actions” for traffic steering could be to steer traffic
to the attached service function or SF instantiations via a specific
port.</t>
<t>The “Actions” to SFC Proxy may include a method to map
the SFC Identifier carried in the packet header to a locally
significant link identifier, e.g., VLAN-ID, and a method to construct
and encapsulate the SFC header back to the packets when they come back
from the attached SFs.</t>
<t>This approach does not require using an end-to-end signaling
protocol among Classier nodes and SFF nodes. However, there may be
problems encountered if SFF nodes are not updated in the proper order
or not at the same time. For example, if the SFF “A” and
SFF “C” get flow steering policies at slightly different
times, some packets might not be directed to some service functions on
a chain.</t>
</section>
</section>
<section numbered="no" title="Acknowledgments">
<t>This document is the result of merging with <xref
target="I-D.lee-sfc-dynamic-instantiation" />.</t>
<t>The authors would like to thank Shibi Huang and LAC Chidung for the
review and comments.</t>
<t>The text about the semantic of a context information is provided by
Dave Dolson.</t>
</section>
<section numbered="no" title="Contributors">
<t>Many thanks to the following people for contributing text to the
document: <?rfc subcompact="yes" ?> <list style="symbols">
<t>tbc</t>
</list></t>
<?rfc subcompact="no" ?>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 16:22:43 |