docs/changes-by-section-casablanca.rst

   1 .. Modifications Copyright © 2017-2018 AT&T Intellectual Property.
   2
   3 .. Licensed under the Creative Commons License, Attribution 4.0 Intl.
   4    (the "License"); you may not use this documentation except in compliance
   5    with the License. You may obtain a copy of the License at
   6
   7 .. https://creativecommons.org/licenses/by/4.0/
   8
   9 .. Unless required by applicable law or agreed to in writing, software
  10    distributed under the License is distributed on an "AS IS" BASIS,
  11    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  12    See the License for the specific language governing permissions and
  13    limitations under the License.
  14
  15
  16 Requirement Changes Introduced in Casablanca
  17 ========================================================
  18
  19 This document summarizes the requirement changes by section that were
  20 introduced between the Beijing release and
  21 Casablanca release. Click on the requirement number to
  22 navigate to the
  23
  24 .. contents::
  25     :depth: 2
  26
  27 Summary of Changes
  28 ------------------
  29
  30 * **Requirements Added:** 102
  31 * **Requirements Changed:** 232
  32 * **Requirements Removed:** 63
  33
  34
  35 Configuration Management > Ansible Standards and Capabilities > xNF Configuration via Ansible Requirements > Ansible Client Requirements
  36 ----------------------------------------------------------------------------------------------------------------------------------------
  37
  38
  39 Requirements Added
  40 ~~~~~~~~~~~~~~~~~~
  41
  42 .. container:: note
  43
  44     :need:`R-24482`
  45
  46     The xNF **MUST** provide Ansible playbooks that are designed to run using
  47     an inventory hosts file in a supported format; with site group that shall
  48     be used to add site specific configurations to the target xNF VM(s) as
  49     needed.
  50
  51
  52 .. container:: note
  53
  54     :need:`R-45197`
  55
  56     The xNF **MUST** define the "from=" clause to provide the list of IP
  57     addresses of the Ansible Servers in the Cluster, separated by coma, to
  58     restrict use of the SSH key pair to elements that are part of the Ansible
  59     Cluster owner of the issued and assigned mechanized user ID.
  60
  61
  62 .. container:: note
  63
  64     :need:`R-67124`
  65
  66     The xNF **MUST** provide Ansible playbooks that are designed to run using
  67     an inventory hosts file in a supported format; with group names matching
  68     VNFC 3-character string adding "vip" for groups with virtual IP addresses
  69     shared by multiple VMs as seen in examples provided in Appendix.
  70
  71
  72 .. container:: note
  73
  74     :need:`R-73459`
  75
  76     The xNF **MUST** provide the ability to include a "from=" clause in SSH
  77     public keys associated with mechanized user IDs created for an Ansible
  78     Server cluster to use for xNF VM authentication.
  79
  80
  81 .. container:: note
  82
  83     :need:`R-94567`
  84
  85     The xNF **MUST** provide Ansible playbooks that are designed to run using
  86     an inventory hosts file in a supported format with only IP addresses or
  87     IP addresses and VM/xNF names.
  88
  89
  90 .. container:: note
  91
  92     :need:`R-97345`
  93
  94     The xNF **MUST** permit authentication, using root account, only right
  95     after instantiation and until post-instantiation configuration is
  96     completed.
  97
  98
  99 .. container:: note
 100
 101     :need:`R-97451`
 102
 103     The xNF **MUST** provide the ability to remove root access once
 104     post-instantiation configuration (Configure) is completed.
 105
 106
 107 Requirements Changed
 108 ~~~~~~~~~~~~~~~~~~~~
 109
 110
 111 .. container:: note
 112
 113     :need:`R-32217`
 114
 115     The xNF **MUST** have routable management IP addresses or FQDNs that
 116     are reachable via the Ansible Server for the endpoints (VMs) of a
 117     xNF that playbooks will target. ONAP will initiate requests to the
 118     Ansible Server for invocation of playbooks against these end
 119     points [#7.3.3]_.
 120
 121
 122 .. container:: note
 123
 124     :need:`R-91745`
 125
 126     The xNF **MUST** update the Ansible Server and other entities
 127     storing and using the SSH keys for authentication when the SSH
 128     keys used by Ansible are regenerated/updated.
 129
 130     **Note**: Ansible Server itself may be used to upload new SSH public
 131     keys onto supported xNFs.
 132
 133
 134 .. container:: note
 135
 136     :need:`R-82018`
 137
 138     The xNF **MUST** load the Ansible Server SSH public key onto xNF
 139     VM(s) /root/.ssh/authorized_keys as part of instantiation. Alternative,
 140     is for Ansible Server SSH public key to be loaded onto xNF VM(s) under
 141     /home/<Mechanized user ID>/.ssh/authorized_keys as part of instantiation,
 142     when a Mechanized user ID is created during instantiation, and Configure
 143     and all playbooks are designed to use a mechanized user ID only for
 144     authentication (never using root authentication during Configure playbook
 145     run). This will allow the Ansible Server to authenticate to perform
 146     post-instantiation configuration without manual intervention and without
 147     requiring specific xNF login IDs and passwords.
 148
 149     *CAUTION*: For xNFs configured using Ansible, to eliminate the need
 150     for manual steps, post-instantiation and pre-configuration, to
 151     upload of SSH public keys, SSH public keys loaded during (heat)
 152     instantiation shall be preserved and not removed by (heat) embedded
 153     (userdata) scripts.
 154
 155
 156 .. container:: note
 157
 158     :need:`R-35401`
 159
 160     The xNF **MUST** support SSH and allow SSH access by the
 161     Ansible server to the endpoint VM(s) and comply with the Network
 162     Cloud Service Provider guidelines for authentication and access.
 163
 164
 165 .. container:: note
 166
 167     :need:`R-92866`
 168
 169     The xNF **MUST** include as part of post-instantiation configuration
 170     done by Ansible Playbooks the removal/update of the SSH public key from
 171     /root/.ssh/authorized_keys, and update of SSH keys loaded through
 172     instantiation to support Ansible. This may include creating Mechanized user
 173     ID(s) used by the Ansible Server(s) on VNF VM(s) and uploading and
 174     installing new SSH keys used by the mechanized use ID(s).
 175
 176
 177 Configuration Management > Ansible Standards and Capabilities > xNF Configuration via Ansible Requirements > Ansible Playbook Requirements
 178 ------------------------------------------------------------------------------------------------------------------------------------------
 179
 180
 181 Requirements Added
 182 ~~~~~~~~~~~~~~~~~~
 183
 184
 185 .. container:: note
 186
 187     :need:`R-24189`
 188
 189     The xNF provider **MUST** deliver a new set of playbooks that includes
 190     all updated and unchanged playbooks for any new revision to an existing
 191     set of playbooks.
 192
 193
 194 .. container:: note
 195
 196     :need:`R-49751`
 197
 198     The xNF **MUST** support Ansible playbooks that are compatible with
 199     Ansible version 2.6 or later.
 200
 201
 202 .. container:: note
 203
 204     :need:`R-49911`
 205
 206     The xNF provider **MUST** assign a new point release to the updated
 207     playbook set. The functionality of a new playbook set must be tested before
 208     it is deployed to the production.
 209
 210
 211 Requirements Changed
 212 ~~~~~~~~~~~~~~~~~~~~
 213
 214
 215 .. container:: note
 216
 217     :need:`R-48698`
 218
 219     The xNF **MUST** utilize information from key value pairs that will be
 220     provided by the Ansible Server as "extra-vars" during invocation to
 221     execute the desired xNF action. The "extra-vars" attribute-value pairs
 222     are passed to the Ansible Server by an APPC/SDN-C as part of the
 223     Rest API request. If the playbook requires files, they must also be
 224     supplied using the methodology detailed in the Ansible Server API, unless
 225     they are bundled with playbooks, example, generic templates. Any files
 226     containing instance specific info (attribute-value pairs), not obtainable
 227     from any ONAP inventory databases or other sources, referenced and used an
 228     input by playbooks, shall be provisioned (and distributed) in advance of
 229     use, e.g., xNF instantiation. Recommendation is to avoid these instance
 230     specific, manually created in advance of instantiation, files.
 231
 232
 233 .. container:: note
 234
 235     :need:`R-43353`
 236
 237     The xNF **MUST** return control from Ansible Playbooks only after all
 238     tasks performed by playbook are fully complete, signaling that the
 239     playbook completed all tasks. When starting services, return control
 240     only after all services are up. This is critical for workflows where
 241     the next steps are dependent on prior tasks being fully completed.
 242
 243
 244 .. container:: note
 245
 246     :need:`R-51442`
 247
 248     The xNF **SHOULD** use playbooks that are designed to
 249     automatically 'rollback' to the original state in case of any errors
 250     for actions that change state of the xNF (e.g., configure).
 251
 252     **Note**: In case rollback at the playbook level is not supported or
 253     possible, the xNF provider shall provide alternative rollback
 254     mechanism (e.g., for a small xNF the rollback mechanism may rely
 255     on workflow to terminate and re-instantiate VNF VMs and then re-run
 256     playbook(s)). Backing up updated files is also recommended to support
 257     rollback when soft rollback is feasible.
 258
 259
 260 .. container:: note
 261
 262     :need:`R-50252`
 263
 264     The xNF **MUST** write to a response file in JSON format that will be
 265     retrieved and made available by the Ansible Server if, as part of a xNF
 266     action (e.g., audit), a playbook is required to return any xNF
 267     information/response. The text files must be written in the main playbook
 268     home directory, in JSON format. The JSON file must be created for the xNF
 269     with the name '<xNF name>_results.txt'. All playbook output results, for
 270     all xNF VMs, to be provided as a response to the request, must be written
 271     to this response file.
 272
 273
 274 .. container:: note
 275
 276     :need:`R-49396`
 277
 278     The xNF **MUST** support each APPC/SDN-C xNF action
 279     by invocation of **one** playbook [#7.3.4]_. The playbook will be responsible
 280     for executing all necessary tasks (as well as calling other playbooks)
 281     to complete the request.
 282
 283
 284 .. container:: note
 285
 286     :need:`R-02651`
 287
 288     The xNF **SHOULD** use available backup capabilities to save a
 289     copy of configuration files before implementing changes to support
 290     operations such as backing out of software upgrades, configuration
 291     changes or other work as this will help backing out of configuration
 292     changes when needed.
 293
 294
 295 .. container:: note
 296
 297     :need:`R-58301`
 298
 299     The xNF **SHOULD NOT** use playbooks that make requests to
 300     Cloud resources e.g. Openstack (nova, neutron, glance, heat, etc.);
 301     therefore, there is no use for Cloud specific variables like Openstack
 302     UUIDs in Ansible Playbook related artifacts.
 303
 304     **Rationale**: Flows that require interactions with Cloud services e.g.
 305     Openstack shall rely on workflows run by an Orchestrator
 306     (Change Management) or other capability (such as a control loop or
 307     Operations GUI) outside Ansible Server which can be executed by a
 308     APPC/SDN-C. There are policies, as part of Control Loop
 309     models, that send remediation action requests to an APPC/SDN-C; these
 310     are triggered as a response to an event or correlated events published
 311     to Event Bus.
 312
 313
 314 Configuration Management > Chef Standards and Capabilities > xNF Configuration via Chef Requirements > Chef Roles/Requirements
 315 ------------------------------------------------------------------------------------------------------------------------------
 316
 317
 318 Requirements Changed
 319 ~~~~~~~~~~~~~~~~~~~~
 320
 321
 322 .. container:: note
 323
 324     :need:`R-26567`
 325
 326     The xNF Package **MUST** include a run list of
 327     roles/cookbooks/recipes, for each supported xNF action, that will
 328     perform the desired xNF action in its entirety as specified by ONAP
 329     (see Section 7.c, APPC/SDN-C APIs and Behavior, for list of xNF
 330     actions and requirements), when triggered by a chef-client run list
 331     in JSON file.
 332
 333
 334 Configuration Management > Controller Interactions With xNF > Configuration Commands
 335 ------------------------------------------------------------------------------------
 336
 337
 338 Requirements Changed
 339 ~~~~~~~~~~~~~~~~~~~~
 340
 341
 342 .. container:: note
 343
 344     :need:`R-20741`
 345
 346     The xNF **MUST** support APPC/SDN-C ``Configure`` command.
 347
 348
 349 .. container:: note
 350
 351     :need:`R-94084`
 352
 353     The xNF **MUST** support APPC/SDN-C ``ConfigScaleOut`` command.
 354
 355
 356 .. container:: note
 357
 358     :need:`R-32981`
 359
 360     The xNF **MUST** support APPC ``ConfigBackup`` command.
 361
 362
 363 .. container:: note
 364
 365     :need:`R-48247`
 366
 367     The xNF **MUST** support APPC ``ConfigRestore`` command.
 368
 369
 370 .. container:: note
 371
 372     :need:`R-56385`
 373
 374     The xNF **MUST** support APPC ``Audit`` command.
 375
 376
 377 .. container:: note
 378
 379     :need:`R-19366`
 380
 381     The xNF **MUST** support APPC ``ConfigModify`` command.
 382
 383
 384 Configuration Management > Controller Interactions With xNF > HealthCheck and Failure Related Commands
 385 ------------------------------------------------------------------------------------------------------
 386
 387
 388 Requirements Changed
 389 ~~~~~~~~~~~~~~~~~~~~
 390
 391
 392 .. container:: note
 393
 394     :need:`R-41430`
 395
 396     The xNF **MUST** support APPC/SDN-C ``HealthCheck`` command.
 397
 398
 399 Configuration Management > Controller Interactions With xNF > Lifecycle Management Related Commands
 400 ---------------------------------------------------------------------------------------------------
 401
 402
 403 Requirements Added
 404 ~~~~~~~~~~~~~~~~~~
 405
 406
 407 .. container:: note
 408
 409     :need:`R-328086`
 410
 411     The xNF **MUST**, if serving as a distribution point or anchor point for
 412     steering point from source to destination, support the ONAP Controller's
 413     ``DistributeTraffic`` command.
 414
 415
 416 Requirements Changed
 417 ~~~~~~~~~~~~~~~~~~~~
 418
 419
 420 .. container:: note
 421
 422     :need:`R-12706`
 423
 424     The xNF **MUST** support APPC/SDN-C ``QuiesceTraffic`` command.
 425
 426
 427 .. container:: note
 428
 429     :need:`R-49466`
 430
 431     The xNF **MUST** support APPC/SDN-C ``UpgradeSoftware`` command.
 432
 433
 434 .. container:: note
 435
 436     :need:`R-82811`
 437
 438     The xNF **MUST** support APPC ``StartApplication`` command.
 439
 440
 441 .. container:: note
 442
 443     :need:`R-07251`
 444
 445     The xNF **MUST** support APPC/SDN-C ``ResumeTraffic`` command.
 446
 447
 448 .. container:: note
 449
 450     :need:`R-45856`
 451
 452     The xNF **MUST** support APPC/SDN-C ``UpgradePostCheck`` command.
 453
 454
 455 .. container:: note
 456
 457     :need:`R-65641`
 458
 459     The xNF **MUST** support APPC/SDN-C ``UpgradeBackOut`` command.
 460
 461
 462 .. container:: note
 463
 464     :need:`R-83146`
 465
 466     The xNF **MUST** support APPC ``StopApplication`` command.
 467
 468
 469 .. container:: note
 470
 471     :need:`R-97343`
 472
 473     The xNF **MUST** support APPC/SDN-C ``UpgradeBackup`` command.
 474
 475
 476 .. container:: note
 477
 478     :need:`R-19922`
 479
 480     The xNF **MUST** support APPC/SDN-C ``UpgradePrecheck`` command.
 481
 482
 483 Configuration Management > NETCONF Standards and Capabilities > xNF Configuration via NETCONF Requirements > NETCONF Server Requirements
 484 ----------------------------------------------------------------------------------------------------------------------------------------
 485
 486
 487 Requirements Changed
 488 ~~~~~~~~~~~~~~~~~~~~
 489
 490
 491 .. container:: note
 492
 493     :need:`R-18733`
 494
 495     The xNF **MUST** implement the protocol operation:
 496     ``discard-changes()`` - Revert the candidate configuration
 497     data store to the running configuration.
 498
 499
 500 .. container:: note
 501
 502     :need:`R-29488`
 503
 504     The xNF **MUST** implement the protocol operation:
 505     ``get-config(source, filter`` - Retrieve a (filtered subset of
 506     a) configuration from the configuration data store source.
 507
 508
 509 .. container:: note
 510
 511     :need:`R-70496`
 512
 513     The xNF **MUST** implement the protocol operation:
 514     ``commit(confirmed, confirm-timeout)`` - Commit candidate
 515     configuration data store to the running configuration.
 516
 517
 518 .. container:: note
 519
 520     :need:`R-44281`
 521
 522     The xNF **MUST** implement the protocol operation:
 523     ``edit-config(target, default-operation, test-option, error-option,
 524     config)`` - Edit the target configuration data store by merging,
 525     replacing, creating, or deleting new config elements.
 526
 527
 528 .. container:: note
 529
 530     :need:`R-02597`
 531
 532     The xNF **MUST** implement the protocol operation:
 533     ``lock(target)`` - Lock the configuration data store target.
 534
 535
 536 .. container:: note
 537
 538     :need:`R-90007`
 539
 540     The xNF **MUST** implement the protocol operation:
 541     ``close-session()`` - Gracefully close the current session.
 542
 543
 544 .. container:: note
 545
 546     :need:`R-11235`
 547
 548     The xNF **MUST** implement the protocol operation:
 549     ``kill-session(session``- Force the termination of **session**.
 550
 551
 552 .. container:: note
 553
 554     :need:`R-96554`
 555
 556     The xNF **MUST** implement the protocol operation:
 557     ``unlock(target)`` - Unlock the configuration data store target.
 558
 559
 560 .. container:: note
 561
 562     :need:`R-88031`
 563
 564     The xNF **SHOULD** implement the protocol operation:
 565     ``delete-config(target)`` - Delete the named configuration
 566     data store target.
 567
 568
 569 .. container:: note
 570
 571     :need:`R-29324`
 572
 573     The xNF **SHOULD** implement the protocol operation:
 574     ``copy-config(target, source)`` - Copy the content of the
 575     configuration data store source to the configuration data store target.
 576
 577
 578 Contrail Resource Parameters > Contrail Network Parameters > External Networks
 579 ------------------------------------------------------------------------------
 580
 581
 582 Requirements Changed
 583 ~~~~~~~~~~~~~~~~~~~~
 584
 585
 586 .. container:: note
 587
 588     :need:`R-02164`
 589
 590     When a VNF's Heat Orchestration Template's Contrail resource
 591     has a property that
 592     references an external network that requires the network's
 593     Fully Qualified Domain Name (FQDN), the property parameter
 594
 595     * **MUST** follow the format ``{network-role}_net_fqdn``
 596     * **MUST** be declared as type ``string``
 597     * **MUST NOT** be enumerated in the VNF's Heat Orchestration Template's
 598       Environment File
 599
 600
 601 Heat > Cinder Volumes
 602 ---------------------
 603
 604
 605 Requirements Removed
 606 ~~~~~~~~~~~~~~~~~~~~
 607
 608
 609 .. container:: note
 610
 611     R-79531
 612
 613     The VNF Heat Orchestration Template **MUST** define
 614     "outputs" in the volume template for each Cinder volume
 615     resource universally unique identifier (UUID) (i.e. ONAP
 616     Volume Template Output Parameters).
 617
 618
 619 Heat > Heat Orchestration Template Format > Heat Orchestration Template Structure > resources > metadata
 620 --------------------------------------------------------------------------------------------------------
 621
 622
 623 Requirements Removed
 624 ~~~~~~~~~~~~~~~~~~~~
 625
 626
 627 .. container:: note
 628
 629     R-97199
 630
 631     A VNF's Heat Orchestration Template's OS::Nova::Server
 632     resource **MUST** contain the attribute "metadata".
 633
 634
 635 Heat > Heat Template Constructs > Heat Files Support (get_file)
 636 ---------------------------------------------------------------
 637
 638
 639 Requirements Removed
 640 ~~~~~~~~~~~~~~~~~~~~
 641
 642
 643 .. container:: note
 644
 645     R-62177
 646
 647     When using the intrinsic function get_file, the included files
 648     **MUST** have unique file names within the scope of the VNF.
 649
 650
 651 Heat > Heat Template Constructs > Nested Heat Template Requirements
 652 -------------------------------------------------------------------
 653
 654
 655 Requirements Removed
 656 ~~~~~~~~~~~~~~~~~~~~
 657
 658
 659 .. container:: note
 660
 661     R-89868
 662
 663     The VNF Heat Orchestration Template **MUST** have unique
 664     file names within the scope of the VNF for a nested heat yaml file.
 665
 666
 667 Heat > Networking > External Networks
 668 -------------------------------------
 669
 670
 671 Requirements Removed
 672 ~~~~~~~~~~~~~~~~~~~~
 673
 674
 675 .. container:: note
 676
 677     R-29865
 678
 679     When a VNF connects to an external network, a network role,
 680     referred to as the '{network-role}' **MUST** be assigned to the
 681     external network for use in the VNF's Heat Orchestration Template.
 682
 683
 684 Heat > Networking > Internal Networks
 685 -------------------------------------
 686
 687
 688 Requirements Removed
 689 ~~~~~~~~~~~~~~~~~~~~
 690
 691
 692 .. container:: note
 693
 694     R-34726
 695
 696     If a VNF's port is connected to an internal network and the port
 697     is created in the same Heat Orchestration Template as the internal network,
 698     then the port resource **MUST** use a 'get_resource' to obtain
 699     the network UUID.
 700
 701
 702 Heat > ONAP Resource ID and Parameter Naming Convention > Contrail Resource Parameters > Contrail Network Parameters > External Networks
 703 ----------------------------------------------------------------------------------------------------------------------------------------
 704
 705
 706 Requirements Removed
 707 ~~~~~~~~~~~~~~~~~~~~
 708
 709
 710 .. container:: note
 711
 712     R-73228
 713
 714     A VNF's Heat Orchestration Template's parameter
 715     '{network-role}_net_fqdn'
 716     **MUST** be declared as type 'string'.
 717
 718
 719 Heat > ONAP Resource ID and Parameter Naming Convention > Resource: OS::Nova::Server – Metadata Parameters > vm_role
 720 --------------------------------------------------------------------------------------------------------------------
 721
 722
 723 Requirements Removed
 724 ~~~~~~~~~~~~~~~~~~~~
 725
 726
 727 .. container:: note
 728
 729     R-46823
 730
 731     A VNF's Heat Orchestration Template's OS::Nova::Server
 732     Resource metadata map value parameter 'vnf_name' **MUST** be
 733     either
 734
 735      - enumerated in the VNF's Heat Orchestration
 736        Template's environment file.
 737
 738      - hard coded in the VNF's Heat Orchestration
 739        Template's OS::Nova::Resource metadata property.
 740
 741
 742 Heat > ONAP Support of Environment Files
 743 ----------------------------------------
 744
 745
 746 Requirements Removed
 747 ~~~~~~~~~~~~~~~~~~~~
 748
 749
 750 .. container:: note
 751
 752     R-22656
 753
 754     The VNF Heat Orchestration Template **MUST** have a
 755     corresponding environment file for a Cinder Volume Module.
 756
 757
 758 .. container:: note
 759
 760     R-35727
 761
 762     The VNF Heat Orchestration Template **MUST** have a
 763     corresponding environment file for an Incremental module.
 764
 765
 766 .. container:: note
 767
 768     R-67205
 769
 770     The VNF Heat Orchestration Template **MUST** have a corresponding
 771     environment file for a Base Module.
 772
 773
 774 Monitoring & Management > Data Structure Specification of the Event Record
 775 --------------------------------------------------------------------------
 776
 777
 778 Requirements Added
 779 ~~~~~~~~~~~~~~~~~~
 780
 781
 782 .. container:: note
 783
 784     :need:`R-120182`
 785
 786     The xNF provider **MUST** indicate specific conditions that may arise, and
 787     recommend actions that may be taken at specific thresholds, or if specific
 788     conditions repeat within a specified time interval, using the semantics and
 789     syntax described by the :doc:`VES Event Registration specification<../../../../vnfsdk/module.git/files/VESEventRegistration_3_0>`.
 790
 791
 792 .. container:: note
 793
 794     :need:`R-123044`
 795
 796     The xNF Provider **MAY** require that specific events, identified by their
 797     ``eventName``, require that certain fields, which are optional in the common
 798     event format, must be present when they are published.
 799
 800
 801 .. container:: note
 802
 803     :need:`R-520802`
 804
 805     The xNF provider **MUST** provide a YAML file formatted in adherence with
 806     the :doc:`VES Event Registration specification<../../../../vnfsdk/module.git/files/VESEventRegistration_3_0>`
 807     that defines the following information for each event produced by the VNF:
 808
 809     * ``eventName``
 810     * Required fields
 811     * Optional fields
 812     * Any special handling to be performed for that event
 813
 814
 815 .. container:: note
 816
 817     :need:`R-570134`
 818
 819     The events produced by the xNF **MUST** must be compliant with the common
 820     event format defined in the
 821     :doc:`VES Event Listener<../../../../vnfsdk/model.git/docs/files/VESEventListener_7_0_1>`
 822     specification.
 823
 824
 825 Monitoring & Management > Event Records - Data Structure Description > Common Event Header
 826 ------------------------------------------------------------------------------------------
 827
 828
 829 Requirements Added
 830 ~~~~~~~~~~~~~~~~~~
 831
 832
 833 .. container:: note
 834
 835     :need:`R-528866`
 836
 837     The VNF **MUST** produce VES events that include the following mandatory
 838     fields in the common event header.
 839
 840      * ``domain`` - the event domain enumeration
 841      * ``eventId`` - the event key unique to the event source
 842      * ``eventName`` - the unique event name
 843      * ``lastEpochMicrosec`` - the latest unix time (aka epoch time) associated
 844        with the event
 845      * ``priority`` - the processing priority enumeration
 846      * ``reportingEntityName`` - name of the entity reporting the event or
 847        detecting a problem in another xNF
 848      * ``sequence`` - the ordering of events communicated by an event source
 849      * ``sourceName`` - name of the entity experiencing the event issue, which
 850        may be detected and reported by a separate reporting entity
 851      * ``startEpochMicrosec`` - the earliest unix time (aka epoch time)
 852        associated with the event
 853      * ``version`` - the version of the event header
 854      * ``vesEventListenerVersion`` - Version of the VES event listener API spec
 855        that this event is compliant with
 856
 857
 858 Monitoring & Management > Event Records - Data Structure Description > Miscellaneous
 859 ------------------------------------------------------------------------------------
 860
 861
 862 Requirements Added
 863 ~~~~~~~~~~~~~~~~~~
 864
 865
 866 .. container:: note
 867
 868     :need:`R-283988`
 869
 870     The VNF, when publishing events, **MUST NOT** send information through
 871     extensible structures if the event specification has explicitly defined
 872     fields for that information.
 873
 874
 875 .. container:: note
 876
 877     :need:`R-408813`
 878
 879     The VNF, when publishing events, **MUST** pass all information it is
 880     able to collect even if the information field is identified as optional.
 881     However, if the data cannot be collected, then optional fields can be
 882     omitted.
 883
 884
 885 .. container:: note
 886
 887     :need:`R-470963`
 888
 889     The VNF, when publishing events, **MUST** leverage camel case to separate
 890     words and acronyms used as keys that will be sent through extensible fields.
 891     When an acronym is used as the key, then only the first letter shall be
 892     capitalized.
 893
 894
 895 Monitoring & Management > Monitoring & Management Requirements > Asynchronous and Synchronous Data Delivery
 896 -----------------------------------------------------------------------------------------------------------
 897
 898
 899 Requirements Added
 900 ~~~~~~~~~~~~~~~~~~
 901
 902
 903 .. container:: note
 904
 905     :need:`R-332680`
 906
 907     The xNF **SHOULD** deliver all syslog messages to the VES Collector per the
 908     specifications in Monitoring and Management chapter.
 909
 910
 911 Monitoring & Management > Monitoring & Management Requirements > Bulk Performance Measurement
 912 ---------------------------------------------------------------------------------------------
 913
 914
 915 Requirements Added
 916 ~~~~~~~~~~~~~~~~~~
 917
 918
 919 .. container:: note
 920
 921     :need:`R-440220`
 922
 923     The xNF **SHOULD** support File transferring protocol, such as FTPES or SFTP,
 924     when supporting the event-driven bulk transfer of monitoring data.
 925
 926
 927 .. container:: note
 928
 929     :need:`R-75943`
 930
 931     The xNF **SHOULD** support the data schema defined in 3GPP TS 32.435, when
 932     supporting the event-driven bulk transfer of monitoring data.
 933
 934
 935 .. container:: note
 936
 937     :need:`R-841740`
 938
 939     The xNF **SHOULD** support FileReady VES event for event-driven bulk transfer
 940     of monitoring data.
 941
 942
 943 Monitoring & Management > Monitoring & Management Requirements > Google Protocol Buffers (GPB)
 944 ----------------------------------------------------------------------------------------------
 945
 946
 947 Requirements Added
 948 ~~~~~~~~~~~~~~~~~~
 949
 950
 951 .. container:: note
 952
 953     :need:`R-257367`
 954
 955     The xNF, when leveraging Google Protocol Buffers for events, **MUST**
 956     serialize the events using native Google Protocol Buffers (GPB) according
 957     to the following guidelines:
 958
 959        * The keys are represented as integers pointing to the system resources
 960          for the xNF being monitored
 961        * The values correspond to integers or strings that identify the
 962          operational state of the VNF resource, such a statistics counters and
 963          the state of an xNF resource.
 964        * The required Google Protocol Buffers (GPB) metadata is provided in the
 965          form of .proto files.
 966
 967
 968 .. container:: note
 969
 970     :need:`R-978752`
 971
 972     The xNF providers **MUST** provide the Service Provider the following
 973     artifacts to support the delivery of high-volume xNF telemetry to
 974     DCAE via GPB over TLS/TCP:
 975
 976        * A valid VES Event .proto definition file, to be used validate and
 977          decode an event
 978        * A valid high volume measurement .proto definition file, to be used for
 979          processing high volume events
 980        * A supporting PM content metadata file to be used by analytics
 981          applications to process high volume measurement events
 982
 983
 984 Monitoring & Management > Monitoring & Management Requirements > JSON
 985 ---------------------------------------------------------------------
 986
 987
 988 Requirements Changed
 989 ~~~~~~~~~~~~~~~~~~~~
 990
 991
 992 .. container:: note
 993
 994     :need:`R-19624`
 995
 996     The xNF, when leveraging JSON for events, **MUST** encode and serialize
 997     content delivered to ONAP using JSON (RFC 7159) plain text format.
 998     High-volume data is to be encoded and serialized using
 999     `Avro <http://avro.apache.org/>`_, where the Avro [#7.4.1]_ data
1000     format are described using JSON.
1001
1002
1003 Monitoring & Management > Monitoring & Management Requirements > Reporting Frequency
1004 ------------------------------------------------------------------------------------
1005
1006
1007 Requirements Added
1008 ~~~~~~~~~~~~~~~~~~
1009
1010
1011 .. container:: note
1012
1013     :need:`R-146931`
1014
1015     The xNF **MUST** report exactly one Measurement event per period
1016     per source name.
1017
1018
1019 Monitoring & Management > Monitoring & Management Requirements > VNF telemetry via standardized interface
1020 ---------------------------------------------------------------------------------------------------------
1021
1022
1023 Requirements Added
1024 ~~~~~~~~~~~~~~~~~~
1025
1026
1027 .. container:: note
1028
1029     :need:`R-821473`
1030
1031     The xNF MUST produce heartbeat indicators consisting of events containing
1032     the common event header only per the VES Listener Specification.
1033
1034
1035 Requirements Removed
1036 ~~~~~~~~~~~~~~~~~~~~
1037
1038
1039 .. container:: note
1040
1041     R-51910
1042
1043     The xNF **MUST** provide all telemetry (e.g., fault event
1044     records, syslog records, performance records etc.) to ONAP using the
1045     model, format and mechanisms described in this section.
1046
1047
1048 Monitoring & Management > Transports and Protocols Supporting Resource Interfaces
1049 ---------------------------------------------------------------------------------
1050
1051
1052 Requirements Added
1053 ~~~~~~~~~~~~~~~~~~
1054
1055
1056 .. container:: note
1057
1058     :need:`R-798933`
1059
1060     The xNF **SHOULD** deliver event records that fall into the event domains
1061     supported by VES.
1062
1063
1064 .. container:: note
1065
1066     :need:`R-821839`
1067
1068     The xNF **MUST** deliver event records to ONAP using the common transport
1069     mechanisms and protocols defined in this document.
1070
1071
1072 .. container:: note
1073
1074     :need:`R-932071`
1075
1076     The xNF provider **MUST** reach agreement with the Service Provider on
1077     the selected methods for encoding, serialization and data delivery
1078     prior to the on-boarding of the xNF into ONAP SDC Design Studio.
1079
1080
1081 Monitoring & Management > Transports and Protocols Supporting Resource Interfaces > Bulk Telemetry Transmission
1082 ---------------------------------------------------------------------------------------------------------------
1083
1084
1085 Requirements Added
1086 ~~~~~~~~~~~~~~~~~~
1087
1088
1089 .. container:: note
1090
1091     :need:`R-908291`
1092
1093     The XNF **MAY** leverage bulk xNF telemetry transmission mechanism, as
1094     depicted in Figure 4, in instances where other transmission methods are not
1095     practical or advisable.
1096
1097
1098 Monitoring & Management > Transports and Protocols Supporting Resource Interfaces > xNF Telemetry using Google Protocol Buffers
1099 -------------------------------------------------------------------------------------------------------------------------------
1100
1101
1102 Requirements Added
1103 ~~~~~~~~~~~~~~~~~~
1104
1105
1106 .. container:: note
1107
1108     :need:`R-697654`
1109
1110     The xNF **MAY** leverage the Google Protocol Buffers (GPB) delivery model
1111     depicted in Figure 3 to support real-time performance management (PM) data.
1112     In this model the VES events are streamed as binary-encoded GBPs over via
1113     TCP sockets.
1114
1115
1116 Monitoring & Management > Transports and Protocols Supporting Resource Interfaces > xNF Telemetry using VES/JSON Model
1117 ----------------------------------------------------------------------------------------------------------------------
1118
1119
1120 Requirements Added
1121 ~~~~~~~~~~~~~~~~~~
1122
1123
1124 .. container:: note
1125
1126     :need:`R-659655`
1127
1128     The xNF **SHOULD** leverage the JSON-driven model, as depicted in Figure 2,
1129     for data delivery unless there are specific performance or operational
1130     concerns agreed upon by the Service Provider that would warrant using an
1131     alternate model.
1132
1133
1134 ONAP Heat Cinder Volumes
1135 ------------------------
1136
1137
1138 Requirements Added
1139 ~~~~~~~~~~~~~~~~~~
1140
1141
1142 .. container:: note
1143
1144     :need:`R-270358`
1145
1146     A VNF's Heat Orchestration Template's Cinder Volume Template **MUST**
1147     contain either
1148
1149     * An ``OS::Cinder::Volume`` resource
1150     * An ``OS::Heat::ResourceGroup`` resource that references a Nested YAML
1151       file that contains an ``OS::Cinder::Volume`` resource
1152     * A resource that defines the property ``type`` as a Nested YAML file
1153       (i.e., static nesting) and the Nested YAML contains
1154       an ``OS::Cinder::Volume`` resource
1155
1156
1157 ONAP Heat Heat Template Constructs > Heat Files Support (get_file)
1158 ------------------------------------------------------------------
1159
1160
1161 Requirements Changed
1162 ~~~~~~~~~~~~~~~~~~~~
1163
1164
1165 .. container:: note
1166
1167     :need:`R-05050`
1168
1169     A VNF's Heat Orchestration Templates intrinsic function
1170     ``get_file`` <content key> **MAY** be used:
1171
1172         * more than once in a VNF's Heat Orchestration Template
1173         * in two or more of a VNF's Heat Orchestration Templates
1174         * in a VNF's Heat Orchestration Templates nested YAML file
1175
1176
1177 .. container:: note
1178
1179     :need:`R-76718`
1180
1181     If a VNF's Heat Orchestration Template uses the intrinsic function
1182     ``get_file``, the ``get_file`` target **MUST** be referenced in
1183     the Heat Orchestration Template by file name.
1184
1185
1186 .. container:: note
1187
1188     :need:`R-41888`
1189
1190     A VNF's Heat Orchestration Template intrinsic function
1191     ``get_file`` **MUST NOT** utilize URL-based file retrieval.
1192
1193
1194 .. container:: note
1195
1196     :need:`R-87848`
1197
1198     When using the intrinsic function get_file, ONAP does not support
1199     a directory hierarchy for included files. All files must be in a
1200     single, flat directory per VNF. A VNF's Heat Orchestration
1201     Template's ``get_file`` target files **MUST** be in the same
1202     directory hierarchy as the VNF's Heat Orchestration Templates.
1203
1204
1205 ONAP Heat Heat Template Constructs > Nested Heat Templates > Nested Heat Template Requirements
1206 ----------------------------------------------------------------------------------------------
1207
1208
1209 Requirements Added
1210 ~~~~~~~~~~~~~~~~~~
1211
1212
1213 .. container:: note
1214
1215     :need:`R-70112`
1216
1217     A VNF's Heat Orchestration Template **MUST** reference a Nested YAML
1218     file by name. The use of ``resource_registry`` in the VNF's Heat
1219     Orchestration Templates Environment File **MUST NOT** be used.
1220
1221
1222 ONAP Heat Networking > External Networks
1223 ----------------------------------------
1224
1225
1226 Requirements Changed
1227 ~~~~~~~~~~~~~~~~~~~~
1228
1229
1230 .. container:: note
1231
1232     :need:`R-00606`
1233
1234     A VNF **MAY** be connected to zero, one or more than one external
1235     network.
1236
1237
1238 ONAP Heat Networking > Internal Networks
1239 ----------------------------------------
1240
1241
1242 Requirements Changed
1243 ~~~~~~~~~~~~~~~~~~~~
1244
1245
1246 .. container:: note
1247
1248     :need:`R-46461`
1249
1250     A VNF's port connected to an internal network **MUST NOT** use the port
1251     for the purpose of reaching VMs in another VNF and/or an
1252     external gateway and/or
1253     external router.
1254
1255
1256 .. container:: note
1257
1258     :need:`R-52425`
1259
1260     A VNF's port connected to an internal network **MUST**
1261     use the port for the purpose of reaching VMs in the same VNF.
1262
1263
1264 .. container:: note
1265
1266     :need:`R-87096`
1267
1268     A VNF **MAY** contain zero, one or more than one internal network.
1269
1270
1271 ONAP Heat Orchestration Template Format
1272 ---------------------------------------
1273
1274
1275 Requirements Added
1276 ~~~~~~~~~~~~~~~~~~
1277
1278
1279 .. container:: note
1280
1281     :need:`R-92635`
1282
1283     A VNF's Heat Orchestration Template **MUST** be compliant with the
1284     OpenStack Template Guide.
1285
1286
1287 ONAP Heat Orchestration Template Format > Environment File Format
1288 -----------------------------------------------------------------
1289
1290
1291 Requirements Changed
1292 ~~~~~~~~~~~~~~~~~~~~
1293
1294
1295 .. container:: note
1296
1297     :need:`R-86285`
1298
1299     A VNF's Heat Orchestration template **MUST** have a
1300     corresponding environment file.
1301
1302
1303 .. container:: note
1304
1305     :need:`R-68198`
1306
1307     A VNF's Heat Orchestration template's Environment File's
1308     ``parameters:`` section **MAY** (or **MAY NOT**) enumerate parameters.
1309
1310
1311 .. container:: note
1312
1313     :need:`R-03324`
1314
1315     A VNF's Heat Orchestration template's Environment File **MUST**
1316     contain the ``parameters:`` section.
1317
1318
1319 ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > parameters
1320 --------------------------------------------------------------------------------------------
1321
1322
1323 Requirements Changed
1324 ~~~~~~~~~~~~~~~~~~~~
1325
1326
1327 .. container:: note
1328
1329     :need:`R-90279`
1330
1331     A VNF Heat Orchestration's template's parameter **MUST** be used
1332     in a resource with the exception of the parameters for the
1333     ``OS::Nova::Server`` resource property ``availability_zone``.
1334
1335
1336 .. container:: note
1337
1338     :need:`R-91273`
1339
1340     A VNF Heat Orchestration's template's parameter for the
1341     ``OS::Nova::Server`` resource property ``availability_zone``
1342     **MAY NOT** be used in any ``OS::Nova::Server``.
1343
1344
1345 ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > parameters > constraints
1346 ----------------------------------------------------------------------------------------------------------
1347
1348
1349 Requirements Changed
1350 ~~~~~~~~~~~~~~~~~~~~
1351
1352
1353 .. container:: note
1354
1355     :need:`R-88863`
1356
1357     A VNF's Heat Orchestration Template's parameter defined
1358     in a non-nested YAML file as type
1359     ``number`` **MUST** have a parameter constraint of ``range`` or
1360     ``allowed_values`` defined.
1361
1362
1363 .. container:: note
1364
1365     :need:`R-00011`
1366
1367     A VNF's Heat Orchestration Template's parameter defined
1368     in a nested YAML file
1369     **MUST NOT** have a parameter constraint defined.
1370
1371
1372 .. container:: note
1373
1374     :need:`R-06613`
1375
1376     A VNF's Heat Orchestration Template's parameter defined
1377     in a non-nested YAML file as type
1378     ``boolean`` **MAY** have a parameter constraint defined.
1379
1380
1381 .. container:: note
1382
1383     :need:`R-40518`
1384
1385     A VNF's Heat Orchestration Template's parameter defined
1386     in a non-nested YAML file as type
1387     ``string`` **MAY** have a parameter constraint defined.
1388
1389
1390 .. container:: note
1391
1392     :need:`R-96227`
1393
1394     A VNF's Heat Orchestration Template's parameter defined
1395     in a non-nested YAML file as type
1396     ``json`` **MAY** have a parameter constraint defined.
1397
1398
1399 .. container:: note
1400
1401     :need:`R-79817`
1402
1403     A VNF's Heat Orchestration Template's parameter defined
1404     in a non-nested YAML file as
1405     type ``comma_delimited_list`` **MAY** have a parameter constraint defined.
1406
1407
1408 ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > parameters > default
1409 ------------------------------------------------------------------------------------------------------
1410
1411
1412 Requirements Changed
1413 ~~~~~~~~~~~~~~~~~~~~
1414
1415
1416 .. container:: note
1417
1418     :need:`R-26124`
1419
1420     If a VNF Heat Orchestration Template parameter has a default value,
1421     it **MUST** be enumerated in the environment file.
1422
1423
1424 ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > parameters > type
1425 ---------------------------------------------------------------------------------------------------
1426
1427
1428 Requirements Changed
1429 ~~~~~~~~~~~~~~~~~~~~
1430
1431
1432 .. container:: note
1433
1434     :need:`R-11441`
1435
1436     A VNF's Heat Orchestration Template's parameter type **MUST** be one of
1437     the following values:
1438
1439     * ``string``
1440     * ``number``
1441     * ``json``
1442     * ``comma_delimited_list``
1443     * ``boolean``
1444
1445
1446 ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > resources
1447 -------------------------------------------------------------------------------------------
1448
1449
1450 Requirements Changed
1451 ~~~~~~~~~~~~~~~~~~~~
1452
1453
1454 .. container:: note
1455
1456     :need:`R-40551`
1457
1458     A VNF's Heat Orchestration Template's Nested YAML files **MAY**
1459     (or **MAY NOT**) contain the section ``resources:``.
1460
1461
1462 ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > resources > deletion_policy
1463 -------------------------------------------------------------------------------------------------------------
1464
1465
1466 Requirements Changed
1467 ~~~~~~~~~~~~~~~~~~~~
1468
1469
1470 .. container:: note
1471
1472     :need:`R-43740`
1473
1474     VNF's Heat Orchestration Template's Resource **MAY** declare the
1475     attribute ``deletion_policy:``.
1476
1477
1478 ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > resources > external_id
1479 ---------------------------------------------------------------------------------------------------------
1480
1481
1482 Requirements Changed
1483 ~~~~~~~~~~~~~~~~~~~~
1484
1485
1486 .. container:: note
1487
1488     :need:`R-78569`
1489
1490     VNF's Heat Orchestration Template's Resource **MAY** declare the
1491     attribute ``external_id:``.
1492
1493
1494 ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > resources > metadata
1495 ------------------------------------------------------------------------------------------------------
1496
1497
1498 Requirements Added
1499 ~~~~~~~~~~~~~~~~~~
1500
1501
1502 .. container:: note
1503
1504     :need:`R-67386`
1505
1506     A VNF's Heat Orchestration Template's Resource **MAY** declare the
1507     attribute ``metadata``.
1508
1509
1510 ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > resources > properties
1511 --------------------------------------------------------------------------------------------------------
1512
1513
1514 Requirements Changed
1515 ~~~~~~~~~~~~~~~~~~~~
1516
1517
1518 .. container:: note
1519
1520     :need:`R-10834`
1521
1522     If a VNF's Heat Orchestration Template resource attribute
1523     ``property:`` uses a nested ``get_param``, the nested
1524     ``get_param`` **MUST** reference an index.
1525
1526
1527 ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Base Modules
1528 ------------------------------------------------------------------------------------------------------
1529
1530
1531 Requirements Changed
1532 ~~~~~~~~~~~~~~~~~~~~
1533
1534
1535 .. container:: note
1536
1537     :need:`R-81339`
1538
1539     A VNF Heat Orchestration Template's Base Module file name **MUST** include
1540     case insensitive 'base' in the filename and
1541     **MUST** match one of the following four
1542     formats:
1543
1544      1.) ``base_<text>.y[a]ml``
1545
1546      2.) ``<text>_base.y[a]ml``
1547
1548      3.) ``base.y[a]ml``
1549
1550      4.) ``<text>_base_<text>``.y[a]ml
1551
1552     where ``<text>`` **MUST** contain only alphanumeric characters and
1553     underscores '_' and **MUST NOT** contain the case insensitive word ``base``.
1554
1555
1556 ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Cinder Volume Modules
1557 ---------------------------------------------------------------------------------------------------------------
1558
1559
1560 Requirements Changed
1561 ~~~~~~~~~~~~~~~~~~~~
1562
1563
1564 .. container:: note
1565
1566     :need:`R-31141`
1567
1568     VNF Heat Orchestration Template's Cinder Volume Module's Environment File
1569     **MUST** be named identical to the VNF Heat Orchestration Template's
1570     Cinder Volume Module with ``.y[a]ml`` replaced with ``.env``.
1571
1572
1573 .. container:: note
1574
1575     :need:`R-82732`
1576
1577     A VNF Heat Orchestration Template's Cinder Volume Module **MUST**
1578     be named identical to the base or incremental module it is supporting with
1579     ``_volume`` appended.
1580
1581
1582 ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Incremental Modules
1583 -------------------------------------------------------------------------------------------------------------
1584
1585
1586 Requirements Changed
1587 ~~~~~~~~~~~~~~~~~~~~
1588
1589
1590 .. container:: note
1591
1592     :need:`R-87247`
1593
1594     VNF Heat Orchestration Template's Incremental Module file name
1595     **MUST** contain only alphanumeric characters and underscores
1596     '_' and **MUST NOT** contain the case insensitive word ``base``.
1597
1598
1599 ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Nested Heat file
1600 ----------------------------------------------------------------------------------------------------------
1601
1602
1603 Requirements Changed
1604 ~~~~~~~~~~~~~~~~~~~~
1605
1606
1607 .. container:: note
1608
1609     :need:`R-76057`
1610
1611     VNF Heat Orchestration Template's Nested YAML file name **MUST** contain
1612     only alphanumeric characters and underscores '_' and
1613     **MUST NOT** contain the case insensitive word ``base``.
1614
1615
1616 ONAP Heat Orchestration Templates Overview > ONAP VNF Modularity Overview
1617 -------------------------------------------------------------------------
1618
1619
1620 Requirements Changed
1621 ~~~~~~~~~~~~~~~~~~~~
1622
1623
1624 .. container:: note
1625
1626     :need:`R-38474`
1627
1628     A VNF's Base Module **MUST** have a corresponding Environment File.
1629
1630
1631 .. container:: note
1632
1633     :need:`R-20974`
1634
1635     At orchestration time, the VNF's Base Module **MUST**
1636     be deployed first, prior to any incremental modules.
1637
1638
1639 .. container:: note
1640
1641     :need:`R-53433`
1642
1643     A VNF's Cinder Volume Module **MUST** have a corresponding environment file
1644
1645
1646 .. container:: note
1647
1648     :need:`R-11200`
1649
1650     A VNF's Cinder Volume Module, when it exists, **MUST** be 1:1
1651     with a Base module or Incremental module.
1652
1653
1654 .. container:: note
1655
1656     :need:`R-33132`
1657
1658     A VNF's Heat Orchestration Template **MAY** be
1659      1.) Base Module Heat Orchestration Template (also referred to as a
1660          Base Module),
1661      2.) Incremental Module Heat Orchestration Template (referred to as
1662          an Incremental Module), or
1663      3.) a Cinder Volume Module Heat Orchestration Template (referred to as
1664          Cinder Volume  Module).
1665
1666
1667 .. container:: note
1668
1669     :need:`R-81725`
1670
1671     A VNF's Incremental Module **MUST** have a corresponding Environment File
1672
1673
1674 .. container:: note
1675
1676     :need:`R-37028`
1677
1678     A VNF **MUST** be composed of one Base Module
1679
1680
1681 ONAP Heat Orchestration Templates Overview > Output Parameters > ONAP Volume Module Output Parameters
1682 -----------------------------------------------------------------------------------------------------
1683
1684
1685 Requirements Changed
1686 ~~~~~~~~~~~~~~~~~~~~
1687
1688
1689 .. container:: note
1690
1691     :need:`R-07443`
1692
1693     A VNF's Heat Orchestration Templates' Cinder Volume Module Output
1694     Parameter's name and type **MUST** match the input parameter name and type
1695     in the corresponding Base Module or Incremental Module unless the Output
1696     Parameter is of the type ``comma_delimited_list``, then the corresponding
1697     input parameter **MUST** be declared as type ``json``.
1698
1699
1700 .. container:: note
1701
1702     :need:`R-89913`
1703
1704     A VNF's Heat Orchestration Template's Cinder Volume Module Output
1705     Parameter(s)
1706     **MUST** include the
1707     UUID(s) of the Cinder Volumes created in template,
1708     while others **MAY** be included.
1709
1710
1711 ONAP Heat VNF Modularity
1712 ------------------------
1713
1714
1715 Requirements Changed
1716 ~~~~~~~~~~~~~~~~~~~~
1717
1718
1719 .. container:: note
1720
1721     :need:`R-61001`
1722
1723     A shared Heat Orchestration Template resource is a resource that **MUST**
1724     be defined in the base module and will be referenced by one or
1725     more resources in one or more incremental modules.
1726
1727     The UUID of the shared resource (created in the base module) **MUST** be
1728     exposed by declaring a parameter in the
1729     ``outputs`` section of the base module.
1730
1731     For ECOMP to provided the UUID value of the shared resource to the
1732     incremental module, the parameter name defined in the ``outputs``
1733     section of the base module **MUST** be defined as a parameter
1734     in the ``parameters`` section of the incremental module.
1735
1736     ECOMP will capture the output parameter name and value in the base module
1737     and provide the value to the corresponding parameter(s) in the
1738     incremental module(s).
1739
1740
1741 ONAP Output Parameter Names > Predefined Output Parameters > OAM Management IP Addresses
1742 ----------------------------------------------------------------------------------------
1743
1744
1745 Requirements Changed
1746 ~~~~~~~~~~~~~~~~~~~~
1747
1748
1749 .. container:: note
1750
1751     :need:`R-56287`
1752
1753     If the VNF's OAM Management IP Address is assigned by ONAP SDN-C and
1754     assigned in the VNF's Heat Orchestration Template's via a heat resource
1755     ``OS::Neutron::Port`` property ``fixed_ips`` map property
1756     ``ip_adress`` parameter (e.g., ``{vm-type}_{network-role}_ip_{index}``,
1757     ``{vm-type}_{network-role}_v6_ip_{index}``)
1758     and the OAM IP Address is required to be inventoried in ONAP A&AI,
1759     then the parameter **MUST** be echoed in an output statement.
1760
1761     .. code-block:: yaml
1762
1763       outputs:
1764           oam_management_v4_address:
1765             value: {get_param: {vm-type}_{network-role}_ip_{index} }
1766           oam_management_v6_address:
1767             value: {get_param: {vm-type}_{network-role}_v6_ip_{index} }
1768
1769
1770 .. container:: note
1771
1772     :need:`R-48987`
1773
1774     If the VNF's OAM Management IP Address is cloud assigned and
1775     and the OAM IP Address is required to be inventoried in ONAP A&AI,
1776     then the parameter **MUST** be obtained by the
1777     resource ``OS::Neutron::Port``
1778     attribute ``ip_address``.
1779
1780
1781 .. container:: note
1782
1783     :need:`R-94669`
1784
1785     If a VNF has one IPv6 OAM Management IP Address and the
1786     IP Address needs to be inventoried in ONAP's A&AI
1787     database, an output parameter **MUST** be declared in only one of the
1788     VNF's Heat Orchestration Templates and the parameter **MUST** be named
1789     ``oam_management_v6_address``.
1790
1791
1792 ONAP TOSCA VNFD Requirements > TOSCA VNF Descriptor > Capability Types
1793 ----------------------------------------------------------------------
1794
1795
1796 Requirements Added
1797 ~~~~~~~~~~~~~~~~~~
1798
1799
1800 .. container:: note
1801
1802     :need:`R-67895`
1803
1804     The VNFD provided by VNF vendor may use the below described TOSCA
1805     capabilities. An on-boarding entity (ONAP SDC) **MUST** support them.
1806
1807       **tosca.capabilities.nfv.VirtualBindable**
1808
1809         A node type that includes the VirtualBindable capability indicates
1810         that it can be pointed by **tosca.relationships.nfv.VirtualBindsTo**
1811         relationship type.
1812
1813       **tosca.capabilities.nfv.VirtualLinkable**
1814
1815         A node type that includes the VirtualLinkable capability indicates
1816         that it can be pointed by **tosca.relationships.nfv.VirtualLinksTo**
1817         relationship.
1818
1819       **tosca.capabilities.nfv.ExtVirtualLinkable**
1820
1821         A node type that includes the ExtVirtualLinkable capability
1822         indicates that it can be pointed by
1823         **tosca.relationships.nfv.VirtualLinksTo** relationship.
1824
1825       **Note**: This capability type is used in Casablanca how it does
1826       not exist in the last SOL001 draft
1827
1828       **tosca.capabilities.nfv.VirtualCompute** and
1829       **tosca.capabilities.nfv.VirtualStorage** includes flavours of VDU
1830
1831
1832 ONAP TOSCA VNFD Requirements > TOSCA VNF Descriptor > Data Types
1833 ----------------------------------------------------------------
1834
1835
1836 Requirements Added
1837 ~~~~~~~~~~~~~~~~~~
1838
1839
1840 .. container:: note
1841
1842     :need:`R-54356`
1843
1844     The below table includes the data types used by NFV node and is based
1845     on TOSCA/YAML constructs specified in draft GS NFV-SOL 001. The node
1846     data definitions/attributes used in VNFD **MUST** comply with the below
1847     table.
1848
1849
1850 .. container:: note
1851
1852     :need:`R-54876`
1853
1854     The below table describes the data types used for LCM configuration
1855     and is based on TOSCA constructs specified in draft GS NFV-SOL 001.
1856     The LCM configuration data elements used in VNFD **MUST** comply
1857     with the below table.
1858
1859
1860 ONAP TOSCA VNFD Requirements > TOSCA VNF Descriptor > General
1861 -------------------------------------------------------------
1862
1863
1864 Requirements Added
1865 ~~~~~~~~~~~~~~~~~~
1866
1867
1868 .. container:: note
1869
1870     :need:`R-15837`
1871
1872     The following table defines the major TOSCA  Types specified in
1873     ETSI NFV-SOL001 standard draft. The VNFD provided by a VNF vendor
1874     **MUST** comply with the below definitions:
1875
1876
1877 .. container:: note
1878
1879     :need:`R-17852`
1880
1881     The VNFD **MAY** include TOSCA/YAML definitions that are not part of
1882     NFV Profile. If provided, these definitions MUST comply with TOSCA
1883     Simple Profile in YAML v.1.2.
1884
1885
1886 .. container:: note
1887
1888     :need:`R-35854`
1889
1890     The VNF Descriptor (VNFD) provided by VNF vendor **MUST** comply with
1891     TOSCA/YAML based Service template for VNF descriptor specified in
1892     ETSI NFV-SOL001.
1893
1894     **Note**: As the ETSI NFV-SOL001 is work in progress the below tables
1895     summarizes the TOSCA definitions agreed to be part of current version
1896     of NFV profile and that VNFD MUST comply with in ONAP Release 2+
1897     Requirements.
1898
1899
1900 .. container:: note
1901
1902     :need:`R-46527`
1903
1904     A VNFD is a deployment template which describes a VNF in terms of
1905     deployment and operational behavior requirements. It contains
1906     virtualized resources (nodes) requirements as well as connectivity
1907     and interfaces requirements and **MUST** comply with info elements
1908     specified in ETSI GS NFV-IFA 011. The main parts of the VNFD are
1909     the following:
1910
1911       - VNF topology: it is modeled in a cloud agnostic way using virtualized
1912         containers and their connectivity. Virtual Deployment Units (VDU)
1913         describe the capabilities of the virtualized containers, such as
1914         virtual CPU, RAM, disks; their connectivity is modeled with VDU
1915         Connection Point Descriptors (VduCpd), Virtual Link Descriptors
1916         (VnfVld) and VNF External Connection Point Descriptors
1917         (VnfExternalCpd);
1918
1919       - VNF deployment aspects: they are described in one or more
1920         deployment flavours, including configurable parameters, instantiation
1921         levels, placement constraints (affinity / antiaffinity), minimum and
1922         maximum VDU instance numbers. Horizontal scaling is modeled with
1923         scaling aspects and the respective scaling levels in the deployment
1924         flavours;
1925
1926     **Note**: The deployment aspects (deployment flavour etc.) are postponed
1927     for future ONAP releases.
1928
1929       - VNF lifecycle management (LCM) operations: describes the LCM operations
1930         supported per deployment flavour, and their input parameters;
1931         Note, thatthe actual LCM implementation resides in a different layer,
1932         namely referring to additional template artifacts.
1933
1934
1935 .. container:: note
1936
1937     :need:`R-65486`
1938
1939     The VNFD **MUST** comply with ETSI GS NFV-SOL001 document endorsing
1940     the above mentioned NFV Profile and maintaining the gaps with the
1941     requirements specified in ETSI GS NFV-IFA011 standard.
1942
1943
1944 ONAP TOSCA VNFD Requirements > TOSCA VNF Descriptor > Interface Types
1945 ---------------------------------------------------------------------
1946
1947
1948 Requirements Added
1949 ~~~~~~~~~~~~~~~~~~
1950
1951
1952 .. container:: note
1953
1954     :need:`R-32155`
1955
1956     The VNFD provided by VNF vendor may use the below described TOSCA
1957     interface types. An on-boarding entity (ONAP SDC) **MUST** support them.
1958
1959       **tosca.interfaces.nfv.vnf.lifecycle.Nfv** supports LCM operations
1960
1961
1962 ONAP TOSCA VNFD Requirements > TOSCA VNF Descriptor > Relationship Types
1963 ------------------------------------------------------------------------
1964
1965
1966 Requirements Added
1967 ~~~~~~~~~~~~~~~~~~
1968
1969
1970 .. container:: note
1971
1972     :need:`R-95321`
1973
1974     The VNFD provided by VNF vendor may use the below described TOSCA
1975     relationships. An on-boarding entity (ONAP SDC) **MUST** support them.
1976
1977       **tosca.relationships.nfv.VirtualBindsTo**
1978
1979         This relationship type represents an association relationship between
1980         VDU and CP node types.
1981
1982       **tosca.relationships.nfv.VirtualLinksTo**
1983
1984         This relationship type represents an association relationship between
1985         the VduCpd's and VirtualLinkDesc node types.
1986
1987
1988 ONAP TOSCA VNFD Requirements > VNF CSAR Package > VNF Package Contents
1989 ----------------------------------------------------------------------
1990
1991
1992 Requirements Added
1993 ~~~~~~~~~~~~~~~~~~
1994
1995
1996 .. container:: note
1997
1998     :need:`R-01123`
1999
2000     The VNF package Manifest file **MUST** contain: VNF package meta-data, a
2001     list of all artifacts (both internal and external) entry's including
2002     their respected URI's, an algorithm to calculate a digest and a digest
2003     result calculated on the content of each artifacts, as specified in
2004     ETSI GS NFV-SOL004. The VNF Package MUST include VNF Identification
2005     Data to uniquely identify the resource for a given VNF provider. The
2006     identification data must include: an identifier for the VNF, the name
2007     of the VNF as was given by the VNF provider, VNF description, VNF
2008     provider, and version.
2009
2010
2011 .. container:: note
2012
2013     :need:`R-10087`
2014
2015     The VNF package **MUST** contain all standard artifacts as specified in
2016     ETSI GS NFV-SOL004 including Manifest file, VNFD (or Main TOSCA/YAML
2017     based Service Template) and other optional artifacts. CSAR Manifest
2018     file as per SOL004 - for example ROOT\\ **MainServiceTemplate.mf**
2019
2020
2021 .. container:: note
2022
2023     :need:`R-21322`
2024
2025     The VNF provider **MUST** provide their testing scripts to support
2026     testing as specified in ETSI NFV-SOL004 - Testing directory in CSAR
2027
2028
2029 .. container:: note
2030
2031     :need:`R-26885`
2032
2033     The VNF provider **MUST** provide the binaries and images needed to
2034     instantiate the VNF (VNF and VNFC images) either as:
2035
2036       - Local artifact in CSAR: ROOT\\Artifacts\\ **VNF_Image.bin**
2037
2038       - externally referred (by URI) artifact in Manifest file (also may be
2039         referred by VNF Descriptor)
2040
2041     Note: Currently, ONAP doesn't have the capability of Image management,
2042     we upload the image into VIM/VNFM manually.
2043
2044
2045 .. container:: note
2046
2047     :need:`R-40820`
2048
2049     The VNF provider MUST enumerate all of the open source licenses
2050     their VNF(s) incorporate. CSAR License directory as per ETSI SOL004.
2051
2052     for example ROOT\\Licenses\\ **License_term.txt**
2053
2054
2055 ONAP TOSCA VNFD Requirements > VNF CSAR Package > VNF Package Structure and Format
2056 ----------------------------------------------------------------------------------
2057
2058
2059 Requirements Added
2060 ~~~~~~~~~~~~~~~~~~
2061
2062
2063 .. container:: note
2064
2065     :need:`R-51347`
2066
2067     The VNF package **MUST** be arranged as a CSAR archive as specified in
2068     TOSCA Simple Profile in YAML 1.2.
2069
2070
2071 .. container:: note
2072
2073     :need:`R-87234`
2074
2075     The VNF package provided by a VNF vendor **MAY** be either with
2076     TOSCA-Metadata directory (CSAR Option 1) or without TOSCA-Metadata
2077     directory (CSAR Option 2) as specified in ETSI GS NFV-SOL004. On-boarding
2078     entity (ONAP SDC) must support both options.
2079
2080     **Note:** SDC supports only the CSAR Option 1 in Casablanca. The Option 2
2081     will be considered in future ONAP releases,
2082
2083
2084 PNF Plug and Play > PNF Plug and Play
2085 -------------------------------------
2086
2087
2088 Requirements Added
2089 ~~~~~~~~~~~~~~~~~~
2090
2091
2092 .. container:: note
2093
2094     :need:`R-01427`
2095
2096     The PNF **MUST** support the provisioning of security and authentication
2097     parameters (HTTP username and password) in order to be able to authenticate
2098     with DCAE (in ONAP).
2099
2100     Note: In R3, a username and password are used with the DCAE VES Event
2101     Listener which are used for HTTP Basic Authentication.
2102
2103     Note: The configuration management and provisioning software are specific
2104     to a vendor architecture.
2105
2106
2107 .. container:: note
2108
2109     :need:`R-106240`
2110
2111     The following VES Events **MUST** be supported by the PNF: pnfRegistration
2112     VES Event, HVol VES Event, and Fault VES Event. These are onboarded via
2113     he SDC Design Studio.
2114
2115     Note: these VES Events are emitted from the PNF to support PNF Plug and
2116     Play, High Volume Measurements, and Fault events respectively.
2117
2118
2119 .. container:: note
2120
2121     :need:`R-17624`
2122
2123     The PNF **MAY** support the optional parameters for Service
2124     Configuration Parameters.
2125
2126     Note: These are detailed in the Stage 5 PnP
2127
2128     Note: These parameters are optional, and not all PNFs will support any
2129     or all of these parameters, it is up to the vendor and service provider
2130     to ascertain which ones are supported up to an including all of the ones
2131     that have been defined. Note: It is expected that there will be a growing
2132     list of supported configuration parameters in future releases of ONAP.
2133
2134
2135 .. container:: note
2136
2137     :need:`R-256347`
2138
2139     The PNF **MUST** support the Ansible protocol for a Service Configuration
2140     message exchange between the PNF and PNF Controller (in ONAP).
2141
2142     Note: this exchange may be either Ansible, Chef, or NetConf depending on
2143     the PNF. Note: The PNF Controller may be VF-C, APP-C or SDN-C based on the
2144     PNF and PNF domain. Note: for R3 (Casablanca) only Ansible is supported.
2145
2146
2147 .. container:: note
2148
2149     :need:`R-258352`
2150
2151     The PNF **MUST** support & accept the provisioning of an ONAP contact IP
2152     address (in IPv4 or IPv6 format).
2153
2154     Note: For example, it a possibility is that an external EMS would configure
2155     & provision the ONAP contact IP address to the PNF (in either IPv4 or
2156     IPv6 format). For the PNF Plug and Play Use Case, this IP address is the
2157     service provider's "point of entry" to the DCAE VES Listener.
2158
2159     Note: different service provider's network architecture may also require
2160     special setup to allow an external PNF to contact the ONAP installation.
2161     For example, in the AT&T network, a maintenance tunnel is used to access
2162     ONAP.
2163
2164
2165 .. container:: note
2166
2167     :need:`R-284934`
2168
2169     If the PNF encounters an error authenticating, reaching the ONAP DCAE VES
2170     Event listener or recieves an error response from sending the pnfRegistration
2171     VES Event, it **MAY** log the error, and notify the operator.
2172
2173     Note: the design of how errors are logged, retrieved and reported
2174     will be a vendor-specific architecture. Reporting faults and errors
2175     is also a vendor specific design. It is expected that the PNF shall
2176     have a means to log an error and notify a user when a fault condition
2177     occurs in trying to contact ONAP, authenticate or send a pnfRegistration
2178     event.
2179
2180
2181 .. container:: note
2182
2183     :need:`R-378131`
2184
2185     (Error Case) - If an error is encountered by the PNF during a
2186     Service Configuration exchange with ONAP, the PNF **MAY** log the
2187     error and notify an operator.
2188
2189
2190 .. container:: note
2191
2192     :need:`R-56718`
2193
2194     The PNF Vendor **MAY** provide software version(s) to be supported by PNF
2195     for SDC Design Studio PNF Model. This is set in the PNF Model property
2196     software_versions.
2197
2198
2199 .. container:: note
2200
2201     :need:`R-579051`
2202
2203     The PNF **MAY** support a HTTP connection to the DCAE VES Event Listener.
2204
2205     Note: HTTP is allowed but not recommended.
2206
2207
2208 .. container:: note
2209
2210     :need:`R-638216`
2211
2212     (Error Case) - The PNF **MUST** support a configurable timer to stop the
2213     periodicity sending of the pnfRegistration VES event. If this timer expires
2214     during a Service Configuration exchange between the PNF and ONAP, it
2215     MAY log a time-out error and notify an operator.
2216
2217     Note: It is expected that each vendor will enforce and define a PNF
2218     service configuration timeout period. This is because the PNF cannot
2219     wait indefinitely as there may also be a technician on-site trying to
2220     complete installation & commissioning. The management of the VES event
2221     exchange is also a requirement on the PNF to be developed by the PNF
2222     vendor.
2223
2224
2225 .. container:: note
2226
2227     :need:`R-686466`
2228
2229     The PNF **MUST** support sending a pnfRegistration VES event.
2230
2231
2232 .. container:: note
2233
2234     :need:`R-707977`
2235
2236     When the PNF receives a Service configuration from ONAP, the PNF **MUST**
2237     cease sending the pnfRegistration VES Event.
2238
2239
2240 .. container:: note
2241
2242     :need:`R-763774`
2243
2244     The PNF **MUST** support a HTTPS connection to the DCAE VES Event
2245     Listener.
2246
2247
2248 .. container:: note
2249
2250     :need:`R-793716`
2251
2252     The PNF **MUST** have "ONAP Aware" software which is capable of performing
2253     PNF PnP registration with ONAP. The "ONAP Aware" software is capable of
2254     performing the PNF PnP Registration with ONAP MUST either be loaded
2255     separately or integrated into the PNF software upon physical delivery
2256     and installation of the PNF.
2257
2258     Note: It is up to the specific vendor to design the software management
2259     functions.
2260
2261
2262 .. container:: note
2263
2264     :need:`R-809261`
2265
2266     The PNF **MUST** use a IP address to contact ONAP.
2267
2268     Note: it is expected that an ONAP operator can ascertain the ONAP IP
2269     address or the security gateway to reach ONAP on the VID or ONAP portal
2270     GUI.
2271
2272     Note: The ONAP contact IP address has been previously configured and
2273     provisioned prior to this step.
2274
2275     Note: The ONAP IP address could be provisioned or resolved through
2276     FQDN & DNS.
2277
2278
2279 .. container:: note
2280
2281     :need:`R-894004`
2282
2283     When the PNF sets up a HTTP or HTTPS connection, it **MUST** provide a
2284     username and password to the DCAE VES Collector for HTTP Basic
2285     Authentication.
2286
2287     Note: HTTP Basic Authentication has 4 steps: Request, Authenticate,
2288     Authorization with Username/Password Credentials, and Authentication Status
2289     as per RFC7617 and RFC 2617.
2290
2291
2292 .. container:: note
2293
2294     :need:`R-952314`
2295
2296     If the PNF set up a TLS connection and mutual (two-way) authentication is
2297     being used, then the PNF **MUST** provide its own X.509v3 Certificate to
2298     the DCAE VES Collector for authentication.
2299
2300     Note: This allows TLS authentication by DCAE VES Collector.
2301
2302     Note: The PNF got its X.509 certificate through Enrollment with an
2303     operator certificate authority or a X.509 vendor certificate from the
2304     vendor factory CA.
2305
2306     Note: In R3 three authentication options are supported:
2307
2308     (1) HTTP with Username & Password and no TLS.
2309
2310     (2) HTTP with Username & Password & TLS with two-way certificate
2311         authentication.
2312
2313     (3) HTTP with Username & Password & TLS with server-side
2314         certificate authentication.
2315
2316
2317 .. container:: note
2318
2319     :need:`R-980039`
2320
2321     The PNF **MUST** send the pnfRegistration VES event periodically.
2322
2323
2324 .. container:: note
2325
2326     :need:`R-981585`
2327
2328     The pnfRegistration VES event periodicity **MUST** be configurable.
2329
2330     Note: The PNF uses the service configuration request as a semaphore to
2331     stop sending the pnfRegistration sent. See the requirement PNP-5360
2332     requirement.
2333
2334
2335 Resource IDs
2336 ------------
2337
2338
2339 Requirements Changed
2340 ~~~~~~~~~~~~~~~~~~~~
2341
2342
2343 .. container:: note
2344
2345     :need:`R-98138`
2346
2347     When a VNF's Heat Orchestration Template's resource is associated with a
2348     single internal network, the Resource ID **MUST** contain the text
2349     ``int_{network-role}``.
2350
2351
2352 .. container:: note
2353
2354     :need:`R-67793`
2355
2356     When a VNF's Heat Orchestration Template's resource is associated
2357     with more than one ``{vm-type}`` and/or more than one internal and/or
2358     external network, the Resource ID **MUST** not contain the ``{vm-type}``
2359     and/or ``{network-role}``/``int_{network-role}``. It also should contain the
2360     term ``shared`` and/or contain text that identifies the VNF.
2361
2362
2363 .. container:: note
2364
2365     :need:`R-82115`
2366
2367     When a VNF's Heat Orchestration Template's resource is associated with a
2368     single ``{vm-type}``
2369     and a single external network, the Resource ID text **MUST** contain both
2370     the ``{vm-type}``
2371     and the ``{network-role}``
2372
2373     - the ``{vm-type}`` **MUST** appear before the ``{network-role}`` and
2374       **MUST** be separated by an underscore '_'
2375
2376
2377       - e.g., ``{vm-type}_{network-role}``, ``{vm-type}_{index}_{network-role}``
2378
2379
2380     - note that an ``{index}`` value **MAY** separate the ``{vm-type}`` and the
2381       ``{network-role}`` and when this occurs underscores **MUST** separate the
2382       three values.  (e.g., ``{vm-type}_{index}_{network-role}``).
2383
2384
2385 .. container:: note
2386
2387     :need:`R-82551`
2388
2389     When a VNF's Heat Orchestration Template's resource is associated with a
2390     single ``{vm-type}`` and a single internal network, the Resource ID **MUST**
2391     contain both the ``{vm-type}`` and the ``int_{network-role}`` and
2392
2393     - the ``{vm-type}`` **MUST** appear before the ``int_{network-role}`` and
2394       **MUST** be separated by an underscore '_'
2395
2396       - (e.g., ``{vm-type}_int_{network-role}``,
2397         ``{vm-type}_{index}_int_{network-role}``)
2398
2399     - note that an ``{index}`` value **MAY** separate the
2400       ``{vm-type}`` and the ``int_{network-role}`` and when this occurs
2401       underscores **MUST** separate the three values.
2402       (e.g., ``{vm-type}_{index}_int_{network-role}``).
2403
2404
2405 Resource IDs > Contrail Heat Resources Resource ID Naming Convention > OS::ContrailV2::VirtualNetwork
2406 -----------------------------------------------------------------------------------------------------
2407
2408
2409 Requirements Changed
2410 ~~~~~~~~~~~~~~~~~~~~
2411
2412
2413 .. container:: note
2414
2415     :need:`R-99110`
2416
2417     A VNF's Heat Orchestration Template's Resource
2418     ``OS::ContrailV2::VirtualNetwork`` Resource ID **MUST** use the naming convention
2419
2420     1) ``int_{network-role}_network``
2421
2422     or
2423
2424     2) ``int_{network-role}_RVN`` where RVN represents Resource Virtual
2425        Network
2426
2427     VNF Heat Orchestration Templates can only create internal networks.
2428     There is no ``{index}`` after ``{network-role}`` because ``{network-role}``
2429     **MUST** be unique in the scope of the VNF's
2430     Heat Orchestration Template.
2431
2432     Note that option 1 is preferred.
2433
2434
2435 Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Neutron::Net
2436 ----------------------------------------------------------------------------------------
2437
2438
2439 Requirements Changed
2440 ~~~~~~~~~~~~~~~~~~~~
2441
2442
2443 .. container:: note
2444
2445     :need:`R-25720`
2446
2447     A VNF's Heat Orchestration Template's Resource ``OS::Neutron::Net``
2448     Resource ID **MUST** use the naming convention
2449
2450     * ``int_{network-role}_network``
2451
2452     VNF Heat Orchestration Templates can only create internal networks.
2453     There is no ``{index}`` after ``{network-role}`` because ``{network-role}``
2454     **MUST** be unique in the scope of the VNF's
2455     Heat Orchestration Template.
2456
2457
2458 Resource: OS::Neutron::Port - Parameters > Introduction > Items to Note
2459 -----------------------------------------------------------------------
2460
2461
2462 Requirements Changed
2463 ~~~~~~~~~~~~~~~~~~~~
2464
2465
2466 .. container:: note
2467
2468     :need:`R-48880`
2469
2470     If a VNF's Port is attached to an external network and the port's
2471     IP addresses are assigned by ONAP's SDN-Controller,
2472     the ``OS::Neutron::Port`` Resource's
2473
2474     * property ``fixed_ips`` map property ``ip_address`` **MUST** be used
2475     * property ``fixed_ips`` map property ``subnet``
2476       **MUST NOT** be used
2477
2478
2479 .. container:: note
2480
2481     :need:`R-45602`
2482
2483     If a VNF's Port is attached to a network (internal or external)
2484     and the port's IP addresses are cloud assigned by OpenStack's DHCP
2485     Service, the ``OS::Neutron::Port`` Resource's
2486
2487     * property ``fixed_ips`` map property ``ip_address`` **MUST NOT** be used
2488     * property ``fixed_ips`` map property ``subnet``
2489       **MAY** be used
2490
2491
2492 .. container:: note
2493
2494     :need:`R-70964`
2495
2496     If a VNF's Port is attached to an internal network and the port's
2497     IP addresses are statically assigned by the VNF's Heat Orchestration\
2498     Template (i.e., enumerated in the Heat Orchestration Template's
2499     environment file), the ``OS::Neutron::Port`` Resource's
2500
2501     * property ``fixed_ips`` map property ``ip_address`` **MUST** be used
2502     * property ``fixed_ips`` map property ``subnet``
2503       **MUST NOT** be used
2504
2505
2506 Resource: OS::Neutron::Port - Parameters > Property: allowed_address_pairs, Map Property: ip_address > VIP Assignment, External Networks, Supported by Automation
2507 -----------------------------------------------------------------------------------------------------------------------------------------------------------------
2508
2509
2510 Requirements Changed
2511 ~~~~~~~~~~~~~~~~~~~~
2512
2513
2514 .. container:: note
2515
2516     :need:`R-35735`
2517
2518     When the VNF's Heat Orchestration Template's Resource
2519     ``OS::Neutron::Port`` is attaching to an external network (per the
2520     ONAP definition, see Requirement R-57424),
2521     and an IPv6 Virtual IP (VIP)
2522     address is assigned via ONAP automation
2523     using the property ``allowed_address_pairs``
2524     map property ``ip_address``,
2525     the parameter name **MUST** follow the
2526     naming convention
2527
2528       * ``{vm-type}_{network-role}_floating_v6_ip``
2529
2530     where
2531
2532       * ``{vm-type}`` is the {vm-type} associated with the
2533         OS::Nova::Server
2534       * ``{network-role}`` is the {network-role} of the external
2535         network
2536
2537     And the parameter **MUST** be declared as type ``string``.
2538
2539
2540 .. container:: note
2541
2542     :need:`R-41492`
2543
2544     When the VNF's Heat Orchestration Template's Resource
2545     ``OS::Neutron::Port`` is attaching to an external network (per the
2546     ONAP definition, see Requirement R-57424),
2547     and an IPv4 Virtual IP (VIP)
2548     address is assigned via ONAP automation
2549     using the property ``allowed_address_pairs``
2550     map property ``ip_address`` and
2551     the parameter name **MUST** follow the
2552     naming convention
2553
2554       * ``{vm-type}_{network-role}_floating_ip``
2555
2556     where
2557
2558       * ``{vm-type}`` is the {vm-type} associated with the
2559         OS::Nova::Server
2560       * ``{network-role}`` is the {network-role} of the external
2561         network
2562
2563     And the parameter **MUST** be declared as type ``string``.
2564
2565
2566 Resource: OS::Neutron::Port - Parameters > Property: fixed_ips, Map Property: ip_address
2567 ----------------------------------------------------------------------------------------
2568
2569
2570 Requirements Changed
2571 ~~~~~~~~~~~~~~~~~~~~
2572
2573
2574 .. container:: note
2575
2576     :need:`R-28795`
2577
2578     The VNF's Heat Orchestration Template's Resource
2579     ``OS::Neutron::Port`` property ``fixed_ips``
2580     map property ``ip_address`` parameter
2581     ``{vm-type}_int_{network-role}_ip_{index}``
2582     **MUST** be enumerated in the
2583     VNF's Heat Orchestration Template's Environment File.
2584
2585
2586 .. container:: note
2587
2588     :need:`R-39841`
2589
2590     The VNF's Heat Orchestration Template's Resource
2591     ``OS::Neutron::Port`` property ``fixed_ips``
2592     map property ``ip_address`` parameter
2593     ``{vm-type}_{network-role}_ip_{index}``
2594     **MUST NOT** be enumerated in the
2595     VNF's Heat Orchestration Template's Environment File.
2596
2597
2598 .. container:: note
2599
2600     :need:`R-85235`
2601
2602     When the VNF's Heat Orchestration Template's Resource
2603     ``OS::Neutron::Port`` is attaching to an internal network (per the
2604     ONAP definition, see Requirements R-52425 and R-46461),
2605     and an IPv4 address is assigned
2606     using the property ``fixed_ips``
2607     map property ``ip_address`` and the parameter type is defined as a
2608     ``comma_delimited_list``,
2609     the parameter name **MUST** follow the
2610     naming convention
2611
2612       * ``{vm-type}_int_{network-role}_ips``
2613
2614     where
2615
2616       * ``{vm-type}`` is the {vm-type} associated with the
2617         ``OS::Nova::Server``
2618       * ``{network-role}`` is the {network-role} of the internal
2619         network
2620
2621
2622 .. container:: note
2623
2624     :need:`R-78380`
2625
2626     When the VNF's Heat Orchestration Template's Resource
2627     ``OS::Neutron::Port`` is attaching to an internal network (per the
2628     ONAP definition, see Requirements R-52425 and R-46461),
2629     and an IPv4 address is assigned
2630     using the property ``fixed_ips``
2631     map property ``ip_address`` and the parameter type is
2632     defined as a ``string``,
2633     the parameter name **MUST** follow the
2634     naming convention
2635
2636       * ``{vm-type}_int_{network-role}_ip_{index}``
2637
2638     where
2639
2640       * ``{vm-type}`` is the {vm-type} associated with the
2641         OS::Nova::Server
2642       * ``{network-role}`` is the {network-role} of the internal
2643         network
2644       * the value for ``{index`` must start at zero (0) and increment by one
2645
2646
2647 .. container:: note
2648
2649     :need:`R-90206`
2650
2651     The VNF's Heat Orchestration Template's Resource
2652     ``OS::Neutron::Port`` property ``fixed_ips``
2653     map property ``ip_address`` parameter
2654     ``{vm-type}_int_{network-role}_int_ips``
2655     **MUST** be enumerated in the
2656     VNF's Heat Orchestration Template's Environment File.
2657
2658
2659 .. container:: note
2660
2661     :need:`R-23503`
2662
2663     When the VNF's Heat Orchestration Template's Resource
2664     ``OS::Neutron::Port`` is attaching to an external network (per the
2665     ONAP definition, see Requirement R-57424),
2666     and an IPv6 address is assigned
2667     using the property ``fixed_ips``
2668     map property ``ip_address`` and the parameter type is defined as a
2669     ``comma_delimited_list``,
2670     the parameter name **MUST** follow the
2671     naming convention
2672
2673       * ``{vm-type}_{network-role}_v6_ips``
2674
2675     where
2676
2677       * ``{vm-type}`` is the {vm-type} associated with the
2678         OS::Nova::Server
2679       * ``{network-role}`` is the {network-role} of the external
2680         network
2681
2682
2683 .. container:: note
2684
2685     :need:`R-87123`
2686
2687     The VNF's Heat Orchestration Template's Resource
2688     ``OS::Neutron::Port`` property ``fixed_ips``
2689     map property ``ip_address`` parameter
2690     ``{vm-type}_{network-role}_v6_ip_{index}``
2691     **MUST NOT** be enumerated in the
2692     VNF's Heat Orchestration Template's Environment File.
2693
2694
2695 .. container:: note
2696
2697     :need:`R-98569`
2698
2699     The VNF's Heat Orchestration Template's Resource
2700     ``OS::Neutron::Port`` property ``fixed_ips``
2701     map property ``ip_address`` parameter
2702     ``{vm-type}_int_{network-role}_v6_ips``
2703     **MUST** be enumerated in the
2704     VNF's Heat Orchestration Template's Environment File.
2705
2706
2707 .. container:: note
2708
2709     :need:`R-93496`
2710
2711     The VNF's Heat Orchestration Template's Resource ``OS::Neutron::Port``
2712     property ``fixed_ips``
2713     map property ``ip_address``
2714     parameter associated with an internal network, i.e.,
2715
2716      * ``{vm-type}_int_{network-role}_ip_{index}``
2717      * ``{vm-type}_int_{network-role}_v6_ip_{index}``
2718      * ``{vm-type}_int_{network-role}_ips``
2719      * ``{vm-type}_int_{network-role}_v6_ips``
2720
2721
2722     **MUST** be enumerated in the Heat Orchestration
2723     Template's Environment File and IP addresses **MUST** be
2724     assigned.
2725
2726
2727 .. container:: note
2728
2729     :need:`R-40971`
2730
2731     When the VNF's Heat Orchestration Template's Resource
2732     ``OS::Neutron::Port`` is attaching to an external network (per the
2733     ONAP definition, see Requirement R-57424),
2734     and an IPv4 address is assigned
2735     using the property ``fixed_ips``
2736     map property ``ip_address`` and the parameter type is defined as a string,
2737     the parameter name **MUST** follow the
2738     naming convention
2739
2740       * ``{vm-type}_{network-role}_ip_{index}``
2741
2742       where
2743
2744       * ``{vm-type}`` is the {vm-type} associated with the
2745         ``OS::Nova::Server``
2746       * ``{network-role}`` is the {network-role} of the external
2747         network
2748       * the value for ``{index}`` must start at zero (0) and increment by one
2749
2750
2751 .. container:: note
2752
2753     :need:`R-29765`
2754
2755     When the VNF's Heat Orchestration Template's Resource
2756     ``OS::Neutron::Port`` is attaching to an internal network (per the
2757     ONAP definition, see Requirements R-52425 and R-46461),
2758     and an IPv6 address is assigned
2759     using the property ``fixed_ips``
2760     map property ``ip_address`` and the parameter type is defined as a
2761     ``comma_delimited_list``,
2762     the parameter name **MUST** follow the
2763     naming convention
2764
2765       * ``{vm-type}_int_{network-role}_v6_ips``
2766
2767     where
2768
2769       * ``{vm-type}`` is the {vm-type} associated with the
2770         ``OS::Nova::Server``
2771       * ``{network-role}`` is the {network-role} of the internal
2772         network
2773
2774
2775 .. container:: note
2776
2777     :need:`R-71577`
2778
2779     When the VNF's Heat Orchestration Template's Resource
2780     ``OS::Neutron::Port`` is attaching to an external network (per the
2781     ONAP definition, see Requirement R-57424),
2782     and an IPv6 address is assigned
2783     using the property ``fixed_ips``
2784     map property ``ip_address`` and the parameter type is defined as a string,
2785     the parameter name **MUST** follow the
2786     naming convention
2787
2788       * ``{vm-type}_{network-role}_v6_ip_{index}``
2789
2790       where
2791
2792       * ``{vm-type}`` is the {vm-type} associated with the
2793         OS::Nova::Server
2794       * ``{network-role}`` is the {network-role} of the external
2795         network
2796       * the value for ``{index}`` must start at zero (0) and increment by one
2797
2798
2799 .. container:: note
2800
2801     :need:`R-62590`
2802
2803     The VNF's Heat Orchestration Template's Resource ``OS::Neutron::Port``
2804     property ``fixed_ips``
2805     map property ``ip_address``
2806     parameter associated with an external network, i.e.,
2807
2808      * ``{vm-type}_{network-role}_ip_{index}``
2809      * ``{vm-type}_{network-role}_v6_ip_{index}``
2810      * ``{vm-type}_{network-role}_ips``
2811      * ``{vm-type}_{network-role}_v6_ips``
2812
2813
2814     **MUST NOT** be enumerated in the Heat Orchestration
2815     Template's Environment File.  ONAP provides the IP address
2816     assignments at orchestration time.
2817
2818
2819 .. container:: note
2820
2821     :need:`R-04697`
2822
2823     When the VNF's Heat Orchestration Template's Resource
2824     ``OS::Neutron::Port`` is attaching to an external network (per the
2825     ONAP definition, see Requirement R-57424),
2826     and an IPv4 address is assigned
2827     using the property ``fixed_ips``
2828     map property ``ip_address`` and the parameter type is defined as a
2829     ``comma_delimited_list``,
2830     the parameter name **MUST** follow the
2831     naming convention
2832
2833       * ``{vm-type}_{network-role}_ips``
2834
2835       where
2836
2837       * ``{vm-type}`` is the {vm-type} associated with the
2838         ``OS::Nova::Server``
2839       * ``{network-role}`` is the {network-role} of the external
2840         network
2841
2842
2843 .. container:: note
2844
2845     :need:`R-97201`
2846
2847     The VNF's Heat Orchestration Template's Resource
2848     ``OS::Neutron::Port`` property ``fixed_ips``
2849     map property ``ip_address`` parameter
2850     ``{vm-type}_int_{network-role}_v6_ip_{index}``
2851     **MUST** be enumerated in the
2852     VNF's Heat Orchestration Template's Environment File.
2853
2854
2855 .. container:: note
2856
2857     :need:`R-27818`
2858
2859     When the VNF's Heat Orchestration Template's Resource
2860     ``OS::Neutron::Port`` is attaching to an internal network (per the
2861     ONAP definition, see RRequirements R-52425 and R-46461),
2862     and an IPv6 address is assigned
2863     using the property ``fixed_ips``
2864     map property ``ip_address`` and the parameter type is defined as a
2865     ``string``,
2866     the parameter name **MUST** follow the
2867     naming convention
2868
2869       * ``{vm-type}_int_{network-role}_v6_ip_{index}``
2870
2871     where
2872
2873       * ``{vm-type}`` is the {vm-type} associated with the
2874         ``OS::Nova::Server``
2875       * ``{network-role}`` is the {network-role} of the internal
2876         network
2877       * the value for ``{index}`` must start at zero (0) and increment by one
2878
2879
2880 Resource: OS::Neutron::Port - Parameters > Property: fixed_ips, Map Property: subnet
2881 ------------------------------------------------------------------------------------
2882
2883
2884 Requirements Changed
2885 ~~~~~~~~~~~~~~~~~~~~
2886
2887
2888 .. container:: note
2889
2890     :need:`R-84123`
2891
2892     When
2893
2894       * the VNF's Heat Orchestration Template's
2895         resource ``OS::Neutron::Port`` in an Incremental Module is attaching
2896         to an internal network (per the ONAP definition, see
2897         Requirements R-52425 and R-46461)
2898         that is created in the Base Module, AND
2899       * an IPv4 address is being cloud assigned by OpenStack's DHCP Service AND
2900       * the internal network IPv4 subnet is to be specified
2901         using the property ``fixed_ips`` map property ``subnet``,
2902
2903     the parameter **MUST** follow the naming convention
2904
2905       * ``int_{network-role}_subnet_id``
2906
2907     where
2908
2909       * ``{network-role}`` is the network role of the internal network
2910
2911     Note that the parameter **MUST** be defined as an ``output`` parameter in
2912     the base module.
2913
2914
2915 .. container:: note
2916
2917     :need:`R-62802`
2918
2919     When the VNF's Heat Orchestration Template's
2920     resource ``OS::Neutron::Port`` is attaching
2921     to an external network (per the ONAP definition, see
2922     Requirement R-57424),
2923     and an IPv4 address is being cloud assigned by OpenStack's DHCP Service
2924     and the external network IPv4 subnet is to be specified
2925     using the property ``fixed_ips``
2926     map property ``subnet``, the parameter
2927     **MUST** follow the naming convention
2928
2929       * ``{network-role}_subnet_id``
2930
2931     where
2932
2933       * ``{network-role}`` is the network role of the network.
2934
2935
2936 .. container:: note
2937
2938     :need:`R-22288`
2939
2940     The VNF's Heat Orchestration Template's Resource
2941     ``OS::Neutron::Port`` property ``fixed_ips``
2942     map property ``subnet`` parameter
2943     ``int_{network-role}_v6_subnet_id``
2944     **MUST NOT** be enumerated in the
2945     VNF's Heat Orchestration Template's Environment File.
2946
2947
2948 .. container:: note
2949
2950     :need:`R-76160`
2951
2952     When
2953
2954       * the VNF's Heat Orchestration Template's
2955         resource ``OS::Neutron::Port`` in an Incremental Module is attaching
2956         to an internal network (per the ONAP definition, see Requirements
2957         R-52425 and R-46461)
2958         that is created in the Base Module, AND
2959       * an IPv6 address is being cloud assigned by OpenStack's DHCP Service AND
2960       * the internal network IPv6 subnet is to be specified
2961         using the property ``fixed_ips`` map property ``subnet``,
2962
2963     the parameter **MUST** follow the naming convention
2964     ``int_{network-role}_v6_subnet_id``,
2965     where ``{network-role}`` is the network role of the internal network.
2966
2967     Note that the parameter **MUST** be defined as an ``output`` parameter in
2968     the base module.
2969
2970
2971 .. container:: note
2972
2973     :need:`R-15287`
2974
2975     When the VNF's Heat Orchestration Template's
2976     resource ``OS::Neutron::Port`` is attaching
2977     to an external network (per the ONAP definition, see
2978     Requirement R-57424),
2979     and an IPv6 address is being cloud assigned by OpenStack's DHCP Service
2980     and the external network IPv6 subnet is to be specified
2981     using the property ``fixed_ips``
2982     map property ``subnet``, the parameter
2983     **MUST** follow the naming convention
2984
2985       * ``{network-role}_v6_subnet_id``
2986
2987     where
2988
2989       * ``{network-role}`` is the network role of the network.
2990
2991
2992 .. container:: note
2993
2994     :need:`R-83677`
2995
2996     The VNF's Heat Orchestration Template's Resource
2997     ``OS::Neutron::Port`` property ``fixed_ips``
2998     map property ``subnet`` parameter
2999     ``{network-role}_subnet_id``
3000     **MUST NOT** be enumerated in the
3001     VNF's Heat Orchestration Template's Environment File.
3002
3003
3004 .. container:: note
3005
3006     :need:`R-80829`
3007
3008     The VNF's Heat Orchestration Template's Resource
3009     ``OS::Neutron::Port`` property ``fixed_ips``
3010     map property ``subnet`` parameter
3011     ``{network-role}_v6_subnet_id``
3012     **MUST NOT** be enumerated in the
3013     VNF's Heat Orchestration Template's Environment File.
3014
3015
3016 .. container:: note
3017
3018     :need:`R-38236`
3019
3020     The VNF's Heat Orchestration Template's
3021     resource ``OS::Neutron::Port`` property ``fixed_ips``
3022     map property ``subnet`` parameter
3023     **MUST** be declared type ``string``.
3024
3025
3026 .. container:: note
3027
3028     :need:`R-69634`
3029
3030     The VNF's Heat Orchestration Template's Resource
3031     ``OS::Neutron::Port`` property ``fixed_ips``
3032     map property ``subnet`` parameter
3033     ``int_{network-role}_subnet_id``
3034     **MUST NOT** be enumerated in the
3035     VNF's Heat Orchestration Template's Environment File.
3036
3037
3038 Resource: OS::Neutron::Port - Parameters > Property: network
3039 ------------------------------------------------------------
3040
3041
3042 Requirements Changed
3043 ~~~~~~~~~~~~~~~~~~~~
3044
3045
3046 .. container:: note
3047
3048     :need:`R-29872`
3049
3050     The VNF's Heat Orchestration Template's Resource ``OS::Neutron::Port``
3051     property ``network``
3052     parameter **MUST NOT** be enumerated in the Heat Orchestration
3053     Template's Environment File.
3054
3055
3056 .. container:: note
3057
3058     :need:`R-62983`
3059
3060     When the VNF's Heat Orchestration Template's Resource
3061     ``OS::Neutron::Port`` is attaching to an external network (per the
3062     ONAP definition, see Requirement R-57424), the
3063     ``network`` parameter name **MUST**
3064
3065       * follow the naming convention ``{network-role}_net_id`` if the Neutron
3066         network UUID value is used to reference the network
3067       * follow the naming convention ``{network-role}_net_name`` if the
3068         OpenStack network name is used to reference the network.
3069
3070     where ``{network-role}`` is the network-role of the external network
3071     and a ``get_param`` **MUST** be used as the intrinsic function.
3072
3073
3074 .. container:: note
3075
3076     :need:`R-93177`
3077
3078     When the VNF's Heat Orchestration Template's resource
3079     ``OS::Neutron::Port`` is attaching to an internal network (per the
3080     ONAP definition, see Requirements R-52425 and R-46461),
3081     and the internal network is created in the
3082     same Heat Orchestration Template as the ``OS::Neutron::Port``,
3083     the ``network`` property value **MUST** obtain the UUID
3084     of the internal network by using the intrinsic function
3085     ``get_resource``
3086     and referencing the Resource ID of the internal network.
3087
3088
3089 .. container:: note
3090
3091     :need:`R-86182`
3092
3093     When the VNF's Heat Orchestration Template's Resource
3094     ``OS::Neutron::Port`` is attaching to an internal network (per the
3095     ONAP definition, see Requirements R-52425 and R-46461),
3096     and the internal network is created in a
3097     different Heat Orchestration Template than the ``OS::Neutron::Port``,
3098     the ``network`` parameter name **MUST**
3099
3100       * follow the naming convention ``int_{network-role}_net_id`` if the Neutron
3101         network UUID value is used to reference the network
3102       * follow the naming convention ``int_{network-role}_net_name`` if the
3103         OpenStack network name in is used to reference the network.
3104
3105     where ``{network-role}`` is the network-role of the internal network and
3106     a ``get_param`` **MUST** be used as the intrinsic function.
3107
3108
3109 Resource: OS::Nova::Server - Parameters
3110 ---------------------------------------
3111
3112
3113 Requirements Added
3114 ~~~~~~~~~~~~~~~~~~
3115
3116
3117 .. container:: note
3118
3119     :need:`R-304011`
3120
3121     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource's
3122
3123     * Resource ID
3124     * property ``image`` parameter name
3125     * property ``flavor`` parameter name
3126     * property ``name`` parameter name
3127
3128
3129     **MUST** contain the identical ``{vm-type}``
3130     and **MUST** follow the naming conventions defined
3131     in R-58670, R-45188, R-54171, R-87817, and R-29751.
3132
3133
3134 Resource: OS::Nova::Server - Parameters > Property: Name
3135 --------------------------------------------------------
3136
3137
3138 Requirements Added
3139 ~~~~~~~~~~~~~~~~~~
3140
3141
3142 .. container:: note
3143
3144     :need:`R-663631`
3145
3146     The VNF's Heat Orchestration Template's Resource ``OS::Nova::Server``
3147     property ``name`` value **MUST** be be obtained via a ``get_param``.
3148
3149
3150 Requirements Changed
3151 ~~~~~~~~~~~~~~~~~~~~
3152
3153
3154 .. container:: note
3155
3156     :need:`R-40899`
3157
3158     When the VNF's Heat Orchestration Template's Resource ``OS::Nova::Server``
3159     property ``name`` parameter is defined as a ``string``, a parameter
3160     **MUST** be delcared for
3161     each ``OS::Nova::Server`` resource associated with the ``{vm-type}``.
3162
3163
3164 .. container:: note
3165
3166     :need:`R-54171`
3167
3168     When the VNF's Heat Orchestration Template's Resource ``OS::Nova::Server``
3169     property ``name`` parameter is defined as a ``string``,
3170     the parameter name **MUST** follow the naming convention
3171     ``{vm-type}_name_{index}``, where ``{index}`` is a numeric
3172     value that starts at
3173     zero and increments by one.
3174
3175
3176 .. container:: note
3177
3178     :need:`R-51430`
3179
3180     The VNF's Heat Orchestration Template's Resource ``OS::Nova::Server``
3181     property
3182     ``name`` parameter **MUST** be declared as either type ``string``
3183     or type ``comma_delimited_list``.
3184
3185
3186 Resource: OS::Nova::Server - Parameters > Property: Name > Contrail Issue with Values for OS::Nova::Server Property Name
3187 ------------------------------------------------------------------------------------------------------------------------
3188
3189
3190 Requirements Changed
3191 ~~~~~~~~~~~~~~~~~~~~
3192
3193
3194 .. container:: note
3195
3196     :need:`R-44271`
3197
3198     The VNF's Heat Orchestration Template's Resource ``OS::Nova::Server``
3199     property
3200     ``name`` parameter value **SHOULD NOT** contain special characters
3201     since the Contrail GUI has a limitation displaying special characters.
3202
3203     However, if special characters must be used, the only special characters
3204     supported are: --- \" ! $ ' (\ \ ) = ~ ^ | @ ` { } [ ] > , . _
3205
3206
3207 Resource: OS::Nova::Server - Parameters > Property: availability_zone
3208 ---------------------------------------------------------------------
3209
3210
3211 Requirements Changed
3212 ~~~~~~~~~~~~~~~~~~~~
3213
3214
3215 .. container:: note
3216
3217     :need:`R-01359`
3218
3219     A VNF's Heat Orchestration Template that contains an ``OS::Nova:Server``
3220     Resource **MAY** define a parameter for the property
3221     ``availability_zone`` that is not utilized in any ``OS::Nova::Server``
3222     resources in the Heat Orchestration Template.
3223
3224
3225 .. container:: note
3226
3227     :need:`R-98450`
3228
3229     The VNF's Heat Orchestration Template's Resource ``OS::Nova::Server``
3230     property
3231     ``availability_zone`` parameter name **MUST** follow the naming convention
3232     ``availability_zone_{index}`` where the ``{index}``
3233     **MUST** start at zero and
3234     increment by one.
3235
3236
3237 Resource: OS::Nova::Server - Parameters > Property: flavor
3238 ----------------------------------------------------------
3239
3240
3241 Requirements Added
3242 ~~~~~~~~~~~~~~~~~~
3243
3244
3245 .. container:: note
3246
3247     :need:`R-481670`
3248
3249     The VNF's Heat Orchestration Template's Resource ``OS::Nova::Server``
3250     property ``flavor`` value **MUST** be be obtained via a ``get_param``.
3251
3252
3253 Resource: OS::Nova::Server - Parameters > Property: image
3254 ---------------------------------------------------------
3255
3256
3257 Requirements Added
3258 ~~~~~~~~~~~~~~~~~~
3259
3260
3261 .. container:: note
3262
3263     :need:`R-901331`
3264
3265     The VNF's Heat Orchestration Template's Resource ``OS::Nova::Server``
3266     property ``image`` value **MUST** be be obtained via a ``get_param``.
3267
3268
3269 Resource: OS::Nova::Server Metadata Parameters > environment_context
3270 --------------------------------------------------------------------
3271
3272
3273 Requirements Changed
3274 ~~~~~~~~~~~~~~~~~~~~
3275
3276
3277 .. container:: note
3278
3279     :need:`R-13194`
3280
3281     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3282     property
3283     ``metadata`` key/value pair ``environment_context`` **MUST NOT**
3284     be enumerated in the Heat Orchestration Template's environment file.
3285
3286
3287 .. container:: note
3288
3289     :need:`R-56183`
3290
3291     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3292     property ``metadata``key/value pair ``environment_context``
3293     parameter ``environment_context`` **MUST NOT**
3294     have parameter constraints defined.
3295
3296
3297 .. container:: note
3298
3299     :need:`R-20308`
3300
3301     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3302     property ``metadata`` key/value pair ``environment_context``
3303     parameter **MUST** be declared as ``environment_context`` and the
3304     parameter type **MUST** be defined as type: ``string``.
3305
3306
3307 Resource: OS::Nova::Server Metadata Parameters > vf_module_id
3308 -------------------------------------------------------------
3309
3310
3311 Requirements Changed
3312 ~~~~~~~~~~~~~~~~~~~~
3313
3314
3315 .. container:: note
3316
3317     :need:`R-86237`
3318
3319     If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3320     property
3321     ``metadata`` key/value pair ``vf_module_id`` is passed into a
3322     Nested YAML
3323     file, the key/value pair name ``vf_module_id`` **MUST NOT** change.
3324
3325
3326 .. container:: note
3327
3328     :need:`R-71493`
3329
3330     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3331     property ``metadata`` **MUST**
3332     contain the key/value pair ``vf_module_id``
3333     and the value MUST be obtained via a ``get_param``.
3334
3335
3336 .. container:: note
3337
3338     :need:`R-82134`
3339
3340     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource property
3341     ``metadata`` key/value pair ``vf_module_id`` parameter **MUST**
3342     be declared as ``vf_module_id`` and the parameter **MUST**
3343     be defined as type: ``string``.
3344
3345
3346 .. container:: note
3347
3348     :need:`R-98374`
3349
3350     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource property
3351     ``metadata`` key/value pair ``vf_module_id`` parameter ``vf_module_id``
3352     **MUST NOT**
3353     have parameter constraints defined.
3354
3355
3356 .. container:: note
3357
3358     :need:`R-72871`
3359
3360     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource property
3361     ``metadata`` key/value pair ``vf_module_id`` parameter ``vf_module_id``
3362     **MUST NOT**
3363     be enumerated in the Heat Orchestration Template's environment file.
3364
3365
3366 Resource: OS::Nova::Server Metadata Parameters > vf_module_index
3367 ----------------------------------------------------------------
3368
3369
3370 Requirements Changed
3371 ~~~~~~~~~~~~~~~~~~~~
3372
3373
3374 .. container:: note
3375
3376     :need:`R-37039`
3377
3378     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3379     property
3380     ``metadata`` key/value pair ``vf_module_index`` parameter
3381     ``vf_module_index`` **MUST NOT**
3382     be enumerated in the Heat Orchestration Template's environment file.
3383
3384
3385 .. container:: note
3386
3387     :need:`R-09811`
3388
3389     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3390     property ``metadata`` key/value pair ``vf_module_index`` **MUST NOT**
3391     have parameter constraints defined.
3392
3393
3394 .. container:: note
3395
3396     :need:`R-22441`
3397
3398     If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3399     property ``metadata`` key/value pair ``vf_module_index`` is passed into a
3400     Nested YAML file, the key/value pair
3401     ``vf_module_index`` **MUST NOT** change.
3402
3403
3404 .. container:: note
3405
3406     :need:`R-50816`
3407
3408     A VNF's Heat Orchestration Template's ``OS::Nova::Server``
3409     resource  property ``metadata`` **MAY**
3410     contain the key/value pair ``vf_module_index``
3411     and the value **MUST** be obtained via a ``get_param``.
3412
3413
3414 .. container:: note
3415
3416     :need:`R-55306`
3417
3418     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3419     property ``metadata`` key/value pair ``vf_module_index`` **MUST NOT**
3420     be used in a ``OS::Cinder::Volume`` resource and **MUST NOT** be
3421     used in VNF's Volume template;
3422     it is not supported.
3423
3424
3425 .. container:: note
3426
3427     :need:`R-54340`
3428
3429     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3430     property
3431     ``metadata`` key/value pair ``vf_module_index`` parameter **MUST**
3432     be declared as ``vf_module_index`` and the parameter **MUST** be
3433     defined as type: ``number``.
3434
3435
3436 Resource: OS::Nova::Server Metadata Parameters > vf_module_name
3437 ---------------------------------------------------------------
3438
3439
3440 Requirements Changed
3441 ~~~~~~~~~~~~~~~~~~~~
3442
3443
3444 .. container:: note
3445
3446     :need:`R-68023`
3447
3448     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3449     property ``metadata`` **SHOULD**
3450     contain the key/value pair ``vf_module_name`` and the value **MUST**
3451     be obtained via a ``get_param``.
3452
3453
3454 .. container:: note
3455
3456     :need:`R-49177`
3457
3458     If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3459     property ``metadata`` key/value pair ``vf_module_name`` is passed into a
3460     Nested YAML
3461     file, the key/value pair name ``vf_module_name`` **MUST NOT** change.
3462
3463
3464 .. container:: note
3465
3466     :need:`R-80374`
3467
3468     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3469     property ``metadata`` key/value pair ``vf_module_name``
3470     parameter ``vf_module_name`` **MUST NOT**
3471     be enumerated in the Heat Orchestration Template's environment file.
3472
3473
3474 .. container:: note
3475
3476     :need:`R-15480`
3477
3478     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3479     property
3480     ``metadata`` key/value pair ``vf_module_name`` parameter ``vf_module_name``
3481     **MUST NOT** have parameter constraints defined.
3482
3483
3484 .. container:: note
3485
3486     :need:`R-39067`
3487
3488     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3489     property
3490     ``metadata`` key/value pair ``vf_module_name`` parameter **MUST** be
3491     declared as ``vf_module_name`` and the parameter **MUST**
3492     be defined as type: ``string``.
3493
3494
3495 Resource: OS::Nova::Server Metadata Parameters > vm_role
3496 --------------------------------------------------------
3497
3498
3499 Requirements Changed
3500 ~~~~~~~~~~~~~~~~~~~~
3501
3502
3503 .. container:: note
3504
3505     :need:`R-67597`
3506
3507     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3508     property ``metadata`` key/value pair ``vm_role`` parameter ``vm_role``
3509     **MUST NOT** have parameter constraints defined.
3510
3511
3512 .. container:: note
3513
3514     :need:`R-70757`
3515
3516     If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3517     property ``metadata`` key/value pair ``vm_role`` is passed into a Nested
3518     YAML
3519     file, the key/value pair name ``vm_role`` **MUST NOT** change.
3520
3521
3522 .. container:: note
3523
3524     :need:`R-86476`
3525
3526     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3527     property ``metadata`` key/value pair ``vm_role`` value **MUST**
3528     only contain alphanumeric characters and underscores (i.e., '_').
3529
3530
3531 .. container:: note
3532
3533     :need:`R-95430`
3534
3535     If a VNF's Heat Orchestration Template's ``OS::Nova::Server``
3536     resource property
3537     ``metadata`` key/value pair ``vm_role`` value is obtained via
3538     ``get_param``, the parameter **MUST** be declared as ``vm_role``
3539     and the parameter **MUST** be defined as type: ``string``.
3540
3541
3542 .. container:: note
3543
3544     :need:`R-85328`
3545
3546     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource property
3547     ``metadata`` **MAY**
3548     contain the key/value pair ``vm_role`` and the value **MUST** be
3549     obtained either via
3550
3551     - ``get_param``
3552     - hard coded in the key/value pair ``vm_role``.
3553
3554
3555 Resource: OS::Nova::Server Metadata Parameters > vnf_id
3556 -------------------------------------------------------
3557
3558
3559 Requirements Changed
3560 ~~~~~~~~~~~~~~~~~~~~
3561
3562
3563 .. container:: note
3564
3565     :need:`R-44491`
3566
3567     If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3568     property
3569     ``metadata`` key/value pair ``vnf_id`` is passed into a Nested YAML
3570     file, the key/value pair name ``vnf_id`` **MUST NOT** change.
3571
3572
3573 .. container:: note
3574
3575     :need:`R-20856`
3576
3577     A VNF's Heat Orchestration Template's ``OS::Nova::Server``
3578     resource property
3579     ``metadata`` key/value pair ``vnf_id`` parameter ``vnf_id`` **MUST NOT**
3580     be enumerated in the Heat Orchestration Template's environment file.
3581
3582
3583 .. container:: note
3584
3585     :need:`R-07507`
3586
3587     A VNF's Heat Orchestration Template's ``OS::Nova::Server``
3588     resource property
3589     ``metadata`` key/value pair ``vnf_id`` parameter
3590     **MUST** be declared as ``vnf_id`` and the parameter **MUST**
3591     be defined as type: ``string``.
3592
3593
3594 .. container:: note
3595
3596     :need:`R-37437`
3597
3598     A VNF's Heat Orchestration Template's ``OS::Nova::Server``
3599     resource property ``metadata`` **MUST**
3600     contain the  key/value pair ``vnf_id``
3601     and the value **MUST** be obtained via a ``get_param``.
3602
3603
3604 .. container:: note
3605
3606     :need:`R-55218`
3607
3608     A VNF's Heat Orchestration Template's ``OS::Nova::Server``
3609     resource property
3610     ``metadata`` key/value pair ``vnf_id`` parameter ``vnf_id`` **MUST NOT**
3611     have parameter constraints defined.
3612
3613
3614 Resource: OS::Nova::Server Metadata Parameters > vnf_name
3615 ---------------------------------------------------------
3616
3617
3618 Requirements Changed
3619 ~~~~~~~~~~~~~~~~~~~~
3620
3621
3622 .. container:: note
3623
3624     :need:`R-36542`
3625
3626     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3627     property ``metadata`` key/value pair ``vnf_name`` parameter
3628     ``vnf_name`` **MUST NOT**
3629     be enumerated in the Heat Orchestration Template's environment file.
3630
3631
3632 .. container:: note
3633
3634     :need:`R-72483`
3635
3636     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource property
3637     ``metadata`` **MUST** contain the key/value pair ``vnf_name`` and the
3638     value **MUST** be obtained via a ``get_param``.
3639
3640
3641 .. container:: note
3642
3643     :need:`R-44318`
3644
3645     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3646     property ``metadata`` key/value pair ``vnf_name``
3647     parameter ``vnf_name`` **MUST NOT**
3648     have parameter constraints defined.
3649
3650
3651 .. container:: note
3652
3653     :need:`R-62428`
3654
3655     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3656     property ``metadata`` key/value pair ``vnf_name`` parameter **MUST**
3657     be declared as ``vnf_name`` and the parameter **MUST** be defined as
3658     type: ``string``.
3659
3660
3661 .. container:: note
3662
3663     :need:`R-16576`
3664
3665     If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3666     property
3667     ``metadata`` key/value pair ``vnf_name`` is passed into a Nested YAML
3668     file, the key/value pair name ``vnf_name`` **MUST NOT** change.
3669
3670
3671 Resource: OS::Nova::Server Metadata Parameters > workload_context
3672 -----------------------------------------------------------------
3673
3674
3675 Requirements Changed
3676 ~~~~~~~~~~~~~~~~~~~~
3677
3678
3679 .. container:: note
3680
3681     :need:`R-74978`
3682
3683     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3684     property ``metadata`` key/value pair ``workload_context``
3685     parameter **MUST**
3686     be declared as ``workload_context`` and the parameter **MUST**
3687     be defined as type: ``string``.
3688
3689
3690 .. container:: note
3691
3692     :need:`R-02691`
3693
3694     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3695     property ``metadata`` key/value pair ``workload_context``
3696     parameter ``workload_context`` **MUST NOT**
3697     be enumerated in the Heat Orchestration Template's environment file.
3698
3699
3700 .. container:: note
3701
3702     :need:`R-34055`
3703
3704     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3705     property ``metadata`` key/value pair ``workload_context``
3706     parameter ``workload_context`` **MUST NOT**
3707     have parameter constraints defined.
3708
3709
3710 .. container:: note
3711
3712     :need:`R-75202`
3713
3714     If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
3715     property ``metadata`` key/value pair ``workload_context``
3716     is passed into a Nested YAML
3717     file, the key/value pair name ``workload_context`` **MUST NOT** change.
3718
3719
3720 VNF On-boarding and package management > Resource Description
3721 -------------------------------------------------------------
3722
3723
3724 Requirements Added
3725 ~~~~~~~~~~~~~~~~~~
3726
3727
3728 .. container:: note
3729
3730     :need:`R-22346`
3731
3732     The VNF package MUST provide :doc:`VES Event Registration <../../../../vnfsdk/module.git/files/VESEventRegistration_3_0>`
3733     for all VES events provided by that xNF.
3734
3735
3736 .. container:: note
3737
3738     :need:`R-384337`
3739
3740     The VNF documentation **MUST** contain a list of the files within the VNF
3741     package that are static during the VNF's runtime.
3742
3743
3744 VNF On-boarding and package management > Testing
3745 ------------------------------------------------
3746
3747
3748 Requirements Changed
3749 ~~~~~~~~~~~~~~~~~~~~
3750
3751
3752 .. container:: note
3753
3754     :need:`R-43958`
3755
3756     The xNF Package **MUST** include documentation describing
3757     the tests that were conducted by the xNF provider and the test results.
3758
3759
3760 VNF Resiliency > Virtual Function - Container Recovery Requirements
3761 -------------------------------------------------------------------
3762
3763
3764 Requirements Added
3765 ~~~~~~~~~~~~~~~~~~
3766
3767
3768 .. container:: note
3769
3770     :need:`R-46851`
3771
3772     The VNF **MUST** support ONAP Controller's Evacuate command.
3773
3774
3775 .. container:: note
3776
3777     :need:`R-48761`
3778
3779     The VNF **MUST** support ONAP Controller's Snapshot command.
3780
3781
3782 VNF Security > VNF API Security Requirements
3783 --------------------------------------------
3784
3785
3786 Requirements Changed
3787 ~~~~~~~~~~~~~~~~~~~~
3788
3789
3790 .. container:: note
3791
3792     :need:`R-21210`
3793
3794     The VNF **MUST** implement the following input validation control
3795     on APIs: Validate that any input file has a correct and valid
3796     Multipurpose Internet Mail Extensions (MIME) type. Input files
3797     should be tested for spoofed MIME types.
3798
3799
3800 .. container:: note
3801
3802     :need:`R-54930`
3803
3804     The VNF **MUST** implement the following input validation controls:
3805     Do not permit input that contains content or characters inappropriate
3806     to the input expected by the design. Inappropriate input, such as
3807     SQL expressions, may cause the system to execute undesirable and
3808     unauthorized transactions against the database or allow other
3809     inappropriate access to the internal network (injection attacks).
3810
3811
3812 .. container:: note
3813
3814     :need:`R-43884`
3815
3816     The VNF **SHOULD** integrate with the Operator's authentication and
3817     authorization services (e.g., IDAM).
3818
3819
3820 Requirements Removed
3821 ~~~~~~~~~~~~~~~~~~~~
3822
3823
3824 .. container:: note
3825
3826     R-02137
3827
3828     The VNF **MUST** implement all monitoring and logging as
3829     described in the Security Analytics section.
3830
3831
3832 .. container:: note
3833
3834     R-15659
3835
3836     The VNF **MUST** restrict changing the criticality level of
3837     a system security alarm to administrator(s).
3838
3839
3840 .. container:: note
3841
3842     R-19367
3843
3844     The VNF **MUST** monitor API invocation patterns to detect
3845     anomalous access patterns that may represent fraudulent access or
3846     other types of attacks, or integrate with tools that implement anomaly
3847     and abuse detection.
3848
3849
3850 .. container:: note
3851
3852     R-19804
3853
3854     The VNF **MUST** validate the CA signature on the certificate,
3855     ensure that the date is within the validity period of the certificate,
3856     check the Certificate Revocation List (CRL), and recognize the identity
3857     represented by the certificate where PKI-based authentication is used.
3858
3859
3860 .. container:: note
3861
3862     R-23772
3863
3864     The VNF **MUST** validate input at all layers implementing VNF APIs.
3865
3866
3867 .. container:: note
3868
3869     R-25878
3870
3871     The VNF **MUST** use certificates issued from publicly
3872     recognized Certificate Authorities (CA) for the authentication process
3873     where PKI-based authentication is used.
3874
3875
3876 .. container:: note
3877
3878     R-37608
3879
3880     The VNF **MUST** provide a mechanism to restrict access based
3881     on the attributes of the VNF and the attributes of the subject.
3882
3883
3884 .. container:: note
3885
3886     R-78066
3887
3888     The VNF **MUST** support requests for information from law
3889     enforcement and government agencies.
3890
3891
3892 .. container:: note
3893
3894     R-87135
3895
3896     The VNF **MUST** comply with NIST standards and industry
3897     best practices for all implementations of cryptography.
3898
3899
3900 VNF Security > VNF Cryptography Requirements
3901 --------------------------------------------
3902
3903
3904 Requirements Changed
3905 ~~~~~~~~~~~~~~~~~~~~
3906
3907
3908 .. container:: note
3909
3910     :need:`R-48080`
3911
3912     The VNF **SHOULD** support an automated certificate management protocol
3913     such as CMPv2, Simple Certificate Enrollment Protocol (SCEP) or
3914     Automated Certificate Management Environment (ACME).
3915
3916
3917 .. container:: note
3918
3919     :need:`R-93860`
3920
3921     The VNF **SHOULD** provide the capability to integrate with an
3922     external encryption service.
3923
3924
3925 .. container:: note
3926
3927     :need:`R-41994`
3928
3929     The VNF **MUST** support the use of X.509 certificates issued from any
3930     Certificate Authority (CA) that is compliant with RFC5280, e.g., a public
3931     CA such as DigiCert or Let's Encrypt, or an RFC5280  compliant Operator
3932     CA.
3933
3934     Note: The VNF provider cannot require the use of self-signed certificates
3935     in an Operator's run time environment.
3936
3937
3938 .. container:: note
3939
3940     :need:`R-49109`
3941
3942     The VNF **MUST** support HTTP/S using TLS v1.2 or higher
3943     with strong cryptographic ciphers.
3944
3945
3946 VNF Security > VNF Data Protection Requirements
3947 -----------------------------------------------
3948
3949
3950 Requirements Changed
3951 ~~~~~~~~~~~~~~~~~~~~
3952
3953
3954 .. container:: note
3955
3956     :need:`R-69610`
3957
3958     The VNF **MUST** provide the capability of using X.509 certificates
3959     issued by an external Certificate Authority.
3960
3961
3962 .. container:: note
3963
3964     :need:`R-58964`
3965
3966     The VNF **MUST** provide the capability to restrict read
3967     and write access to data handled by the VNF.
3968
3969
3970 .. container:: note
3971
3972     :need:`R-47204`
3973
3974     The VNF **MUST** be capable of protecting the confidentiality and integrity
3975     of data at rest and in transit from unauthorized access and modification.
3976
3977
3978 .. container:: note
3979
3980     :need:`R-32641`
3981
3982     The VNF **MUST** provide the capability to encrypt data on
3983     non-volatile memory.Non-volative memory is storage that is
3984     capable of retaining data without electrical power, e.g.
3985     Complementary metal-oxide-semiconductor (CMOS) or hard drives.
3986
3987
3988 .. container:: note
3989
3990     :need:`R-73067`
3991
3992     The VNF **MUST** use NIST and industry standard cryptographic
3993     algorithms and standard modes of operations when implementing
3994     cryptography.
3995
3996
3997 .. container:: note
3998
3999     :need:`R-95864`
4000
4001     The VNF **MUST** support digital certificates that comply with X.509
4002     standards.
4003
4004
4005 .. container:: note
4006
4007     :need:`R-02170`
4008
4009     The VNF **MUST** use, whenever possible, standard implementations
4010     of security applications, protocols, and formats, e.g., S/MIME, TLS, SSH,
4011     IPSec, X.509 digital certificates for cryptographic implementations.
4012     These implementations must be purchased from reputable vendors or obtained
4013     from reputable open source communities and must not be developed in-house.
4014
4015
4016 .. container:: note
4017
4018     :need:`R-70933`
4019
4020     The VNF **MUST** provide the ability to migrate to newer
4021     versions of cryptographic algorithms and protocols with minimal impact.
4022
4023
4024 .. container:: note
4025
4026     :need:`R-12467`
4027
4028     The VNF **MUST NOT** use compromised encryption algorithms.
4029     For example, SHA, DSS, MD5, SHA-1 and Skipjack algorithms.
4030     Acceptable algorithms can be found in the NIST FIPS publications
4031     (https://csrc.nist.gov/publications/fips) and in the
4032     NIST Special Publications (https://csrc.nist.gov/publications/sp).
4033
4034
4035 Requirements Removed
4036 ~~~~~~~~~~~~~~~~~~~~
4037
4038
4039 .. container:: note
4040
4041     R-22645
4042
4043     The VNF **SHOULD** use commercial algorithms only when there
4044     are no applicable governmental standards for specific cryptographic
4045     functions, e.g., public key cryptography, message digests.
4046
4047
4048 .. container:: note
4049
4050     R-99112
4051
4052     The VNF **MUST** provide the capability to restrict access
4053     to data to specific users.
4054
4055
4056 VNF Security > VNF General Security Requirements
4057 ------------------------------------------------
4058
4059
4060 Requirements Added
4061 ~~~~~~~~~~~~~~~~~~
4062
4063
4064 .. container:: note
4065
4066     :need:`R-118669`
4067
4068     Login access (e.g., shell access) to the operating system layer, whether
4069     interactive or as part of an automated process, **MUST** be through an
4070     encrypted protocol such as SSH or TLS.
4071
4072
4073 .. container:: note
4074
4075     :need:`R-240760`
4076
4077     The VNF **MUST NOT** contain any backdoors.
4078
4079
4080 .. container:: note
4081
4082     :need:`R-256267`
4083
4084     If SNMP is utilized, the VNF **MUST** support at least SNMPv3 with
4085     message authentication.
4086
4087
4088 .. container:: note
4089
4090     :need:`R-258686`
4091
4092     The VNF application processes **MUST NOT** run as root.
4093
4094
4095 .. container:: note
4096
4097     :need:`R-343842`
4098
4099     The VNF **MUST**, after a successful login at command line or a GUI,
4100     display the last valid login date and time and the number of unsuccessful
4101     attempts since then made with that user's ID. This requirement is only
4102     applicable when the user account is defined locally in the VNF.
4103
4104
4105 .. container:: note
4106
4107     :need:`R-638682`
4108
4109     The VNF **MUST** log any security event required by the VNF Requirements to
4110     Syslog using LOG_AUTHPRIV for any event that would contain sensitive
4111     information and LOG_AUTH for all other relevant events.
4112
4113
4114 .. container:: note
4115
4116     :need:`R-756950`
4117
4118     The VNF **MUST** be operable without the use of Network File System (NFS).
4119
4120
4121 .. container:: note
4122
4123     :need:`R-842258`
4124
4125     The VNF **MUST** include a configuration, e.g., a heat template or CSAR
4126     package, that specifies the targetted parameters, e.g. a limited set of
4127     ports, over which the VNF will communicate (including internal, external
4128     and management communication).
4129
4130
4131 .. container:: note
4132
4133     :need:`R-872986`
4134
4135     The VNF **MUST** store Authentication Credentials used to authenticate to
4136     other systems encrypted except where there is a technical need to store
4137     the password unencrypted in which case it must be protected using other
4138     security techniques that include the use of file and directory permissions.
4139     Ideally, credentials SHOULD rely on a HW Root of Trust, such as a
4140     TPM or HSM.
4141
4142
4143 Requirements Changed
4144 ~~~~~~~~~~~~~~~~~~~~
4145
4146
4147 .. container:: note
4148
4149     :need:`R-62498`
4150
4151     The VNF **MUST** support encrypted access protocols, e.g., TLS,
4152     SSH, SFTP.
4153
4154
4155 .. container:: note
4156
4157     :need:`R-23882`
4158
4159     The VNF **SHOULD** provide the capability for the Operator to run security
4160     vulnerability scans of the operating system and all application layers.
4161
4162
4163 .. container:: note
4164
4165     :need:`R-61354`
4166
4167     The VNF **MUST** provide a mechanism (e.g., access control list) to
4168     permit and/or restrict access to services on the VNF by source,
4169     destination, protocol, and/or port.
4170
4171
4172 .. container:: note
4173
4174     :need:`R-19768`
4175
4176     The VNF **SHOULD** support network segregation, i.e., separation of OA&M
4177     traffic from signaling and payload traffic, using technologies such as
4178     VPN and VLAN.
4179
4180
4181 .. container:: note
4182
4183     :need:`R-19082`
4184
4185     The VNF **MUST** allow the Operator to disable or remove any security
4186     testing tools or programs included in the VNF, e.g., password cracker,
4187     port scanner.
4188
4189
4190 .. container:: note
4191
4192     :need:`R-86261`
4193
4194     The VNF **MUST** support the ability to prohibit remote access to the VNF
4195     via a host based security mechanism.
4196
4197
4198 .. container:: note
4199
4200     :need:`R-99771`
4201
4202     The VNF **MUST** have all code (e.g., QCOW2) and configuration files
4203     (e.g., HEAT template, Ansible playbook, script) hardened, or with
4204     documented recommended configurations for hardening and interfaces that
4205     allow the Operator to harden the VNF. Actions taken to harden a system
4206     include disabling all unnecessary services, and changing default values
4207     such as default credentials and community strings.
4208
4209
4210 .. container:: note
4211
4212     :need:`R-80335`
4213
4214     For all GUI and command-line interfaces, the VNF **MUST** provide the
4215     ability to present a warning notice that is set by the Operator. A warning
4216     notice is a formal statement of resource intent presented to everyone
4217     who accesses the system.
4218
4219
4220 .. container:: note
4221
4222     :need:`R-21819`
4223
4224     The VNF **MUST** provide functionality that enables the Operator to comply
4225     with requests for information from law enforcement and government agencies.
4226
4227
4228 .. container:: note
4229
4230     :need:`R-23740`
4231
4232     The VNF **MUST** implement and enforce the principle of least privilege
4233     on all protected interfaces.
4234
4235
4236 .. container:: note
4237
4238     :need:`R-40813`
4239
4240     The VNF **SHOULD** support the use of virtual trusted platform
4241     module.
4242
4243
4244 .. container:: note
4245
4246     :need:`R-69649`
4247
4248     The VNF Provider **MUST** have patches available for vulnerabilities
4249     in the VNF as soon as possible. Patching shall be controlled via change
4250     control process with vulnerabilities disclosed along with
4251     mitigation recommendations.
4252
4253
4254 .. container:: note
4255
4256     :need:`R-92207`
4257
4258     The VNF **SHOULD** provide a mechanism that enables the operators to
4259     perform automated system configuration auditing at configurable time
4260     intervals.
4261
4262
4263 Requirements Removed
4264 ~~~~~~~~~~~~~~~~~~~~
4265
4266
4267 .. container:: note
4268
4269     R-26586
4270
4271     The VNF **SHOULD** support the ability to work with aliases
4272     (e.g., gateways, proxies) to protect and encapsulate resources.
4273
4274
4275 .. container:: note
4276
4277     R-33981
4278
4279     The VNF **SHOULD** interoperate with various access control
4280     mechanisms for the Network Cloud execution environment (e.g.,
4281     Hypervisors, containers).
4282
4283
4284 .. container:: note
4285
4286     R-35144
4287
4288     The VNF **MUST**, if not using the NCSP's IDAM API, comply
4289     with the NCSP's credential management policy.
4290
4291
4292 .. container:: note
4293
4294     R-39342
4295
4296     The VNF **MUST**, if not using the NCSP's IDAM API, comply
4297     with "password changes (includes default passwords)" policy. Products
4298     will support password aging, syntax and other credential management
4299     practices on a configurable basis.
4300
4301
4302 .. container:: note
4303
4304     R-40521
4305
4306     The VNF **MUST**, if not using the NCSP's IDAM API, support
4307     use of common third party authentication and authorization tools such
4308     as TACACS+, RADIUS.
4309
4310
4311 .. container:: note
4312
4313     R-42681
4314
4315     The VNF **MUST** use the NCSP's IDAM API or comply with
4316     the requirements if not using the NCSP's IDAM API, for identification,
4317     authentication and access control of OA&M and other system level
4318     functions.
4319
4320
4321 .. container:: note
4322
4323     R-49956
4324
4325     The VNF **MUST** pass all access to applications (Bearer,
4326     signaling and OA&M) through various security tools and platforms from
4327     ACLs, stateful firewalls and application layer gateways depending on
4328     manner of deployment. The application is expected to function (and in
4329     some cases, interwork) with these security tools.
4330
4331
4332 .. container:: note
4333
4334     R-52085
4335
4336     The VNF **MUST**, if not using the NCSP's IDAM API, provide
4337     the ability to support Multi-Factor Authentication (e.g., 1st factor =
4338     Software token on device (RSA SecureID); 2nd factor = User Name+Password,
4339     etc.) for the users.
4340
4341
4342 .. container:: note
4343
4344     R-55830
4345
4346     The VNF **MUST** distribute all production code from NCSP
4347     internal sources only. No production code, libraries, OS images, etc.
4348     shall be distributed from publically accessible depots.
4349
4350
4351 .. container:: note
4352
4353     R-63217
4354
4355     The VNF **MUST**, if not using the NCSP's IDAM API, support
4356     logging via ONAP for a historical view of "who did what and when."
4357
4358
4359 .. container:: note
4360
4361     R-68589
4362
4363     The VNF **MUST**, if not using the NCSP's IDAM API, support
4364     User-IDs and passwords to uniquely identify the user/application. VNF
4365     needs to have appropriate connectors to the Identity, Authentication
4366     and Authorization systems that enables access at OS, Database and
4367     Application levels as appropriate.
4368
4369
4370 .. container:: note
4371
4372     R-85633
4373
4374     The VNF **MUST** implement Data Storage Encryption
4375     (database/disk encryption) for Sensitive Personal Information (SPI)
4376     and other subscriber identifiable data.
4377
4378     Note: Subscribers SPI/data must be encrypted at rest, and other
4379     subscriber identifiable data should be encrypted at rest. Other
4380     data protection requirements exist and should be well understood
4381     by the developer.
4382
4383
4384 VNF Security > VNF Identity and Access Management Requirements
4385 --------------------------------------------------------------
4386
4387
4388 Requirements Added
4389 ~~~~~~~~~~~~~~~~~~
4390
4391
4392 .. container:: note
4393
4394     :need:`R-231402`
4395
4396     The VNF **MUST** provide a means for the user to explicitly logout, thus
4397     ending that session for that authenticated user.
4398
4399
4400 .. container:: note
4401
4402     :need:`R-45719`
4403
4404     The VNF **MUST**, if not integrated with the Operator's Identity and Access
4405     Management system, or enforce a configurable "terminate idle sessions"
4406     policy by terminating the session after a configurable period of inactivity.
4407
4408
4409 .. container:: note
4410
4411     :need:`R-479386`
4412
4413     The VNF **MUST NOT** display "Welcome" notices or messages that could
4414     be misinterpreted as extending an invitation to unauthorized users.
4415
4416
4417 .. container:: note
4418
4419     :need:`R-581188`
4420
4421     A failed authentication attempt **MUST NOT** identify the reason for the
4422     failure to the user, only that the authentication failed.
4423
4424
4425 .. container:: note
4426
4427     :need:`R-814377`
4428
4429     The VNF **MUST** have the capability of allowing the Operator to create,
4430     manage, and automatically provision user accounts using an Operator
4431     approved identity lifecycle management tool using a standard protocol,
4432     e.g., NETCONF API.
4433
4434
4435 .. container:: note
4436
4437     :need:`R-844011`
4438
4439     The VNF MUST not store authentication credentials to itself in clear
4440     text or any reversible form and must use salting.
4441
4442
4443 .. container:: note
4444
4445     :need:`R-931076`
4446
4447     The VNF **MUST** support account names that contain at least A-Z, a-z,
4448     0-9 character sets and be at least 6 characters in length.
4449
4450
4451 Requirements Changed
4452 ~~~~~~~~~~~~~~~~~~~~
4453
4454
4455 .. container:: note
4456
4457     :need:`R-23135`
4458
4459     The VNF **MUST**, if not integrated with the Operator's identity and
4460     access management system, authenticate all access to protected GUIs, CLIs,
4461     and APIs.
4462
4463
4464 .. container:: note
4465
4466     :need:`R-15671`
4467
4468     The VNF **MUST** provide access controls that allow the Operator
4469     to restrict access to VNF functions and data to authorized entities.
4470
4471
4472 .. container:: note
4473
4474     :need:`R-78010`
4475
4476     The VNF **MUST** integrate with standard identity and access management
4477     protocols such as LDAP, TACACS+, Windows Integrated Authentication
4478     (Kerberos), SAML federation, or OAuth 2.0.
4479
4480
4481 .. container:: note
4482
4483     :need:`R-86835`
4484
4485     The VNF **MUST** set the default settings for user access
4486     to deny authorization, except for a super user type of account.
4487     When a VNF is added to the network, nothing should be able to use
4488     it until the super user configures the VNF to allow other users
4489     (human and application)  have access.
4490
4491
4492 .. container:: note
4493
4494     :need:`R-59391`
4495
4496     The VNF **MUST NOT** allow the assumption of the permissions of another
4497     account to mask individual accountability. For example, use SUDO when a
4498     user requires elevated permissions such as root or admin.
4499
4500
4501 .. container:: note
4502
4503     :need:`R-75041`
4504
4505     The VNF **MUST**, if not integrated with the Operator's Identity and
4506     Access Management system, support configurable password expiration.
4507
4508
4509 .. container:: note
4510
4511     :need:`R-71787`
4512
4513     Each architectural layer of the VNF (eg. operating system, network,
4514     application) **MUST** support access restriction independently of all
4515     other layers so that Segregation of Duties can be implemented.
4516
4517
4518 .. container:: note
4519
4520     :need:`R-79107`
4521
4522     The VNF **MUST**, if not integrated with the Operator's Identity
4523     and Access Management system, support the ability to disable the
4524     userID after a configurable number of consecutive unsuccessful
4525     authentication attempts using the same userID.
4526
4527
4528 .. container:: note
4529
4530     :need:`R-46908`
4531
4532     The VNF **MUST**, if not integrated with the Operator's Identity and
4533     Access Management system, comply with "password complexity" policy. When
4534     passwords are used, they shall be complex and shall at least meet the
4535     following password construction requirements: (1) be a minimum configurable
4536     number of characters in length, (2) include 3 of the 4 following types of
4537     characters: upper-case alphabetic, lower-case alphabetic, numeric, and
4538     special, (3) not be the same as the UserID with which they are associated
4539     or other common strings as specified by the environment, (4) not contain
4540     repeating or sequential characters or numbers, (5) not to use special
4541     characters that may have command functions, and (6) new passwords must
4542     not contain sequences of three or more characters from the previous
4543     password.
4544
4545
4546 .. container:: note
4547
4548     :need:`R-85419`
4549
4550     The VNF **SHOULD** support OAuth 2.0 authorization using an external
4551     Authorization Server.
4552
4553
4554 .. container:: note
4555
4556     :need:`R-98391`
4557
4558     The VNF **MUST**, if not integrated with the Operator's Identity and
4559     Access Management system, support Role-Based Access Control to enforce
4560     least privilege.
4561
4562
4563 .. container:: note
4564
4565     :need:`R-99174`
4566
4567     The VNF **MUST**, if not integrated with the Operator's Identity and
4568     Access Management system, support the creation of multiple IDs so that
4569     individual accountability can be supported.
4570
4571
4572 .. container:: note
4573
4574     :need:`R-81147`
4575
4576     The VNF **MUST** support strong authentication, also known as
4577     multifactor authentication, on all protected interfaces exposed by the
4578     VNF for use by human users. Strong authentication uses at least two of the
4579     three different types of authentication factors in order to prove the
4580     claimed identity of a user.
4581
4582
4583 .. container:: note
4584
4585     :need:`R-42874`
4586
4587     The VNF **MUST** allow the Operator to restrict access based on
4588     the assigned permissions associated with an ID in order to support
4589     Least Privilege (no more privilege than required to perform job
4590     functions).
4591
4592
4593 Requirements Removed
4594 ~~~~~~~~~~~~~~~~~~~~
4595
4596
4597 .. container:: note
4598
4599     R-05470
4600
4601     The VNF **MUST** host connectors for access to the database layer.
4602
4603
4604 .. container:: note
4605
4606     R-14025
4607
4608     The VNF **MUST** provide or support the Identity and Access
4609     Management (IDAM) based threat detection data for Session Hijacking.
4610
4611
4612 .. container:: note
4613
4614     R-19790
4615
4616     The VNF **MUST NOT** include authentication credentials
4617     in security audit logs, even if encrypted.
4618
4619
4620 .. container:: note
4621
4622     R-24825
4623
4624     The VNF **MUST** provide Context awareness data (device,
4625     location, time, etc.) and be able to integrate with threat detection system.
4626
4627
4628 .. container:: note
4629
4630     R-29301
4631
4632     The VNF **MUST** provide or support the Identity and Access
4633     Management (IDAM) based threat detection data for Password Attacks.
4634
4635
4636 .. container:: note
4637
4638     R-31412
4639
4640     The VNF **MUST** provide or support the Identity and Access
4641     Management (IDAM) based threat detection data for XSS / CSRF.
4642
4643
4644 .. container:: note
4645
4646     R-31751
4647
4648     The VNF **MUST** subject VNF provider access to privilege
4649     reconciliation tools to prevent access creep and ensure correct
4650     enforcement of access policies.
4651
4652
4653 .. container:: note
4654
4655     R-44032
4656
4657     The VNF **MUST** provide or support the Identity and Access
4658     Management (IDAM) based threat detection data for Man in the Middle (MITM).
4659
4660
4661 .. container:: note
4662
4663     R-45496
4664
4665     The VNF **MUST** host connectors for access to the OS (Operating System) layer.
4666
4667
4668 .. container:: note
4669
4670     R-49945
4671
4672     The VNF **MUST** authorize VNF provider access through a
4673     client application API by the client application owner and the resource
4674     owner of the VNF before provisioning authorization through Role Based
4675     Access Control (RBAC), Attribute Based Access Control (ABAC), or other
4676     policy based mechanism.
4677
4678
4679 .. container:: note
4680
4681     R-51883
4682
4683     The VNF **MUST** provide or support the Identity and Access
4684     Management (IDAM) based threat detection data for Replay.
4685
4686
4687 .. container:: note
4688
4689     R-58977
4690
4691     The VNF **MUST** provide or support the Identity and Access
4692     Management (IDAM) based threat detection data for Eavesdropping.
4693
4694
4695 .. container:: note
4696
4697     R-58998
4698
4699     The VNF **MUST** provide or support the Identity and Access
4700     Management (IDAM) based threat detection data for Malware (Key Logger).
4701
4702
4703 .. container:: note
4704
4705     R-64503
4706
4707     The VNF **MUST** provide minimum privileges for initial
4708     and default settings for new user accounts.
4709
4710
4711 .. container:: note
4712
4713     R-72243
4714
4715     The VNF **MUST** provide or support the Identity and Access
4716     Management (IDAM) based threat detection data for Phishing / SMishing.
4717
4718
4719 .. container:: note
4720
4721     R-73541
4722
4723     The VNF **MUST** use access controls for VNFs and their
4724     supporting computing systems at all times to restrict access to
4725     authorized personnel only, e.g., least privilege. These controls
4726     could include the use of system configuration or access control
4727     software.
4728
4729
4730 .. container:: note
4731
4732     R-77157
4733
4734     The VNF **MUST** conform to approved request, workflow
4735     authorization, and authorization provisioning requirements when
4736     creating privileged users.
4737
4738
4739 .. container:: note
4740
4741     R-85028
4742
4743     The VNF **MUST** authenticate system to system access and
4744     do not conceal a VNF provider user's individual accountability for
4745     transactions.
4746
4747
4748 .. container:: note
4749
4750     R-89753
4751
4752     The VNF **MUST NOT** install or use systems, tools or
4753     utilities capable of capturing or logging data that was not created
4754     by them or sent specifically to them in production, without
4755     authorization of the VNF system owner.
4756
4757
4758 .. container:: note
4759
4760     R-95105
4761
4762     The VNF **MUST** host connectors for access to the application layer.
4763
4764
4765 VNF Security > VNF Security Analytics Requirements
4766 --------------------------------------------------
4767
4768
4769 Requirements Added
4770 ~~~~~~~~~~~~~~~~~~
4771
4772
4773 .. container:: note
4774
4775     :need:`R-303569`
4776
4777     The VNF **MUST** log the Source IP address in the security audit logs.
4778
4779
4780 .. container:: note
4781
4782     :need:`R-465236`
4783
4784     The VNF **SHOULD** provide the capability of maintaining the integrity of
4785     its static files using a cryptographic method.
4786
4787
4788 .. container:: note
4789
4790     :need:`R-629534`
4791
4792     The VNF **MUST** be capable of automatically synchronizing the system clock
4793     daily with the Operator's trusted time source, to assure accurate time
4794     reporting in log files. It is recommended that Coordinated Universal Time
4795     (UTC) be used where possible, so as to eliminate ambiguity owing to daylight
4796     savings time.
4797
4798
4799 .. container:: note
4800
4801     :need:`R-703767`
4802
4803     The VNF **MUST** have the capability to securely transmit the security logs
4804     and security events to a remote system before they are purged from the
4805     system.
4806
4807
4808 .. container:: note
4809
4810     :need:`R-859208`
4811
4812     The VNF **MUST** log automated remote activities performed with
4813     elevated privileges.
4814
4815
4816 Requirements Changed
4817 ~~~~~~~~~~~~~~~~~~~~
4818
4819
4820 .. container:: note
4821
4822     :need:`R-07617`
4823
4824     The VNF **MUST** log success and unsuccessful creation, removal, or
4825     change to the inherent privilege level of users.
4826
4827
4828 .. container:: note
4829
4830     :need:`R-22367`
4831
4832     The VNF **MUST** support detection of malformed packets due to software
4833     misconfiguration or software vulnerability, and generate an error to the
4834     syslog console facility.
4835
4836
4837 .. container:: note
4838
4839     :need:`R-34552`
4840
4841     The VNF **MUST** be implemented so that it is not vulnerable to OWASP
4842     Top 10 web application security risks.
4843
4844
4845 .. container:: note
4846
4847     :need:`R-54520`
4848
4849     The VNF **MUST** log successful and unsuccessful authentication
4850     attempts, e.g., authentication associated with a transaction,
4851     authentication to create a session, authentication to assume elevated
4852     privilege.
4853
4854
4855 .. container:: note
4856
4857     :need:`R-58370`
4858
4859     The VNF **SHOULD** operate with anti-virus software which produces alarms
4860     every time a virus is detected.
4861
4862
4863 .. container:: note
4864
4865     :need:`R-94525`
4866
4867     The VNF **MUST** log connections to the network listeners of the
4868     resource.
4869
4870
4871 .. container:: note
4872
4873     :need:`R-43332`
4874
4875     The VNF **MUST** activate security alarms automatically when
4876     it detects the successful modification of a critical system or
4877     application file.
4878
4879
4880 .. container:: note
4881
4882     :need:`R-41825`
4883
4884     The VNF **MUST** activate security alarms automatically when
4885     a configurable number of consecutive unsuccessful login attempts
4886     is reached.
4887
4888
4889 .. container:: note
4890
4891     :need:`R-29705`
4892
4893     The VNF **MUST** restrict changing the criticality level of a
4894     system security alarm to users with administrative privileges.
4895
4896
4897 .. container:: note
4898
4899     :need:`R-63330`
4900
4901     The VNF **MUST** detect when its security audit log storage
4902     medium is approaching capacity (configurable) and issue an alarm.
4903
4904
4905 .. container:: note
4906
4907     :need:`R-30932`
4908
4909     The VNF **MUST** log successful and unsuccessful access to VNF
4910     resources, including data.
4911
4912
4913 .. container:: note
4914
4915     :need:`R-04492`
4916
4917     The VNF **MUST** generate security audit logs that can be sent
4918     to Security Analytics Tools for analysis.
4919
4920
4921 .. container:: note
4922
4923     :need:`R-74958`
4924
4925     The VNF **MUST** activate security alarms automatically when
4926     it detects an unsuccessful attempt to gain permissions
4927     or assume the identity of another user.
4928
4929
4930 .. container:: note
4931
4932     :need:`R-54816`
4933
4934     The VNF **MUST** support the storage of security audit logs for a
4935     configurable period of time.
4936
4937
4938 Requirements Removed
4939 ~~~~~~~~~~~~~~~~~~~~
4940
4941
4942 .. container:: note
4943
4944     R-08598
4945
4946     The VNF **MUST** log successful and unsuccessful changes to a privilege level.
4947
4948
4949 .. container:: note
4950
4951     R-19219
4952
4953     The VNF **MUST** provide audit logs that include user ID, dates,
4954     times for log-on and log-off, and terminal location at minimum.
4955
4956
4957 .. container:: note
4958
4959     R-20912
4960
4961     The VNF **MUST** support alternative monitoring capabilities
4962     when VNFs do not expose data or control traffic or use proprietary and
4963     optimized protocols for inter VNF communication.
4964
4965
4966 .. container:: note
4967
4968     R-25094
4969
4970     The VNF **MUST** perform data capture for security functions.
4971
4972
4973 .. container:: note
4974
4975     R-31961
4976
4977     The VNF **MUST** support integrated DPI/monitoring functionality
4978     as part of VNFs (e.g., PGW, MME).
4979
4980
4981 .. container:: note
4982
4983     R-56786
4984
4985     The VNF **MUST** implement "Closed Loop" automatic implementation
4986     (without human intervention) for Known Threats with detection rate in low
4987     false positives.
4988
4989
4990 .. container:: note
4991
4992     R-57271
4993
4994     The VNF **MUST** provide the capability of generating security
4995     audit logs by interacting with the operating system (OS) as appropriate.
4996
4997
4998 .. container:: note
4999
5000     R-61648
5001
5002     The VNF **MUST** support event logging, formats, and delivery
5003     tools to provide the required degree of event data to ONAP.
5004
5005
5006 {network-role}
5007 --------------
5008
5009
5010 Requirements Changed
5011 ~~~~~~~~~~~~~~~~~~~~
5012
5013
5014 .. container:: note
5015
5016     :need:`R-26506`
5017
5018     A VNF's Heat Orchestration Template's ``{network-role}`` **MUST** contain
5019     only alphanumeric characters and/or underscores '_' and
5020     **MUST NOT** contain any of the following strings:
5021     ``_int`` or ``int_`` or ``_int_``.
5022
5023
5024 .. container:: note
5025
5026     :need:`R-84322`
5027
5028     A VNF's Heat Orchestration Template's Resource property parameter that
5029     is associated with an internal network **MUST** include
5030     ``int_{network-role}`` as part of the parameter name,
5031     where ``int_`` is a hard coded string.
5032
5033
5034 .. container:: note
5035
5036     :need:`R-96983`
5037
5038     A VNF's Heat Orchestration Template's Resource ID that is associated
5039     with an internal network **MUST** include ``int_{network-role}`` as part
5040     of the Resource ID, where ``int_`` is a hard coded string.
5041
5042
5043 {vm-type}
5044 ---------
5045
5046
5047 Requirements Changed
5048 ~~~~~~~~~~~~~~~~~~~~
5049
5050
5051 .. container:: note
5052
5053     :need:`R-82481`
5054
5055     A VNF's Heat Orchestration Template's Resource property parameter that is
5056     associated with a unique Virtual Machine type **MUST** include
5057     ``{vm-type}`` as part of the parameter name with two exceptions:
5058
5059      1.) The Resource ``OS::Nova::Server`` property ``availability_zone``
5060      parameter **MUST NOT** be prefixed with a common ``{vm-type}`` identifier,
5061
5062      2.) The Resource ``OS::Nova::Server`` eight mandatory and optional
5063      ``metadata``
5064      parameters (i.e., ``vnf_name``, ``vnf_id``, ``vf_module_id``,
5065      ``vf_module_name``, ``vm_role``,
5066      ``vf_module_index``, ``environment_context``, ``workload_context``)
5067      **MUST NOT** be prefixed with a common ``{vm-type}`` identifier.
5068
5069
5070 .. container:: note
5071
5072     :need:`R-98407`
5073
5074     A VNF's Heat Orchestration Template's ``{vm-type}`` **MUST** contain only
5075     alphanumeric characters and/or underscores '_' and **MUST NOT**
5076     contain any of the following strings:
5077     ``_int`` or ``int_`` or ``_int_``.
5078
5079
5080 .. container:: note
5081
5082     :need:`R-01455`
5083
5084     When a VNF's Heat Orchestration Template creates a Virtual Machine
5085     (i.e., ``OS::Nova::Server``),
5086     each "class" of VMs **MUST** be assigned a VNF unique
5087     ``{vm-type}``; where "class" defines VMs that
5088     **MUST** have the following identical characteristics:
5089
5090       1.) ``OS::Nova::Server`` resource property ``flavor`` value
5091
5092       2.) ``OS::Nova::Server`` resource property ``image`` value
5093
5094       3.) Cinder Volume attachments
5095
5096         - Each VM in the "class" **MUST** have the identical Cinder Volume
5097           configuration
5098
5099       4.) Network attachments and IP address requirements
5100
5101         - Each VM in the "class" **MUST** have the the identical number of
5102           ports connecting to the identical networks and requiring the identical
5103           IP address configuration.
5104