ETSI GS NFV-SOL 004 V2.4.1 (2018-02)

Network Functions Virtualisation (NFV) Release 2; Protocols and Data Models; VNF Package specification

RGS/NFV-SOL004ed241

General Information

• Status: Published
• Publication Date: 12-Feb-2018
• Technical Committee: NFV SOL - Solutions
• Current Stage: 12 - Completion
• Due Date: 09-Mar-2018
• Completion Date: 13-Feb-2018

Standards Content (Sample)

ETSI GS NFV-SOL 004 V2.4.1 (2018-02)






GROUP SPECIFICATION
Network Functions Virtualisation (NFV) Release 2;
Protocols and Data Models;
VNF Package specification
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.

---------------------- Page: 1 ----------------------
2 ETSI GS NFV-SOL 004 V2.4.1 (2018-02)



Reference
RGS/NFV-SOL004ed241
Keywords
data, NFV, protocol, virtualisation

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 2018.
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

---------------------- Page: 2 ----------------------
3 ETSI GS NFV-SOL 004 V2.4.1 (2018-02)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 6
4 VNF package . 6
4.1 TOSCA YAML Cloud Service Archive (CSAR) overview . 6
4.1.1 CSAR structure . 6
4.1.2 CSAR with TOSCA-Metadata directory . 7
4.1.3 CSAR zip without TOSCA-Metadata directory . 7
4.2 VNF package structure and format . 7
4.3 VNF package file contents . 7
4.3.1 General . 7
4.3.2 VNF package manifest file . 8
4.3.3 VNF package change history file . 8
4.3.4 VNF package testing files . 9
4.3.5 VNF package licensing information . 9
4.3.6 Certificate file . 9
4.3.7 Non-MANO artifact sets in a VNF package . 9
5 Adding security to TOSCA CSAR . 10
5.1 VNF package authenticity and integrity . 10
5.2 VNF package manifest and certificate files . 11
5.3 Conventions in the manifest file . 11
5.4 Signature of individual artifacts . 12
5.5 Support for security sensitive artifacts . 12
Annex A (informative): TOSCA CSAR examples . 14
A.1 CSAR with the TOSCA-Metadata directory . 14
A.2 CSAR without the TOSCA-Metadata directory . 14
Annex B (normative): Non-MANO artifact sets registry . 15
B.1 General . 15
B.2 Non-MANO artifact set identifier format. 15
B.3 Registered information . 15
Annex C (informative): Authors & contributors . 17
Annex D (informative): Change History . 18
History . 19


ETSI

---------------------- Page: 3 ----------------------
4 ETSI GS NFV-SOL 004 V2.4.1 (2018-02)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables 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 Specification (GS) has been produced by ETSI Industry Specification Group (ISG) Network Functions
Virtualisation (NFV).
Modal verbs terminology
In the present document "shall", "shall not", "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.

ETSI

---------------------- Page: 4 ----------------------
5 ETSI GS NFV-SOL 004 V2.4.1 (2018-02)
1 Scope
The present document specifies the structure and format of a VNF package file and its constituents, fulfilling the
requirements specified in ETSI GS NFV-IFA 011 [1] for a VNF package.
2 References
2.1 Normative 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.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
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 necessary for the application of the present document.
[1] ETSI GS NFV-IFA 011: "Network Functions Virtualisation (NFV); Management and
Orchestration; VNF Packaging Specification".
[2] TOSCA-Simple-Profile-YAML-v1.1-csprd01: "TOSCA Simple Profile in YAML Version 1.1".
[3] IETF RFC 3339: "Date and Time on the Internet: Timestamps".
[4] IANA register for Hash Function Textual Names.
NOTE: Available at https://www.iana.org/assignments/hash-function-text-names/hash-function-text-
names.xhtml.
[5] IETF RFC 5652 (September 2009): "Cryptographic Message Syntax (CMS)".
[6] IETF RFC 7468: "Textual Encodings of PKIX, PKCS, and CMS Structures".
[7] IANA register for Media Types.
NOTE: Available at https://www.iana.org/assignments/media-types/media-types.txt.
[8] Recommendation ITU-T X.509: "Information technology - Open Systems Interconnection - The
Directory: Public-key and attribute certificate frameworks".
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] TOSCA-v1.0-os: "TOSCA Version 1.0".
[i.2] TOSCA-Simple-Profile-YAML-v1.0-csprd02: "TOSCA Simple Profile in YAML Version 1.0".
ETSI

