One document matched: draft-ww-sfc-control-plane-00.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-00" 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
Overview</title>
<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="Danhua Wang" initials="D." surname="Wang">
<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>wangdanhua@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="XianGuo Zhang" initials="X." surname="Zhang">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<city>Beijing</city>
<region></region>
<code>100085</code>
<country>China</country>
</postal>
<email>zhangxianguo09@huawei.com</email>
</address>
</author>
<author fullname="Yang Shi" initials="Y." surname="Shi">
<organization>Huawei</organization>
<address>
<postal>
<street></street>
<city>Beijing</city>
<region></region>
<code>100085</code>
<country>China</country>
</postal>
<email>shiyang1@huawei.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>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 focusing
on discussing how the Service Functions are discovered and provisioned
and how Service Function Chaining path is 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 or removed to an SFC. Service functions can be
co-located on the same physical node or be embedded in distinct physical
nodes.</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 is
focusing on discussing how the set of available Service Functions
(including several instances of the same Service Function) are
discovered and provisioned and how Service Function Chaining path is
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="SFC Control Plane Overview">
<t>The Service Function Chain Control plane Overview proposed in this
document includes a topology server, policy decision point(PDP), and
service Function(SF) Nodes, SFC Ingress Node, SFC Egress Node. Service
functions can be co-located on one SF Node or physically separated
across several SF Nodes with each having one or more Service Functions.
The Topology server(Topo Server for short) is used to locate SF Nodes in
the network as needed. The PDP is a central control/management plane
entity and used to maintain SFC Policy Tables defined in figure 1 of
[I.D- boucadair-sfc-framework], and generating and communicating
appropriate policies in SF Nodes and SFC Ingress/Egress Nodes. To create
SF map in the SFC Policy tables, PDP may interact with the Topo Server
using SF node discovery protocol to build SF maps. To communicate
policies in SF nodes, either fully centralized approach, or half
centralized approach or distributed approach can be used. <list
style="symbols">
<t>In the fully centralized approach, Communication between PDP and
Topo Server can be used to return computed path information . I2RS
signaling can be used to communicate policy between PDP and SF Node
or between PDP and SF Ingress/Egress Node.</t>
<t>In the distributed approach, The Topo server communicate with SFC
Ingress Node and returns computed path in the Explicit Route Object
in the response [I.D-wu-pce-traffic-steering-sfc]. SFC Ingress Node
then can use RSVP-TE to initiate signaling and communicate policy
with each SF Node and establish the service Function Chaining
path.</t>
<t>In the half centralized approach, The Topo server communicate
with SFC Ingress Node and return the path computation results to SFC
Ingress Node and then SFC Ingress Node uses RSVP-TE to populate the
Path profile Identifier in each SF node
[I.D-wu-pce-traffic-steering-sfc]. Then each SF node can use Path
Profile Identifier to request PDP for SF path profile.</t>
</list></t>
<figure>
<artwork> +-------------+
+---------------------| |
| (e.g.,PCEP, ALTO..) | Topo Server |
| +------------------| |
| | +----A--------+
| | | |
| | | |(e.g.,PCEP, ALTO..)
| | e.g., Netconf.. +----|-----V--+
| | +--------------> PDP <------------------+
| | | | <---+ |
| | | +-A-----------+ | |
| | | | | |
| | | | | |
| | | RSVP-TE.. | | |
+-V--V---V--+ +-------V-+ +------V--+ +-----V------+
|SFC Ingress| | SF | | SF | | SFC Egress |
| Node |---->| Node1 |----->| Node2 |---->| Node |
| |<----| |<---- | |<----| |
+-----------+ | SF1 SF2 | | SF3 SF4 | +------------+
+---------+ +---------+
</artwork>
</figure>
</section>
<section title="Signaling procedure">
<section title="Building Service Topology ">
<t>Network topology information can be collected from network by using
IGP or BGP-LS [I.D-draft-idr-ls-distribution].</t>
<t>Not all SF Nodes can be directly connected. The Service overlay
creates a forwarding path between SF Nodes or connected graph for
these SF Nodes. SF nodes can be co-located on the same physical node
or be embedded in distinct physical nodes. A service specific overlay
utilized by SFC creates the service topology. Service topology
information includes SF Identifier, SF Locator, Service Function
administration information (Packet rate utilization,Bandwidth
utilization per CoS,Packet rate utilization per Cos,Memory
utilization, RIB utilization per address family, FIB utilization per
address family,,available memory,CPU utilization,Available storage)or
Service Function capability information(e.g.,supported ACLnumbers,
virtual context number,supported-packet-rate) Service topology
information can be collected by the Topo server using either I2RS
interface or routing protocol. The Topo Server can be collocated with
PDP or physically separated from the entity that supports the PDP.</t>
<t>Within the service topology, an ordered set of SF nodes will be
invoked for each packet that belongs to a given flow for which a SFC
will be applied. Adding new Service Functions to SF Node in the
Service 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 Discovery">
<t>When service 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. There are one approache for Service Function Discovery <list
style="symbols">
<t>PDP initiated Service Function Discovery <list>
<t>Upon receiving service request, PDP send path computation
request to Topo server.</t>
</list><vspace blankLines="1" /></t>
</list></t>
<t>The Service request carries various constraint information or
resource requirements(e.g., SF location constraint, SF order
constraint, SF capability information) The topo Server looks up
service topology information and returns either computed path or path
profile Identifier to the PDP. In the centralized approach, the Topo
server will return computed path to the PDP. In the distributed
approach, the Topo server will send computed path to the SF Ingress
Node. In the half centralized approach, the Topo server will only
return path profile Identifier to the SF Ingress Node.</t>
</section>
<section title="Service Function Map Selection">
<t>In either PDP initiates Service Function Discovery or SF Ingress
Node Initiated Service Function Discovery, PDP 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="Building Service Function Chaining (SFC) Policy Tables">
<t>In case of SFC ingress node initiated Service Function Discovery,
the SFC ingress node retrieves path profile Identifier in the half
centralized approach and retrieves service Function Map and associated
Service Function Map index from the Topo server in the distributed
approach. The SFC ingress Node can create entries in the Policy Table
based on Service Function Map obtained from the Topo server.</t>
<t>In case of PDP initiated Service Function Discovery, the PDP
retrieve computed path information from topo server and compose
service Function Map based on computed path information and create
entries in the Policy Table .</t>
</section>
<section title="Service Function Chaining Path Setup and Policy configuration">
<t>In case of SFC ingress node initiated Service Function Discovery,
SFC ingress node initiate signaling to establish the service chaining
path. Path Profile ID can be carried in the RSVP-TE message and
populated to each SF Node in the Service Function Chain. When each SF
node receives Path Profile ID, it will pull policy table based on Path
Profile ID from PDP.</t>
<t>In case of PDP initiated Service Function Discovery, PDP will use
I2RS interface and communicate policy with each SF node in the Service
Function Chain. A set of policy templates can be pre-defined, as shown
in Figure 3. By applying policy template, different service chains are
pre- provisioned and provided to users. For example, the "DATA_SEC"
template defined in Figure 3 implies you can choose random
combinations of these services provided in the "Service-chain"
list.</t>
<figure>
<artwork>
Policy Template Service-chain list
DLP
DATA_SEC AV
IPS
DPI
SIP
Figure 3 Policy Template
</artwork>
</figure>
</section>
<section title="Service Availability">
<t>In order to check service Function availability for each SF node,
the control channel should be setup between service function and
monitoring system to keep track of state change or performance issue.
The monitoring system can be either collocated with <list
style="symbols">
<t>PDP</t>
<t>or NFVPool Manager</t>
<t>or vswitch as SF node or overlay node in the service
overlay.</t>
</list></t>
<t>When one service Function is not a mandatory service function(e.g.,
HTTP optimization service function) in the Service Function Chain and
break down, this service function can be bypassed from service
Function chain, the service will not be interrupted since other
service functions still work well, but service provided by service
function chain is in the degraded mode. When the service function is a
mandatory service function (e.g., firewall) in the Service Function
Chain and break down, the service will be interrupted before this
service function recovers from failing.</t>
<figure>
<artwork>
^ ^
| |
+--|----------|--+
___________________|__| | |
| | | |
+--------+ Heartbeat | | |
| vFW |----------------->| vSwitch | |
+--------+ | (SF Node) | |
| __________________|__ | |
Fail | | | |
+--|----------|--+
| |
| |
| |
Security Failure
Detection ---->
Process Bypass
Figure 4 Heartbeat Monitoring Process</artwork>
</figure>
</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="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></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></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></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="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></organization>
</author>
<date month="August" year="2006" />
</front>
<seriesInfo name="RFC" value="4655" />
</reference>
<reference anchor="ALTO">
<front>
<title>ALTO Protocol</title>
<author fullname="Y.Yang" initials="Y." surname="Yang">
<organization></organization>
</author>
<date month="May" year="2013" />
</front>
<seriesInfo name="ID"
value="http://tools.ietf.org/html/draft-ietf-alto-protocol-16" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:12:53 |