One document matched: draft-ww-sfc-control-plane-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- 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-03" 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 Chaining (SFC) Control Plane
Achitecture</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="Yong(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></area>
<workgroup></workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword></keyword>
<abstract>
<t>This document defines the control plane architecture which include
control plane components and interface between control plane component
and data plane component. This document further describes how Service
Functions Chains are structured and how Service Function Chaining path
is provisioned and setup.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The dynamic enforcement of a service-derived, adequate forwarding
policy for packets entering a network that supports advanced Service
Functions (SFs) has become a key challenge for operators and service
providers.</t>
<t>Service Function Chaining (SFC) typically observe, alter or even
terminate and re-establish session flows between user equipment and
application platforms (Web, Video, VoIP etc.) by invoking, in a given
order, a set of Service Functions [I.D-ietf-sfc-problem-statement].
Service functions involved in a given SFC may include load-balancing,
firewalling, intrusion prevention, etc.</t>
<t>A given SFC-enabled domain may involve several instances of the same
Service Function. Service function instances can be automatically added
to or removed from a given SFC. SFs can be co-located or embedded in
distinct physical nodes, or virtualized.</t>
<t>This document describes SFC control plane architecture 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>This document defines the control plane architecture while the data
plane architecture is defined in [I.D-ietf-sfc-architecture].</t>
<t>The SFC data plane characteristics considered as basic assumptions by
the SFC control architecture are summarized below: <list style="symbols">
<t>Traffic that enters a SFC-enabled domain is classified according
to the rules the SFC Control Plane provides to the Classifier. After
classification, the traffic is forwarded into the SFC-enabled domain
passing a set of Service Functions as defined in the corresponding
SFC instructions. SFC-specific forwarding information is used by
Service Forwarder Entity (i.e., a node which include service
forwarder function (SFF)) to make traffic forwarding decisions and
pass the traffic to the next Service Function instance within the
chain, through the Service Function Path derived from Control Plane
Information and instantiated from the Classifier.</t>
<t>The Service Forwarder Entity forwards packets according to the
entries maintained in the SFC Policy rule base. A Service Forwarder
Entity can be a virtualized or physical L2/L3 network device that
serves Service Functions within a given chain. A Service Forwarder
Entity may serve one or more Service Functions (Fig. 1).</t>
<t>When a Service Forwarder Entity needs to forward a packet to an
SFC-unware legacy node, the packet is likely to be forwarded by a
SFC proxy to SFC-unaware legacy node.</t>
</list></t>
</section>
<section title="SFC Control Plane: An Overview">
<t>For the purpose of defining the SFC control plane architecture, the
SFC control plane is broken up into five distinct components: <list
style="hanging">
<t hangText="Chain Selection Policy Control"><vspace
blankLines="1" />Chain Selection Policy Control component maintains
SFC-related information models (chain structures, classification
rules) derived from business or operational models. <vspace
blankLines="1" /></t>
<t hangText="Chain Management Policy Control"><vspace
blankLines="1" />This component is responsible for:<list
style="symbols">
<t>Structuring 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], business guidelines, etc.).</t>
<t>Adjusting a chain based on the external policy context or any
path change computed by Service Overlay Topology management
component.</t>
</list><vspace blankLines="1" /></t>
<t hangText="Service Overlay Topology management"><vspace
blankLines="1" /> This is an optional component that is not needed
particularly when SFC forwarding is fully distributed. This
component is responsible for:<list style="symbols">
<t>Creating the service topology which consist of Service
Function-related information and network topology
information.</t>
<t>Helping Chain Mapping and forwarding Control Component
determine forwarding path in case the said forwarding path is
traffic engineered.</t>
</list><vspace blankLines="1" /></t>
<t hangText="Service Function (SF) Management"><vspace
blankLines="1" />This component allows for the dynamic discovery of
locations of Service Functions and is used to help the SFC control
plane to gather Service Function-related information from various
Service Functions available within a SFC-enabled domain. <vspace
blankLines="1" /></t>
<t hangText="SFC Mapping and Forwarding Control"><vspace
blankLines="1" />This is a component that helps the SFC Control
plane to dynamically: <list style="symbols">
<t>Map SFCs to the specific Service Function path.</t>
<t>Populate forwarding rules on the data plane.</t>
</list><vspace blankLines="1" /></t>
</list></t>
<figure align="left" anchor="fig-1" title="SFC Control Plane Overview">
<artwork><![CDATA[
+-------------------------------------------------+
| SFC Control Plane |
| +---------------+ +---------------+ |
+-------| |Chain Management |Service Overlay| |
| | |Policy Control | |Topo Management| |
| | +---------------+ +---------------+ |
| | +---------------+ +---------------+ |
+---------|Chain Selection| | Chain Mapping | +----------+|
| | | Policy Control| | and Forwarding| |External SF|
| +---------------+ | Control | |Management||
| | +---------------+ +----------+|
C1 +------^-----------^-------------^----------------+
+---------------------|F----------|-------------|-------------+
| | +----+ | | |
| | | SF | |C2 |C2 |
| +----+ | | |
| +----V--- --+ | | | |
| | SFC | +----+ +-|--+ +----+ |
| |Classifier |---->|SFF |----->|SFF |------->|SFF | |
| | Node |<----| |<-----| |<-------| | |
| +-----------+ +----+ +----+ +----+ |
| | | | |
| |C2 ------- | |
| | | | +-----------+ F |
| V +----+ +----+ | SFC Proxy |--> |
| | SF | |SF | +-----------+ |
| +----+ +----+ |
| |F |F |
| SFC Data Plane Components V V |
| |
+-------------------------------------------------------------+
]]></artwork>
</figure>
<t>There are three interfaces connected to the SFC control plane.<list>
<t>C1 Interface: the interface between the SFC control plane and the
SFC Classifiers. Classification rules are installed on the SFC
Classifier Node(s) via this interface.In addition, this Interface
may be used by the control plane to instantiate of
traffic-engineered paths that will be used to forward traffic
according to SFC information.</t>
<t>C2 Interface: the interface between the SFC control plane and the
Service Forwarder Function. SFC-based forwarding entries on Service
Function nodes are provided by the SFC Control plane via this
interface.</t>
<t>F Interface: This interface is used by Service Function to
feedback service or application level information of a data flow to
the SFC control plane.</t>
</list></t>
<section title="SFC Control plane">
<t>The SFC control plane is in charge of Service Function chain
creation and maintenance, service chain path instantiation (in case of
the traffic-engineered SFCs), mapping between SFC and Service Function
path, SFC Policy Table creation and configuration, including the
sequence of Service Functions in a Service Function chain, Service
Function information, SFC paths information.</t>
<t>The SFC control plane 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 SFC Control plane also creates classification rules and
installs them on the classifier nodes. The SFC control plane also
assigns SFC identification and installs SFC Policy Tables in the
Service forwarder function.</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 SFC control plane to
update the SFC classification 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 nodes. These rules are created by the SFC control
Plane. They may be updated by information provided by the Service
Function nodes (in case a change of the network topology has occurred,
for example).</t>
<t>SFC Classifier Node binds incoming traffic to SFCs according to
these classification rules.</t>
</section>
<section title="C2 interface">
<t>Service forwarder entity make traffic forwarding decisions
according to the entries maintained in their SFC Policy Table. Such
Table is populated by the SFC control plane through the C2
interface.</t>
<t>Each Service Function has a unique Service Function identifier to
identify itself in the SFC forwarding plane. The Service Function
locator is typically referred to as a network address. In case the
Service Function instance is directly connected to a Service forwarder
entity, the forwarding entry may also include the port through which
the Service Function instance can be reached.</t>
<t>Some proxy function may also use the C2 interface to retrieve the
mapping between a Service Function Identifier and a Service Function
locator from the SFC control plane.</t>
</section>
</section>
<section title="Signaling procedure">
<section title="Service Topology Building">
<t>When a Service Function is instantiated into the network it is
necessary to select the locator of the specific instances of Service
Functions that will be used, and to construct the service overlay
using Service Function's network locator. The service overlay is built
on top of the underlying network. The resulting service overlay is
meant to facilitate SFC-enabled domain operation, as it may provide a
better, up-to-date, network-wise overview of the Service Functions
status and usage.</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 Service Function-related information (such as Service
Function administration information and Service Function capability
information) that may be collected from the management interface. For
example, Network topology information can be collected from the
network using an IGP or BGP-LS [I.D-draft-idr-ls-distribution]. </t>
<t>Service Function-related information includes Service Function
Identifier, Service Function 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). This
information can be retrieved by various means (e.g., registration
mechanism that provides binding between Service Function Identifier
and Service Function Locator(s) and allows for the dynamic discovery
of locations of Service Functions).</t>
<t>Network topology is not required for dynamically structuring
service chains, but it may be helpful during service troubleshooting
and diagnostics.</t>
<t>The creation of the service topology is not conditioned by the
creation of the network topology: what is required is the mapping
between Service Function-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. Means to
dynamically discover the location of available Service Function
instances may be supported.</t>
</section>
<section title="Service Function Chain Structuring">
<t>The chain management component of the SFC control plane 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 follows: <figure align="left">
<artwork><![CDATA[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 Service Function identifier and can be located
using Service Function locators. A Service Function chain should be
assigned an SFC Index. A Service Function identifier does not
necessarily hint the service offered by that Service Function; its
purpose is to uniquely identify a Service Function among those present
in a SFC-enabled domain.</t>
</section>
<section title="Service Function Path Determining">
<t>The Chain Mapping and forwarding Control Component of the SFC
control plane is a component that is responsible for Service Function
path determination based on Service Overlay Topology information
maintained in the Service Overlay Topology management component.
However, not all SFC deployments may require Service Function path
determination (e.g., SFC forwarding is fully distributed ). 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 Service Function instances, or dynamic -
choosing explicit Service Function instances at the time of delivering
traffic to the Service Function.</t>
<t>When there are multiple instances of a given Service Function 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 SFPs. In some other cases, a Service Function path
can pre-determined by SFC mapping and forwarding component for traffic
engineering purposes by interacting with Service Overlay Topology
management component. However 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>In addition, the SFC mapping and forwarding component also
maintains the mapping between Service Function chains and Service
Function paths. When Service Function chain structuring is complete,
the SFC control plane will use the SFC forwarding and mapping
component to determine the locator of each specific Service Function
instance in the chain and return a set of Service Function locators
associated with a Service Function chain.</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 other information
maintained in Policy Tables. The policy table is built based on SFC
policy and service information(e.g.,subscriber being mapped into a
service class related to a SFC) captured by using policy related
components, 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 hop-by-hop basis.</t>
</section>
</section>
<section title="Security Considerations">
<t>The SFC Control and the participating SFC functional elements must be
mutually authenticated. Means to protect against an attacker who would
install/remove/modify classification rules must be supported. When means
to dynamically discover the location of SF instances are in use, they
should be designed to avoid illegitimate SFs to belong to the
SFC-enabled domain.</t>
</section>
<section title="Acknowledgements">
<t>The author would like to thank Shibi Huang for providing input and
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-ietf-sfc-architecture">
<front>
<title>Service Function Chaining (SFC) Architecture</title>
<author fullname="J. Halpern" initials="J." surname="Halpern">
<organization></organization>
</author>
<author fullname="C. Pignataro" initials="C." surname="Pignataro">
<organization></organization>
</author>
<date month="September" year="2014" />
</front>
<seriesInfo name="ID" value="draft-ietf-sfc-architecture-01" />
</reference>
</references>
<references title="Informative References">
<reference anchor="I.D-ietf-sfc-problem-statement">
<front>
<title>Network Service Chaining Problem Statement</title>
<author fullname="P. Quinn" initials="P." surname="Quinn">
<organization></organization>
</author>
<date month="August" year="2014" />
</front>
<seriesInfo name="ID" value="draft-ietf-sfc-problem-statement-10" />
</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></organization>
</author>
<author fullname="D. Dhody" initials="D." surname="Dhody">
<organization></organization>
</author>
<author fullname="M. Boucadair" initials="M." surname="Boucadair">
<organization></organization>
</author>
<author fullname="C. Boucadair" initials="C." surname="Boucadair">
<organization></organization>
</author>
<author fullname="J. Tantsura" initials="J." surname="Tantsura">
<organization></organization>
</author>
<date month="September" year="2014" />
</front>
<seriesInfo name="ID" value="draft-wu-pce-traffic-steering-sfc-05" />
</reference>
</references>
<section title="SFC Control Plane Components Deployment Consideration in Mobile Backbone (MBB) Environment">
<figure title="SFC in MBB">
<artwork><![CDATA[
+---------------------------------------------------------------+
| SFC Control Plane +----------------------+ |
| | +------------+ | |
| | | SFC | | |
| +----------------|Orchestrator-----------+ |
| | | +------------+ | | |
| | | SFC Management System| | |
| | +----------------------+ | |
| | | |
| | | |
|+------|-------------+ +--------|------------+ |
||+-----|----+ | | +------|---------+ | |
|||SFC Policy| | | | SFC Forwarding | | |
||| Control | | |-------| Control -----|----+
||+-----|----+ | | | +----------------+ | | |
|| Enhancement in PCRF| | | SFC Controller | | |
|+------|-------------+ | | | | |
| | | +---------------------+ | |
+-------|-------------------------|-----------------------------+ |
+-------|-------------------------|------------------------------------+
|+--------------------+ +---------------+ +---------------+ | |
||Enhancement in PCEF | | Enhancement in| | Enhancement in| | |
|| or TDF | | ToR switch or | | ToR Switch or | | |
||+-----|-------+ | | Router | | Router | | |
||| SFC | | |+----|--+ | |+-------+ | | |
||| Classifier |-----------|| |------------- | | | | |
||| Function | | || SFF1 | | || SFF2 ---------+ |
||+-------------+ | || | | || | | |
|+--------------------+ |+---|---+ | |+---|---+ | |
| +----|----------+ +----|----------+ |
| ------------ -----|------ |
| | | | | |
| +----+ +---+ +----+ +---+ |
| | SF1| |SF2| | SF3| |SF4| |
| +----+ +---+ +----+ +---+ |
|SFC Data Plane |
-----------------------------------------------------------------------+
]]></artwork>
</figure>
<t>In MBB environment, Policy Control component and Chain Management
Policy Control component defined in section 4 can be supported using
Enhanced PCRF. Service Overlay Topology management defined in section 4
can be supported using SFC Orchestrator. SFC Mapping and Forwarding
Control component defined in section 4 can be supported using SFC
Controller. Note that 3GPP is considering integrating Chain Selection
Policy Control component and Chain Management Policy Control component
using PCRF.</t>
</section>
<section title="SFC Control Plane Components Deployment Consideration in Fixed Backbone (FBB) Environment">
<figure title="SFC in FBB">
<artwork><![CDATA[
+---------------------------------------------------------------+
| SFC Control Plane +----------------------+ |
| | +------------+ | |
| | | SFC | | |
| +----------------|Orchestrator-----------+ |
| | | +------------+ | | |
| | | SFC Management System| | |
| | +----------------------+ | |
| | | |
| | | |
|+------|-------------+ +--------|------------+ |
||+-----|----+ | | +------|---------+ | |
|||SFC Policy| | | | SFC Forwarding | | |
||| Control | | -|-------| Control -----|----+
||+-----|----+ | | | +----------------+ | | |
|| Enhancement in RADIUS | | SFC Controller | | |
|+------|-------------+ | | | | |
| | | +---------------------+ | |
+---------------------------------------------------------------+ |
+----------------------------------------------------------------------+
|+--------------------+ +---------------+ +---------------+ | |
||Enhancement in BRAS | | Enhancement in| | Enhancement in| | |
|| or BNG | | ToR switch or | | ToR Switch or | | |
||+-----|-------+ | | Router | | Router | | |
||| SFC | | |+----|--+ | |+-------+ | | |
||| Classifier |-----------|| |------------- | | | | |
||| Function | | || SFF1 | | || SFF2 ---------+ |
||+-------------+ | || | | || | | |
|+--------------------+ |+---|---+ | |+---|---+ | |
| +----|----------+ +----|----------+ |
| ------------ -----|------ |
| | | | | |
| +----+ +---+ +----+ +---+ |
| | SF1| |SF2| | SF3| |SF4| |
| +----+ +---+ +----+ +---+ |
|SFC Data Plane |
-----------------------------------------------------------------------+
]]></artwork>
</figure>
<t>In FBB environment, Policy Control component and Chain Management
Policy Control component defined in section 4 can be supported using
Enhanced RADIUS. Service Overlay Topology management defined in section
4 can be supported using SFC Orchestrator. SFC Mapping and Forwarding
Control component defined in section 4 can be supported using SFC
Controller. Note that BBF is considering integrating Chain Selection
Policy Control component and Chain Management Policy Control component
using RADIUS.</t>
</section>
<section title="SFC Control Plane Components Deployment Consideration in Data Center(DC) Environment">
<figure title="SFC in DC Environment">
<artwork><![CDATA[
+---------------------------------------------------------------+
| SFC Control Plane +----------------------+ |
| | +------------+ | |
| | | SFC | | |
| +----------------|Orchestrator-----------+ |
| | | +------------+ | | |
| | | SFC Management System| | |
| | +----------------------+ | |
| | | |
| | | |
| |Download Classifier +--------|------------+ |
| | Rule directly | +------|---------+ | |
| | | | SFC Forwarding | | |
| | -|-------| Control -----|----+
| | | | +----------------+ | | |
| | | | SFC Controller | | |
| | | | | | |
| | | +---------------------+ | |
+-------|-------------------------------------------------------+ |
+-------|--------------------------------------------------------------+
|+------|-------------+ +---------------+ +---------------+ | |
|| Enhancement in DC | | Enhancement in| | Enhancement in| | |
|| | Gateway | | ToR switch or | | ToR Switch or | | |
||+-----|-------+ | | Router | | Router | | |
||| SFC | | |+----|--+ | |+-------+ | | |
||| Classifier |-----------|| |------------- | | | | |
||| Function | | || SFF1 | | || SFF2 ---------+ |
||+-------------+ | || | | || | | |
|+--------------------+ |+---|---+ | |+---|---+ | |
| +----|----------+ +----|----------+ |
| ------------ -----|------ |
| | | | | |
| +----+ +---+ +----+ +---+ |
| | SF1| |SF2| | SF3| |SF4| |
| +----+ +---+ +----+ +---+ |
|SFC Data Plane |
-----------------------------------------------------------------------+
]]></artwork>
</figure>
<t>In DC environment, Policy Control component and Chain Management
Policy Control component, Service Overlay Topology management defined in
section 4 can be supported using SFC Orchestrator. SFC Mapping and
Forwarding Control component defined in section 4 can be supported using
SFC Controller.</t>
</section>
<section title="SFC Control Plane Components Deployment Consideration in Data Center (DC) Environment">
<figure title="SFC in DC Environment">
<artwork><![CDATA[
+---------------------------------------------------------------+
| SFC Control Plane |
| +------------------------+ |
| | stateful PCE | |
| +-------------| +-------+ +-------+ | |
| | | |Policy | | TE-DB | |<-------| |
| | | +-------+ +-------+ | | |
| | +------------------------+ | |
| | ---------------|-----| |
| | SFC Controller | | |
| | | +----------------+ | |
| | +---------------------------| Policy Control| | |
| | | | +----------------+ | |
| | | +------ ------ --+ |
| | | | | SFC Forwarding | | |
| | | +-------| Control -----|----+
| | | | | +----------------+ | | |
| | | | +---------------------+ | |
+-------|-----|-------------------------------------------------+ |
+-------|-----|--------------------------------------------------------+
|+------|-----|-------+ +---------------+ +---------------+ | |
|| Enhancement in DC | | Enhancement in| | Enhancement in| | |
|| | Gateway | | ToR switch or | | ToR Switch or | | |
||+-----|-------+ | | Router | | Router | | |
||| SFC | | |+----|--+ | |+-------+ | | |
||| Classifier |-----------|| |------------- | | | | |
||| Function | | || SFF1 | | || SFF2 ---------+ |
||+-------------+ | || | | || | | |
|+--------------------+ |+---|---+ | |+---|---+ | |
| +----|----------+ +----|----------+ |
| ------------ -----|------ |
| | | | | |
| +----+ +---+ +----+ +---+ |
| | SF1| |SF2| | SF3| |SF4| |
| +----+ +---+ +----+ +---+ |
|SFC Data Plane |
-----------------------------------------------------------------------+
]]></artwork>
</figure>
<t>Alternatively, In DC environment, Policy Control component and Chain
Management Policy Control component, Service Overlay Topology management
defined in section 4 can be supported, SFC Mapping and Forwarding
Control component defined in section 4 can be supported together using
SFC Controller. In addtion, SFC Controler operates a stateful PCE and
its instantiation mechanism to compute and instantiate Service Function
Paths (SFP). </t>
<t>The PCE maybe co-located with the SFC Control plane component or an
external entity (e.g., [I.D-wu-pce-traffic-steering-sfc]).</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:18:52 |