---------------------- Page: 5 ----------------------
6 ETSI GS NFV-SOL 004 V2.4.1 (2018-02)
[i.3] ETSI GS NFV 003: "Network Functions Virtualisation (NFV); Terminology for Main Concepts in
NFV".
[i.4] ETSI GS NFV-SOL 001: "Network Functions Virtualisation (NFV) Release 2; Protocols and Data
Models; NFV Descriptors based on TOSCA".
[i.5] ETSI NFV registry of non-MANO artifact sets.
NOTE: Available at http://register.etsi.org/NFV.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in ETSI GS NFV 003 [i.3] and the following
apply:
non-MANO artifact: artifact for use by functional blocks beyond NFV-MANO
non-MANO artifact set: set of related non-MANO artifacts which are intended to be used together
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
CA Certificate Authority
CMS Cryptographic Message Syntax
CSAR Cloud Service Archive
NFVI NFV Infrastructure
NFVO NFV Orchestrator
TOSCA Topology and Orchestration Specification for Cloud Applications
URI Universal Resource Identifier
UTF Unicode Transformation Format
VNF Virtualised Network Function
VNFC VNF Component
VNFD VNF Descriptor
YAML YAML Ain't Markup Language
4 VNF package
4.1 TOSCA YAML Cloud Service Archive (CSAR) overview
4.1.1 CSAR structure
TOSCA YAML CSAR file is an archive file using the ZIP file format whose structure complies with the TOSCA
Simple Profile YAML v1.1 Specification [2]. The CSAR file may have one of the two following structures:
• CSAR containing a TOSCA-Metadata directory, which includes the TOSCA.meta metadata file providing an
entry information for processing a CSAR file as defined in TOSCA v1.0 Specification [i.1].
• CSAR containing a single yaml (.yml or .yaml) file at the root of the archive. The yaml file is a TOSCA
definition template that contains a metadata section with template_name and template_version metadata. This
file is the CSAR Entry-Definitions file.
In addition, the CSAR file may optionally contain other directories with bespoke names and contents.
ETSI

---------------------- Page: 6 ----------------------
7 ETSI GS NFV-SOL 004 V2.4.1 (2018-02)
4.1.2 CSAR with TOSCA-Metadata directory
The TOSCA.meta metadata file includes block_0 with the Entry-Definitions keyword pointing to a TOSCA definitions
YAML file used as entry for parsing the contents of the overall CSAR archive.
Any TOSCA definitions files besides the one denoted by the Entry-Definitions keyword can be found by processing
respective imports statements in the entry definitions file (or in recursively imported files).
Any additional artifacts files (e.g. scripts, binaries, configuration files) can be either declared explicitly through blocks
in the TOSCA.meta file as described in TOSCA v1.0 Specification [i.1] or pointed to by relative path names through
artifact definitions in one of the TOSCA definitions files contained in the CSAR file.
In order to indicate that the simplified structure (i.e. not all files need to be declared explicitly) of TOSCA.meta file
allowed by TOSCA Simple profile YAML 1.0 [i.2] is used, the CSAR-Version keyword listed in block_0 of the meta-
file denotes the version 1.1 as described in the below example. Otherwise the CSAR-Version keyword denotes the
version 1.0 and all files are declared explicitly.
EXAMPLE:
TOSCA-Meta-File-Version: 1.0
CSAR-Version: 1.1
Created-by: Onboarding portal
Entry-Definitions: Definitions/ MainServiceTemplate.yaml

END OF EXAMPLE.
4.1.3 CSAR zip without TOSCA-Metadata directory
The yaml file at the root of the archive is the CSAR Entry-Definition file. The CSAR-Version is defined by the
template_version metadata as can be seen in the below example.
EXAMPLE:
tosca_definitions_version: tosca_simple_yaml_1_1
metadata:
  template_name: MainServiceTemplate
  template_author: Onboarding portal
  template_version: 1.0

END OF EXAMPLE.
4.2 VNF package structure and format
The structure and format of a VNF package shall conform to the TOSCA Simple Profile YAML v1.1 Specification of
the CSAR format [2].
NOTE: This implies that the VNF package can be structured according to any of the two options described in
clause 4.1.
4.3 VNF package file contents
4.3.1 General
A VNF Package shall contain the VNFD as the main TOSCA definitions YAML file, and additional files, and shall be
structured according to one of the CSAR structure options described in clause 4.1.
NOTE: ETSI GS NFV-SOL 001 [i.4] specifies the structure and format of the VNFD based on TOSCA
specifications.
ETSI

