Internet DRAFT - draft-yanhuan-anima-policy
draft-yanhuan-anima-policy
Autonomic Networking Integrated Model and Approach H. Yan
Internet Draft Tsinghua University
Intended status: Informational Y. Li
Expires: January 2018 Tsinghua University
H. Sun
Huawei Technologies
C. Xiong
Huawei Technologies
D. Jin
Tsinghua University
Auguest 30, 2017
A Generic Network Policy Model and its Deployment
in Future Wireless Network System
draft-yanhuan-anima-policy-00.txt
Abstract
Recent years have witnessed a rapid development of wireless
communication technologies. Internet Service Providers (ISPs) are
willing to provide customized network services in a very short
time to their customers. However, since network demands are highly
diverse, it is difficult to design the specific network policies
that implement the required network services for each scenario. In
this document, we propose a generic network policy model for
future wireless network systems to meet different network demands
based on the typical scenarios. Meanwhile, to automatically and
intelligently deploy the policies defined by this model, we design
a novel architecture that orchestrates the high-level policies
into the low-level rules available in the underlying networks.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
Yan, et al. Expires February 29, 2018 [Page 1]
Internet-Draft Policy Model and its Application August 2017
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on February 29, 2018.
Copyright Notice
Copyright (c) 2017 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.
Table of Contents
1. Introduction 3
2. Design Objective 4
3. Requirements and Terminology 4
3.1. Requirements 4
3.2. Definition of Terms 4
4. The Network Policy Model 4
4.1. Model Overview 4
4.2. Example 7
5. The Deployment Architecture 7
6. Summary 9
7. Security Considerations 9
8. IANA Considerations 9
9. Informative References 9
10. Acknowledgments 9
1. Introduction
Wireless communication technologies have achieved a great progress
in recent years, which are indispensable in many important
applications such as Internet of Things (IoT), Augmented Reality
(AR). To impel the evolution of wireless network, Internet Service
Providers (ISPs) have increased their investment to construct or
upgrade the network infrastructures, but they can hardly make big
profits. This is because they only provide the services of data
transmission, which is seen as the plumber. To address it, ISPs
have to innovate their service types and open the capability of
customizing network services through web portals.
Yan, et al. Expires February 29, 2018 [Page 2]
Internet-Draft Policy Model and its Application August 2017
However, it is challenging to provide such capabilities. First,
network demands have become more diverse. Different customers
(e.g., enterprises) have different network requirements in their
scenarios. It is expected to provide customized network services
for them on demand. However, it is impractical to design the
specific network policies for each scenario. Therefore, it is
required to design the generic network policy model to meet the
demands. Second, implementing network services often requires
network operators to manually configure network policies, which
leads to low efficiency and is prone to error. Moreover, this
process needs to take much time. To quickly and intelligently
deploy them, an effective approach is needed to compile the
abstract network policies into low-level rules available in the
underlying networks.
Many previous works [Chaithan_pga_sigcomm] have studied the design
of network policy model and its deployment in the proposed network
architecture. However, most of them are applied in the networks
deployed in datacenters. In this document, we design a generic
network policy model in future wireless network systems based on
the typical scenarios. Specifically, we abstract network
connections that can be seen as the most basic policies into
general types. Based on this abstraction, customers can specify
more complicated network policies by adding required network
functions. Furthermore, we propose a novel architecture to
automatically orchestrate high-level policies into low-level rules
that can be used for the underlying networks. This helps to
improve the efficiency of policy deployment and user experience of
network services. Therefore, our proposed policy model and its
implementation approach can benefit ISPs to design their network
systems to provide better network services and gain more revenue.
2. Design Objective
Our proposed network policy model aims at providing generic ways
to define network polices, which is suitable of customers to
conveniently request their on-demand network services. To deploy
them in a short time, we propose a modified architecture to
perform the automatic compilation. Therefore, it is beneficial of
ISPs to design their network systems to improve better network
services.
3. Requirements and Terminology
3.1. Requirements
Based on the separation of the control and forwarding plane, the
future wireless network system requires to support the NFV
capability. Network functions can be implemented by means of the
virtualized technologies used in the generic sever. Thus,
controller can flexibly deploy required network functions in the
underlying networks.
Yan, et al. Expires February 29, 2018 [Page 3]
Internet-Draft Policy Model and its Application August 2017
3.2. Definition of Terms
Network service: This consists of one or more network policies,
which is often provided by the operators.
Network function: It is responsible for processing the specific
packets. A network function can be implemented as a virtual
element in a generic sever or be embedded in a proprietary device.
Network demand: This consists of required network resources.
Service chain: This defines an ordered set of virtual network
functions. For example, firewall can be seen as a virtual network
function.
4. The Network Policy Model
In this section, we introduce our generic network policy model and
illustrate how it can meet different network demands.
4.1. Model Overview
For the customers, when they request network services, they do not
care about the details in underlying networks. In other words,
they focus on network demands associated with their own business.
To design the generic model, we have to reasonably abstract
network policies used in different scenarios
First, we introduce two basic elements in our model: vertex and
edge. We regard a vertex as an endpoint group consisting of
multiple endpoint (i.e., a server, a virtual machine or a user
equipment). Meanwhile, we can specify the attribute tag of the
vertex including the geolocation, tenant and running state. The
edge between two vertexes denotes a forwarding path, which is
directional. Moreover, the edge can be seen as a classifier that
specify packets from/to the required ports or the service chain
consisting of multiple network function elements (e.g., middlebox).
Considering that some policies are performed when the special
conditions are satisfied, we introduce a novel connection mode,
which is called parallel mode. As shown in Figure 1, we define the
edge drawn in dash line as the triggering condition, and the one
drawn in dotted line as the required action. This figure shows
that if the transmission delay between two nodes is greater than
10 ms, it is required to place an accelerator between them to
reduce the delay.
Yan, et al. Expires February 29, 2018 [Page 4]
Internet-Draft Policy Model and its Application August 2017
+----------+
+------|Delay<10ms|------+
| +----------+ |
| v
++ ++
+ + + +
++ ++
. ^
. +-----------+ .
.......|Accelerator|......
+-----------+
Figure 1: The policy described in paralleling form
The network policies are requested on the basis of network
connections. Different scenarios have different demands of network
connections. For example, two network nodes need to communicate
with each other over virtual private network (VPN), which is
regarded as the point-to-point communication. To be closer to
practical scenarios, we divide the network connections into three
types: point to point (seen in Figure 2), point and multiple
points (seen in Figure 3), multiple points to multiple points
(seen in Figure 4).
++ ++
+ +-------->+ +
++ ++
Figure 2: The point-to-point type
++
+ ++
++ |
| ++
+------------>+ +
| ++
++ |
+ ++
++
Figure 3: The point-and-multiple-points type
++ ++
+ ++ >+ +
++ | | ++
| |
+-------------|
| |
++ | | ++
+ ++ >+ +
++ ++
Figure 4: The multiple points to multiple points
Yan, et al. Expires February 29, 2018 [Page 5]
Internet-Draft Policy Model and its Application August 2017
Point-to-point connection is used to establish connection between
two nodes, i.e., the connection over VPN. This is the simplest
connection type since it only involves the original and
destination nodes.
Point and multiple-points connection is an asymmetric connection
type. This is because that network traffic has marked orientation.
Specifically, one node called the producer produces the large
traffic, while other nodes called the consumers consumes the
traffic. The reverse is also the same. The typical example is the
communication between user devices and the server provided by the
content provider.
Multiple-points to multiple-points connection represents the
interconnection among multiple nodes. The nodes in this type are
not only service producers but also consumers. The typical example
is device to device communication.
4.2. Example
Consider a typical IoT scenario. A company needs to establish
network connections to multiple wireless smart devices distributed
in three different regions. Meanwhile, it requires to guarantee
the communication security and reliability. According to our
designed policy model, we can request the network services showed
in Figure 5. Specifically, we can regard the devices in each
region as a virtual endpoint group. The demands between the
company and three endpoint group are the same. To guarantee the
security and reliability, the edge between the company and devices
need to add the firewall and QoS monitor.
+--------------+
|Device group 1+--+
+--------------+ |
|
|
+--------------+ | +--------+ +-----------+ +---------+
|Device group 2+--+------+Firewall+---+QoS monitor+---->Company A|
+--------------+ | +--------+ +-----------+ +---------+
|
|
+--------------+ |
|Device group 3+--+
+--------------+
Figure 5: Point and Multiple points connection in IoT scenario
Yan, et al. Expires February 29, 2018 [Page 6]
Internet-Draft Policy Model and its Application August 2017
5. The Deployment Architecture
In this section, we design a policy deployment architecture to
automatically compile the requested policies into forwarding rules
and network configurations.
Figure 6 shows the policy deployment architecture in wireless
network system. This architecture is decoupled the controlling
plane from the user plane, and consists of five major modules
including the application manager (AM), compiler, converter,
monitor and controller in controlling plane.
+-----+ +---------+
| AM +--+ Compiler|
+-----+ +----+----+
|
+----+----+ +-------+
|Converter|--|Monitor|
+----+----+ +---+---+
| |
+----+-----+ |
|Controller| |
+----+-----+ |
| |
.--. |
__( ')__ |
( ')_|
( ')
( Wireless Network Infrastructure ')
( ')
( )
'--(_____)--'
Figure 6: The policy deployment architecture in future wireless
network systems
AM is used to request network services based on our policy model.
It can provide services for customers via Application Programming
Interfaces (APIs).
The compiler is to compile high-level network policies. When
receiving the requested services, the compiler maps each vertex
defined in policy model into a virtual network element, and
constructs a virtual network topology according to required
network connections. If a vertex participates in multiple
connection types, we have to add a divider to assure the isolation
of different services. Meanwhile, the network function elements
defined in each edge are mapped into virtual network devices. Note
that in this phase we do not consider available network resources
in the underlying networks. The purpose of such process is to hide
from the differences in the underlying network and thus make it
more efficiently.
Yan, et al. Expires February 29, 2018 [Page 7]
Internet-Draft Policy Model and its Application August 2017
Monitor is used to process the policies defined in parallel mode.
According to the policies, it needs to check whether the required
performance is fulfilled. To achieve it, it has to collect the
measurements from the underlying networks. When the performance
indicator is lower than the required value, it triggers the
request notifying the converter enforces pre-defined actions.
Converter is to convert the results obtained from the compiler
into forwarding rules and network configurations. In this phase,
we have to consider available network resources in the underlying
networks. This information can be obtained from the controller.
Meanwhile, it also receives the request that performs the
value-added actions from monitor when policies in parallel mode is
in effect.
Controller is responsible for configuring network resources to the
underlying networks. It not only installs/uninstalls forwarding
rules to the switches in the underlying wireless network
infrastructure, but also creates, deletes and manages the virtual
network function entities in the underlying networks.
6. Summary
This document proposes a generic policy model based on the
practical scenarios in future wireless network systems. With this
model, customers can conveniently request the network services
without caring about the details in the underlying networks.
Furthermore, we design an architecture to automatically deploy the
defined policies. Our architecture can benefit ISPs to improve
user experience on network services as well as increase their
revenue.
Yan, et al. Expires February 29, 2018 [Page 8]
Internet-Draft Policy Model and its Application August 2017
7. Security Considerations
Security issues due to aggregating the service chains across
different administrative domain are an aspect for further study.
8. IANA Considerations
This draft does not have any IANA considerations.
9. Informative References
[Chaithan_pga_sigcomm]Chaithan Prakash, J. Lee, Yoshio Turner,
J.M. Kang, Aditya Akella, Sujata Banerjee, Charles Clark, Yadi
Ma,Puneet Sharma, and Ying Zhang. PGA: Using Graphs to Express and
Automatically Reconcile Network Policies. SIGCOMM Comput. Commun,
29-42, 2015.
10. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Huan Yan
Tsinghua University
yanh14@mails.tsinghua.edu.cn
Yong Li
Tsinghua University
liyong07@tsinghua.edu.cn
Haiyang Sun
Huawei Technologies
sunhaiyang3@huawei.com
Chunshan Xiong
Huawei Technologies
sam.xiongchunshan@huawei.com
Depeng Jin
Tsinghua University
jindp@tsinghua.edu.cn
Yan, et al. Expires February 29, 2018 [Page 9]
