idnits 2.17.1 draft-liu-aponf-using-abstract-view-use-case-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 5) being 63 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 4, 2014) is 3577 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group W. Liu 2 Internet-Draft T. Tsou 3 Intended status: Informational Huawei Technologies 4 Expires: January 4, 2015 G. Karagiannis 5 University of Twente 6 J. Saldana 7 University of Zaragoza 8 July 4, 2014 10 APONF Use Case: Using Abstract View of Network by Application 11 Developers 12 draft-liu-aponf-using-abstract-view-use-case-00 14 Abstract 16 This document describes a use case of Application Policy on Network 17 Functions (APONF) that presents how service developers can profit by 18 using an abstract view of the network during the programming and 19 development process, instead of manipulating individual devices. In 20 this way one can write software that programs an arbitrary network. 21 APONF can be used to interface the programmed arbitrary network into 22 network management policies, i.e., device configuration models. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 30, 2014. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Requirements Language 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC 2119 [RFC2119]. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. APONF Use Case: Using Abstract View of Network by Application 67 Developers . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 74 1. Introduction 76 As the Internet grows, more and more new services keep on arising, 77 and network traffic is rapidly increased, which may result in slow 78 performance of network devices (e.g., BRAS) and poor end-user 79 experience. This also implies that demands and requirements of such 80 new services on the supporting communication network will increase. 82 In addition, today's network operators are challenged to create an 83 abstract view of their network infrastructure and help service 84 developers on using and programming this abstraction rather than 85 manipulating individual devices. An abstract view of a network 86 infrastructure can be realized using a network configuration model, 87 that provides a declarative configuration and a network topology 88 model that describes a multi-layer network. Network management 89 applications are Operational Support System (OSS)-like applications 90 that help a communication service provider to monitor, control, 91 analyze and manage a communication network. 93 Currently, there are no IETF standard mechanisms or modeling 94 languages that can directly be applied to model the network 95 configuration nor the network topology. IETF has however created the 96 IETF SFC WG [SFC] to document a new approach to service delivery and 97 operation, where one of its goals is to realize an abstract view of a 98 network by using a service graph instance, denoted as the Service 99 Function Path (SFP). This will enable the development of suitable 100 models for network configuration and network topology. 102 This use case description is based on [Google], and argues that 103 service developers can profit by using an abstract view of the 104 network during the programming and development process, instead of 105 manipulating individual devices. In this way one can write software 106 that programs an arbitrary network. 108 Application Policy on Network Functions (APONF) [APONF] can be used 109 to interface the programmed arbitrary network into network management 110 policies, i.e., device configuration models. 112 This document is organized as follows. Section 2 presents the 113 terminology. Section 3 provides a brief description of this use 114 case. Section 4 provides the security considerations. 116 2. Terminology 118 Device level configuration model: Supports the description of the 119 network management policies and describes the configuration 120 details at the device level. 122 Network Management Application: Operational Support System (OSS)-like 123 application that help a communication service provider to monitor, 124 control, analyze and manage a communication network. 126 Network configuration model: Provides a declarative configuration of 127 the network. 129 Network topology model: Describes the topology of a multi-layer 130 network. 132 Service Function Chain (SFC): It defines an ordered set of service 133 functions that must be applied to packets and/or layer-2 frames 134 selected as a result of classification. The implied order may not be a 135 linear progression as nodes may copy to more than one branch. The term 136 "service chain" is often used as shorthand for service function chain. 138 Service Function Path (SFP): The instantiation of a Service Function 139 Chain in the network. Packets follow a Service Function Path from 140 a classifier through the required instances of service functions 141 in the network. 143 3. APONF Use Case: Using an Abstract View of the Network by Application 144 Developers 146 This section briefly describes the use case that is based on 147 [Google], which argues that service developers can profit by using 148 an abstract view of the network during the programming and 149 development process instead of manipulating individual devices. 151 Suppose that a network service is developed and maintained as a 152 network management application. Such network service can enable the 153 use of end user applications that require a high security, 154 reliability and QoS levels to users that are located in the football 155 stadium in Rio during the FIFA soccer World Cup 2014 in Brazil. The 156 network service, that for the moment we call "secure applications 157 during football match", is developed using the requirements of the 158 end user applications and the available information about the 159 existing communication infrastructure at the particular football 160 stadium. 162 The network management application is used to provide the required 163 configuration and application programming interfaces to an 164 application developer that can develop the end user 165 applications using the SFP based network configuration and network 166 topology information, associated with the "secure applications 167 during football match" network service. The application developer can 168 create an application based model associated with this network 169 service. This application-based model includes the updates of parts 170 of the abstract view of the network, i.e., SFP based network 171 configuration and topology associated with the communication network 172 infrastructure available at the Rio stadium and the necessary 173 application based demands to be applied on this network configuration 174 and network topology. 176 In this context, APONF can be used to map the application-based model 177 associated with the "secure applications during football 178 match" network service into specific network management policies, 179 i.e., device level configuration models. 181 4. Security Considerations 183 Security is a key aspect of any protocol that allows state 184 installation and extracting of detailed configuration states. More 185 investigation remains to fully define the security requirements, such 186 as authorization and authentication levels. 188 5. IANA Considerations 190 This document has no actions for IANA. 192 6. Acknowledgements 194 The authors of this draft would like to thank the APONF participants 195 for their valuable feedback. 197 7. References 199 7.1. Normative References 201 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 202 Requirement Levels", BCP 14, RFC 2119, March 1997. 204 7.2. Informative References 206 [Google] Google Use Case, 207 http://www.sdncentral.com/news/google-open-source-help-policy-based- 208 sdn/2014/06/ 210 [SFC] IETF SFC (Service Function Chaining) WG charter, 211 http://datatracker.ietf.org/wg/sfc/charter/ 213 [APONF] http://tools.ietf.org/html/draft-zhou-aponf-architecture-01 215 Authors' Addresses 217 Will(Shucheng) Liu 218 Huawei Technologies 219 Bantian, Longgang District 220 Shenzhen 518129 221 P.R. China 223 Email: liushucheng@huawei.com 225 Tina Tsou 226 Huawei Technologies 227 Bantian, Longgang District 228 Shenzhen 518129 229 P.R. China 231 Email: Tina.Tsou.Zouting@huawei.com 233 Georgios Karagiannis 234 University of Twente 236 Email: g.karagiannis@utwente.nl 238 Jose Saldana 239 University of Zaragoza 240 Dpt. IEC Ada Byron Building 241 Zaragoza 50018 242 Spain 243 Phone: +34 976 762 698 244 Email: jsaldana@unizar.es