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 For HEAT package, the VNF Package **MUST** include VNF Identification Data to
47 uniquely identify the resource for a given VNF provider. The identification
48 data must include: an identifier for the VNF, the name of the VNF as was
49 given by the VNF provider, VNF description, VNF provider, and version.
56 The xNF Package **MUST** include documentation describing xNF
57 Management APIs, which must include information and tools for ONAP to
58 deploy and configure (initially and ongoing) the xNF application(s)
59 (e.g., NETCONF APIs) which includes a description of configurable
60 parameters for the xNF and whether the parameters can be configured
61 after xNF instantiation.
68 The xNF Package **MUST** include documentation describing xNF
69 Management APIs, which must include information and tools for
70 ONAP to monitor the health of the xNF (conditions that require
71 healing and/or scaling responses).
78 The xNF Package **MUST** include documentation which includes
79 a description of parameters that can be monitored for the xNF
80 and event records (status, fault, flow, session, call, control
81 plane, etc.) generated by the xNF after instantiation.
88 The xNF Package **MUST** include documentation which includes a
89 description of runtime lifecycle events and related actions (e.g.,
90 control responses, tests) which can be performed for the xNF.
97 The xNF Package **MUST** include documentation describing
98 xNF Functional APIs that are utilized to build network and
99 application services. This document describes the externally exposed
100 functional inputs and outputs for the xNF, including interface
101 format and protocols supported.
108 The xNF provider **MUST** provide documentation describing
109 xNF Functional Capabilities that are utilized to operationalize the
110 xNF and compose complex services.
114 :target: VNF PROVIDER
117 The VNF Provider **MUST** provide documentation regarding any dependency
118 (e.g. affinity, anti-affinity) the VNF has on other VNFs and resources.
124 :introduced: casablanca
125 :validation_mode: static
127 The xNF package MUST provide :doc:`VES Event Registration <../../../../vnfsdk/model.git/docs/files/VESEventRegistration_3_0>`
128 for all VES events provided by that xNF.
134 :introduced: casablanca
136 The VNF documentation **MUST** contain a list of the files within the VNF
137 package that are static during the VNF's runtime.
141 :target: VNF PROVIDER
144 :impacts: DCAE,Documentation,Integration,SDC
145 :validation_mode: static
147 The VNF or PNF PROVIDER **MUST** provide FM Meta Data to support the
148 analysis of fault events delivered to DCAE. The Meta Data must be
149 included in the VES Registration YAML file with each fault event
150 supported by that NF at onboarding time and the Meta Data must follow
151 the VES Event Listener and VES Event Registration Specifications.
154 Resource Configuration
155 ^^^^^^^^^^^^^^^^^^^^^^^
163 The xNF **MUST** support and provide artifacts for configuration
164 management using at least one of the following technologies;
165 a) Netconf/YANG, b) Chef, or c) Ansible.
167 Note: The requirements for Netconf/YANG, Chef, and Ansible protocols
168 are provided separately and must be supported only if the corresponding
169 protocol option is provided by the xNF providor.
172 Configuration Management via NETCONF/YANG
173 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
181 The VNF or PNF provider **MUST** provide a Resource/Device YANG model
182 as a foundation for creating the YANG model for configuration.
184 Configuration Management via Chef
185 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
193 The xNF provider **MUST** provide cookbooks to be loaded
194 on the appropriate Chef Server.
201 The xNF provider **MUST** provide a JSON file for each
202 supported action for the xNF. The JSON file must contain key value
203 pairs with all relevant values populated with sample data that illustrates
204 its usage. The fields and their description are defined in Tables A1
205 and A2 in the Appendix.
207 Note: Chef support in ONAP is not currently available and planned for 4Q 2017.
210 Configuration Management via Ansible
211 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
219 The xNF provider **MUST** provide playbooks to be loaded
220 on the appropriate Ansible Server.
227 The xNF provider **MUST** provide a JSON file for each
228 supported action for the xNF. The JSON file must contain key value
229 pairs with all relevant values populated with sample data that illustrates
230 its usage. The fields and their description are defined in Table B1
238 The xNF Package **MUST** include configuration scripts
239 for boot sequence and configuration.
246 The xNF provider **MUST** provide configurable parameters
247 (if unable to conform to YANG model) including xNF attributes/parameters
248 and valid values, dynamic attributes and cross parameter dependencies
249 (e.g., customer provisioning data).
251 Resource Control Loop
252 ^^^^^^^^^^^^^^^^^^^^^^^
260 The xNF provider **MUST** provide documentation for the xNF
261 Policy Description to manage the xNF runtime lifecycle. The document
262 must include a description of how the policies (conditions and actions)
263 are implemented in the xNF.
270 The xNF Package **MUST** include documentation describing the
271 fault, performance, capacity events/alarms and other event records
272 that are made available by the xNF.
279 The xNF Package **MUST** include documentation which must include
280 a unique identification string for the specific xNF, a description of
281 the problem that caused the error, and steps or procedures to perform
282 Root Cause Analysis and resolve the issue.
289 The xNF Package **MUST** include documentation which must include
290 all events, severity level (e.g., informational, warning, error) and
291 descriptions including causes/fixes if applicable for the event.
298 The xNF Package **MUST** include documentation which must include
299 all events (fault, measurement for xNF Scaling, Syslogs, State Change
300 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.
308 The xNF Package **MUST** include documentation describing all
309 parameters that are available to monitor the xNF after instantiation
310 (includes all counters, OIDs, PM data, KPIs, etc.) that must be
311 collected for reporting purposes.
318 The xNF Package **MUST** include documentation about monitoring
319 parameters/counters exposed for virtual resource management and xNF
320 application management.
327 The xNF Package **MUST** include documentation about KPIs and
328 metrics that need to be collected at each VM for capacity planning
329 and performance management purposes.
336 The xNF Package **MUST** include documentation about the monitoring
337 parameters that must include latencies, success rates, retry rates, load
338 and quality (e.g., DPM) for the key transactions/functions supported by
339 the xNF and those that must be exercised by the xNF in order to perform
347 The xNF Package **MUST** include documentation for each KPI, provide
348 lower and upper limits.
355 The xNF Package **MUST** include documentation to, when relevant,
356 provide a threshold crossing alert point for each KPI and describe the
357 significance of the threshold crossing.
364 The xNF Package **MUST** include documentation for each KPI,
365 identify the suggested actions that need to be performed when a
366 threshold crossing alert event is recorded.
373 The xNF Package **MUST** include documentation that describes
374 any requirements for the monitoring component of tools for Network
375 Cloud automation and management to provide these records to components
383 The xNF Package **MUST** include documentation to when applicable,
384 provide calculators needed to convert raw data into appropriate reporting
392 The xNF Package **MUST** include documentation describing
393 supported xNF scaling capabilities and capacity limits (e.g., number
394 of users, bandwidth, throughput, concurrent calls).
401 The xNF Package **MUST** include documentation describing
402 the characteristics for the xNF reliability and high availability.
406 Compute, Network, and Storage Requirements
407 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
412 :target: VNF HEAT PACKAGE
416 The VNF HEAT Package **MUST** include VNF topology that describes basic
417 network and application connectivity internal and external to the VNF
418 including Link type, KPIs, Bandwidth, latency, jitter, QoS (if applicable)
426 The VNF Package **MUST** include VM requirements via a Heat
427 template that provides the necessary data for VM specifications
428 for all VNF components - for hypervisor, CPU, memory, storage.
435 The VNF Package **MUST** include VM requirements via a Heat
436 template that provides the necessary data for network connections,
437 interface connections, internal and external to VNF.
444 The VNF Package **MUST** include VM requirements via a Heat
445 template that provides the necessary data for high availability
453 The VNF Package **MUST** include VM requirements via a Heat
454 template that provides the necessary data for scaling/growth VM
457 Note: Must comply with the *Heat requirements in 5.b*.
464 The VNF provider **MUST** provide the binaries and images
465 needed to instantiate the VNF (VNF and VNFC images).
469 :target: VNF or PNF PROVIDER
473 The VNF or PNF Provider **MUST** provide human readable documentation
474 (not in the on-boarding package) to describe scaling capabilities to manage
475 scaling characteristics of the VNF or PNF.
487 The VNF Package **MUST** include documentation describing
488 the tests that were conducted by the VNF provider and the test results.
495 The VNF provider **MUST** provide their testing scripts to
503 The VNF provider **MUST** provide software components that
504 can be packaged with/near the VNF, if needed, to simulate any functions
505 or systems that connect to the VNF system under test. This component is
506 necessary only if the existing testing environment does not have the
507 necessary simulators.
509 Licensing Requirements
510 ^^^^^^^^^^^^^^^^^^^^^^^
518 The xNF **MUST** provide metrics (e.g., number of sessions,
519 number of subscribers, number of seats, etc.) to ONAP for tracking
527 The xNF provider **MUST** agree to the process that can
528 be met by Service Provider reporting infrastructure. The Contract
529 shall define the reporting process and the available reporting tools.
536 The xNF provider **MUST** enumerate all of the open
537 source licenses their xNF(s) incorporate.
544 The xNF provider **MUST NOT** require audits
545 of Service Provider's business.
552 The xNF provider **MUST NOT** require additional
553 infrastructure such as a xNF provider license server for xNF provider
554 functions and metrics.
561 The VNF **MUST** provide clear measurements for licensing
562 purposes to allow automated scale up/down by the management system.
569 The VNF provider **MUST** provide the ability to scale
570 up a VNF provider supplied product during growth and scale down a
571 VNF provider supplied product during decline without "real-time"
572 restrictions based upon VNF provider permissions.
579 The xNF provider **MUST** provide a universal license key
580 per xNF to be used as needed by services (i.e., not tied to a VM
581 instance) as the recommended solution. The xNF provider may provide
582 pools of Unique xNF License Keys, where there is a unique key for
583 each xNF instance as an alternate solution. Licensing issues should
584 be resolved without interrupting in-service xNFs.
591 The xNF provider **MUST** support the metadata about
592 licenses (and their applicable entitlements) as defined in this
593 document for xNF software, and any license keys required to authorize
594 use of the xNF software. This metadata will be used to facilitate
595 onboarding the xNF into the ONAP environment and automating processes
596 for putting the licenses into use and managing the full lifecycle of
597 the licenses. The details of this license model are described in
598 Tables C1 to C8 in the Appendix.
600 Note: License metadata support in ONAP is not currently available
601 and planned for 1Q 2018.
Code Review / vnfrqts / requirements.git / blob