diff options
Diffstat (limited to 'docs/Chapter8/Requirement-List.rst')
-rw-r--r-- | docs/Chapter8/Requirement-List.rst | 2888 |
1 files changed, 2888 insertions, 0 deletions
diff --git a/docs/Chapter8/Requirement-List.rst b/docs/Chapter8/Requirement-List.rst new file mode 100644 index 0000000..41c9ea2 --- /dev/null +++ b/docs/Chapter8/Requirement-List.rst @@ -0,0 +1,2888 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. Copyright 2017 AT&T Intellectual Property. All rights reserved. + +Requirement List +-------------------------------- + +**VNF Development Requirements** +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +VNF Design +~~~~~~~~~~~~~ + +R-58421 The VNF **SHOULD** be decomposed into granular re-usable VNFCs. + +R-82223 The VNF **MUST** be decomposed if the functions have +significantly different scaling characteristics (e.g., signaling +versus media functions, control versus data plane functions). + +R-16496 The VNF **MUST** enable instantiating only the functionality that +is needed for the decomposed VNF (e.g., if transcoding is not needed it +should not be instantiated). + +R-02360 The VNFC **MUST** be designed as a standalone, executable process. + +R-34484 The VNF **SHOULD** create a single component VNF for VNFCs +that can be used by other VNFs. + +R-23035 The VNF **MUST** be designed to scale horizontally (more +instances of a VNF or VNFC) and not vertically (moving the existing +instances to larger VMs or increasing the resources within a VM) +to achieve effective utilization of cloud resources. + +R-30650 The VNF **MUST** utilize cloud provided infrastructure and +VNFs (e.g., virtualized Local Load Balancer) as part of the VNF so +that the cloud can manage and provide a consistent service resiliency +and methods across all VNF's. + +R-12709 The VNFC **SHOULD** be independently deployed, configured, +upgraded, scaled, monitored, and administered by ONAP. + +R-37692 The VNFC **MUST** provide API versioning to allow for +independent upgrades of VNFC. + +R-86585 The VNFC **SHOULD** minimize the use of state within +a VNFC to facilitate the movement of traffic from one instance +to another. + +R-65134 The VNF **SHOULD** maintain state in a geographically +redundant datastore that may, in fact, be its own VNFC. + +R-75850 The VNF **SHOULD** decouple persistent data from the VNFC +and keep it in its own datastore that can be reached by all instances +of the VNFC requiring the data. + +R-88199 The VNF **MUST** utilize a persistent datastore service that +can meet the data performance/latency requirements. (For example: +Datastore service could be a VNFC in VNF or a DBaaS in the Cloud +execution environment) + +R-99656 The VNF **MUST** NOT terminate stable sessions if a VNFC +instance fails. + +R-84473 The VNF **MUST** enable DPDK in the guest OS for VNF’s requiring +high packets/sec performance. High packet throughput is defined as greater +than 500K packets/sec. + +R-54430 The VNF **MUST** use the NCSP’s supported library and compute +flavor that supports DPDK to optimize network efficiency if using DPDK. [4]_ + +R-18864 The VNF **MUST** NOT use technologies that bypass virtualization +layers (such as SR-IOV) unless approved by the NCSP (e.g., if necessary +to meet functional or performance requirements). + +R-64768 The VNF **MUST** limit the size of application data packets +to no larger than 9000 bytes for SDN network-based tunneling when +guest data packets are transported between tunnel endpoints that +support guest logical networks. + +R-74481 The VNF **MUST** NOT require the use of a dynamic routing +protocol unless necessary to meet functional requirements. + +VNF Resiliency +~~~~~~~~~~~~~~~~~~~~~~~~~ + +R-52499 The VNF **MUST** meet their own resiliency goals and not rely +on the Network Cloud. + +R-42207 The VNF **MUST** design resiliency into a VNF such that the +resiliency deployment model (e.g., active-active) can be chosen at +run-time. + +R-03954 The VNF **MUST** survive any single points of failure within +the Network Cloud (e.g., virtual NIC, VM, disk failure). + +R-89010 The VNF **MUST** survive any single points of software failure +internal to the VNF (e.g., in memory structures, JMS message queues). + +R-67709 The VNF **MUST** be designed, built and packaged to enable +deployment across multiple fault zones (e.g., VNFCs deployed in +different servers, racks, OpenStack regions, geographies) so that +in the event of a planned/unplanned downtime of a fault zone, the +overall operation/throughput of the VNF is maintained. + +R-35291 The VNF **MUST** support the ability to failover a VNFC +automatically to other geographically redundant sites if not +deployed active-active to increase the overall resiliency of the VNF. + +R-36843 The VNF **MUST** support the ability of the VNFC to be deployable +in multi-zoned cloud sites to allow for site support in the event of cloud +zone failure or upgrades. + +R-00098 The VNF **MUST NOT** impact the ability of the VNF to provide +service/function due to a single container restart. + +R-79952 The VNF **SHOULD** support container snapshots if not for rebuild +and evacuate for rollback or back out mechanism. + +R-92935 The VNF **SHOULD** minimize the propagation of state information +across multiple data centers to avoid cross data center traffic. + +R-26371 The VNF **MUST** detect communication failure for inter VNFC +instance and intra/inter VNF and re-establish communication +automatically to maintain the VNF without manual intervention to +provide service continuity. + +R-18725 The VNF **MUST** handle the restart of a single VNFC instance +without requiring all VNFC instances to be restarted. + +R-06668 The VNF **MUST** handle the start or restart of VNFC instances +in any order with each VNFC instance establishing or re-establishing +required connections or relationships with other VNFC instances and/or +VNFs required to perform the VNF function/role without requiring VNFC +instance(s) to be started/restarted in a particular order. + +R-80070 The VNF **MUST** handle errors and exceptions so that they do +not interrupt processing of incoming VNF requests to maintain service +continuity (where the error is not directly impacting the software +handling the incoming request). + +R-32695 The VNF **MUST** provide the ability to modify the number of +retries, the time between retries and the behavior/action taken after +the retries have been exhausted for exception handling to allow the +NCSP to control that behavior, where the interface and/or functional +specification allows for altering behaviour. + +R-48356 The VNF **MUST** fully exploit exception handling to the extent +that resources (e.g., threads and memory) are released when no longer +needed regardless of programming language. + +R-67918 The VNF **MUST** handle replication race conditions both locally +and geo-located in the event of a data base instance failure to maintain +service continuity. + +R-36792 The VNF **MUST** automatically retry/resubmit failed requests +made by the software to its downstream system to increase the success rate. + +R-70013 The VNF **MUST NOT** require any manual steps to get it ready for +service after a container rebuild. + +R-65515 The VNF **MUST** provide a mechanism and tool to start VNF +containers (VMs) without impacting service or service quality assuming +another VNF in same or other geographical location is processing service +requests. + +R-94978 The VNF **MUST** provide a mechanism and tool to perform a graceful +shutdown of all the containers (VMs) in the VNF without impacting service +or service quality assuming another VNF in same or other geographical +location can take over traffic and process service requests. + +R-22059 The VNF **MUST NOT** execute long running tasks (e.g., IO, +database, network operations, service calls) in a critical section +of code, so as to minimize blocking of other operations and increase +concurrent throughput. + +R-63473 The VNF **MUST** automatically advertise newly scaled +components so there is no manual intervention required. + +R-74712 The VNF **MUST** utilize FQDNs (and not IP address) for +both Service Chaining and scaling. + +R-41159 The VNF **MUST** deliver any and all functionality from any +VNFC in the pool (where pooling is the most suitable solution). The +VNFC pool member should be transparent to the client. Upstream and +downstream clients should only recognize the function being performed, +not the member performing it. + +R-85959 The VNF **SHOULD** automatically enable/disable added/removed +sub-components or component so there is no manual intervention required. + +R-06885 The VNF **SHOULD** support the ability to scale down a VNFC pool +without jeopardizing active sessions. Ideally, an active session should +not be tied to any particular VNFC instance. + +R-12538 The VNF **SHOULD** support load balancing and discovery +mechanisms in resource pools containing VNFC instances. + +R-98989 The VNF **SHOULD** utilize resource pooling (threads, +connections, etc.) within the VNF application so that resources +are not being created and destroyed resulting in resource management +overhead. + +R-55345 The VNF **SHOULD** use techniques such as “lazy loading” when +initialization includes loading catalogues and/or lists which can grow +over time, so that the VNF startup time does not grow at a rate +proportional to that of the list. + +R-35532 The VNF **SHOULD** release and clear all shared assets (memory, +database operations, connections, locks, etc.) as soon as possible, +especially before long running sync and asynchronous operations, so as +to not prevent use of these assets by other entities. + +R-77334 The VNF **MUST** allow configurations and configuration parameters +to be managed under version control to ensure consistent configuration +deployment, traceability and rollback. + +R-99766 The VNF **MUST** allow configurations and configuration parameters +to be managed under version control to ensure the ability to rollback to +a known valid configuration. + +R-73583 The VNF **MUST** allow changes of configuration parameters +to be consumed by the VNF without requiring the VNF or its sub-components +to be bounced so that the VNF availability is not effected. + +R-21558 The VNF **SHOULD** use intelligent routing by having knowledge +of multiple downstream/upstream endpoints that are exposed to it, to +ensure there is no dependency on external services (such as load balancers) +to switch to alternate endpoints. + +R-08315 The VNF **SHOULD** use redundant connection pooling to connect +to any backend data source that can be switched between pools in an +automated/scripted fashion to ensure high availability of the connection +to the data source. + +R-27995 The VNF **SHOULD** include control loop mechanisms to notify +the consumer of the VNF of their exceeding SLA thresholds so the consumer +is able to control its load against the VNF. + +R-73364 The VNF **MUST** support at least two major versions of the +VNF software and/or sub-components to co-exist within production +environments at any time so that upgrades can be applied across +multiple systems in a staggered manner. + +R-02454 The VNF **MUST** support the existence of multiple major/minor +versions of the VNF software and/or sub-components and interfaces that +support both forward and backward compatibility to be transparent to +the Service Provider usage. + +R-57855 The VNF **MUST** support hitless staggered/rolling deployments +between its redundant instances to allow "soak-time/burn in/slow roll" +which can enable the support of low traffic loads to validate the +deployment prior to supporting full traffic loads. + +R-64445 The VNF **MUST** support the ability of a requestor of the +service to determine the version (and therefore capabilities) of the +service so that Network Cloud Service Provider can understand the +capabilities of the service. + +R-56793 The VNF **MUST** test for adherence to the defined performance +budgets at each layer, during each delivery cycle with delivered +results, so that the performance budget is measured and the code +is adjusted to meet performance budget. + +R-77667 The VNF **MUST** test for adherence to the defined performance +budget at each layer, during each delivery cycle so that the performance +budget is measured and feedback is provided where the performance budget +is not met. + +R-49308 The VNF **SHOULD** test for adherence to the defined resiliency +rating recommendation at each layer, during each delivery cycle with +delivered results, so that the resiliency rating is measured and the +code is adjusted to meet software resiliency requirements. + +R-16039 The VNF **SHOULD** test for adherence to the defined +resiliency rating recommendation at each layer, during each +delivery cycle so that the resiliency rating is measured and +feedback is provided where software resiliency requirements are +not met. + +R-34957 The VNF **MUST** provide a method of metrics gathering for each +layer's performance to identify/document variances in the allocations so +they can be addressed. + +R-49224 The VNF **MUST** provide unique traceability of a transaction +through its life cycle to ensure quick and efficient troubleshooting. + +R-52870 The VNF **MUST** provide a method of metrics gathering +and analysis to evaluate the resiliency of the software from both +a granular as well as a holistic standpoint. This includes, but is +not limited to thread utilization, errors, timeouts, and retries. + +R-92571 The VNF **MUST** provide operational instrumentation such as +logging, so as to facilitate quick resolution of issues with the VNF to +provide service continuity. + +R-48917 The VNF **MUST** monitor for and alert on (both sender and +receiver) errant, running longer than expected and missing file transfers, +so as to minimize the impact due to file transfer errors. + +R-28168 The VNF **SHOULD** use an appropriately configured logging +level that can be changed dynamically, so as to not cause performance +degradation of the VNF due to excessive logging. + +R-87352 The VNF **SHOULD** utilize Cloud health checks, when available +from the Network Cloud, from inside the application through APIs to check +the network connectivity, dropped packets rate, injection, and auto failover +to alternate sites if needed. + +R-16560 The VNF **SHOULD** conduct a resiliency impact assessment for all +inter/intra-connectivity points in the VNF to provide an overall resiliency +rating for the VNF to be incorporated into the software design and +development of the VNF. + +VNF Security +~~~~~~~~~~~~~~ + +R-23740 The VNF **MUST** accommodate the security principle of +“least privilege” during development, implementation and operation. +The importance of “least privilege” cannot be overstated and must be +observed in all aspects of VNF development and not limited to security. +This is applicable to all sections of this document. + +R-61354 The VNF **MUST** implement access control list for OA&M +services (e.g., restricting access to certain ports or applications). + +R-85633 The VNF **MUST** implement Data Storage Encryption +(database/disk encryption) for Sensitive Personal Information (SPI) +and other subscriber identifiable data. Note: subscriber’s SPI/data +must be encrypted at rest, and other subscriber identifiable data +should be encrypted at rest. Other data protection requirements exist +and should be well understood by the developer. + +R-92207 The VNF **SHOULD** implement a mechanism for automated and +frequent "system configuration (automated provisioning / closed loop)" +auditing. + +R-23882 The VNF **SHOULD** be scanned using both network scanning +and application scanning security tools on all code, including underlying +OS and related configuration. Scan reports shall be provided. Remediation +roadmaps shall be made available for any findings. + +R-46986 The VNF **SHOULD** have source code scanned using scanning +tools (e.g., Fortify) and provide reports. + +R-55830 The VNF **MUST** distribute all production code from NCSP +internal sources only. No production code, libraries, OS images, etc. +shall be distributed from publically accessible depots. + +R-99771 The VNF **MUST** provide all code/configuration files in a +"Locked down" or hardened state or with documented recommendations for +such hardening. All unnecessary services will be disabled. VNF provider +default credentials, community strings and other such artifacts will be +removed or disclosed so that they can be modified or removed during +provisioning. + +R-19768 The VNF **SHOULD** support L3 VPNs that enable segregation of +traffic by application (dropping packets not belonging to the VPN) (i.e., +AVPN, IPSec VPN for Internet routes). + +R-33981 The VNF **SHOULD** interoperate with various access control +mechanisms for the Network Cloud execution environment (e.g., +Hypervisors, containers). + +R-40813 The VNF **SHOULD** support the use of virtual trusted platform +module, hypervisor security testing and standards scanning tools. + +R-56904 The VNF **MUST** interoperate with the ONAP (SDN) Controller so that +it can dynamically modify the firewall rules, ACL rules, QoS rules, virtual +routing and forwarding rules. + +R-26586 The VNF **SHOULD** support the ability to work with aliases +(e.g., gateways, proxies) to protect and encapsulate resources. + +R-49956 The VNF **MUST** pass all access to applications (Bearer, +signaling and OA&M) through various security tools and platforms from +ACLs, stateful firewalls and application layer gateways depending on +manner of deployment. The application is expected to function (and in +some cases, interwork) with these security tools. + +R-69649 The VNF **MUST** have all vulnerabilities patched as soon +as possible. Patching shall be controlled via change control process +with vulnerabilities disclosed along with mitigation recommendations. + +R-78010 The VNF **MUST** use the NCSP’s IDAM API for Identification, +authentication and access control of customer or VNF application users. + +R-42681 The VNF **MUST** use the NCSP’s IDAM API or comply with +the requirements if not using the NCSP’s IDAM API, for identification, +authentication and access control of OA&M and other system level +functions. + +R-68589 The VNF **MUST**, if not using the NCSP’s IDAM API, support +User-IDs and passwords to uniquely identify the user/application. VNF +needs to have appropriate connectors to the Identity, Authentication +and Authorization systems that enables access at OS, Database and +Application levels as appropriate. + +R-52085 The VNF **MUST**, if not using the NCSP’s IDAM API, provide +the ability to support Multi-Factor Authentication (e.g., 1st factor = +Software token on device (RSA SecureID); 2nd factor = User Name+Password, +etc.) for the users. + +R-98391 The VNF **MUST**, if not using the NCSP’s IDAM API, support +Role-Based Access Control to permit/limit the user/application to +performing specific activities. + +R-63217 The VNF **MUST**, if not using the NCSP’s IDAM API, support +logging via ONAP for a historical view of “who did what and when”. + +R-62498 The VNF **MUST**, if not using the NCSP’s IDAM API, encrypt +OA&M access (e.g., SSH, SFTP). + +R-79107 The VNF **MUST**, if not using the NCSP’s IDAM API, enforce +a configurable maximum number of Login attempts policy for the users. +VNF provider must comply with "terminate idle sessions" policy. +Interactive sessions must be terminated, or a secure, locking screensaver +must be activated requiring authentication, after a configurable period +of inactivity. The system-based inactivity timeout for the enterprise +identity and access management system must also be configurable. + +R-35144 The VNF **MUST**, if not using the NCSP’s IDAM API, comply +with the NCSP’s credential management policy. + +R-75041 The VNF **MUST**, if not using the NCSP’s IDAM API, expire +passwords at regular configurable intervals. + +R-46908 The VNF **MUST**, if not using the NCSP’s IDAM API, comply +with "password complexity" policy. When passwords are used, they shall +be complex and shall at least meet the following password construction +requirements: (1) be a minimum configurable number of characters in +length, (2) include 3 of the 4 following types of characters: +upper-case alphabetic, lower-case alphabetic, numeric, and special, +(3) not be the same as the UserID with which they are associated or +other common strings as specified by the environment, (4) not contain +repeating or sequential characters or numbers, (5) not to use special +characters that may have command functions, and (6) new passwords must +not contain sequences of three or more characters from the previous +password. + +R-39342 The VNF **MUST**, if not using the NCSP’s IDAM API, comply +with "password changes (includes default passwords)" policy. Products +will support password aging, syntax and other credential management +practices on a configurable basis. + +R-40521 The VNF **MUST**, if not using the NCSP’s IDAM API, support +use of common third party authentication and authorization tools such +as TACACS+, RADIUS. + +R-41994 The VNF **MUST**, if not using the NCSP’s IDAM API, comply +with "No Self-Signed Certificates" policy. Self-signed certificates +must be used for encryption only, using specified and approved +encryption protocols such as TLS 1.2 or higher or equivalent security +protocols such as IPSec, AES. + +R-23135 The VNF **MUST**, if not using the NCSP’s IDAM API, +authenticate system to system communications where one system +accesses the resources of another system, and must never conceal +individual accountability. + +R-95105 The VNF **MUST** host connectors for access to the application +layer. + +R-45496 The VNF **MUST** host connectors for access to the OS +(Operating System) layer. + +R-05470 The VNF **MUST** host connectors for access to the database layer. + +R-99174 The VNF **MUST** comply with Individual Accountability +(each person must be assigned a unique ID) when persons or non-person +entities access VNFs. + +R-42874 The VNF **MUST** comply with Least Privilege (no more +privilege than required to perform job functions) when persons +or non-person entities access VNFs. + +R-71787 The VNF **MUST** comply with Segregation of Duties (access to a +single layer and no developer may access production without special +oversight) when persons or non-person entities access VNFs. + +R-86261 The VNF **MUST NOT** allow VNF provider access to VNFs remotely. + +R-49945 The VNF **MUST** authorize VNF provider access through a +client application API by the client application owner and the resource +owner of the VNF before provisioning authorization through Role Based +Access Control (RBAC), Attribute Based Access Control (ABAC), or other +policy based mechanism. + +R-31751 The VNF **MUST** subject VNF provider access to privilege +reconciliation tools to prevent access creep and ensure correct +enforcement of access policies. + +R-34552 The VNF **MUST** provide or support the Identity and Access +Management (IDAM) based threat detection data for OWASP Top 10. + +R-29301 The VNF **MUST** provide or support the Identity and Access +Management (IDAM) based threat detection data for Password Attacks. + +R-72243 The VNF **MUST** provide or support the Identity and Access +Management (IDAM) based threat detection data for Phishing / SMishing. + +R-58998 The VNF **MUST** provide or support the Identity and Access +Management (IDAM) based threat detection data for Malware (Key Logger). + +R-14025 The VNF **MUST** provide or support the Identity and Access +Management (IDAM) based threat detection data for Session Hijacking. + +R-31412 The VNF **MUST** provide or support the Identity and Access +Management (IDAM) based threat detection data for XSS / CSRF. + +R-51883 The VNF **MUST** provide or support the Identity and Access +Management (IDAM) based threat detection data for Replay. + +R-44032 The VNF **MUST** provide or support the Identity and Access +Management (IDAM) based threat detection data for Man in the Middle (MITM). + +R-58977 The VNF **MUST** provide or support the Identity and Access +Management (IDAM) based threat detection data for Eavesdropping. + +R-24825 The VNF **MUST** provide Context awareness data (device, +location, time, etc.) and be able to integrate with threat detection system. + +R-59391 The VNF provider **MUST**, where a VNF provider requires +the assumption of permissions, such as root or administrator, first +log in under their individual user login ID then switch to the other +higher level account; or where the individual user login is infeasible, +must login with an account with admin privileges in a way that +uniquely identifies the individual performing the function. + +R-85028 The VNF **MUST** authenticate system to system access and +do not conceal a VNF provider user’s individual accountability for +transactions. + +R-80335 The VNF **MUST** make visible a Warning Notice: A formal +statement of resource intent, i.e., a warning notice, upon initial +access to a VNF provider user who accesses private internal networks +or Company computer resources, e.g., upon initial logon to an internal +web site, system or application which requires authentication. + +R-73541 The VNF **MUST** use access controls for VNFs and their +supporting computing systems at all times to restrict access to +authorized personnel only, e.g., least privilege. These controls +could include the use of system configuration or access control +software. + +R-64503 The VNF **MUST** provide minimum privileges for initial +and default settings for new user accounts. + +R-86835 The VNF **MUST** set the default settings for user access +to sensitive commands and data to deny authorization. + +R-77157 The VNF **MUST** conform to approved request, workflow +authorization, and authorization provisioning requirements when +creating privileged users. + +R-81147 The VNF **MUST** have greater restrictions for access and +execution, such as up to 3 factors of authentication and restricted +authorization, for commands affecting network services, such as +commands relating to VNFs. + +R-49109 The VNF **MUST** encrypt TCP/IP--HTTPS (e.g., TLS v1.2) +transmission of data on internal and external networks. + +R-39562 The VNF **MUST** disable unnecessary or vulnerable cgi-bin programs. + +R-15671 The VNF **MUST NOT** provide public or unrestricted access +to any data without the permission of the data owner. All data +classification and access controls must be followed. + +R-89753 The VNF **MUST NOT** install or use systems, tools or +utilities capable of capturing or logging data that was not created +by them or sent specifically to them in production, without +authorization of the VNF system owner. + +R-19082 The VNF **MUST NOT** run security testing tools and +programs, e.g., password cracker, port scanners, hacking tools +in production, without authorization of the VNF system owner. + +R-19790 The VNF **MUST NOT** include authentication credentials +in security audit logs, even if encrypted. + +R-85419 The VNF **SHOULD** use REST APIs exposed to Client +Applications for the implementation of OAuth 2.0 Authorization +Code Grant and Client Credentials Grant, as the standard interface +for a VNF. + +R-48080 The VNF **SHOULD** support SCEP (Simple Certificate +Enrollment Protocol). + +R-37608 The VNF **MUST** provide a mechanism to restrict access based +on the attributes of the VNF and the attributes of the subject. + +R-43884 The VNF **MUST** integrate with external authentication +and authorization services (e.g., IDAM). + +R-25878 The VNF **MUST** use certificates issued from publicly +recognized Certificate Authorities (CA) for the authentication process +where PKI-based authentication is used. + +R-19804 The VNF **MUST** validate the CA signature on the certificate, +ensure that the date is within the validity period of the certificate, +check the Certificate Revocation List (CRL), and recognize the identity +represented by the certificate where PKI-based authentication is used. + +R-47204 The VNF **MUST** protect the confidentiality and integrity of +data at rest and in transit from unauthorized access and modification. + +R-33488 The VNF **MUST** protect against all denial of service +attacks, both volumetric and non-volumetric, or integrate with external +denial of service protection tools. + +R-21652 The VNF **MUST** implement the following input validation +control: Check the size (length) of all input. Do not permit an amount +of input so great that it would cause the VNF to fail. Where the input +may be a file, the VNF API must enforce a size limit. + +R-54930 The VNF **MUST** implement the following input validation +control: Do not permit input that contains content or characters +inappropriate to the input expected by the design. Inappropriate input, +such as SQL insertions, may cause the system to execute undesirable +and unauthorized transactions against the database or allow other +inappropriate access to the internal network. + +R-21210 The VNF **MUST** implement the following input validation +control: Validate that any input file has a correct and valid +Multipurpose Internet Mail Extensions (MIME) type. Input files +should be tested for spoofed MIME types. + +R-23772 The VNF **MUST** validate input at all layers implementing VNF APIs. + +R-87135 The VNF **MUST** comply with NIST standards and industry +best practices for all implementations of cryptography. + +R-02137 The VNF **MUST** implement all monitoring and logging as +described in the Security Analytics section. + +R-15659 The VNF **MUST** restrict changing the criticality level of +a system security alarm to administrator(s). + +R-19367 The VNF **MUST** monitor API invocation patterns to detect +anomalous access patterns that may represent fraudulent access or +other types of attacks, or integrate with tools that implement anomaly +and abuse detection. + +R-78066 The VNF **MUST** support requests for information from law +enforcement and government agencies. + +R-48470 The VNF **MUST** support Real-time detection and +notification of security events. + +R-22286 The VNF **MUST** support Integration functionality via +API/Syslog/SNMP to other functional modules in the network (e.g., +PCRF, PCEF) that enable dynamic security control by blocking the +malicious traffic or malicious end users. + +R-32636 The VNF **MUST** support API-based monitoring to take care of +the scenarios where the control interfaces are not exposed, or are +optimized and proprietary in nature. + +R-61648 The VNF **MUST** support event logging, formats, and delivery +tools to provide the required degree of event data to ONAP. + +R-22367 The VNF **MUST** support detection of malformed packets due to +software misconfiguration or software vulnerability. + +R-31961 The VNF **MUST** support integrated DPI/monitoring functionality +as part of VNFs (e.g., PGW, MME). + +R-20912 The VNF **MUST** support alternative monitoring capabilities +when VNFs do not expose data or control traffic or use proprietary and +optimized protocols for inter VNF communication. + +R-73223 The VNF **MUST** support proactive monitoring to detect and +report the attacks on resources so that the VNFs and associated VMs can +be isolated, such as detection techniques for resource exhaustion, namely +OS resource attacks, CPU attacks, consumption of kernel memory, local +storage attacks. + +R-58370 The VNF **MUST** coexist and operate normally with commercial +anti-virus software which shall produce alarms every time when there is a +security incident. + +R-56920 The VNF **MUST** protect all security audit logs (including +API, OS and application-generated logs), security audit software, data, +and associated documentation from modification, or unauthorized viewing, +by standard OS access control mechanisms, by sending to a remote system, +or by encryption. + +R-54520 The VNF **MUST** log successful and unsuccessful login attempts. + +R-55478 The VNF **MUST** log logoffs. + +R-08598 The VNF **MUST** log successful and unsuccessful changes to +a privilege level. + +R-13344 The VNF **MUST** log starting and stopping of security +logging. + +R-07617 The VNF **MUST** log creating, removing, or changing the +inherent privilege level of users. + +R-94525 The VNF **MUST** log connections to a network listener of the +resource. + +R-31614 The VNF **MUST** log the field “event type” in the security +audit logs. + +R-97445 The VNF **MUST** log the field “date/time” in the security +audit logs. + +R-25547 The VNF **MUST** log the field “protocol” in the security audit logs. + +R-06413 The VNF **MUST** log the field “service or program used for +access” in the security audit logs. + +R-15325 The VNF **MUST** log the field “success/failure” in the +security audit logs. + +R-89474 The VNF **MUST** log the field “Login ID” in the security audit logs. + +R-04982 The VNF **MUST NOT** include an authentication credential, +e.g., password, in the security audit logs, even if encrypted. + +R-63330 The VNF **MUST** detect when the security audit log storage +medium is approaching capacity (configurable) and issue an alarm via +SMS or equivalent as to allow time for proper actions to be taken to +pre-empt loss of audit data. + +R-41252 The VNF **MUST** support the capability of online storage of +security audit logs. + +R-41825 The VNF **MUST** activate security alarms automatically when +the following event is detected: configurable number of consecutive +unsuccessful login attempts + +R-43332 The VNF **MUST** activate security alarms automatically when +the following event is detected: successful modification of critical +system or application files + +R-74958 The VNF **MUST** activate security alarms automatically when +the following event is detected: unsuccessful attempts to gain permissions +or assume the identity of another user + +R-15884 The VNF **MUST** include the field “date” in the Security alarms +(where applicable and technically feasible). + +R-23957 The VNF **MUST** include the field “time” in the Security alarms +(where applicable and technically feasible). + +R-71842 The VNF **MUST** include the field “service or program used for +access” in the Security alarms (where applicable and technically feasible). + +R-57617 The VNF **MUST** include the field “success/failure” in the +Security alarms (where applicable and technically feasible). + +R-99730 The VNF **MUST** include the field “Login ID” in the Security +alarms (where applicable and technically feasible). + +R-29705 The VNF **MUST** restrict changing the criticality level of a +system security alarm to administrator(s). + +R-13627 The VNF **MUST** monitor API invocation patterns to detect +anomalous access patterns that may represent fraudulent access or other +types of attacks, or integrate with tools that implement anomaly and +abuse detection. + +R-21819 The VNF **MUST** support requests for information from law +enforcement and government agencies. + +R-56786 The VNF **MUST** implement “Closed Loop” automatic implementation +(without human intervention) for Known Threats with detection rate in low +false positives. + +R-25094 The VNF **MUST** perform data capture for security functions. + +R-04492 The VNF **MUST** generate security audit logs that must be sent +to Security Analytics Tools for analysis. + +R-19219 The VNF **MUST** provide audit logs that include user ID, dates, +times for log-on and log-off, and terminal location at minimum. + +R-30932 The VNF **MUST** provide security audit logs including records +of successful and rejected system access data and other resource access +attempts. + +R-54816 The VNF **MUST** support the storage of security audit logs +for agreed period of time for forensic analysis. + +R-57271 The VNF **MUST** provide the capability of generating security +audit logs by interacting with the operating system (OS) as appropriate. + +R-84160 The VNF **MUST** have security logging for VNFs and their +OSs be active from initialization. Audit logging includes automatic +routines to maintain activity records and cleanup programs to ensure +the integrity of the audit/logging systems. + +R-58964 The VNF **MUST** provide the capability to restrict read +and write access to data. + +R-99112 The VNF **MUST** provide the capability to restrict access +to data to specific users. + +R-83227 The VNF **MUST** Provide the capability to encrypt data in +transit on a physical or virtual network. + +R-32641 The VNF **MUST** provide the capability to encrypt data on +non-volatile memory. + +R-13151 The VNF **SHOULD** disable the paging of the data requiring +encryption, if possible, where the encryption of non-transient data is +required on a device for which the operating system performs paging to +virtual memory. If not possible to disable the paging of the data +requiring encryption, the virtual memory should be encrypted. + +R-93860 The VNF **MUST** provide the capability to integrate with an +external encryption service. + +R-73067 The VNF **MUST** use industry standard cryptographic algorithms +and standard modes of operations when implementing cryptography. + +R-22645 The VNF **SHOULD** use commercial algorithms only when there +are no applicable governmental standards for specific cryptographic +functions, e.g., public key cryptography, message digests. + +R-12467 The VNF **MUST NOT** use the SHA, DSS, MD5, SHA-1 and +Skipjack algorithms or other compromised encryption. + +R-02170 The VNF **MUST** use, whenever possible, standard implementations +of security applications, protocols, and format, e.g., S/MIME, TLS, SSH, +IPSec, X.509 digital certificates for cryptographic implementations. +These implementations must be purchased from reputable vendors and must +not be developed in-house. + +R-70933 The VNF **MUST** provide the ability to migrate to newer +versions of cryptographic algorithms and protocols with no impact. + +R-44723 The VNF **MUST** use symmetric keys of at least 112 bits in length. + +R-25401 The VNF **MUST** use asymmetric keys of at least 2048 bits in length. + +R-95864 The VNF **MUST** use commercial tools that comply with X.509 +standards and produce x.509 compliant keys for public/private key generation. + +R-12110 The VNF **MUST NOT** use keys generated or derived from +predictable functions or values, e.g., values considered predictable +include user identity information, time of day, stored/transmitted data. + +R-52060 The VNF **MUST** provide the capability to configure encryption +algorithms or devices so that they comply with the laws of the jurisdiction +in which there are plans to use data encryption. + +R-69610 The VNF **MUST** provide the capability of using certificates +issued from a Certificate Authority not provided by the VNF provider. + +R-83500 The VNF **MUST** provide the capability of allowing certificate +renewal and revocation. + +R-29977 The VNF **MUST** provide the capability of testing the validity +of a digital certificate by validating the CA signature on the certificate. + +R-24359 The VNF **MUST** provide the capability of testing the validity +of a digital certificate by validating the date the certificate is being +used is within the validity period for the certificate. + +R-39604 The VNF **MUST** provide the capability of testing the +validity of a digital certificate by checking the Certificate Revocation +List (CRL) for the certificates of that type to ensure that the +certificate has not been revoked. + +R-75343 The VNF **MUST** provide the capability of testing the +validity of a digital certificate by recognizing the identity represented +by the certificate — the "distinguished name". + +VNF Modularity +~~~~~~~~~~~~~~~~~~ + +R-37028 The VNF **MUST** be composed of one “base” module. + +R-41215 The VNF **MAY** have zero to many “incremental” modules. + +R-20974 The VNF **MUST** deploy the base module first, prior to +the incremental modules. + +R-11200 The VNF **MUST** keep the scope of a Cinder volume module, +when it exists, to be 1:1 with the VNF Base Module or Incremental Module. + +R-38474 The VNF **MUST** have a corresponding environment file for +a Base Module. + +R-81725 The VNF **MUST** have a corresponding environment file for +an Incremental Module. + +R-53433 The VNF **MUST** have a corresponding environment file for +a Cinder Volume Module. + +VNF Devops +~~~~~~~~~~~~~~ + +R-46960 NCSPs **MAY** operate a limited set of Guest OS and CPU +architectures and families, virtual machines, etc. + +R-23475 VNFCs **SHOULD** be agnostic to the details of the Network Cloud +(such as hardware, host OS, Hypervisor or container technology) and must run +on the Network Cloud with acknowledgement to the paradigm that the Network +Cloud will continue to rapidly evolve and the underlying components of +the platform will change regularly. + +R-33846 The VNF **MUST** install the NCSP required software on Guest OS +images when not using the NCSP provided Guest OS images. [4]_ + +R-09467 The VNF **MUST** utilize only NCSP standard compute flavors. [4]_ + +R-02997 The VNF **MUST** preserve their persistent data. Running VMs +will not be backed up in the Network Cloud infrastructure. + +R-29760 The VNFC **MUST** be installed on non-root file systems, +unless software is specifically included with the operating system +distribution of the guest image. + +R-20860 The VNF **MUST** be agnostic to the underlying infrastructure +(such as hardware, host OS, Hypervisor), any requirements should be +provided as specification to be fulfilled by any hardware. + +R-89800 The VNF **MUST NOT** require Hypervisor-level customization +from the cloud provider. + +R-86758 The VNF **SHOULD** provide an automated test suite to validate +every new version of the software on the target environment(s). The tests +should be of sufficient granularity to independently test various +representative VNF use cases throughout its lifecycle. Operations might +choose to invoke these tests either on a scheduled basis or on demand to +support various operations functions including test, turn-up and +troubleshooting. + +R-39650 The VNF **SHOULD** provide the ability to test incremental +growth of the VNF. + +R-14853 The VNF **MUST** respond to a "move traffic" [1]_ command +against a specific VNFC, moving all existing session elsewhere with +minimal disruption if a VNF provides a load balancing function across +multiple instances of its VNFCs. Note: Individual VNF performance +aspects (e.g., move duration or disruption scope) may require further +constraints. + +R-06327 The VNF **MUST** respond to a "drain VNFC" [1]_ command against +a specific VNFC, preventing new session from reaching the targeted VNFC, +with no disruption to active sessions on the impacted VNFC, if a VNF +provides a load balancing function across multiple instances of its VNFCs. +This is used to support scenarios such as proactive maintenance with no +user impact. + +R-64713 The VNF **SHOULD** support a software promotion methodology +from dev/test -> pre-prod -> production in software, development & +testing and operations. + +**VNF Modeling Requirements** +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Heat +~~~~ + +R-95303 A VNF's Heat Orchestration Template **MUST** +be defined using valid YAML. + +R-27078 A VNF's Heat Orchestration template **MUST** contain +the section "heat_template_version:". + +R-39402 A VNF's Heat Orchestration Template **MUST** +contain the section "description:". + +R-35414 A VNF Heat Orchestration's template **MUST** +contain the section "parameters:". + +R-90279 A VNF Heat Orchestration's template's parameter **MUST** +be used in a resource with the exception of the parameters +for the OS::Nova::Server resource property availability_zone. + +R-91273 A VNF Heat Orchestration’s template’s parameter for +the OS::Nova::Server resource property availability_zone +**MAY NOT** be used in any OS::Nova::Resource. + +R-25877 A VNF's Heat Orchestration Template's parameter +name (i.e., <param name>) **MUST** contain only +alphanumeric characters and underscores ('_'). + +R-36772 A VNF’s Heat Orchestration Template’s parameter +**MUST** include the attribute “type:”. + +R-11441 A VNF’s Heat Orchestration Template’s parameter +type **MUST** be one of the following values: "string", +"number", "json", "comma_delimited_list" or "boolean". + +R-32094 A VNF's Heat Orchestration Template parameter +declaration **MAY** contain the attribute "label:" + +R-44001 A VNF's Heat Orchestration Template parameter +declaration **MUST** contain the attribute "description". + +R-90526 A VNF Heat Orchestration Template parameter +declaration **MUST** not contain the default attribute. + +R-26124 If a VNF Heat Orchestration Template parameter +requires a default value, it **MUST** be enumerated in the environment file. + +R-32557 A VNF's Heat Orchestration Template parameter +declaration MAY contain the attribute "hidden:". + +R-88863 A VNF's Heat Orchestration Template's parameter defined as +type "number" **MUST** have a parameter constraint of "range" or +"allowed_values" defined. + +R-40518 A VNF's Heat Orchestration Template’s parameter defined as +type "string" **MAY** have a parameter constraint defined. + +R-96227 A VNF's Heat Orchestration Template’s parameter defined as +type "json" **MAY** have a parameter constraint defined. + +R-79817 A VNF's Heat Orchestration Template’s parameter defined as +type "comma_delimited_list" **MAY** have a parameter constraint defined. + +R-06613 A VNF's Heat Orchestration Template’s parameter defined as +type "boolean" **MAY** have a parameter constraint defined. + +R-00011 A VNF's Heat Orchestration Template's Nested YAML files +parameter's **MUST NOT** have a parameter constraint defined. + +R-22589 A VNF’s Heat Orchestration Template parameter declaration +**MAY** contain the attribute "immutable:". + +R-23664 A VNF's Heat Orchestration template **MUST** contain +the section "resources:". + +R-90152 A VNF's Heat Orchestration Template's "resources:" +section **MUST** contain the declaration of at least one resource. + +R-40551 A VNF's Heat Orchestration Template's Nested YAML files +**MAY** contain the section "resources:". + +R-75141 A VNF's Heat Orchestration Template's resource name +(i.e., <resource ID>) **MUST** only contain alphanumeric +characters and underscores ('_'). + +R-16447 A VNF's <resource ID> **MUST** be unique across all +Heat Orchestration Templates and all HEAT Orchestration Template +Nested YAML files that are used to create the VNF. + +R-53952 A VNF’s Heat Orchestration Template’s Resource +**MUST NOT** reference a HTTP-based resource definitions. + +R-71699 A VNF’s Heat Orchestration Template’s Resource +**MUST NOT** reference a HTTP-based Nested YAML file. + +R-10834 If a VNF Heat Orchestration Template resource attribute +"property:" uses a nested "get_param", one level of nesting is +supported and the nested "get_param" **MUST** reference an index + +R-97199 A VNF's Heat Orchestration Template's OS::Nova::Server +resource **MUST** contain the attribute "metadata". + +R-46968 VNF’s Heat Orchestration Template’s Resource **MAY** +declare the attribute “depends_on:”. + +R-63137 VNF’s Heat Orchestration Template’s Resource **MAY** +declare the attribute “update_policy:”. + +R-43740 A VNF’s Heat Orchestration Template’s Resource +**MAY** declare the attribute “deletion_policy:”. + +R-78569 A VNF’s Heat Orchestration Template’s Resouce **MAY** +declare the attribute “external_id:”. + +R-36982 A VNF’s Heat Orchestration template **MAY** contain the +“outputs:” section. + +R-86285 The VNF Heat Orchestration Template **MUST** have a corresponding +environment file, even if no parameters are required to be enumerated. + +R-86285 The VNF Heat Orchestration Template **MUST** have a +corresponding environment file, even if no parameters are required to be +enumerated. + +R-03324 The VNF Heat Orchestration Template **MUST** contain the +"parameters" section in the +environment file + +R-68198 A VNF’s Heat Orchestration template’s Environment File’s +“parameters:” section **MAY** enumerate parameters. + +R-59930 A VNF’s Heat Orchestration template’s Environment +File’s **MAY** contain the “parameter_defaults:” section. + +R-46096 A VNF’s Heat Orchestration template’s Environment File’s +**MAY** contain the “encrypted_parameters:” section. + +R-24893 A VNF’s Heat Orchestration template’s Environment File’s +**MAY** contain the “event_sinks:” section. + +R-42685 A VNF’s Heat Orchestration template’s Environment File’s +**MAY** contain the “parameter_merge_strategies:” section. + +R-67231 A VNF’s Heat Orchestration template’s Environment File’s **MUST NOT** +contain the “resource_registry:” section. + +R-69663 A VNF **MAY** be composed from one or more Heat Orchestration +Templates, each of which represents a subset of the overall VNF. + +R-33132 A VNF’s Heat Orchestration Template **MAY** be 1.) Base Module +Heat Orchestration Template (also referred to as a Base Module), 2.) +Incremental Module Heat Orchestration Template (referred to as an Incremental +Module), or 3.) a Cinder Volume Module Heat Orchestration Template +(referred to as Cinder Volume Module). + +R-13196 A VNF **MAY** be composed of zero to many Incremental Modules + +R-28980 A VNF’s incremental module **MAY** be used for initial VNF +deployment only. + +R-86926 A VNF’s incremental module **MAY** be used for scale out only. + +R-91497 A VNF’s incremental module **MAY** be used for both deployment +and scale out. + +R-68122 A VNF’s incremental module **MAY** be deployed more than once, +either during initial VNF deployment and/or scale out. + +R-46119 A VNF’s Heat Orchestration Template’s Resource OS::Heat::CinderVolume +**MAY** be defined in a Base Module. + +R-90748 A VNF’s Heat Orchestration Template’s Resource OS::Cinder::Volume +**MAY** be defined in an Incremental Module. + +R-03251 A VNF’s Heat Orchestration Template’s Resource OS::Cinder::Volume +**MAY** be defined in a Cinder Volume Module. + +R-11200 The VNF **MUST** keep the scope of a Cinder volume module, +when it exists, to be 1:1 with the VNF Base Module or Incremental Module. + +R-11200 The VNF **MUST** keep the scope of a Cinder volume module, when it +exists, to be 1:1 with the VNF Base Module or Incremental Module + +R-36582 A VNF’s Base Module **MAY** utilize nested heat. + +R-56721 A VNF’s Incremental Module **MAY** utilize nested heat. + +R-30395 A VNF’s Cinder Volume Module **MAY** utilize nested heat. + +R-87485 A VNF’s Heat Orchestration Template’s file extension **MUST** +be in the lower case format ‘.yaml’ or ‘.yml’. + +R-56438 A VNF’s Heat Orchestration Template’s Nested YAML file extension +**MUST** be in the lower case format ‘.yaml’ or ‘.yml’. + +R-74304 A VNF’s Heat Orchestration Template’s Environment file extension +**MUST** be in the lower case format ‘.env’. + +R-81339 A VNF Heat Orchestration Template’s Base Module file name **MUST** +include ‘base’ in the filename and **MUST** match one of the following four +formats: 1.) ‘base_<text>.y[a]ml’, 2.) ‘<text>_base.y[a]ml’, 3.) +‘base.y[a]ml’, or 4.) ‘<text>_base_<text>’.y[a]ml; where ‘base’ is case +insensitive and where ‘<text>’ **MUST** contain only alphanumeric characters +and underscores ‘_’ and **MUST NOT** contain the case insensitive word ‘base’. + +R-91342 A VNF Heat Orchestration Template’s Base Module’s Environment File +**MUST** be named identical to the VNF Heat Orchestration Template’s Base +Module with ‘.y[a]ml’ replaced with ‘.env’. + +R-87247 A VNF Heat Orchestration Template’s Incremental Module file name +**MUST** contain only alphanumeric characters and underscores ‘_’ and +**MUST NOT** contain the case insensitive word ‘base’. + +R-94509 A VNF Heat Orchestration Template’s Incremental Module’s Environment +File **MUST** be named identical to the VNF Heat Orchestration Template’s +Incremental Module with ‘.y[a]ml’ replaced with ‘.env’. + +R-82732 A VNF Heat Orchestration Template’s Cinder Volume Module **MUST** be +named identical to the base or incremental module it is supporting with +‘_volume appended’ + +R-31141 A VNF Heat Orchestration Template’s Cinder Volume Module’s Environment +File **MUST** be named identical to the VNF Heat Orchestration Template’s +Cinder Volume Module with .y[a]ml replaced with ‘.env’. + +R-76057 A VNF Heat Orchestration Template’s Nested YAML file name **MUST** +contain only alphanumeric characters and underscores ‘_’ and **MUST NOT** +contain the case insensitive word ‘base’. + +R-18224 The VNF Heat Orchestration Template **MUST** pass in as properties +all parameter values +associated with the nested heat file in the resource definition defined +in the parent heat template. + +R-52753 VNF’s Heat Orchestration Template’s Base Module’s output parameter’s +name and type **MUST** match the VNF’s Heat Orchestration Template’s +incremental Module’s name and type unless the output parameter is of type +‘comma_delimited_list’, then the corresponding input parameter **MUST** +be declared as type ‘json’. + +R-22608 When a VNF’s Heat Orchestration Template’s Base Module’s output +parameter is declared as an input parameter in an Incremental Module, +the parameter attribute ‘constraints:’ **MUST NOT** be declared. + +R-89913 A VNF’s Heat Orchestration Template’s Cinder Volume Module Output +Parameter(s) **MUST** include the UUID(s) of the Cinder Volumes created in +template, while other Output Parameters **MAY** be included. + +R-07443 A VNF’s Heat Orchestration Templates’ Cinder Volume Module Output +Parameter’s name and type **MUST** match the input parameter name and type +in the corresponding Base Module or Incremental Module unless the Output +Parameter is of the type ‘comma_delimited_list’, then the corresponding input +parameter **MUST** be declared as type ‘json’. + +R-20547 When an ONAP Volume Module Output Parameter is declared as an input +parameter in a base or an incremental module Heat Orchestration Template, +parameter constraints **MUST NOT** be declared. + +R-39349 A VNF Heat Orchestration Template **MUST NOT** be designed to +utilize the OpenStack ‘heat stack-update’ command for scaling +(growth/de-growth). + +R-43413 A VNF **MUST** utilize a modular Heat Orchestration Template +design to support scaling (growth/de-growth). + +R-59482 A VNF’s Heat Orchestration Template **MUST NOT** be VNF instance +specific or Cloud site specific + +R-56750 A VNF’s Heat Orchestration Template’s parameter values that are +constant across all deployments **MUST** be declared in a Heat Orchestration +Template Environment File. + +R-01896 A VNF’s Heat Orchestration Template’s parameter values that are +constant across all deployments **MUST** be declared in a Heat Orchestration +Template Environment File. + +R-16968 A VNF’s Heat Orchestration Templates **MUST NOT** include heat +resources to create external networks. + +R-00606 A VNF **MAY** be connected to zero, one or more than one external +networks. + +R-57424 A VNF’s port connected to an external network **MUST** connect the +port to VMs in another VNF and/or an external gateway and/or external router. + +R-29865 A VNF’s port connected to an external network **MUST NOT** connect +the port to VMs in the same VNF. + +R-69014 When a VNF connects to an external network, a network role, referred +to as the ‘{network-role}’ **MUST** be assigned to the external network +for use in the VNF’s Heat Orchestration Template. + +R-05201 When a VNF connects to two or more external networks, each external +network **MUST** be assigned a unique ‘{network-role}’ in the context of +the VNF for use in the VNF’s Heat Orchestration Template. + +R-83015 A VNF’s ‘{network-role}’ assigned to an external network **MUST** +be different than the ‘{network-role}’ assigned to the VNF’s internal +networks, if internal networks exist. + +R-87096 A VNF **MAY** contain zero, one or more than one internal networks. + +R-35666 If a VNF has an internal network, the VNF Heat Orchestration +Template **MUST** include the heat resources to create the internal network. + +R-86972 A VNF **SHOULD** create the internal network in the VNF’s Heat +Orchestration Template Base Module. + +R-52425 A VNF’s port connected to an internal network **MUST** connect +the port to VMs in the same VNF. + +R-46461 A VNF’s port connected to an internal network **MUST NOT** connect +the port to VMs in another VNF and/or an external gateway and/or +external router. + +R-68936 When a VNF creates an internal network, a network role, referred to +as the ‘{network-role}’ **MUST** be assigned to the internal network for +use in the VNF’s Heat Orchestration Template. + +R-32025 When a VNF creates two or more internal networks, each internal +network **MUST** be assigned a unique ‘{network-role}’ in the context of +the VNF for use in the VNF’s Heat Orchestration Template. + +R-69874 A VNF’s ‘{network-role}’ assigned to an internal network **MUST** +be different than the ‘{network-role}’ assigned to the VNF’s external +networks. + +R-34726 If a VNF’s port is connected to an internal network and the port +is created in the same Heat Orchestration Template as the internal network, +then the port resource **MUST** use a ‘get_resource’ to obtain +the network UUID. + +R-22688 If a VNF’s port is connected to an internal network and the +port is created in an Incremental Module and the internal network is created +in the Base Module then the UUID of the internal network **MUST** be exposed +as a parameter in the ‘outputs:’ section of the Base Module and the port +resource **MUST** use a ‘get_param’ to obtain the network UUID. + +R-01455 When a VNF's Heat Orchestration Template creates a +Virtual Machine (i.e., 'OS::Nova::Server'), +each 'class' of VMs **MUST** be assigned a VNF unique +'{vm-type}'; where 'class' defines VMs that **MUST** have the following +identical characteristics: + +R-82481 A VNF's Heat Orchestration Template's Resource +property parameter that is associated with a unique Virtual +Machine type **MUST** include '{vm-type}' as part of the +parameter name with two exceptions: + +R-66729 A VNF’s Heat Orchestration Template’s Resource that is +associated with a unique Virtual Machine type **MUST** include +‘{vm-type}’ as part of the resource ID. + +R-98407 A VNF's Heat Orchestration Template's '{vm-type}' **MUST** contain +only alphanumeric characters and/or underscores '_' and +**MUST NOT** contain any of the following strings: '_int' or 'int\_' +or '\_int\_'. + +R-48067 A VNF's Heat Orchestration Template's {vm-type} **MUST NOT** be a +substring of {network-role}. + +R-32394 A VNF’s Heat Orchestration Template’s use of ‘{vm-type}’ +in all Resource property parameter names **MUST** be the same case. + +R-46839 A VNF’s Heat Orchestration Template’s use of +‘{vm-type}’ in all Resource IDs **MUST** be the same case. + +R-36687 A VNF’s Heat Orchestration Template’s ‘{vm-type}’ case in +Resource property parameter names **SHOULD** match the case of +‘{vm-type}’ in Resource IDs and vice versa. + +R-21330 A VNF’s Heat Orchestration Template’s Resource property parameter +that is associated with external network **MUST** include the +‘{network-role}’’ as part of the parameter name + +R-11168 A VNF's Heat Orchestration Template's Resource ID that is +associated with an external network **MUST** include the +'{network-role}' as part of the resource ID. + +R-84322 A VNF's Heat Orchestration Template's Resource property +parameter that is associated with an internal network +**MUST** include 'int\_{network-role}' as part of the parameter +name, where 'int\_' is a hard coded string. + +R-96983 A VNF's Heat Orchestration Template's Resource ID that is +associated with an internal network **MUST** include +'int\_{network-role}' as part of the Resource ID, where +'int\_' is a hard coded string. + +R-26506 A VNF's Heat Orchestration Template's '{network-role}' +**MUST** contain only alphanumeric characters and/or +underscores '_' and **MUST NOT** contain any of the following +strings: '_int' or 'int\_' or '\_int\_'. + +R-00977 A VNF’s Heat Orchestration Template’s ‘{network-role}’ +**MUST NOT** be a substring of ‘{vm-type}’. + +R-58424 A VNF’s Heat Orchestration Template’s use of ‘{network-role}’ +in all Resource property parameter names **MUST** be the same case + +R-21511 A VNF’s Heat Orchestration Template’s use of ‘{network-role}’ +in all Resource IDs **MUST** be the same case. + +R-86588 A VNF’s Heat Orchestration Template’s ‘{network-role}’ case +in Resource property parameter names **SHOULD** match the case +of ‘{network-role}’ in Resource IDs and vice versa. + +R-54517 When a VNF’s Heat Orchestration Template’s resource is associated +with a single ‘{vm-type}’, the Resource ID **MUST** contain the ‘{vm-type}’. + +R-96482 When a VNF’s Heat Orchestration Template’s resource is associated +with a single external network, the Resource ID MUST contain the text +‘{network-role}’. + +R-98138 When a VNF’s Heat Orchestration Template’s resource is associated +with a single internal network, the Resource ID MUST contain the text +‘int\_{network-role}’. + +R-82115 When a VNF's Heat Orchestration Template's resource is associated +with a single '{vm-type}' and a single external network, the Resource +ID text **MUST** contain both the '{vm-type}' and the '{network-role}' + +- the '{vm-type}' **MUST** appear before the '{network-role}' and **MUST** + be separated by an underscore '_' + + - e.g., '{vm-type}_{network-role}', '{vm-type}_{index}_{network-role}' + +- note that an '{index}' value **MAY** separate the '{vm-type}' and the + '{network-role}' and when this occurs underscores **MUST** separate the + three values. + +R-82551 When a VNF's Heat Orchestration Template's resource is associated +with a single '{vm-type}' and a single internal network, the Resource ID +**MUST** contain both the '{vm-type}' and the 'int\_{network-role}' and + +- the '{vm-type}' **MUST** appear before the 'int\_{network-role}' and + **MUST** be separated by an underscore '_' + + - (e.g., '{vm-type}\_int\_{network-role}', + '{vm-type}_{index}\_int\_{network-role}') + +- note that an '{index}' value **MAY** separate the '{vm-type}' and the + 'int\_{network-role}' and when this occurs underscores **MUST** separate + the three values. + +R-67793 When a VNF’s Heat Orchestration Template’s resource is associated +with more than one ‘{vm-type}’ and/or more than one internal and/or +external network, the Resource ID **MUST NOT** contain the ‘{vm-type}’ +and/or ‘{network-role}’/’int\_{network-role}’. It also should contain the +term ‘shared’ and/or contain text that identifies the VNF + +R-27970 When a VNF’s Heat Orchestration Template’s resource is associated +with more than one ‘{vm-type}’ and/or more than one internal and/or +external network, the Resource ID **MAY** contain the term ‘shared’ +and/or **MAY** contain text that identifies the VNF. + +R-11690 When a VNF’s Heat Orchestration Template’s Resource ID contains +an {index} value (e.g. multiple VMs of same {vm-type}), the ‘{index}’ +**MUST** start at zero and increment by one. + +R-71152 The VNF’s Heat Orchestration Template’s Resource +‘OS::Nova::Server’ property ‘image’ parameter **MUST** be declared as +type: ‘string’. + +R-58670 The VNF’s Heat Orchestration Template’s Resource +‘OS::Nova::Server’ property ‘image’ parameter name **MUST** follow the +naming convention ‘{vm-type}_image_name’. + +R-91125 The VNF’s Heat Orchestration Template’s Resource +‘OS::Nova::Server’ property ‘image’ parameter **MUST** be enumerated in +the Heat Orchestration Template’s Environment File and a value **MUST** be +assigned. + +R-57282 Each VNF’s Heat Orchestration Template’s ‘{vm-type}’ +**MUST** have a unique parameter name for the ‘OS::Nova::Server’ +property ‘image’ even if more than one {vm-type} shares the same image. + +R-50436 The VNF’s Heat Orchestration Template’s Resource +‘OS::Nova::Server’ property ‘flavor’ parameter **MUST** be declared as +type: ‘string’. + +R-45188 The VNF’s Heat Orchestration Template’s Resource +‘OS::Nova::Server’ property ‘flavor’ parameter name **MUST** follow the +naming convention ‘{vm-type}_flavor_name’. + +R-69431 The VNF’s Heat Orchestration Template’s Resource +‘OS::Nova::Server’ property ‘flavor’ parameter **MUST** be enumerated in the +Heat Orchestration Template’s Environment File and a value **MUST** be +assigned. + +R-40499 Each VNF’s Heat Orchestration Template’s ‘{vm-type}’ **MUST** +have a unique parameter name for the ‘OS::Nova::Server’ property +‘flavor’ even if more than one {vm-type} shares the same flavor. + +R-51430 The VNF’s Heat Orchestration Template’s Resource +‘OS::Nova::Server’ property ‘name’ parameter **MUST** be declared as +either type ‘string’ or type ‘comma_delimited_list”. + +R-54171 When the VNF’s Heat Orchestration Template’s Resource +‘OS::Nova::Server’ property ‘name’ parameter is defined as a ‘string’, +the parameter name **MUST** follow the naming convention +‘{vm-type}\_name\_{index}’, where {index} is a numeric value that starts +at zero and increments by one. + +R-40899 When the VNF’s Heat Orchestration Template’s Resource +‘OS::Nova::Server’ property ‘name’ parameter is defined as a ‘string’, +a parameter **MUST** be declared for each ‘OS::Nova::Server’ resource +associated with the ‘{vm-type}’. + +R-87817 When the VNF’s Heat Orchestration Template’s Resource +‘OS::Nova::Server’ property ‘name’ parameter is defined as a +‘comma_delimited_list’, the parameter name **MUST** follow the naming +convention ‘{vm-type}_names’. + +R-85800 When the VNF’s Heat Orchestration Template’s Resource +‘OS::Nova::Server’ property ‘name’ parameter is defined as a +‘comma_delimited_list’, a parameter **MUST** be delcared once for all +‘OS::Nova::Server’ resources associated with the ‘{vm-type}’. + +R-22838 The VNF’s Heat Orchestration Template’s Resource +‘OS::Nova::Server’ property ‘name’ parameter **MUST NOT** be enumerated +in the Heat Orchestration Template’s Environment File. + +R-44271 The VNF's Heat Orchestration Template's Resource +'OS::Nova::Server' property 'name' parameter value **SHOULD NOT** +contain special characters since the Contrail GUI has a limitation +displaying special characters. + +R-98450 The VNF’s Heat Orchestration Template’s Resource +‘OS::Nova::Server’ property ‘availability_zone’ parameter name +**MUST** follow the naming convention ‘availability\_zone\_{index}’ +where the ‘{index}’ **MUST** start at zero and increment by one. + +R-23311 The VNF’s Heat Orchestration Template’s Resource +‘OS::Nova::Server’ property ‘availability_zone’ parameter **MUST** +be declared as type: ‘string’. + +R-59568 The VNF’s Heat Orchestration Template’s Resource +‘OS::Nova::Server’ property ‘availability_zone’ parameter **MUST NOT** +be enumerated in the Heat Orchestration Template’s Environment File. + +R-01359 A VNF’s Heat Orchstration Template that contains an +‘OS::Nova:Server’ Resource **MAY** define a parameter for the property +‘availability_zone’ that is not utilized in any ‘OS::Nova::Server’ +resources in the Heat Orchestration Template. + +R-99798 A VNF’s Heat Orchestration Template’s Virtual Machine +(i.e., OS::Nova::Server Resource) **MAY** boot from an image or **MAY** +boot from a Cinder Volume. + +R-83706 When a VNF’s Heat Orchestration Template’s Virtual Machine +(i.e., ‘OS::Nova::Server’ Resource) boots from an image, the +‘OS::Nova::Server’ resource property ‘image’ **MUST** be used. + +R-69588 When a VNF’s Heat Orchestration Template’s Virtual Machine +(i.e., ‘OS::Nova::Server’ Resource) boots from Cinder Volume, the +‘OS::Nova::Server’ resource property ‘block_device_mapping’ or +‘block_device_mapping_v2’ **MUST** be used. + +R-37437 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource **MUST** contain the metadata map value parameter ‘vnf_id’. + +R-07507 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vnf_id’ **MUST** be declared +as type: ‘string’. + +R-55218 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vnf_id’ **MUST NOT** have +parameter contraints defined. + +R-20856 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vnf_id’ **MUST NOT** be +enumerated in the Heat Orchestration Template’s environment file. + +R-44491 If a VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vnf_id’ is passed into a +Nested YAML file, the parameter name ‘vnf_id’ **MUST NOT** change. + +R-71493 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource **MUST** contain the metadata map value parameter +‘vf\_module\_id’. + +R-82134 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vf\_module\_id’ **MUST** +be declared as type: ‘string’. + +R-98374 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vf\_module\_id’ **MUST NOT** +have parameter contraints defined. + +R-72871 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vf\_module\_id’ **MUST NOT** +be enumerated in the Heat Orchestration Template’s environment file. + +R-86237 If a VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vf_module_id’ is passed +into a Nested YAML file, the parameter name ‘vf\_module\_id’ +**MUST NOT** change. + +R-72483 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource **MUST** contain the metadata map value parameter +‘vnf_name’. + +R-62428 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vnf_name’ **MUST** be +declared as type: ‘string’. + +R-44318 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vnf_name’ **MUST NOT** have +parameter contraints defined. + +R-36542 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vnf_name’ **MUST NOT** be +enumerated in the Heat Orchestration Template’s environment file. + +R-16576 If a VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vnf_name’ is passed into a +Nested YAML file, the parameter name ‘vnf_name’ **MUST NOT** change. + +R-68023 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource **SHOULD** contain the metadata map value parameter +‘vf\_module\_name’. + +R-39067 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vf\_module\_name’ **MUST** +be declared as type: ‘string’. + +R-15480 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vf\_module\_name’ +**MUST NOT** have parameter contraints defined. + +R-80374 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vf\_module\_name’ +**MUST NOT** be enumerated in the Heat Orchestration Template’s +environment file. + +R-49177 If a VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vf\_module\_name’ is passed +into a Nested YAML file, the parameter name ‘vf\_module\_name’ +**MUST NOT** change. + +R-85328 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource **MAY** contain the metadata map value parameter ‘vm_role’. + +R-95430 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vm_role’ **MUST** be +declared as type: ‘string’. + +R-67597 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vm_role’ **MUST NOT** have +parameter contraints defined. + +R-46823 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vnf_name’ **MUST** be +either + + - enumerated in the VNF’s Heat Orchestration + Template’s environment file. + + - hard coded in the VNF’s Heat Orchestration + Template’s OS::Nova::Resource metadata property. + +R-86476 If a VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vm_role’ value **MUST only** +contain alphanumeric characters and underscores ‘_’. + +R-70757 If a VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vm_role’ is passed into a +Nested YAML file, the parameter name ‘vm_role’ **MUST NOT** change. + +R-50816 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource **MAY** contain the metadata map value parameter +‘vf\_module\_index’. + +R-54340 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vf\_module\_index’ **MUST** be +declared as type: ‘number’. + +R-09811 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vf\_module\_index’ **MUST NOT** +have parameter contraints defined. + +R-37039 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vf\_module\_index’ **MUST NOT** +be enumerated in the Heat Orchestration Template’s environment file. + +R-22441 If a VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vf\_module\_index’ is passed +into a Nested YAML file, the parameter name ‘vf\_module\_index’ +**MUST NOT** change. + +R-55306 If a VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘vf\_module\_index’ **MUST NOT** be +used in a VNF’s Volume Template; it is not supported. + +R-47061 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource **SHOULD** contain the metadata map value parameter +‘workload_context’. + +R-74978 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘workload_context’ **MUST** be +declared as type: ‘string’. + +R-34055 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘workload_context’ **MUST NOT** +have parameter contraints defined. + +R-02691 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘workload_context’ **MUST NOT** +be enumerated in the Heat Orchestration Template’s environment file. + +R-75202 If a VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘workload_context’ is passed +into a Nested YAML file, the parameter name ‘workload_context’ +**MUST NOT** change. + +R-88536 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource **SHOULD** contain the metadata map value parameter +‘environment_context’. + +R-20308 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘environment_context’ **MUST** +be declared as type: ‘string’. + +R-56183 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘environment_context’ **MUST NOT** +have parameter contraints defined. + +R-13194 A VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘environment_context’ **MUST NOT** +be enumerated in the Heat Orchestration Template’s environment file. + +R-62954 If a VNF’s Heat Orchestration Template’s OS::Nova::Server +Resource metadata map value parameter ‘environment_context’ is +passed into a Nested YAML file, the parameter name +‘environment_context’ **MUST NOT** change. + +R-18008 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ +property ‘network’ parameter **MUST** be declared as type: ‘string’. + +R-62983 When the VNF’s Heat Orchestration Template’s +Resource ‘OS::Neutron::Port’ is attaching to an external +network, the ‘network’ parameter name **MUST** + +- follow the naming convention ‘{network-role}_net_id’ if the Neutron + network UUID value is used to reference the network +- follow the naming convention ‘{network-role}_net_name’ if the OpenStack + network name is used to reference the network. + +where ‘{network-role}’ is the network-role of the external network and +a ‘get_param’ **MUST** be used as the intrinsic function. + +R-86182 When the VNF’s Heat Orchestration Template’s +Resource ‘OS::Neutron::Port’ is attaching to an internal +network, and the internal network is created in a different +Heat Orchestration Template than the ‘OS::Neutron::Port’, the +‘network’ parameter name **MUST** + +- follow the naming convention ‘int\_{network-role}_net_id’ if the Neutron + network UUID value is used to reference the network +- follow the naming convention ‘int\_{network-role}_net_name’ if the + OpenStack network name in is used to reference the network. + +where ‘{network-role}’ is the network-role of the internal network +and a ‘get_param’ **MUST** be used as the intrinsic function. + +R-93177 When the VNF’s Heat Orchestration Template’s Resource +‘OS::Neutron::Port’ is attaching to an internal network, and +the internal network is created in the same Heat +Orchestration Template than the ‘OS::Neutron::Port’, the ‘network’ +parameter name **MUST** obtain the UUID of the internal network by using +the intrinsic function ‘get_resource’ or ‘get_attr’ and referencing the +Resource ID of the internal network. + +R-29872 The VNF’s Heat Orchestration Template’s Resource ‘OS::Nova::Server’ +property ‘network’ parameter **MUST NOT** be enumerated in the Heat +Orchestration Template’s Environment File. + +R-34037 The VNF’s Heat Orchestration Template’s resource ‘OS::Neutron::Port’ +property ‘fixed_ips’ map property ‘ip_address’ parameter **MUST** be +declared as either type ‘string’ or type ‘comma_delimited_list’. + +R-40971 When the VNF’s Heat Orchestration Template’s Resource +‘OS::Neutron::Port’ is attaching to an external network, and an +IPv4 address is assigned using the property +‘fixed_ips’ map property ‘ip_address’ and the parameter type is defined +as a string, the parameter name **MUST** follow the naming +convention ‘{vm-type}_{network-role}\_ip\_{index}’, where + +- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server +- ‘{network-role}’ is the {network-role} of the external network +- the value for {index} must start at zero (0) and increment by one + +R-39841 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ +property ‘fixed_ips’ map property ‘ip_address’ parameter +‘{vm-type}_{network-role}\_ip\_{index}’ **MUST NOT** be enumerated in the +VNF’s Heat Orchestration Template’s Environment File. + +R-04697 When the VNF’s Heat Orchestration Template’s +Resource ‘OS::Neutron::Port’ is attaching to an external +network, and an IPv4 address is assigned using the property +‘fixed_ips’ map property ‘ip_address’ and the parameter type +is defined as a comma_delimited_list, the parameter name **MUST** +follow the naming convention ‘{vm-type}_{network-role}_ips’, where + +- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server +- ‘{network-role}’ is the {network-role} of the external network + +R-98905 The VNF’s Heat Orchestration Template’s Resource ‘OS::Neutron::Port’ +property ‘fixed_ips’ map property ‘ip_address’ parameter +‘{vm-type}_{network-role}_ips’ **MUST NOT** be enumerated in the VNF’s +Heat Orchestration Template’s Environment File. + +R-71577 When the VNF’s Heat Orchestration Template’s Resource +‘OS::Neutron::Port’ is attaching to an external network, and an IPv6 address +is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and +the parameter type is defined as a string, the parameter name **MUST** follow +the naming convention ‘{vm-type}_{network-role}\_v6\_ip\_{index}’, where + +- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server +- ‘{network-role}’ is the {network-role} of the external network +- the value for {index} must start at zero (0) and increment by one + +R-87123 The VNF’s Heat Orchestration Template’s Resource +‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’ +parameter ‘{vm-type}_{network-role}\_v6\_ip\_{index}’ +**MUST NOT** be enumerated in the VNF’s Heat Orchestration +Template’s Environment File. + +R-23503 When the VNF’s Heat Orchestration Template’s Resource +‘OS::Neutron::Port’ is attaching to an external network, and an IPv6 +address is assigned using the property ‘fixed_ips’ map property ‘ip_address’ +and the parameter type is defined as a comma_delimited_list, the parameter +name **MUST** follow the naming convention +‘{vm-type}_{network-role}_v6_ips’, where + +- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server +- ‘{network-role}’ is the {network-role} of the external network + +R-93030 The VNF’s Heat Orchestration Template’s Resource +‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’ +parameter ‘{vm-type}_{network-role}_v6_ips’ **MUST NOT** be enumerated in the +VNF’s Heat Orchestration Template’s Environment File. + +R-78380 When the VNF’s Heat Orchestration Template’s Resource +‘OS::Neutron::Port’ is attaching to an internal network, and an IPv4 address +is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and +the parameter type is defined as a string, the parameter name **MUST** follow +the naming convention ‘{vm-type}\_int\_{network-role}\_ip\_{index}’, where + +- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server +- ‘{network-role}’ is the {network-role} of the internal network +- the value for {index} must start at zero (0) and increment by one + +R-28795 The VNF’s Heat Orchestration Template’s Resource +‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’ +parameter ‘{vm-type}\_int\_{network-role}\_ip\_{index}’ **MUST** be enumerated +in the VNF’s Heat Orchestration Template’s Environment File. + +R-85235 When the VNF’s Heat Orchestration Template’s Resource +‘OS::Neutron::Port’ is attaching to an internal network, and an IPv4 +address is assigned using the property ‘fixed_ips’ map property ‘ip_address’ +and the parameter type is defined as a comma_delimited_list, the parameter +name **MUST** follow the naming convention +‘{vm-type}\_int\_{network-role}_ips’, where + +- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server +- ‘{network-role}’ is the {network-role} of the internal network + +R-90206 The VNF’s Heat Orchestration Template’s Resource +‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’ +parameter ‘{vm-type}\_int\_{network-role}_int_ips’ **MUST** be enumerated in +the VNF’s Heat Orchestration Template’s Environment File. + +R-27818 When the VNF’s Heat Orchestration Template’s Resource +‘OS::Neutron::Port’ is attaching to an internal network, and an IPv6 address +is assigned using the property ‘fixed_ips’ map property ‘ip_address’ and +the parameter type is defined as a string, the parameter name **MUST** follow +the naming convention ‘{vm-type}\_int\_{network-role}\_v6\_ip\_{index}’, where + +- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server +- ‘{network-role}’ is the {network-role} of the internal network +- the value for {index} must start at zero (0) and increment by one + +R-97201 The VNF’s Heat Orchestration Template’s Resource +‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’ +parameter ‘{vm-type}\_int\_{network-role}\_v6\_ip\_{index}’ +**MUST** be enumerated in the VNF’s Heat Orchestration Template’s +Environment File. + +R-29765 When the VNF’s Heat Orchestration Template’s Resource +‘OS::Neutron::Port’ is attaching to an internal network, and an IPv6 +address is assigned using the property ‘fixed_ips’ map property ‘ip_address’ +and the parameter type is defined as a comma_delimited_list, the parameter +name **MUST** follow the naming convention +‘{vm-type}\_int\_{network-role}_v6_ips’, where + +- ‘{vm-type}’ is the {vm-type} associated with the OS::Nova::Server +- ‘{network-role}’ is the {network-role} of the internal network + +R-98569 The VNF’s Heat Orchestration Template’s Resource +‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’ +parameter ‘{vm-type}\_int\_{network-role}_v6_ips’ **MUST** be enumerated in +the VNF’s Heat Orchestration Template’s Environment File. + +R-62590 The VNF’s Heat Orchestration Template’s Resource +‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’ +parameter associated with an external network, i.e., + +- {vm-type}_{network-role}\_ip\_{index} +- {vm-type}_{network-role}\_ip\_v6\_{index} +- {vm-type}_{network-role}_ips +- {vm-type}_{network-role}_v6_ips + +**MUST NOT** be enumerated in the Heat Orchestration Template’s +Environment File. ONAP provides the IP address assignments at +orchestration time. + +R-93496 The VNF’s Heat Orchestration Template’s Resource +‘OS::Neutron::Port’ property ‘fixed_ips’ map property ‘ip_address’ +parameter associated with an internal network, i.e., + +- {vm-type}\_int\_{network-role}\_ip\_{index} +- {vm-type}\_int\_{network-role}\_ip\_v6\_{index} +- {vm-type}\_int\_{network-role}_ips +- {vm-type}\_int\_{network-role}_v6_ips + +**MUST** be enumerated in the Heat Orchestration Template’s Environment +File and IP addresses **MUST** be assigned. + +R-38236 The VNF’s Heat Orchestration Template’s resource +‘OS::Neutron::Port’ property ‘fixed_ips’ map property +‘subnet’/’subnet_id’ parameter **MUST** be declared type ‘string’. + +R-62802 When the VNF’s Heat Orchestration Template’s resource +‘OS::Neutron::Port’ is attaching to an external network, and an IPv4 +address is being Cloud Assigned by OpenStack’s DHCP Service and the +external network IPv4 subnet is to be specified using the property +‘fixed_ips’ map property ‘subnet’/’subnet_id’, the parameter **MUST** +follow the naming convention ‘{network-role}_subnet_id’, where +‘{network-role}’ is the network role of the network. + +R-83677 The VNF’s Heat Orchestration Template’s Resource +‘OS::Neutron::Port’ property ‘fixed_ips’ map property +subnet’/’subnet_id’ parameter ‘{network-role}_subnet_id’ +**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s +Environment File. + +R-15287 When the VNF’s Heat Orchestration Template’s resource +‘OS::Neutron::Port’ is attaching to an external network, and an IPv6 +address is being Cloud Assigned by OpenStack’s DHCP Service and the +external network IPv6 subnet is to be specified using the property +‘fixed_ips’ map property ‘subnet’/’subnet_id’, the parameter **MUST** +follow the naming convention ‘{network-role}_subnet_v6_id’, where +‘{network-role}’ is the network role of the network. + +R-80829 The VNF’s Heat Orchestration Template’s Resource +‘OS::Neutron::Port’ property ‘fixed_ips’ map property +subnet’/’subnet_id’ parameter ‘{network-role}_subnet_v6_id’ +**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s +Environment File. + +R-84123 When + +- the VNF’s Heat Orchestration Template’s resource ‘OS::Neutron::Port’ + in an Incremental Module is attaching to an internal network + that is created in the Base Module, AND +- an IPv4 address is being Cloud Assigned by OpenStack’s DHCP Service AND +- the internal network IPv4 subnet is to be specified using the + property ‘fixed_ips’ map property ‘subnet’/’subnet_id’, + +the parameter **MUST** follow the naming convention +‘int\_{network-role}_subnet_id’, where ‘{network-role}’ is the +network role of the internal network + +- Note that the parameter **MUST** be defined as an ‘output’ parameter in + the base module. + +R-69634 The VNF’s Heat Orchestration Template’s Resource +‘OS::Neutron::Port’ property ‘fixed_ips’ map property +subnet’/’subnet_id’ parameter ‘int\_{network-role}_subnet_id’ +**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s +Environment File. + +R-76160 When + +- the VNF’s Heat Orchestration Template’s resource + ‘OS::Neutron::Port’ in an Incremental Module is attaching to an + internal network that is created in the Base Module, AND +- an IPv6 address is being Cloud Assigned by OpenStack’s DHCP Service AND +- the internal network IPv6 subnet is to be specified using the property + ‘fixed_ips’ map property ‘subnet’/’subnet_id’, + +the parameter **MUST** follow the naming convention +‘int\_{network-role}_v6_subnet_id’, where ‘{network-role}’ +is the network role of the internal network + +- Note that the parameter **MUST** be defined as an ‘output’ parameter in + the base module. + +R-22288 The VNF’s Heat Orchestration Template’s Resource +‘OS::Neutron::Port’ property ‘fixed_ips’ map property +‘subnet’/’subnet_id’ parameter ‘int\_{network-role}_v6_subnet_id’ +**MUST NOT** be enumerated in the VNF’s Heat Orchestration Template’s +Environment File. + +R-61282 The VNF Heat Orchestration Template **MUST** +adhere to the following naming convention for the property +allowed\_address\_pairs and Map Property ip\_address parameter, +when the parameter is referencing an “external” network: + +- {vm-type}\_{network-role}\_floating\_ip for an IPv4 address + +- {vm-type}\_{network-role}\_floating\_v6\_ip for an IPv6 address + +R-16805 The VNF Heat Orchestration Template **MUST** adhere to the +following naming convention for the property allowed\_address\_pairs +and Map Property ip\_address parameter when the parameter is +referencing an “internal” network. + +R-85734 The VNF Heat Orchestration Template **MUST** use the +intrinsic function str\_replace in conjunction with the ONAP +supplied metadata parameter vnf\_name to generate a unique value, +when the property name for a non OS::Nova::Server resources is defined +in a Heat Orchestration Template. + +R-47788 The VNF Heat Orchestration Template **MUST** have a 1:1 +scope of a cinder volume module, when it exists, with the Base +Module or Incremental Module + +R-86285 The VNF Heat Orchestration Template **MUST** have a corresponding +environment file, even if no parameters are required to be enumerated. + +R-86285 The VNF Heat Orchestration Template **MUST** have a +corresponding environment file, even if no parameters are required to be +enumerated. + +R-67205 The VNF Heat Orchestration Template **MUST** have a corresponding +environment file for a Base Module. + +R-35727 The VNF Heat Orchestration Template **MUST** have a +corresponding environment file for an Incremental module. + +R-22656 The VNF Heat Orchestration Template **MUST** have a +corresponding environment file for a Cinder Volume Module. + +R-89868 The VNF Heat Orchestration Template **MUST** have unique +file names within the scope of the VNF for a nested heat yaml file. + +R-52530 The VNF Heat Orchestration Template **MUST NOT** use a +directory hierarchy for nested templates. All templates must be +in a single, flat directory (per VNF). + +R-76718 The VNF Heat Orchestration Template **MUST** reference the +get\_files targets in Heat templates by file name, and the corresponding +files should be delivered to ONAP along with the Heat templates. + +R-41888 The VNE Heat **MUST NOT** use URL-based file retrieval. + +R-62177 The VNF Heat Orchestration Template **MUST** have unique +file names for the included files within the scope of the VNF. + +**ONAP Management Requirements** +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + + +VNF On-boarding and package management +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + + +R-77707 The xNF provider **MUST** include a Manifest File that +contains a list of all the components in the xNF package. + +R-66070 The xNF Package **MUST** include xNF Identification Data to +uniquely identify the resource for a given xNF provider. The identification +data must include: an identifier for the xNF, the name of the xNF as was +given by the xNF provider, xNF description, xNF provider, and version. + +R-69565 The xNF Package **MUST** include documentation describing xNF +Management APIs, which must include information and tools for ONAP to +deploy and configure (initially and ongoing) the xNF application(s) +(e.g., NETCONF APIs) which includes a description of configurable +parameters for the xNF and whether the parameters can be configured +after xNF instantiation. + +R-00156 The xNF Package **MUST** include documentation describing xNF +Management APIs, which must include information and tools for ONAP +to monitor the health of the xNF (conditions that require healing +and/or scaling responses). + +R-00068 The xNF Package **MUST** include documentation which includes +a description of parameters that can be monitored for the xNF and +event records (status, fault, flow, session, call, control plane, +etc.) generated by the xNF after instantiation. + +R-12678 The xNF Package **MUST** include documentation which includes a +description of runtime lifecycle events and related actions (e.g., +control responses, tests) which can be performed for the xNF. + +R-84366 The xNF Package **MUST** include documentation describing +xNF Functional APIs that are utilized to build network and +application services. This document describes the externally exposed +functional inputs and outputs for the xNF, including interface +format and protocols supported. + +R-36280 The xNF provider **MUST** provide documentation describing +xNF Functional Capabilities that are utilized to operationalize the +xNF and compose complex services. + +R-98617 The xNF provider **MUST** provide information regarding any +dependency (e.g., affinity, anti-affinity) with other xNFs and resources. + +R-89571 The xNF **MUST** support and provide artifacts for configuration +management using at least one of the following technologies; +a) Netconf/YANG, b) Chef, or c) Ansible. + +R-30278 The xNF provider **MUST** provide a Resource/Device YANG model +as a foundation for creating the YANG model for configuration. This will +include xNF attributes/parameters and valid values/attributes configurable +by policy. + +R-13390 The xNF provider **MUST** provide cookbooks to be loaded +on the appropriate Chef Server. + +R-18525 The xNF provider **MUST** provide a JSON file for each +supported action for the xNF. The JSON file must contain key value +pairs with all relevant values populated with sample data that illustrates +its usage. The fields and their description are defined in Tables A1 +and A2 in the Appendix. + +R-75608 The xNF provider **MUST** provide playbooks to be loaded +on the appropriate Ansible Server. + +R-16777 The xNF provider **MUST** provide a JSON file for each +supported action for the xNF. The JSON file must contain key value +pairs with all relevant values populated with sample data that illustrates +its usage. The fields and their description are defined in Table B1 in +the Appendix. + +R-46567 The xNF Package **MUST** include configuration scripts +for boot sequence and configuration. + +R-16065 The xNF provider **MUST** provide configurable parameters +(if unable to conform to YANG model) including xNF attributes/parameters +and valid values, dynamic attributes and cross parameter dependencies +(e.g., customer provisioning data). + +R-22888 The xNF provider **MUST** provide documentation for the xNF +Policy Description to manage the xNF runtime lifecycle. The document +must include a description of how the policies (conditions and actions) +are implemented in the xNF. + +R-01556 The xNF Package **MUST** include documentation describing the +fault, performance, capacity events/alarms and other event records +that are made available by the xNF. + +R-16875 The xNF Package **MUST** include documentation which must include +a unique identification string for the specific xNF, a description of +the problem that caused the error, and steps or procedures to perform +Root Cause Analysis and resolve the issue. + +R-35960 The xNF Package **MUST** include documentation which must include +all events, severity level (e.g., informational, warning, error) and +descriptions including causes/fixes if applicable for the event. + +R-42018 The xNF Package **MUST** include documentation which must include +all events (fault, measurement for xNF Scaling, Syslogs, State Change +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. + +R-27711 The xNF provider **MUST** provide an XML file that contains a +list of xNF error codes, descriptions of the error, and possible +causes/corrective action. + +R-01478 The xNF Package **MUST** include documentation describing all +parameters that are available to monitor the xNF after instantiation +(includes all counters, OIDs, PM data, KPIs, etc.) that must be +collected for reporting purposes. + +R-73560 The xNF Package **MUST** include documentation about monitoring +parameters/counters exposed for virtual resource management and xNF +application management. + +R-90632 The xNF Package **MUST** include documentation about KPIs and +metrics that need to be collected at each VM for capacity planning +and performance management purposes. + +R-86235 The xNF Package **MUST** include documentation about the monitoring +parameters that must include latencies, success rates, retry rates, load +and quality (e.g., DPM) for the key transactions/functions supported by +the xNF and those that must be exercised by the xNF in order to perform +its function. + +R-33904 The xNF Package **MUST** include documentation for each KPI, provide +lower and upper limits. + +R-53598 The xNF Package **MUST** include documentation to, when relevant, +provide a threshold crossing alert point for each KPI and describe the +significance of the threshold crossing. + +R-69877 The xNF Package **MUST** include documentation for each KPI, +identify the suggested actions that need to be performed when a +threshold crossing alert event is recorded. + +R-22680 The xNF Package **MUST** include documentation that describes +any requirements for the monitoring component of tools for Network +Cloud automation and management to provide these records to components +of the xNF. + +R-33694 The xNF Package **MUST** include documentation to when applicable, +provide calculators needed to convert raw data into appropriate reporting +artifacts. + +R-56815 The xNF Package **MUST** include documentation describing +supported xNF scaling capabilities and capacity limits (e.g., number +of users, bandwidth, throughput, concurrent calls). + +R-48596 The xNF Package **MUST** include documentation describing +the characteristics for the xNF reliability and high availability. + +R-74763 The xNF provider **MUST** provide an artifact per xNF that contains +all of the xNF Event Records supported. The artifact should include reference +to the specific release of the xNF Event Stream Common Event Data Model +document it is based on. (e.g., `VES Event Listener <https://github.com/att/evel-test-collector/tree/master/docs/att_interface_definition>`__) + +R-35851 The xNF Package **MUST** include xNF topology that describes +basic network and application connectivity internal and external to the +xNF including Link type, KPIs, Bandwidth, latency, jitter, QoS (if +applicable) for each interface. + +R-97102 The VNF Package **MUST** include VM requirements via a Heat +template that provides the necessary data for VM specifications +for all VNF components - for hypervisor, CPU, memory, storage. + +R-20204 The VNF Package **MUST** include VM requirements via a Heat +template that provides the necessary data for network connections, +interface connections, internal and external to VNF. + +R-44896 The VNF Package **MUST** include VM requirements via a Heat +template that provides the necessary data for high availability +redundancy model. + +R-55802 The VNF Package **MUST** include VM requirements via a Heat +template that provides the necessary data for scaling/growth VM +specifications. + +R-26881 The xNF provider **MUST** provide the binaries and images +needed to instantiate the xNF (xNF and VNFC images). + +R-96634 The xNF provider **MUST** describe scaling capabilities +to manage scaling characteristics of the xNF. + +R-43958 The xNF Package **MUST** include documentation describing +the tests that were conducted by the xNF providor and the test results. + +R-04298 The xNF provider **MUST** provide their testing scripts to +support testing. + +R-58775 The xNF provider **MUST** provide software components that +can be packaged with/near the xNF, if needed, to simulate any functions +or systems that connect to the xNF system under test. This component is +necessary only if the existing testing environment does not have the +necessary simulators. + +R-85653 The xNF **MUST** provide metrics (e.g., number of sessions, +number of subscribers, number of seats, etc.) to ONAP for tracking +every license. + +R-44125 The xNF provider **MUST** agree to the process that can +be met by Service Provider reporting infrastructure. The Contract +shall define the reporting process and the available reporting tools. + +R-40827 The xNF provider **MUST** enumerate all of the open +source licenses their xNF(s) incorporate. + +R-97293 The xNF provider **MUST NOT** require audits of +Service Provider’s business. + +R-44569 The xNF provider **MUST NOT** require additional +infrastructure such as a xNF provider license server for xNF provider +functions and metrics. + +R-13613 The VNF **MUST** provide clear measurements for licensing +purposes to allow automated scale up/down by the management system. + +R-27511 The VNF provider **MUST** provide the ability to scale +up a VNF provider supplied product during growth and scale down a +VNF provider supplied product during decline without “real-time” +restrictions based upon VNF provider permissions. + +R-85991 The xNF provider **MUST** provide a universal license key +per xNF to be used as needed by services (i.e., not tied to a VM +instance) as the recommended solution. The xNF provider may provide +pools of Unique xNF License Keys, where there is a unique key for +each xNF instance as an alternate solution. Licensing issues should +be resolved without interrupting in-service xNFs. + +R-47849 The xNF provider **MUST** support the metadata about +licenses (and their applicable entitlements) as defined in this +document for xNF software, and any license keys required to authorize +use of the xNF software. This metadata will be used to facilitate +onboarding the xNF into the ONAP environment and automating processes +for putting the licenses into use and managing the full lifecycle of +the licenses. The details of this license model are described in +Tables C1 to C8 in the Appendix. Note: License metadata support in +ONAP is not currently available and planned for 1Q 2018. + +Configuration Management +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +R-20741 The xNF **MUST** support ONAP Controller’s **Configure** command. + +R-19366 The xNF **MUST** support ONAP Controller’s **ConfigModify** command. + +R-32981 The xNF **MUST** support ONAP Controller’s **ConfigBackup** command. + +R-48247 The xNF **MUST** support ONAP Controller’s **ConfigRestore** command. + +R-94084 The xNF **MUST** support ONAP Controller’s **ConfigScaleOut** +command. + +R-56385 The xNF **MUST** support ONAP Controller’s **Audit** command. + +R-12706 The xNF **MUST** support ONAP Controller’s **QuiesceTraffic** +command. + +R-07251 The xNF **MUST** support ONAP Controller’s **ResumeTraffic** +command. + +R-83146 The xNF **MUST** support ONAP Controller’s **StopApplication** +command. + +R-82811 The xNF **MUST** support ONAP Controller’s **StartApplication** +command. + +R-19922 The xNF **MUST** support ONAP Controller’s **UpgradePrecheck** +command. + +R-49466 The xNF **MUST** support ONAP Controller’s **UpgradeSoftware** +command. + +R-45856 The xNF **MUST** support ONAP Controller’s **UpgradePostCheck** +command. + +R-97343 The xNF **MUST** support ONAP Controller’s **UpgradeBackup** +command. + +R-65641 The xNF **MUST** support ONAP Controller’s **UpgradeBackOut** +command. + +R-11790 The VNF **MUST** support ONAP Controller’s +**Restart (stop/start or reboot)** command. + +R-56218 The VNF **MUST** support ONAP Controller’s Migrate command that +moves container (VM) from a live Physical Server / Compute Node to +another live Physical Server / Compute Node. + +R-38001 The VNF MUST support ONAP Controller’s **Rebuild** command. + +R-76901 VNF MUST support a container rebuild mechanism based on existing +image (e.g. Glance image in Openstack environment) or a snapshot. + +R-41430 The xNF **MUST** support ONAP Controller’s **HealthCheck** +command. + +R-88026 The xNF **MUST** include a NETCONF server enabling +runtime configuration and lifecycle management capabilities. + +R-95950 The xNF **MUST** provide a NETCONF interface fully defined +by supplied YANG models for the embedded NETCONF server. + +R-73468 The xNF **MUST** allow the NETCONF server connection +parameters to be configurable during virtual machine instantiation +through Heat templates where SSH keys, usernames, passwords, SSH +service and SSH port numbers are Heat template parameters. + +R-90007 The xNF **MUST** implement the protocol operation: +**close-session()**- Gracefully close the current session. + +R-70496 The xNF **MUST** implement the protocol operation: +**commit(confirmed, confirm-timeout)** - Commit candidate +configuration datastore to the running configuration. + +R-18733 The xNF **MUST** implement the protocol operation: +**discard-changes()** - Revert the candidate configuration +datastore to the running configuration. + +R-44281 The xNF **MUST** implement the protocol operation: +**edit-config(target, default-operation, test-option, error-option, +config)** - Edit the target configuration datastore by merging, +replacing, creating, or deleting new config elements. + +R-60106 The xNF **MUST** implement the protocol operation: +**get(filter)** - Retrieve (a filtered subset of) the running +configuration and device state information. This should include +the list of xNF supported schemas. + +R-29488 The xNF **MUST** implement the protocol operation: +**get-config(source, filter)** - Retrieve a (filtered subset of +a) configuration from the configuration datastore source. + +R-11235 The xNF **MUST** implement the protocol operation: +**kill-session(session)** - Force the termination of **session**. + +R-02597 The xNF **MUST** implement the protocol operation: +**lock(target)** - Lock the configuration datastore target. + +R-96554 The xNF **MUST** implement the protocol operation: +**unlock(target)** - Unlock the configuration datastore target. + +R-29324 The xNF **SHOULD** implement the protocol operation: +**copy-config(target, source) -** Copy the content of the +configuration datastore source to the configuration datastore target. + +R-88031 The xNF **SHOULD** implement the protocol operation: +**delete-config(target) -** Delete the named configuration +datastore target. + +R-97529 The xNF **SHOULD** implement the protocol operation: +**get-schema(identifier, version, format) -** Retrieve the YANG schema. + +R-62468 The xNF **MUST** allow all configuration data to be +edited through a NETCONF <edit-config> operation. Proprietary +NETCONF RPCs that make configuration changes are not sufficient. + +R-01382 The xNF **MUST** allow the entire configuration of the +xNF to be retrieved via NETCONF's <get-config> and <edit-config>, +independently of whether it was configured via NETCONF or other +mechanisms. + +R-28756 The xNF **MUST** support **:partial-lock** and +**:partial-unlock** capabilities, defined in RFC 5717. This +allows multiple independent clients to each write to a different +part of the <running> configuration at the same time. + +R-83873 The xNF **MUST** support **:rollback-on-error** value for +the <error-option> parameter to the <edit-config> operation. If any +error occurs during the requested edit operation, then the target +database (usually the running configuration) will be left unaffected. +This provides an 'all-or-nothing' edit mode for a single <edit-config> +request. + +R-68990 The xNF **MUST** support the **:startup** capability. It +will allow the running configuration to be copied to this special +database. It can also be locked and unlocked. + +R-68200 The xNF **MUST** support the **:url** value to specify +protocol operation source and target parameters. The capability URI +for this feature will indicate which schemes (e.g., file, https, sftp) +that the server supports within a particular URL value. The 'file' +scheme allows for editable local configuration databases. The other +schemes allow for remote storage of configuration databases. + +R-20353 The xNF **MUST** implement both **:candidate** and +**:writable-running** capabilities. When both **:candidate** and +**:writable-running** are provided then two locks should be supported. + +R-11499 The xNF **MUST** fully support the XPath 1.0 specification +for filtered retrieval of configuration and other database contents. +The 'type' attribute within the <filter> parameter for <get> and +<get-config> operations may be set to 'xpath'. The 'select' attribute +(which contains the XPath expression) will also be supported by the +server. A server may support partial XPath retrieval filtering, but +it cannot advertise the **:xpath** capability unless the entire XPath +1.0 specification is supported. + +R-83790 The xNF **MUST** implement the **:validate** capability + +R-49145 The xNF **MUST** implement **:confirmed-commit** If +**:candidate** is supported. + +R-58358 The xNF **MUST** implement the **:with-defaults** capability +[RFC6243]. + +R-59610 The xNF **MUST** implement the data model discovery and +download as defined in [RFC6022]. + +R-93443 The xNF **MUST** define all data models in YANG [RFC6020], +and the mapping to NETCONF shall follow the rules defined in this RFC. + +R-26115 The xNF **MUST** follow the data model upgrade rules defined +in [RFC6020] section 10. All deviations from section 10 rules shall +be handled by a built-in automatic upgrade mechanism. + +R-10716 The xNF **MUST** support parallel and simultaneous +configuration of separate objects within itself. + +R-29495 The xNF **MUST** support locking if a common object is +being manipulated by two simultaneous NETCONF configuration operations +on the same xNF within the context of the same writable running data +store (e.g., if an interface parameter is being configured then it +should be locked out for configuration by a simultaneous configuration +operation on that same interface parameter). + +R-53015 The xNF **MUST** apply locking based on the sequence of +NETCONF operations, with the first configuration operation locking +out all others until completed. + +R-02616 The xNF **MUST** permit locking at the finest granularity +if a xNF needs to lock an object for configuration to avoid blocking +simultaneous configuration operations on unrelated objects (e.g., BGP +configuration should not be locked out if an interface is being +configured or entire Interface configuration should not be locked out +if a non-overlapping parameter on the interface is being configured). + +R-41829 The xNF **MUST** be able to specify the granularity of the +lock via a restricted or full XPath expression. + +R-66793 The xNF **MUST** guarantee the xNF configuration integrity +for all simultaneous configuration operations (e.g., if a change is +attempted to the BUM filter rate from multiple interfaces on the same +EVC, then they need to be sequenced in the xNF without locking either +configuration method out). + +R-54190 The xNF **MUST** release locks to prevent permanent lock-outs +when/if a session applying the lock is terminated (e.g., SSH session +is terminated). + +R-03465 The xNF **MUST** release locks to prevent permanent lock-outs +when the corresponding <partial-unlock> operation succeeds. + +R-63935 The xNF **MUST** release locks to prevent permanent lock-outs +when a user configured timer has expired forcing the NETCONF SSH Session +termination (i.e., product must expose a configuration knob for a user +setting of a lock expiration timer) + +R-10173 The xNF **MUST** allow another NETCONF session to be able to +initiate the release of the lock by killing the session owning the lock, +using the <kill-session> operation to guard against hung NETCONF sessions. + +R-88899 The xNF **MUST** support simultaneous <commit> operations +within the context of this locking requirements framework. + +R-07545 The xNF **MUST** support all operations, administration and +management (OAM) functions available from the supplier for xNFs using +the supplied YANG code and associated NETCONF servers. + +R-60656 The xNF **MUST** support sub tree filtering. + +R-80898 The xNF **MUST** support heartbeat via a <get> with null filter. + +R-25238 The xNF PACKAGE **MUST** validated YANG code using the open +source pyang [2]_ program using the following commands: + +R-63953 The xNF **MUST** have the echo command return a zero value +otherwise the validation has failed + +R-26508 The xNF **MUST** support a NETCONF server that can be mounted on +OpenDaylight (client) and perform the operations of: modify, update, +change, rollback configurations using each configuration data element, +query each state (non-configuration) data element, execute each YANG +RPC, and receive data through each notification statement. + +R-28545 The xNF **MUST** conform its YANG model to RFC 6060, +“YANG - A Data Modeling Language for the Network Configuration +Protocol (NETCONF)” + +R-22700 The xNF **MUST** conform its YANG model to RFC 6470, +“NETCONF Base Notifications”. + +R-10353 The xNF **MUST** conform its YANG model to RFC 6244, +“An Architecture for Network Management Using NETCONF and YANG”. + +R-53317 The xNF **MUST** conform its YANG model to RFC 6087, +“Guidelines for Authors and Reviewers of YANG Data Model Documents”. + +R-33955 The xNF **SHOULD** conform its YANG model to RFC 6991, +“Common YANG Data Types”. + +R-22946 The xNF **SHOULD** conform its YANG model to RFC 6536, +“NETCONF Access Control Model”. + +R-10129 The xNF **SHOULD** conform its YANG model to RFC 7223, +“A YANG Data Model for Interface Management”. + +R-12271 The xNF **SHOULD** conform its YANG model to RFC 7223, +“IANA Interface Type YANG Module”. + +R-49036 The xNF **SHOULD** conform its YANG model to RFC 7277, +“A YANG Data Model for IP Management”. + +R-87564 The xNF **SHOULD** conform its YANG model to RFC 7317, +“A YANG Data Model for System Management”. + +R-24269 The xNF **SHOULD** conform its YANG model to RFC 7407, +“A YANG Data Model for SNMP Configuration”, if Netconf used to +configure SNMP engine. + +R-33946 The xNF **MUST** conform to the NETCONF RFC 4741, +“NETCONF Configuration Protocol”. + +R-04158 The xNF **MUST** conform to the NETCONF RFC 4742, +“Using the NETCONF Configuration Protocol over Secure Shell (SSH)”. + +R-13800 The xNF **MUST** conform to the NETCONF RFC 5277, +“NETCONF Event Notification”. + +R-01334 The xNF **MUST** conform to the NETCONF RFC 5717, +“Partial Lock Remote Procedure Call”. + +R-08134 The xNF **MUST** conform to the NETCONF RFC 6241, +“NETCONF Configuration Protocol”. + +R-78282 The xNF **MUST** conform to the NETCONF RFC 6242, +“Using the Network Configuration Protocol over Secure Shell”. + +R-31809 The xNF **MUST** support the HealthCheck RPC. The HealthCheck +RPC executes a xNF Provider-defined xNF HealthCheck over the scope of +the entire xNF (e.g., if there are multiple VNFCs, then run a health check, +as appropriate, for all VNFCs). It returns a 200 OK if the test completes. +A JSON object is returned indicating state (healthy, unhealthy), scope +identifier, time-stamp and one or more blocks containing info and fault +information. If the xNF is unable to run the HealthCheck, return a +standard http error code and message. + +R-79224 The xNF **MUST** have the chef-client be preloaded with +validator keys and configuration to register with the designated +Chef Server as part of the installation process. + +R-72184 The xNF **MUST** have routable FQDNs for all the endpoints +(VMs) of a xNF that contain chef-clients which are used to register +with the Chef Server. As part of invoking xNF actions, ONAP will +trigger push jobs against FQDNs of endpoints for a xNF, if required. + +R-47068 The xNF **MAY** expose a single endpoint that is +responsible for all functionality. + +R-67114 The xNF **MUST** be installed with Chef-Client >= 12.0 and +Chef push jobs client >= 2.0. + +R-27310 The xNF Package **MUST** include all relevant Chef artifacts +(roles/cookbooks/recipes) required to execute xNF actions requested by +ONAP for loading on appropriate Chef Server. + +R-26567 The xNF Package **MUST** include a run list of +roles/cookbooks/recipes, for each supported xNF action, that will +perform the desired xNF action in its entirety as specified by ONAP +(see Section 7.c, ONAP Controller APIs and Behavior, for list of xNF +actions and requirements), when triggered by a chef-client run list +in JSON file. + +R-98911 The xNF **MUST NOT** use any instance specific parameters +for the xNF in roles/cookbooks/recipes invoked for a xNF action. + +R-37929 The xNF **MUST** accept all necessary instance specific +data from the environment or node object attributes for the xNF +in roles/cookbooks/recipes invoked for a xNF action. + +R-62170 The xNF **MUST** over-ride any default values for +configurable parameters that can be set by ONAP in the roles, +cookbooks and recipes. + +R-78116 The xNF **MUST** update status on the Chef Server +appropriately (e.g., via a fail or raise an exception) if the +chef-client run encounters any critical errors/failures when +executing a xNF action. + +R-44013 The xNF **MUST** populate an attribute, defined as node +[‘PushJobOutput’] with the desired output on all nodes in the push job +that execute chef-client run if the xNF action requires the output of a +chef-client run be made available (e.g., get running configuration). + +R-30654 The xNF Package **MUST** have appropriate cookbooks that are +designed to automatically ‘rollback’ to the original state in case of +any errors for actions that change state of the xNF (e.g., configure). + +R-65755 The xNF **SHOULD** support callback URLs to return information +to ONAP upon completion of the chef-client run for any chef-client run +associated with a xNF action. + +R-15885 The xNF **MUST** Upon completion of the chef-client run, +POST back on the callback URL, a JSON object as described in Table +A2 if the chef-client run list includes a cookbook/recipe that is +callback capable. Failure to POST on the Callback Url should not be +considered a critical error. That is, if the chef-client successfully +completes the xNF action, it should reflect this status on the Chef +Server regardless of whether the Callback succeeded or not. + +R-32217 The xNF **MUST** have routable FQDNs that are reachable via +the Ansible Server for the endpoints (VMs) of a xNF on which playbooks +will be executed. ONAP will initiate requests to the Ansible Server +for invocation of playbooks against these end points [3]_. + +R-54373 The xNF **MUST** have Python >= 2.6 on the endpoint VM(s) +of a xNF on which an Ansible playbook will be executed. + +R-35401 The xNF **MUST** support SSH and allow SSH access by the +Ansible server for the endpoint VM(s) and comply with the Network +Cloud Service Provider guidelines for authentication and access. + +R-82018 The xNF **MUST** load the Ansible Server SSH public key onto xNF +VM(s) as part of instantiation. This will allow the Ansible Server +to authenticate to perform post-instantiation configuration without +manual intervention and without requiring specific xNF login IDs +and passwords. + +R-92866 The xNF **MUST** include as part of post-instantiation configuration +done by Ansible Playbooks the removal/update of the SSH public key from +/root/.ssh/authorized_keys, and update of SSH keys loaded through +instantiation to support Ansible. This may include download and install of +new SSH keys and new mechanized IDs. + +R-91745 The xNF **MUST** update the Ansible Server and other entities +storing and using the SSH keys for authentication when the SSH keys used +by Ansible are regenerated/updated. + +R-40293 The xNF **MUST** make available playbooks that conform +to the ONAP requirement. + +R-49396 The xNF **MUST** support each ONAP (APPC) xNF action by invocation +of **one** playbook [6]_. The playbook will be responsible +for executing all necessary tasks (as well as calling other playbooks) +to complete the request. + +R-33280 The xNF **MUST NOT** use any instance specific parameters +in a playbook. + +R-48698 The xNF **MUST** utilize information from key value pairs +that will be provided by the Ansible Server as "extra-vars" during +invocation to execute the desired xNF action. If the playbook requires +files, they must also be supplied using the methodology detailed in +the Ansible Server API, unless they are bundled with playbooks, example, +generic templates. + +R-43253 The xNF **MUST** use playbooks designed to allow Ansible +Server to infer failure or success based on the “PLAY_RECAP” capability. +NOTE: There are cases where playbooks need to interpret results of a task +and then determine success or failure and return result accordingly +(failure for failed tasks). + +R-50252 The xNF **MUST** write to a specific one text files that +will be retrieved and made available by the Ansible Server if, as part +of a xNF action (e.g., audit), a playbook is required to return any +xNF information. The text files must be written in the same directory as +the one from which the playbook is being executed. A text file must be +created for the xNF playbook run targets/affects, with the name +‘<VNFname>_results.txt’ into which any desired output from each +respective VM/xNF must be written. + +R-51442 The xNF **SHOULD** use playbooks that are designed to +automatically ‘rollback’ to the original state in case of any errors +for actions that change state of the xNF (e.g., configure). + +R-58301 The xNF **SHOULD NOT** use playbooks that make requests to +Cloud resources e.g. Openstack (nova, neutron, glance, heat, etc.); +therefore, there is no use for Cloud specific variables like Openstack +UUIDs in Ansible Playbooks. + +R-02651 The xNF **SHOULD** use the Ansible backup feature to save a +copy of configuration files before implementing changes to support +operations such as backing out of software upgrades, configuration +changes or other work as this will help backing out of configuration +changes when needed. + +R-43353 The xNF **MUST** return control from Ansible Playbooks only +after tasks are fully complete, signaling that the playbook completed +all tasks. When starting services, return control only after all services +are up. This is critical for workflows where the next steps are dependent + +R-51910 The xNF **MUST** provide all telemetry (e.g., fault event +records, syslog records, performance records etc.) to ONAP using the +model, format and mechanisms described in this section. + +R-19624 The xNF **MUST** encode and serialize content delivered to +ONAP using JSON (RFC 7159) plain text format. High-volume data is to +be encoded and serialized using `Avro <http://avro.apache.org/>`_, +where the Avro [5]_ data format are described using JSON. + +Note: + +- JSON plain text format is preferred for moderate volume data sets + (option 1), as JSON has the advantage of having well-understood simple + processing and being human-readable without additional decoding. Examples + of moderate volume data sets include the fault alarms and performance + alerts, heartbeat messages, measurements used for xNF scaling and syslogs. +- Binary format using Avro is preferred for high volume data sets + (option 2) such as mobility flow measurements and other high-volume + streaming events (such as mobility signaling events or SIP signaling) + or bulk data, as this will significantly reduce the volume of data + to be transmitted. As of the date of this document, all events are + reported using plain text JSON and REST. +- Avro content is self-documented, using a JSON schema. The JSON schema is + delivered along with the data content + (http://avro.apache.org/docs/current/ ). This means the presence and + position of data fields can be recognized automatically, as well as the + data format, definition and other attributes. Avro content can be + serialized as JSON tagged text or as binary. In binary format, the + JSON schema is included as a separate data block, so the content is + not tagged, further compressing the volume. For streaming data, Avro + will read the schema when the stream is established and apply the + schema to the received content. + +R-98191 The xNF **MUST** vary the frequency that asynchronous data is +delivered based on the content and how data may be aggregated or grouped +together. + +Note: + +- For example, alarms and alerts are expected to be delivered as soon + as they appear. In contrast, other content, such as performance + measurements, KPIs or reported network signaling may have various ways + of packaging and delivering content. Some content should be streamed + immediately; or content may be monitored over a time interval, then packaged + as collection of records and delivered as block; or data may be collected + until a package of a certain size has been collected; or content may be + summarized statistically over a time interval, or computed as a KPI, with + the summary or KPI being delivered. +- We expect the reporting frequency to be configurable depending + on the virtual network function’s needs for management. For example, + Service Provider may choose to vary the frequency of collection between + normal and trouble-shooting scenarios. +- Decisions about the frequency of data reporting will affect the + size of delivered data sets, recommended delivery method, and how the + data will be interpreted by ONAP. These considerations should not + affect deserialization and decoding of the data, which will be guided + by the accompanying JSON schema or GPB definition files. + +R-88482 The xNF **SHOULD** use REST using HTTPS delivery of plain +text JSON for moderate sized asynchronous data sets, and for high +volume data sets when feasible. + +R-84879 The xNF **MUST** have the capability of maintaining a primary +and backup DNS name (URL) for connecting to ONAP collectors, with the +ability to switch between addresses based on conditions defined by policy +such as time-outs, and buffering to store messages until they can be +delivered. At its discretion, the service provider may choose to populate +only one collector address for a xNF. In this case, the network will +promptly resolve connectivity problems caused by a collector or network +failure transparently to the xNF. + +R-81777 The xNF **MUST** be configured with initial address(es) to use +at deployment time. Subsequently, address(es) may be changed through +ONAP-defined policies delivered from ONAP to the xNF using PUTs to a +RESTful API, in the same manner that other controls over data reporting +will be controlled by policy. + +R-08312 The xNF **MAY** use another option which is expected to include REST +delivery of binary encoded data sets. + +R-79412 The xNF **MAY** use another option which is expected to include TCP +for high volume streaming asynchronous data sets and for other high volume +data sets. TCP delivery can be used for either JSON or binary encoded data +sets. + +R-01033 The xNF **MAY** use another option which is expected to include SFTP +for asynchronous bulk files, such as bulk files that contain large volumes of +data collected over a long time interval or data collected across many xNFs. +(Preferred is to reorganize the data into more frequent or more focused data +sets, and deliver these by REST or TCP as appropriate.) + +R-63229 The xNF **MAY** use another option which is expected to include REST +for synchronous data, using RESTCONF (e.g., for xNF state polling). + +R-03070 The xNF **MUST**, by ONAP Policy, provide the ONAP addresses +as data destinations for each xNF, and may be changed by Policy while +the xNF is in operation. We expect the xNF to be capable of redirecting +traffic to changed destinations with no loss of data, for example from +one REST URL to another, or from one TCP host and port to another. + +R-06924 The xNF **MUST** deliver asynchronous data as data becomes +available, or according to the configured frequency. + +R-73285 The xNF **MUST** must encode, address and deliver the data +as described in the previous paragraphs. + +R-42140 The xNF **MUST** respond to data requests from ONAP as soon +as those requests are received, as a synchronous response. + +R-34660 The xNF **MUST** use the RESTCONF/NETCONF framework used by +the ONAP configuration subsystem for synchronous communication. + +R-86586 The xNF **MUST** use the YANG configuration models and RESTCONF +[RFC8040] (https://tools.ietf.org/html/rfc8040). + +R-11240 The xNF **MUST** respond with content encoded in JSON, as +described in the RESTCONF specification. This way the encoding of a +synchronous communication will be consistent with Avro. + +R-70266 The xNF **MUST** respond to an ONAP request to deliver the +current data for any of the record types defined in +Event Records - Data Structure Description by returning the requested +record, populated with the current field values. (Currently the defined +record types include fault fields, mobile flow fields, measurements for +xNF scaling fields, and syslog fields. Other record types will be added +in the future as they become standardized and are made available.) + +R-46290 The xNF **MUST** respond to an ONAP request to deliver granular +data on device or subsystem status or performance, referencing the YANG +configuration model for the xNF by returning the requested data elements. + +R-43327 The xNF **SHOULD** use `Modeling JSON text with YANG +<https://tools.ietf.org/html/rfc7951>`_, If YANG models need to be +translated to and from JSON[RFC7951]. YANG configuration and content can +be represented via JSON, consistent with Avro, as described in “Encoding +and Serialization” section. + +R-42366 The xNF **MUST** support secure connections and transports such as +Transport Layer Security (TLS) protocol +[`RFC5246 <https://tools.ietf.org/html/rfc5246>`_] and should adhere to +the best current practices outlined in +`RFC7525 <https://tools.ietf.org/html/rfc7525>`_. + +R-44290 The xNF **MUST** control access to ONAP and to xNFs, and creation +of connections, through secure credentials, log-on and exchange mechanisms. + +R-47597 The xNF **MUST** carry data in motion only over secure connections. + +R-68165 The xNF **MUST** encrypt any content containing Sensitive Personal +Information (SPI) or certain proprietary data, in addition to applying the +regular procedures for securing access and delivery. + + +.. [1] + Not currently supported in ONAP release 1 + +.. [2] + https://github.com/mbj4668/pyang + +.. [3] + Upstream elements must provide the appropriate FQDN in the request to + ONAP for the desired action. + +.. [4] + Refer to NCSP’s Network Cloud specification + +.. [5] + This option is not currently supported in ONAP and it is currently + under consideration. + +.. [6] + Multiple ONAP actions may map to one playbook. + + |