Network Working Group C. Zhou Internet-Draft T. Tsou Intended status: Informational Huawei Technologies Expires: December 6, 2014 Q. Sun China Telecom D. Lopez Telefonica G. Karagiannis University of Twente June 6, 2014 APONF Architecture draft-zhou-aponf-architecture-00 Abstract Currently, there are transport applications that have specific demands on a communication network. This document describes the APONF basic architecture, its elements and interfaces. The main APONF architecture entity is the Application-based Policy Decision (ABPD), which supports groups/classes of application models. Each of these models supports application demands that are similar in nature and therefore can be grouped/classified together. Moreover, the ABPD maps the classified application models into network capabilities, e.g., network management and 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 6, 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 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Zhou, et al. Expires December 6, 2014 [Page 1] Internet-Draft APONF architecture June 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of the APONF Architecture . . . . . . . . . . . . . 3 4. Transport Applications . . . . . . . . . . . . . . . . . . . 4 5. Application Based Policy Decision . . . . . . . . . . . . . . 5 6. Network Elements . . . . . . . . . . . . . . . . . . . . . . 6 7. The APONF Interface . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction 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. In addition, 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. There are transport applications, see e.g., [ID.montpetit-transport-use-cases], that have specific and real time demands on the communication network. In particular, these demands require the use of specific network management and traffic policies which are currently not directly provided by the communication network to these applications. This introduces difficulties for the applications to use these network capabilities efficiently and may cause user experience degradation, e.g., congestion and delay. It is therefore, required that the communication network manages and/or controls the application traffic according to the requirements imposed by the application. Zhou, et al. Expires December 6, 2014 [Page 2] Internet-Draft APONF architecture June 2014 The application's demands on a communication network may be different, but there are several application demands that may be similar, such as Web Surfing/Browsing applications, IoT applications, virtual network function services, which can be grouped/classified together. The classified application demands on a communication network can be presented and modeled as 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. The main goal of this document is to specify the APONF basic architecture, its elements and interfaces. The main APONF architecture entity is the Application-based Policy Decision (ABPD), which supports classified application models. The Application-based Policy Decision entity provides an interface to the application to generate the classified application models and to map these models to the network management and traffic policies that can be used by the communication network. The definition of these network management and traffic policies is out of the APONF scope. 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 virtualisation 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. Overview of the APONF Architecture This section depicts an overview of the architecture of application- based policy on network functions. Figure 1 shows the basic architecture of the application-based policy on network functions. The entities used in the APONF architecture are: Zhou, et al. Expires December 6, 2014 [Page 3] Internet-Draft APONF architecture June 2014 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. 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 existing network management and traffic policies that can be used by the communication network. It can communicate with multiple applications simultaneously. +-----------+ +-----------+ +-----------+ +-----------+ |Transport | |Transport | |Transport | |Transport | |Application| |Application| |Application| |Application| +-----^-----+ +---^-------+ +-----^-----+ +---^-------+ | | | | +------+-----+ +------+-----+ | | | APONF Interface | APONF Interface | Protocol | Protocol +---------------|-------------------------------|----------------------+ |+--------------v--------------+ +-------------v--------------+ +---+ | ||Classified Application Model | |Classified Application Model| |...| | |+-----------------------------+ +----------------------------+ +---+ | | | | Application Based Policy Decision | +-----------------------------------^----------------------------------+ | | | +--------------------+---------------------+ | | | | | | +--------------v--------------+ +-----------------v-----------+ | | | | | | ... | | | Network Element | | Network Element | +-----------------------------+ +-----------------------------+ Figure 1: Architecture of application-based policy on network functions 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. 4. Transport Applications The Transport Architecture entity represents transport applications. This architecture is expected to be used for several categories of transport applications, e.g., Web Surfing/Browsing, Streaming Video, Real-time Communications, Data storage, etc. Zhou, et al. Expires December 6, 2014 [Page 4] Internet-Draft APONF architecture June 2014 These transport Applications provide a set of application-based policy models which are imposing similar network management and traffic policy requirements on the communication network. The application's demands on the network may be different, but some application's demands on the communication network may be similar, and can be grouped/classified together. Such similar application's demands can be: Web Surfing/Browsing applications, IoT applications, virtual network function services, etc. The classified application demands on a communication network can be presented and modeled as classified application-based policies and models. 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. The Transport Applications entity will use the APONF interface to communicate with the Application Based Policy Decision (ABPD) entity. 5. Application Based Policy Decision The Application-Based Policy Decision (ABPD) block, is a an entity used between the Transport Application entity and the network elements to provide and maintain the application-based policies. It supports the APONF interface/protocol and is a software repository, which stores the information associated with each NE, and maps the classified application models to existing network management and traffic policies. In particular, by creating application-based policies that mirror application semantics, a better mapping to existing traffic and network management policies can be realized. This provides a simple, self-documenting mechanism for capturing application-based policy requirements and mapping them to existing traffic and network management policies. This will allow applications to use the network capabilities in a more accurate and efficient way. The definition of these 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). Zhou, et al. Expires December 6, 2014 [Page 5] Internet-Draft APONF architecture June 2014 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). These application-based policy models can 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. 6. Network Elements The Network Element (NE) handles incoming packets based on the policy information communicated with the ABPD block and makes corresponding policy enforcement, which is based on existing network management and traffic policies, see Section 5. A NE may be a physical entity or a virtual entity and is locally managed, whether via CLI, SNMP, or NeTConf. Examples of NEs can include: o A router that has an extended function module. The extended module handles incoming packets basing on the flow table of the module. o A server that runs vRouter or vSwitch. o A CGN that runs NAT, Tunnel En/De-capsulation functions. o A virtual network function (VNF) entity. 7. The APONF Interface/Protocol This APONF Interface/Protocol, needs to be specified by the APONF WG and is used to support the communication between the Transport Application entity and the ABPD entity, see Section 5. 8. 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. Zhou, et al. Expires December 6, 2014 [Page 6] Internet-Draft APONF architecture June 2014 9. IANA Considerations This document has no actions for IANA. 10. 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, Jose Santana, Simon Perreault, Fernando Gont. 11. References 11.1 Informative References [ID.montpetit-transport-use-cases] Montpetit, M. and I. Zhovnirovsky, "Use Cases and Requirements", Feb 2014. Authors' Addresses Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: cathy.zhou@huawei.com Tina Tsou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Email: Tina.Tsou.Zouting@huawei.com 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 Georgios Karagiannis University of Twente Email: g.karagiannis@utwente.nl Zhou, et al. Expires December 6, 2014 [Page 7]