Network Working Group W. Liu Internet-Draft T. Tsou Intended status: Informational Huawei Technologies Expires: January 4, 2015 G. Karagiannis University of Twente J. Saldana University of Zaragoza July 4, 2014 APONF Use Case: Using Abstract View of Network by Application Developers draft-liu-aponf-using-abstract-view-use-case-00 Abstract This document describes a use case of Application Policy on Network Functions (APONF) that presents how service developers can profit by using an abstract view of the network during the programming and development process, instead of manipulating individual devices. In this way one can write software that programs an arbitrary network. APONF can be used to interface the programmed arbitrary network into network management policies, i.e., device configuration models. 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 30, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Liu, et al. Expires January 4, 2015 [Page 1] Internet-Draft Abstract Network View APONF Use Case 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. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. APONF Use Case: Using Abstract View of Network by Application Developers . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 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. This also implies that demands and requirements of such new services on the supporting communication network will increase. In addition, today's network operators are challenged to create an abstract view of their network infrastructure and help service developers on using and programming this abstraction rather than manipulating individual devices. An abstract view of a network infrastructure can be realized using a network configuration model, that provides a declarative configuration and a network topology model that describes a multi-layer network. Network management applications are Operational Support System (OSS)-like applications that help a communication service provider to monitor, control, analyze and manage a communication network. Liu, et al. Expires January 4, 2015 [Page 2] Internet-Draft Abstract Network View APONF Use Case July 2014 Currently, there are no IETF standard mechanisms or modeling languages that can directly be applied to model the network configuration nor the network topology. IETF has however created the IETF SFC WG [SFC] to document a new approach to service delivery and operation, where one of its goals is to realize an abstract view of a network by using a service graph instance, denoted as the Service Function Path (SFP). This will enable the development of suitable models for network configuration and network topology. This use case description is based on [Google], and argues that service developers can profit by using an abstract view of the network during the programming and development process, instead of manipulating individual devices. In this way one can write software that programs an arbitrary network. Application Policy on Network Functions (APONF) [APONF] can be used to interface the programmed arbitrary network into network management policies, i.e., device configuration models. This document is organized as follows. Section 2 presents the terminology. Section 3 provides a brief description of this use case. Section 4 provides the security considerations. 2. Terminology Device level configuration model: Supports the description of the network management policies and describes the configuration details at the device level. Network Management Application: Operational Support System (OSS)-like application that help a communication service provider to monitor, control, analyze and manage a communication network. Network configuration model: Provides a declarative configuration of the network. Network topology model: Describes the topology of a multi-layer network. Service Function Chain (SFC): It defines an ordered set of service functions that must be applied to packets and/or layer-2 frames selected as a result of classification. The implied order may not be a linear progression as nodes may copy to more than one branch. The term "service chain" is often used as shorthand for service function chain. Service Function Path (SFP): The instantiation of a Service Function Chain in the network. Packets follow a Service Function Path from a classifier through the required instances of service functions in the network. Liu, et al. Expires January 4, 2015 [Page 3] Internet-Draft Abstract Network View APONF Use Case July 2014 3. APONF Use Case: Using an Abstract View of the Network by Application Developers This section briefly describes the use case that is based on [Google], which argues that service developers can profit by using an abstract view of the network during the programming and development process instead of manipulating individual devices. Suppose that a network service is developed and maintained as a network management application. Such network service can enable the use of end user applications that require a high security, reliability and QoS levels to users that are located in the football stadium in Rio during the FIFA soccer World Cup 2014 in Brazil. The network service, that for the moment we call "secure applications during football match", is developed using the requirements of the end user applications and the available information about the existing communication infrastructure at the particular football stadium. The network management application is used to provide the required configuration and application programming interfaces to an application developer that can develop the end user applications using the SFP based network configuration and network topology information, associated with the "secure applications during football match" network service. The application developer can create an application based model associated with this network service. This application-based model includes the updates of parts of the abstract view of the network, i.e., SFP based network configuration and topology associated with the communication network infrastructure available at the Rio stadium and the necessary application based demands to be applied on this network configuration and network topology. In this context, APONF can be used to map the application-based model associated with the "secure applications during football match" network service into specific network management policies, i.e., device level configuration models. 4. Security Considerations Security is a key aspect of any protocol that allows state installation and extracting of detailed configuration states. More investigation remains to fully define the security requirements, such as authorization and authentication levels. 5. IANA Considerations This document has no actions for IANA. 6. Acknowledgements The authors of this draft would like to thank the APONF participants for their valuable feedback. Liu, et al. Expires January 4, 2015 [Page 4] Internet-Draft Abstract Network View APONF Use Case July 2014 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [Google] Google Use Case, http://www.sdncentral.com/news/google-open-source-help-policy-based- sdn/2014/06/ [SFC] IETF SFC (Service Function Chaining) WG charter, http://datatracker.ietf.org/wg/sfc/charter/ [APONF] http://tools.ietf.org/html/draft-zhou-aponf-architecture-01 Authors' Addresses 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 Georgios Karagiannis University of Twente Email: g.karagiannis@utwente.nl Jose Saldana University of Zaragoza Dpt. IEC Ada Byron Building Zaragoza 50018 Spain Phone: +34 976 762 698 Email: jsaldana@unizar.es Liu, et al. Expires January 4, 2015 [Page 5]