One document matched: draft-boucadair-sfc-requirements-00.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-00"
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>
<date day="03" month="October" year="2013" />
<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).</t>
<t>The overall problem space is described in <xref
target="I-D.quinn-nsc-problem-statement"></xref>. The Service Function
Chaining Framework is documented in <xref
target="I-D.boucadair-service-chaining-framework"></xref>.</t>
</section>
<section title="Terminology">
<t>The reader should be familiar with the terms defined in <xref
target="I-D.boucadair-service-chaining-framework"></xref> and <xref
target="I-D.quinn-nsc-problem-statement"></xref>.</t>
</section>
<section 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,
horizontal scaling of Service Functions, are co-resident on a single
addressable Network Element, or any combination thereof. <list
hangIndent="11" style="empty">
<t>Note: Communications between Service Functions co-resident on
same Network Element are considered implementation-specific.
These considerations are 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 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, prevent from
failures (e.g., hot or cold standby protection mechanism),
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 be involved
in multiple Service Function Chains.</t>
<t>The solution MUST support multiple SFC-enabled domains be
deployed 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. In particular, unidirectional Service Function Chains,
bi-directional Service Function Chains, or any combination thereof
MUST be supported.</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 Service
Function Chaining logic and related policies from being exposed
outside its 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>The per-SF Map forwarding MUST be undertaken without relying
on dedicated resources to treat fragments. In particular, Out of
order fragments MUST be forwarded on a per-SF Map 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
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 (this is deployment-specific).</t>
<t>An administrative entity, grouping its Service Functions within
the same IP subnet, SHOULD be able to avoid encapsulation overhead
.</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 classifying traffic into Service
Function Chains.</t>
<t>The solution MUST NOT require every Service Function be
co-located with a SFC Classifier; this is a deployment-specific
decision.</t>
<t>The solution MAY allow reclassification at the 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 managing that
SFC-enabled domain.</t>
<t>The solution MUST be able to forward the traffic between two
Service Functions (involved in the same Service Function Chain)
without relying on the original destination address in 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 (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>Finer-grained of policies should be configured directly
to each Service Function; 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, <list hangIndent="11" style="letters">
<t>Support means to verify the completion of the forwarding
actions derived from the contents of the SF Map until the 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 to all SFC Classifiers.</t>
<t>Support means to correlate between the classification
policies and observed forwarding actions.</t>
<t>Support in-band liveness and functionality checking of
instantiated Service Function Chains.</t>
</list></t>
<t>The solution MUST prevent the same Service Function to be invoked
multiple times in 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 provisioning-related aspects from the
actual handling of packets (including forwarding decisions).</t>
<t>The solution SHOULD means to detect the liveness 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 traffic streams (e.g., configure Classes of Service
(CoSes)).</t>
<t>The solution MUST be compatible with Diffserv <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="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 leaking any
information 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 supported to avoid
exposing the topology of an SFC-enabled domain (including the
set of involved Service Functions).</t>
</list></t>
<t>The solution MUST support means to defend against
denial-of-service and theft of service (e.g., illegitimate access to
the service). <list style="empty">
<t>For example, a user should not be granted access to
connectivity services it didn't subscribed to such as
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 for his review.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.boucadair-service-chaining-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.quinn-nsc-problem-statement"?>
<?rfc include='reference.RFC.5706'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 15:42:00 |