One document matched: draft-ww-sfc-control-plane-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<!-- 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 category="std" docName="draft-ww-sfc-control-plane-02" ipr="trust200902">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<front>
<title abbrev="SFC CP">Service Function Chain Control Plane
Framework</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="Huang(Oliver) Huang" initials="H." 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" 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>
<date year="2014"/>
<area/>
<workgroup/>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword/>
<abstract>
<t>As described in [I.D-boucadair-sfc-framework], the dynamic
enforcement of a Service-derived, adequate forwarding policy for packets
entering a network that supports such advanced Service Functions has
become a key challenge for operators and service providers.</t>
<t>This document is based on [I.D-boucadair-sfc-framework] and discusses
how the Service Functions chain is structured and how Service Function
Chaining path is provisioned and setup.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Service Function Chaining(SFC) refers to the delivery of added value
services by invoking, in a given order, a set of Service Functions along
the forwarding path towards a specific destination [I.D-quinn-
sfc-problem-statement]. Service functions involved in a given SFC may
include advanced Service Functions such as load-balancing, firewalling,
intrusion prevention. A given SFC domain may involve several instances
of the same Service Functions. Service Function instances can be
automatically added to or removed from a given SFC. Service functions
can be co-located or embedded in distinct physical nodes, or
virtualized.</t>
<t>As described in [I.D-boucadair-sfc-framework], the dynamic
enforcement of a SF-derived, adequate forwarding policy for packets
entering a network that supports such advanced Service Functions has
become a key challenge for operators and service providers.</t>
<t>This document is based on [I.D-boucadair-sfc-framework] and discusses
how the Service Function Chains are structured and how Service Function
Chaining path is provisioned and setup.</t>
</section>
<section title="Conventions used in this document">
<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">RFC2119</xref>.</t>
</section>
<section title="Data plane basic assumption">
<t>The control plane framework described in this document applies to SFC
architectures defined by [ID Jiang-SFC-ARCH], [ID Boucadair-SFC-
framework]and [ID Quinn-SFC-ARCH].</t>
<t>The SFC data plane characteristics considered as basic assumptions by
the SFC control framework are summarized below: <list style="symbols">
<t>Traffic that enters a SFC domain is firstly classified according
to the rules provided to the classifier node by the PDP, and then
forwarded into the SFC domain according to the various Service
Functions that need to be invoked, as per the corresponding SFC
instructions. SFC-specific forwarding information is used by service
function nodes to make traffic forwarding decisions, according to
the contents of the chain. That is, traffic is forwarded to the SF
Node that embeds the next SF function to invoke. Classification in
the SCLA is done according to a set of classification rules that are
provided by the PDP.</t>
<t>The Service Node forwards packets according to the entries
maintained in the SFC Policy Table. A Service Node can be a L2/L3
network device that embeds SF functions that can be invoked for a
given chain. A Service node may embed one or more Service Functions
(Fig. 1).</t>
<t>When a Service node needs to forward a packet to a node that
cannot process SFC-specific information as carried in the packet,
the packet is usually forwarded to a SFC proxy.</t>
</list></t>
</section>
<section title="SFC Control Plane Overview">
<t>For the purpose of defining the SFC control plane framework, the
control plane PDP is broken up into five distinct components<list
style="hanging">
<t hangText="Policy"><vspace blankLines="1"/>Maintains SFC-related
policy provisioning information (chain structures, classification
rules) and possibly other information (e.g., information that
pertains to user data and services).<vspace blankLines="1"/></t>
<t hangText="Meta Data"><vspace blankLines="1"/>May include
Subscriber profile, access network type, network load, etc.
Subscriber attributes may include access bandwidth (e.g.,
512K,1M,2M,4M), QoS level (e.g., Gold, Silver, Bronze), access
line/cell id, payment status, Radio Access Technology (RAT)
(GPRS,UMTS,HSPA,LTE), etc. Subscriber attributes may vary frequently
and the control plane PDP therefore needs to be informed about such
modification in a timely manner. <vspace blankLines="1"/></t>
<t hangText="Service Template Profile"><vspace
blankLines="1"/>Include service function template and service chain
template.<vspace blankLines="1"/></t>
<t hangText="Path management"><vspace blankLines="1"/>This component
is used to map a service function chain to a forwarding path, in
case the said forwarding path is PDP-computed and traffic engineered
[I.D-wu-pce-traffic-steering-sfc].<vspace blankLines="1"/></t>
<t hangText="Chain management"><vspace blankLines="1"/>This is the
component that helps the PDP dynamically structure a SFC chain,
based upon various inputs that include service function information
as collected through the management interface (e.g., the outcomes of
a negotiation between a customer and a service provider, as
documented in RFC7297). <vspace blankLines="1"/></t>
</list></t>
<figure align="left" anchor="fig-1" title="SFC Control Plane Overview">
<artwork>
+--------------------------------------+
| PDP |
| +-------+ +----------+ +----------+ |
| |Policy | | Service | |Meta Data | |
| +-------+ | template | | | |
| +---------++----------+ +----------+ |
| | Path | +-----------+ |
+-------+-|Management | Chain | |
| | +---------+ | Management| |
| +---+ +-----------+ +
| | | |
C1 C1 +------^--^--------------^--^----------+
| | | | C2 | | C2
| | F| F| |Service F| F| | Service
| | | | | Node1 | | | Node2
+----V---V--+ +-+--+--V-+ +--+--+-V-+
|SFC Ingress| | | | | | | | |
| Node |---->| |----->| | | |
(Classifier)|<----|SF1 SF2 |<---- | |
+-----------+ | | |SF3 SF4 |
+---------+ +---------+
</artwork>
</figure>
<t>There are three interfaces connected to the Control Plane PDP.<list>
<t>C1 Interface: the interface between the control plane PDP and the
Service Classifier (SCLA). Classification rules are installed on the
SCLA via this interface. In addition, this interface can be used by
the Path management component to trigger the dynamic computation and
selection of traffic-engineered paths that will be used to forward
traffic according to SFC information.</t>
<t>C2 Interface: the interface between the control plane PDP and the
Service node. SFC-based forwarding entries on service nodes are
provided by the PDP via this interface.</t>
<t>F Interface: This interface is used by service functions to
feedback service or application level information of a dataflow to
the control plane PDP.</t>
</list></t>
<section title="Control plane PDP">
<t>The control plane PDP is in charge of service function chain
creation and maintenance, service chain path instantiation (in case
the PDP is involved in the dynamic SFC path computation and
selection), mapping between SFC and service function path, SFC Policy
Table creation and configuration, including the sequence of SFs in a
service function chain, SF information, SFC paths and metadata.</t>
<t>The control plane PDP may be fed with service function chain
information from the Management application. A SFC service template
information may look like: <list>
<t>{{MBR>1Mbps, RAT='UMTS', protocol='HTTP',
QOS='Gold'},goto'sfc1'}</t>
</list></t>
<t>The control plane PDP may combine the management plane-originated
information with subscriber attributes provided by the metadata
component. The PDP also creates classification rules and installs them
on the classifier nodes. The control plane PDP also assigns SFC
identification and installs SFC Policy Tables in the Service
Nodes.</t>
</section>
<section title="F interface">
<t>Service functions, e.g., deep packet inspection (DPI) or firewall
may need to output some processing results of packets to the control
system. This information can be used by the control plane PDP to
update the SFC classification rules and SFC forwarding entries.</t>
<t>The F Interface is used to collect such kind of feedback
information from the service functions or the SF nodes.</t>
</section>
<section title="C1 interface">
<t>This interface is used to install SFC classification rules in
Service Classifier(SCLA) nodes. These rules are created by the SFC
control Plane PDP. These rules may be updated by information provided
by the Service Nodes (in case a change of the network topology has
occurred, for example). </t>
<t>SCLA binds incoming traffic to SFCs according to these
classification rules.</t>
</section>
<section title="C2 interface">
<t>Service Nodes make traffic forwarding decisions according to the
entries maintained in their SFC Policy Table. Such Table is populated
by the control plane PDP through the C2 interface.</t>
<t>Each SF has a unique service function identifier to identify itself
in the SFC forwarding plane. The locator is typically referred to as a
network address. In case the SF instance is directly connected to a
Service node, the forwarding entry may also include the port through
which the SF instance can be reached.</t>
<t>Some proxy function may also use the C2 interface to get the
mapping between a SF Identifier and a SF locator from the control
plane PDP.</t>
</section>
</section>
<section title="Signaling procedure">
<section title="Service Function Chain Structuring">
<t>The chain management component of the Control Plane PDP is
responsible for the dynamic structuring of service function chains
(i.e., define an ordered list of service function identifiers) that
can be supported, as a function of the services that can be delivered,
among other information that may include subscriber-specific
information. For example, a service function chain can be structured
as: <figure align="left">
<artwork>service-chain 100 {
10 url-filter
20 web-cache
30 web-optimizer
40 firewall
}</artwork>
</figure></t>
<t>In this service function chain, each Service Function needs to be
assigned with a unique SF identifier and can be located using SF
locators. A Service Function chain should be assigned a SF Map Index.
A service function identifier does not necessarily hint the service
offered by that SF; its purpose is to uniquely identify a SF among
those present in a SFC-enabled domain. </t>
</section>
<section title="Service Function Path Determining">
<t>The path management component of the control plane PDP is
responsible for service function path determination. Service function
path determination is referred to determine an ordered list of
locators of each service function that belongs to a service function
chain. </t>
<t>The service function path determining may be static or
pre-determined using specific SF instances, or dynamic - choosing the
locators of service explicit SF instances at the time of delivering
traffic to the SF. </t>
<t>When there are multiple instances of a given SF that belongs to a
given SFC, each of these instances is assigned a unique locator. These
multiple instances may actually be invoked within the context of a
single chain, or within the context of multiple chains depending on
how the said chains are structured. The latter case may lead to
multiple SFP paths. In some other cases, a Service function path can
pre-computed by path management component for traffic engineering
purposes. Service function path doesn't need to be pre- determined.
The chain management component responsible for structuring the service
chains cannot decide in advance the actual path that will be followed
by packets. </t>
<t>When service function chain structuring is complete, the control
plane PDP will use the Path management component to determine the
locator of each specific SF instance in the chain and return a set of
SF locators associated with A service function chain. </t>
<t>In addition, the path management component also maintains the
mapping between service function chains and service function paths.
The control plane PDP can use the path management component to acquire
the service function path ID (i.e., service function map index). </t>
</section>
<section title="Service Topology Building">
<t>When an SFC is instantiated into the network it is necessary to
select the locator of the specific instances of SFs that will be used,
and to construct the service overlay for that SFC using SF's network
locator. The Service overlay is built on top of the underlying
network. The resulting service overlay is meant to facilitate SFC
domain operation, as it may provide a better, up-to-date, network-wise
overview of the SF status and usage on a per SFC basis.</t>
<t>A service specific overlay utilized by SFC then results in the
creation of the service topology. Service topology information
consists of network topology information collected from the underlying
network and SF-related information (such as Service Function
administration information and Service Function capability
information) that may be collected from the management interface.
Network topology information can be collected from the network by
using an IGP or BGP-LS [I.D-draft-idr-ls-distribution]. SF-related
information includes SF Identifier, SF Locator, Service Function
administration information (e.g., available memory, CPU utilization,
available storage capacity, etc.) or Service Function capability
information (e.g., supported ACL numbers, virtual context number).
</t>
<t>But the creation of the service topology is not conditioned by the
creation of the network topology: what is required is the mapping
between SF-related information and existing network topology
information. Additional service functions or Service Function
instances, for redundancy or load distribution purposes, can be added
to or removed from the service topology as required. </t>
</section>
<section title="Service Function Chaining Path Setup and Policy Table configuration">
<t>Once a SFC is structured, traffic classification rules are derived
and provided to the classifier nodes, along with the information
maintained in Policy Tables. The policy table is built based on SFC
policy and SFC service template information and metadata information
captured by using policy, service template and metadata components,
respectively when a Service function path is determined. The policy
table will be populated at each participating node involved in the
application of a service function chain and used by them to make their
forwarding decisions on a typical SF Hop-by-Hop basis. </t>
</section>
</section>
<section title="Security Considerations">
<t>TBD</t>
</section>
<section title="Acknowledgements">
<t>The author would like to thank LAC Chidung for his review and
comments that helped improve this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>In many standards track documents several words are used to
signify the requirements in the specification. These words are
often capitalized. This document defines these words as they
should be interpreted in IETF documents. Authors who follow these
guidelines should incorporate this phrase near the beginning of
their document: <list>
<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 RFC 2119.</t>
</list></t>
<t>Note that the force of these words is modified by the
requirement level of the document in which they are used.</t>
</abstract>
</front>
</reference>
<reference anchor="I.D-boucadair-sfc-framework">
<front>
<title>Service Function Chaining: Framework &
Architecture</title>
<author fullname="M. Boucadair" initials="M." surname="Boucadair">
<organization/>
</author>
<date month="October" year="2013"/>
</front>
<seriesInfo name="ID" value="draft-boucadair-sfc-framework-00"/>
</reference>
<reference anchor="I.D-quinn-sfc-problem-statement">
<front>
<title>Network Service Chaining Problem Statement</title>
<author fullname="P. Quinn" initials="P." surname="Quinn">
<organization/>
</author>
<date month="August" year="2013"/>
</front>
<seriesInfo name="ID" value="draft-quinn-nsc-problem-statement-03"/>
</reference>
<reference anchor="I.D-wu-pce-traffic-steering-sfc">
<front>
<title>PCEP Extensions for traffic steering support in Service
Function Chaining</title>
<author fullname="Q.Wu" initials="Q." surname="Wu">
<organization/>
</author>
<author fullname="D. Dhody" initials="D." surname="Dhody">
<organization/>
</author>
<author fullname="M. Boucadair" initials="M." surname="Boucadair">
<organization/>
</author>
<author fullname="C. Boucadair" initials="C." surname="Boucadair">
<organization/>
</author>
<author fullname="J. Tantsura" initials="J." surname="Tantsura">
<organization/>
</author>
<date month="Feburary" year="2014"/>
</front>
<seriesInfo name="ID" value="draft-wu-pce-traffic-steering-sfc-02"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC4655">
<front>
<title>A Path Computation Element (PCE)-Based Architecture</title>
<author fullname="A.Farrel" initials="A." surname="Farrel">
<organization/>
</author>
<date month="August" year="2006"/>
</front>
<seriesInfo name="RFC" value="4655"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:19:07 |