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]