Network Working Group C. Huang Internet Draft Carleton University Intended status: Informational Jiafeng Zhu Expires: January 3, 2015 Huawei Peng He Ciena Shucheng (Will) Liu Huawei Baek-Yong Choi University of Missouri-Kansas City July 3, 2014 Use Cases on Application-centric Network Management and Service Provision draft-huang-aponf-use-cases-01.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), 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 The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 3, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Huang Expires January 3, 2014 [Page 1] Internet-Draft Use Cases on . . . July 2014 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. Abstract New services such as virtual networks, service function chaining, and application-centric traffic steering bring new opportunities for network providers and service providers. With these new services, the interactions between applications and networks are becoming more critical in order to achieve satisfactory QoS, reliability, and security, which are tailored to each specific application. Application-based Policy for Network Function (APONF) is designed to facilitate these interactions. This internet draft describes some use cases that show how APONF may be deployed to support these services. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................3 3. Use Cases......................................................4 3.1. Network Virtualization....................................4 3.2. Virtualized Enterprise Applications.......................4 3.3. Application Centric QoS and Reliability...................5 4. IANA Considerations............................................6 1. Introduction The wide deployment of optical networks and large-scale datacenters has enabled many new services such as network virtualization, service chaining, and application-centric traffic steering which bring new opportunities to network and service providers. One of the primary new services that have been envisioned is the network virtualization service, which allows physical network provider to sell different virtual networks to different service network providers. Each service network provider can use its virtual network just like the way it uses its own private network while sharing underlying physical network resources with other Huang Expires January 3, 2015 [Page 2] Internet-Draft Use Cases on . . . July 2014 service network providers. The physical network provider, on the other hand, can enjoy new revenue growth through selling virtual networks with different granularities. Traditionally a service chain consists of a set of dedicated network service boxes such as firewall, load balancers, and application delivery controllers that are concatenated together to support a specific application. With a new service request, new devices must be installed and interconnected in certain order. This can be a very complex, time-consuming, and error-prone process, requiring careful planning of topology changes and network outages and incurring high OPEX. This situation is exacerbated when a tenant requires different service sequences for different traffic flows or when multiple tenants share the same datacenter network. Network Function Virtualization (NFV) is a concept built upon network virtualization. It involves the implementation of network functions such as load balancing, intrusion detection, firewall, monitoring, and accelerations in software that can run on a range of industry standard high volume servers, switches, and storage. Through NFV, service providers can dynamically create a virtual environment for a specific service chain and eliminate the dedicated hardware and complex labor work for supporting a new service chain request. Both network virtualization and NFV require network management and service provisioning. Experiences from the services provided by modern datacenters (e.g. Amazon EC2) have shown that fast response time and easy-to-use are critical for the success of these new services. There is no existing management and service provisioning infrastructure to support network virtualization and NFV. However, these new services typically require complex interactions and orchestration between service subscribers and network infrastructure, which are missing in the existing Internet architecture. There are many other use cases that can be better served with application-centric network management and service provisioning. Application service providers have tried various ways to differentiate their customers so that they can maximize their revenues and minimize their costs. For example, cookies have been used to track HTTP users. Unfortunately they are designed for specific applications. Because cookies only appear in HTTP headers, they will not be carried by all packets except the first one. Therefore they cannot be used by operators to provision switches. On the other hand, VLAN and DiffServ are hard to be maintained at the level of end-to-end, since they operate on Layers 2 and 3. In this Huang Expires January 3, 2015 [Page 3] Internet-Draft Use Cases on . . . July 2014 regard, application-centric network management and service provisioning, although widely desired, are still hard to achieve. In this document, we describe some typical use cases that may be supported using APONF architecture. 2. Conventions used in this document 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 RFC-2119. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. 3. Use Cases There are numerous use cases that APONF can be applied to. Some common use cases are described in this section. 3.1. Network Virtualization Service The first use case is a network virtualization service. Here a physical network provider will serve as the service provider and virtual network providers will serve as clients. Virtual network providers request virtual networks by contacting Application Based Policy Decision (ABPD) module. ABPD module will check against its policy to see whether the request is acceptable. If not, it will reject the request. If acceptable, it will assign an ID to identify the request and map the virtual topology to physical networks with required performance. ABPD will then contact related physical network providers to provision the required resources. After all the required networks resources are reserved and setup, the infrastructure network providers will inform ABPD, which will then update its database about those physical networks and inform the virtual network provider about its requested virtual network and associated ID to identify the required virtual network. When the users of the virtual network provider send traffic, they need to encapsulate the ID in their packets so that network providers can identify the traffic belonging to the same user group and treat them with required resources and policies. In the case that the users of the virtual network provider cannot encapsulate the ID into packets due to their software version, the ABDP, after learning this information from its interactions with the virtual network provider, will inform the border routers to classify traffic Huang Expires January 3, 2015 [Page 4] Internet-Draft Use Cases on . . . July 2014 and encapsulate and de-capsulate packets with the ID. Without ABDP, this kind of negotiation and configuration will not be possible. 3.2. Virtualized Enterprise Applications Virtualized enterprise applications make the Virtualized Network Function (VNF) functionality available to enterprise users as a service, comparable to the cloud computing concept denoted as the Software as a Service (SaaS), see [NIST SP 800-146]. Virtualized enterprise application policies include dynamic orchestration of virtualized network functions, dynamic increase/decrease of network bandwidth, pay-as-you-go billing, etc. GiLAN is another important application of a virtualized network function, as it is a boundary between mobile and data networks which operate on very different strategies. In mobile core networks, it is preferable that QoS provisioning and network function requirements are different for subscribers with different profiles. In such scenarios, specialized applications such as BSS/OSS can send service policies to a policy decision point, which further map these service policies to GiLAN specific VNF policies, and realize the required QoS and with appropriate network functions, for example, video transcoding parameters, traffic steering points, etc. Consider a scenario where an enterprise requests such a service. The enterprise will contact ABDP for the required resources. After receiving the request, the ABDP will check its policy and database to see whether the required service can be supported or not. If yes, the ABDP will assign an ID for each of the requested service, map the request to network policies and related service functions in the infrastructure environment, and send a request to the infrastructure provider with related network policies and service functions. The infrastructure provider will install the requested policies and service functions and confirm the request. The ABDP will confirm to the enterprise with the associated IDs and update its database. When the users of the enterprise need to send traffic, they will encapsulate their packets with corresponding IDs. The infrastructure network can then apply appropriate service functions and policies to the corresponding packets. If the application users cannot add the IDs, the ABPD will inform edge service function nodes to classify traffic and encapsulate and de-capsulate packets. 3.3. Application-centric QoS and Reliability Service providers are increasingly interested in providing different treatments to different types of customers, e.g. subscribers vs. casual users. User traffic flows need to be steered to different Huang Expires January 3, 2015 [Page 5] Internet-Draft Use Cases on . . . July 2014 environments with different networking and computing resources provisioned. Under this context, ABPD provides a simple and effective handle that connects applications to physical layer devices and enables application-centric network management and service provisioning. There are many existing Quality of Service (QoS) schemes such as VLAN and DiffServ. However, they are Layer 2 or 3 mechanisms which are hard to scale to end-to-end applications without a network management and configuration agent like ABPD. There are many application scenarios that can demonstrate the usage of ABPD. For example, a service provider may want some of its user traffic be protected from server or link failures while other traffic not. When a server or link failure happens, the traffic that needs protection is steered to a protection path. The ABDP provides an excellent option to achieve this function. Specifically, application users may send a request to ABPD for traffic that requires protection. The ABPD can check its policy and database to decide whether it can accept the request. If yes, the ABPD will decide the working and protection routes, assign an ID, and inform underlying physical networks to install the required mechanism and resources. After receiving confirmation from all the network elements, the ABPD will respond to the users with the ID. When the application users send traffic that requires protection, it will encapsulate the ID into their packets. When a network failure happens, network elements can route the traffic through backup path by identifying the traffic through the ID. 4. IANA Considerations It is recommended that IANA assign a port in UDP and another port number in TCP to identify the existing of SFLs in Layer 5. The top level SFL of a SFL stack can use all existing port number assignments to identify various applications. Huang Expires January 3, 2015 [Page 6] Internet-Draft Use Cases on . . . July 2014 Authors' Addresses Changcheng Huang Department of Systems and Computer Engineering Carleton University 1125 Colonel By Drive Ottawa, ON K1S 5B6 Canada Email: huang@sce.carleton.ca Jiafeng Zhu Huawei Technologies Inc Santa Clara, CA US Email: Jiafeng.zhu@huawei.com Peng He Ciena Corp Email: phe@ciena.com Will(Shucheng) Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: liushucheng@huawei.com Baek-Young Choi Department of Computer Science and Electrical Engineering University of Missouri-Kansas City 550D FH, 5110 Rockhill Road Kansas City, MO64110 Email: choiby@umkc.edu Huang Expires January 3, 2015 [Page 7]