ETSI GR NFV-EVE 010 V3.1.1 (2017-12)

Network Functions Virtualisation (NFV) Release 3; Licensing Management; Report on License Management for NFV

DGR/NFV-EVE010

General Information

• Status: Published
• Publication Date: 19-Dec-2017
• Technical Committee: NFV EVE - Evolution and Ecosystem
• Current Stage: 12 - Completion
• Due Date: 09-Jan-2018
• Completion Date: 20-Dec-2017

Standards Content (Sample)

GROUP REPORT
Network Functions Virtualisation (NFV) Release 3;
Licensing Management;
Report on License Management for NFV
Disclaimer
The present document has been produced and approved by the Network Functions Virtualisation (NFV) ETSI Industry
Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GR NFV-EVE 010 V3.1.1 (2017-12)

Reference
DGR/NFV-EVE010
Keywords
license schemes, management, NFV

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2017.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members.
GSM® and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI GR NFV-EVE 010 V3.1.1 (2017-12)

Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 7
4 NFV licenses . 8
4.1 NFV licenses scope . 8
4.2 NFV licenses categorization . 8
4.2.1 Introduction. 8
4.2.2 Open Source software licenses . 9
4.2.3 Proprietary software licenses . 9
4.2.4 Declarative software licenses . 10
4.3 VNF licenses . 10
4.4 Enforcement of VNF licenses . 11
5 NFV Licenses use cases . 11
5.1 Use Case 1: On-demand instantiation and termination of Virtual Firewall (vFirewall) . 11
5.1.1 Introduction. 11
5.1.2 Business Value . 11
5.1.3 Actors and roles . 12
5.1.4 Pre-conditions . 12
5.1.5 Post-conditions . 12
5.1.6 Flow description . 12
5.2 Use Case 2: VNF licenses implications for sharing of vFirewall VNFs instances across NFVI-PoPs . 13
5.2.1 Introduction. 13
5.2.2 Business Value . 14
5.2.3 Actors and roles . 14
5.2.4 Pre-conditions . 14
5.2.5 Post-conditions . 14
5.2.6 Flow description . 15
5.3 Use Case 3: Applying revised license terms to an on-boarded VNF Package . 15
5.3.1 Introduction. 15
5.3.2 Business Value . 16
5.3.3 Actors and roles . 16
5.3.4 Pre-conditions . 16
5.3.5 Post-conditions . 16
5.3.6 Flow description . 17
5.4 Use Case 4: Applying VNF license to enable or disable VNF functionalities . 17
5.4.1 Introduction. 17
5.4.2 Business Value . 17
5.4.3 Actors and roles . 17
5.4.4 Pre-conditions . 18
5.4.5 Post-conditions . 18
5.4.6 Flow description . 18
5.5 Use Case 5: License event reporting . 19
5.5.1 Introduction. 19
ETSI
4 ETSI GR NFV-EVE 010 V3.1.1 (2017-12)
5.5.2 Business Value . 19
5.5.3 Actors and roles . 19
5.5.4 Pre-conditions . 20
5.5.5 Post-conditions . 20
5.5.6 Flow description . 20
5.6 Use Case 6: Identifying the need of additional license . 20
5.6.1 Introduction. 20
5.6.2 Business Value . 20
5.6.3 Actors and roles . 20
5.6.4 Pre-conditions . 20
5.6.5 Post-conditions . 21
5.6.6 Flow description . 21
5.7 Use Case 7: Use of declarative licenses for vEPC-VNF . 21
5.7.1 Introduction. 21
5.7.2 Business value . 21
5.7.3 Actors and roles . 22
5.7.4 Pre-conditions . 22
5.7.5 Post-conditions . 22
5.7.6 Flow description . 23
6 Use case analysis . 23
6.1 VNF license recommendations . 23
7 NFV license final report . 29
7.1 Management and operational aspects . 29
Annex A: Authors & contributors . 30
History . 31

