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 ^^^^^^^^^^^^^^^^^^^^^^
45 The xNF Package **MUST** include xNF Identification Data to
46 uniquely identify the resource for a given xNF provider. The identification
47 data must include: an identifier for the xNF, the name of the xNF as was
48 given by the xNF provider, xNF description, xNF provider, and version.
55 The xNF Package **MUST** include documentation describing xNF
56 Management APIs, which must include information and tools for ONAP to
57 deploy and configure (initially and ongoing) the xNF application(s)
58 (e.g., NETCONF APIs) which includes a description of configurable
59 parameters for the xNF and whether the parameters can be configured
60 after xNF instantiation.
67 The xNF Package **MUST** include documentation describing xNF
68 Management APIs, which must include information and tools for
69 ONAP to monitor the health of the xNF (conditions that require
70 healing and/or scaling responses).
77 The xNF Package **MUST** include documentation which includes
78 a description of parameters that can be monitored for the xNF
79 and event records (status, fault, flow, session, call, control
80 plane, etc.) generated by the xNF after instantiation.
87 The xNF Package **MUST** include documentation which includes a
88 description of runtime lifecycle events and related actions (e.g.,
89 control responses, tests) which can be performed for the xNF.
96 The xNF Package **MUST** include documentation describing
97 xNF Functional APIs that are utilized to build network and
98 application services. This document describes the externally exposed
99 functional inputs and outputs for the xNF, including interface
100 format and protocols supported.
107 The xNF provider **MUST** provide documentation describing
108 xNF Functional Capabilities that are utilized to operationalize the
109 xNF and compose complex services.
113 :target: VNF PROVIDER
116 The VNF Provider **MUST** provide documentation regarding any dependency
117 (e.g. affinity, anti-affinity) the VNF has on other VNFs and resources.
123 :introduced: casablanca
124 :validation_mode: static
126 The xNF package MUST provide :doc:`VES Event Registration <../../../../vnfsdk/model.git/docs/files/VESEventRegistration_3_0>`
127 for all VES events provided by that xNF.
133 :introduced: casablanca
135 The VNF documentation **MUST** contain a list of the files within the VNF
136 package that are static during the VNF's runtime.
139 Resource Configuration
140 ^^^^^^^^^^^^^^^^^^^^^^^
148 The xNF **MUST** support and provide artifacts for configuration
149 management using at least one of the following technologies;
150 a) Netconf/YANG, b) Chef, or c) Ansible.
152 Note: The requirements for Netconf/YANG, Chef, and Ansible protocols
153 are provided separately and must be supported only if the corresponding
154 protocol option is provided by the xNF providor.
157 Configuration Management via NETCONF/YANG
158 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
165 The xNF provider **MUST** provide a Resource/Device YANG model
166 as a foundation for creating the YANG model for configuration. This will
167 include xNF attributes/parameters and valid values/attributes configurable
170 Configuration Management via Chef
171 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
179 The xNF provider **MUST** provide cookbooks to be loaded
180 on the appropriate Chef Server.
187 The xNF provider **MUST** provide a JSON file for each
188 supported action for the xNF. The JSON file must contain key value
189 pairs with all relevant values populated with sample data that illustrates
190 its usage. The fields and their description are defined in Tables A1
191 and A2 in the Appendix.
193 Note: Chef support in ONAP is not currently available and planned for 4Q 2017.
196 Configuration Management via Ansible
197 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
205 The xNF provider **MUST** provide playbooks to be loaded
206 on the appropriate Ansible Server.
213 The xNF provider **MUST** provide a JSON file for each
214 supported action for the xNF. The JSON file must contain key value
215 pairs with all relevant values populated with sample data that illustrates
216 its usage. The fields and their description are defined in Table B1
224 The xNF Package **MUST** include configuration scripts
225 for boot sequence and configuration.
232 The xNF provider **MUST** provide configurable parameters
233 (if unable to conform to YANG model) including xNF attributes/parameters
234 and valid values, dynamic attributes and cross parameter dependencies
235 (e.g., customer provisioning data).
237 Resource Control Loop
238 ^^^^^^^^^^^^^^^^^^^^^^^
246 The xNF provider **MUST** provide documentation for the xNF
247 Policy Description to manage the xNF runtime lifecycle. The document
248 must include a description of how the policies (conditions and actions)
249 are implemented in the xNF.
256 The xNF Package **MUST** include documentation describing the
257 fault, performance, capacity events/alarms and other event records
258 that are made available by the xNF.
265 The xNF Package **MUST** include documentation which must include
266 a unique identification string for the specific xNF, a description of
267 the problem that caused the error, and steps or procedures to perform
268 Root Cause Analysis and resolve the issue.
275 The xNF Package **MUST** include documentation which must include
276 all events, severity level (e.g., informational, warning, error) and
277 descriptions including causes/fixes if applicable for the event.
284 The xNF Package **MUST** include documentation which must include
285 all events (fault, measurement for xNF Scaling, Syslogs, State Change
286 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.
294 The xNF Package **MUST** include documentation describing all
295 parameters that are available to monitor the xNF after instantiation
296 (includes all counters, OIDs, PM data, KPIs, etc.) that must be
297 collected for reporting purposes.
304 The xNF Package **MUST** include documentation about monitoring
305 parameters/counters exposed for virtual resource management and xNF
306 application management.
313 The xNF Package **MUST** include documentation about KPIs and
314 metrics that need to be collected at each VM for capacity planning
315 and performance management purposes.
322 The xNF Package **MUST** include documentation about the monitoring
323 parameters that must include latencies, success rates, retry rates, load
324 and quality (e.g., DPM) for the key transactions/functions supported by
325 the xNF and those that must be exercised by the xNF in order to perform
333 The xNF Package **MUST** include documentation for each KPI, provide
334 lower and upper limits.
341 The xNF Package **MUST** include documentation to, when relevant,
342 provide a threshold crossing alert point for each KPI and describe the
343 significance of the threshold crossing.
350 The xNF Package **MUST** include documentation for each KPI,
351 identify the suggested actions that need to be performed when a
352 threshold crossing alert event is recorded.
359 The xNF Package **MUST** include documentation that describes
360 any requirements for the monitoring component of tools for Network
361 Cloud automation and management to provide these records to components
369 The xNF Package **MUST** include documentation to when applicable,
370 provide calculators needed to convert raw data into appropriate reporting
378 The xNF Package **MUST** include documentation describing
379 supported xNF scaling capabilities and capacity limits (e.g., number
380 of users, bandwidth, throughput, concurrent calls).
387 The xNF Package **MUST** include documentation describing
388 the characteristics for the xNF reliability and high availability.
395 The xNF provider **MUST** provide an artifact per xNF that contains
396 all of the xNF Event Records supported. The artifact should include
397 reference to the specific release of the xNF Event Stream Common Event
398 Data Model document it is based on. (e.g.,
399 `VES Event Listener <https://onap.readthedocs.io/en/latest/submodules/vnfsdk/model.git/docs/files/VESEventListener.html>`__)
401 Compute, Network, and Storage Requirements
402 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
410 The xNF Package **MUST** include xNF topology that describes
411 basic network and application connectivity internal and external to the
412 xNF including Link type, KPIs, Bandwidth, latency, jitter, QoS (if
413 applicable) for each interface.
420 The VNF Package **MUST** include VM requirements via a Heat
421 template that provides the necessary data for VM specifications
422 for all VNF components - for hypervisor, CPU, memory, storage.
429 The VNF Package **MUST** include VM requirements via a Heat
430 template that provides the necessary data for network connections,
431 interface connections, internal and external to VNF.
438 The VNF Package **MUST** include VM requirements via a Heat
439 template that provides the necessary data for high availability
447 The VNF Package **MUST** include VM requirements via a Heat
448 template that provides the necessary data for scaling/growth VM
451 Note: Must comply with the *Heat requirements in 5.b*.
458 The VNF provider **MUST** provide the binaries and images
459 needed to instantiate the VNF (VNF and VNFC images).
463 :target: VNF or PNF PROVIDER
467 The VNF or PNF Provider **MUST** provide human readable documentation
468 (not in the on-boarding package) to describe scaling capabilities to manage
469 scaling characteristics of the VNF or PNF.
481 The VNF Package **MUST** include documentation describing
482 the tests that were conducted by the VNF provider and the test results.
489 The VNF provider **MUST** provide their testing scripts to
497 The VNF provider **MUST** provide software components that
498 can be packaged with/near the VNF, if needed, to simulate any functions
499 or systems that connect to the VNF system under test. This component is
500 necessary only if the existing testing environment does not have the
501 necessary simulators.
503 Licensing Requirements
504 ^^^^^^^^^^^^^^^^^^^^^^^
512 The xNF **MUST** provide metrics (e.g., number of sessions,
513 number of subscribers, number of seats, etc.) to ONAP for tracking
521 The xNF provider **MUST** agree to the process that can
522 be met by Service Provider reporting infrastructure. The Contract
523 shall define the reporting process and the available reporting tools.
530 The xNF provider **MUST** enumerate all of the open
531 source licenses their xNF(s) incorporate.
538 The xNF provider **MUST NOT** require audits
539 of Service Provider's business.
546 The xNF provider **MUST NOT** require additional
547 infrastructure such as a xNF provider license server for xNF provider
548 functions and metrics.
555 The VNF **MUST** provide clear measurements for licensing
556 purposes to allow automated scale up/down by the management system.
563 The VNF provider **MUST** provide the ability to scale
564 up a VNF provider supplied product during growth and scale down a
565 VNF provider supplied product during decline without "real-time"
566 restrictions based upon VNF provider permissions.
573 The xNF provider **MUST** provide a universal license key
574 per xNF to be used as needed by services (i.e., not tied to a VM
575 instance) as the recommended solution. The xNF provider may provide
576 pools of Unique xNF License Keys, where there is a unique key for
577 each xNF instance as an alternate solution. Licensing issues should
578 be resolved without interrupting in-service xNFs.
585 The xNF provider **MUST** support the metadata about
586 licenses (and their applicable entitlements) as defined in this
587 document for xNF software, and any license keys required to authorize
588 use of the xNF software. This metadata will be used to facilitate
589 onboarding the xNF into the ONAP environment and automating processes
590 for putting the licenses into use and managing the full lifecycle of
591 the licenses. The details of this license model are described in
592 Tables C1 to C8 in the Appendix.
594 Note: License metadata support in ONAP is not currently available
595 and planned for 1Q 2018.
Code Review / vnfrqts / requirements.git / blob