Network Working Group G. Karagiannis Internet-Draft University of Twente Intended status: Informational W. Liu Expires: December 6, 2014 T. Tsou Huawei Technologies Q. Sun China Telecom D. Lopez Telefonica June 6, 2014 Problem Statement for Application Policy on Network Functions (APONF) draft-karagiannis-aponf-problem-statement-00 Abstract As more and more modern network applications grow in scale and complexity, their demands and requirements on the supporting communication network will increase. In particular, these demands require the use of specific network management and traffic policies which currently are not provided directly by the communication network to these applications. Application demands that are similar in nature can be grouped together in grouped/classified application models. This draft specifies the need for application policy on network functions (APONF) APONF protocol(s), mechanisms and models required by transport applications to easily, accurately, and efficiently select and use the available communication network capabilities, i.e., network management and/or traffic policies. 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 December 5, 2014. Copyright Notice Copyright (c) 2014 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 Karagiannis, et al. Expires December 6, 2014 [Page 1] Internet-Draft APONF Problem Statement June 2014 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. Requirements Language 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 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Requirements/Objectives . . . . . . . . . . . . . . . . . . . . 5 5 Relationships between APONF and other IETF Working Groups . . . 6 6. Existing Protocols and Methods . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Today, as the Internet grows, more and more new services keep on arising, and network traffic is rapidly increased, which may result in slow performance of network devices (e.g., BRAS) and poor end-user experience. This also implies that demands and requirements of such new services on the supporting communication network will increase. In particular, these demands require the use of specific network management and traffic policies which currently are not provided directly by the communication network to these applications. Furthermore, and especially for cloud applications, the cloud tenants and developers usually need to use the communication network capabilities, such as dynamic network management and dynamic traffic steering, easily, accurately and efficiently. In this way, the deployment of new applications and services may be accelerated and the user experience can be improved. Moreover, the Development Operations (DevOps), see e.g., [DevOps], is another network development trend which orchestrates the complex interdependent processes associated with software development and IT operations in order to accelerate the production and roll out of Karagiannis, et al. Expires December 6, 2014 [Page 2] Internet-Draft APONF Problem Statement June 2014 software products and services. Currently, the separation of development and operation of network technologies leads to slow deployment of network functions/devices and poor user experiences. The communication network needs to provide graceful adjustment capabilities in order to accommodate the diverse needs of applications and the rapid network evolution. Currently, there are transport applications that have specific demands on a communication network. For example, some specialized applications, like virtual network function services, may need to *dynamically manage* the network infrastructure, and other specialized applications, like streaming applications and Internet of Things (IoT) applications, may require from the network to treat their traffic according to their demands. If possible, an application may require from the communication network to apply the following different network management and/or traffic capabilities, such as: o) dynamically (re)configure a network entity o) accelerate the service deployment o) getting better network services from transport network o) providing better user experience The application's demands on a communication network are different, but there are several application demands that may be similar, such as different Web Surfing/Browsing applications, IoT applications, virtual network function services, which can be grouped/classified together. The grouped/classified application demands on a communication network can be presented and modeled as grouped/classified application-based policies. A set of application- based policy models may be needed for auto-mapping of application's demands to existing network management and/or traffic policies. This will allow applications to use the network capabilities in a more accurate and efficient way. These application-based policy models could meet the application's demands on the communication network and map these demands to network management and traffic policies that can be understood by the communication network. The main goal of APONF is to specify the application-based policy protocol(s), mechanisms and models required by transport applications to easily, accurately, and efficiently select and use the available communication network capabilities, i.e., network management and/or traffic policies. This document is organized as follows. Section 2 presents the terminology. Section 3 provides a brief overview of the use cases associated with APONF. The requirements/objectives are provided in Section 4. Section 5 presents the relationships between APONF and other IETF Working Groups and other IETF activities. The existing IETF protocols and methods that can be used by the APONF solutions are given in Section 6. Section 7 provides the security and privacy considerations. The IANA considerations are given in Section 8. Section 9 gives the acknowledgements and Section 10 lists the used references. Karagiannis, et al. Expires December 6, 2014 [Page 3] Internet-Draft APONF Problem Statement June 2014 2. Terminology VNF (Virtualized Network Function): An implementation of an executable software program that constitutes the whole or a part of an NF and can be deployed on a virtualization infrastructure. TAPS (Transport Services): The main goal of this activity (currently BOF) is to provide the means to applications to specify the services they can receive from the transport protocol, but NFVcon (Network Functions Virtualization configuration): The main goal of this activity (BOF status) is to support the dynamic configuration of NFV instances. AECON (Application Enabled Collaborative Network): The main goal of the AECON activity (currently BOF) is to allow applications to explicitly signal their flow characteristics to the network. Abstraction and Control of Transport Networks (ACTN): The main goal of this activity is to enable discussion of the architecture, use- cases, and requirements that provide abstraction and virtual control of transport networks to various applications. 3. Use Cases This section briefly describes the use cases that are associated with different types of grouped/classified application-based policy models. The detailed description of these use cases is provided in other Internet draft(s). 3.1. Interactive Application Policy This type of policy provides a bidirectional transport layer channel. The bidirectional channel needs to support data-loss protection and link detection. Both, the bandwidth and delay parameters of the bidirectional channel need to be configured to guarantee that application operates satisfactorily. Examples of applications that are using this policy are web surfing and voice call conference applications. 3.2. Streaming Application Policy Streaming applications usually need large bandwidth and an unidirectional transport layer channel. In this type of applications the high bandwidth and the guaranteed delivery parameters of the unidirectional channel need to be configured on demand. Examples of applications that are using this policy are IPTV and VoD applications. 3.3. Media Sharing Application Policy Media sharing application policies include capabilities such as media resource lookup and routing applied to reduce the use of the network bandwidth. Karagiannis, et al. Expires December 6, 2014 [Page 4] Internet-Draft APONF Problem Statement June 2014 3.4. P2P Application Policy P2P (Peer to Peer) applications are using P2P concepts such as P2P Content distribution and P2P content searching techniques. The P2P application policies include capabilities like mass sessions creation and media resource location. 3.5. Data Storage Application Policy Applications, such as cloud computing applications need to be able to store and retrieve large amounts of data quickly and on demand. The Data Storage application policies include dynamic reconfiguration of data storage and dynamic increase/decrease of network bandwidth. 3.6. IOT Application Policy Internet of Things (IoT) applications are using various types of communicating Internet enabled entities, e.g. sensors, robots, computers, that can be located in several geographical areas and which are able to monitor, generate and disseminate information during short periods of time. IoT application policies include short- duration session creation and route decision capabilities. 3.7. Virtualized Enterprise Application policy 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 and charging. 4. Requirements/Objectives Before describing the APONF requirements/objectives a brief description on the network entities proposed in [APONF-architecture] is given below: O) Application: A transport application that needs to observe the network or manipulate the network to achieve its service requirements. Several applications may communicate with the Application Based Policy Decision block. The traditional applications can communicate real time, using an existing interface, e.g., netconf, restconf, or some new protocols proposed by interested parties, with the transport applications and exchange information requested by the Application-Based Policy Decision entity. The definition of this interface is out of the scope of this document. O) Application Based Policy Decision (ABPD): A functional entity Which provides an interface to the application to generate the grouped/classified application models and to map these models to Karagiannis, et al. Expires December 6, 2014 [Page 5] Internet-Draft APONF Problem Statement June 2014 existing network management and traffic policies that can be used by the communication network. It can communicate with multiple applications simultaneously. o) Network Element (NE): A NE handles incoming packets based on the policy information communicated with the applications and enforces the corresponding network management and traffic manipulation. The requirements/objectives that need to be supported by the APONF methods, models and protocol solutions are the following ones: o) specify the APONF groups/classes of application policies and models o) provide mechanisms that can accurately map and store the APONF groups/classes of application policies and models into existing network management and traffic policies. o) specify the protocol and the required mechanisms that are able to support the communication between the transport applications and the ABPD entity that maintains the groups/classes of application policies and models. o) provide the means to use existing network management and/or traffic conditioning protocols and mechanisms to enforce the application policies (via the associated network management and traffic policies) into network entities. Such protocols and mechanism are supported for/by e.g., SNMP/MIB, COPS-PR/PIB, NetConf/Yang, Web Services/MIB, nfvcon activity, SCF WG, ACT activity, I2RS WG, FORCES WG, AECON BOF activity, NAT, Firewall, Intserv, Diffsrerv, PCN, MPLS. o) provide authentication and authorization mechanisms to support the communication between the Transport Application and the ABPD entity. o) provide privacy support for the end users running the applications that make use of the APONF protocol and mechanisms. 5. Relationships between APONF and other IETF Working Groups The following relationships between APONF and other IETF WGs have been identified: APONF is different than existing WGs and other IETF activities, due to the fact that APONF is the only activity that specifies the application-based policy protocol(s), mechanisms and models required by transport applications to easily, accurately, and efficiently select and use the available communication network capabilities, i.e., network management and/or traffic policies. APONF may use existing network management and/or traffic conditioning protocols and mechanisms to enforce the application policies into Karagiannis, et al. Expires December 6, 2014 [Page 6] Internet-Draft APONF Problem Statement June 2014 network entities, see Section 6. Such protocols and mechanism are supported for/by e.g., SNMP/MIB, COPS-PR/PIB, NetConf/Yang, Web Services/MIB, nfvconf activity, SCF WG, ACT activity, I2RS WG, FORCES WG, AECON BOF activity, NAT, Firewall, Intserv, Diffsrerv, PCN, MPLS. The TAPS (Transport Services) activity may apply the Transport Application entity, see Section 4, in order to interact and use the grouped/classified application policies and models maintained by the ABPD entity. 6. Existing Protocols and Methods The APONF protocol and mechanisms will have an impact on layers 4 and above. The definition of the used network management and traffic policies is out of the APONF scope. Examples of such existing network management and traffic policies that are considered by APONF are the following: o) Manage dynamically network semantics (supported by e.g., SNMP/MIB, COPS-PR/PIB, NetConf/Yang, CLI, Web Services/MIB, nfvcon (Network Function Virtualization configuration) activity). o) Orchestrate dynamically virtualized functions (supported by e.g., SCF WG, nfvcon activity, Abstraction and Control of Transport Networks (ACTN) activity). o) Permit/Block/Redirect the traffic (supported by e.g., I2RS WG, FORCES WG, Application Enabled Collaborative Network (AECON) activity). o) Log the traffic (supported by e.g., I2RS WG, FORCES WG, AECON activity). o) Copy the traffic (supported by e.g., I2RS WG, FORCES WG, AECON activity). o) Set the traffic (supported for/by e.g., NAT, Firewall, I2RS WG, FORCES WG, AECON activity). o) Mark the traffic (supported for/by e.g., Intserv, Diffserv, PCN, MPLS). 7. Security Considerations Authentication and authorization mechanisms are needed to ensure that the transport applications communicating with the ABPD entity are indeed authenticated and authorized. Furthermore, the privacy of the end users running the applications that make use of APONF must be protected. Karagiannis, et al. Expires December 6, 2014 [Page 7] Internet-Draft APONF Problem Statement June 2014 8. IANA Considerations This document has no actions for IANA. 9. Acknowledgements The authors of this draft would like to thank the following persons for the provided valuable feedback: Spencer Dawkins, Jun Bi, Xing Li, Qiong Sun, Chongfeng Xie, Benoit Claise, Ian Farrer, Marc Blancet, Zhen Cao, Hosnieh Rafiee, Mehmet Ersue, Simon Perreault, Fernando Gont, Jose Saldana. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10.2. Informative References [DevOps] DevOps website, http://devops.com/ [NIST SP 800-146] Badger et al.: "Draft Cloud Computing Synopsis and recommendations", NIST specifications, May 2011. [APONF-architecture] C. Zhou, T. Tsou, Q. Sun, D. Lopez, G. Karagiannis, "APONF Architecture", IETF Internet draft, draft-zhou-aponf-architecture-00, June 2014 Authors' Addresses Georgios Karagiannis University of Twente Email: g.karagiannis@utwente.nl Will(Shucheng) Liu Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: liushucheng@huawei.com Tina Tsou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: Tina.Tsou.Zouting@huawei.com Karagiannis, et al. Expires December 6, 2014 [Page 8] Internet-Draft APONF Problem Statement June 2014 Qiong Sun China Telecom No.118 Xizhimennei street, Xicheng District Beijing 100035 P.R. China Email: sunqiong@ctbri.com.cn Diego Lopez Telefonica Email: diego@tid.es Karagiannis, et al. Expires December 6, 2014 [Page 9]