Internet DRAFT - draft-sonata-nfvrg-devops-gatekeeper
draft-sonata-nfvrg-devops-gatekeeper
Network Working Group D. Lopez
Internet-Draft TID
Intended status: Experimental J. Bonnet
Expires: September 14, 2017 Altice Labs
M. Peuster
UPB
P. Aranda Gutierrez
UC3M
March 13, 2017
The Role of a Mediation Element in NFV DevOps
draft-sonata-nfvrg-devops-gatekeeper-03
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 September 14, 2017.
Copyright Notice
Copyright (c) 2017 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
Lopez, et al. Expires September 14, 2017 [Page 1]
Internet-Draft A Gatekeeper for NFV DevOps March 2017
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 7
4.3. Monitor Data Transfer . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Lopez, et al. Expires September 14, 2017 [Page 2]
Internet-Draft A Gatekeeper for NFV DevOps March 2017
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.
Lopez, et al. Expires September 14, 2017 [Page 3]
Internet-Draft A Gatekeeper for NFV DevOps March 2017
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 tools of this tool-chains provides all
necesaray interfaces to establish fully automated continuous
Lopez, et al. Expires September 14, 2017 [Page 4]
Internet-Draft A Gatekeeper for NFV DevOps March 2017
integration (CI) workflows. The implemented artefacts are stored
in the developer's private catalogues. Moreover, service
components can 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. The tools provided by a service development
tool-chain can be classified as follows:
* Pre-validation tools used by service developers to ensure the
correctness of service and function descriptions, including
syntax checks, static structure validation, and integrity
ensurance tools.
* Offline testing and emulation tools used by service developers
to conduct functional tests of complex services in well-
defined, reproducible environments. Especially focusing on the
integration and interoperability between multiple network
functions combined to a single service.
* Packaging tools responsible to create the final service bundle.
This class includes tools that automatically resolve external
dependencies of a service to automatically include required
artifacts into a package. It also contains tools which sign
the final package to give service platforms the necessary
confidence that service packages have not been altered during
the uploading procedure and to ensure the authenticity of the
package.
* Tools to support the interaction of a developer with service
platforms as well as services and functions deployed in these
platforms. This includes two ways of interactions. First,
uploading, instantiation and management of service packages on
service platforms. Second, receiving runtime, debugging, and
monitoring information from the platform as well as accessing
artifacts stored in platform catalogues.
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
Lopez, et al. Expires September 14, 2017 [Page 5]
Internet-Draft A Gatekeeper for NFV DevOps March 2017
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.
4. The Role of the Gatekeeper
The gatekeeper is the module in the service platform that mediates
the interactions between the SDK and the SP, settling 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
Lopez, et al. Expires September 14, 2017 [Page 6]
Internet-Draft A Gatekeeper for NFV DevOps March 2017
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.
To support a DevOps environment the following roles are considered:
o Developer, able to publish and update service packages on the
service platform through the SDK, as well as other operations
related to service package status.
o Service provider, in charge of structuring and managing the
services available for a certain organization, or organizational
group, defining an administrative domain.
o Customer, as a user of the public services available for the
administrative domain they belong to, managing their lifecycles
(instantiating, pausing, resuming, retiring...).
o Service platform admin, with management capabilities on the
platform itself, as well as superuser-like control over the
available services. These capabilities include the registration
of roles and users, and the association of users to roles,
enabling the authentication and authorization mechanisms described
above.
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.
Lopez, et al. Expires September 14, 2017 [Page 7]
Internet-Draft A Gatekeeper for NFV DevOps March 2017
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.
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 signatures, generated by the SDK's
packaging tools, that allow the validation of the integrity and
authenticity of the package's contents, the component VNFs, and other
components (forwarding graphs, test suites, etc.). These signatured
can be optionally used to attest the components at different stages
of their lifecycle, and/or during runtime.
Requests for a change in the life-cycle of a package must be
validated. This might be a simple authorization configuration.
Lopez, et al. Expires September 14, 2017 [Page 8]
Internet-Draft A Gatekeeper for NFV DevOps March 2017
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
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.
4.3. Monitor Data Transfer
The gatekeeper is the first point of access to reach the SP from the
SDK. Service developers can use their identities from the SDK to
access monitor data from the SP. After the successful AuthN/AuthZ
phase, developers are granted a session token to access monitoring
data. Multiple developers will use different data access views to
get their own set of authorized monitor data.
It is desirable that the gatekeeper is transparent to the monitor
data transfer, acting as a pure forwarder, apart from the AuthN/AuthZ
phase. Optionally, the gatekeeper could filter non-numerical
monitored data (e.g. obfuscate domain names, IP/MAC addresses...)
transferred in logfiles or packet streams. The session token is used
by the monitor data management components to decide on which data to
expose, so metrics of another user, other services not started by the
developer or the SP itself can never be queried by the SDK. In
addition, other limits can be enforced, such as:
Lopez, et al. Expires September 14, 2017 [Page 9]
Internet-Draft A Gatekeeper for NFV DevOps March 2017
o Limit the number of monitor samples
o Limit the data size to be received
o Limit the time frame during which metrics are accessible
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
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>.
Lopez, et al. Expires September 14, 2017 [Page 10]
Internet-Draft A Gatekeeper for NFV DevOps March 2017
8.2. Informative References
[SONATA] "Project SONATA", <http://www.sonata-nfv.eu/>.
Authors' Addresses
Diego R. Lopez
Telefonica I+D
Zurbaran, 12
Madrid, 28010
Spain
Phone: +34 913 129 041
Email: diego.r.lopez@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
Manuel Peuster
Paderborn University
Warburgerstrasse 100
Paderborn, 33098
Germany
Phone: +49 5251 60 4341
Email: manuel.peuster@upb.de
Pedro A. Aranda Gutierrez
UC3M
Email: paaguti@hotmail.com
Lopez, et al. Expires September 14, 2017 [Page 11]