1 .. Modifications Copyright © 2017-2018 AT&T Intellectual Property.
3 .. Licensed under the Creative Commons License, Attribution 4.0 Intl.
4 (the "License"); you may not use this documentation except in compliance
5 with the License. You may obtain a copy of the License at
7 .. https://creativecommons.org/licenses/by/4.0/
9 .. Unless required by applicable law or agreed to in writing, software
10 distributed under the License is distributed on an "AS IS" BASIS,
11 WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
12 See the License for the specific language governing permissions and
13 limitations under the License.
16 VNF On-boarding and package management
17 --------------------------------------
22 The ONAP Design Time Framework provides the ability to design NFV
23 resources including VNFs, Services, and products. The VNF provider must
24 provide VNF packages that include a rich set of recipes, management and
25 functional interfaces, policies, configuration parameters, and
26 infrastructure requirements that can be utilized by the ONAP Design
27 module to onboard and catalog these resources. Initially this
28 information may be provided in documents, but in the near future a
29 method will be developed to automate as much of the transfer of data as
30 possible to satisfy its long term requirements.
32 The current VNF Package Requirement is based on a subset of the
33 Requirements contained in the ETSI Document: ETSI GS NFV-MAN 001 v1.1.1
34 and GS NFV IFA011 V0.3.0 (2015-10) - Network Functions Virtualization
35 (NFV), Management and Orchestration, VNF Packaging Specification.
38 ^^^^^^^^^^^^^^^^^^^^^^
46 The xNF provider **MUST** include a Manifest File that
47 contains a list of all the components in the xNF package.
54 The xNF Package **MUST** include xNF Identification Data to
55 uniquely identify the resource for a given xNF provider. The identification
56 data must include: an identifier for the xNF, the name of the xNF as was
57 given by the xNF provider, xNF description, xNF provider, and version.
64 The xNF Package **MUST** include documentation describing xNF
65 Management APIs, which must include information and tools for ONAP to
66 deploy and configure (initially and ongoing) the xNF application(s)
67 (e.g., NETCONF APIs) which includes a description of configurable
68 parameters for the xNF and whether the parameters can be configured
69 after xNF instantiation.
76 The xNF Package **MUST** include documentation describing xNF
77 Management APIs, which must include information and tools for
78 ONAP to monitor the health of the xNF (conditions that require
79 healing and/or scaling responses).
86 The xNF Package **MUST** include documentation which includes
87 a description of parameters that can be monitored for the xNF
88 and event records (status, fault, flow, session, call, control
89 plane, etc.) generated by the xNF after instantiation.
96 The xNF Package **MUST** include documentation which includes a
97 description of runtime lifecycle events and related actions (e.g.,
98 control responses, tests) which can be performed for the xNF.
105 The xNF Package **MUST** include documentation describing
106 xNF Functional APIs that are utilized to build network and
107 application services. This document describes the externally exposed
108 functional inputs and outputs for the xNF, including interface
109 format and protocols supported.
116 The xNF provider **MUST** provide documentation describing
117 xNF Functional Capabilities that are utilized to operationalize the
118 xNF and compose complex services.
125 The xNF provider **MUST** provide information regarding any
126 dependency (e.g., affinity, anti-affinity) with other xNFs and resources.
132 :introduced: casablanca
133 :validation_mode: static
135 The VNF package MUST provide `VES Event Registration <https://onap.readthedocs.io/en/latest/submodules/vnfsdk/model.git/docs/files/VESEventRegistration.html>`_ for all VES events provided by that xNF.
138 Resource Configuration
139 ^^^^^^^^^^^^^^^^^^^^^^^
147 The xNF **MUST** support and provide artifacts for configuration
148 management using at least one of the following technologies;
149 a) Netconf/YANG, b) Chef, or c) Ansible.
151 Note: The requirements for Netconf/YANG, Chef, and Ansible protocols
152 are provided separately and must be supported only if the corresponding
153 protocol option is provided by the xNF providor.
156 Configuration Management via NETCONF/YANG
157 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
164 The xNF provider **MUST** provide a Resource/Device YANG model
165 as a foundation for creating the YANG model for configuration. This will
166 include xNF attributes/parameters and valid values/attributes configurable
169 Configuration Management via Chef
170 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
178 The xNF provider **MUST** provide cookbooks to be loaded
179 on the appropriate Chef Server.
186 The xNF provider **MUST** provide a JSON file for each
187 supported action for the xNF. The JSON file must contain key value
188 pairs with all relevant values populated with sample data that illustrates
189 its usage. The fields and their description are defined in Tables A1
190 and A2 in the Appendix.
192 Note: Chef support in ONAP is not currently available and planned for 4Q 2017.
195 Configuration Management via Ansible
196 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
204 The xNF provider **MUST** provide playbooks to be loaded
205 on the appropriate Ansible Server.
212 The xNF provider **MUST** provide a JSON file for each
213 supported action for the xNF. The JSON file must contain key value
214 pairs with all relevant values populated with sample data that illustrates
215 its usage. The fields and their description are defined in Table B1
223 The xNF Package **MUST** include configuration scripts
224 for boot sequence and configuration.
231 The xNF provider **MUST** provide configurable parameters
232 (if unable to conform to YANG model) including xNF attributes/parameters
233 and valid values, dynamic attributes and cross parameter dependencies
234 (e.g., customer provisioning data).
236 Resource Control Loop
237 ^^^^^^^^^^^^^^^^^^^^^^^
245 The xNF provider **MUST** provide documentation for the xNF
246 Policy Description to manage the xNF runtime lifecycle. The document
247 must include a description of how the policies (conditions and actions)
248 are implemented in the xNF.
255 The xNF Package **MUST** include documentation describing the
256 fault, performance, capacity events/alarms and other event records
257 that are made available by the xNF.
264 The xNF Package **MUST** include documentation which must include
265 a unique identification string for the specific xNF, a description of
266 the problem that caused the error, and steps or procedures to perform
267 Root Cause Analysis and resolve the issue.
274 The xNF Package **MUST** include documentation which must include
275 all events, severity level (e.g., informational, warning, error) and
276 descriptions including causes/fixes if applicable for the event.
283 The xNF Package **MUST** include documentation which must include
284 all events (fault, measurement for xNF Scaling, Syslogs, State Change
285 and Mobile Flow), that need to be collected at each VM, VNFC (defined in `VNF Guidelines <https://onap.readthedocs.io/en/latest/submodules/vnfrqts/guidelines.git/docs/vnf_guidelines/vnf_guidelines.html>`__ ) and for the overall xNF.
292 The xNF provider **MUST** provide an XML file that contains a
293 list of xNF error codes, descriptions of the error, and possible
294 causes/corrective action.
301 The xNF Package **MUST** include documentation describing all
302 parameters that are available to monitor the xNF after instantiation
303 (includes all counters, OIDs, PM data, KPIs, etc.) that must be
304 collected for reporting purposes.
311 The xNF Package **MUST** include documentation about monitoring
312 parameters/counters exposed for virtual resource management and xNF
313 application management.
320 The xNF Package **MUST** include documentation about KPIs and
321 metrics that need to be collected at each VM for capacity planning
322 and performance management purposes.
329 The xNF Package **MUST** include documentation about the monitoring
330 parameters that must include latencies, success rates, retry rates, load
331 and quality (e.g., DPM) for the key transactions/functions supported by
332 the xNF and those that must be exercised by the xNF in order to perform
340 The xNF Package **MUST** include documentation for each KPI, provide
341 lower and upper limits.
348 The xNF Package **MUST** include documentation to, when relevant,
349 provide a threshold crossing alert point for each KPI and describe the
350 significance of the threshold crossing.
357 The xNF Package **MUST** include documentation for each KPI,
358 identify the suggested actions that need to be performed when a
359 threshold crossing alert event is recorded.
366 The xNF Package **MUST** include documentation that describes
367 any requirements for the monitoring component of tools for Network
368 Cloud automation and management to provide these records to components
376 The xNF Package **MUST** include documentation to when applicable,
377 provide calculators needed to convert raw data into appropriate reporting
385 The xNF Package **MUST** include documentation describing
386 supported xNF scaling capabilities and capacity limits (e.g., number
387 of users, bandwidth, throughput, concurrent calls).
394 The xNF Package **MUST** include documentation describing
395 the characteristics for the xNF reliability and high availability.
402 The xNF provider **MUST** provide an artifact per xNF that contains
403 all of the xNF Event Records supported. The artifact should include
404 reference to the specific release of the xNF Event Stream Common Event
405 Data Model document it is based on. (e.g.,
406 `VES Event Listener <https://onap.readthedocs.io/en/latest/submodules/vnfsdk/model.git/docs/files/VESEventListener.html>`__)
408 Compute, Network, and Storage Requirements
409 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
417 The xNF Package **MUST** include xNF topology that describes
418 basic network and application connectivity internal and external to the
419 xNF including Link type, KPIs, Bandwidth, latency, jitter, QoS (if
420 applicable) for each interface.
427 The VNF Package **MUST** include VM requirements via a Heat
428 template that provides the necessary data for VM specifications
429 for all VNF components - for hypervisor, CPU, memory, storage.
436 The VNF Package **MUST** include VM requirements via a Heat
437 template that provides the necessary data for network connections,
438 interface connections, internal and external to VNF.
445 The VNF Package **MUST** include VM requirements via a Heat
446 template that provides the necessary data for high availability
454 The VNF Package **MUST** include VM requirements via a Heat
455 template that provides the necessary data for scaling/growth VM
458 Note: Must comply with the *Heat requirements in 5.b*.
465 The xNF provider **MUST** provide the binaries and images
466 needed to instantiate the xNF (xNF and VNFC images).
473 The xNF provider **MUST** describe scaling capabilities
474 to manage scaling characteristics of the xNF.
486 The xNF Package **MUST** include documentation describing
487 the tests that were conducted by the xNF provider and the test results.
494 The xNF provider **MUST** provide their testing scripts to
502 The xNF provider **MUST** provide software components that
503 can be packaged with/near the xNF, if needed, to simulate any functions
504 or systems that connect to the xNF system under test. This component is
505 necessary only if the existing testing environment does not have the
506 necessary simulators.
508 Licensing Requirements
509 ^^^^^^^^^^^^^^^^^^^^^^^
517 The xNF **MUST** provide metrics (e.g., number of sessions,
518 number of subscribers, number of seats, etc.) to ONAP for tracking
526 The xNF provider **MUST** agree to the process that can
527 be met by Service Provider reporting infrastructure. The Contract
528 shall define the reporting process and the available reporting tools.
535 The xNF provider **MUST** enumerate all of the open
536 source licenses their xNF(s) incorporate.
543 The xNF provider **MUST NOT** require audits
544 of Service Provider's business.
551 The xNF provider **MUST NOT** require additional
552 infrastructure such as a xNF provider license server for xNF provider
553 functions and metrics.
560 The VNF **MUST** provide clear measurements for licensing
561 purposes to allow automated scale up/down by the management system.
568 The VNF provider **MUST** provide the ability to scale
569 up a VNF provider supplied product during growth and scale down a
570 VNF provider supplied product during decline without "real-time"
571 restrictions based upon VNF provider permissions.
578 The xNF provider **MUST** provide a universal license key
579 per xNF to be used as needed by services (i.e., not tied to a VM
580 instance) as the recommended solution. The xNF provider may provide
581 pools of Unique xNF License Keys, where there is a unique key for
582 each xNF instance as an alternate solution. Licensing issues should
583 be resolved without interrupting in-service xNFs.
590 The xNF provider **MUST** support the metadata about
591 licenses (and their applicable entitlements) as defined in this
592 document for xNF software, and any license keys required to authorize
593 use of the xNF software. This metadata will be used to facilitate
594 onboarding the xNF into the ONAP environment and automating processes
595 for putting the licenses into use and managing the full lifecycle of
596 the licenses. The details of this license model are described in
597 Tables C1 to C8 in the Appendix.
599 Note: License metadata support in ONAP is not currently available
600 and planned for 1Q 2018.