idnits 2.17.1 draft-sonata-nfvrg-devops-gatekeeper-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 5, 2016) is 2845 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Aranda Gutierrez 3 Internet-Draft TID 4 Intended status: Experimental J. Bonnet 5 Expires: January 6, 2017 Altice Labs 6 D. Lopez 7 TID 8 July 5, 2016 10 The Role of a Mediation Element in NFV DevOps 11 draft-sonata-nfvrg-devops-gatekeeper-00 13 Abstract 15 This document describes how a mediation element (a "gatekeeper") can 16 be applied to support DevOps practices in the provisioning of network 17 services based on Network Function Virtualisation (NFV). 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 6, 2017. 36 Copyright Notice 38 Copyright (c) 2016 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 4 55 3. The Essential Components for NFV DevOps . . . . . . . . . . . . 4 56 4. The Role of the Gatekeeper . . . . . . . . . . . . . . . . . . 6 57 4.1. User Management . . . . . . . . . . . . . . . . . . . . . . 6 58 4.2. Package Management . . . . . . . . . . . . . . . . . . . . 6 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 The DevOps model is already an established concept in IT industry 70 reducing time to market by close collaboration between service 71 developers and service operators. The switch to virtualisation 72 technologies in the network and its potential for quicker time-to- 73 market deployment requires the application of agile development 74 cycles supporting a DevOps approach. This kind of approach will 75 overcome key inhibitors that network operators face when deploying 76 NFV, such as lack of legacy compatibility, resource orchestration, 77 automation and multi-vendor interoperability, hence facilitating the 78 transition to a software-driven network. The adoption of the DevOps 79 model for network services will contribute to interaction between 80 development, testing, and operation of network functionalities and 81 network services. Both the function/service description formats as 82 well as the infrastructure resource descriptions will be able to 83 express and use legacy cases, e.g., the case of a non-virtual network 84 function bound to a specific place in the network, with the data 85 flows routed accordingly. 87 Network Service Providers (NSPs) must be able to orchestrate diverse 88 network functions from multiple sources for automation and streamline 89 them into an inter-organizational DevOps workflow. To embrace the 90 DevOps model implies not only to shorten time between deploying, 91 testing and validating of services, but also to enable the mechanisms 92 for the network to consider application layer requirements and 93 reaction to SLAs, and to ease network reconfiguration in order to 94 achieve fast reaction in a timely manner. 96 Development and operational tools, the two essential pillars of 97 DevOps, translate into the need of addressing the interfacing of 98 service development tasks and the service platform, which in DevOps 99 are closely linked together. It is required to emphasize the need 100 for quick turn-around times in service development and operation, and 101 materialize it in a mediated interface making a direct collaboration 102 on both the development and the platform side possible. 104 The branching to multiple stakeholders in the service lifecycle 105 creates an inter-organizational dynamics that must be taken into 106 account. A realistic NFV DevOps approach has to take into account a 107 trustworthy cycle with a mediation element that ensures compliance 108 policies set by the NSP considering legacy situation, allowing 109 developers across stakeholders to enter the ecosystem. Such a 110 mediation element is what we will refer as a "gatekeeper" in the rest 111 of this document. The resulting strategy opens collaborating 112 opportunities while mitigating liability risks across the network 113 service lifecycle. 115 2. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in [RFC2119]. 121 In this document, these words will appear with that interpretation 122 only when in ALL CAPS. Lower case uses of these words are not to be 123 interpreted as carrying RFC-2119 significance. 125 3. The Essential Components for NFV DevOps 127 The collaboration between the development and operational tasks to 128 build a service lifecycle according to the DevOps principles requires 129 to combine service programming and orchestration frameworks by means 130 of the following components: 132 o Catalogues, storing static information regarding network functions 133 and services: code, executables, configuration data, and specific 134 management requirements and preferences. Contents, location, 135 organization, and implementation of catalogues for different 136 artefacts can vary considerably. However, users of these 137 catalogues need to deal with them in a consistent fashion and the 138 differences across different catalogues need to be harmonized and 139 abstracted away. As a high-level categorization, the following 140 three types of catalogues can be considered: 142 * Private catalogues of service developers, where they can 143 define, access, reuse, and modify services and service 144 components. 146 * Service platform catalogues made available to authorized 147 service developers for reusing existing components in their 148 services, and used for storing services and their components 149 that need to be deployed by the service platform. 151 * Public catalogues storing artefacts developed and maintained by 152 third-party developers on arbitrary platforms accessible to 153 service developers and service platform operators. 155 o Service Development Kit (SDK). The SDK supports service 156 developers by providing a service programming model and a 157 development tool-chain, designed to support developers in defining 158 and testing complex services consisting of multiple network 159 functions, and to facilitate custom implementations of individual 160 network functions. The implemented artefacts are stored in the 161 developer's private catalogues. Moreover, service components can 162 easily be obtained from external catalogues. The obtained 163 artefacts can be directly used in a service or after being 164 modified and tested using the SDK development tools. The service 165 components and all the information necessary for deployment and 166 execution of a service are bundled together into a package. The 167 service package can be handed over to a service platform for 168 actual deployment and for testing, debugging, and profiling 169 purposes. 171 o Service Platform. The service platform receives the service 172 packages implemented and created with the help of the SDK and is 173 responsible for placing, deploying, provisioning, scaling, and 174 managing the services on existing cloud infrastructures. It can 175 also provide direct feedback about the deployed services to the 176 SDK, for example, monitoring data about a service or its 177 components. The service developer can ship the service package to 178 the service platform together with service- or function-specific 179 lifecycle management requirements and preferences. A gatekeeper 180 module in the service platform is responsible for processing the 181 incoming and outgoing requests. 183 o Underlying Infrastructure. The infrastructure needs to host and 184 execute the actual network functions of a service, e.g., as a 185 virtual machine. The service platform sends necessary information 186 and instructions for execution and lifecycle management of 187 services to the infrastructure. The infrastructure may belong to 188 the service platform operator, or to a third-party infrastructure 189 operator. The interaction between the service platform and the 190 infrastructure is done through a Virtual Infrastructure Manager 191 (VIM). In a typical deployment, the service platform runs 192 directly on top of an actual infrastructure. However, there can 193 be service platforms supporting a recursive deployment model, 194 where a service platform can act as an abstraction to the 195 underlying infrastructure for another service platform. The 196 service platform gatekeeper can play a relevant role to support 197 mediated recursion as well. 199 The DevOps workflow is supported by the integration between the SDK 200 and the service platform. This workflow implies continuous 201 deployment and continuous integration during service development. 202 The main entity exchanged between the SDK and the service platform is 203 the service package to be deployed and runtime information like 204 monitoring data and performance measurements regarding the service 205 package, which is provided to the service developer during the 206 development phase, as well as the runtime. This information can be 207 used for optimizing, modifying, and debugging the operation and 208 functionality of services. 210 4. The Role of the Gatekeeper 212 The gatekeeper is the module in the service platform that validates 213 the services submitted to that platform, mediating the development 214 and operational tasks, by performing the basic functions described 215 here. 217 4.1. User Management 219 User management allows the service platform owner to control who can 220 do what in the platform. This feature is particularly important in 221 recursive scenarios, on which we may have a chain of service 222 platforms interacting for the implementation of an end-to-end 223 service. 225 The most basic feature of any user management component will be to 226 know who is the user, a feature that is usually called 227 authentication. Authentication requires user registration and the 228 maintenance of user identity attributes, including not only 229 identification attributes (user identifiers, passwords, public keys, 230 trusted signing certificates, etc.) but also other information 231 supporting different authorization schemas, such as group-based or 232 role-based ones. 234 The definition of what each (known) user can do is usually called 235 authorization. The most common approach nowadays to authorization is 236 called role-based, in which each user is assigned one (or more) 237 role(s) and different roles have different permissions. This extra 238 level of indirection, that is users to roles and roles to 239 permissions, simplifies the overall maintenance of the system, when 240 compared to a more direct scheme, like users permissions. Specially 241 when accessing external APIs, it is common to issue temporary keys 242 (then usually called tokens) which enable temporary access to those 243 APIs. Real keys therefore do not leave the realm on which they are 244 valid and useful, thus increasing the overall level of security. 246 4.2. Package Management 248 The gatekeeper receives the software to be validated in the form of 249 packages. Package management is mostly about accepting and 250 validating new or updated packages. The metadata describing such 251 packages is called package descriptor, and constitutes the core of 252 the gatekeeper interface. 254 Only known (i.e., successfully authenticated) and authorized users 255 will be able to submit new or revised services through the 256 gatekeeper. On-boarding of a package can only be considered 257 successful when package validation and attestation is successful. 259 Only then the (new version of) the package will become part of the 260 catalogue. On-boarding requests are usually processed in a first 261 come, first served way, otherwise contradictory requests may 262 jeopardize the whole system. The usual solution for this problem is 263 to use a queue mechanism that guarantees this sequence. 265 A package descriptor is validated in several ways: 267 o Syntax, comprising the validation against the expected package 268 descriptor format. 270 o Semantics, which includes the validation of at least the basic 271 parameters. The exact semantic aspects to be validated will 272 depend on the content and format chosen for the package 273 descriptor. 275 o Licensing, by checking that all external dependencies (i.e., 276 packages, libraries or services) have to have their licenses 277 checked before being used. 279 o Tests availability. Although this might be seen as part of the 280 syntactic/semantic correction, there must be a set of tests that 281 can be executed when validating the package. Depending of the 282 scope and complexity of the Service, these tests may be a subset 283 of the unit tests or a more elaborate suit of integration tests. 285 o Tests execution. Besides providing a suit of tests, these have to 286 be successfully executed. This execution may (usually will) imply 287 the creation and initialization of at least one test environment. 288 When the package under test depends on other packages, libraries 289 or services, those too should be taken into account in the 290 execution of the package tests. 292 The service package must include some signatures that allows validate 293 its content and the component VNFs and other components (forwarding 294 graphs, test suites, etc. 296 Requests for a change in the life-cycle of a package must be 297 validated. This might be a simple authorization configuration. 299 o Deployment. Valid packages, available at the service platform 300 repository, may receive a request for deployment. Package 301 deployment implies the creation of all the environments and 302 connections needed for the package and its dependencies to work 303 and of an instance of that package. 305 o Instance (re)-configuration. A deployed package instance may need 306 to be configured. A special kind of configuration might be, for 307 packages supporting multi-tenancy, adding a new tenant. The 308 package may have "open parameters" that can only be closed upon 309 instantiation (e.g., an IP address). If a Package upgrade 310 happens, a reconfiguration of the instance must also be made. 312 o Instance (re-)start. When, e.g., configuration changes. 314 o Instance monitoring. This is not strictly a change in the life- 315 cycle, but would require the execution of certain aspects 316 identified by the package descriptor or its components. 318 o Instance stop. Includes soft-stop (i.e., not accepting new 319 requests and letting currently running request reach their end of 320 life normally, with a pre-defined time-out) and hard-stop (i.e., a 321 sudden stop, with requests still being answered by the service). 323 o Instance termination. Frees any resource(s) that were being used, 324 taking care of dependencies. 326 o Removal. It requieres an evaluation of currently running 327 instances and dependencies. 329 5. Security Considerations 331 The gatekeeper acts as the security enforcement point for all DevOps 332 interactions between the development and operational tasks, and even 333 between different layers in recursive structure. 335 Gatekeeper APIs will have to be secured, providing identification, 336 confidentiality, integrity and non-repudiation. 338 Other potential threats are related to denial-of-service, whereby an 339 adversary could make the whole NFV environment unusable by 340 overloading the gatekeeper with a high number of requests or requests 341 tailored to exhaust its resources. Mechanisms for overload detection 342 and mitigation should be put in place. 344 6. IANA Considerations 346 This document requires no IANA actions. 348 7. Acknowledgements 350 This work has been partially performed in the scope of the SONATA 351 project [SONATA], which has received funding from the European 352 Union's Horizon 2020 research and innovation programme. The authors 353 would like to acknowledge the contributions of their colleagues. 354 This information reflects the consortium's view, but the consortium 355 is not liable for any use that may be made of any of the information 356 contained therein. 358 8. References 360 8.1. Normative References 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 364 RFC2119, March 1997, 365 . 367 8.2. Informative References 369 [SONATA] "Project SONATA", . 371 Authors' Addresses 373 Pedro A. Aranda Gutierrez 374 Telefonica I+D 375 Zurbaran, 12 376 Madrid 28010 377 Spain 379 Email: pedroa.aranda@telefonica.com 381 Jose Bonnet 382 Altice Labs 383 Rua Eng. Jose Ferreira Pinto Basto 384 Aveiro, 3810-106 385 Portugal 387 Phone: +351 234 403 200 388 Email: jbonnet@alticelabs.com 389 Diego R. Lopez 390 Telefonica I+D 391 Zurbaran, 12 392 Madrid, 28010 393 Spain 395 Phone: +34 913 129 041 396 Email: diego.r.lopez@telefonica.com