ETSI GS NFV-SOL 007 V2.5.1 (2018-12)

Network Functions Virtualisation (NFV) Release 2; Protocols and Data Models; Network Service Descriptor File Structure Specification

DGS/NFV-SOL007

General Information

• Status: Published
• Publication Date: 10-Dec-2018
• Technical Committee: NFV SOL - Solutions
• Current Stage: 12 - Completion
• Due Date: 04-Jan-2019
• Completion Date: 11-Dec-2018

Standards Content (Sample)

ETSI GS NFV-SOL 007 V2.5.1 (2018-12)






GROUP SPECIFICATION
Network Functions Virtualisation (NFV) Release 2;
Protocols and Data Models;
Network Service Descriptor File Structure 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 007 V2.5.1 (2018-12)



Reference
DGS/NFV-SOL007
Keywords
data, information model, model, NFV,
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 TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners.
®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI

---------------------- Page: 2 ----------------------
3 ETSI GS NFV-SOL 007 V2.5.1 (2018-12)
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 . 6
3 Definition of terms and abbreviations . 6
3.1 Terms . 6
3.2 Abbreviations . 6
4 NSD file structure . 6
4.1 TOSCA YAML Cloud Service Archive (CSAR) . 6
4.2 NSD file structure and format . 7
4.3 NSD file contents . 7
4.3.1 General . 7
4.3.2 NSD file archive manifest file . 7
4.3.3 NSD file archive change history file . 8
4.3.4 Testing files in the NSD file archive . 8
4.3.5 Certificate file . 8
5 Adding security to TOSCA CSAR . 9
5.1 NSD file archive authenticity and integrity . 9
5.2 Manifest and certificate files in the NSD file archive . 9
5.3 Conventions in the manifest file . 10
5.4 Signature of individual artifacts . 11
5.5 Support for security sensitive artifacts . 12
Annex A (informative): TOSCA CSAR Examples . 13
A.1 CSAR with the TOSCA-Metadata directory . 13
A.2 CSAR without the TOSCA-Metadata directory . 13
Annex B (informative): Authors & contributors . 14
Annex C (informative): Change History . 15
History . 16


ETSI

---------------------- Page: 3 ----------------------
4 ETSI GS NFV-SOL 007 V2.5.1 (2018-12)
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 007 V2.5.1 (2018-12)
1 Scope
The present document specifies the structure of the Network Service Descriptor (NSD) file archive and the naming
conventions for the different files it contains, fulfilling the requirements specified in ETSI GS NFV-IFA 014 [1] for an
NSD file structure.
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 014: "Network Functions Virtualisation (NFV) Release 2; Management and
Orchestration; Network Service Templates Specification".
[2] TOSCA-Simple-Profile-YAML-v1.2-csprd01: "TOSCA Simple Profile in YAML Version 1.2".
NOTE: Available at http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csprd01/TOSCA-
Simple-Profile-YAML-v1.2-csprd01.pdf.
[3] IETF RFC 3339: "Date and Time on the Internet: Timestamps".
[4] Recommendation ITU-T X.509: "Information technology - Open Systems Interconnection - The
Directory: Public-key and attribute certificate frameworks".
[5] IANA register for Hash Function Textual Names.
NOTE: Available at https://www.iana.org/assignments/hash-function-text-names/hash-function-text-
names.xhtml.
[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] IETF RFC 5652 (September 2009): "Cryptographic Message Syntax (CMS)".
[9] IETF RFC 3629: "UTF-8, a transformation format of ISO 10646".
ETSI

---------------------- Page: 5 ----------------------
6 ETSI GS NFV-SOL 007 V2.5.1 (2018-12)
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] ETSI GS NFV 003: "Network Functions Virtualisation (NFV); Terminology for Main Concepts in
NFV".
[i.3] ETSI GS NFV-SOL 001: "Network Functions Virtualisation (NFV) Release 2; Protocols and Data
Models; NFV descriptors based on TOSCA specification".
3 Definition of terms and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GS NFV 003 [i.2] apply.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI GS NFV 003 [i.2] and the following apply:
CA Certificate Authority
CMS Cryptographic Message Syntax
CSAR Cloud Service ARchive
IANA Internet Assigned Number Association
TOSCA Topology and Orchestration Specification for Cloud Applications
URI Universal Resource Identifier
UTF Unicode Transformation Format
YAML YAML Ain't Markup Language
4 NSD file structure
4.1 TOSCA YAML Cloud Service Archive (CSAR)
A TOSCA YAML CSAR file is an archive file using the ZIP file format whose structure complies with the TOSCA
Simple Profile in YAML version 1.2 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 007 V2.5.1 (2018-12)
4.2 NSD file structure and format
The structure and format of an NSD file archive shall conform to the TOSCA Simple Profile in YAML version 1.2
specification of the CSAR format [2].
NOTE: This implies that the NSD file archive can be structured according to any of the two options described in
clause 4.1.
4.3 NSD file contents
4.3.1 General
An NSD file archive shall contain the NSD 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.3] specifies the structure and format of the NSD based on TOSCA
specifications.
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 NSD) contained in the CSAR need not be declared in the TOSCA.meta file.
Examples of NSD file archive options are described in annex A.
4.3.2 NSD file archive manifest file
A CSAR NSD file archive shall contain 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 NSD file archive 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 NSD file archive metadata
Name Value
nsd_designer A sequence of UTF-8 [9] characters.
See note 1.
nsd_invariant_id A sequence of UTF-8 [9] characters.
See note 1.
nsd_name A sequence of UTF-8 [9] characters.
See note 1.
nsd_release_date_time String formatted according to IETF RFC 3339 [3].
nsd_file_structure_version A string.
See note 2.
NOTE 1: The value shall be identical to that specified in the NSD.
NOTE 2: The value shall be identical to the version attribute specified in the NSD.

An example of valid manifest file metadata entries follows.
ETSI

---------------------- Page: 7 ----------------------
8 ETSI GS NFV-SOL 007 V2.5.1 (2018-12)
EXAMPLE:
metadata:
nsd_designer: Mycompany
nsd_invariant_id: Sunshine
nsd_name: Sunshine
nsd_file_structure_version: 1.0
nsd_release_date_time: 2018-04-08T10:00+08:00

END OF EXAMPLE
If the NSD file archive refers to external files, the manifest file shall contain digests of individual files in the file
archive, both local files contained in the archive and external files referenced in the archive.
If the NSD file archive does not refer to external files, the manifest files may contain digests of the individual files
contained in the archive. If the manifest file does not include digests, the complete CSAR file shall be digitally signed
by the NS designer. A consumer of the NSD file archive 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 an NSD file archive
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 clause.
4.3.3 NSD file archive change history file
A CSAR NSD file archive shall contain a humanly readable text file describing any change in the constituency of the
NSD file archive. All the changes in the NSD file archive shall be versioned, tracked and inventoried in the change
history file.
The NSD file archive 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".
4.3.4 Testing files in the NSD file archive
To enable NS validation, an NS designer should include in an NSD file archive, files containing necessary information
(e.g. test description) in order to perform NS testing. The contents of NS testing information included in the NSD file
archive is outside the scope of the present document.
The NS testing information in the NSD file archive 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 co
...