One document matched: draft-boucadair-sfc-requirements-04.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="info" docName="draft-boucadair-sfc-requirements-04"
ipr="trust200902">
<front>
<title abbrev="SFC Requirements">Requirements for Service Function
Chaining (SFC)</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="Yuanlong Jiang" initials="Y." surname="Jiang">
<organization>Huawei Technologies Co., Ltd.</organization>
<address>
<postal>
<street>Bantian, Longgang district</street>
<city>Shenzhen 518129,</city>
<region></region>
<code></code>
<country>China</country>
</postal>
<email>jiangyuanlong@huawei.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="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>
<author fullname="Kengo Naito" initials="K." surname="Naito">
<organization>NTT</organization>
<address>
<postal>
<street>Midori-Cho 3-9-11</street>
<city>Musashino-shi, Tokyo 180-8585</city>
<region></region>
<country>Japan</country>
</postal>
<email>naito.kengo@lab.ntt.co.jp</email>
</address>
</author>
<date day="04" month="April" year="2014" />
<workgroup>SFC</workgroup>
<abstract>
<t>This document identifies the requirements for the Service Function
Chaining (SFC).</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>This document identifies the requirements for the Service Function
Chaining (SFC). In particular:</t>
<t><list style="numbers">
<t>Generic requirements are listed in <xref
target="gen"></xref>.</t>
<t>SFC diagnostic requirements are discussed in <xref
target="diag"></xref>.</t>
<t>Security-specific requirements are listed in <xref
target="Security"></xref>.</t>
</list></t>
<t>The overall problem space is described in <xref
target="I-D.ietf-sfc-problem-statement"></xref>.<!--[[Service Function Discovery has been removed as per as comment from J. Halper. The issue can be revived in the future to have more feedback
REQ#29: Means to dynamically discover Service Functions SHOULD be
supported.
]]--></t>
</section>
<section title="Terminology">
<t>The reader should be familiar with the terms defined in <xref
target="I-D.ietf-sfc-problem-statement"></xref>.</t>
<t>The document makes use of the following terms:</t>
<t><list style="symbols">
<t>SFC-enabled domain: denotes a network (or a region thereof) that
implements SFC.</t>
<t>Service Function Loop: If a Service Function Chain is structured
to not invoke Service Functions multiple times, a loop is the error
that occurs when the same Service Function is invoked several times
when handling data bound to that Service Function Chain. In other
words, a loop denotes an error that occurs when a packet handled by
a Service Function, forwarded onwards, and arrives once again at
that Service Function while this is not allowed by the Service
Function Chain it is bound to.</t>
<t>Service Function Spiral: denotes a Service Function Chain in
which data is handled by a Service Function, forwarded onwards, and
arrives once again at that Service Function. <list style="symbols">
<t>Note that some Service Functions support built-in functions
to accommodate spirals; these service-specific functions may
require that the data received in a spiral should differ in a
way that will result in a different processing decision than the
original data. This document does not make such assumption.</t>
<t>A Service Function Chain may involve one or more Service
Function Spirals.</t>
<t>Unlike Service Function loop, spirals are not considered as
errors.</t>
</list></t>
</list></t>
</section>
<section anchor="gen" title="Detailed Requirements List">
<t>The following set of functional requirements should be considered for
the design of the Service Function Chaining solution:<?rfc subcompact="no" ?><list
hangIndent="9" style="format REQ#%d:">
<t>The solution MUST NOT make any assumption on whether Service
Functions (SF) are deployed directly on physical hardware, as one or
more Virtual Machines, or any combination thereof.</t>
<t>The solution MUST NOT make any assumption on whether Service
Functions each reside on a separate addressable Network Element, or
as a horizontal scaling of Service Functions, or are co-resident in
a single addressable Network Element, or any combination thereof.
<list hangIndent="11" style="empty">
<t>Note: Communications between co-located Service Functions are
considered implementation-specific. These considerations are
therefore out of scope of the SFC specification effort.</t>
</list></t>
<t>The solution MUST NOT require any IANA registry for Service
Functions.</t>
<t>The solution MUST NOT assume any predefined order of Service
Functions. In particular, the solution MUST NOT require any IANA
registry to store typical Service Function Chains.</t>
<t>The identification of instantiated Service Function Chains is
local to each administrative domain; it is policy-based and
deployment-specific.</t>
<t>The solution MUST allow multiple instances of a given Service
Function ( i.e., a Service Function can be embedded in multiple
Network Elements).<list hangIndent="11" style="letters">
<t>This is used for load-balancing, load-sharing, to minimize
the impact of failures (e.g., by means of a hot or cold standby
protection design), to accommodate planned maintenance
operations, etc.</t>
<t>How these multiple devices are involved in the service
delivery is deployment-specific.</t>
</list></t>
<t>The solution MUST allow for multiple Service Chains to be
simultaneously enforced within an administrative domain.</t>
<t>The solution MUST allow the same Service Function to belong to
multiple Service Function Chains.</t>
<t>The solution MUST support the ability to deploy multiple
SFC-enabled domains within the same administrative domain.</t>
<t>The solution MUST be able to associate the same or distinct
Service Function Chains for each direction (inbound/outbound) of the
traffic pertaining to a specific service. In particular,
unidirectional Service Function Chains, bi-directional Service
Function Chains, or any combination thereof MUST be supported.<list
style="empty">
<t>Note, the solution must allow to involve distinct SFC
Boundary Nodes for upstream and downstream. Multiple SFC
Boundary Nodes may be deployed within an administrative
domain.</t>
</list></t>
<t>The solution MUST be able to dynamically enforce Service Function
Chains. In particular, the solution MUST allow the update or the
withdrawal of existing Service Function Chains, the definition of a
new Service Function Chain, the addition of new Service Functions
without having any impact on other existing Service Functions or
other Service Function Chains.</t>
<t>The solution MUST provide means to control the SF-inferred
information to be leaked outside an SFC-enabled domain. In
particular, an administrative entity MUST be able to prevent the
exposure of the Service Function Chaining logic and its related
policies outside the administrative domain.</t>
<t>The solution SHOULD minimize fragmentation; in particular, a
minimal set of SFC-specific information should be conveyed in the
data packet.<list style="letters">
<t>Traffic forwarding on a SFC basis MUST be undertaken without
relying on dedicated resources to treat fragments. In
particular, Out of order fragments MUST be forwarded on a
per-SFC basis without relying on any state.</t>
<t>Of course, some SFs (e.g., NAT) may require dedicated
resources (e.g., resources to store fragmented packets) or they
may adopt a specific behavior (e.g, limit the time interval to
accept fragments). The solution MUST NOT interfere with such
practices.</t>
</list></t>
<t>The solution MUST NOT make any assumption on how RIBs (Routing
Information Bases) and FIBs (Forwarding Information Bases) are
populated. Particularly, the solution does not make any assumption
on protocols and mechanisms used to build these tables.</t>
<t>The solution MUST be transport independent.<list hangIndent="11"
style="letters">
<t>The Service Function Chaining should operate regardless of
the network transport used by the administrative entity. In
particular, the solution can be used whatever the switching
technologies deployed in the underlying transport
infrastructure.</t>
<t>Techniques such as MPLS are neither required nor
excluded.</t>
</list></t>
<t>The solution MUST allow for chaining logics where involved
Service Functions are not within the same layer 3 subnet.</t>
<t>The solution MUST NOT exclude Service Functions to be within the
same IP subnet (because this is deployment-specific).</t>
<t>The solution MUST NOT make any assumption on how the traffic is
to be bound to a given chaining policy. In other words,
classification rules are deployment-specific and policy-based. 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. <list style="letters">
<t>The solution SHOULD accommodate a large number of
classification policy entries.</t>
<t>In order to reduce classification look-up time, means to
optimize the size of the classification table (e.g.,
aggregation) SHOULD be supported by the Classifier.</t>
</list></t>
<t>The solution MUST support traffic classification capabilities
according to the Service Function Chains supported within the SFC
domain.</t>
<t>The solution MUST NOT require every Service Function to be
co-located with a SFC Classifier; this is a deployment-specific
decision.<list style="letters">
<t>The solution MAY allow traffic re-classification at the level
of Service Functions (i.e., a Service Function can also be
co-located with a classifier). The configuration of
classification rules in such context are the responsibility of
the administrative entity that operates the SFC-enabled
domain.</t>
</list></t>
<t>The solution MUST be able to forward traffic between two Service
Functions (involved in the same Service Function Chain) without
relying upon the destination address field of the a data packet.</t>
<t>The solution MUST allow for the association of a context with the
data packets. In particular:<list hangIndent="11" style="letters">
<t>The solution MUST support the ability to invoke
differentiated sets of policies for a Service Function (such
sets of policies are called Profiles). A profile denotes a set
of policies configured to a local Service Function (e.g.,
content-filter-child, content-filter-adult).<list
hangIndent="11" style="letters">
<t>Few profiles should be assumed per Service Function to
accommodate the need for scalable solutions.</t>
<t>A finer granularity of profiles may be configured
directly to each Service Function; there is indeed no need
to overload the design of Service Function Chains with
policies of low-level granularity.</t>
</list></t>
</list></t>
<t>The solution MUST allow for Operations, Administration, and
Maintenance (OAM) features <xref target="RFC6291"></xref>. In
particular, the solution MUST:<list hangIndent="11" style="letters">
<t>Support means to verify the completion of the forwarding
actions until the SFC Border Node is reached (see Section 3.4.1
of <xref target="RFC5706"></xref>).</t>
<t>Support means to ensure coherent classification rules are
installed in and enforced by all the Classifiers of the SFC
domain.</t>
<t>Support means to correlate classification policies with
observed forwarding actions.</t>
<t>Support in-band liveliness and functionality checking
mechanisms for the instantiated Service Function Chains and the
Service Functions that belong to these chains.</t>
</list></t>
<t>The solution MUST prevent infinite Service Function Loops.<list
hangIndent="11" style="letters">
<t>Service Functions MAY be invoked multiple times in the same
Service Function Chain (denoted as SF Spiral), but the solution
MUST prevent infinite forwarding loops.</t>
</list></t>
<t>The solution MUST allow for load-balancing.<list hangIndent="11"
style="letters">
<t>Load-balancing may be provided by legacy technologies or
protocols (e.g., make use of load-balancers)</t>
<t>Load-balancing may be part of the Service Function
itself.</t>
<t>Load-balancer may be considered as a Service Function
element.</t>
<t>Because of the possible complications, load balancing SHOULD
NOT be driven by the SFC Classifier.</t>
</list></t>
<t>The solution MUST separate SF-specific policy
provisioning-related aspects from the actual handling of packets
(including forwarding decisions).</t>
<t>The solution MUST support means to detect the liveliness of
Service Functions of an SFC-enabled domain. In particular, the
solution MUST support means to (dynamically) detect that a Service
Function instance is out of service and notify the relevant elements
accordingly (PDP and Classifiers, for one).</t>
<t>Service Functions may be reachable using IPv4 and/or IPv6. The
administrative domain entity MUST be able to define and enforce
policies with regards to the address family to be used when invoking
a Service Function. <list hangIndent="11" style="letters">
<t>A Service Function Chain may be composed of IPv4 addresses,
IPv6 addresses, or a mix of both IPv4 and IPv6 addresses.</t>
<t>Multiple Service Functions can be reachable using the same IP
address. Each of these Service Functions is unambiguously
identified with a Service Function Identifier.</t>
</list></t>
<t>The solution MUST allow for gradual deployment in legacy
infrastructures, and therefore coexist with legacy technologies that
cannot support SFC-specific capabilities, such as Service Function
Chain interpretation and processing. The solution MUST be able to
work in a domain that may be partly composed of opaque elements,
i.e., elements that do not support SFC-specific capabilities.</t>
<t>The solution MUST be able to provide different SLAs (Service
Level Agreements, <xref
target="I-D.boucadair-connectivity-provisioning-profile"></xref>).
In particular,<list style="letters">
<t>The solution MUST allow for different levels of service to be
provided for different traffic streams (e.g., configure Classes
of Service (CoSes)).</t>
<t>The solution MUST be able to work properly within a Diffserv
domain <xref target="RFC2475"></xref>.</t>
<t>The solution SHOULD support the two modes defined in <xref
target="RFC2983"></xref>.</t>
</list></t>
<t>ECN re-marking, when required, MUST be performed according to
<xref target="RFC6040"></xref>.</t>
</list><?rfc subcompact="no" ?></t>
</section>
<section anchor="diag" title="SFC Diagnosis & Troubleshooting">
<t>This section lists the set of requirements for the SFC Diagnosis
& Troubleshooting procedure (denoted hereafter as "the
solution").<list hangIndent="15" style="format DIAG_REQ#%d:">
<t>The solution MUST allow to assess the status of the
serviceability of a Service Function (i.e., the Service Function
that provides the service(s) it is configured for).</t>
<t>The solution MUST NOT rely only on IP reachability to assess
whether a Service Function is up and running.</t>
<t>The solution MUST allow to diagnose the availability of a Service
Function Chain.</t>
<t>The solution MUST support the correlation between a Service
Function Chain and the actual forwarding path followed by a packet
matching that SFC.</t>
<t>The solution MUST allow to diagnose the availability of a segment
of a Service Function Chain, i.e., a subset of service functions
that belong to the said chain.</t>
<t>The solution MUST support the unsolicited notification of signals
as a means to notify the PDPs whenever some events occur (for
example, a malfunctioning service function instance).</t>
<t>The solution MUST allow for local diagnostic procedures specific
to each Service Function. <list style="symbols">
<t>In particular, the solution MUST allow to make use of local
diagnostic procedures (e.g., regular checks using SF built-in
diagnostic procedures) for SFC diagnosis purposes.</t>
</list></t>
<t>The solution MUST allow for customized service diagnostic. <list
style="symbols">
<t>For example, the solution should be able to generate a test
packet as per a customer's request who may have observed some
service degradation.</t>
</list></t>
</list></t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document does not require any action from IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Below are listed some security-related requirements to be taken into
account when designing the Service Function Chaining solution. This
version does not cover the provisioning interface used to enforce
policies into the Classifier and Service Functions.</t>
<t><list hangIndent="12" style="format SEC_REQ#%d:">
<t>The solution MUST provide means to prevent any information
leaking that would be used as a hint to guess internal engineering
practices (e.g., network topology, service infrastructure topology,
hints on the enabled mechanisms to protect internal service
infrastructures, etc.).<list style="empty">
<t>The solution MUST support means to protect the SFC domain as
a whole against attacks that would lead to the discovery of
Service Functions enabled in a SFC domain.</t>
<t>In particular, topology hiding means MUST be supported to
avoid the exposure of the SFC-enabled domain topology (including
the set of the service function chains supported within the
domain and the corresponding Service Functions that belong to
these chains).</t>
</list></t>
<t>The solution MUST support means to protect the SFC-enabled domain
against any kind of denial-of-service and theft of service (e.g.,
illegitimate access to the service) attack. <list style="empty">
<t>For example, a user should not be granted access to
connectivity services he/she didn't subscribe to (including
direct access to some SFs), at the risk of providing
illegitimate access to network resources.</t>
</list></t>
<t>The solution MUST NOT interfere with IPsec <xref
target="RFC4301"></xref> (in particular IPsec integrity checks).</t>
</list></t>
</section>
<section title="Contributors">
<t>The following individuals contributed text to the document:<figure>
<artwork><![CDATA[ Hongyu Li
Huawei Technologies Co., Ltd.
Bantian, Longgang district
Shenzhen 518129,
China
EMail: hongyu.lihongyu@huawei.com
Jim Guichard
Cisco Systems, Inc.
USA
EMail: jguichar@cisco.com
Paul Quinn
Cisco Systems, Inc.
USA
Email: paulq@cisco.com]]></artwork>
</figure></t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks to K. Gray, N. Takaya, H. Kitada, H. Kojima, D. Dolson,
B. Wright, and J. Halpern for their comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.6291'?>
<?rfc include='reference.I-D.boucadair-connectivity-provisioning-profile'?>
<?rfc include='reference.RFC.6040'?>
<?rfc include='reference.RFC.2475'?>
<?rfc include='reference.RFC.4301'?>
<?rfc include='reference.RFC.2983'?>
<?rfc include="reference.I-D.ietf-sfc-problem-statement"?>
<?rfc include='reference.RFC.5706'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:22:08 |