1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
2 .. http://creativecommons.org/licenses/by/4.0
3 .. Copyright 2017 AT&T Intellectual Property. All rights reserved.
6 VNF On-boarding and package management
7 --------------------------------------
12 The ONAP Design Time Framework provides the ability to design NFV
13 resources including VNFs, Services, and products. The VNF provider must
14 provide VNF packages that include a rich set of recipes, management and
15 functional interfaces, policies, configuration parameters, and
16 infrastructure requirements that can be utilized by the ONAP Design
17 module to onboard and catalog these resources. Initially this
18 information may be provided in documents, but in the near future a
19 method will be developed to automate as much of the transfer of data as
20 possible to satisfy its long term requirements.
22 The current VNF Package Requirement is based on a subset of the
23 Requirements contained in the ETSI Document: ETSI GS NFV-MAN 001 v1.1.1
24 and GS NFV IFA011 V0.3.0 (2015-10) - Network Functions Virtualization
25 (NFV), Management and Orchestration, VNF Packaging Specification.
28 ^^^^^^^^^^^^^^^^^^^^^^
36 The xNF provider **MUST** include a Manifest File that
37 contains a list of all the components in the xNF package.
44 The xNF Package **MUST** include xNF Identification Data to
45 uniquely identify the resource for a given xNF provider. The identification
46 data must include: an identifier for the xNF, the name of the xNF as was
47 given by the xNF provider, xNF description, xNF provider, and version.
54 The xNF Package **MUST** include documentation describing xNF
55 Management APIs, which must include information and tools for ONAP to
56 deploy and configure (initially and ongoing) the xNF application(s)
57 (e.g., NETCONF APIs) which includes a description of configurable
58 parameters for the xNF and whether the parameters can be configured
59 after xNF instantiation.
66 The xNF Package **MUST** include documentation describing xNF
67 Management APIs, which must include information and tools for
68 ONAP to monitor the health of the xNF (conditions that require
69 healing and/or scaling responses).
76 The xNF Package **MUST** include documentation which includes
77 a description of parameters that can be monitored for the xNF
78 and event records (status, fault, flow, session, call, control
79 plane, etc.) generated by the xNF after instantiation.
86 The xNF Package **MUST** include documentation which includes a
87 description of runtime lifecycle events and related actions (e.g.,
88 control responses, tests) which can be performed for the xNF.
95 The xNF Package **MUST** include documentation describing
96 xNF Functional APIs that are utilized to build network and
97 application services. This document describes the externally exposed
98 functional inputs and outputs for the xNF, including interface
99 format and protocols supported.
106 The xNF provider **MUST** provide documentation describing
107 xNF Functional Capabilities that are utilized to operationalize the
108 xNF and compose complex services.
115 The xNF provider **MUST** provide information regarding any
116 dependency (e.g., affinity, anti-affinity) with other xNFs and resources.
118 Resource Configuration
119 ^^^^^^^^^^^^^^^^^^^^^^^
127 The xNF **MUST** support and provide artifacts for configuration
128 management using at least one of the following technologies;
129 a) Netconf/YANG, b) Chef, or c) Ansible.
131 Note: The requirements for Netconf/YANG, Chef, and Ansible protocols
132 are provided separately and must be supported only if the corresponding
133 protocol option is provided by the xNF providor.
136 Configuration Management via NETCONF/YANG
137 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
144 The xNF provider **MUST** provide a Resource/Device YANG model
145 as a foundation for creating the YANG model for configuration. This will
146 include xNF attributes/parameters and valid values/attributes configurable
149 Configuration Management via Chef
150 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
158 The xNF provider **MUST** provide cookbooks to be loaded
159 on the appropriate Chef Server.
166 The xNF provider **MUST** provide a JSON file for each
167 supported action for the xNF. The JSON file must contain key value
168 pairs with all relevant values populated with sample data that illustrates
169 its usage. The fields and their description are defined in Tables A1
170 and A2 in the Appendix.
172 Note: Chef support in ONAP is not currently available and planned for 4Q 2017.
175 Configuration Management via Ansible
176 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
184 The xNF provider **MUST** provide playbooks to be loaded
185 on the appropriate Ansible Server.
192 The xNF provider **MUST** provide a JSON file for each
193 supported action for the xNF. The JSON file must contain key value
194 pairs with all relevant values populated with sample data that illustrates
195 its usage. The fields and their description are defined in Table B1
203 The xNF Package **MUST** include configuration scripts
204 for boot sequence and configuration.
211 The xNF provider **MUST** provide configurable parameters
212 (if unable to conform to YANG model) including xNF attributes/parameters
213 and valid values, dynamic attributes and cross parameter dependencies
214 (e.g., customer provisioning data).
216 Resource Control Loop
217 ^^^^^^^^^^^^^^^^^^^^^^^
225 The xNF provider **MUST** provide documentation for the xNF
226 Policy Description to manage the xNF runtime lifecycle. The document
227 must include a description of how the policies (conditions and actions)
228 are implemented in the xNF.
235 The xNF Package **MUST** include documentation describing the
236 fault, performance, capacity events/alarms and other event records
237 that are made available by the xNF.
244 The xNF Package **MUST** include documentation which must include
245 a unique identification string for the specific xNF, a description of
246 the problem that caused the error, and steps or procedures to perform
247 Root Cause Analysis and resolve the issue.
254 The xNF Package **MUST** include documentation which must include
255 all events, severity level (e.g., informational, warning, error) and
256 descriptions including causes/fixes if applicable for the event.
263 The xNF Package **MUST** include documentation which must include
264 all events (fault, measurement for xNF Scaling, Syslogs, State Change
265 and Mobile Flow), that need to be collected at each VM, VNFC (defined in `VNF Guidelines <http://onap.readthedocs.io/en/latest/submodules/vnfrqts/guidelines.git/docs/vnf_guidelines/vnf_guidelines.html#a-glossary>`__ ) and for the overall xNF.
272 The xNF provider **MUST** provide an XML file that contains a
273 list of xNF error codes, descriptions of the error, and possible
274 causes/corrective action.
281 The xNF Package **MUST** include documentation describing all
282 parameters that are available to monitor the xNF after instantiation
283 (includes all counters, OIDs, PM data, KPIs, etc.) that must be
284 collected for reporting purposes.
291 The xNF Package **MUST** include documentation about monitoring
292 parameters/counters exposed for virtual resource management and xNF
293 application management.
300 The xNF Package **MUST** include documentation about KPIs and
301 metrics that need to be collected at each VM for capacity planning
302 and performance management purposes.
309 The xNF Package **MUST** include documentation about the monitoring
310 parameters that must include latencies, success rates, retry rates, load
311 and quality (e.g., DPM) for the key transactions/functions supported by
312 the xNF and those that must be exercised by the xNF in order to perform
320 The xNF Package **MUST** include documentation for each KPI, provide
321 lower and upper limits.
328 The xNF Package **MUST** include documentation to, when relevant,
329 provide a threshold crossing alert point for each KPI and describe the
330 significance of the threshold crossing.
337 The xNF Package **MUST** include documentation for each KPI,
338 identify the suggested actions that need to be performed when a
339 threshold crossing alert event is recorded.
346 The xNF Package **MUST** include documentation that describes
347 any requirements for the monitoring component of tools for Network
348 Cloud automation and management to provide these records to components
356 The xNF Package **MUST** include documentation to when applicable,
357 provide calculators needed to convert raw data into appropriate reporting
365 The xNF Package **MUST** include documentation describing
366 supported xNF scaling capabilities and capacity limits (e.g., number
367 of users, bandwidth, throughput, concurrent calls).
374 The xNF Package **MUST** include documentation describing
375 the characteristics for the xNF reliability and high availability.
382 The xNF provider **MUST** provide an artifact per xNF that contains
383 all of the xNF Event Records supported. The artifact should include
384 reference to the specific release of the xNF Event Stream Common Event
385 Data Model document it is based on. (e.g.,
386 `VES Event Listener <https://github.com/att/evel-test-collector/tree/master/docs/att_interface_definition>`__)
388 Compute, Network, and Storage Requirements
389 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
397 The xNF Package **MUST** include xNF topology that describes
398 basic network and application connectivity internal and external to the
399 xNF including Link type, KPIs, Bandwidth, latency, jitter, QoS (if
400 applicable) for each interface.
407 The VNF Package **MUST** include VM requirements via a Heat
408 template that provides the necessary data for VM specifications
409 for all VNF components - for hypervisor, CPU, memory, storage.
416 The VNF Package **MUST** include VM requirements via a Heat
417 template that provides the necessary data for network connections,
418 interface connections, internal and external to VNF.
425 The VNF Package **MUST** include VM requirements via a Heat
426 template that provides the necessary data for high availability
434 The VNF Package **MUST** include VM requirements via a Heat
435 template that provides the necessary data for scaling/growth VM
438 Note: Must comply with the *Heat requirements in 5.b*.
445 The xNF provider **MUST** provide the binaries and images
446 needed to instantiate the xNF (xNF and VNFC images).
453 The xNF provider **MUST** describe scaling capabilities
454 to manage scaling characteristics of the xNF.
465 The xNF Package **MUST** include documentation describing
466 the tests that were conducted by the xNF providor and the test results.
473 The xNF provider **MUST** provide their testing scripts to
481 The xNF provider **MUST** provide software components that
482 can be packaged with/near the xNF, if needed, to simulate any functions
483 or systems that connect to the xNF system under test. This component is
484 necessary only if the existing testing environment does not have the
485 necessary simulators.
487 Licensing Requirements
488 ^^^^^^^^^^^^^^^^^^^^^^^
496 The xNF **MUST** provide metrics (e.g., number of sessions,
497 number of subscribers, number of seats, etc.) to ONAP for tracking
505 The xNF provider **MUST** agree to the process that can
506 be met by Service Provider reporting infrastructure. The Contract
507 shall define the reporting process and the available reporting tools.
514 The xNF provider **MUST** enumerate all of the open
515 source licenses their xNF(s) incorporate.
522 The xNF provider **MUST NOT** require audits
523 of Service Provider's business.
530 The xNF provider **MUST NOT** require additional
531 infrastructure such as a xNF provider license server for xNF provider
532 functions and metrics.
539 The VNF **MUST** provide clear measurements for licensing
540 purposes to allow automated scale up/down by the management system.
547 The VNF provider **MUST** provide the ability to scale
548 up a VNF provider supplied product during growth and scale down a
549 VNF provider supplied product during decline without "real-time"
550 restrictions based upon VNF provider permissions.
557 The xNF provider **MUST** provide a universal license key
558 per xNF to be used as needed by services (i.e., not tied to a VM
559 instance) as the recommended solution. The xNF provider may provide
560 pools of Unique xNF License Keys, where there is a unique key for
561 each xNF instance as an alternate solution. Licensing issues should
562 be resolved without interrupting in-service xNFs.
569 The xNF provider **MUST** support the metadata about
570 licenses (and their applicable entitlements) as defined in this
571 document for xNF software, and any license keys required to authorize
572 use of the xNF software. This metadata will be used to facilitate
573 onboarding the xNF into the ONAP environment and automating processes
574 for putting the licenses into use and managing the full lifecycle of
575 the licenses. The details of this license model are described in
576 Tables C1 to C8 in the Appendix.
578 Note: License metadata support in ONAP is not currently available
579 and planned for 1Q 2018.
Code Review / vnfrqts / requirements.git / blob