ETSI
5 ETSI GR NFV-EVE 010 V3.1.1 (2017-12)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) Network Functions
Virtualisation (NFV).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
Today there is huge diversity of license management mechanisms across VNF Providers which makes service
provisioning and license renewing operations more complex, error prone and time consuming. It also makes it difficult
to deal with VNF license usage information for settlement between the Service Provider and the VNF Provider.
These issues can be resolved by establishing a standard NFV license management architecture which will have the
following benefits:
• Speed up provision of VNF service without customizing the license management procedure for each VNF-type
or VNF Provider.
• Simplifying acquisition of VNF license usage information.
• Reduce licensing errors.
• Simplified license management operations independent of the underlying VNF solution.
A guiding principle is to minimize the impact on the existing NFV specifications by identifying the minimum features
needed to implement any commercial license management framework typically residing in a separate or higher layer
system (e.g. OSS/BSS).
In order to provide a standardized licensing mechanism, it is necessary to identify the functional blocks, interfaces, and
flows impacted by the requirement to implement any commercial license management framework.
ETSI
6 ETSI GR NFV-EVE 010 V3.1.1 (2017-12)
1 Scope
The present document studies the features needed within the NFV-MANO framework to support license management
for NFV. In this version of the document, a focus is made on the software licenses for VNFs. A set of use cases related
to VNF licenses in the NFV environment are described, analyzed and used to understand the issues and produce
recommendations regarding support for license management within the NFV architectural and NFV-MANO
frameworks.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] TM Forum IG1143 Release 16.5.1: "Frameworx Exploratory Report - License Management".
[i.2] ISO/IEC 19770-5:2015: "Information technology - IT asset management - Part 5: Overview and
vocabulary".
NOTE: Available at https://www.iso.org/standard/68291.html.
[i.3] ETSI GS NFV 003: "Network Functions Virtualisation (NFV); Terminology for Main Concepts in
NFV".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in [i.3] and the following apply:
NOTE: A term defined in the present document takes precedence over the definition of the same term, if any, in
[i.3].
license key: identifier key or activation code associated with VNF, made available by VNF Provider to Service
Provider for operating a VNF instance
license pool: pool of licenses containing licenses to be processed on-demand without need for real-time interaction with
the VNF Provider
NOTE: The Service Provider could maintain a real-time view of all licenses available in the license pools.
ETSI
7 ETSI GR NFV-EVE 010 V3.1.1 (2017-12)
VNF license: legal rights to use a VNF in accordance with terms and conditions specified by the VNF licensor
NOTE 1: "Using a VNF" can include: accessing, copying, distributing, installing and executing the VNF software,
depending on the license's terms and conditions.
NOTE 2: Specified license terms and conditions can include VNF components' license information if different than
the one of the VNF.
NOTE 3: This definition has been specialized from the term "software license" as defined in International Standard
ISO/IEC 19770-5 [i.2].
VNF license entitlement: VNF license use rights as defined through agreements between a VNF licensor and a VNF
licensee
NOTE 1: Effective use rights take into account any contracts and all applicable licenses, including full licenses,
upgrade licenses and maintenance agreements.
NOTE 2: A commonly used synonym for this term is "VNF license terms".
NOTE 3: This definition has been specialized from the term "software entitlement" as defined in International
Standard ISO/IEC 19770-5 [i.2].
VNF licensee: person or organization granted a license to use a specific VNF
NOTE: This definition has been specialized from the term "software licensee" as defined in International
Standard ISO/IEC 19770-5 [i.2].
VNF licensor: person or organization who owns or holds the rights to issue a VNF license for a specific VNF package
NOTE 1: This entity might or might not create the VNF software.
NOTE 2: This definition has been specialized from the term "software licensor" as defined in International
Standard ISO/IEC 19770-5 [i.2].
VNF usage: consumption against a VNF license entitlement measured as defined by the terms and conditions of that
entitlement
NOTE 1: Depending on the specific terms and conditions, usage can include accessing, copying, distributing,
installing and executing the VNF software.
NOTE 2: This definition has been specialized from the term "software usage" as defined in International Standard
ISO/IEC 19770-5 [i.2].
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in [i.3] and the following apply:
NOTE: An abbreviation defined in the present document takes precedence over the definition of the same
abbreviation, if any in [i.3].
BSD Berkeley Software Distribution
BSS Business Support System
CAPEX Capital Expenditures
CI/CD Continuous Integration / Continuous Development
EM (Network) Element Manager
EPC Evolved Packet Core
EULA End-User License Agreement
FOSS Free and Open Source Software
GPL General Public License
IMS IP Multimedia Subsystem
LGPL Lesser General Public License
LM License Management
MIT Massachusetts Institute of Technology
MPL Mozilla Public License
ETSI
8 ETSI GR NFV-EVE 010 V3.1.1 (2017-12)
NFVI Network Functions Virtualisation Infrastructure
NFVO NFV Orchestrator
OPEX Operational Expenditure
OSS Operation Support System
PAYG Pay As You Go/Grow
RGW Residential GateWay
SAM Software Asset Management
SAU Simultaneous Active Users
VNF Virtual Network Function
VNFC Virtualised Network Function Component
4 NFV licenses
4.1 NFV licenses scope
Generally speaking (see note) the software licenses differ according to the rights that are actually granted to the licensee
by the licensor. The scope of those rights covers all what the licensee could do with the licensed software in his
business processes and which may be subject to authorization by the licensor. Usually, the licensee might copy the
software, possibly modify for internal development purpose, resell the derived software and by the way sublicense the
acquired licensed software, distribute it as such or simply deploy and use it to provide services to his customers.
The rights can be granted for a delimited period, i.e. subscription-based license or without time limit, i.e. perpetual
license.
NOTE: This is not limited to NFV software.
4.2 NFV licenses categorization
4.2.1 Introduction
Different types of software licenses exist today and many of them can be reused in the context of NFV. A classification
is generally made according to the entitlement regarding the reproduction (i.e. copy), distribution and use of the
software, which can be different depending on the process of software production and motivations of the licensor,
which can be, for example a software editor or an open source community.
Table 1 gives a high level classification of software licenses.
Table 1: Overall classification of software licenses
Free and Open Source Software (FOSS)
Public Open Source Open Source Open Source Freeware, Trade
Rights Proprietary
domain (Without (Weak (Strong Shareware, secret
copyleft) copyleft) copyleft) Freemium
SQLite, Apache, BSD, GNU LGPL, GNU GPL, Irfanview, World of
Examples Windows
ImageJ MIT MPL GNU Affero Winamp warcraft
Copyright
No Yes Yes Yes Yes Yes Yes
retained
Right to
Yes Yes Yes Yes Yes Yes No
use
Right to
Yes Yes Yes Yes Often No No
copy
Right to
Yes Yes Yes Yes No No No
modify
Right to Yes, under Yes, under Yes, under
Yes Often No No
distribute same license same license same license
Right to
Yes Yes No No No No No
sublicense
ETSI
9 ETSI GR NFV-EVE 010 V3.1.1 (2017-12)
The present document focuses on two "families" of software license:
• Open Source software licenses.
• Proprietary software licenses, used for commercial software products.
4.2.2 Open Source software licenses
There are several subtypes of Open Source software but they all assume that the source code is available according to
the terms of a license that allows the licensee to use but also modify and distribute this code.
Open Source software is also characterized by a charter on rights and duties based on a community model organizing
the use of the software for the benefit of all licensees.
Three subtypes are distinguished in particular by a criterion called copyleft which diverts the principle of copyright to
preserve the freedom of any user to use, modify and distribute the software and its derived versions.
Three degrees of copyleft are identified which specify the obligations with regard to the distribution of modified
software:
• Strong copyleft implies that the whole modified software is subject to the same type of license as the original
copyleft software.
• Weak copyleft allows to compose the copyleft software components with any other software (open source or
proprietary), and in the modified software, only the copyleft software components keep the original copyleft
license.
• Without copyleft, where the choice of the software license for the modified software is free (open source or
proprietary).
4.2.3 Proprietary software licenses
For commercial proprietary software the licensor grants the use of one or more copies of software under the End-User
License Agreement (EULA), but ownership of those copies remains with the licensor, therefore also called proprietary
software.
This characteristic of proprietary software means that, on one hand certain rights relating to the software (see Table 1),
in particular those regarding modification and distribution are reserved by the licensor and on the other side the use are
allowed but subject to entitlements, i.e. the terms and conditions specified in the license.
Business Models
For commercial software products, the licensor monetizes use and distribution rights to finance the development costs
and make profits. Examples of business models for proprietary licenses are:
• FLAT: A perpetual right to use the software is purchased at a fixed price. The price depends on the features of
the software, but is bought entirely from the beginning.
• PAY-AS-YOU-GROW: A perpetual right to use the software is purchased progressively according to the
growth of the service it is deployed for. A metric is used to measure the growth.
• SUBSCRIPTION: A temporary right to use the software (term base) is acquired for a given period of time.
The renewal of this right is decided at the end of each period.
NOTE: License restrictions can be applied to the above business models.
Metrics
Business models of proprietary software licenses are all based on a manner to measure the use of the software. Any
measuring technique relies on well-defined metrics. Metrics differ according to several criteria as for instance, the
network domain and market considered. For instance, for software dedicated to a user (e.g. vRGW), counting the
number of instances actually deployed is probably sufficient. In the case of the Virtualisation of mobile core network
and IMS network functions (e.g. vIMS, vEPC), other metrics are usually used such as the Simultaneous Active Users
(SAU).
ETSI
10 ETSI GR NFV-EVE 010 V3.1.1 (2017-12)
4.2.4 Declarative software licenses
In this approach, software use is left to the software license and enforcement to license terms and condition is done
offline as per the business agreement. One of possible way is to implement it through audit.
Reconciliations between the software licensor and the software licensee can be carried out (off-line) on the basis of:
1) Software usage measurements and reporting based upon the license defined metrics.
2) Explicit business agreements between the software licensor (e.g. VNF Provider) and the software licensee (e.g.
Service Provider).
4.3 VNF licenses
Software licenses are applicable in the different functional domains of network architectures based on NFV (e.g. OSS /
BSS, NFV-MANO, VNF, NFVI). However, it is in the VNF domain that the ruptures are the most important. Indeed,
the promise of time-to-market reduction relies on CI/CD concepts and automated processes (e.g. on-boarding) are
essential across all the domains. In the present document a focus is made on the software licenses for VNFs.
Service providers will be deploying VNFs from many VNF Providers with various terms and agreement for use.
Runtime VNFs instances will be managed and orchestrated by NFV-MANO based on agreed licensing policies and
business models. Streamlining/automating the management and operational aspects of VNF licenses will be very
important to realize the cost saving benefits for NFV. On the other side, it is expected that the management of licenses
does not have impact on service continuity:
• NFV-MANO will use the license for the VNF instantiation and operation.
• Enforcement of the contract between the VNF Provider and the Service Provider should be enabled by a
mechanism trusted by both the parties.
• Usage of VNF licenses needs to be handled proactively to meet the requirements for continuity of the service.
• Service providers adhere to the license policies as per agreed business model and metrics.
• Auto scaling may not work if desired licenses are not in place and even a well-defined automated process for
obtaining licenses on demand cannot guarantee to have the license installed on-time.
• To get the desired business benefit, especially for long term planning it is important to monitor the usage of
VNFs based on the VNF license agreements in place.
• Ability to implement a flexible and extensible model for VNF licenses is essential for cost efficiency.
• There is need to standardize the acquisition of VNF licenses information’s to ensure it is VNF and VNF
Provider agnostic.
It is important to note that in the B2B market, and especially with important customers as telecommunication operators,
a declarative license approach is commonly used (in place of a license management module) which consists in
entrusting the software licensee with the task of controlling by himself that the use of the software is made in
accordance with the license terms defining the rights of use and associated limits. Telecommunication operators are
used to managing their software licenses and have a dedicated business process called Software Asset Management
(SAM). The SAM needs to be adapted to fit with automation processes orchestrated by NFV-MANO.
Telecommunication operators have always collected usage data from their network resources for scaling and business
planning and this will not change with the Virtualisation of network functions. Obviously, these usage data are
considered as sensitive and Virtualisation will not change this.
The management of VNF licenses in the Service Provider and VNF Provider environment is outside the scope of the
present document. The TM Forum IG1143 [i.1] has studied the implications for OSS/BSS of license management and it
is a useful reference to gain a complete picture of VNF license management requirements.
ETSI
11 ETSI GR NFV-EVE 010 V3.1.1 (2017-12)
4.4 Enforcement of VNF licenses
Different approaches are used today for the enforcement of software licenses. Following are the two examples:
• The first approach is based on an automated enforcement of VNF licenses during VNF operations, especially
during instantiation and scaling of VNFs. In this case, an operation (e.g. instantiation) will not be carried out if
it contravenes the terms of the acquired license(s).
• The second approach is based on the declarative VNF license concept (see clause 4.3). In this case the
operations on the VNF will be carried out as per the license agreement. A regularization is carried out on the
basis of VNF usage measurements and reporting as well as explicit business agreements between the VNF
Provider (i.e. the VNF licensor) and the Service Provider (i.e. the VNF licensee) regarding this situation.
Business agreements might refer to the possibility of audits performed by the VNF licensor in order to
strengthen the confidence on the well follow-up of the terms of the business agreements.
The use cases presented in clause 5 cover both approaches:
• Use cases 1 to 6 assume the existence of an on-line license enforcement (using a licenses management
function).
• Use case 7 assumes a declarative license, the possibility of audits and an off-line regularization (using a
centralized SAM function).
NOTE: Enforcement of license is to be looked into from both Service Provider and VNF Provider perspective.
5 NFV Licenses use cases
5.1 Use Case 1: On-demand instantiation and termination of
Virtual Firewall (vFirewall)
5.1.1 Introduction
This use case highlights the use of license for vFirewall VNF, instantiation and termination based on End User order
journey. A vFirewall VNF is composed of a single VNFC which is packaged as a VNF sourced from a VNF Provider.
For the purpose of describing the license management lifecycle, it is assumed that the Service Provider has already on-
boarded the vFirewall VNF Package from the VNF Provider. It is further assumed that:
• For each End User there will be separate instances of vFirewall that will be created to fulfil the End User
order.
• The on-boarded vFirewall VNF Package will be used to create new instances.
• The Service Provider will procure a new license for each new instance of vFirewall.
5.1.2 Business Value
Efficient management of VNF licenses will enable realization of the expected OPEX and CAPEX cost savings for NFV
deployment through automation of the VNF lifecycle, including automation of VNF licensing:
• Service Provider only pays for the number of active instances of vFirewall.
• Once the End User disconnects the vFirewall service offering, the Service Provider will release the license key
back to the VNF Provider or release it to the license pool for reuse.
• Automation of on-boarding and release of licenses without manual intervention.
• Enforcement of the contract between the VNF Provider and the Service Provider should be enabled by a
mechanism trusted by both the parties.
ETSI
12 ETSI GR NFV-EVE 010 V3.1.1 (2017-12)
• VNF license enforcement is performed according to the terms of the contract between VNF Provider and
Service Provider through the use of licenses.
5.1.3 Actors and roles
The use case actors and roles are as follows:
• VNF Provider: This actor provides vFirewall VNF Packages and associated licenses for use.
• Service Provider: This actor uses the vFirewall VNF Package to create services for its End Users and pays the
VNF Provider based on the number of active vFirewall instances.
• End User: This actor subscribes for services from Service Provider.
• License Manager: This actor provides the following:
- Maintaining a license pool for the VNFs.
- Answering to NFV-MANO’s license need and providing the license keys.
- Metering and reporting on "VNF usage" for a "pay as you grow" model.
NOTE: License Manager should be trusted by both Service Provider and VNF Provider.
5.1.4 Pre-conditions
The use case pre-conditions are as follows:
• The Service Provider has already on-boarded the vFirewall VNF Package from the VNF Provider.
• Each End User specific service will have its own instance(s) of vFirewall.
• An agreement with the VNF Provider in place to pay for each instance of the vFirewall.
• The Service Provider will acquire or release licenses for each vFirewall instances back to VNF Provider, or to
the license pool for re-use as and when required.
5.1.5 Post-conditions
The use case post-conditions are as follows:
• As part of End User order fulfilment, the Service Provider will acquire the licenses for instantiation of
vFirewall.
• The acquired license will be associated with the vFirewall instance which in turn will be associated with the
End User service.
• Once the End User discontinues the service, the Service Provider will release the license key back to the VNF
Provider or to the license pool for re-use.
5.1.6 Flow description
The following steps detail the flow description between the actors regarding the order fulfilment for the End User:
• The End User places an order with the Service Provider. The End User order fulfilment requires at least one
instance of vFirewall.
• The Service Provider order fulfilment process will check for license availability from the license pool.
• If no license is available from the license pool, the order fulfilment process at the Service Provider will acquire
an additional license from the VNF Provider via the License Manager.
ETSI
13 ETSI GR NFV-EVE 010 V3.1.1 (2017-12)
• The Service Provider uses the acquired additional license to instantiate the vFirewall to fulfil the End User
order.
• The enforcement of the license is done in the vFirewall domain by checking the validity of the license during
instantiation. If the license is invalid, the instantiation will be denied.
• The License Manager logs and/or reports (in a signed report) the usage of the vFirewall associated licenses as
per the commercial agreement with the VNF Provider.
• The Service Provider will pay the VNF Provider for the use of the additional license as per the commercial
agreement between the Service Provider and the VNF Provider.
The following steps detail the flow description between the actors for cease of services by the End User:
• The End User places an order for cancellation of services with the Service Provider.
• As part of the service cancellation request the vFirewall services for the End User will be stopped. This will
include termination of all the instances of vFirewall used to build the End User services.
• The Service Provider service cancellation process will release the license back to the VNF Provider or to the
license pool for future re-use.
• If the license is no longer required, the Service Provider returns the license to the VNF Provider according to
the commercial agreement between the Service Provider and VNF Provider.
5.2 Use Case 2: VNF licenses implications for sharing of
vFirewall VNFs instances across NFVI-PoPs
5.2.1 Introduction
This use case highlights the use of VNF licenses for vFirewalls instantiated in more than one NFVI-PoP through
sharing the license information.
A vFirewall VNF is composed of single VNFC which is packaged as VNF sourced from VNF Provider. For the purpose
of describing the license management lifecycle, it is assumed that the Service Provider has already on-boarded the
vFirewall VNF Package from the VNF Provider. It is further assumed that:
• The focus of this use case is on license management hence the process of moving the vFirewall instance from
one NFVI-PoP to another is out of scope.
• The on-boarded vFirewall VNF Package will be used to create vFirewall instances.
• Each vFirewall instance will have its own license. The VNF license required for instantiating vFirewall
instances is already made available to the Service Provider (via the license pool), hence there is no need to
approach the VNF Provider for the required licenses.
• One or more End Users will share the same instance of vFirewall.
The following describes the agreement between the Service Provider and the VNF Provider for use of the VNF, along
with other aspects of sharing the vFirewall instance:
• The Service Provider has procured licenses to create X (number of) instances of vFirewall which can be
instantiated across one or more NFVI-PoPs.
• Geolocation restriction:
- A vFirewall instance can only be created in NFVI-PoPs within geographically defined areas as agreed
between Service Provider and VNF Provider.
- Instances of the vFirewall can only be used by an End User located in the defined geographical areas.
ETSI
14 ETSI GR NFV-EVE 010 V3.1.1 (2017-12)
• End User usage restriction:
- The vFirewall instance can only be used by maximum X number of End Users.
• A single NFVO can manage one or more NFVI-PoPs.
• To respond to load changes the NFVO can move the vFirewall instance from one NFVI-PoP to another one
under NFVO control. This can be done by the NFVO alone since the license has already been acquired.
• If the NFVO needs to create a new vFirewall instances then it will retrieve a license from the license pool.
• If instances of vFirewall are no longer required the NFVO can shutdown surplus instances of the vFirewall and
release the license(s) back to the license pool.
5.2.2 Business Value
Efficient management of VNF licenses will enable realization of the expected OPEX and CAPEX cost savings for NFV
deployment through automation of the VNF lifecycle, including automation of VNF licensing:
• Once the End User disconnects the vFirewall service offering, the Service Provider will release the license key
back to the VNF Provider or release it to the license pool for reuse.
• Automation of on-boarding and release of licenses without manual intervention.
5.2.3 Actors and roles
The use case actors and roles are as follows:
• VNF Provider: This actor provides vFirewall packages and associated licenses for use.
• Service Provider: This actor uses the vFirewall package to create services for its End Users and pays the VNF
Provider based on the commercial agreement, for example number of active vFirewall instances.
• End User: This actor subscribes for services from Service Provider.
• License Manager: This actor provides the following:
- Maintaining a license pool for the VNFs.
- Answering to NFV-MANO's license need and providing the license keys.
- Metering and reporting on "VNF usage" for a "pay as you grow" model.
NOTE: License Manager should be trusted by both Service Provider and VNF Provider.
5.2.4 Pre-conditions
The use case pre-conditions are as follows:
• The Service Provider has already on-boarded the vFirewall VNF Package from the VNF Provider.
• A fixed number of licenses to create multiple instances for the vFirewall is available to the Service Provider
via the license pool.
5.2.5 Post-conditions
The use case post-conditions are as follows:
• The VNF license of vFirewall wil
...