ETSI GS NFV-SOL 013 V2.6.1 (2019-03)
Network Functions Virtualisation (NFV) Release 2; Protocols and Data Models; Specification of common aspects for RESTful NFV MANO APIs
Network Functions Virtualisation (NFV) Release 2; Protocols and Data Models; Specification of common aspects for RESTful NFV MANO APIs
DGS/NFV-SOL013ed261
General Information
Standards Content (Sample)
ETSI GS NFV-SOL 013 V2.6.1 (2019-03)
GROUP SPECIFICATION
Network Functions Virtualisation (NFV) Release 2;
Protocols and Data Models;
Specification of common aspects for
RESTful NFV MANO APIs
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 013 V2.6.1 (2019-03)
Reference
DGS/NFV-SOL013ed261
Keywords
API, NFV, protocol
ETSI
650 Route des Lucioles
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 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 prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
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 2019.
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 013 V2.6.1 (2019-03)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols and abbreviations . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
4 HTTP usage . 8
4.1 URI structure and supported content formats . 8
4.2 Usage of HTTP header fields . 9
4.2.1 Introduction. 9
4.2.2 Request header fields . 9
4.2.3 Response header fields . 10
5 Result set control . 11
5.1 Introduction . 11
5.2 Attribute-based filtering . 11
5.2.1 Overview and example (informative) . 11
5.2.2 Specification . 12
5.3 Attribute selectors. 14
5.3.1 Overview and example (informative) . 14
5.3.2 Specification . 14
5.3.2.1 GET request . 14
5.3.2.2 GET response . 15
5.4 Handling of large query results . 15
5.4.1 Overview . 15
5.4.2 Specification . 16
5.4.2.1 Alternatives . 16
5.4.2.2 Error response . 16
5.4.2.3 Paged response . 16
6 Error reporting . 17
6.1 Introduction . 17
6.2 General mechanism . 17
6.3 Type: ProblemDetails . 17
6.4 Common error situations . 18
7 Common data types . 20
7.1 Structured data types . 20
7.1.1 Introduction. 20
7.1.2 Type: Object . 20
7.1.3 Type: Link . 20
7.1.4 Type: NotificationLink . 20
7.1.5 Type: KeyValuePairs . 20
7.1.6 Type: ApiVersionInformation . 21
7.2 Simple data types and enumerations . 21
7.2.1 Introduction. 21
7.2.2 Simple data types . 21
7.2.3 Enumerations . 22
8 Authorization of API requests and notifications . 22
8.1 Introduction . 22
ETSI
---------------------- Page: 3 ----------------------
4 ETSI GS NFV-SOL 013 V2.6.1 (2019-03)
8.2 Flows (informative) . 23
8.2.1 General . 23
8.2.2 Authorization of API requests using OAuth 2.0 access tokens . 23
8.2.3 Authorization of API requests using TLS certificates . 25
8.2.4 Authorization of notifications using the HTTP Basic authentication scheme . 26
8.2.5 Authorization of notifications using OAuth 2.0 access tokens . 27
8.2.6 Authorization of notifications using TLS certificates . 29
8.3 Specification . 31
8.3.1 Introduction. 31
8.3.2 General mechanism. 31
8.3.3 Authorizing API requests . 31
8.3.4 Authorizing the sending of notifications . 32
8.3.5 Client roles . 33
8.3.6 Negotiation of the authorization method . 34
8.3.6.1 Authorization of API requests . 34
8.3.6.2 Authorization of notification requests . 36
9 Version management . 37
9.1 Version identifiers and parameters . 37
9.1.1 Version identifiers . 37
9.1.2 Version parameters . 37
9.2 Rules for incrementing version identifier fields . 37
9.2.1 General . 37
9.2.2 Examples of backward and non-backward compatible changes . 38
9.3 Version information retrieval . 39
9.3.1 General . 39
9.3.2 Resource structure and methods . 39
9.3.3 Resource: API versions . 40
9.3.3.1 Description . 40
9.3.3.2 Resource definition . 40
9.3.3.3 Resource methods . 40
9.3.3.3.1 POST . 40
9.3.3.3.2 GET . 40
9.3.3.3.3 PUT . 41
9.3.3.3.4 PATCH . 41
9.3.3.3.5 DELETE . 41
9.4 Version signaling . 41
Annex A (informative): Change History . 42
History . 43
ETSI
---------------------- Page: 4 ----------------------
5 ETSI GS NFV-SOL 013 V2.6.1 (2019-03)
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: 5 ----------------------
6 ETSI GS NFV-SOL 013 V2.6.1 (2019-03)
1 Scope
The present document specifies common aspects of RESTful protocols and data models for ETSI NFV management
and orchestration (MANO) interfaces.
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] IETF RFC 2818: "HTTP Over TLS".
NOTE: Available at https://tools.ietf.org/html/rfc2818.
[2] IETF RFC 3339: "Date and Time on the Internet: Timestamps".
NOTE: Available at https://tools.ietf.org/html/rfc3339.
[3] IETF RFC 3986: "Uniform Resource Identifier (URI): Generic Syntax".
NOTE: Available at https://tools.ietf.org/html/rfc3986.
[4] IETF RFC 4918: "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)".
NOTE: Available at https://tools.ietf.org/html/rfc4918.
[5] IETF RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2".
NOTE: Available at https://tools.ietf.org/html/rfc5246.
[6] IETF RFC 6585: "Additional HTTP Status Codes".
NOTE: Available at https://tools.ietf.org/html/rfc6585.
[7] IETF RFC 6749: "The OAuth 2.0 Authorization Framework".
NOTE: Available from https://tools.ietf.org/html/rfc6749.
[8] IETF RFC 6750: "The OAuth 2.0 Authorization Framework: Bearer Token Usage".
NOTE: Available from https://tools.ietf.org/html/rfc6750.
[9] IETF RFC 8259: "The JavaScript Object Notation (JSON) Data Interchange Format".
NOTE: Available at https://tools.ietf.org/html/rfc8259.
[10] IETF RFC 7231: "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content".
NOTE: Available at https://tools.ietf.org/html/rfc7231.
ETSI
---------------------- Page: 6 ----------------------
7 ETSI GS NFV-SOL 013 V2.6.1 (2019-03)
[11] IETF RFC 7232: "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests".
NOTE: Available at https://tools.ietf.org/html/rfc7232.
[12] IETF RFC 7233: "Hypertext Transfer Protocol (HTTP/1.1): Range Requests".
NOTE: Available at https://tools.ietf.org/html/rfc7233.
[13] IETF RFC 7235: "Hypertext Transfer Protocol (HTTP/1.1): Authentication".
NOTE: Available at https://tools.ietf.org/html/rfc7235.
[14] IETF RFC 7617: "The 'Basic' HTTP Authentication Scheme".
NOTE: Available from https://tools.ietf.org/html/rfc7617.
[15] IETF RFC 7807: "Problem Details for HTTP APIs".
NOTE: Available at https://tools.ietf.org/html/rfc7807.
[16] IETF RFC 6901: "JavaScript Object Notation (JSON) Pointer".
NOTE: Available at https://tools.ietf.org/html/rfc6901.
[17] IETF RFC 8288: "Web Linking".
NOTE: Available at https://tools.ietf.org/html/rfc8288.
[18] Semantic Versioning 2.0.0.
NOTE: Available at https://semver.org/.
[19] IETF RFC 4229: "HTTP Header Field Registrations".
NOTE: Available at https://tools.ietf.org/html/rfc4229.
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] ETSI GS NFV 003: "Network Functions Virtualisation (NFV); Terminology for Main Concepts in
NFV".
[i.2] ETSI TS 133 310: "Universal Mobile Telecommunications System (UMTS); LTE; Network
Domain Security (NDS); Authentication Framework (AF) (3GPP TS 33.310)".
[i.3] Hypertext Transfer Protocol (HTTP) Status Code Registry at IANA.
NOTE: Available at http://www.iana.org/assignments/http-status-codes.
[i.4] ETSI NFV OpenAPI repository.
NOTE: Available at https://forge.etsi.org/rep/nfv/.
ETSI
---------------------- Page: 7 ----------------------
8 ETSI GS NFV-SOL 013 V2.6.1 (2019-03)
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI GS NFV 003 [i.1] apply.
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
API Application Programming Interface
EM Element Manager
ETSI European Telecommunications Standards Institute
GMT Greenwich Mean Time
GS Group Specification
HATEOAS Hypermedia As The Engine Of Application State
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
HTTPS HTTP Secure
IETF Internet Engineering Task Force
JSON JavaScript Object Notation
MAC Medium Access Control
MANO Management and Orchestration
MIME Multipurpose Internet Mail Extensions
NFV Network Functions Virtualisation
NFVO NFV Orchestrator
REST Representational State Transfer
RFC Request For Comments
TLS Transport Layer Security
URI Uniform Resource Identifier
VIM Virtualised Infrastructure Manager
VNF Virtualised Network Function
VNFM VNF Manager
4 HTTP usage
4.1 URI structure and supported content formats
This clause specifies the URI prefix and the supported formats applicable to the APIs defined in the present document.
All resource URIs of the APIs shall have the following prefix, except the "API versions" resource which shall follow
the rules specified in clause 9.3:
{apiRoot}/{apiName}/{apiMajorVersion}/
where:
{apiRoot} indicates the scheme ("http" or "https"), the host name and optional port, and an
optional sequence of path segments that together represent a prefix path.
ETSI
---------------------- Page: 8 ----------------------
9 ETSI GS NFV-SOL 013 V2.6.1 (2019-03)
EXAMPLE: http://orchestrator.example.com/nfv_apis/abc
{apiName} indicates the interface name in an abbreviated form. The {apiName} of each interface
is defined in the clause specifying the corresponding interface.
{apiMajorVersion} indicates the current major version (see clause 9.1) of the API and is defined in the
clause specifying the corresponding interface.
For HTTP requests and responses that have a body, the content format JSON (see IETF RFC 8259 [9]) shall be
supported. The JSON format shall be signalled by the content type "application/json".
All APIs shall support and use HTTP over TLS (also known as HTTPS) (see IETF RFC 2818 [1]). TLS version 1.2 as
defined by IETF RFC 5246 [5] shall be supported.
NOTE 1: The HTTP protocol elements mentioned in the present document originate from the HTTP specification;
HTTPS runs the HTTP protocol in a TLS layer. The present document therefore uses the statement above
to mention "HTTP request", "HTTP header", etc., without explicitly calling out whether or not these are
run over TLS.
NOTE 2: There are a number of best practices and guidelines how to configure and implement TLS 1.2 in a secure
manner, as security threats evolve. A detailed specification of those is beyond the scope of the present
document; the reader is referred to external documentation such as annex E of ETSI TS 133 310 [i.2].
All resource URIs of the API shall comply with the URI syntax as defined in IETF RFC 3986 [3]. An implementation
that dynamically generates resource URI parts (individual path segments, sequences of path segments that are separated
by "/", query parameter values) shall ensure that these parts only use the character set that is allowed by IETF
RFC 3986 [3] for these parts.
NOTE 3: This means that characters not part of this allowed set are escaped using percent-encoding as defined by
IETF RFC 3986 [3].
Unless otherwise specified explicitly, all request URI parameters that are part of the path of the resource URI shall be
individual path segments, i.e. shall not contain the "/" character.
NOTE 4: A request URI parameter is denoted by a string in curly brackets, e.g. {subscriptionId}.
4.2 Usage of HTTP header fields
4.2.1 Introduction
HTTP headers are components of the header section of the HTTP request and response messages. They contain the
information about the server/client and metadata of the transaction. The use of HTTP header fields shall comply with
the provisions defined for those header fields in the specifications referenced from tables 4.2.2-1 and 4.2.3-1. The
following clauses describe the HTTP header fields that are explicitly mentioned in the present document.
4.2.2 Request header fields
This clause describes the usage of HTTP header fields of the request messages applicable to the APIs defined in the
present document. The HTTP header fields used in the request messages are specified in table 4.2.2-1.
ETSI
---------------------- Page: 9 ----------------------
10 ETSI GS NFV-SOL 013 V2.6.1 (2019-03)
Table 4.2.2-1: Header fields supported in the request message
Header field name Reference Example Descriptions
Accept IETF RFC 7231 [10] application/json Content-Types that are acceptable
for the response.
This header field shall be present if
the response is expected to have a
non-empty message body.
Content-Type IETF RFC 7231 [10] application/json The MIME type of the body of the
request.
This header field shall be present if
the request has a non-empty
message body.
Authorization IETF RFC 7235 [13] Bearer mF_9.B5f-4.1JqM The authorization token for the
request. Details are specified in
clause 8.3.
Range IETF RFC 7233 [12] 1 000-2 000 Requested range of bytes from a
file.
Version IETF RFC 4229 [19] 1.2.0 Version of the API requested to use
or when responding to this request.
1.2.0-
impl:example.com:myProduct:4
4.2.3 Response header fields
This clause describes the usage of HTTP header fields of the response messages applicable to the APIs defined in the
present document. The HTTP header fields used in the response messages are specified in table 4.2.3-1.
Table 4.2.3-1: Header fields supported in the response message
Header field name Reference
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.