One document matched: draft-lee-nfvrg-resource-management-service-chain-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-nfvrg-resource-management-service-chain-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="Resource Management in Service Chaining">
Resource Management in Service Chaining
</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Seungik 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@korea.ac.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="March" year="2015" />
<!-- 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>Internet Research Task Force (IRTF)</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 specifies problem definition and use cases of NFV resource management in service chaining
for path optimization, traffic optimization, failover, load balancing, etc.
It further describes design considerations and relevant framework for the resource management capability
that dynamically creates and updates network forwarding paths (NFPs) considering resource constraints of NFV infrastructure.
</t>
</abstract>
</front>
<middle>
<!-- Section 1 -->
<section title="Introduction">
<t>
Network Functions Virtualisation (NFV) <xref target="ETSI-NFV-WHITE"/> offers a new way to design,
deploy and manage network services. The network service can be composed of one or more network functions
and NFV relocates the network functions from dedicated hardware appliances to generic servers,
so they can run in software. Using these virtualized network functions (VNFs), the network service
can be described by a service chain (or VNF forwarding graph; VNF-FG) which defines an ordered sequence of
VNFs for the composed service. The VNF-FG can be instantiated by creating or selecting VNF instances and virtual links (VLs)
among them, which results in a network forwarding path (NFP).
</t>
<t>
The performance or state of the NFP depends on the ones of underlying NFVI resources including VNF instances (VNF-Is) and VLs.
For example, if one of the VNF instances in a NFP gets failed, the whole network service using the NFP also gets failed.
Thus, the VNF instances per NFP need to be carefully selected at VNF-FG instantiation or dynamically replaced by other
VNF instances at run-time for better performance and resilience of the NFP.
</t>
<t>
The resource placement problem in service chains matters not only to the quality of NFPs but also to the optimized use of NFVI resources.
For example, if some of the VNF instances and VLs are selected to constitute a NFP but the others are not,
the processing and bandwidth burden will converge on those VNF instances and VLs, which results in scalability problem.
</t>
<t>
This document addresses resource management problem in service chaining to optimize the NFP quality and resource usage.
It provides the relevant use cases of the resource management such as traffic optimization, failover, load balancing
and further describes design considerations and relevant framework for the resource management
capability that dynamically creates and updates NFPs considering resource state of VNF instances.
</t>
<t>
This document mainly focuses on the resource capability in the ETSI NFV framework <xref target="ETSI-NFV-ARCH"/> but also studies
its applicability to the control plane of SFC architecture <xref target="I-D.ietf-sfc-architecture"/>.
<vspace blankLines="1" />
</t>
</section>
<!-- Section 2 -->
<section title="Terminology">
<t>
This document uses the following terms and most of them were reproduced from <xref target="ETSI-NFV-TERM"/>.
</t>
<t>
<list style='symbols'>
<t>Network Functions (NF): A functional building block within a network infrastructure,
which has well-defined external interfaces and a well-defined functional behavior. </t>
<t>Network service: A composition of network functions and defined by its functional and behavioural specification.</t>
<t>NFV Framework: The totality of all entities, reference points, information models and other constructs defined
by the specifications published by the ETSI ISG NFV.</t>
<t>Virtualised Network Function (VNF): An implementation of an NF that can be deployed on
a Network Function Virtualisation Infrastructure (NFVI).</t>
<t>NFV Infrastructure (NFVI): The NFV-Infrastructure is the totality of all hardware and software components
which build up the environment in which VNFs are deployed.</t>
<t>NF Forwarding Graph: A graph of logical links connecting NF nodes for the purpose of describing traffic
flow between these network functions.</t>
<t>VNF Forwarding Graph (VNF-FG): A NF forwarding graph where at least one node is a VNF.</t>
<t>Virtual Link: A set of connection points along with the connectivity relationship between them and
any associated target performance metrics (e.g. bandwidth, latency, QoS).
The Virtual Link can interconnect two or more entities (VNF components, VNFs, or PNFs).</t>
<t>Scaling: Ability to dynamically extend/reduce resources granted to the Virtual Network Function (VNF) as needed.</t>
</list>
</t>
</section>
<!-- Section 3 -->
<section title="Resource management in service chain">
<t>
The goal of the resource management is to optimize the quality of network services and resource usage of NFVI.
To meet this goal, NFPs of the network services need to consider the state of NFV resources
(such as VNF instances or virtual links) at construction. The NFPs also need to dynamically adapt to
the changes of the resource state at run-time, such as availability, load, and topological locations of VNF instances;
latency and bandwidth of virtual links.
The adaptation of NFPs can be executed by monitoring the resource state of VNF instances and VLs and replacing the
original VNF instances of the NFP with new VNF instances that constitute a NFP with better performance.
This functionality can be a part of Orchestrator functional building block in the NFV framework <xref target="ETSI-NFV-MANO"/>
but it needs further study.
</t>
<section title="Use cases">
<t>In this section, several (but not exhausted) use cases for resource management in service chaining are provided: fail-over, path optimization,
traffic optimization, load balancing, and energy efficiency.</t>
<t>Fail-over</t>
<t>When one of VNF instances in a NFP gets failed to run due to failure of its VM or underlying network,
the whole chain of network service also gets failed. For service continuity, the failure of VNF instance
needs to be detected and the failed one needs to be replaced with the other one which is available to use.
<xref target='fig_1' /> presents an example of the fail-over use case. A network service is defined as a chain of VNF-A
and VNF-B; and the service chain is instantiated with VNF-A1 and VNF-B1 which are instances of VNF-A and VNF-B
respectively. In the meantime, failure of VNF-B1 is detected so that VNF-B2 replaces the failed one for fail-over of the NFP.</t>
<figure anchor='fig_1' title='A fail-over use case'>
<artwork>
+--------+ +--------+
| VNF-B2 | #| VNF-B2 |###
+--------+ +--------+ +--------+ # +--------+
###| VNF-A1 | _|_ ###| VNF-A1 |# _|_
+--------+ (___) +--------+ (___)
___/ # / \ \ ___/ / \
(___)+---#------+ + ===} (___)+----------+ +
# \ ___ / / \ ___ /
# (___) (___)
# | |
# +--------+ +--------+
######| VNF-B1 |### (failure)--> | VNF-B1 |
+--------+ +--------+
### NFP
</artwork>
</figure>
<t>Path optimization</t>
<t>Traffic for a network service traverses all of the VNF instances and the connecting VLs given by a NFP
to reach a target end point. Thus, quality of the network service depends on the the resource constraints
(e.g., processing power, bandwidth, topological locations, latency) of VNF instances and VLs.
In order to optimize the path of the network service, the resource constraints of VNF instances and VLs
need to be considered at constructing NFPs.
Since the resource state may vary in time during the service, NFPs also need to adapt to the changes of
resource constraints of the VNF instances and VLs by monitoring and replacing them at run-time.
</t>
<t>Traffic optimization</t>
<t>A network operator may provide multiple network services with different VNF-FGs and different flows of traffic traverse
between source and destination end-points along the VNF-FGs. For efficiency of network management resource usage,
the NFPs need to be built as to localize the traffic flows or as to avoid bottleneck links shared by multiple traffic flows.
In this case, multiple NFV instances of different NFPs need to be considered together at constructing a new NFP or adapting one.</t>
<t>Load balancing</t>
<t>A single VNF instances may be shared by multiple traffic flows of the same of different network services.
In order to avoid bottleneck points due to overloaded NFV instances, NFPs need to be constructed or maintained
to distribute workloads of the shared VNF instances.</t>
<t>Energy efficiency</t>
<t>Energy efficiency in the network is getting important to reduce impact on the environment so that energy consumption of
VNF instances using VNFI resources (e.g., compute, storage, I/O) needs to be considered at NFP construction or adaptation.
For example, a NFP can be constructed as to make traffic flows aggregated into a limited number of VNF instances as much as
its performance is preserved in a certain level.</t>
</section>
<section title="Design considerations">
<t>To support the aforementioned use cases, it is required to support resource management capability which provides service chain
(or NFP) construction and adaptation by considering resource state or constraints of VNF instances and virtual links among them.
The resource management operations for service chain construction and adaptation can be divided into several sub-actions:</t>
<t>
<list style='symbols'>
<t>Select a VNF instance</t>
<t>Evaluate a VNF instance and a virtual link</t>
<t>Replace a VNF instance to update a NFP</t>
<t>Monitor state or resource constraints of a VNF instance and a virtual link</t>
<t>Migrate a VNF instance to another ones in different locations</t>
</list>
</t>
<t>Note: While scaling-in/out or -up/down of VNF instances is one of the essential actions for NFV resource management,
it is a different approach with a finer granularity than service chain adaptation.
The scaling approach may be integrated together with the service chain adaptaiton but it is still under study.</t>
<t>As listed above, VNF instances are selected or replaced according to monitoring or evaluation results of
performance metrics of the VNF instances and virtual links. Studies about evaluation methodologies and
performance metrics for VNF instances and NFVI resources can be found at <xref target="ETSI-NFV-PER001"/>
<xref target="I-D.liu-bmwg-virtual-network-benchmark"/> <xref target="I-D.morton-bmwg-virtual-net"/>.
The performance metrics of VNF instances and virtual links specific to service chain construction
and adaptation can be defined as follows:</t>
<t>
<list style='symbols'>
<t>availability (or failure) of a VNF instance and a virtual link</t>
<t>a topological location of a VNF instance</t>
<t>a utilization rate of a VNF instance</t>
<t>a throughput of a VNF instance</t>
<t>energy consumption of VNF instance</t>
<t>bandwidth of a virtual link</t>
<t>latency of a virtual link</t>
</list>
</t>
</section>
<section title="Framework">
<t>The resource management functionality for dynamic service chain adaptation takes role of NFV orchestration
with support of VNF manager and Virtualised Infrastructure Manager (VIM) in the NFV framework <xref target="ETSI-NFV-ARCH"/>.
Detailed functional building block and interfaces are still under study.</t>
</section>
</section>
<!-- Section 4 -->
<section title="Applicability to SFC">
<section title="Related works in IETF SFC WG">
<t>IETF SFC WG 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. Basic concept of the service function chaining is similar to
VNF-FG where a network service is composed of SFs and deployed by making traffic flows traversed instances
of the SFs in a pre-defined order.</t>
<t>There are several works in progress in IETF SFC WG for resource management of service chaining.
<xref target="I-D.ietf-sfc-architecture"/> defines SFC control plane that selects specific SFs for a requested SFC,
either statically or dynamically but details are currently outside the scope of the document.
There are other works <xref target="I-D.ww-sfc-control-plane"/> <xref target="I-D.lee-sfc-dynamic-instantiation"/>
<xref target="I-D.krishnan-sfc-oam-req-framework"/> <xref target="I-D.aldrin-sfc-oam-framework"/> which define the control plane functionality
for service function chain construction and adaptation but details are still under study.
While <xref target="I-D.dunbar-sfc-fun-instances-restoration"/> and <xref target="I-D.meng-sfc-chain-redundancy"/>
provide detailed mechanisms of service chain adaptation, they focus only on resilience or fail-over of service function chains.</t>
</section>
<section title="Integration in SFC control-plane architecture">
<t>In SFC WG, <xref target="I-D.ww-sfc-control-plane"/> defines a generic architecture of SFC control plane
with well-defined functional building blocks and interfaces as follows:</t>
<figure anchor='fig_2' title='SFC control plane architecture'>
<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>The service chain adaptation addressed in this document may be integrated into the
Chain Mapping and Forwarding Control functional block and may use the C2 and F interfaces
for monitoring or collecting the resource constraints of VNF intances and VLs.</t>
<t>Note that SFC does not assume that Service Functions are virtualized. Thus, the parameters of
resource constraints may differ, and it needs further study for integration.</t>
</section>
</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;
</references>
<references title="Informative References">
<reference anchor="ETSI-NFV-WHITE">
<front>
<title>NFV Whitepaper 2</title>
<author>
<organization>ETSI</organization>
</author>
<date month="October" year="2013" />
</front>
</reference>
<reference anchor="ETSI-NFV-ARCH">
<front>
<title>ETSI NFV Architectural Framework v1.1.1</title>
<author>
<organization>ETSI</organization>
</author>
<date month="October" year="2013" />
</front>
</reference>
<reference anchor="ETSI-NFV-MANO">
<front>
<title>Network Function Virtualization (NFV) Management and Orchestration V0.6.3</title>
<author>
<organization>ETSI</organization>
</author>
<date month="October" year="2014" />
</front>
</reference>
<reference anchor="ETSI-NFV-TERM">
<front>
<title>NFV Terminology for Main Concepts in NFV</title>
<author>
<organization>ETSI</organization>
</author>
<date month="October" year="2013" />
</front>
</reference>
<reference anchor="ETSI-NFV-PER001">
<front>
<title>Network Function Virtualization: Performance and Portability Best Practices v1.1.1</title>
<author>
<organization>ETSI</organization>
</author>
<date month="June" year="2014" />
</front>
</reference>
<?rfc include='reference.I-D.liu-bmwg-virtual-network-benchmark'?>
<?rfc include='reference.I-D.morton-bmwg-virtual-net'?>
<?rfc include='reference.I-D.ietf-sfc-architecture'?>
<?rfc include='reference.I-D.ww-sfc-control-plane'?>
<?rfc include='reference.I-D.lee-sfc-dynamic-instantiation'?>
<?rfc include='reference.I-D.aldrin-sfc-oam-framework'?>
<?rfc include='reference.I-D.krishnan-sfc-oam-req-framework'?>
<?rfc include='reference.I-D.meng-sfc-chain-redundancy'?>
<?rfc include='reference.I-D.dunbar-sfc-fun-instances-restoration'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 22:02:50 |