The Role of a Mediation Element in NFV DevOps
draft-sonata-nfvrg-devops-gatekeeper-00

Network Working Group                                P. Aranda Gutierrez
Internet-Draft                                                       TID
Intended status: Experimental                                  J. Bonnet
Expires: January 6, 2017                                     Altice Labs
                                                                D. Lopez
                                                                     TID
                                                            July 5, 2016

             The Role of a Mediation Element in NFV DevOps
                draft-sonata-nfvrg-devops-gatekeeper-00

Abstract

   This document describes how a mediation element (a "gatekeeper") can
   be applied to support DevOps practices in the provisioning of network
   services based on Network Function Virtualisation (NFV).

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 January 6, 2017.

Copyright Notice

   Copyright (c) 2016 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.  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

Aranda Gutierrez, et al.  Expires January 6, 2017               [Page 1]
Internet-Draft         A Gatekeeper for NFV DevOps             July 2016

   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . . . 4
   3.  The Essential Components for NFV DevOps . . . . . . . . . . . . 4
   4.  The Role of the Gatekeeper  . . . . . . . . . . . . . . . . . . 6
     4.1.  User Management . . . . . . . . . . . . . . . . . . . . . . 6
     4.2.  Package Management  . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 9
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9

Aranda Gutierrez, et al.  Expires January 6, 2017               [Page 2]
Internet-Draft         A Gatekeeper for NFV DevOps             July 2016

1.  Introduction

   The DevOps model is already an established concept in IT industry
   reducing time to market by close collaboration between service
   developers and service operators.  The switch to virtualisation
   technologies in the network and its potential for quicker time-to-
   market deployment requires the application of agile development
   cycles supporting a DevOps approach.  This kind of approach will
   overcome key inhibitors that network operators face when deploying
   NFV, such as lack of legacy compatibility, resource orchestration,
   automation and multi-vendor interoperability, hence facilitating the
   transition to a software-driven network.  The adoption of the DevOps
   model for network services will contribute to interaction between
   development, testing, and operation of network functionalities and
   network services.  Both the function/service description formats as
   well as the infrastructure resource descriptions will be able to
   express and use legacy cases, e.g., the case of a non-virtual network
   function bound to a specific place in the network, with the data
   flows routed accordingly.

   Network Service Providers (NSPs) must be able to orchestrate diverse
   network functions from multiple sources for automation and streamline
   them into an inter-organizational DevOps workflow.  To embrace the
   DevOps model implies not only to shorten time between deploying,
   testing and validating of services, but also to enable the mechanisms
   for the network to consider application layer requirements and
   reaction to SLAs, and to ease network reconfiguration in order to
   achieve fast reaction in a timely manner.

   Development and operational tools, the two essential pillars of
   DevOps, translate into the need of addressing the interfacing of
   service development tasks and the service platform, which in DevOps
   are closely linked together.  It is required to emphasize the need
   for quick turn-around times in service development and operation, and
   materialize it in a mediated interface making a direct collaboration
   on both the development and the platform side possible.

   The branching to multiple stakeholders in the service lifecycle
   creates an inter-organizational dynamics that must be taken into
   account.  A realistic NFV DevOps approach has to take into account a
   trustworthy cycle with a mediation element that ensures compliance
   policies set by the NSP considering legacy situation, allowing
   developers across stakeholders to enter the ecosystem.  Such a
   mediation element is what we will refer as a "gatekeeper" in the rest
   of this document.  The resulting strategy opens collaborating
   opportunities while mitigating liability risks across the network
   service lifecycle.

Aranda Gutierrez, et al.  Expires January 6, 2017               [Page 3]
Internet-Draft         A Gatekeeper for NFV DevOps             July 2016

2.  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 [RFC2119].

   In this document, these words will appear with that interpretation
   only when in ALL CAPS.  Lower case uses of these words are not to be
   interpreted as carrying RFC-2119 significance.

3.  The Essential Components for NFV DevOps

   The collaboration between the development and operational tasks to
   build a service lifecycle according to the DevOps principles requires
   to combine service programming and orchestration frameworks by means
   of the following components:

   o  Catalogues, storing static information regarding network functions
      and services: code, executables, configuration data, and specific
      management requirements and preferences.  Contents, location,
      organization, and implementation of catalogues for different
      artefacts can vary considerably.  However, users of these
      catalogues need to deal with them in a consistent fashion and the
      differences across different catalogues need to be harmonized and
      abstracted away.  As a high-level categorization, the following
      three types of catalogues can be considered:

      *  Private catalogues of service developers, where they can
         define, access, reuse, and modify services and service
         components.

      *  Service platform catalogues made available to authorized
         service developers for reusing existing components in their
         services, and used for storing services and their components
         that need to be deployed by the service platform.

      *  Public catalogues storing artefacts developed and maintained by
         third-party developers on arbitrary platforms accessible to
         service developers and service platform operators.

   o  Service Development Kit (SDK).  The SDK supports service
      developers by providing a service programming model and a
      development tool-chain, designed to support developers in defining
      and testing complex services consisting of multiple network
      functions, and to facilitate custom implementations of individual
      network functions.  The implemented artefacts are stored in the
      developer's private catalogues.  Moreover, service components can

