Problem Statement for Application Policy on Network Functions (APONF)
draft-karagiannis-aponf-problem-statement-00

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]