ETSI GS NFV-SOL 004-2018 Network Functions Virtualisation (NFV) Release 2 Protocols and Data Models VNF Package specification (V2 5 1).pdf

1、 ETSI GS NFV-SOL 004 V2.5.1 (2018-09) 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.5.1 (2018-09)2 Reference RGS/NFV-SOL004ed251 Keywords data, NFV, protocol, virtualisation ETSI 650 Route des Luciol

3、es F-06921 Sophia Antipolis 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/standard

4、s-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 b

5、etween 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. Info

6、rmation 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

7、 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 copy

8、right and the foregoing restriction extend to reproduction in all media. ETSI 2018. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are trademarks of ETSI registered for the benefit of its Members. 3GPPTM and LTETMare trademarks of ETSI registered for the benefit of its Members and

9、 of the 3GPP Organizational Partners. oneM2M logo is protected for the benefit of its Members. GSMand the GSM logo are trademarks registered and owned by the GSM Association. ETSI ETSI GS NFV-SOL 004 V2.5.1 (2018-09)3 Contents Intellectual Property Rights 4g3Foreword . 4g3Modal verbs terminology 4g3

10、1 Scope 5g32 References 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 di

11、rectory 7g34.1.3 CSAR 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 . 8g34.3.3 VNF package change history file 8g34.3.4 VNF package testing files . 9g34.3.5 VNF package licensing

12、 information . 9g34.3.6 Certificate file . 9g34.3.7 Non-MANO artifact sets in a VNF package . 9g35 Adding security to TOSCA CSAR . 10g35.1 VNF package authenticity and integrity . 10g35.2 VNF package manifest and certificate files 11g35.3 Conventions in the manifest file . 12g35.4 Signature of indiv

13、idual artifacts . 13g35.5 Support for security sensitive artifacts . 13g3Annex A (informative): TOSCA CSAR examples . 14g3A.1 CSAR with the TOSCA-Metadata directory 14g3A.2 CSAR without the TOSCA-Metadata directory . 14g3Annex B (normative): Non-MANO artifact sets registry . 15g3B.1 General . 15g3B.

14、2 Non-MANO artifact set identifier format. 15g3B.3 Registered information . 15g3B.4 Initial registration . 16g3B.4.1 Template . 16g3B.4.2 Template . 16g3B.5 Registration update . 17g3Annex C (informative): Authors Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standard

15、s“, 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 refer

16、enced 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 ex

17、cept 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 tradema

18、rks. 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

19、 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 ETSI GS NFV-SOL 004 V2.5.1 (2018-09)5 1 Scope The present document specifies

20、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 n

21、on-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:/doc

22、box.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 Vi

23、rtualisation (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 http

24、s:/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

25、/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 editio

26、n 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 publicatio

27、n, 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: “

28、TOSCA Simple Profile in YAML Version 1.0“. ETSI ETSI GS NFV-SOL 004 V2.5.1 (2018-09)6 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 descri

29、ptors based on TOSCA specification“. 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 app

30、ly: 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: ASCII American Standard Code for

31、 Information Interchange CA Certificate Authority CMS Cryptographic Message Syntax CSAR Cloud Service ARchive IANA Internet Assigned Number Association NFVI NFV Infrastructure NFVO NFV OrchestratorTOSCA Topology and Orchestration Specification for Cloud Applications URI Universal Resource Identifier

32、 UTF Unicode Transformation 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 str

33、ucture 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 v

34、1.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. ETSI ETSI GS NFV-SOL 004

35、 V2.5.1 (2018-09)7 In addition, the CSAR file may optionally 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 fo

36、r 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. scr

37、ipts, 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 in

38、dicate 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-

39、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

40、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 te

41、mplate_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 des

42、cribed in clause 4.1. 4.3 VNF package file contents 4.3.1 General A VNF Package shall contain a main TOSCA definitions YAML file representing all or part of the VNFD, and additional files. It shall be structured according to one of the CSAR structure options described in clause 4.1. NOTE: ETSI GS NF

43、V-SOL 001 i.4 specifies the structure and format of the VNFD based on TOSCA specifications. ETSI ETSI GS NFV-SOL 004 V2.5.1 (2018-09)8 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 refe

44、renced 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 fi

45、le. 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 with

46、out 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. Eac

47、h pair shall appear on a different line. The “name“ and the “value“ shall be separated by a colon and, optionally, one or more blanks. 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 na

48、mes and values for VNF package metadata Name Value vnf_provider_id A sequence of UTF-8 characters See note 1. vnf_product_name A sequence of UTF-8 characters0 See note 1. vnf_release_date_time String formatted according to IETF RFC 3339 3. vnf_package_version A stringSee note 2. NOTE 1: The value sh

49、all be identical to those specified in the VNFD. NOTE 2: The value shall be identical to the vnfdVersion attribute specified in the VNFD. An example of valid manifest file metadata entries follows. EXAMPLE: metadata: vnf_product_name: vMRF vnf_provider_id: Acme vnf_package_version: 1.0 vnf_release_date_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