Aranda Gutierrez, et al.  Expires January 6, 2017               [Page 4]
Internet-Draft         A Gatekeeper for NFV DevOps             July 2016

      easily be obtained from external catalogues.  The obtained
      artefacts can be directly used in a service or after being
      modified and tested using the SDK development tools.  The service
      components and all the information necessary for deployment and
      execution of a service are bundled together into a package.  The
      service package can be handed over to a service platform for
      actual deployment and for testing, debugging, and profiling
      purposes.

   o  Service Platform.  The service platform receives the service
      packages implemented and created with the help of the SDK and is
      responsible for placing, deploying, provisioning, scaling, and
      managing the services on existing cloud infrastructures.  It can
      also provide direct feedback about the deployed services to the
      SDK, for example, monitoring data about a service or its
      components.  The service developer can ship the service package to
      the service platform together with service- or function-specific
      lifecycle management requirements and preferences.  A gatekeeper
      module in the service platform is responsible for processing the
      incoming and outgoing requests.

   o  Underlying Infrastructure.  The infrastructure needs to host and
      execute the actual network functions of a service, e.g., as a
      virtual machine.  The service platform sends necessary information
      and instructions for execution and lifecycle management of
      services to the infrastructure.  The infrastructure may belong to
      the service platform operator, or to a third-party infrastructure
      operator.  The interaction between the service platform and the
      infrastructure is done through a Virtual Infrastructure Manager
      (VIM).  In a typical deployment, the service platform runs
      directly on top of an actual infrastructure.  However, there can
      be service platforms supporting a recursive deployment model,
      where a service platform can act as an abstraction to the
      underlying infrastructure for another service platform.  The
      service platform gatekeeper can play a relevant role to support
      mediated recursion as well.

   The DevOps workflow is supported by the integration between the SDK
   and the service platform.  This workflow implies continuous
   deployment and continuous integration during service development.
   The main entity exchanged between the SDK and the service platform is
   the service package to be deployed and runtime information like
   monitoring data and performance measurements regarding the service
   package, which is provided to the service developer during the
   development phase, as well as the runtime.  This information can be
   used for optimizing, modifying, and debugging the operation and
   functionality of services.

Aranda Gutierrez, et al.  Expires January 6, 2017               [Page 5]
Internet-Draft         A Gatekeeper for NFV DevOps             July 2016

4.  The Role of the Gatekeeper

   The gatekeeper is the module in the service platform that validates
   the services submitted to that platform, mediating the development
   and operational tasks, by performing the basic functions described
   here.

4.1.  User Management

   User management allows the service platform owner to control who can
   do what in the platform.  This feature is particularly important in
   recursive scenarios, on which we may have a chain of service
   platforms interacting for the implementation of an end-to-end
   service.

   The most basic feature of any user management component will be to
   know who is the user, a feature that is usually called
   authentication.  Authentication requires user registration and the
   maintenance of user identity attributes, including not only
   identification attributes (user identifiers, passwords, public keys,
   trusted signing certificates, etc.) but also other information
   supporting different authorization schemas, such as group-based or
   role-based ones.

   The definition of what each (known) user can do is usually called
   authorization.  The most common approach nowadays to authorization is
   called role-based, in which each user is assigned one (or more)
   role(s) and different roles have different permissions.  This extra
   level of indirection, that is users to roles and roles to
   permissions, simplifies the overall maintenance of the system, when
   compared to a more direct scheme, like users permissions.  Specially
   when accessing external APIs, it is common to issue temporary keys
   (then usually called tokens) which enable temporary access to those
   APIs.  Real keys therefore do not leave the realm on which they are
   valid and useful, thus increasing the overall level of security.

4.2.  Package Management

   The gatekeeper receives the software to be validated in the form of
   packages.  Package management is mostly about accepting and
   validating new or updated packages.  The metadata describing such
   packages is called package descriptor, and constitutes the core of
   the gatekeeper interface.

   Only known (i.e., successfully authenticated) and authorized users
   will be able to submit new or revised services through the
   gatekeeper.  On-boarding of a package can only be considered
   successful when package validation and attestation is successful.

