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]