1、 ETSI GS NFV-SOL 004 V2.3.1 (2017-07) 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 repres
2、ents the views of those members who participated in this ISG. It does not necessarily represent the views of the entire ETSI membership. GROUP SPECIFICATION ETSI ETSI GS NFV-SOL 004 V2.3.1 (2017-07)2 Reference DGS/NFV-SOL004 Keywords NFV, virtualisation ETSI 650 Route des Lucioles F-06921 Sophia Ant
3、ipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice The present document can be downloaded from: http:/www.etsi.org/standards-search The present
4、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
5、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 curren
6、t 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
7、 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 foregoi
8、ng restriction extend to reproduction in all media. ETSI 2017. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members. 3GPPTM and LTE are Trade Marks of ETSI registered for the benefit of its Members and of the 3GPP Organiz
9、ational Partners. oneM2M logo is protected for the benefit of its Members GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI GS NFV-SOL 004 V2.3.1 (2017-07)3 Contents Intellectual Property Rights 4g3Foreword . 4g3Modal verbs terminology 4g31 Scope 5g32 Refere
10、nces 5g32.1 Normative references . 5g32.2 Informative references 5g33 Definitions and abbreviations . 6g33.1 Definitions 6g33.2 Abbreviations . 6g34 VNF package 6g34.1 TOSCA YAML Cloud Service Archive (CSAR) overview . 6g34.1.1 CSAR structure . 6g34.1.2 CSAR with TOSCA-Metadata directory 6g34.1.3 CS
11、AR zip without TOSCA-Metadata directory . 7g34.2 VNF package structure and format . 7g34.3 VNF package file contents . 7g34.3.1 General 7g34.3.2 VNF package manifest file . 7g34.3.3 VNF package change history file 8g34.3.4 VNF package testing files . 8g34.3.5 VNF package licensing information . 9g34
12、.3.6 Certificate file . 9g35 Adding security to TOSCA CSAR . 9g35.1 VNF package authenticity and integrity . 9g35.2 VNF package manifest and certificate files 10g35.3 Conventions in the manifest file . 11g35.4 Signature of individual artifacts . 12g35.5 Support for security sensitive artifacts . 12g
13、3Annex A (informative): TOSCA CSAR examples . 13g3A.1 CSAR with the TOSCA-Metadata directory 13g3A.2 CSAR without the TOSCA-Metadata directory . 13g3Annex B (informative): Authors Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ET
14、SI 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 u
15、pdates on the ETSI Web server) which are, or may be, or may become, essential to the present document. 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“,
16、“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 d
17、irect citation. ETSI ETSI GS NFV-SOL 004 V2.3.1 (2017-07)5 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 ar
18、e 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
19、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 n
20、ecessary 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 t
21、he Internet: Timestamps“. 4 IANA register for Hash Function Textual Names. NOTE: See 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
22、 CMS Structures“. 7 IANA register for Media Types. NOTE: See 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
23、 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: W
24、hile 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 T
25、OSCA-v1.0-os: “TOSCA Version 1.0“. i.2 TOSCA-Simple-Profile-YAML-v1.0-csprd02: “TOSCA Simple Profile in YAML Version 1.0“. i.3 ETSI GS NFV 003: “Network Functions Virtualisation (NFV); Terminology for Main Concepts in NFV“. ETSI ETSI GS NFV-SOL 004 V2.3.1 (2017-07)6 i.4 ETSI GS NFV-SOL 001: “Network
26、 Functions Virtualisation (NFV) Release 2; Protocols and Data Models; NFV Descriptors based on TOSCA“. 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 apply. 3.2 Abbreviations For the purposes of the pre
27、sent document, the following abbreviations apply: CA Certificate Authority CMS Cryptographic Message Syntax CSAR Cloud Service Archive NFVI NFV InfrastructureNFVO NFV Orchestrator TOSCA Topology and Orchestration Specification for Cloud Applications URI Universal Resource Identifier UTF Unicode Tran
28、sformation Format VNF Virtualised Network Function VNFC VNF Component VNFD VNF DescriptorYAML YAML Aint 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 w
29、ith 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
30、 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
31、 contain other directories with bespoke names and contents. 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 TOSC
32、A 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
33、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. ETSI ETSI GS NFV-SOL 004 V2.3.1 (2017-07)7 In order to indicate that the s
34、implified 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 d
35、enotes 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
36、 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.
37、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.
38、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
39、 format of the VNFD 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
40、, 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 mani
41、fest 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 (a
42、rchive with a TOSCA-Metadata directory). In the latter case, the corresponding entry shall be named “Entry-Manifest“. ETSI ETSI GS NFV-SOL 004 V2.3.1 (2017-07)8 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.
43、The “name“ and the “value“ shall be separated by a colon. The name shall be one of those specified in table 1 and the values shall comply with the provisions specified in table 1. Table 1: List of valid names and values for VNF package metadata Name Value vnf_provider_id A sequence of UTF-8 characte
44、rs 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.
45、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
46、 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
47、 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
48、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 chang
49、e 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
