One document matched: draft-boucadair-sfc-requirements-03.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-03"
ipr="trust200902">
<front>
<title abbrev="SFC Requirements">Requirements for Service Function
Chaining</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="12" month="February" 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>Service Function Discovery requirements are discussed in <xref
target="disc"></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>.</t>
</section>
<section title="Terminology">
<t>The reader should be familiar with the terms defined in <xref
target="I-D.boucadair-sfc-framework"></xref> and <xref
target="I-D.ietf-sfc-problem-statement"></xref>.</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.</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.</t>
<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>
<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 the same Service Function to be invoked
multiple times within the context of the same Service Function Chain
(at the risk of generating Service Function Loop).</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 SHOULD support means to detect the liveliness of
involved Service Functions.</t>
<t>Means to dynamically discover Service Functions SHOULD be
supported.</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 SF Map 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 SFC Map
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="disc" title="Service Function Discovery">
<t>This section lists the set of requirements for the Service Function
Discovery procedure (denoted hereafter as "the solution").</t>
<t><list hangIndent="13" style="format DISC_REQ#%d:">
<t>The solution MUST use the Service Function Identifier as a unique
identifier that unambiguously distinguishes a Service Function among
the set of Service Functions enabled in a given SFC domain.</t>
<t>The solution MUST NOT make any assumption on how a Service
Function Identifier is configured and associated to a given Service
Function.</t>
<t>The solution MUST allow for the dynamic discovery of all
locations where a given Service Function may reside and be invoked
for a given SF chain. Particularly, the solution MUST allow for the
dynamic discovery of both IPv4 and IPv6 locators of a Service
Function instance.</t>
<t>The solution SHOULD allow the dynamic discovery of additional
information characterizing a Service Function, including:<list
style="symbols">
<t>The capabilities of the Service Function.</t>
<t>The capacity of the Service Function. For example, this
information can refer to the maximum number of binding entries
that can be supported by a NAT function, the maximum number of
IP-in-IP tunnels that can be established, the maximum link
capacity, etc.</t>
<t>The current load of the Service Function. This information
may be used for load-balancing purposes for instance. This
parameter may reflect the amount of active NAT entries, the
number of active IP-in-IP tunnel, the link capacity usage,
etc.</t>
</list></t>
<t>The solution MUST support means to protect the SFC domain as a
whole against attacks that would lead to the discovery of an
illegitimate Service Function. For example, a Service Function that
cannot be invoked for a specific SF chain.</t>
<t>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>The solution MUST allow a Service Function instance to
dynamically announce scheduled periods of unavailability (for
maintenance purposes, for example). The support of this capability
is useful for instance to migrate traffic to another instance of the
same Service Function so as to minimize service disruption. Note
also that operational teams proceed to regular reboots of
operational devices (for major software upgrades, for example).
Dynamically advertising such events to inform the PDP that a Service
Function instance will not be available during the reboot of the
device, would be useful. Means to indicate whether the Service
Function will be available immediately after the reboot or not are
RECOMMENDED. Indeed, such information will be used as an input to
the decision-making process of the PDP to avoid any subsequent
traffic forwarding policy changes at the risk of service
disruption.</t>
<t>The solution MAY allow for a Service Function to dynamically
discover its PDP.</t>
</list></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 be able to analyze the outcomes of the
processing of a test packet when presented to a given Service
Function for diagnosis purposes.</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.</t>
<t>The solution MUST allow to make use of local diagnostic
procedures (e.g., regular checks using built-in diagnostic
procedures).</t>
<t>The solution MUST allow for customized service diagnostic. 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>
</section>
<section title="Scalability Considerations">
<t>Designing the SFC solution to accommodate per-subscriber SFCs rather
than SFCs on a per group of subscribers basis, should be conditioned by
the outcomes of assessing the validity of use cases requiring such
per-subscriber SFC feature. Note, instantiating per-subscriber SFCs
would mean that millions of SFCs would need be to handled within an
SFC-enabled domain!</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>Authors of this document do 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:</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>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, and H. Kojima for their
comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.boucadair-sfc-framework"?>
<?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-23 10:57:46 |