One document matched: draft-ww-sfc-control-plane-01.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="info" docName="draft-ww-sfc-control-plane-01" 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 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="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" 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>RTG</area>
<workgroup>Service Function Chaining</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>SFC</keyword>
<abstract>
<t>This document describes a control framework for service function
chaining (SFC), which defines interfaces between SFC control system and
other SFC related entities e.g. service chain management interface, user
profile interfaces, feedback interface and interfaces to dataplane. This
document also describes necessary control functions in the SFC control
framework and discuss how a set of available Service Functions are
provisioned and how Service Function Chaining path is setup.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>Network operators use various mechanisms to steer and adapt user
traffic according their business needs. In general two complementary
building blocks support this task:<list style="symbols">
<t>Policing and shaping for upstream and downstream traffic in the
access network. The two related endpoints are on one end the user
equipment and on the other end a service creation node, e.g. a BNG,
a P-GW or a CMTS. A policy and charging control function typically
supports traffic steering within this closed environment. Two types
of metadata are typically in use for traffic and service management
within the access network. One set includes the user and service
profiles configured and residing in a policy server or more general
within some control plane systems. These data are static and
describe basically the contracted SLAs including charging rules. The
other set of metadata may originate from different equipment in the
access network and describes e.g. the momentary state of the network
or more precisely, a network segment.</t>
<t>Service functions residing in a LAN segment between the service
creation node and the final internal or external service platforms.
Downstream and upstream user packets are forced by some methods to
pass an ordered sequence of service functions a.k.a. Service
Function Chain, on their way to the user terminal or the addressed
service platform. Downstream and upstream traffic may pass different
service chains. While policing in the access network affects the
transport properties, service functions additionally may optimize
the payload of user plane traffic or provide some Value Added
Services. Service Function Chains use control plane or data plane
metadata to properly control and steer the data traffic. For more
details see the SFC use case drafts [mobility], [general],
[DC],[long lived flows].</t>
</list></t>
<t>Service Function Chains (SFC) are essential for the business of a
network or a data center operator Since they enable operators to provide
services with flexible combinations of existing capabilities in the
network. </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 describes a control framework for service function
chaining (SFC), which defines interfaces between SFC control system and
other SFC related entities e.g. service chain management interface, user
profile interfaces, feedback interface and interfaces to data plane.
This document also describes necessary control functions in the SFC
control framework and discuss how a set of available Service Functions
are provisioned and how Service Function Chaining path is setup.</t>
</section>
<section title="Terminology">
<t>This document uses terminologies introduced in [SFC-PS] , [ID
Jiang-SFC-ARCH] and [ID Boucadair-SFC-framework]. Besides, following
terms are also used.<list style="hanging">
<t hangText="SFid"><vspace blankLines="1"/>SF identifier which
uniquely identifies an SF instance<vspace blankLines="1"/></t>
<t hangText="SFE"><vspace blankLines="1"/>Service Forwarding
Entity<vspace blankLines="1"/></t>
</list></t>
</section>
<section title="Data plane basic assumption">
<t>The control 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>SFC data plane characters in these drafts are summarized below, as
basic assumptions for SFC control framework.<list style="symbols">
<t>Data plane traffic is firstly classified by a service classifier
(SCLA), and encapsulated with a SFC header and an underlay network
header. The SFC Header MUST include SFC-specific forwarding
information used by SFEs to pass the data plane traffic to the next
service instance within the chain. Classification in the SCLA is
done by a set of control and/or user plane metadata.</t>
<t>SFE forwards SFC packets according to its SFC forwarding entry. A
SFE typically is a virtualized or a L2/L3 forwarding device able to
interpret the SFC header. A SFE may serve one or more Service
Functions (Fig. 1).</t>
<t>When SFE decides to send a SFC packet to a non-SFC aware SF
instance, it sends the packet to a SFC proxy.</t>
</list></t>
</section>
<section title="Service function chain control framework">
<figure>
<artwork> +-----------+
|Management | abstract definition of the
| System | SFC
+-----------+
|
|M
+-----+ +------------+------------+
| AAA/+-----------+ |
| PCRF| A | | F
+-----+ | SFC control system +------------+
| | |
| +------+ |
+-+-----------+-----------+ C2| |
|C1 |F |C2 |F \F | |
| +---+ | +---+ +---+ | +--++
| |SF | | |SF | | SF| | |SF |
+-----+ +-+-+ | +-+-+ +-+-+ | +--++
| | | | | | |
| --+ | +-+ +-+ | +--+
+---+--+ ++--+--++ ++--+--++
------>|SCLA +--------->| SFE +--------->+ SFE |---->
+------+ +-------+ +-------+
Figure 1. SFC control framework
</artwork>
</figure>
<section title="Overview">
<t>As illustrated in Figure 1, SFC control framework is composed of a
SFC control system and related interfaces. SFC control system is a
central control/management plane entity and includes functions
managing and controlling SFCs. SFC control system also contains
interfaces that can be used to interact with AAA/PCRF server,
Management System, SFE, SF respectively. Service functions can be
co-located with SFE or physically separated from SFEs with each
attached by one or more Service Functions. </t>
<t>The framework supports demands on SFC abstractions and automatic
generation of the underlay connectivity.</t>
<t>As decision center of all the service function chains in domain,
SFC control system can receive subscriber attributes from AAA/policy
server or Policy and Charging Rule Function (PCRF), it also can
receive service function chain configuration from the Management
System and installs corresponding classification rules and forwarding
tables on SFC data plane. SFC control system also collects SFs
topology information and feedbacks from SCLA, SFE, and SF.</t>
<t>There are several interfaces connected to the SFC control
system.<list>
<t>M Interface: the Management System uses this interface to
define service function chains and related policies regarding user
data and service information.</t>
<t>A Interface: the interface between the SFC control system and
AAA, policy server or PCRF, through which subscriber and network
metadata are injected. Metadata include subscriber and service
profile, access network type, network loads etc.</t>
<t>C1 Interface: the interface between the SFC control system and
the Service Classifier (SCLA). Classification rules are configured
on SCLA via this interface.</t>
<t>C2 Interface: the interface between the SFC control system and
the Service Forwarding Entity (SFE). Forwarding entries on SFEs
are configured 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 SFC control system.</t>
</list></t>
</section>
<section title="SFC Control System">
<t>The SFC control system is in charge of maintaining service chain
topologies information, creating and configuring service chain
forwarding entries, including the sequence of SFs in a service chain,
SF information, SFC paths and metadata.</t>
<t>The SFC control system receives service function chain vectors from
the Management System. A SFC vector may look like:</t>
<t>{{MBR>1Mbps, RAT='UMTS', protocol='HTTP',
QOS='Gold'},goto'sfc1'}</t>
<t>The SFC control system combines these policies with subscriber
attributes inputted from the policy server or PCRF, creates
classification rules and configures them on SCLA. The SFC control
system also assigns SFC identification and configures forwarding
entries on SFEs.</t>
<t>Both fixed broadband and mobile broadband networks use policy
server or PCRF to maintain subscriber attributes including access
bandwidth (512K,1M,2M,4M), QoS level (Gold, Silver, Bronze), access
line/cell id, payment status, Radio Access Technology (RAT)
(GPRS,UMTS,HSPA,LTE),etc. Subscriber attributes are volatile and need
to be updated to the SFC control system instantly through A
interface.</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. These information can be used by the control system to update
the SFC classification rules and SFC forwarding entries.</t>
<t>The F Interface is a logical interface used to collect such kind of
feed information from data plane.</t>
</section>
<section title="C1 interface">
<t>This interface is used to install SFC classification rules to
Service Classifier(SCLA). These rules are created by the SFC control
system by calculating inputs of subscriber attributes from A
interface, service chain policies from M interface and possibly
feedback from F interface.</t>
<t>SCLA directs traffic to SFCs according to these classification
rules.</t>
</section>
<section title="C2 interface">
<t>SFE takes the responsibility of the service function chain
forwarding. SFC forwarding entries in the SFE are configured by the
control system through C2 interface.</t>
<t>Each SF has a unique service function identifier to identify itself
in SFC forwarding plane, which is correlated to its network address on
the SFC control system. In case that the SF instance is directly
connected to a SFE node, the forwarding entry may include attaching
port of the SF instance.</t>
<t>Some proxy may also use C2 interface to get the SFid/Network
address mapping from the control system.</t>
</section>
</section>
<section title="Signaling procedure">
<section title="Building overlay Topology">
<t>Network topology information can be collected from network by using
IGP or BGP-LS [I.D-draft-idr-ls-distribution]. The Service overlay is
built on top of underlying network and creates a forwarding path
between SFE Nodes or connected graph for these SFE Nodes. Not all SFE
Nodes need to be directly connected. A service specific overlay
utilized by SFC creates the overlay topology. Overlay topology is
created based on network topology information collected from
underlying network and SF related information collected from
management interface. Overlay topology information includes SF
Identifier, SF Locator, Service Function administration information
(e.g., available memory,CPU utilization,Available storage)or Service
Function capability information(e.g.,supported ACLnumbers, virtual
context number) A topology management function can located in SFC
control system or physically separated from the entity that supports
the SFC control system.</t>
<t>Adding new Service Functions to Overlay Node in the overlay
topology is easily accomplished, and no underlying network changes are
required. Furthermore, additional service Functions or Service
Function instances, for redundancy or load distribution purpose, can
be added or removed to the service topology as required.</t>
</section>
<section title="Service Function Map Selection">
<t>When overlay topology is created by a service-specific overlay
utilized by Service Function Chaining, each Service Function type is
assigned with a unique SF identifier and can be located using SF
locator. </t>
<t>To select appropriate service function for service function chain,
a service request may be send to topology management function. The
Service request carries various constraint information or resource
requirements (e.g., SF location constraint, SF order constraint, SF
capability information). The topology management function returns
computed path information to SFC control system. SFC control system
will compose the Service Function Map based on the returned computed
path. If there are multiple Service Functions or Service Function
Instances can satisfy service requirements, the PDP will select
appropriate Service Function based on Service Functions capability
info or local policy to build Service Function Map.</t>
</section>
<section title="Service Function Chaining (SFC) Policy decision">
<t>The SFC control system gets SFC policy and SFC service topology
definition from M interface (see 4.2.). The SFC control system may
retrieve computed path information from topology management function
and compose them into service Function Map. In addition, the SFC
control system will interact with AAA/PCRF server to correlate
subscriber profile with SFC and make policy decision via F
interface.</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 help improvement to this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<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>
</references>
<references title="Informative References">
<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>
<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-arch">
<front>
<title>Service Function Chaining (SFC) Architecture </title>
<author fullname="P. Quinn" initials="P." role="editor"
surname="Quinn">
<organization/>
</author>
<author fullname="J. Halpern" initials="J." role="editor"
surname="Halpern">
<organization/>
</author>
<date month="May" year="2014"/>
</front>
<seriesInfo name="ID" value="draft-quinn-sfc-arch-05"/>
</reference>
<reference anchor="I.D-jiang-sfc-arch">
<front>
<title>An Architecture of Service Function Chaining </title>
<author fullname="Y. Jiang" initials="Y." surname="Jiang ">
<organization/>
</author>
<author fullname="H. Li" initials="H." surname="Li">
<organization/>
</author>
<date month="February" year="2014"/>
</front>
<seriesInfo name="ID" value="draft-jiang-sfc-arch-01"/>
</reference>
</references>
<section title="Appendix A.">
<figure>
<artwork> Yang Shi
Huawei
Beijing, 100085
China
Email: shiyang1@huawei.com
XianGuo Zhang
Huawei
Beijing, 100085
China
Email: zhangxianguo09@huawei.com</artwork>
</figure>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:11:23 |