One document matched: draft-kim-bmwg-ha-nfvi-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-kim-bmwg-ha-nfvi-01"
ipr="trust200902">
<front>
<title abbrev="Benchmarking High Availability of NFV Inf.">Considerations for
Benchmarking High Availability of NFV Infrastructure</title>
<author fullname="Taekhee Kim" initials="T.Kim" surname="Kim">
<organization abbrev="KT">
KT
</organization>
<address>
<postal>
<street>Infra R&D Lab. KT</street>
<street>17 Woomyeon-dong, Seocho-gu</street>
<city>Seoul</city>
<code>137-792</code>
<country>Korea</country>
</postal>
<phone>+82-2-526-6688</phone>
<facsimile>+82-2-526-5200</facsimile>
<email>taekhee.kim@kt.com</email>
</address>
</author>
<author initials="E. Paik" surname="Paik" fullname="EunKyoung Paik">
<organization abbrev="KT">
KT
</organization>
<address>
<postal>
<street>Infra R&D Lab. KT</street>
<street>17 Woomyeon-dong, Seocho-gu</street>
<city>Seoul</city>
<code>137-792</code>
<country>Korea</country>
</postal>
<phone>+82-2-526-5233</phone>
<facsimile>+82-2-526-5200</facsimile>
<email>eun.paik@kt.com</email>
<uri>http://mmlab.snu.ac.kr/~eun/</uri>
</address>
</author>
<date day="21" month="March" year="2016"/>
<abstract>
<t>This documents lists additional considerations and strategies for benchmarking high availability of NFV infrastructure when network functions are virtualized and performed in NFV infrastructure.</t>
</abstract>
<note title="Requirements Language">
<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">RFC 2119</xref>.</t>
<t/>
</note>
</front>
<middle>
<!-- -->
<!--SECTION 1: Introduction -->
<!-- -->
<section title="Introduction">
<t>As both the amount and variety of traffic massively increase, operators are adopting SDN and NFV, the new paradigm of networking, in order to secure scalability and flexibility. Service providers and venders are developing SDN and NFV solutions to reduce CAPEX and OPEX, focusing on the increment of the scalability and flexibility of the network with programmable networking.</t>
<t>While VNF and NFVI replacing the legacy network devices and operators selecting the fittest one from various products, operators have several issues such as availability, resiliency and immeasurable failures. Above all, they want to ensure the availability of the VNF products and their infrastructures.</t>
<t>Customer expectations on the availability of service are as high as five 9s on any infrastructure operators offer because the standard availability of 4G mobile communication on the legacy physical network among operators has been already five 9s; downtime being 5.26 minutes per year. Therefore, to meet the customer expectations, services on the NFV infrastructure also need to meet the availability to that level, five 9s. Furthermore, the availability of NFV infrastructure needs to be almost six 9s with the consideration of the impact of virtualization and interoperability among different vendor solutions and layers. From the operator point of view, the availability is the most important feature and the benchmarking tests for the high availability of NFV infrastructure are also important. This document investigates considerations for high availability of NFV Infrastructure benchmarking test. </t>
</section>
<!-- -->
<!--SECTION 2: Considerations for Benchmarking High Availability of NFV Infrastructure -->
<!-- -->
<section title="Considerations for Benchmarking High Availability of NFV Infrastructure">
<t>This section defines and lists considerations which must be addressed to benchmark the high availability of the NFV infrastructure.</t>
<!-- -->
<!--SECTION 2.1: Definitions for high availability test -->
<!-- -->
<section title="Definitions for High Availability Benchmarking Test">
<t>Metrics for high availability Benchmarking of NFV infrastructure are as follows.</t>
<t><list style="symbols">
<t>Failure Detection Time : the time takes to detect a failure</t>
<t>Failure Recovery Time : the time takes to recover the failure </t>
<t>Failure Rates : the frequency of failures</t>
<t>Success Rates of Detection Time : the percentage of success among a number of attempts to detect failures</t>
<t>Success Rates of Recovery : the percentage of success among a number of attempts to recover the failures</t>
<t>Failure Impact Fraction : the fraction of the infrastructure when a failure happens</t>
</list></t>
<t>Generally, availability and failure rates are defined as follows, where MTBF stands for Mean Time Between Failure and MTTR stands for Mean Time To Recovery.</t>
<t>Availability : MTBF / (MTBF + MTTR)</t>
<t>Failure Rates : 1 - Availability</t>
<t>A failover procedure in an infrastructure is as follows.</t>
<t>Failure -> Failure Detection -> Isolation -> Recovery, therefore failover time starts from the time when a failure happens.</t>
</section>
<!-- -->
<!--SECTION 2.2: Configuration Parameters for Benchmarking Test -->
<!-- -->
<section title="Configuration Parameters for Benchmarking Test">
<t><list style="symbols">
<t>Types of VNFs; depending on the type of VNF, followings are different.
<list style="numbers">
<t>What kind of operations they do</t>
<t>How many CPUs, MEMs, Storages they need</t>
<t>What kind of traffic pattern they usually face</t>
</list>
</t>
<t>The specification of the physical machine which VMs</t>
<t>The mapping ratio of hardware resources to VMs(virtual machine) where VNF runs, such as vCPU:pCPU (virtual CPU to physical CPU), vMEM:pMEM (virtual memory to physical memory), vNICs as shown below.</t>
<t>Types of hypervisor and the different limitations of their roles.</t>
<t>Cloud Design Pattern of NFVI</t>
<t>The composition of network functions in VNFs : for example, sometimes in vEPC implementations, PGW(Packet Data Network Gateway) and SGW(Serving Gateway) are combined or PGW+SGW+MME.</t>
</list></t>
<t><figure align="center">
<artwork>
+---------------+ +---------------+
| vCPU for VNF1 | | |
+---------------+ | vCPU for VNF2 |
+---------------+ | | +---------------+
| vCPU for VNF2 | +---------------+ | vCPU for VNF1 |
+---------------+ +---------------+
+---------------+ +---------------+ +---------------+ +---------------+
| vCPU for VNF3 | | vCPU for VNF2 | | vCPU for VNF3 | | vCPU for VNF3 |
+---------------+ +---------------+ +---------------+ +---------------+
+---------------+ +---------------+ +---------------+ +---------------+
| pCPU 1 | | pCPU 2 | | pCPU 3 | | pCPU 4 |
+---------------+ +---------------+ +---------------+ +---------------+
</artwork>
</figure></t>
</section></section>
<!-- -->
<!--SECTION 3: High Availability Benchmarking test strategies -->
<!-- -->
<section title="High Availability Benchmarking test strategies">
<t>This section discusses benchmarking test strategies for high availability of NFV infrastructure. For the continuity of the services, followings needs to be considered.</t>
<!-- -->
<!--SECTION 3.1: Single Point of Failure Check -->
<!-- -->
<section title="Single Point of Failure Check">
<t>All devices and software have potential failures, therefore, redundancy is mandatory. First, the redundancy implementation of every sing point of NFV infrastructure must be tested as shown below. </t>
<t><list style="symbols">
<t>Hardware
<list style="symbols">
<t>Power supply</t>
<t>CPU</t>
<t>MEM</t>
<t>Storage</t>
<t>Network :NICs, ports, LAN cable, .. </t>
</list></t>
</list></t>
<t><list style="symbols">
<t>Software
<list style="symbols">
<t>The redundancy of VNFs</t>
<t>The redundancy of VNFs path</t>
<t>The redundancy of OvS</t>
<t>The redundancy of vNICs</t>
<t>The redundancy of VMs</t>
</list></t>
</list></t>
<t><figure align="center">
<artwork>
+--------------------------------------------------------------+
| Physical Machine |
| |
| |
| +--------------------------------------------------------+ |
| | Virtual Network Function | |
| +--------------------------------------------------------+ |
| +--------------------------------------------------------+ |
| | Virtual Machine | |
| +--------------------------------------------------------+ |
| +--------------------------------------------------------+ |
| | Virtual Bridge | |
| +--------------------------------------------------------+ |
| +--------------------------------------------------------+ |
| | Hypervisor | |
| +--------------------------------------------------------+ |
| +--------------------------------------------------------+ |
| | Operating System | |
| +--------------------------------------------------------+ |
| +--------------------------------------------------------+ |
| | Generic Hardware | |
| +--------------------------------------------------------+ |
+--------------------------------------------------------------+
</artwork>
</figure></t>
</section>
<!-- -->
<!--SECTION 3.2: Failover Time Check-->
<!-- -->
<section title="Failover Time Check">
<t>Even though the components of NFV infrastructure are redundant, failover time can be long. For example, when a failure happens, the VNF with failure stops and should be replaced by backup VNF but the time to be shifted to the new VNF can be varied with the VNF; stateless or stateful. Namely, redundancy does not guarantees high availability and short failover time is required to reach high availability. This section discusses strategy about measuring failover time.</t>
<t>In order to measure the failover time presicely, the time when failure happens must be defined. Followings are three different criteria which is the time when failure happens.</t>
<t><list style="numbers">
<t>The time starts when failure actually happens</t>
<t>The time starts when failure detected by manager or controller</t>
<t>The time starts when failure event alerts to the operator</t>
</list></t>
<t>As the actual operations in VNFs and NFV infrastructure start to be changed when failure happens, the precise time of the failure happened must be the 1. When measuring the failover time, it starts from the time when the failures happens at a point in NFV infrastructure or VNF itself.</t>
</section>
</section>
<!-- -->
<!--SECTION 4: Security Considerations -->
<!-- -->
<section title="Security Considerations">
<t>
TBD.
</t>
</section>
<!-- -->
<!--SECTION 5: IANA Considerations -->
<!-- -->
<section anchor="IANA" title="IANA Considerations">
<t>No IANA Action is requested at this time.</t>
</section>
</middle>
<!-- -->
<!--SECTION 6: References -->
<!-- -->
<back>
<references title="Normative References">
<?rfc ?>
<?rfc include="reference.RFC.2119"?>
<reference anchor="NFV.REL001">
<front>
<title>Network Function Virtualization: Resiliency Requirements</title>
<author fullname="ETSI NFV" initials="" surname="">
<organization/>
</author>
<date month="January" year="2015"/>
</front>
<seriesInfo name="Group Specification"
value="ETSI GS NFV-REL 001 V1.1.1 (2015-01)"/>
<format type="PDF"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:43:51 |