One document matched: draft-lee-sfc-dynamic-instantiation-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="info" docName="draft-lee-sfc-dynamic-instantiation-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="yes" ?>
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary
if the
full title is longer than 39 characters -->
<title abbrev="SFC dynamic instantiation">
SFC dynamic instantiation
</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Seung-Ik Lee" initials="S. Lee" surname="Lee">
<organization abbrev="ETRI">ETRI</organization>
<address>
<postal>
<street>218 Gajeong-ro Yuseung-Gu</street>
<!-- Reorder these if your country does things differently -->
<city>Daejeon</city>
<region></region>
<code>305-700</code>
<country>Korea</country>
</postal>
<phone>+82 42 860 1483</phone>
<email>seungiklee@etri.re.kr</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Sangheon Pack" initials="S. Pack" surname="Pack">
<organization abbrev="KU">Korea University</organization>
<address>
<postal>
<street>145 Anam-ro, Seongbuk-gu</street>
<!-- Reorder these if your country does things differently -->
<city>Seoul</city>
<region></region>
<code>136-701</code>
<country>Korea</country>
</postal>
<phone>+82 2 3290 4825</phone>
<email>shpack@etri.re.kr</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Myung-Ki Shin" initials="M-K. Shin" surname="Shin">
<organization abbrev="ETRI">ETRI</organization>
<address>
<postal>
<street>218 Gajeong-ro Yuseung-Gu</street>
<!-- Reorder these if your country does things differently -->
<city>Daejeon</city>
<region></region>
<code>305-700</code>
<country>Korea</country>
</postal>
<phone>+82 42 860 4847</phone>
<email>mkshin@etri.re.kr</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="EunKyoung Paik" initials="E. Paik" surname="Paik">
<organization abbrev="KT">KT</organization>
<address>
<postal>
<street>17 Woomyeon-dong, Seocho-gu</street>
<!-- Reorder these if your country does things differently -->
<city>Seoul</city>
<region></region>
<code>137-792</code>
<country>Korea</country>
</postal>
<phone>+82 2 526 5233</phone>
<email>eun.paik@kt.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="October" year="2014" />
<!-- If the month and year are both specified and are the current ones,
xml2rfc will fill
in the current day for you. If only the current year is specified,
xml2rfc will fill
in the current day and month for you. If the year is not the current one, it
is
necessary to specify at least a month (xml2rfc assumes day="1" if not
specified for the
purpose of calculating the expiry date). With drafts it is normally
sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Service function Chaining</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF.
-->
<keyword>Internet Draft</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
This document describes a control plane architecture for dynamic instantiation
of service function chains which dynamically creates and adapts service function
paths to optimize performance of the service function paths. This document further
defines basic operations for the dynamic instantiations; and performance metrics of
service function path components, i.e., service function instances and forwarding
links among service function forwarders for evaluation of the service function path.
</t>
</abstract>
</front>
<middle>
<!-- Section 1 -->
<section title="Introduction">
<t>
The current service delivery model is bound to static topologies and manually
configured resources. This has motivated a more flexible deployment model which
orchestrates the service delivery separated from the network. Service function
chaining <xref target="I-D.ietf-sfc-problem-statement"/> provides a new service deployment model that
delivers the traffic along the predefined logical paths of service functions (SFs),
called service function chains (SFCs) with no regard of network topologies or
transport mechanisms.
</t>
<t>
A SFC is determined by classification of target traffic based on operator's policy.
Since it is described with logical SFs, the service function chain needs to be
instantiated by selecting instances of the SFs, which results in a service function path (SFP).
Performance of a SFP depends on the current state or attributes (e.g., availability,
topological location, and latency) of SFP components (i.e., SF instances (SFIs) and
forwarding links among SFFs (SFLs)). Thus, the SFP performance may vary according to which
SFIs are selected at SFC instantiation; and it may also vary in time with the state or attributes
of the SFP components.
</t>
<t>
This document describes a control plane architecture for dynamic instantiation of SFCs
which dynamically creates and adapts SFPs to optimize the SFP performance considering
the current state and attributes of SFIs and SFLs. This document further defines basic
operations for the dynamic instantiations and performance metrics of SFP components for
SFP evaluation.
</t>
</section>
<!-- Section 2 -->
<section title="Terminology">
<t>
This document uses the following terms and most of them were reproduced from
<xref target="I-D.ietf-sfc-problem-statement"/> and <xref target="I-D.ietf-sfc-architecture"/>.
</t>
<t>
<list style='symbols'>
<t>Classification: Locally instantiated policy and customer/network/service profile
matching of traffic flows for identification of appropriate outbound forwarding actions.</t>
<t>Service Function Chain (SFC): A service function chain defines a set of abstract
service functions and ordering constraints that must be applied to packets and/or frames
selected as a result of classification. The implied order may not be a linear progression
as the architecture allows for SFCs that copy to more than one branch, and also allows for
ere there is flexibility in the order in which service functions need to be applied.
The term service chain is often used as shorthand for service function chain.</t>
<t>Service Function (SF): A function that is responsible for specific treatment of received packets.
A Service Function can act at various layers of a protocol stack (e.g., at the network layer or
other OSI layers). As a logical component, a Service Function can be realized as a virtual element
or be embedded in a physical network element. One or multiple Service Functions can be embedded
in the same network element. Multiple occurrences of the Service Function can exist in the same
administrative domain.</t>
<t>Service Function Instance (SFI): The instantiation of Service Function that can be a
virtual instance or be embedded in a physical network element. One of multiple Service
Functions can be embedded in the same network element. Multiple instances of the Service
Function can be enabled in the same administrative domain.</t>
<t>Service Function Forwarder (SFF): A service function forwarder is responsible for
delivering traffic received from the network to one or more connected service functions
according to information carried in the SFC encapsulation, as well as handling traffic
coming back from the SF. Additionally, a service function forwarder is responsible for
delivering traffic to a classifier when needed and supported, mapping out traffic to another
SFF (in the same or different type of overlay), and terminating the SFP.</t>
<t>Service Function Path (SFP): The SFP provides a level of indirection between the
fully abstract notion of service chain as a sequence of abstract service functions to
be delivered, and the fully specified notion of exactly which SFF/SFs the packet will
visit when it actually traverses the network. By allowing the control components to specify
this level of indirection, the operator may control the degree of SFF/SF selection authority
that is delegated to the network.</t>
<t>Service Forwarding Link (SFL): An overlay link between two SFFs over which the packet
will visit SF along the SFP.</t>
</list>
</t>
</section>
<!-- Section 3 -->
<section title="SFC dynamic instantiation">
<t>
A service function chain is composed of one or more logical service functions and
it can be further instantiated with a SFP which contains physical instances of the logical SFs.
Since multiple instances of a SF may be available, different sets of SFI (i.e., SFPs) can be built per SFC.
</t>
<t>
For example in <xref target='fig_1' />, a SFC {SF1 -> SF2 -> SF3} selected for a traffic flow can be further
instantiated with two different SFPs: SFP#1 {SF1_a -> SF2_a -> SF3_a} and SFP#2 {SF1_b -> SF2_b -> SF3_b}
by selecting one of multiple instances of the service functions.
</t>
<figure anchor='fig_1' title='SFC instantiation'>
<artwork>
+------+ +------+ +------+
SFC | SF1 |-----------| SF2 |-----------| SF3 |
+------+ +------+ +------+
+------+ +------+ +------+
|SF1_a | |SF2_a | |SF3_a |
+------+ +------+ +------+
SFP#1 | | |
******** ******** ********
* SFF *-----------* SFF *-----------* SFF *
******** SFL ******** SFL ********
SFP#2 | | |
+------+ +------+ +------+
|SF1_b | |SF2_b | |SF3_b |
+------+ +------+ +------+
</artwork>
</figure>
<t>
Under this abstraction, a SFC can be constructed by the following operations:
</t>
<t>
<list style='symbols'>
<t>Classification: One SFC is selected and identified by a classification
function according to the traffic steering policy defined by the network operator.
The policy just logically defines which service functions must be applied to traffic
flows in a specific order.</t>
<t>Re-classification (or branching): According to an intermediate result of packet
treatment, the current SFC can be updated by adding or removing SFs, which results
in creation of a new SFP.</t>
<t>SFC instantiation: In order to define the physical forwarding paths for the traffic,
the SFC needs to be instantiated to a SFP by selecting a specific instance of each service
function that is given in the SFC. The SFP can be updated by replacing one or more
conventional SF instances with the other ones at run-time. Note that it does not
cause change of a SF but change of a physical instance of the same SF.</t>
</list>
</t>
<t>
The SFC instantiation may be static or dynamic. In a static instantiation, specific SF
instances are pre-determined by network operator's configuration or policy.
The static instantiation may be more convenient for network administrators because they
can easily expect the result and troubleshooting locations. However, since it does not
consider the current state and attribute of SFIs, the static instantiation may create more
vulnerable SFPs to state changes of the SFIs such as failure or overload.
</t>
<t>
In a dynamic SFC instantiation, SFIs are selected according to their states and attributes
at time of demand, specifically at initial classification or during intermediate traversal
of the SFP.
</t>
<t>
<list style='symbols'>
<t>At classification: SF instances are selected to initially construct a SFP before
starting to forward the incoming traffic flows</t>
<t>At intermediate traversal: One or more SF instances are selected and dynamically
replaced during traversing the SFP to update the SFP</t>
</list>
</t>
<t>
The example use cases of SFC dynamic instantiation are as follows:
</t>
<t>
<list style='symbols'>
<t>SFP fail-over: re-construct a SFP with replacing the failed SFI with new SFI selected</t>
<t>End-to-end service optimization: construct or maintain a SFP with a low stretch
considering the topological locations of SFI and properties (e.g., latency, bandwidth)
of SFLs</t>
<t>Traffic optimization: construct or maintain SFPs to localize the traffic in the
network considering load and administrative domains of SFIs and SFLs.</t>
<t>Load balancing: construct or maintain SFPs to distribute the load of shared SFIs and SFLs.</t>
</list>
</t>
<t>
For more details about the use cases, refer to
<xref target="I-D.lee-nfvrg-resource-management-service-chain"/>.
</t>
</section>
<!-- Section 4 -->
<section title="Control plane architecture">
<t>
In order to instantiate a SFC dynamically according to the state and attributes of SFP components,
the following functional building blocks are required in a SFC control plane architecture.
</t>
<t>SFC instantiation</t>
<t>
<list style='symbols'>
<t>Evaluate SFIs and SFLs based on the measurements obtained from SFP component management building
block</t>
<t>Select SFIs to construct a SFP optimized according to the evaluation results</t>
<t>Enforce the constructed SFP for incoming traffic to the classification node via interface-(a)</t>
<t>Replace SFIs to update a SFP adapted to changes of state or attributes of SFIs and SFLs</t>
<t>Enforce the updated SFP for upcoming SFC traversal to SFFs via interface-(b)</t>
</list>
</t>
<t>SFP component management</t>
<t>
<list style='symbols'>
<t>Collect and monitor state and attributes of SFIs and SFLs via interface-(d) and interface-(c),
respectively</t>
<t>Provide the collected state and attributes of SFIs and SFLs to SFC instantiation building block
for evaluation</t>
</list>
</t>
<figure anchor='fig_2' title='Control plane architecture for SFC dynamic instantiation'>
<artwork>
#=================================================#
# #
# +---------------+ +---------------+ #
# ____| SFC |______| SFP component | #
# | | instantiation | | management | #
# | +---------------+ +---------------+ #
# | | ^ ^ #
#===|=============|=================|=====|=======#
| | | |
|(a) |(b) |(c) |(d)
| | | |
| | +------+ | +------+
| | | SFI | | | SFI |
| | +------+ | +------+
V V | | |
******** ******** ********
-* CLSF *-------* SFF *-----------* SFF *--------
******** ******** ********
</artwork>
</figure>
<t>
The state and attributes of SFP components for SFP evaluation can be obtained via interface-(c)
and interface-(d). Examples of the state and attributes of SFP components are as follows:
</t>
<t>
<list style='symbols'>
<t>availability (or failure) of a SFI and a SFL</t>
<t>a topological location of a SFI</t>
<t>a utilization rate of a SFI</t>
<t>a throughput of a SFI</t>
<t>energy consumption of SFI</t>
<t>bandwidth of a SFL</t>
<t>latency of a SFL</t>
</list>
</t>
</section>
<!-- Section 5 -->
<section title="Operational procedures">
<t>
(TBD)
</t>
</section>
<!--section anchor="Acknowledgements" title="Acknowledgements">
<t>This template was derived from an initial version written by Pekka
Savola and contributed by him to the xml2rfc project.</t>
<t>This document is part of a plan to make xml2rfc indispensable <xref
target="DOMINATION"></xref>.</t>
</section-->
<!-- Possibly a 'Contributors' section ... -->
<section anchor="Security" title="Security Considerations">
<t>
(TBD)
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
(TBD)
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation
libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here
(as shown)
2. simply use a PI "less than character"?rfc
include="reference.RFC.2119.xml"?> here
(for I-Ds:
include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included
files in the same
directory as the including file. You can also define the XML_LIBRARY
environment variable
with a value containing a set of directories to search. These can be
either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
&rfc2119;
<?rfc include='reference.I-D.ietf-sfc-problem-statement'?>
<?rfc include='reference.I-D.ietf-sfc-architecture'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ww-sfc-control-plane'?>
<?rfc include='reference.I-D.lee-nfvrg-resource-management-service-chain'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 21:42:24 |