Internet DRAFT - draft-liu-nfvrg-analytic-framework
draft-liu-nfvrg-analytic-framework
Network Working Group
Internet Draft V.liu
Intended status: Standards Track China Mobile
Expires: September 2016 March 21, 2016
Analytic Framework for NFV Orchestrator
draft-liu-nfvrg-analytic-framework-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
This Internet-Draft will expire on September 21, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Liu Expires September 21, 2016 [Page 1]
Internet-Draft draft-liu-nfvrg-analytic-framework-00 March 2016
carefully, as they describe your rights and restrictions with
respect to this document.
Abstract
This draft introduces an analytic model and framework with data
collection and policy management in NFV Orchestrator.
Table of Contents
1. Introduction ................................................ 2
2. Data collection and policy inventory......................... 3
2.1. Data collection framework............................... 3
2.2. Policy inventory........................................ 4
3. Analytic model and framework................................. 5
3.1. The real-time analytic mode ............................ 6
3.2. The non-real-time analytic model........................ 8
4. Analytic framework in NFV Orchestrator....................... 9
5. Security Considerations..................................... 10
6. IANA Considerations ........................................ 10
7. Conclusions ................................................ 10
8. References ................................................. 10
8.1. Normative References................................... 11
8.2. Informative References................................. 11
9. Acknowledgments ............................................ 11
1. Introduction
As NFV being researched, we have observed more and more research
started focusing on NFV Orchestrator. Most research in Orchestrator
is to address issues around orchestrator architecture, task
fulfillment, status monitoring as well as network analytic and
policy management.
In this draft, we would like to focus on discussing the network
analytic and policy management (FAPM) module. After that, we will
introduce some Orchestrator architecture, feature and the
relationship with FAPM module. We propose this draft because we
believe FAPM will play an important role in future network
orchestration. We have researched and implemented the features of
orchestration task fulfillment and VIM resource monitoring. In the
GUI, the network operator can define Network Service, manage VNF
lifecycle (e.g. create, terminate, scale in/out), monitor its status
from VIM ceilometer. However, the current network policy is simple
and pre-set in orchestrator. If the FAPM module can be integrated
into this orchestration loop (monitor->FAPM->fulfillment), we may
Liu Expires September 21, 2016 [Page 2]
Internet-Draft draft-liu-nfvrg-analytic-framework-00 March 2016
create a more 'intelligent' network orchestration and policy
management.
In section 2 of this draft, we would like to introduce the
capability of data monitor and collection attributes by
Orchestrator. Besides, the policy inventory is also important to
introduce in this section.
In section 3, we proposed the analytic model and framework for FAPM
module. The real-time analytic model and the non-real-time analytic
model are described respectively. We present one data mining
techniques for the real-time analytic model, and provide the
expectation for the non-real-time analytic model.
In section 4, we describe the Orchestrator architecture along with
introduction of how FAPM module fits in this architecture.
2. Data collection and policy inventory
2.1. Data collection framework
The orchestrator is more like a central brain to provide a global
manage and control of the network resource as well as the logical
network service (e.g. NS model, SFC). By our research, we have
onboard of several network elements (VNF) from different venders,
such as vEPC, vIMS, vCPE, vBRAS and Nanocell Gateway. Above those
VNFs, Data Collection Framework in Orchestrator is response of
collecting status attribute. We have discovered that this work is
not easy to accomplish due to the unfinished definition of
monitoring API. Therefore, we propose a Data Collection Framework
as below in Figure 1.
Liu Expires September 21, 2016 [Page 3]
Internet-Draft draft-liu-nfvrg-analytic-framework-00 March 2016
---------------------------------------
| Data Collection Framework |
| in Orchestrator |
---------------------------------------
| | |
| | |
| | -------
| | L3| NS Mgr|
| | -------
| -----------------
| L2| VNFs from VNFM |
| -----------------
-----
L1| VIMs|(Resource pool monitoring)
-----
Figure 1: The framework of data collection
The monitoring data collection consists of three layers. The first
layer is connecting between VIM and Orchestrator to collect resource
pool status, like CPU usage, Memory usage, File-system usage and
Nic(network) usage. The second layer is connecting between VNFM and
Orchestrator to collect VNFs status. In addition, the third layer is
connecting between NS manager and Orchestrator to collect service
status.
2.2. Policy inventory
Conceptually, the policy is the key to trigger the network
management action such as scale in/out. The analytic model will
calculate the decision to hit the particular policies from policy
inventory. For the policy in Orchestrator, previously there are
simple pre-set policies, such as an attribute of a threshold value
for VNF scaled up. When the status reaches the attribute threshold
value, the system will trigger the policy action. However, the real
situation of network is unstable or fluctuant. For example, we
assume that the attribute value to trigger the scale-out action is
by the CPU usage. The real situation is there are lots of peaks of
CPU usage's curve that over threshold value. How did the system
decide to trigger the action of scaling out? With this question, we
propose a closed circle to work out this problem, shown in Figure 2.
Liu Expires September 21, 2016 [Page 4]
Internet-Draft draft-liu-nfvrg-analytic-framework-00 March 2016
---------- -------- ----------------- ------
|Collection|>>>|Analysis|>>>| decision making|>>>|Policy|
---------- -------- ----------------- ------
|| ||
|| ||
|| ------- ||
<===============|Monitor|<======================
-------
Figure 2: The closed circle of FAPM
In Figure 2, the collection model depicts the data collection
mentioned previously. The block of analysis depicts the analytic
model described in the following section. It provides data analysis
to predict the results or make decisions thus trigger the hit in
policy inventory. The monitor block provides the feedback of the
circle.
3. Analytic model and framework
As the development of Orchestrator, a more intelligent trend wishes
to be researched and exploited. One of the FAPM's function, analytic
model, is designed for achieve the goal.
As tons of the status attribute data are collected, we cannot
directly obtain the relationship among them. However, data analysis
can be implemented to process and model the data to trigger the
conclusion and decision-making to the orchestrator. Data mining is a
particular data analysis technique that focuses on modeling and
knowledge discovery for predictive [wiki]. It is a promising yet
challenge direction to enforce into the Orchestrator.
The analytic module in the Orchestrator can be divided into two
parts. One is the real-time analysis which can provide an on demand
network policy delivery for features such as dynamic scale in/out or
auto-healing, etc. The other one is the non-real-time analysis that
process batch data (e.g. log, etc.) and provide for static analysis
and global resource planning. For real-time analytic model, we
propose K-nearest neighbor (KNN) algorithm, because KNN can be
realized in this analysis to assistant other components making real-
time response. In non-real-time analytic model, unfortunately, the
collection module has not accomplished, we just bring out an
assumption of using decision trees learning, or neural networks.
Liu Expires September 21, 2016 [Page 5]
Internet-Draft draft-liu-nfvrg-analytic-framework-00 March 2016
3.1. The real-time analytic model
The real-time analytic model is a significantly dynamic part that is
processing the real-time data and predicting results or trends for
employing by other components, like optimized resource, work
distribution, etc. It requires a real-time method to attain the
target of quickly response and opportunely updating model.
Accordingly, the real-time KNN algorithm is proposed to realize the
goal.
Firstly, KNN algorithm is a type of instance-based learning, or lazy
learning used for classification. The input consists of the k
closest training examples in the feature space, and the output
depends on a majority vote of its neighbors, with the object being
assigned to the class most common among its k nearest neighbors. It
assumes all the instances correspond to points in the n-dimensional
space.
In the training phase, the algorithm only stores the training data
and their corresponding labels. More precisely, an instance x can be
described as
[a1(x), a2(x), ? an(x)]
where the ai(x) denotes the ith attribute (e.g. CPU utilization or
memory usage or file-system usage or nic usage or etc.) of instance
x, and its corresponded label is marked as l. All kinds of labels
will have their own corresponding relations to the following actions
or events, like the number 1 could present to increase or decrease
the number of virtual machines, etc.
In the classification phase, one defined number of k should be
provided, and a testing instance y (or an unlabeled instance) is
classified by assigning the label which is most frequent among the k
training samples nearest to that query point [wiki]. Generally, the
standard Euclidean distance is utilized to define the nearest
neighbor of an instance as
d(x,y)=sqrt(sum(ai(x)-ai(y))^2)
where d(x,y) denotes the distance between x and y. After obtaining
the distance matrix D between the testing instance y and all
training instances, the nearest k neighbors could be utilized to
vote the label of the testing instance y.
Liu Expires September 21, 2016 [Page 6]
Internet-Draft draft-liu-nfvrg-analytic-framework-00 March 2016
Figure 3 illustrates an example of implementing the KNN algorithm,
where the instances are points in a two-dimensional space and the
labels are marked by different numbers. For example, the two-
dimensional space could include two arbitrary attributes of
collected data, like CPU usage and memory usage. The marked numbers
could present the action of scaling up, scaling down or termination.
The testing instance y is shown as well. If the k is assumed as 5, y
will be classified as class 1 by voting. Furthermore, this algorithm
also can be implemented to analyze for either low-dimensional or
high-dimensional data. It can be easily to extend the example of
two-dimensional space to a higher dimension by increasing the number
of attributes.
-------------------------------------------
| |
| .1 .3 |
| ** |
| * * .1 |
| * .1 * |
| * .1 * |
| * .2 * .2 |
| * .y * |
| .2 * .3 * |
| * .2 * .3 |
| * .1 * |
| * * |
| ** |
| .3 .1 |
| .2 |
| .2 |
| .2 |
--------------------------------------------
Figure 3: An example of KNN algorithm
Based on the KNN algorithm, our purpose is to achieve the real-time
analytic model. Figure 4 describes the real-time model implemented
in the KNN algorithm. Firstly, the same process is implemented to
classify the testing data. In addition, there will be a detection
model to check the label of it. If the label does not generate some
anomalies, the testing data can be added into the training database
to achieve the real-time analysis and update the training dataset.
Liu Expires September 21, 2016 [Page 7]
Internet-Draft draft-liu-nfvrg-analytic-framework-00 March 2016
======================================
|| ||
|| ||
------- -------- ------- ---------
|Testing|>>>| KNN |>>>| Result|>>>|Decision |
| Data | |analytic| | | | |
------- -------- ------- ---------
|| ||
|| ||
|| ||
|| --------
||=======>|Training|
| Data |
--------
Figure 4: The model of real-time KNN algorithm
KNN algorithm is one of the most fundamental and simple
classification methods, which can be relatively easy to understand.
In addition, it is a non-parametric method that can omit the process
of setting and optimizing parameters. On the contrary, KNN algorithm
is computationally expensive, and requires lots of memory.
Fortunately, the orchestration usually implemented by cloud
computing which can overcome the weakness. Moreover, there are other
solutions to improve this algorithm, like dimensionality reduction,
optimized training dataset, etc.
Eventually, the real-time analytic model is proposed. It is achieved
by the real-time KNN algorithm to predict the outcomes or
directions. Furthermore, the real-time analytic model can fulfill
the dynamic control, which can assistant the Orchestrator to achieve
a more intelligent way.
3.2. The non-real-time analytic model
For the non-real-time analytic model, it still plays an
indispensable role to help the system to predict the future
situation. It needs a pre-trained model to obtain the prediction of
the following situation. In the case of that, it can help other
components to achieve static analysis, etc. Therefore, the method of
data mining (e.g. decision tree learning, neural networks, etc.) is
a promising direction to deal with this.
Liu Expires September 21, 2016 [Page 8]
Internet-Draft draft-liu-nfvrg-analytic-framework-00 March 2016
4. Analytic framework in NFV Orchestrator
In this section, we would like to introduce the architecture of
Orchestrator and how analytic and policy management (FAPM) modules
fit in this Architecture. Since we initiate the Open-O project from
mid-2015, we have finished most work in task fulfillment and
monitoring. The architecture with analytic and policy is shown below
in Figure 5.
***************
---------------------* NBI *----------------------
| *************** |
| ---------- -------------- |
| | Model | | NS Lifecycle | |
| -------- ---------- | Designer | | Manager | |
| | | | | ---------- ------------- |
| | | | | ---------- ------------- |
| | | | Policy | | Catalog | | Work Flow | |
| |Analytic| | Inventory| ---------- ------------- |
| | | | | -------- ------- |
| | | | | |Resource| |Monitor| |
| | | | | |Manager | | | |
| -------- ---------- -------- ------- |
| --------------------------------------------------- |
| | Data Collection framework | |
| --------------------------------------------------- |
-----------------------------------------------------------
| |
| -----------
| | Multi |
| | VNFMs |
| -----------
-------------
| Multi VIMs |
-------------
Figure 5: The architecture with analytic and policy
From down to top, the Orchestrator supports Multi VIMs, such as
OpenStack, as well as multi VNFMs, such as tacker, Huawei VNFM and
other 3rd party VNMFs. With help of those VNFMs, we have onboard
VNFs such as vEPC, vIMS, vBras, vCPE and Nanocell Gateway.
On the top of VIM and VNFM, the Orchestrator acts like a central
brain of the network. There can be divided as three parts.
Liu Expires September 21, 2016 [Page 9]
Internet-Draft draft-liu-nfvrg-analytic-framework-00 March 2016
The first part is the FAPM module which include Data Collection
Platform, Analytic and Policy Inventory. The Data Collection
Platform is response for collection status form VIM, VNFM and NS
which are discussed in section 2 and provides internal API for
Analytic, Policy Inventory and Monitor module to use. The Analytic
module is in charge of processing the network analysis and provide
decision-making from the Policy Inventory. The Policy Inventory
currently reposits policies which are input from NBI manually.
The second part of Open-O is Resource Orchestrator (OR) which
includes Resource manager and Monitor. The resource manager is in
charge of manager the connection with VNFM to globally manager the
VNF and VIM resource. And the Monitor is called from the Data
Collection Platform to get the system status.
The third part of Open-O is Network Service Orchestrator(NSO) which
includes Model Designer, Catalog, NS lifecycle Manager and workflow
engine. Model Designer can provide network operator and user a GUI
that allows them to design the network topology and create data
model of VNF, NS, VNFG, VL. The Catalog can store the VNF, NS, VNFG,
VL data model. NS lifecycle manager is for NS level scale in/out.
Workflow engine assist the lifecycle management process by
interacted with internal and external modules.
5. Security Considerations
6. IANA Considerations
7. Conclusions
In this draft, we have introduced data collection framework. And
bring out an analytic model and framework with Orchestrator status
data. At last, we introduced the analytic and policy architecture
with Orchestrator.
8. References
Liu Expires September 21, 2016 [Page 10]
Internet-Draft draft-liu-nfvrg-analytic-framework-00 March 2016
8.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
8.2. Informative References
[3] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in TCP
and Its Effect on Busy Servers", Proc. Infocom 1999 pp. 1573-
1583.
[Fab1999] Faber, T., Touch, J. and W. Yue, "The TIME-WAIT state in
TCP and Its Effect on Busy Servers", Proc. Infocom 1999
pp. 1573-1583.
9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
This draft is also contributed by Yuan Liu from China Mobile.
Authors' Addresses
Vic Liu
China Mobile
32 Xuanwumen West AVE, Xicheng, Beijing
Email: liuzhiheng@chinamobile.com
Liu Expires September 21, 2016 [Page 11]