---------------------- Page: 7 ----------------------
8 ETSI GS NFV-SOL 004 V2.4.1 (2018-02)
If the option with a TOSCA-Metadata directory is used and the CSAR-Version parameter indicates version 1.0, all files
that are contained in the archive shall be referenced from the TOSCA.meta file. If the CSAR-Version parameter
indicates version 1.1, the files that are referenced and pointed to by relative path names through artifact definitions in
one of the TOSCA definitions files (e.g. the VNFD) contained in the CSAR need not be declared in the TOSCA.meta
file.
Examples of VNF package options are described in annex A.
4.3.2 VNF package manifest file
A CSAR VNF package shall have a manifest file. The manifest file shall have an extension .mf and the same name as
the main TOSCA definitions YAML file and be located at the root of the archive (archive without TOSCA-Metadata
directory) or in the location specified by the TOSCA.meta file (archive with a TOSCA-Metadata directory). In the latter
case, the corresponding entry shall be named "Entry-Manifest".
The manifest file shall start with the VNF package metadata in the form of a name-value pairs. Each pair shall appear
on a different line. The "name" and the "value" shall be separated by a colon. The name shall be one of those specified
in table 4.3.2-1 and the values shall comply with the provisions specified in table 4.3.2-1.
Table 4.3.2-1: List of valid names and values for VNF package metadata
Name Value
vnf_provider_id A sequence of UTF-8 characters
See note.
vnf_product_name A sequence of UTF-8 characters0
See note.
vnf_release_data_time String formatted according to IETF RFC 3339 [3].
vnf_package_version A sequence of groups of one or more digits separated by dots.
See note.
NOTE: The value shall be identical to those specified in the VNFD.

An example of valid manifest file metadata entries follows.
EXAMPLE:
metadata:
vnf_product_name: vMRF-1-0-0
vnf_provider_id: Acme
vnf_package_version: 1.0
vnf_release_data_time: 2017.01.01T10:00+03:00

END OF EXAMPLE.
If the VNF package refers to external files, the manifest file shall contain digests of individual files in the package, both
local files contained in the package and external files referenced in the package.
If the VNF package does not refer to external files, the manifest files may contain digests of individual files contained
in the package. If the manifest file does not include digests, the complete CSAR file shall be digitally signed by the
VNF provider. A consumer of the VNF package verifies the digests in the manifest file by computing the actual digests
and comparing them with the digests listed in the manifest file.
The manifest file, or alternatively, the signature of the CSAR file, is the key for decision regarding a VNF package
integrity and validity in terms of its contained artifacts. The specification of the manifest file and specific algorithms
used in digest creation and validation is described in the security related sub-clause.
4.3.3 VNF package change history file
A CSAR VNF package shall have a humanly readable text file describing any change in the constituency of the VNF
package. All the changes in the VNF package shall be versioned, tracked and inventoried in the change history file.
The VNF package change history file shall be named "ChangeLog.txt" and be located at the root of the archive (archive
without TOSCA-Metadata directory) or in the location specified by the TOSCA.meta file (archive with a TOSCA-
Metadata directory). In the latter case, the corresponding entry shall be named "Entry-Change-Log".
ETSI

---------------------- Page: 8 ----------------------
9 ETSI GS NFV-SOL 004 V2.4.1 (2018-02)
4.3.4 VNF package testing files
To enable VNF package validation, a VNF Provider should include in a VNF package files containing necessary
information (e.g. test description) in order to perform VNF testing. The contents of VNF testing information is outside
the scope of the present document.
The VNF testing information shall be located in a directory named "Tests" located at the root of the archive (archive
without TOSCA-Metadata directory) or in the location specified by the TOSCA.meta file (archive with a TOSCA-
Metadata directory). In the latter case, the corresponding entry shall be named "Entry-Tests".
4.3.5 VNF package licensing information
As required in ETSI GS NFV-IFA 011 [1] the VNF package shall contain license information for the released VNF.
The license information shall include a single license term for the whole VNF. In addition the license information may
also include license terms for each of the VNF package artifacts if different from the one of the released VNF.
The VNF licensing information shall be located in a directory named "Licenses" located at the root of the archive
(archive without TOSCA-Metadata directory) or in the location specified by the TOSCA.meta file (archive with a
TOSCA-Metadata directory). In the latter case, the corresponding entry shall be named "Entry-Licenses".
4.3.6 Certificate file
If the manifest file is signed by the VNF provider (see option 1 in clause 5.1), the CSAR VNF package shall contain a
certificate file if the certificate is not included in the signature container (see note) within the manifest file. In this case,
the certificate file shall have an extension .cert and the same name as the main TOSCA definitions YAML file and be
located at the root of the archive (archive without TOSCA-Metadata directory) or in the location specified by the
TOSCA.meta file (archive with a TOSCA-Metadata directory). In the latter case, the corresponding entry shall be
named "Entry-Certificate".
NOTE: Signature container refers to a structure in a standard format (e.g. CMS) which contains signature and
additional data needed to process the signature (e.g. certificates, algorithms, etc.).
If the complete CSAR file is signed by the VNF provider (see option 2 in clause 5.1), the certificate file shall be
contained in a zip file together with the CSAR file and the signature file if the certificate is not included in the signature
file. The certificate file shall have an extension .cert and the same name as the CSAR file.
4.3.7 Non-MANO artifact sets in a VNF package
As required in ETSI GS NFV-IFA 011 [1] the VNF package shall allow to store and identify non-MANO artifact sets in
the VNF package file.
Every non-MANO artifact set shall be identified by a non-MANO artifact set identifier which shall be registered in the
registry (specified in annex B). A non-MANO artifact set identifier shall be a string that consists of sub-strings which
shall not contain characters other than the following: digits (0-9), lowercase ASCII characters (a-z), and the special
characters underscore "_" and dash "-". Sub-strings shall be separated by the dot "." character.
All files belonging to the same non-MANO artifact set shall share a common path prefix other than the root of the
package.
Non-MANO artifact sets shall be declared in the manifest file. If the package contains at least one non-MANO artifact
set, an entry named "non_mano_artifact_sets:" shall be present in the package on its own line after the "metadata"
section that is defined in clause 4.3.2. The section defined by the "non_mano_artifact_sets" keyname shall have the
following structure:
• Every non-MANO artifact set shall be declared on its own line, by a key name that is equal to the non-MANO
artifact set identifier.
• Below the key name, all artifacts that belong to the non-MANO artifact set shall be listed, each on its own line,
starting with key name "Source", followed by a colon (":") and a blank, and further followed by a file name
with path for a file in the CSAR archive that is not contained in the root of this archive.
ETSI