Aranda Gutierrez, et al.  Expires January 6, 2017               [Page 6]
Internet-Draft         A Gatekeeper for NFV DevOps             July 2016

   Only then the (new version of) the package will become part of the
   catalogue.  On-boarding requests are usually processed in a first
   come, first served way, otherwise contradictory requests may
   jeopardize the whole system.  The usual solution for this problem is
   to use a queue mechanism that guarantees this sequence.

   A package descriptor is validated in several ways:

   o  Syntax, comprising the validation against the expected package
      descriptor format.

   o  Semantics, which includes the validation of at least the basic
      parameters.  The exact semantic aspects to be validated will
      depend on the content and format chosen for the package
      descriptor.

   o  Licensing, by checking that all external dependencies (i.e.,
      packages, libraries or services) have to have their licenses
      checked before being used.

   o  Tests availability.  Although this might be seen as part of the
      syntactic/semantic correction, there must be a set of tests that
      can be executed when validating the package.  Depending of the
      scope and complexity of the Service, these tests may be a subset
      of the unit tests or a more elaborate suit of integration tests.

   o  Tests execution.  Besides providing a suit of tests, these have to
      be successfully executed.  This execution may (usually will) imply
      the creation and initialization of at least one test environment.
      When the package under test depends on other packages, libraries
      or services, those too should be taken into account in the
      execution of the package tests.

   The service package must include some signatures that allows validate
   its content and the component VNFs and other components (forwarding
   graphs, test suites, etc.

   Requests for a change in the life-cycle of a package must be
   validated.  This might be a simple authorization configuration.

   o  Deployment.  Valid packages, available at the service platform
      repository, may receive a request for deployment.  Package
      deployment implies the creation of all the environments and
      connections needed for the package and its dependencies to work
      and of an instance of that package.

   o  Instance (re)-configuration.  A deployed package instance may need
      to be configured.  A special kind of configuration might be, for

Aranda Gutierrez, et al.  Expires January 6, 2017               [Page 7]
Internet-Draft         A Gatekeeper for NFV DevOps             July 2016

      packages supporting multi-tenancy, adding a new tenant.  The
      package may have "open parameters" that can only be closed upon
      instantiation (e.g., an IP address).  If a Package upgrade
      happens, a reconfiguration of the instance must also be made.

   o  Instance (re-)start.  When, e.g., configuration changes.

   o  Instance monitoring.  This is not strictly a change in the life-
      cycle, but would require the execution of certain aspects
      identified by the package descriptor or its components.

   o  Instance stop.  Includes soft-stop (i.e., not accepting new
      requests and letting currently running request reach their end of
      life normally, with a pre-defined time-out) and hard-stop (i.e., a
      sudden stop, with requests still being answered by the service).

   o  Instance termination.  Frees any resource(s) that were being used,
      taking care of dependencies.

   o  Removal.  It requieres an evaluation of currently running
      instances and dependencies.

5.  Security Considerations

   The gatekeeper acts as the security enforcement point for all DevOps
   interactions between the development and operational tasks, and even
   between different layers in recursive structure.

   Gatekeeper APIs will have to be secured, providing identification,
   confidentiality, integrity and non-repudiation.

   Other potential threats are related to denial-of-service, whereby an
   adversary could make the whole NFV environment unusable by
   overloading the gatekeeper with a high number of requests or requests
   tailored to exhaust its resources.  Mechanisms for overload detection
   and mitigation should be put in place.

6.  IANA Considerations

   This document requires no IANA actions.

7.  Acknowledgements

   This work has been partially performed in the scope of the SONATA
   project [SONATA], which has received funding from the European

Aranda Gutierrez, et al.  Expires January 6, 2017               [Page 8]
Internet-Draft         A Gatekeeper for NFV DevOps             July 2016

   Union's Horizon 2020 research and innovation programme.  The authors
   would like to acknowledge the contributions of their colleagues.
   This information reflects the consortium's view, but the consortium
   is not liable for any use that may be made of any of the information
   contained therein.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
              RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

8.2.  Informative References

   [SONATA]   "Project SONATA", <http://www.sonata-nfv.eu/>.

Authors' Addresses

   Pedro A. Aranda Gutierrez
   Telefonica I+D
   Zurbaran, 12
   Madrid  28010
   Spain

   Email: pedroa.aranda@telefonica.com

   Jose Bonnet
   Altice Labs
   Rua Eng. Jose Ferreira Pinto Basto
   Aveiro,   3810-106
   Portugal

   Phone: +351 234 403 200
   Email: jbonnet@alticelabs.com

Aranda Gutierrez, et al.  Expires January 6, 2017               [Page 9]
Internet-Draft         A Gatekeeper for NFV DevOps             July 2016

   Diego R. Lopez
   Telefonica I+D
   Zurbaran, 12
   Madrid,   28010
   Spain

   Phone: +34 913 129 041
   Email: diego.r.lopez@telefonica.com

Aranda Gutierrez, et al.  Expires January 6, 2017              [Page 10]