---------------------- Page: 9 ----------------------
10 ETSI GS NFV-SOL 004 V2.4.1 (2018-02)
If the Manifest file provides the integrity assurance of the VNF package (option 1 in clause 5.1), these artifacts shall
also appear in the list of blocks of name-value pairs specified in clause 5.3.
An example of the section that declares the non-MANO artifact sets in the package is provided below.
EXAMPLE:
non_mano_artifact_sets:
foo_bar:
 Source: foobar/foo/foo.yaml
 Source: foobar/foo/foo.script
 Source: foobar/bar/descriptor.xml
prv.happy-nfv.cool:
 Source: happy/cool/123.html
 Source: happy/cool/cool.json
 Source: happy/cool/hot/hot_or_cool.json

END OF EXAMPLE.
5 Adding security to TOSCA CSAR
5.1 VNF package authenticity and integrity
As specified in ETSI GS NFV-IFA 011 [1] a VNF package shall support a method for authenticity and integrity
assurance.
In order to provide the public key based authenticity and integrity for the whole VNF package one of the two following
options shall be followed:
Option 1: The VNF package shall contain a Digest (a.k.a. hash) for each of the components of the VNF
package. The table of hashes is included in the manifest file, which is signed with the VNF
provider private key. In addition, the VNF provider shall include a signing certificate that includes
the VNF provider public key, following a pre-defined naming convention and located either at the
root of the archive or in a predefined location (e.g. directory).
The certificate may also be included in the signature container, if the signature format allows that.
For example, the CMS format allows to include the certificate in the same container as the
signature.
Option 2: The complete CSAR file shall be digitally signed with the VNF provider private key. The VNF
provider delivers one zip file consisting of the CSAR file, a signature file and a certificate file that
includes the VNF provider public key. The certificate may also be included in the signature
container, if the signature format allows that.
In option 2, the VNF package delivered would therefore be according to figure 5.1-1.

Figure 5.1-1: Composition of the VNF Package zip file in option 2
Option 2 is only valid if all artifacts are included in the package, i.e. no external artifacts are referenced in the package.
ETSI

---------------------- Page: 10 ----------------------
11 ETSI GS NFV-SOL 004 V2.4.1 (2018-02)
This solution, either option 1 or option 2, relies on the existence in the NFVO of a root certificate of a trusted CA that
shall have been delivered via a trusted channel that preserves its integrity (separate from the VNF package) to the
NFVO and be pre-installed in the NFVO before the on-boarding of the VNF package.
NOTE: The present document makes no assumption on who this trusted CA is. Furthermore, it does not exclude
that the root certificate be issued by the VNF vendor or by the NFVI provider.
5.2 VNF package manifest and certificate files
When the manifest file provides the VNF package integrity assurance (option 1 in clause 5.1) it contains the digests
(hashes) for each individual file locally stored within the VNF package or referenced from it. Each file related entry of
the manifest file includes the path or URI of the individual file, the hash algorithm and the generated digest. A
consumer of the VNF package shall verify the digests in the manifest file by computing the actual digests and
comparing them with the digests listed in the manifest file.
The VNF package authenticity is ensured by signing the manifest file with the VNF provider private key. The digital
signature is stored in the manifest file itself (see clause 5.3). The VNF provider shall include an X.509 certificate [8] in
the VNF Package. The cert
...