docs/changes-by-section-dublin.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 Dublin
  17 ========================================================
  18
  19 This document summarizes the requirement changes by section that were
  20 introduced between the Casablanca release and
  21 Dublin 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:** 64
  31 * **Requirements Changed:** 275
  32 * **Requirements Removed:** 40
  33
  34
  35 Configuration Management > Ansible Standards and Capabilities > VNF or PNF Configuration via Ansible Requirements > Ansible Client Requirements
  36 -----------------------------------------------------------------------------------------------------------------------------------------------
  37
  38
  39 Requirements Changed
  40 ~~~~~~~~~~~~~~~~~~~~
  41
  42
  43 .. container:: note
  44
  45     :need:`R-94567`
  46
  47     The VNF or PNF **MUST** provide Ansible playbooks that are designed to run
  48     using an inventory hosts file in a supported format with only IP addresses
  49     or IP addresses and VM/VNF or PNF names.
  50
  51
  52 .. container:: note
  53
  54     :need:`R-82018`
  55
  56     The VNF or PNF **MUST** load the Ansible Server SSH public key onto VNF or
  57     PNF VM(s) /root/.ssh/authorized_keys as part of instantiation. Alternative,
  58     is for Ansible Server SSH public key to be loaded onto VNF or PNF VM(s)
  59     under /home/<Mechanized user ID>/.ssh/authorized_keys as part of
  60     instantiation, when a Mechanized user ID is created during instantiation,
  61     and Configure and all playbooks are designed to use a mechanized user ID
  62     only for authentication (never using root authentication during Configure
  63     playbook run). This will allow the Ansible Server to authenticate to
  64     perform post-instantiation configuration without manual intervention and
  65     without requiring specific VNF or PNF login IDs and passwords.
  66
  67     *CAUTION*: For VNFs or PNFs configured using Ansible, to eliminate the need
  68     for manual steps, post-instantiation and pre-configuration, to
  69     upload of SSH public keys, SSH public keys loaded during (heat)
  70     instantiation shall be preserved and not removed by (heat) embedded
  71     (userdata) scripts.
  72
  73
  74 .. container:: note
  75
  76     :need:`R-35401`
  77
  78     The VNF or PNF **MUST** support SSH and allow SSH access by the
  79     Ansible server to the endpoint VM(s) and comply with the Network
  80     Cloud Service Provider guidelines for authentication and access.
  81
  82
  83 .. container:: note
  84
  85     :need:`R-97451`
  86
  87     The VNF or PNF **MUST** provide the ability to remove root access once
  88     post-instantiation configuration (Configure) is completed.
  89
  90
  91 .. container:: note
  92
  93     :need:`R-45197`
  94
  95     The VNF or PNF **MUST** define the "from=" clause to provide the list of IP
  96     addresses of the Ansible Servers in the Cluster, separated by coma, to
  97     restrict use of the SSH key pair to elements that are part of the Ansible
  98     Cluster owner of the issued and assigned mechanized user ID.
  99
 100
 101 .. container:: note
 102
 103     :need:`R-73459`
 104
 105     The VNF or PNF **MUST** provide the ability to include a "from=" clause in
 106     SSH public keys associated with mechanized user IDs created for an Ansible
 107     Server cluster to use for VNF or PNF VM authentication.
 108
 109
 110 .. container:: note
 111
 112     :need:`R-97345`
 113
 114     The VNF or PNF **MUST** permit authentication, using root account, only
 115     right after instantiation and until post-instantiation configuration is
 116     completed.
 117
 118
 119 .. container:: note
 120
 121     :need:`R-92866`
 122
 123     The VNF or PNF **MUST** include as part of post-instantiation configuration
 124     done by Ansible Playbooks the removal/update of the SSH public key from
 125     /root/.ssh/authorized_keys, and update of SSH keys loaded through
 126     instantiation to support Ansible. This may include creating Mechanized user
 127     ID(s) used by the Ansible Server(s) on VNF VM(s) and uploading and
 128     installing new SSH keys used by the mechanized use ID(s).
 129
 130
 131 .. container:: note
 132
 133     :need:`R-67124`
 134
 135     The VNF or PNF **MUST** provide Ansible playbooks that are designed to run
 136     using an inventory hosts file in a supported format; with group names
 137     matching VNFC 3-character string adding "vip" for groups with virtual IP
 138     addresses shared by multiple VMs as seen in examples provided in Appendix.
 139
 140
 141 .. container:: note
 142
 143     :need:`R-32217`
 144
 145     The VNF or PNF **MUST** have routable management IP addresses or FQDNs that
 146     are reachable via the Ansible Server for the endpoints (VMs) of a
 147     VNF or PNF that playbooks will target. ONAP will initiate requests to the
 148     Ansible Server for invocation of playbooks against these end
 149     points [#7.3.3]_.
 150
 151
 152 .. container:: note
 153
 154     :need:`R-54373`
 155
 156     The VNF or PNF **MUST** have Python >= 2.6 on the endpoint VM(s)
 157     of a VNF or PNF on which an Ansible playbook will be executed.
 158
 159
 160 .. container:: note
 161
 162     :need:`R-24482`
 163
 164     The VNF or PNF **MUST** provide Ansible playbooks that are designed to run
 165     using an inventory hosts file in a supported format; with site group that
 166     shall be used to add site specific configurations to the target VNF or PNF
 167     VM(s) as needed.
 168
 169
 170 .. container:: note
 171
 172     :need:`R-91745`
 173
 174     The VNF or PNF **MUST** update the Ansible Server and other entities
 175     storing and using the SSH keys for authentication when the SSH
 176     keys used by Ansible are regenerated/updated.
 177
 178     **Note**: Ansible Server itself may be used to upload new SSH public
 179     keys onto supported VNFs or PNFs.
 180
 181
 182 Configuration Management > Ansible Standards and Capabilities > VNF or PNF Configuration via Ansible Requirements > Ansible Playbook Requirements
 183 -------------------------------------------------------------------------------------------------------------------------------------------------
 184
 185
 186 Requirements Changed
 187 ~~~~~~~~~~~~~~~~~~~~
 188
 189
 190 .. container:: note
 191
 192     :need:`R-49911`
 193
 194     The VNF or PNF provider **MUST** assign a new point release to the updated
 195     playbook set. The functionality of a new playbook set must be tested before
 196     it is deployed to the production.
 197
 198
 199 .. container:: note
 200
 201     :need:`R-58301`
 202
 203     The VNF or PNF **SHOULD NOT** use playbooks that make requests to
 204     Cloud resources e.g. Openstack (nova, neutron, glance, heat, etc.);
 205     therefore, there is no use for Cloud specific variables like Openstack
 206     UUIDs in Ansible Playbook related artifacts.
 207
 208     **Rationale**: Flows that require interactions with Cloud services e.g.
 209     Openstack shall rely on workflows run by an Orchestrator
 210     (Change Management) or other capability (such as a control loop or
 211     Operations GUI) outside Ansible Server which can be executed by a
 212     APPC/SDN-C. There are policies, as part of Control Loop
 213     models, that send remediation action requests to an APPC/SDN-C; these
 214     are triggered as a response to an event or correlated events published
 215     to Event Bus.
 216
 217
 218 .. container:: note
 219
 220     :need:`R-24189`
 221
 222     The VNF or PNF provider **MUST** deliver a new set of playbooks that
 223     includes all updated and unchanged playbooks for any new revision to an
 224     existing set of playbooks.
 225
 226
 227 .. container:: note
 228
 229     :need:`R-43353`
 230
 231     The VNF or PNF **MUST** return control from Ansible Playbooks only after
 232     all tasks performed by playbook are fully complete, signaling that the
 233     playbook completed all tasks. When starting services, return control
 234     only after all services are up. This is critical for workflows where
 235     the next steps are dependent on prior tasks being fully completed.
 236
 237
 238 .. container:: note
 239
 240     :need:`R-51442`
 241
 242     The VNF or PNF **SHOULD** use playbooks that are designed to
 243     automatically 'rollback' to the original state in case of any errors
 244     for actions that change state of the VNF or PNF (e.g., configure).
 245
 246     **Note**: In case rollback at the playbook level is not supported or
 247     possible, the VNF or PNF provider shall provide alternative rollback
 248     mechanism (e.g., for a small VNF or PNF the rollback mechanism may rely
 249     on workflow to terminate and re-instantiate VNF VMs and then re-run
 250     playbook(s)). Backing up updated files is also recommended to support
 251     rollback when soft rollback is feasible.
 252
 253
 254 .. container:: note
 255
 256     :need:`R-48698`
 257
 258     The VNF or PNF **MUST** utilize information from key value pairs that will
 259     be provided by the Ansible Server as "extra-vars" during invocation to
 260     execute the desired VNF or PNF action. The "extra-vars" attribute-value
 261     pairs are passed to the Ansible Server by an APPC/SDN-C as part of the
 262     Rest API request. If the playbook requires files, they must also be
 263     supplied using the methodology detailed in the Ansible Server API, unless
 264     they are bundled with playbooks, example, generic templates. Any files
 265     containing instance specific info (attribute-value pairs), not obtainable
 266     from any ONAP inventory databases or other sources, referenced and used an
 267     input by playbooks, shall be provisioned (and distributed) in advance of
 268     use, e.g., VNF or PNF instantiation. Recommendation is to avoid these
 269     instance specific, manually created in advance of instantiation, files.
 270
 271
 272 .. container:: note
 273
 274     :need:`R-43253`
 275
 276     The VNF or PNF **MUST** use playbooks designed to allow Ansible
 277     Server to infer failure or success based on the "PLAY_RECAP" capability.
 278
 279     **Note**: There are cases where playbooks need to interpret results
 280     of a task and then determine success or failure and return result
 281     accordingly (failure for failed tasks).
 282
 283
 284 .. container:: note
 285
 286     :need:`R-50252`
 287
 288     The VNF or PNF **MUST** write to a response file in JSON format that will
 289     be retrieved and made available by the Ansible Server if, as part of a VNF
 290     or PNF action (e.g., audit), a playbook is required to return any VNF or
 291     PNF information/response. The text files must be written in the main
 292     playbook home directory, in JSON format. The JSON file must be created for
 293     the VNF or PNF with the name '<VNF or PNF name>_results.txt'. All playbook
 294     output results, for all VNF or PNF VMs, to be provided as a response to the
 295     request, must be written to this response file.
 296
 297
 298 .. container:: note
 299
 300     :need:`R-49751`
 301
 302     The VNF or PNF **MUST** support Ansible playbooks that are compatible with
 303     Ansible version 2.6 or later.
 304
 305
 306 .. container:: note
 307
 308     :need:`R-33280`
 309
 310     The VNF or PNF **MUST NOT** use any instance specific parameters
 311     in a playbook.
 312
 313
 314 .. container:: note
 315
 316     :need:`R-40293`
 317
 318     The VNF or PNF **MUST** make available playbooks that conform
 319     to the ONAP requirement.
 320
 321
 322 .. container:: note
 323
 324     :need:`R-02651`
 325
 326     The VNF or PNF **SHOULD** use available backup capabilities to save a
 327     copy of configuration files before implementing changes to support
 328     operations such as backing out of software upgrades, configuration
 329     changes or other work as this will help backing out of configuration
 330     changes when needed.
 331
 332
 333 .. container:: note
 334
 335     :need:`R-49396`
 336
 337     The VNF or PNF **MUST** support each APPC/SDN-C VNF or PNF action
 338     by invocation of **one** playbook [#7.3.4]_. The playbook will be
 339     responsible for executing all necessary tasks (as well as calling other
 340     playbooks) to complete the request.
 341
 342
 343 Configuration Management > Chef Standards and Capabilities > VNF or PNF Configuration via Chef Requirements > Chef Client Requirements
 344 --------------------------------------------------------------------------------------------------------------------------------------
 345
 346
 347 Requirements Changed
 348 ~~~~~~~~~~~~~~~~~~~~
 349
 350
 351 .. container:: note
 352
 353     :need:`R-47068`
 354
 355     The VNF or PNF **MAY** expose a single endpoint that is
 356     responsible for all functionality.
 357
 358
 359 .. container:: note
 360
 361     :need:`R-79224`
 362
 363     The VNF or PNF **MUST** have the chef-client be preloaded with
 364     validator keys and configuration to register with the designated
 365     Chef Server as part of the installation process.
 366
 367
 368 .. container:: note
 369
 370     :need:`R-67114`
 371
 372     The VNF or PNF **MUST** be installed with Chef-Client >= 12.0 and Chef
 373     push jobs client >= 2.0.
 374
 375
 376 .. container:: note
 377
 378     :need:`R-72184`
 379
 380     The VNF or PNF **MUST** have routable FQDNs for all the endpoints
 381     (VMs) of a VNF or PNF that contain chef-clients which are used to register
 382     with the Chef Server.  As part of invoking VNF or PNF actions, ONAP will
 383     trigger push jobs against FQDNs of endpoints for a VNF or PNF, if required.
 384
 385
 386 Configuration Management > Chef Standards and Capabilities > VNF or PNF Configuration via Chef Requirements > Chef Roles/Requirements
 387 -------------------------------------------------------------------------------------------------------------------------------------
 388
 389
 390 Requirements Changed
 391 ~~~~~~~~~~~~~~~~~~~~
 392
 393
 394 .. container:: note
 395
 396     :need:`R-37929`
 397
 398     The VNF or PNF **MUST** accept all necessary instance specific
 399     data from the environment or node object attributes for the VNF or PNF
 400     in roles/cookbooks/recipes invoked for a VNF or PNF action.
 401
 402
 403 .. container:: note
 404
 405     :need:`R-62170`
 406
 407     The VNF or PNF **MUST** over-ride any default values for
 408     configurable parameters that can be set by ONAP in the roles,
 409     cookbooks and recipes.
 410
 411
 412 .. container:: note
 413
 414     :need:`R-30654`
 415
 416     The VNF or PNF Package **MUST** have appropriate cookbooks that are
 417     designed to automatically 'rollback' to the original state in case of
 418     any errors for actions that change state of the VNF or PNF (e.g.,
 419     configure).
 420
 421
 422 .. container:: note
 423
 424     :need:`R-26567`
 425
 426     The VNF or PNF Package **MUST** include a run list of
 427     roles/cookbooks/recipes, for each supported VNF or PNF action, that will
 428     perform the desired VNF or PNF action in its entirety as specified by ONAP
 429     (see Section 7.c, APPC/SDN-C APIs and Behavior, for list of VNF or PNF
 430     actions and requirements), when triggered by a chef-client run list
 431     in JSON file.
 432
 433
 434 .. container:: note
 435
 436     :need:`R-27310`
 437
 438     The VNF or PNF Package **MUST** include all relevant Chef artifacts
 439     (roles/cookbooks/recipes) required to execute VNF or PNF actions requested
 440     by ONAP for loading on appropriate Chef Server.
 441
 442
 443 .. container:: note
 444
 445     :need:`R-44013`
 446
 447     The VNF or PNF **MUST** populate an attribute, defined as node
 448     ['PushJobOutput'] with the desired output on all nodes in the push job
 449     that execute chef-client run if the VNF or PNF action requires the output
 450     of a chef-client run be made available (e.g., get running configuration).
 451
 452
 453 .. container:: note
 454
 455     :need:`R-15885`
 456
 457     The VNF or PNF **MUST** Upon completion of the chef-client run,
 458     POST back on the callback URL, a JSON object as described in Table
 459     A2 if the chef-client run list includes a cookbook/recipe that is
 460     callback capable. Failure to POST on the Callback Url should not be
 461     considered a critical error. That is, if the chef-client successfully
 462     completes the VNF or PNF action, it should reflect this status on the Chef
 463     Server regardless of whether the Callback succeeded or not.
 464
 465
 466 .. container:: note
 467
 468     :need:`R-65755`
 469
 470     The VNF or PNF **SHOULD** support callback URLs to return information
 471     to ONAP upon completion of the chef-client run for any chef-client run
 472     associated with a VNF or PNF action.
 473
 474     -  As part of the push job, ONAP will provide two parameters in the
 475        environment of the push job JSON object:
 476
 477         -  "RequestId" a unique Id to be used to identify the request,
 478         -  "CallbackUrl", the URL to post response back.
 479
 480     -  If the CallbackUrl field is empty or missing in the push job, then
 481        the chef-client run need not post the results back via callback.
 482
 483
 484 .. container:: note
 485
 486     :need:`R-98911`
 487
 488     The VNF or PNF **MUST NOT** use any instance specific parameters
 489     for the VNF or PNF in roles/cookbooks/recipes invoked for a VNF or PNF
 490     action.
 491
 492
 493 .. container:: note
 494
 495     :need:`R-78116`
 496
 497     The VNF or PNF **MUST** update status on the Chef Server
 498     appropriately (e.g., via a fail or raise an exception) if the
 499     chef-client run encounters any critical errors/failures when
 500     executing a VNF or PNF action.
 501
 502
 503 Configuration Management > Controller Interactions With VNF or PNF > Configuration Commands
 504 -------------------------------------------------------------------------------------------
 505
 506
 507 Requirements Changed
 508 ~~~~~~~~~~~~~~~~~~~~
 509
 510
 511 .. container:: note
 512
 513     :need:`R-20741`
 514
 515     The VNF or PNF **MUST** support APPC/SDN-C ``Configure`` command.
 516
 517
 518 .. container:: note
 519
 520     :need:`R-56385`
 521
 522     The VNF or PNF **MUST** support APPC ``Audit`` command.
 523
 524
 525 .. container:: note
 526
 527     :need:`R-48247`
 528
 529     The VNF or PNF **MUST** support APPC ``ConfigRestore`` command.
 530
 531
 532 .. container:: note
 533
 534     :need:`R-94084`
 535
 536     The VNF or PNF **MUST** support APPC/SDN-C ``ConfigScaleOut`` command.
 537
 538
 539 .. container:: note
 540
 541     :need:`R-19366`
 542
 543     The VNF or PNF **MUST** support APPC ``ConfigModify`` command.
 544
 545
 546 .. container:: note
 547
 548     :need:`R-32981`
 549
 550     The VNF or PNF **MUST** support APPC ``ConfigBackup`` command.
 551
 552
 553 Configuration Management > Controller Interactions With VNF or PNF > HealthCheck and Failure Related Commands
 554 -------------------------------------------------------------------------------------------------------------
 555
 556
 557 Requirements Changed
 558 ~~~~~~~~~~~~~~~~~~~~
 559
 560
 561 .. container:: note
 562
 563     :need:`R-41430`
 564
 565     The VNF or PNF **MUST** support APPC/SDN-C ``HealthCheck`` command.
 566
 567
 568 Configuration Management > Controller Interactions With VNF or PNF > Lifecycle Management Related Commands
 569 ----------------------------------------------------------------------------------------------------------
 570
 571
 572 Requirements Changed
 573 ~~~~~~~~~~~~~~~~~~~~
 574
 575
 576 .. container:: note
 577
 578     :need:`R-65641`
 579
 580     The VNF or PNF **MUST** support APPC/SDN-C ``UpgradeBackOut`` command.
 581
 582
 583 .. container:: note
 584
 585     :need:`R-97343`
 586
 587     The VNF or PNF **MUST** support APPC/SDN-C ``UpgradeBackup`` command.
 588
 589
 590 .. container:: note
 591
 592     :need:`R-45856`
 593
 594     The VNF or PNF **MUST** support APPC/SDN-C ``UpgradePostCheck`` command.
 595
 596
 597 .. container:: note
 598
 599     :need:`R-07251`
 600
 601     The VNF or PNF **MUST** support APPC/SDN-C ``ResumeTraffic`` command.
 602
 603
 604 .. container:: note
 605
 606     :need:`R-19922`
 607
 608     The VNF or PNF **MUST** support APPC/SDN-C ``UpgradePrecheck`` command.
 609
 610
 611 .. container:: note
 612
 613     :need:`R-49466`
 614
 615     The VNF or PNF **MUST** support APPC/SDN-C ``UpgradeSoftware`` command.
 616
 617
 618 .. container:: note
 619
 620     :need:`R-82811`
 621
 622     The VNF or PNF **MUST** support APPC ``StartApplication`` command.
 623
 624
 625 .. container:: note
 626
 627     :need:`R-12706`
 628
 629     The VNF or PNF **MUST** support APPC/SDN-C ``QuiesceTraffic`` command.
 630
 631
 632 .. container:: note
 633
 634     :need:`R-328086`
 635
 636     The VNF or PNF **MUST**, if serving as a distribution point or anchor point for
 637     steering point from source to destination, support the ONAP Controller's
 638     ``DistributeTraffic`` command.
 639
 640
 641 .. container:: note
 642
 643     :need:`R-83146`
 644
 645     The VNF or PNF **MUST** support APPC ``StopApplication`` command.
 646
 647
 648 Configuration Management > NETCONF Standards and Capabilities > VNF or PNF Configuration via NETCONF Requirements > Configuration Management
 649 --------------------------------------------------------------------------------------------------------------------------------------------
 650
 651
 652 Requirements Changed
 653 ~~~~~~~~~~~~~~~~~~~~
 654
 655
 656 .. container:: note
 657
 658     :need:`R-95950`
 659
 660     The VNF or PNF **MUST** provide a NETCONF interface fully defined
 661     by supplied YANG models for the embedded NETCONF server.
 662
 663
 664 .. container:: note
 665
 666     :need:`R-88026`
 667
 668     The VNF or PNF **MUST** include a NETCONF server enabling
 669     runtime configuration and lifecycle management capabilities.
 670
 671
 672 Configuration Management > NETCONF Standards and Capabilities > VNF or PNF Configuration via NETCONF Requirements > NETCONF Server Requirements
 673 -----------------------------------------------------------------------------------------------------------------------------------------------
 674
 675
 676 Requirements Added
 677 ~~~~~~~~~~~~~~~~~~
 678
 679
 680 .. container:: note
 681
 682     :need:`R-997907`
 683
 684     The VNF or PNF **SHOULD** support TLS as secure transport for the NETCONF
 685     protocol according to [RFC7589].
 686
 687
 688 Requirements Changed
 689 ~~~~~~~~~~~~~~~~~~~~
 690
 691
 692 .. container:: note
 693
 694     :need:`R-26115`
 695
 696     The VNF or PNF **MUST** follow the data model update rules defined in
 697     [RFC6020] section 10 for YANG 1.0 modules, and [RFC7950] section 11
 698     for YANG 1.1 modules. All deviations from the aforementioned update
 699     rules shall be handled by a built-in  automatic upgrade mechanism.
 700
 701
 702 .. container:: note
 703
 704     :need:`R-10716`
 705
 706     The VNF or PNF **MUST** support parallel and simultaneous
 707     configuration of separate objects within itself.
 708
 709
 710 .. container:: note
 711
 712     :need:`R-59610`
 713
 714     The VNF or PNF **MUST** implement the data model discovery and
 715     download as defined in [RFC6022].
 716
 717
 718 .. container:: note
 719
 720     :need:`R-83790`
 721
 722     The VNF or PNF **MUST** implement the ``:validate`` capability.
 723
 724
 725 .. container:: note
 726
 727     :need:`R-62468`
 728
 729     The VNF or PNF **MUST** allow all configuration data to be
 730     edited through a NETCONF <edit-config> operation. Proprietary
 731     NETCONF RPCs that make configuration changes are not sufficient.
 732
 733
 734 .. container:: note
 735
 736     :need:`R-29495`
 737
 738     The VNF or PNF **MUST** support locking if a common object is
 739     being manipulated by two simultaneous NETCONF configuration operations
 740     on the same VNF or PNF within the context of the same writable running data
 741     store (e.g., if an interface parameter is being configured then it
 742     should be locked out for configuration by a simultaneous configuration
 743     operation on that same interface parameter).
 744
 745
 746 .. container:: note
 747
 748     :need:`R-88031`
 749
 750     The VNF or PNF **SHOULD** implement the protocol operation:
 751     ``delete-config(target)`` - Delete the named configuration
 752     data store target.
 753
 754
 755 .. container:: note
 756
 757     :need:`R-54190`
 758
 759     The VNF or PNF **MUST** release locks to prevent permanent lock-outs
 760     when/if a session applying the lock is terminated (e.g., SSH session
 761     is terminated).
 762
 763
 764 .. container:: note
 765
 766     :need:`R-49145`
 767
 768     The VNF or PNF **MUST** implement ``:confirmed-commit`` If
 769     ``:candidate`` is supported.
 770
 771
 772 .. container:: note
 773
 774     :need:`R-96554`
 775
 776     The VNF or PNF **MUST** implement the protocol operation:
 777     ``unlock(target)`` - Unlock the configuration data store target.
 778
 779
 780 .. container:: note
 781
 782     :need:`R-22946`
 783
 784     The VNF or PNF **SHOULD** conform its YANG model to RFC 6536,
 785     "NETCONF Access Control Model".
 786
 787
 788 .. container:: note
 789
 790     :need:`R-01382`
 791
 792     The VNF or PNF **MUST** allow the entire configuration of the VNF or PNF to be
 793     retrieved via NETCONF's <get-config> and <edit-config>, independently
 794     of whether it was configured via NETCONF or other mechanisms.
 795
 796
 797 .. container:: note
 798
 799     :need:`R-10173`
 800
 801     The VNF or PNF **MUST** allow another NETCONF session to be able to
 802     initiate the release of the lock by killing the session owning the lock,
 803     using the <kill-session> operation to guard against hung NETCONF sessions.
 804
 805
 806 .. container:: note
 807
 808     :need:`R-08134`
 809
 810     The VNF or PNF **MUST** conform to the NETCONF RFC 6241,
 811     "NETCONF Configuration Protocol".
 812
 813
 814 .. container:: note
 815
 816     :need:`R-60656`
 817
 818     The VNF or PNF **MUST** support sub tree filtering.
 819
 820
 821 .. container:: note
 822
 823     :need:`R-29488`
 824
 825     The VNF or PNF **MUST** implement the protocol operation:
 826     ``get-config(source, filter`` - Retrieve a (filtered subset of
 827     a) configuration from the configuration data store source.
 828
 829
 830 .. container:: note
 831
 832     :need:`R-01334`
 833
 834     The VNF or PNF **MUST** conform to the NETCONF RFC 5717,
 835     "Partial Lock Remote Procedure Call".
 836
 837
 838 .. container:: note
 839
 840     :need:`R-33946`
 841
 842     The VNF or PNF **MUST** conform to the NETCONF RFC 4741,
 843     "NETCONF Configuration Protocol".
 844
 845
 846 .. container:: note
 847
 848     :need:`R-25238`
 849
 850     The VNF or PNF PACKAGE **MUST** validated YANG code using the open
 851     source pyang [#7.3.1]_ program using the following commands:
 852
 853     .. code-block:: text
 854
 855       $ pyang --verbose --strict <YANG-file-name(s)> $ echo $!
 856
 857
 858 .. container:: note
 859
 860     :need:`R-10129`
 861
 862     The VNF or PNF **SHOULD** conform its YANG model to RFC 7223,
 863     "A YANG Data Model for Interface Management".
 864
 865
 866 .. container:: note
 867
 868     :need:`R-33955`
 869
 870     The VNF or PNF **SHOULD** conform its YANG model to RFC 6991,
 871     "Common YANG Data Types".
 872
 873
 874 .. container:: note
 875
 876     :need:`R-88899`
 877
 878     The VNF or PNF **MUST** support simultaneous <commit> operations
 879     within the context of this locking requirements framework.
 880
 881
 882 .. container:: note
 883
 884     :need:`R-11235`
 885
 886     The VNF or PNF **MUST** implement the protocol operation:
 887     ``kill-session(session``- Force the termination of **session**.
 888
 889
 890 .. container:: note
 891
 892     :need:`R-12271`
 893
 894     The VNF or PNF **SHOULD** conform its YANG model to RFC 7223,
 895     "IANA Interface Type YANG Module".
 896
 897
 898 .. container:: note
 899
 900     :need:`R-90007`
 901
 902     The VNF or PNF **MUST** implement the protocol operation:
 903     ``close-session()`` - Gracefully close the current session.
 904
 905
 906 .. container:: note
 907
 908     :need:`R-03465`
 909
 910     The VNF or PNF **MUST** release locks to prevent permanent lock-outs
 911     when the corresponding <partial-unlock> operation succeeds.
 912
 913
 914 .. container:: note
 915
 916     :need:`R-93443`
 917
 918     The VNF or PNF **MUST** define all data models in YANG 1.0 [RFC6020] or
 919     YANG 1.1 [RFC7950]. A combination of YANG 1.0 and YANG 1.1 modules is
 920     allowed subject to the rules in [RFC7950] section 12. The mapping to
 921     NETCONF shall follow the rules defined in this RFC.
 922
 923
 924 .. container:: note
 925
 926     :need:`R-29324`
 927
 928     The VNF or PNF **SHOULD** implement the protocol operation:
 929     ``copy-config(target, source)`` - Copy the content of the
 930     configuration data store source to the configuration data store target.
 931
 932
 933 .. container:: note
 934
 935     :need:`R-68990`
 936
 937     The VNF or PNF **MUST** support the ``:startup`` capability. It
 938     will allow the running configuration to be copied to this special
 939     database. It can also be locked and unlocked.
 940
 941
 942 .. container:: note
 943
 944     :need:`R-80898`
 945
 946     TThe VNF or PNF **MUST** support heartbeat via a <get> with null filter.
 947
 948
 949 .. container:: note
 950
 951     :need:`R-66793`
 952
 953     The VNF or PNF **MUST** guarantee the VNF or PNF configuration integrity
 954     for all simultaneous configuration operations (e.g., if a change is
 955     attempted to the BUM filter rate from multiple interfaces on the same
 956     EVC, then they need to be sequenced in the VNF or PNF without locking either
 957     configuration method out).
 958
 959
 960 .. container:: note
 961
 962     :need:`R-11499`
 963
 964     The VNF or PNF **MUST** fully support the XPath 1.0 specification
 965     for filtered retrieval of configuration and other database contents.
 966     The 'type' attribute within the <filter> parameter for <get> and
 967     <get-config> operations may be set to 'xpath'. The 'select' attribute
 968     (which contains the XPath expression) will also be supported by the
 969     server. A server may support partial XPath retrieval filtering, but
 970     it cannot advertise the ``:xpath`` capability unless the entire XPath
 971     1.0 specification is supported.
 972
 973
 974 .. container:: note
 975
 976     :need:`R-63935`
 977
 978     The VNF or PNF **MUST** release locks to prevent permanent lock-outs
 979     when a user configured timer has expired forcing the NETCONF SSH Session
 980     termination (i.e., product must expose a configuration knob for a user
 981     setting of a lock expiration timer).
 982
 983
 984 .. container:: note
 985
 986     :need:`R-63953`
 987
 988     The VNF or PNF **MUST** have the echo command return a zero value
 989     otherwise the validation has failed.
 990
 991
 992 .. container:: note
 993
 994     :need:`R-26508`
 995
 996     The VNF or PNF **MUST** support a NETCONF server that can be mounted on
 997     OpenDaylight (client) and perform the operations of: modify, update,
 998     change, rollback configurations using each configuration data element,
 999     query each state (non-configuration) data element, execute each YANG
1000     RPC, and receive data through each notification statement.
1001
1002
1003 .. container:: note
1004
1005     :need:`R-70496`
1006
1007     The VNF or PNF **MUST** implement the protocol operation:
1008     ``commit(confirmed, confirm-timeout)`` - Commit candidate
1009     configuration data store to the running configuration.
1010
1011
1012 .. container:: note
1013
1014     :need:`R-24269`
1015
1016     The VNF or PNF **SHOULD** conform its YANG model to RFC 7407,
1017     "A YANG Data Model for SNMP Configuration", if Netconf used to
1018     configure SNMP engine.
1019
1020
1021 .. container:: note
1022
1023     :need:`R-13800`
1024
1025     The VNF or PNF **MUST** conform to the NETCONF RFC 5277,
1026     "NETCONF Event Notification".
1027
1028
1029 .. container:: note
1030
1031     :need:`R-22700`
1032
1033     The VNF or PNF **MUST** conform its YANG model to RFC 6470,
1034     "NETCONF Base Notifications".
1035
1036
1037 .. container:: note
1038
1039     :need:`R-78282`
1040
1041     The VNF or PNF **MUST** conform to the NETCONF RFC 6242,
1042     "Using the Network Configuration Protocol over Secure Shell".
1043
1044
1045 .. container:: note
1046
1047     :need:`R-53317`
1048
1049     The VNF or PNF **MUST** conform its YANG model to RFC 6087,
1050     "Guidelines for Authors and Reviewers of YANG Data Model specification".
1051
1052
1053 .. container:: note
1054
1055     :need:`R-97529`
1056
1057     The VNF or PNF **SHOULD** implement the protocol operation:
1058     ``get-schema(identifier, version, format)`` - Retrieve the YANG schema.
1059
1060
1061 .. container:: note
1062
1063     :need:`R-18733`
1064
1065     The VNF or PNF **MUST** implement the protocol operation:
1066     ``discard-changes()`` - Revert the candidate configuration
1067     data store to the running configuration.
1068
1069
1070 .. container:: note
1071
1072     :need:`R-44281`
1073
1074     The VNF or PNF **MUST** implement the protocol operation:
1075     ``edit-config(target, default-operation, test-option, error-option,
1076     config)`` - Edit the target configuration data store by merging,
1077     replacing, creating, or deleting new config elements.
1078
1079
1080 .. container:: note
1081
1082     :need:`R-02597`
1083
1084     The VNF or PNF **MUST** implement the protocol operation:
1085     ``lock(target)`` - Lock the configuration data store target.
1086
1087
1088 .. container:: note
1089
1090     :need:`R-20353`
1091
1092     The VNF or PNF **MUST** implement both ``:candidate`` and
1093     ``:writable-running`` capabilities. When both ``:candidate`` and
1094     ``:writable-running`` are provided then two locks should be supported.
1095
1096
1097 .. container:: note
1098
1099     :need:`R-10353`
1100
1101     The VNF or PNF **MUST** conform its YANG model to RFC 6244,
1102     "An Architecture for Network Management Using NETCONF and YANG".
1103
1104
1105 .. container:: note
1106
1107     :need:`R-60106`
1108
1109     The VNF or PNF **MUST** implement the protocol operation:
1110     ``get(filter)`` - Retrieve (a filtered subset of) the running
1111     configuration and device state information. This should include
1112     the list of VNF or PNF supported schemas.
1113
1114
1115 .. container:: note
1116
1117     :need:`R-87564`
1118
1119     The VNF or PNF **SHOULD** conform its YANG model to RFC 7317,
1120     "A YANG Data Model for System Management".
1121
1122
1123 .. container:: note
1124
1125     :need:`R-83873`
1126
1127     The VNF or PNF **MUST** support ``:rollback-on-error`` value for
1128     the <error-option> parameter to the <edit-config> operation. If any
1129     error occurs during the requested edit operation, then the target
1130     database (usually the running configuration) will be left unaffected.
1131     This provides an 'all-or-nothing' edit mode for a single <edit-config>
1132     request.
1133
1134
1135 .. container:: note
1136
1137     :need:`R-73468`
1138
1139     The VNF or PNF **MUST** allow the NETCONF server connection
1140     parameters to be configurable during virtual machine instantiation
1141     through Heat templates where SSH keys, usernames, passwords, SSH
1142     service and SSH port numbers are Heat template parameters.
1143
1144
1145 .. container:: note
1146
1147     :need:`R-28756`
1148
1149     The VNF or PNF **MUST** support ``:partial-lock`` and
1150     ``:partial-unlock`` capabilities, defined in RFC 5717. This
1151     allows multiple independent clients to each write to a different
1152     part of the <running> configuration at the same time.
1153
1154
1155 .. container:: note
1156
1157     :need:`R-68200`
1158
1159     The VNF or PNF **MUST** support the ``:url`` value to specify
1160     protocol operation source and target parameters. The capability URI
1161     for this feature will indicate which schemes (e.g., file, https, sftp)
1162     that the server supports within a particular URL value. The 'file'
1163     scheme allows for editable local configuration databases. The other
1164     schemes allow for remote storage of configuration databases.
1165
1166
1167 .. container:: note
1168
1169     :need:`R-53015`
1170
1171     The VNF or PNF **MUST** apply locking based on the sequence of
1172     NETCONF operations, with the first configuration operation locking
1173     out all others until completed.
1174
1175
1176 .. container:: note
1177
1178     :need:`R-07545`
1179
1180     The VNF or PNF **MUST** support all operations, administration and
1181     management (OAM) functions available from the supplier for VNFs or PNFs
1182     using the supplied YANG code and associated NETCONF servers.
1183
1184
1185 .. container:: note
1186
1187     :need:`R-41829`
1188
1189     The VNF or PNF **MUST** be able to specify the granularity of the
1190     lock via a restricted or full XPath expression.
1191
1192
1193 .. container:: note
1194
1195     :need:`R-49036`
1196
1197     The VNF or PNF **SHOULD** conform its YANG model to RFC 7277,
1198     "A YANG Data Model for IP Management".
1199
1200
1201 .. container:: note
1202
1203     :need:`R-02616`
1204
1205     The VNF or PNF **MUST** permit locking at the finest granularity
1206     if a VNF or PNF needs to lock an object for configuration to avoid blocking
1207     simultaneous configuration operations on unrelated objects (e.g., BGP
1208     configuration should not be locked out if an interface is being
1209     configured or entire Interface configuration should not be locked out
1210     if a non-overlapping parameter on the interface is being configured).
1211
1212
1213 .. container:: note
1214
1215     :need:`R-58358`
1216
1217     The VNF or PNF **MUST** implement the ``:with-defaults`` capability
1218     [RFC6243].
1219
1220
1221 .. container:: note
1222
1223     :need:`R-04158`
1224
1225     The VNF or PNF **MUST** conform to the NETCONF RFC 4742,
1226     "Using the NETCONF Configuration Protocol over Secure Shell (SSH)".
1227
1228
1229 Configuration Management > NETCONF Standards and Capabilities > xNF Configuration via NETCONF Requirements > NETCONF Server Requirements
1230 ----------------------------------------------------------------------------------------------------------------------------------------
1231
1232
1233 Requirements Removed
1234 ~~~~~~~~~~~~~~~~~~~~
1235
1236
1237 .. container:: note
1238
1239     R-28545
1240
1241     The xNF **MUST** conform its YANG model to RFC 6060,
1242     "YANG - A Data Modeling Language for the Network Configuration
1243     Protocol (NETCONF)".
1244
1245
1246 Configuration Management > VNF or PNF REST APIs > REST APIs
1247 -----------------------------------------------------------
1248
1249
1250 Requirements Changed
1251 ~~~~~~~~~~~~~~~~~~~~
1252
1253
1254 .. container:: note
1255
1256     :need:`R-31809`
1257
1258     The VNF or PNF **MUST** support the HealthCheck RPC. The HealthCheck
1259     RPC executes a VNF or PNF Provider-defined VNF or PNF HealthCheck over the
1260     scope of the entire VNF or PNF (e.g., if there are multiple VNFCs, then
1261     run a health check, as appropriate, for all VNFCs). It returns a 200 OK if
1262     the test completes. A JSON object is returned indicating state (healthy,
1263     unhealthy), scope identifier, time-stamp and one or more blocks containing
1264     info and fault information. If the VNF or PNF is unable to run the
1265     HealthCheck, return a standard http error code and message.
1266
1267
1268 Contrail Resource Parameters > OS::ContrailV2::VirtualMachineInterface Property virtual_machine_interface_allowed_address_pairs > External Networks
1269 ---------------------------------------------------------------------------------------------------------------------------------------------------
1270
1271
1272 Requirements Added
1273 ~~~~~~~~~~~~~~~~~~
1274
1275
1276 .. container:: note
1277
1278     :need:`R-100280`
1279
1280     If a VNF's Heat Orchestration Template's resource
1281     ``OS::ContrailV2::VirtualMachineInterface``
1282     is attaching to an external network (per the
1283     ONAP definition, see Requirement R-57424), the
1284     map property
1285
1286     ``virtual_machine_interface_allowed_address_pairs``,
1287
1288     ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``,
1289
1290     ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``,
1291
1292     ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
1293
1294     parameter
1295     **MUST NOT** be enumerated in the
1296     VNF's Heat Orchestration Template's Environment File.
1297
1298
1299 .. container:: note
1300
1301     :need:`R-100310`
1302
1303     When the VNF's Heat Orchestration Template's resource
1304     ``OS::ContrailV2::VirtualMachineInterface`` is attaching to an external
1305     network (per the
1306     ONAP definition, see Requirement R-57424),
1307     and an IPv4 Virtual IP (VIP)
1308     is required to be supported by the ONAP data model,
1309     the map property
1310
1311     ``virtual_machine_interface_allowed_address_pairs``,
1312
1313     ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``,
1314
1315     ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``,
1316
1317     ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
1318
1319     parameter name **MUST** follow the naming convention
1320
1321     * ``{vm-type}_{network-role}_floating_ip``
1322
1323     where
1324
1325     * ``{vm-type}`` is the {vm-type} associated with the ``OS::Nova::Server``
1326     * ``{network-role}`` is the {network-role} of the external network
1327
1328     And the parameter **MUST** be declared as type ``string``.
1329
1330     The ONAP data model can only support one IPv4 VIP address.
1331
1332
1333 .. container:: note
1334
1335     :need:`R-100330`
1336
1337     When the VNF's Heat Orchestration Template's resource
1338     ``OS::ContrailV2::VirtualMachineInterface`` is attaching to an external
1339     network (per the
1340     ONAP definition, see Requirement R-57424),
1341     and an IPv6 Virtual IP (VIP)
1342     is required to be supported by the ONAP data model,
1343     the map property
1344
1345     ``virtual_machine_interface_allowed_address_pairs``,
1346
1347     ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``,
1348
1349     ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``,
1350
1351     ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
1352
1353     parameter name **MUST** follow the naming convention
1354
1355     * ``{vm-type}_{network-role}_floating_v6_ip``
1356
1357     where
1358
1359     * ``{vm-type}`` is the {vm-type} associated with the ``OS::Nova::Server``
1360     * ``{network-role}`` is the {network-role} of the external network
1361
1362     And the parameter **MUST** be declared as type ``string``.
1363
1364     The ONAP data model can only support one IPv6 VIP address.
1365
1366
1367 .. container:: note
1368
1369     :need:`R-100350`
1370
1371     When the VNF's Heat Orchestration Template's resource
1372     ``OS::ContrailV2::VirtualMachineInterface`` is attaching to an
1373     external network
1374     (per the ONAP definition, see Requirement R-57424),
1375     and the IPv4 VIP address and/or IPv6 VIP address
1376     is **not** supported by the ONAP data model,
1377     the map property
1378
1379     ``virtual_machine_interface_allowed_address_pairs``,
1380
1381     ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``,
1382
1383     ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``,
1384
1385     ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
1386
1387     * Parameter name **MAY** use any naming convention.  That is, there is no
1388       ONAP mandatory parameter naming convention.
1389     * Parameter **MAY** be declared as type ``string`` or type
1390     ``comma_delimited_list``.
1391
1392     And the ``OS::ContrailV2::VirtualMachineInterface`` resource
1393     **MUST** contain resource-level ``metadata`` (not property-level).
1394
1395     And the ``metadata`` format **MUST**  must contain the
1396     key value ``aap_exempt`` with a list of all map property
1397
1398     ``virtual_machine_interface_allowed_address_pairs``,
1399
1400     ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``,
1401
1402     ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``,
1403
1404     ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
1405
1406     parameters **not** supported by the ONAP data model.
1407
1408
1409 Contrail Resource Parameters > OS::ContrailV2::VirtualMachineInterface Property virtual_machine_interface_allowed_address_pairs > Internal Networks
1410 ---------------------------------------------------------------------------------------------------------------------------------------------------
1411
1412
1413 Requirements Added
1414 ~~~~~~~~~~~~~~~~~~
1415
1416
1417 .. container:: note
1418
1419     :need:`R-100360`
1420
1421     When the VNF's Heat Orchestration Template's Resource
1422     ``OS::ContrailV2::VirtualMachineInterface`` is attaching to an
1423     internal network (per the
1424     ONAP definition, see Requirements R-52425 and R-46461),
1425     and an IPv4 Virtual IP (VIP)
1426     address is assigned using the map property,
1427     ``virtual_machine_interface_allowed_address_pairs,
1428     virtual_machine_interface_allowed_address_pairs_allowed_address_pair,
1429     virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip,
1430     virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
1431     , the parameter name **MUST** follow the
1432     naming convention
1433
1434       * ``{vm-type}_int_{network-role}_floating_ip``
1435
1436     where
1437
1438       * ``{vm-type}`` is the {vm-type} associated with the
1439         OS::Nova::Server
1440       * ``{network-role}`` is the {network-role} of the external
1441         network
1442
1443     And the parameter **MUST** be declared as ``type: string``
1444     and **MUST** be enumerated in the environment file.
1445
1446     OR
1447
1448     the parameter name **MUST** follow the
1449     naming convention
1450
1451       * ``{vm-type}_int_{network-role}_floating_ips``
1452
1453     where
1454
1455       * ``{vm-type}`` is the {vm-type} associated with the
1456         OS::Nova::Server
1457       * ``{network-role}`` is the {network-role} of the external
1458         network
1459
1460     And the parameter **MUST** be declared as ``type: comma_delimited_list``
1461     and **MUST** be enumerated in the environment file.
1462
1463
1464 .. container:: note
1465
1466     :need:`R-100370`
1467
1468     When the VNF's Heat Orchestration Template's Resource
1469     ``OS::ContrailV2::VirtualMachineInterface`` is attaching to an
1470     internal network (per the
1471     ONAP definition, see Requirements R-52425 and R-46461),
1472     and an IPv6 Virtual IP (VIP)
1473     address is assigned
1474     using the map property,
1475     ``virtual_machine_interface_allowed_address_pairs,
1476     virtual_machine_interface_allowed_address_pairs_allowed_address_pair,
1477     virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip,
1478     virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
1479     , the parameter name **MUST** follow the
1480     naming convention
1481
1482       * ``{vm-type}_int_{network-role}_floating_v6_ip``
1483
1484     where
1485
1486       * ``{vm-type}`` is the {vm-type} associated with the
1487         OS::Nova::Server
1488       * ``{network-role}`` is the {network-role} of the external
1489         network
1490
1491     And the parameter **MUST** be declared as ``type: string``
1492     and **MUST** be enumerated in the environment file
1493
1494     OR
1495
1496     the parameter name **MUST** follow the
1497     naming convention
1498
1499       * ``{vm-type}_int_{network-role}_floating_v6_ips``
1500
1501     where
1502
1503       * ``{vm-type}`` is the {vm-type} associated with the
1504         OS::Nova::Server
1505       * ``{network-role}`` is the {network-role} of the external
1506         network
1507
1508     And the parameter **MUST** be declared as ``type: comma_delimited_list``
1509     and **MUST** be enumerated in the environment file.
1510
1511
1512 Contrail Resource Parameters > Resource OS::ContrailV2::InstanceIp > Resource OS::ContrailV2::InstanceIp Property instance_ip_address
1513 -------------------------------------------------------------------------------------------------------------------------------------
1514
1515
1516 Requirements Added
1517 ~~~~~~~~~~~~~~~~~~
1518
1519
1520 .. container:: note
1521
1522     :need:`R-100000`
1523
1524     The VNF's Heat Orchestration Template's
1525     resource ``OS::ContrailV2::InstanceIp`` property ``instance_ip_address``
1526     parameter
1527     **MUST** be declared as either type ``string`` or type
1528     ``comma_delimited_list``.
1529
1530
1531 .. container:: note
1532
1533     :need:`R-100010`
1534
1535     When the VNF's Heat Orchestration Template's Resource
1536     ``OS::ContrailV2::InstanceIp`` is assigning an IP address
1537     to an external network (per the ONAP definition, see Requirement R-57424),
1538     and an IPv4 address is assigned
1539     using the property ``instance_ip_address``
1540     and the parameter type is defined as a string,
1541     the parameter name **MUST** follow the
1542     naming convention
1543
1544     * ``{vm-type}_{network-role}_ip_{index}``
1545
1546     where
1547
1548     * ``{vm-type}`` is the {vm-type} associated with the ``OS::Nova::Server``
1549     * ``{network-role}`` is the {network-role} of the external network
1550     * ``{index}`` is a numeric value that **MUST** start at zero in a
1551       VNF's Heat Orchestration Template and **MUST** increment by one
1552
1553
1554 .. container:: note
1555
1556     :need:`R-100020`
1557
1558     The VNF's Heat Orchestration Template's Resource
1559     ``OS::ContrailV2::InstanceIp`` property ``instance_ip_address``
1560     parameter
1561     ``{vm-type}_{network-role}_ip_{index}``
1562     **MUST NOT** be enumerated in the
1563     VNF's Heat Orchestration Template's Environment File.
1564
1565
1566 .. container:: note
1567
1568     :need:`R-100030`
1569
1570     When the VNF's Heat Orchestration Template's Resource
1571     ``OS::ContrailV2::InstanceIp`` is assigning an IP address
1572     to an external network (per the
1573     ONAP definition, see Requirement R-57424),
1574     and an IPv4 address is assigned
1575     using the property ``instance_ip_address``
1576     and the parameter type is defined as a
1577     ``comma_delimited_list``,
1578     the parameter name **MUST** follow the
1579     naming convention
1580
1581       * ``{vm-type}_{network-role}_ips``
1582
1583       where
1584
1585       * ``{vm-type}`` is the {vm-type} associated with the
1586         ``OS::Nova::Server``
1587       * ``{network-role}`` is the {network-role} of the external
1588         network
1589
1590
1591 .. container:: note
1592
1593     :need:`R-100040`
1594
1595     The VNF's Heat Orchestration Template's Resource
1596     ``OS::ContrailV2::InstanceIp`` property ``instance_ip_address``
1597     parameter
1598     ``{vm-type}_{network-role}_ips``
1599     **MUST NOT** be enumerated in the
1600     VNF's Heat Orchestration Template's Environment File.
1601
1602
1603 .. container:: note
1604
1605     :need:`R-100050`
1606
1607     When the VNF's Heat Orchestration Template's Resource
1608     ``OS::ContrailV2::InstanceIp`` is assigning an IP address
1609     to an external network
1610     (per the
1611     ONAP definition, see Requirement R-57424),
1612     and an IPv6 address is assigned
1613     using the property ``instance_ip_address``
1614     and the parameter type is defined as a string,
1615     the parameter name **MUST** follow the
1616     naming convention
1617
1618     * ``{vm-type}_{network-role}_v6_ip_{index}``
1619
1620     where
1621
1622     * ``{vm-type}`` is the {vm-type} associated with the
1623       ``OS::Nova::Server``
1624     * ``{network-role}`` is the {network-role} of the external network
1625     * ``{index}`` is a numeric value that **MUST** start at zero in a
1626       VNF's Heat Orchestration Template and **MUST** increment by one
1627
1628
1629 .. container:: note
1630
1631     :need:`R-100060`
1632
1633     The VNF's Heat Orchestration Template's Resource
1634     ``OS::ContrailV2::InstanceIp`` property ``instance_ip_address``
1635     parameter
1636     ``{vm-type}_{network-role}_v6_ip_{index}``
1637     **MUST NOT** be enumerated in the
1638     VNF's Heat Orchestration Template's Environment File.
1639
1640
1641 .. container:: note
1642
1643     :need:`R-100070`
1644
1645     When the VNF's Heat Orchestration Template's Resource
1646     ``OS::ContrailV2::InstanceIp`` is assigning an IP address
1647     to an external network (per the
1648     ONAP definition, see Requirement R-57424),
1649     and an IPv6 address is assigned
1650     using the property ``instance_ip_address``
1651     and the parameter type is defined as a
1652     ``comma_delimited_list``,
1653     the parameter name **MUST** follow the
1654     naming convention
1655
1656       * ``{vm-type}_{network-role}_v6_ips``
1657
1658     where
1659
1660       * ``{vm-type}`` is the {vm-type} associated with the
1661         OS::Nova::Server
1662       * ``{network-role}`` is the {network-role} of the external
1663         network
1664
1665
1666 .. container:: note
1667
1668     :need:`R-100080`
1669
1670     The VNF's Heat Orchestration Template's Resource
1671     ``OS::ContrailV2::InstanceIp`` property ``instance_ip_address``
1672     parameter
1673     ``{vm-type}_{network-role}_v6_ips``
1674     **MUST NOT** be enumerated in the
1675     VNF's Heat Orchestration Template's Environment File.
1676
1677
1678 .. container:: note
1679
1680     :need:`R-100090`
1681
1682     When the VNF's Heat Orchestration Template's Resource
1683     ``OS::ContrailV2::InstanceIp`` is assigning an IP address
1684     to an internal network (per the
1685     ONAP definition, see Requirements R-52425 and R-46461),
1686     and an IPv4 address is assigned
1687     using the property ``instance_ip_address``
1688     and the parameter type is
1689     defined as a ``string``,
1690     the parameter name **MUST** follow the
1691     naming convention
1692
1693     * ``{vm-type}_int_{network-role}_ip_{index}``
1694
1695     where
1696
1697     * ``{vm-type}`` is the {vm-type} associated with the
1698       ``OS::Nova::Server``
1699     * ``{network-role}`` is the {network-role} of the internal network
1700     * ``{index}`` is a numeric value that **MUST** start at zero in a
1701       VNF's Heat Orchestration Template and **MUST** increment by one
1702
1703
1704 .. container:: note
1705
1706     :need:`R-100100`
1707
1708     The VNF's Heat Orchestration Template's Resource
1709     ``OS::ContrailV2::InstanceIp`` property ``instance_ip_address``
1710     parameter
1711     ``{vm-type}_int_{network-role}_ip_{index}``
1712     **MUST** be enumerated in the
1713     VNF's Heat Orchestration Template's Environment File.
1714
1715
1716 .. container:: note
1717
1718     :need:`R-100110`
1719
1720     When the VNF's Heat Orchestration Template's Resource
1721     ``OS::ContrailV2::InstanceIp`` is assigning an IP address
1722     to an internal network (per the
1723     ONAP definition, see Requirements R-52425 and R-46461),
1724     and an IPv4 address is assigned
1725     using the property ``instance_ip_address``
1726     and the parameter type is defined as a
1727     ``comma_delimited_list``,
1728     the parameter name **MUST** follow the
1729     naming convention
1730
1731       * ``{vm-type}_int_{network-role}_ips``
1732
1733     where
1734
1735       * ``{vm-type}`` is the {vm-type} associated with the
1736         ``OS::Nova::Server``
1737       * ``{network-role}`` is the {network-role} of the internal
1738         network
1739
1740
1741 .. container:: note
1742
1743     :need:`R-100120`
1744
1745     The VNF's Heat Orchestration Template's Resource
1746     ``OS::ContrailV2::InstanceIp`` property ``instance_ip_address``
1747     parameter
1748     ``{vm-type}_int_{network-role}_int_ips``
1749     **MUST** be enumerated in the
1750     VNF's Heat Orchestration Template's Environment File.
1751
1752
1753 .. container:: note
1754
1755     :need:`R-100130`
1756
1757     When the VNF's Heat Orchestration Template's Resource
1758     ``OS::ContrailV2::InstanceIp`` is assigning an IP address to an
1759     internal network (per the
1760     ONAP definition, see Requirements R-52425 and R-46461),
1761     and an IPv6 address is assigned
1762     using the property ``instance_ip_address``
1763     and the parameter type is defined as a
1764     ``string``,
1765     the parameter name **MUST** follow the
1766     naming convention
1767
1768     * ``{vm-type}_int_{network-role}_v6_ip_{index}``
1769
1770     where
1771
1772     * ``{vm-type}`` is the {vm-type} associated with the ``OS::Nova::Server``
1773     * ``{network-role}`` is the {network-role} of the internal network
1774     * ``{index}`` is a numeric value that **MUST** start at zero in a
1775       VNF's Heat Orchestration Template and **MUST** increment by one
1776
1777
1778 .. container:: note
1779
1780     :need:`R-100140`
1781
1782     The VNF's Heat Orchestration Template's Resource
1783     ``OS::ContrailV2::InstanceIp`` property ``instance_ip_address``
1784     parameter
1785     ``{vm-type}_int_{network-role}_v6_ip_{index}``
1786     **MUST** be enumerated in the
1787     VNF's Heat Orchestration Template's Environment File.
1788
1789
1790 .. container:: note
1791
1792     :need:`R-100150`
1793
1794     When the VNF's Heat Orchestration Template's Resource
1795     ``OS::ContrailV2::InstanceIp`` is assigning an IP address to an
1796     internal network (per the
1797     ONAP definition, see Requirements R-52425 and R-46461),
1798     and an IPv6 address is assigned
1799     using the property ``instance_ip_address``
1800     and the parameter type is defined as a
1801     ``comma_delimited_list``,
1802     the parameter name **MUST** follow the
1803     naming convention
1804
1805       * ``{vm-type}_int_{network-role}_v6_ips``
1806
1807     where
1808
1809       * ``{vm-type}`` is the {vm-type} associated with the
1810         ``OS::Nova::Server``
1811       * ``{network-role}`` is the {network-role} of the internal
1812         network
1813
1814
1815 .. container:: note
1816
1817     :need:`R-100160`
1818
1819     The VNF's Heat Orchestration Template's Resource
1820     ``OS::ContrailV2::InstanceIp`` property ``instance_ip_address``
1821     map property ``ip_address`` parameter
1822     ``{vm-type}_int_{network-role}_v6_ips``
1823     **MUST** be enumerated in the
1824     VNF's Heat Orchestration Template's Environment File.
1825
1826
1827 .. container:: note
1828
1829     :need:`R-100170`
1830
1831     The VNF's Heat Orchestration Template's Resource
1832     ``OS::ContrailV2::InstanceIp``
1833     property ``instance_ip_address``
1834     parameter associated with an external network, i.e.,
1835
1836      * ``{vm-type}_{network-role}_ip_{index}``
1837      * ``{vm-type}_{network-role}_v6_ip_{index}``
1838      * ``{vm-type}_{network-role}_ips``
1839      * ``{vm-type}_{network-role}_v6_ips``
1840
1841
1842     **MUST NOT** be enumerated in the Heat Orchestration
1843     Template's Environment File.  ONAP provides the IP address
1844     assignments at orchestration time.
1845
1846
1847 .. container:: note
1848
1849     :need:`R-100180`
1850
1851     The VNF's Heat Orchestration Template's Resource
1852     ``OS::ContrailV2::InstanceIp``
1853     property ``instance_ip_address``
1854     parameter associated with an internal network, i.e.,
1855
1856      * ``{vm-type}_int_{network-role}_ip_{index}``
1857      * ``{vm-type}_int_{network-role}_v6_ip_{index}``
1858      * ``{vm-type}_int_{network-role}_ips``
1859      * ``{vm-type}_int_{network-role}_v6_ips``
1860
1861
1862     **MUST** be enumerated in the Heat Orchestration
1863     Template's Environment File and IP addresses **MUST** be
1864     assigned.
1865
1866
1867 Contrail Resource Parameters > Resource OS::ContrailV2::InstanceIp > Resource OS::ContrailV2::InstanceIp Property subnet_uuid
1868 -----------------------------------------------------------------------------------------------------------------------------
1869
1870
1871 Requirements Added
1872 ~~~~~~~~~~~~~~~~~~
1873
1874
1875 .. container:: note
1876
1877     :need:`R-100190`
1878
1879     The VNF's Heat Orchestration Template's
1880     resource ``OS::ContrailV2::InstanceIp`` property ``subnet_uuid``
1881     parameter
1882     **MUST** be declared type ``string``.
1883
1884
1885 .. container:: note
1886
1887     :need:`R-100200`
1888
1889     When the VNF's Heat Orchestration Template's
1890     resource ``OS::ContrailV2::InstanceIp`` is assigning an IP address
1891     to an external network (per the ONAP definition, see
1892     Requirement R-57424),
1893     and an IPv4 address is being cloud assigned by OpenStack's DHCP Service
1894     and the external network IPv4 subnet is to be specified
1895     using the property ``subnet_uuid``, the parameter
1896     **MUST** follow the naming convention
1897
1898       * ``{network-role}_subnet_id``
1899
1900     where
1901
1902       * ``{network-role}`` is the network role of the network.
1903
1904
1905 .. container:: note
1906
1907     :need:`R-100210`
1908
1909     The VNF's Heat Orchestration Template's Resource
1910     ``OS::ContrailV2::InstanceIp`` property ``subnet_uuid``
1911     parameter
1912     ``{network-role}_subnet_id``
1913     **MUST NOT** be enumerated in the
1914     VNF's Heat Orchestration Template's Environment File.
1915
1916
1917 .. container:: note
1918
1919     :need:`R-100220`
1920
1921     When the VNF's Heat Orchestration Template's
1922     resource ``OS::ContrailV2::InstanceIp`` is assigning an IP address
1923     to an external network (per the ONAP definition, see
1924     Requirement R-57424),
1925     and an IPv6 address is being cloud assigned by OpenStack's DHCP Service
1926     and the external network IPv6 subnet is to be specified
1927     using the property ``subnet_uuid``, the parameter
1928     **MUST** follow the naming convention
1929
1930       * ``{network-role}_v6_subnet_id``
1931
1932     where
1933
1934       * ``{network-role}`` is the network role of the network.
1935
1936
1937 .. container:: note
1938
1939     :need:`R-100230`
1940
1941     The VNF's Heat Orchestration Template's Resource
1942     ``OS::ContrailV2::InstanceIp`` property ``subnet_uuid``
1943     parameter
1944     ``{network-role}_v6_subnet_id``
1945     **MUST NOT** be enumerated in the
1946     VNF's Heat Orchestration Template's Environment File.
1947
1948
1949 .. container:: note
1950
1951     :need:`R-100240`
1952
1953     When
1954
1955       * the VNF's Heat Orchestration Template's
1956         resource ``OS::ContrailV2::InstanceIp`` in an Incremental Module is
1957         assigning an IP address
1958         to an internal network (per the ONAP definition, see
1959         Requirements R-52425 and R-46461)
1960         that is created in the Base Module, AND
1961       * an IPv4 address is being cloud assigned by OpenStack's DHCP Service AND
1962       * the internal network IPv4 subnet is to be specified
1963         using the property ``subnet_uuid``,
1964
1965     the parameter **MUST** follow the naming convention
1966
1967       * ``int_{network-role}_subnet_id``
1968
1969     where
1970
1971       * ``{network-role}`` is the network role of the internal network
1972
1973     Note that the parameter **MUST** be defined as an ``output`` parameter in
1974     the base module.
1975
1976
1977 .. container:: note
1978
1979     :need:`R-100250`
1980
1981     The VNF's Heat Orchestration Template's Resource
1982     ``OS::ContrailV2::InstanceIp`` property ``subnet_uuid``
1983     parameter
1984     ``int_{network-role}_subnet_id``
1985     **MUST NOT** be enumerated in the
1986     VNF's Heat Orchestration Template's Environment File.
1987
1988
1989 .. container:: note
1990
1991     :need:`R-100260`
1992
1993     When
1994
1995       * the VNF's Heat Orchestration Template's
1996         resource ``OS::ContrailV2::InstanceIp`` in an Incremental Module is
1997         attaching
1998         to an internal network (per the ONAP definition,
1999         see Requirements R-52425 and R-46461)
2000         that is created in the Base Module, AND
2001       * an IPv6 address is being cloud assigned by OpenStack's DHCP Service AND
2002       * the internal network IPv6 subnet is to be specified
2003         using the property ``subnet_uuid``,
2004
2005     the parameter **MUST** follow the naming convention
2006     ``int_{network-role}_v6_subnet_id``,
2007     where ``{network-role}`` is the network role of the internal network.
2008
2009     Note that the parameter **MUST** be defined as an ``output`` parameter in
2010     the base module.
2011
2012
2013 .. container:: note
2014
2015     :need:`R-100270`
2016
2017     The VNF's Heat Orchestration Template's Resource
2018     ``OS::ContrailV2::InstanceIp`` property ``subnet_uuid``
2019     parameter
2020     ``int_{network-role}_v6_subnet_id``
2021     **MUST NOT** be enumerated in the
2022     VNF's Heat Orchestration Template's Environment File.
2023
2024
2025 Monitoring & Management > Data Structure Specification of the Event Record
2026 --------------------------------------------------------------------------
2027
2028
2029 Requirements Changed
2030 ~~~~~~~~~~~~~~~~~~~~
2031
2032
2033 .. container:: note
2034
2035     :need:`R-120182`
2036
2037     The VNF or PNF provider **MUST** indicate specific conditions that may arise, and
2038     recommend actions that may be taken at specific thresholds, or if specific
2039     conditions repeat within a specified time interval, using the semantics and
2040     syntax described by the :ref:`VES Event Registration specification <ves_event_registration_3_2>`.
2041
2042
2043 .. container:: note
2044
2045     :need:`R-570134`
2046
2047     The events produced by the VNF or PNF **MUST** must be compliant with the common
2048     event format defined in the
2049     :ref:`VES Event Listener<ves_event_listener_7_1>`
2050     specification.
2051
2052
2053 .. container:: note
2054
2055     :need:`R-520802`
2056
2057     The VNF or PNF provider **MUST** provide a YAML file formatted in adherence with
2058     the :ref:`VES Event Registration specification <ves_event_registration_3_2>`
2059     that defines the following information for each event produced by the VNF:
2060
2061     * ``eventName``
2062     * Required fields
2063     * Optional fields
2064     * Any special handling to be performed for that event
2065
2066
2067 .. container:: note
2068
2069     :need:`R-123044`
2070
2071     The VNF or PNF Provider **MAY** require that specific events, identified by their
2072     ``eventName``, require that certain fields, which are optional in the common
2073     event format, must be present when they are published.
2074
2075
2076 Monitoring & Management > Event Records - Data Structure Description > Common Event Header
2077 ------------------------------------------------------------------------------------------
2078
2079
2080 Requirements Changed
2081 ~~~~~~~~~~~~~~~~~~~~
2082
2083
2084 .. container:: note
2085
2086     :need:`R-528866`
2087
2088     The VNF **MUST** produce VES events that include the following mandatory
2089     fields in the common event header.
2090
2091      * ``domain`` - the event domain enumeration
2092      * ``eventId`` - the event key unique to the event source
2093      * ``eventName`` - the unique event name
2094      * ``lastEpochMicrosec`` - the latest unix time (aka epoch time) associated
2095        with the event
2096      * ``priority`` - the processing priority enumeration
2097      * ``reportingEntityName`` - name of the entity reporting the event or
2098        detecting a problem in another VNF or PNF
2099      * ``sequence`` - the ordering of events communicated by an event source
2100      * ``sourceName`` - name of the entity experiencing the event issue, which
2101        may be detected and reported by a separate reporting entity
2102      * ``startEpochMicrosec`` - the earliest unix time (aka epoch time)
2103        associated with the event
2104      * ``version`` - the version of the event header
2105      * ``vesEventListenerVersion`` - Version of the VES event listener API spec
2106        that this event is compliant with
2107
2108
2109 Monitoring & Management > Monitoring & Management Requirements > Addressing and Delivery Protocol
2110 -------------------------------------------------------------------------------------------------
2111
2112
2113 Requirements Changed
2114 ~~~~~~~~~~~~~~~~~~~~
2115
2116
2117 .. container:: note
2118
2119     :need:`R-84879`
2120
2121     The VNF or PNF **MUST** have the capability of maintaining a primary
2122     and backup DNS name (URL) for connecting to ONAP collectors, with the
2123     ability to switch between addresses based on conditions defined by policy
2124     such as time-outs, and buffering to store messages until they can be
2125     delivered. At its discretion, the service provider may choose to populate
2126     only one collector address for a VNF or PNF. In this case, the network will
2127     promptly resolve connectivity problems caused by a collector or network
2128     failure transparently to the VNF or PNF.
2129
2130
2131 .. container:: note
2132
2133     :need:`R-88482`
2134
2135     The VNF or PNF **SHOULD** use REST using HTTPS delivery of plain
2136     text JSON for moderate sized asynchronous data sets, and for high
2137     volume data sets when feasible.
2138
2139
2140 .. container:: note
2141
2142     :need:`R-81777`
2143
2144     The VNF or PNF **MUST** be configured with initial address(es) to use
2145     at deployment time. Subsequently, address(es) may be changed through
2146     ONAP-defined policies delivered from ONAP to the VNF or PNF using PUTs to a
2147     RESTful API, in the same manner that other controls over data reporting
2148     will be controlled by policy.
2149
2150
2151 .. container:: note
2152
2153     :need:`R-79412`
2154
2155     The VNF or PNF **MAY** use another option which is expected to include TCP
2156     for high volume streaming asynchronous data sets and for other high volume
2157     data sets. TCP delivery can be used for either JSON or binary encoded data
2158     sets.
2159
2160
2161 .. container:: note
2162
2163     :need:`R-01033`
2164
2165     The VNF or PNF **MAY** use another option which is expected to include SFTP
2166     for asynchronous bulk files, such as bulk files that contain large volumes
2167     of data collected over a long time interval or data collected across many
2168     VNFs or PNFs. (Preferred is to reorganize the data into more frequent or more focused
2169     data sets, and deliver these by REST or TCP as appropriate.)
2170
2171
2172 .. container:: note
2173
2174     :need:`R-03070`
2175
2176     The VNF or PNF **MUST**, by ONAP Policy, provide the ONAP addresses
2177     as data destinations for each VNF or PNF, and may be changed by Policy while
2178     the VNF or PNF is in operation. We expect the VNF or PNF to be capable of redirecting
2179     traffic to changed destinations with no loss of data, for example from
2180     one REST URL to another, or from one TCP host and port to another.
2181
2182
2183 .. container:: note
2184
2185     :need:`R-08312`
2186
2187     The VNF or PNF **MAY** use another option which is expected to include REST
2188     delivery of binary encoded data sets.
2189
2190
2191 .. container:: note
2192
2193     :need:`R-63229`
2194
2195     The VNF or PNF **MAY** use another option which is expected to include REST
2196     for synchronous data, using RESTCONF (e.g., for VNF or PNF state polling).
2197
2198
2199 Monitoring & Management > Monitoring & Management Requirements > Asynchronous and Synchronous Data Delivery
2200 -----------------------------------------------------------------------------------------------------------
2201
2202
2203 Requirements Changed
2204 ~~~~~~~~~~~~~~~~~~~~
2205
2206
2207 .. container:: note
2208
2209     :need:`R-73285`
2210
2211     The VNF or PNF **MUST** must encode, address and deliver the data
2212     as described in the previous paragraphs.
2213
2214
2215 .. container:: note
2216
2217     :need:`R-06924`
2218
2219     The VNF or PNF **MUST** deliver asynchronous data as data becomes
2220     available, or according to the configured frequency.
2221
2222
2223 .. container:: note
2224
2225     :need:`R-86586`
2226
2227     The VNF or PNF **MUST** use the YANG configuration models and RESTCONF
2228     [RFC8040] (https://tools.ietf.org/html/rfc8040).
2229
2230
2231 .. container:: note
2232
2233     :need:`R-70266`
2234
2235     The VNF or PNF **MUST** respond to an ONAP request to deliver the
2236     current data for any of the record types defined in
2237     `Event Records - Data Structure Description`_ by returning the requested
2238     record, populated with the current field values. (Currently the defined
2239     record types include fault fields, mobile flow fields, measurements for
2240     VNF or PNF scaling fields, and syslog fields. Other record types will be added
2241     in the future as they become standardized and are made available.)
2242
2243
2244 .. container:: note
2245
2246     :need:`R-34660`
2247
2248     The VNF or PNF **MUST** use the RESTCONF/NETCONF framework used by
2249     the ONAP configuration subsystem for synchronous communication.
2250
2251
2252 .. container:: note
2253
2254     :need:`R-332680`
2255
2256     The VNF or PNF **SHOULD** deliver all syslog messages to the VES Collector per the
2257     specifications in Monitoring and Management chapter.
2258
2259
2260 .. container:: note
2261
2262     :need:`R-46290`
2263
2264     The VNF or PNF **MUST** respond to an ONAP request to deliver granular
2265     data on device or subsystem status or performance, referencing the YANG
2266     configuration model for the VNF or PNF by returning the requested data elements.
2267
2268
2269 .. container:: note
2270
2271     :need:`R-42140`
2272
2273     The VNF or PNF **MUST** respond to data requests from ONAP as soon
2274     as those requests are received, as a synchronous response.
2275
2276
2277 .. container:: note
2278
2279     :need:`R-11240`
2280
2281     The VNF or PNF **MUST** respond with content encoded in JSON, as
2282     described in the RESTCONF specification. This way the encoding of a
2283     synchronous communication will be consistent with Avro.
2284
2285
2286 .. container:: note
2287
2288     :need:`R-43327`
2289
2290     The VNF or PNF **SHOULD** use `Modeling JSON text with YANG
2291     <https://tools.ietf.org/html/rfc7951>`_, If YANG models need to be
2292     translated to and from JSON{RFC7951]. YANG configuration and content can
2293     be represented via JSON, consistent with Avro, as described in "Encoding
2294     and Serialization" section.
2295
2296
2297 Monitoring & Management > Monitoring & Management Requirements > Bulk Performance Measurement
2298 ---------------------------------------------------------------------------------------------
2299
2300
2301 Requirements Added
2302 ~~~~~~~~~~~~~~~~~~
2303
2304
2305 .. container:: note
2306
2307     :need:`R-807129`
2308
2309     The VNF or PNF **SHOULD** report the files in FileReady for as long as they are
2310     available at VNF or PNF.
2311
2312     Note: Recommended period is at least 24 hours.
2313
2314
2315 Requirements Changed
2316 ~~~~~~~~~~~~~~~~~~~~
2317
2318
2319 .. container:: note
2320
2321     :need:`R-841740`
2322
2323     The VNF or PNF **SHOULD** support FileReady VES event for event-driven bulk transfer
2324     of monitoring data.
2325
2326
2327 .. container:: note
2328
2329     :need:`R-440220`
2330
2331     The VNF or PNF **SHOULD** support File transferring protocol, such as FTPES or SFTP,
2332     when supporting the event-driven bulk transfer of monitoring data.
2333
2334
2335 .. container:: note
2336
2337     :need:`R-75943`
2338
2339     The VNF or PNF **SHOULD** support the data schema defined in 3GPP TS 32.435, when
2340     supporting the event-driven bulk transfer of monitoring data.
2341
2342
2343 Monitoring & Management > Monitoring & Management Requirements > Google Protocol Buffers (GPB)
2344 ----------------------------------------------------------------------------------------------
2345
2346
2347 Requirements Changed
2348 ~~~~~~~~~~~~~~~~~~~~
2349
2350
2351 .. container:: note
2352
2353     :need:`R-257367`
2354
2355     The VNF or PNF, when leveraging Google Protocol Buffers for events, **MUST**
2356     serialize the events using native Google Protocol Buffers (GPB) according
2357     to the following guidelines:
2358
2359        * The keys are represented as integers pointing to the system resources
2360          for the VNF or PNF being monitored
2361        * The values correspond to integers or strings that identify the
2362          operational state of the VNF resource, such a statistics counters and
2363          the state of an VNF or PNF resource.
2364        * The required Google Protocol Buffers (GPB) metadata is provided in the
2365          form of .proto files.
2366
2367
2368 .. container:: note
2369
2370     :need:`R-978752`
2371
2372     The VNF or PNF providers **MUST** provide the Service Provider the following
2373     artifacts to support the delivery of high-volume VNF or PNF telemetry to
2374     DCAE via GPB over TLS/TCP:
2375
2376        * A valid VES Event .proto definition file, to be used validate and
2377          decode an event
2378        * A valid high volume measurement .proto definition file, to be used for
2379          processing high volume events
2380        * A supporting PM content metadata file to be used by analytics
2381          applications to process high volume measurement events
2382
2383
2384 Monitoring & Management > Monitoring & Management Requirements > JSON
2385 ---------------------------------------------------------------------
2386
2387
2388 Requirements Changed
2389 ~~~~~~~~~~~~~~~~~~~~
2390
2391
2392 .. container:: note
2393
2394     :need:`R-19624`
2395
2396     The VNF or PNF, when leveraging JSON for events, **MUST** encode and serialize
2397     content delivered to ONAP using JSON (RFC 7159) plain text format.
2398     High-volume data is to be encoded and serialized using
2399     `Avro <http://avro.apache.org/>`_, where the Avro data
2400     format are described using JSON.
2401
2402
2403 Monitoring & Management > Monitoring & Management Requirements > Reporting Frequency
2404 ------------------------------------------------------------------------------------
2405
2406
2407 Requirements Changed
2408 ~~~~~~~~~~~~~~~~~~~~
2409
2410
2411 .. container:: note
2412
2413     :need:`R-98191`
2414
2415     The VNF or PNF **MUST** vary the frequency that asynchronous data
2416     is delivered based on the content and how data may be aggregated or
2417     grouped together.
2418
2419         Note:
2420
2421         - For example, alarms and alerts are expected to be delivered as
2422           soon as they appear. In contrast, other content, such as performance
2423           measurements, KPIs or reported network signaling may have various
2424           ways of packaging and delivering content. Some content should be
2425           streamed immediately; or content may be monitored over a time
2426           interval, then packaged as collection of records and delivered
2427           as block; or data may be collected until a package of a certain
2428           size has been collected; or content may be summarized statistically
2429           over a time interval, or computed as a KPI, with the summary or KPI
2430           being delivered.
2431         - We expect the reporting frequency to be configurable depending on
2432           the virtual network functions needs for management. For example,
2433           Service Provider may choose to vary the frequency of collection
2434           between normal and trouble-shooting scenarios.
2435         - Decisions about the frequency of data reporting will affect
2436           the size of delivered data sets, recommended delivery method,
2437           and how the data will be interpreted by ONAP. These considerations
2438           should not affect deserialization and decoding of the data, which
2439           will be guided by the accompanying JSON schema or GPB definition
2440           files.
2441
2442
2443 .. container:: note
2444
2445     :need:`R-146931`
2446
2447     The VNF or PNF **MUST** report exactly one Measurement event per period
2448     per source name.
2449
2450
2451 Monitoring & Management > Monitoring & Management Requirements > Security
2452 -------------------------------------------------------------------------
2453
2454
2455 Requirements Changed
2456 ~~~~~~~~~~~~~~~~~~~~
2457
2458
2459 .. container:: note
2460
2461     :need:`R-42366`
2462
2463     The VNF or PNF **MUST** support secure connections and transports such as
2464     Transport Layer Security (TLS) protocol
2465     [`RFC5246 <https://tools.ietf.org/html/rfc5246>`_] and should adhere to
2466     the best current practices outlined in
2467     `RFC7525 <https://tools.ietf.org/html/rfc7525>`_.
2468
2469
2470 .. container:: note
2471
2472     :need:`R-44290`
2473
2474     The VNF or PNF **MUST** control access to ONAP and to VNFs or PNFs, and creation
2475     of connections, through secure credentials, log-on and exchange mechanisms.
2476
2477
2478 .. container:: note
2479
2480     :need:`R-894004`
2481
2482     When the VNF or PNF sets up a HTTP or HTTPS connection to the collector, it **MUST**
2483     provide a username and password to the DCAE VES Collector for HTTP Basic
2484     Authentication.
2485
2486     Note: HTTP Basic Authentication has 4 steps: Request, Authenticate,
2487     Authorization with Username/Password Credentials, and Authentication Status
2488     as per RFC7617 and RFC 2617.
2489
2490
2491 .. container:: note
2492
2493     :need:`R-01427`
2494
2495     The VNF or PNF **MUST** support the provisioning of security and authentication
2496     parameters (HTTP username and password) in order to be able to authenticate
2497     with DCAE (in ONAP).
2498
2499     Note: In R3, a username and password are used with the DCAE VES Event
2500     Listener which are used for HTTP Basic Authentication.
2501
2502     Note: The configuration management and provisioning software are specific
2503     to a vendor architecture.
2504
2505
2506 .. container:: note
2507
2508     :need:`R-68165`
2509
2510     The VNF or PNF **MUST** encrypt any content containing Sensitive Personal
2511     Information (SPI) or certain proprietary data, in addition to applying the
2512     regular procedures for securing access and delivery.
2513
2514
2515 .. container:: note
2516
2517     :need:`R-47597`
2518
2519     The VNF or PNF **MUST** carry data in motion only over secure connections.
2520
2521
2522 Monitoring & Management > Monitoring & Management Requirements > VNF telemetry via standardized interface
2523 ---------------------------------------------------------------------------------------------------------
2524
2525
2526 Requirements Changed
2527 ~~~~~~~~~~~~~~~~~~~~
2528
2529
2530 .. container:: note
2531
2532     :need:`R-821473`
2533
2534     The VNF or PNF MUST produce heartbeat indicators consisting of events containing
2535     the common event header only per the VES Listener Specification.
2536
2537
2538 Monitoring & Management > Transports and Protocols Supporting Resource Interfaces
2539 ---------------------------------------------------------------------------------
2540
2541
2542 Requirements Changed
2543 ~~~~~~~~~~~~~~~~~~~~
2544
2545
2546 .. container:: note
2547
2548     :need:`R-821839`
2549
2550     The VNF or PNF **MUST** deliver event records to ONAP using the common
2551     transport mechanisms and protocols defined in this specification.
2552
2553
2554 .. container:: note
2555
2556     :need:`R-798933`
2557
2558     The VNF or PNF **SHOULD** deliver event records that fall into the event domains
2559     supported by VES.
2560
2561
2562 .. container:: note
2563
2564     :need:`R-932071`
2565
2566     The VNF or PNF provider **MUST** reach agreement with the Service Provider on
2567     the selected methods for encoding, serialization and data delivery
2568     prior to the on-boarding of the VNF or PNF into ONAP SDC Design Studio.
2569
2570
2571 Monitoring & Management > Transports and Protocols Supporting Resource Interfaces > Bulk Telemetry Transmission
2572 ---------------------------------------------------------------------------------------------------------------
2573
2574
2575 Requirements Changed
2576 ~~~~~~~~~~~~~~~~~~~~
2577
2578
2579 .. container:: note
2580
2581     :need:`R-908291`
2582
2583     The VNF or PNF **MAY** leverage bulk VNF or PNF telemetry transmission mechanism, as
2584     depicted in Figure 4, in instances where other transmission methods are not
2585     practical or advisable.
2586
2587
2588 Monitoring & Management > Transports and Protocols Supporting Resource Interfaces > VNF or PNF Telemetry using Google Protocol Buffers
2589 --------------------------------------------------------------------------------------------------------------------------------------
2590
2591
2592 Requirements Changed
2593 ~~~~~~~~~~~~~~~~~~~~
2594
2595
2596 .. container:: note
2597
2598     :need:`R-697654`
2599
2600     The VNF or PNF **MAY** leverage the Google Protocol Buffers (GPB) delivery model
2601     depicted in Figure 3 to support real-time performance management (PM) data.
2602     In this model the VES events are streamed as binary-encoded GBPs over via
2603     TCP sockets.
2604
2605
2606 Monitoring & Management > Transports and Protocols Supporting Resource Interfaces > VNF or PNF Telemetry using VES/JSON Model
2607 -----------------------------------------------------------------------------------------------------------------------------
2608
2609
2610 Requirements Changed
2611 ~~~~~~~~~~~~~~~~~~~~
2612
2613
2614 .. container:: note
2615
2616     :need:`R-659655`
2617
2618     The VNF or PNF **SHOULD** leverage the JSON-driven model, as depicted in Figure 2,
2619     for data delivery unless there are specific performance or operational
2620     concerns agreed upon by the Service Provider that would warrant using an
2621     alternate model.
2622
2623
2624 ONAP Heat Heat Template Constructs > Heat Files Support (get_file)
2625 ------------------------------------------------------------------
2626
2627
2628 Requirements Removed
2629 ~~~~~~~~~~~~~~~~~~~~
2630
2631
2632 .. container:: note
2633
2634     R-87848
2635
2636     When using the intrinsic function get_file, ONAP does not support
2637     a directory hierarchy for included files. All files must be in a
2638     single, flat directory per VNF. A VNF's Heat Orchestration
2639     Template's ``get_file`` target files **MUST** be in the same
2640     directory hierarchy as the VNF's Heat Orchestration Templates.
2641
2642
2643 ONAP Heat Heat Template Constructs > Key Pairs
2644 ----------------------------------------------
2645
2646
2647 Requirements Added
2648 ~~~~~~~~~~~~~~~~~~
2649
2650
2651 .. container:: note
2652
2653     :need:`R-100380`
2654
2655     If a VNF requires the use of an SSH key created by OpenStack, the VNF
2656     Heat Orchestration Template **SHOULD** create the ``OS::Nova::Keypair``
2657     in the base module, and expose the public key as an output value.
2658
2659     This allows re-use of the key by ONAP when triggering scale out, recovery,
2660     or other day 1 operations.
2661
2662
2663 ONAP Heat Heat Template Constructs > Nested Heat Templates > Nested Heat Template Requirements
2664 ----------------------------------------------------------------------------------------------
2665
2666
2667 Requirements Added
2668 ~~~~~~~~~~~~~~~~~~
2669
2670
2671 .. container:: note
2672
2673     :need:`R-708564`
2674
2675     If a VNF's Heat Orchestration Template's resource invokes a nested
2676     YAML file, either statically or dynamically
2677     (via ``OS::Heat::ResourceGroup``),
2678     the names of the parameters associated with the following resource
2679     properties **MUST NOT** change.
2680
2681     * ``OS::Nova::Server`` property ``flavor``
2682     * ``OS::Nova::Server`` property ``image``
2683     * ``OS::Nova::Server`` property ``name``
2684     * ``OS::Nova::Server`` property metadata key value ``vnf_id``
2685     * ``OS::Nova::Server`` property metadata key value ``vf_module_id``
2686     * ``OS::Nova::Server`` property metadata key value ``vnf_name``
2687     * ``OS::Nova::Server`` property metadata key value ``vf_module_name``
2688     * ``OS::Nova::Server`` property metadata key value ``vm_role``
2689     * ``OS::Nova::Server`` property metadata key value ``vf_module_index``
2690     * ``OS::Nova::Server`` property metadata key value ``workload_context``
2691     * ``OS::Nova::Server`` property metadata key value ``environment_context``
2692     * ``OS::Neutron::Port`` property ``fixed_ips``, map property ``ip_address``
2693     * ``OS::Neutron::Port`` property ``fixed_ips``, map property ``subnet``
2694     * ``OS::Neutron::Port`` property ``allowed_address_pairs``, map property
2695       ``ip_address``
2696     * ``OS::Neutron::Port`` property ``network``
2697     * ``OS::ContrailV2::VirtualMachineInterface`` property
2698       ``virtual_network_refs``
2699     * ``OS::ContrailV2::VirtualMachineInterface`` property
2700       ``virtual_machine_interface_allowed_address_pairs``, map property
2701       ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair``,
2702       ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip``
2703       ,
2704       ``virtual_machine_interface_allowed_address_pairs_allowed_address_pair_ip_ip_prefix``
2705     * ``OS::ContrailV2::InstanceIP`` property ``instance_ip_address``
2706     * ``OS::ContrailV2::InstanceIP`` property ``subnet_uuid``
2707
2708
2709 Requirements Removed
2710 ~~~~~~~~~~~~~~~~~~~~
2711
2712
2713 .. container:: note
2714
2715     R-52530
2716
2717     A VNF's Heat Orchestration Template's Nested YAML file
2718     **MUST** be in the same directory hierarchy as the VNF's Heat
2719     Orchestration Templates.
2720
2721
2722 .. container:: note
2723
2724     R-70112
2725
2726     A VNF's Heat Orchestration Template **MUST** reference a Nested YAML
2727     file by name. The use of ``resource_registry`` in the VNF's Heat
2728     Orchestration Templates Environment File **MUST NOT** be used.
2729
2730
2731 ONAP Heat Networking > External Networks
2732 ----------------------------------------
2733
2734
2735 Requirements Removed
2736 ~~~~~~~~~~~~~~~~~~~~
2737
2738
2739 .. container:: note
2740
2741     R-83015
2742
2743     A VNF's ``{network-role}`` assigned to an external network **MUST**
2744     be different than the ``{network-role}`` assigned to the VNF's
2745     internal networks, if internal networks exist.
2746
2747
2748 ONAP Heat Networking > Internal Networks
2749 ----------------------------------------
2750
2751
2752 Requirements Changed
2753 ~~~~~~~~~~~~~~~~~~~~
2754
2755
2756 .. container:: note
2757
2758     :need:`R-35666`
2759
2760     If a VNF has an internal network, the VNF Heat Orchestration Template
2761     **MUST** include the heat resources to create the internal network.
2762
2763     A VNF's Internal Network is created using Neutron Heat Resources
2764     (i.e., ``OS::Neutron::Net``, ``OS::Neutron::Subnet``) and/or
2765     Contrail Heat Resources (i.e., ``OS::ContrailV2::VirtualNetwork``,
2766     ``ContrailV2::NetworkIpam``).
2767
2768
2769 .. container:: note
2770
2771     :need:`R-22688`
2772
2773     When a VNF's Heat Orchestration Template creates an internal network
2774     (per the ONAP definition, see Requirements R-52425 and R-46461
2775     and R-35666) and the internal network needs to be shared between modules
2776     within a VNF,  the internal network **MUST** be created either in the
2777
2778     * the base module
2779     * a nested YAML file invoked by the base module
2780
2781     and the base module **MUST** contain an output parameter that provides
2782     either the network UUID or network name.
2783
2784     * If the network UUID value is used to reference the network, the output
2785       parameter name in the base module **MUST** follow the naming convention
2786       ``int_{network-role}_net_id``
2787     * If the network name in is used to reference the network, the output
2788       parameter name in the base template **MUST** follow the naming convention
2789       ``int_{network-role}_net_name``
2790
2791     ``{network-role}`` **MUST** be the network-role of the internal network
2792     created in the Base Module.
2793
2794     The Base Module Output Parameter MUST be declared in the ``parameters:``
2795     section of the Incremental Module(s) where the ``OS::Neutron::Port``
2796     resource(s) is attaching to the internal network.
2797
2798
2799 Requirements Removed
2800 ~~~~~~~~~~~~~~~~~~~~
2801
2802
2803 .. container:: note
2804
2805     R-32025
2806
2807     When a VNF creates two or more internal networks, each internal
2808     network **MUST** be assigned a unique ``{network-role}`` in the context
2809     of the VNF for use in the VNF's Heat Orchestration Template.
2810
2811
2812 .. container:: note
2813
2814     R-68936
2815
2816     When a VNF creates an internal network, a network role, referred to as
2817     the ``{network-role}`` **MUST** be assigned to the internal network
2818     for use in the VNF's Heat Orchestration Template.
2819
2820
2821 .. container:: note
2822
2823     R-69874
2824
2825     A VNF's ``{network-role}`` assigned to an internal network **MUST**
2826     be different than the ``{network-role}`` assigned to the VNF's external
2827     networks.
2828
2829
2830 ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > parameters > constraints
2831 ----------------------------------------------------------------------------------------------------------
2832
2833
2834 Requirements Changed
2835 ~~~~~~~~~~~~~~~~~~~~
2836
2837
2838 .. container:: note
2839
2840     :need:`R-00011`
2841
2842     A VNF's Heat Orchestration Template's parameter defined
2843     in a nested YAML file
2844     **SHOULD NOT** have a parameter constraint defined.
2845
2846
2847 .. container:: note
2848
2849     :need:`R-88863`
2850
2851     A VNF's Heat Orchestration Template's parameter defined
2852     in a non-nested YAML file as type
2853     ``number`` **MAY** have a parameter constraint defined.
2854
2855
2856 ONAP Heat Orchestration Template Format > Heat Orchestration Template Structure > resources > properties
2857 --------------------------------------------------------------------------------------------------------
2858
2859
2860 Requirements Changed
2861 ~~~~~~~~~~~~~~~~~~~~
2862
2863
2864 .. container:: note
2865
2866     :need:`R-10834`
2867
2868     A VNF's Heat Orchestration Template resource attribute ``property:``
2869     **MUST NOT** use more than two levels of nested ``get_param`` intrinsic
2870     functions when deriving a property value.  SDC does not support nested
2871     ``get_param`` with recursive lists (i.e., a list inside list).
2872     The second ``get_param`` in a nested lookup must directly derive its value
2873     without further calls to ``get_param`` functions.
2874
2875     * Example of valid nesting:
2876
2877       * ``name: {get_param: [ {vm-type}_names, {get_param : index } ] }``
2878
2879     * Examples of invalid nesting.  SDC will not support these examples since
2880       there is an array inside array.
2881
2882       * ``name: {get_param: [ {vm-type}_names, { get_param: [ indexlist, 0 ] } ] }``
2883       * ``name: {get_param: [ {vm-type}_names, { get_param: [ indexlist1, { get_param: indexlist2 } ] } ] }``
2884
2885
2886 ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Base Modules
2887 ------------------------------------------------------------------------------------------------------
2888
2889
2890 Requirements Changed
2891 ~~~~~~~~~~~~~~~~~~~~
2892
2893
2894 .. container:: note
2895
2896     :need:`R-81339`
2897
2898     A VNF Heat Orchestration Template's Base Module file name **MUST** include
2899     case insensitive 'base' in the filename and
2900     **MUST** match one of the following four
2901     formats:
2902
2903      1.) ``base_<text>.y[a]ml``
2904
2905      2.) ``<text>_base.y[a]ml``
2906
2907      3.) ``base.y[a]ml``
2908
2909      4.) ``<text>_base_<text>``.y[a]ml
2910
2911     where ``<text>`` **MUST** contain only alphanumeric characters and
2912     underscores '_' and **MUST NOT** contain the case insensitive string
2913     ``base`` or ``volume``.
2914
2915
2916 ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Cinder Volume Modules
2917 ---------------------------------------------------------------------------------------------------------------
2918
2919
2920 Requirements Added
2921 ~~~~~~~~~~~~~~~~~~
2922
2923
2924 .. container:: note
2925
2926     :need:`R-589037`
2927
2928     A VNF Heat Orchestration Template's Cinder Volume Module ``resources:``
2929     section
2930     **MUST** only be defined using one of the following:
2931
2932     * one of more ``OS::Cinder::Volume`` resources
2933     * one or more ``OS::Heat::ResourceGroup`` resources that call a nested YAML
2934       file that contains only ``OS::Cinder::Volume`` resources
2935     * a resource that calls a nested YAML file (static nesting) that contains
2936       only ``OS::Cinder::Volume`` resources
2937
2938
2939 ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Incremental Modules
2940 -------------------------------------------------------------------------------------------------------------
2941
2942
2943 Requirements Changed
2944 ~~~~~~~~~~~~~~~~~~~~
2945
2946
2947 .. container:: note
2948
2949     :need:`R-87247`
2950
2951     VNF Heat Orchestration Template's Incremental Module file name
2952     **MUST** contain only alphanumeric characters and underscores
2953     '_' and **MUST NOT** contain the case insensitive string ``base``.
2954
2955
2956 ONAP Heat Orchestration Templates Overview > ONAP Heat Orchestration Template Filenames > Nested Heat file
2957 ----------------------------------------------------------------------------------------------------------
2958
2959
2960 Requirements Changed
2961 ~~~~~~~~~~~~~~~~~~~~
2962
2963
2964 .. container:: note
2965
2966     :need:`R-76057`
2967
2968     VNF Heat Orchestration Template's Nested YAML file name **MUST** contain
2969     only alphanumeric characters and underscores '_' and
2970     **MUST NOT** contain the case insensitive string ``base``.
2971
2972
2973 ONAP Heat Orchestration Templates Overview > ONAP VNF Modularity Overview
2974 -------------------------------------------------------------------------
2975
2976
2977 Requirements Changed
2978 ~~~~~~~~~~~~~~~~~~~~
2979
2980
2981 .. container:: note
2982
2983     :need:`R-90748`
2984
2985     A VNF's Heat Orchestration Template's Resource ``OS::Cinder::Volume``
2986     **MAY** be defined in an Incremental Module.
2987
2988
2989 .. container:: note
2990
2991     :need:`R-03251`
2992
2993     A VNF's Heat Orchestration Template's Resource ``OS::Cinder::Volume``
2994     **MAY** be defined in a Cinder Volume Module.
2995
2996
2997 .. container:: note
2998
2999     :need:`R-46119`
3000
3001     A VNF's Heat Orchestration Template's Resource ``OS::Cinder::Volume``
3002     **MAY** be defined in a Base Module.
3003
3004
3005 Requirements Removed
3006 ~~~~~~~~~~~~~~~~~~~~
3007
3008
3009 .. container:: note
3010
3011     R-20974
3012
3013     At orchestration time, the VNF's Base Module **MUST**
3014     be deployed first, prior to any incremental modules.
3015
3016
3017 ONAP Heat Orchestration Templates Overview > ONAP VNF On-Boarding
3018 -----------------------------------------------------------------
3019
3020
3021 Requirements Added
3022 ~~~~~~~~~~~~~~~~~~
3023
3024
3025 .. container:: note
3026
3027     :need:`R-348813`
3028
3029     The VNF's Heat Orchestration Template's ZIP file **MUST NOT** include
3030     a binary image file.
3031
3032
3033 .. container:: note
3034
3035     :need:`R-511776`
3036
3037     When a VNF's Heat Orchestration Template is ready
3038     to be on-boarded to ONAP,
3039     all files composing the VNF Heat Orchestration Template
3040     **MUST** be placed in a flat (i.e., non-hierarchical) directory and
3041     archived using ZIP.  The resulting ZIP file is uploaded into ONAP.
3042
3043
3044 ONAP Heat Orchestration Templates Overview > Output Parameters > ONAP Base Module Output Parameters
3045 ---------------------------------------------------------------------------------------------------
3046
3047
3048 Requirements Changed
3049 ~~~~~~~~~~~~~~~~~~~~
3050
3051
3052 .. container:: note
3053
3054     :need:`R-52753`
3055
3056     VNF's Heat Orchestration Template's Base Module's output parameter's
3057     name and type **MUST** match the VNF's Heat Orchestration Template's
3058     incremental Module's name and type.
3059
3060
3061 .. container:: note
3062
3063     :need:`R-22608`
3064
3065     When a VNF's Heat Orchestration Template's Base Module's output
3066     parameter is declared as an input parameter in an Incremental Module,
3067     the parameter attribute ``constraints:`` **SHOULD NOT** be declared.
3068
3069
3070 ONAP Heat Orchestration Templates Overview > Output Parameters > ONAP Volume Module Output Parameters
3071 -----------------------------------------------------------------------------------------------------
3072
3073
3074 Requirements Changed
3075 ~~~~~~~~~~~~~~~~~~~~
3076
3077
3078 .. container:: note
3079
3080     :need:`R-20547`
3081
3082     When an ONAP Volume Module Output Parameter is declared as an input
3083     parameter in a base or an incremental module Heat Orchestration
3084     Template, parameter constraints **SHOULD NOT** be declared.
3085
3086
3087 .. container:: note
3088
3089     :need:`R-07443`
3090
3091     A VNF's Heat Orchestration Templates' Cinder Volume Module Output
3092     Parameter's name and type **MUST** match the input parameter name and type
3093     in the corresponding Base Module or Incremental Module.
3094
3095
3096 .. container:: note
3097
3098     :need:`R-89913`
3099
3100     A VNF's Heat Orchestration Template's Cinder Volume Module Output
3101     Parameter(s)
3102     **MUST** include the
3103     UUID(s) of the Cinder Volumes created in template.
3104
3105
3106 ONAP Heat Support of Environment Files
3107 --------------------------------------
3108
3109
3110 Requirements Added
3111 ~~~~~~~~~~~~~~~~~~
3112
3113
3114 .. container:: note
3115
3116     :need:`R-599443`
3117
3118     A parameter enumerated in a
3119     VNF's Heat Orchestration Template's environment file **MUST** be declared
3120     in the
3121     corresponding VNF's Heat Orchestration Template's YAML file's
3122     ``parameters:`` section.
3123
3124
3125 ONAP Heat VNF Modularity
3126 ------------------------
3127
3128
3129 Requirements Changed
3130 ~~~~~~~~~~~~~~~~~~~~
3131
3132
3133 .. container:: note
3134
3135     :need:`R-61001`
3136
3137     A shared Heat Orchestration Template resource is a resource that **MUST**
3138     be defined in the base module and will be referenced by one or
3139     more resources in one or more incremental modules.
3140
3141     The UUID of the shared resource (created in the base module) **MUST** be
3142     exposed by declaring a parameter in the
3143     ``outputs`` section of the base module.
3144
3145     For ONAP to provided the UUID value of the shared resource to the
3146     incremental module, the parameter name defined in the ``outputs``
3147     section of the base module **MUST** be defined as a parameter
3148     in the ``parameters`` section of the incremental module.
3149
3150     ONAP will capture the output parameter name and value in the base module
3151     and provide the value to the corresponding parameter(s) in the
3152     incremental module(s).
3153
3154
3155 ONAP TOSCA VNFD Requirements > VNF CSAR Package > VNF Package Contents
3156 ----------------------------------------------------------------------
3157
3158
3159 Requirements Removed
3160 ~~~~~~~~~~~~~~~~~~~~
3161
3162
3163 .. container:: note
3164
3165     R-26885
3166
3167     The VNF provider **MUST** provide the binaries and images needed to
3168     instantiate the VNF (VNF and VNFC images) either as:
3169
3170       - Local artifact in CSAR: ROOT\\Artifacts\\ **VNF_Image.bin**
3171
3172       - externally referred (by URI) artifact in Manifest file (also may be
3173         referred by VNF Descriptor)
3174
3175     Note: Currently, ONAP doesn't have the capability of Image management,
3176     we upload the image into VIM/VNFM manually.
3177
3178
3179 ONAP TOSCA VNFD or PNFD Requirements > TOSCA PNF Descriptor > Capability Types
3180 ------------------------------------------------------------------------------
3181
3182
3183 Requirements Added
3184 ~~~~~~~~~~~~~~~~~~
3185
3186
3187 .. container:: note
3188
3189     :need:`R-177937`
3190
3191     The PNFD provided by a PNF vendor **MUST** comply with the following
3192     Capabilities Types as specified in ETSI NFV-SOL001 standard:
3193
3194       - tosca.datatypes.nfv.VirtualLinkable
3195
3196
3197 ONAP TOSCA VNFD or PNFD Requirements > TOSCA PNF Descriptor > Data Types
3198 ------------------------------------------------------------------------
3199
3200
3201 Requirements Added
3202 ~~~~~~~~~~~~~~~~~~
3203
3204
3205 .. container:: note
3206
3207     :need:`R-484843`
3208
3209     The PNFD provided by a PNF vendor **MUST** comply with the following Data
3210     Types as specified in ETSI NFV-SOL001 standard:
3211
3212       - tosca.datatypes.nfv.CpProtocolData
3213
3214       - tosca.datatypes.nfv.AddressData
3215
3216       - tosca.datatypes.nfv.L2AddressData
3217
3218       - tosca.datatypes.nfv.L3AddressData
3219
3220       - tosca.datatypes.nfv.LocationInfo
3221
3222       - tosca.datatypes.nfv.CivicAddressElement
3223
3224
3225 ONAP TOSCA VNFD or PNFD Requirements > TOSCA PNF Descriptor > General
3226 ---------------------------------------------------------------------
3227
3228
3229 Requirements Added
3230 ~~~~~~~~~~~~~~~~~~
3231
3232
3233 .. container:: note
3234
3235     :need:`R-24632`
3236
3237     The PNF Descriptor (PNFD) provided by PNF vendor **MUST** comply with
3238     TOSCA/YAML based Service template for PNF descriptor specified in ETSI
3239     NFV-SOL001.
3240
3241
3242 ONAP TOSCA VNFD or PNFD Requirements > TOSCA PNF Descriptor > Node Types
3243 ------------------------------------------------------------------------
3244
3245
3246 Requirements Added
3247 ~~~~~~~~~~~~~~~~~~
3248
3249
3250 .. container:: note
3251
3252     :need:`R-535009`
3253
3254     The PNFD provided by a PNF vendor **MUST** comply with the following Node
3255     Types as specified in ETSI NFV-SOL001 standard:
3256
3257       - tosca.nodes.nfv.PNF
3258
3259       - tosca.nodes.nfv.PnfExtCp
3260
3261       - tosca.nodes.nfv.Cp
3262
3263
3264 ONAP TOSCA VNFD or PNFD Requirements > TOSCA PNF Descriptor > Policy Types
3265 --------------------------------------------------------------------------
3266
3267
3268 Requirements Added
3269 ~~~~~~~~~~~~~~~~~~
3270
3271
3272 .. container:: note
3273
3274     :need:`R-596064`
3275
3276     The PNFD provided by a PNF vendor **MUST** comply with the following Policy
3277     Types as specified in ETSI NFV-SOL001 standard:
3278
3279       - tosca.datatypes.nfv.SecurityGroupRule
3280
3281
3282 ONAP TOSCA VNFD or PNFD Requirements > TOSCA PNF Descriptor > Relationship Types
3283 --------------------------------------------------------------------------------
3284
3285
3286 Requirements Added
3287 ~~~~~~~~~~~~~~~~~~
3288
3289
3290 .. container:: note
3291
3292     :need:`R-64064`
3293
3294     The PNFD provided by a PNF vendor **MUST** comply with the following
3295     Relationship Types as specified in ETSI NFV-SOL001 standard:
3296
3297       - tosca.datatypes.nfv.VirtualLinksTo
3298
3299
3300 ONAP TOSCA VNFD or PNFD Requirements > TOSCA VNF Descriptor > General
3301 ---------------------------------------------------------------------
3302
3303
3304 Requirements Changed
3305 ~~~~~~~~~~~~~~~~~~~~
3306
3307
3308 .. container:: note
3309
3310     :need:`R-65486`
3311
3312     The VNFD **MUST** comply with ETSI GS NFV-SOL001 specification endorsing
3313     the above mentioned NFV Profile and maintaining the gaps with the
3314     requirements specified in ETSI GS NFV-IFA011 standard.
3315
3316
3317 ONAP TOSCA VNFD or PNFD Requirements > VNF or PNF CSAR Package > VNF Package Contents
3318 -------------------------------------------------------------------------------------
3319
3320
3321 Requirements Added
3322 ~~~~~~~~~~~~~~~~~~
3323
3324
3325 .. container:: note
3326
3327     :need:`R-146092`
3328
3329     If one or more non-MANO artifact(s) is included in the VNF or PNF TOSCA CSAR
3330     package, the Manifest file in this CSAR package **MUST** contain: non-MANO
3331     artifact set which MAY contain following ONAP public tag.
3332
3333       - onap_ves_events: contains VES registration files
3334
3335       - onap_pm_dictionary: contains the PM dictionary files
3336
3337       - onap_yang_modules: contains Yang module files for configurations
3338
3339       - onap_ansible_playbooks: contains any ansible_playbooks
3340
3341       - onap_others: contains any other non_MANO artifacts, e.g. informational
3342         documents
3343
3344
3345 .. container:: note
3346
3347     :need:`R-221914`
3348
3349     The VNF or PNF package **MUST** contain a a human-readable change log text
3350     file. The Change Log file keeps a history describing any changes in the VNF
3351     or PNF package. The Change Log file is kept up to date continuously from
3352     the creation of the CSAR package.
3353
3354
3355 .. container:: note
3356
3357     :need:`R-293901`
3358
3359     The VNF or PNF CSAR PACKAGE with TOSCA-Metadata **MUST** include following
3360     additional keywords pointing to TOSCA files:
3361
3362       - ETSI-Entry-Manifest
3363
3364       - ETSI-Entry-Change-Log
3365
3366     Note: For a CSAR containing a TOSCA-Metadata directory, which includes
3367     the TOSCA.meta metadata file. The TOSCA.meta metadata file includes block_0
3368     with the Entry-Definitions keyword pointing to a TOSCA definitions YAML
3369     file used as entry for parsing the contents of the overall CSAR archive.
3370
3371
3372 .. container:: note
3373
3374     :need:`R-57019`
3375
3376     The PNF TOSCA CSAR PACKAGE Manifest file **MUST** start with the PNF
3377     package metadata in the form of a name-value pairs. Each pair shall appear
3378     on a different line. The name is specified as following:
3379
3380       - pnfd_provider
3381
3382       - pnfd_name
3383
3384       - pnfd_release_date_time
3385
3386       - pnfd_archive_version
3387
3388
3389 .. container:: note
3390
3391     :need:`R-795126`
3392
3393     The VNF TOSCA CSAR package Manifest file **MUST** start with the VNF
3394     package metadata in the form of a name-value pairs. Each pair shall appear
3395     on a different line. The name is specified as following:
3396
3397       - vnf_provider_id
3398
3399       - vnf_product_name
3400
3401       - vnf_release_date_time
3402
3403       - vnf_package_version
3404
3405
3406 Requirements Changed
3407 ~~~~~~~~~~~~~~~~~~~~
3408
3409
3410 .. container:: note
3411
3412     :need:`R-10087`
3413
3414     The VNF or PNF CSAR package **MUST** include all artifacts required by
3415     ETSI GS NFV-SOL004 including Manifest file, VNFD or PNFD (or Main
3416     TOSCA/YAML based Service Template) and other optional artifacts.
3417
3418
3419 .. container:: note
3420
3421     :need:`R-40820`
3422
3423     The VNF or PNF TOSCA PACKAGE **MUST** enumerate all of the open source
3424     licenses their VNF(s) incorporate. CSAR License directory as per ETSI
3425     SOL004.
3426
3427     for example ROOT\\Licenses\\ **License_term.txt**
3428
3429
3430 .. container:: note
3431
3432     :need:`R-01123`
3433
3434     The VNF or PNF package Manifest file **MUST** contain: VNF or PNF package
3435     meta-data, a list of all artifacts (both internal and external) entry's
3436     including their respected URI's, an algorithm to calculate a digest and
3437     a digest result calculated on the content of each artifacts, as specified
3438     in ETSI GS NFV-SOL004.
3439
3440
3441 ONAP TOSCA VNFD or PNFD Requirements > VNF or PNF CSAR Package > VNF Package Structure and Format
3442 -------------------------------------------------------------------------------------------------
3443
3444
3445 Requirements Added
3446 ~~~~~~~~~~~~~~~~~~
3447
3448
3449 .. container:: note
3450
3451     :need:`R-506221`
3452
3453     The VNF or PNF TOSCA CSAR file **MUST** be a zip file with .csar extension.
3454
3455
3456 Requirements Changed
3457 ~~~~~~~~~~~~~~~~~~~~
3458
3459
3460 .. container:: note
3461
3462     :need:`R-51347`
3463
3464     The VNF or PNF CSAR package **MUST** be arranged as a CSAR archive as
3465     specified in TOSCA Simple Profile in YAML 1.2.
3466
3467
3468 .. container:: note
3469
3470     :need:`R-87234`
3471
3472     The VNF or PNF package provided by a VNF or PNF vendor **MUST** be with
3473     TOSCA-Metadata directory (CSAR Option 1) as specified in
3474     ETSI GS NFV-SOL004.
3475
3476     **Note:** SDC supports only the CSAR Option 1 in Dublin. The Option 2
3477     will be considered in future ONAP releases.
3478
3479
3480 ONAP TOSCA VNFD or PNFD Requirements > VNF or PNF CSAR Package > VNF or PNF Package Authenticity and Integrity
3481 --------------------------------------------------------------------------------------------------------------
3482
3483
3484 Requirements Added
3485 ~~~~~~~~~~~~~~~~~~
3486
3487
3488 .. container:: note
3489
3490     :need:`R-130206`
3491
3492     If the VNF or PNF CSAR Package utilizes Option 2 for package security, then
3493     the complete CSAR file **MUST** contain a Digest (a.k.a. hash) for each of
3494     the components of the VNF or PNF package. The table of hashes is included
3495     in the package manifest file, which is signed with the VNF or PNF provider
3496     private key. In addition, the VNF or PNF provider MUST include a signing
3497     certificate that includes the VNF or PNF provider public key, following a
3498     TOSCA pre-defined naming convention and located either at the root of the
3499     archive or in a predefined location specified by the TOSCA.meta file with
3500     the corresponding entry named "ETSI-Entry-Certificate".
3501
3502
3503 .. container:: note
3504
3505     :need:`R-787965`
3506
3507     If the VNF or PNF CSAR Package utilizes Option 2 for package security, then
3508     the complete CSAR file **MUST** be digitally signed with the VNF or PNF
3509     provider private key. The VNF or PNF provider delivers one zip file
3510     consisting of the CSAR file, a signature file and a certificate file that
3511     includes the VNF or PNF provider public key. The certificate may also be
3512     included in the signature container, if the signature format allows that.
3513     The VNF or PNF provider creates a zip file consisting of the CSAR file with
3514     .csar extension, signature and certificate files. The signature and
3515     certificate files must be siblings of the CSAR file with extensions .cms
3516     and .cert respectively.
3517
3518
3519 PNF Plug and Play > PNF Plug and Play
3520 -------------------------------------
3521
3522
3523 Requirements Changed
3524 ~~~~~~~~~~~~~~~~~~~~
3525
3526
3527 .. container:: note
3528
3529     :need:`R-256347`
3530
3531     The PNF **MUST** support one of the protocols for a Service Configuration
3532     message exchange between the PNF and PNF Controller (in ONAP):
3533     a) Netconf/YANG, b) Chef, or c) Ansible.
3534
3535     Note: The PNF Controller may be VF-C, APP-C or SDN-C based on the
3536     PNF and PNF domain.
3537
3538
3539 .. container:: note
3540
3541     :need:`R-106240`
3542
3543     The following VES Events **SHOULD** be supported by the PNF: pnfRegistration
3544     VES Event, HVol VES Event, and Fault VES Event. These are onboarded via
3545     he SDC Design Studio.
3546
3547     Note: these VES Events are emitted from the PNF to support PNF Plug and
3548     Play, High Volume Measurements, and Fault events respectively.
3549
3550
3551 Resource IDs
3552 ------------
3553
3554
3555 Requirements Changed
3556 ~~~~~~~~~~~~~~~~~~~~
3557
3558
3559 .. container:: note
3560
3561     :need:`R-11690`
3562
3563     When a VNF's Heat Orchestration Template's Resource ID contains an
3564     ``{index}``, the ``{index}`` is a numeric value that **MUST** start at
3565     zero and **MUST** increment by one.
3566
3567     As stated in R-16447,
3568     *a VNF's <resource ID> MUST be unique across all Heat
3569     Orchestration Templates and all HEAT Orchestration Template
3570     Nested YAML files that are used to create the VNF*.  While the ``{index}``
3571     will start at zero in the VNF, the ``{index}`` may not start at zero
3572     in a given Heat Orchestration Template or HEAT Orchestration Template
3573     Nested YAML file.
3574
3575
3576 Resource IDs > Contrail Heat Resources Resource ID Naming Convention > OS::ContrailV2::InstanceIp
3577 -------------------------------------------------------------------------------------------------
3578
3579
3580 Requirements Changed
3581 ~~~~~~~~~~~~~~~~~~~~
3582
3583
3584 .. container:: note
3585
3586     :need:`R-53310`
3587
3588     A VNF's Heat Orchestration Template's Resource
3589     ``OS::ContrailV2::InstanceIp`` Resource ID
3590     that is configuring an IPv4 Address on a virtual machine interface
3591     (i.e., OS::ContrailV2::VirtualMachineInterface)
3592     attached to an external network
3593     **MUST** use the naming convention
3594
3595     *  ``{vm-type}_{vm-type_index}_{network-role}_vmi_{vmi_index}_IP_{index}``
3596
3597     where
3598
3599     * ``{vm-type}`` is the vm-type
3600     * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in
3601       the VNF.  The
3602       ``{vm-type_index}`` is a numeric value that **MUST** start at zero
3603       in the VNF and
3604       **MUST** increment by one each time a new instance of a ``{vm-type}``
3605       is referenced.
3606     * ``{network-role}`` is the network-role of the network that the
3607       virtual machine interface is attached to
3608     * ``{vmi_index}`` references the instance of the virtual machine interface
3609       on the ``{vm-type}`` attached to ``{network-role}`` network.  The
3610       ``{vmi_index}`` is a numeric value that **MUST** start at zero on an
3611       instance of a ``{vm-type}`` and **MUST** increment by one each time a
3612       new virtual machine interface is defined on the instance of the
3613       ``{vm-type}`` attached to ``{network-role}`` network.
3614     * ``IP`` signifies that an IPv4 address is being configured
3615     * ``{index}`` references the instance of the IPv4 address configured
3616       on the virtual machine interface.  The ``{index}`` is a numeric value
3617       that **MUST** start at zero on an
3618       instance of a virtual machine interface and **MUST** increment by one
3619       each time a new IPv4 address is configured on the
3620       virtual machine interface.
3621
3622
3623 .. container:: note
3624
3625     :need:`R-87563`
3626
3627     A VNF's Heat Orchestration Template's Resource
3628     ``OS::ContrailV2::InstanceIp`` Resource ID
3629     that is configuring an IPv6 Address on a virtual machine interface
3630     (i.e., OS::ContrailV2::VirtualMachineInterface)
3631     attached to an internal network
3632     **MUST** use the naming convention
3633
3634     *  ``{vm-type}_{vm-type_index}_int_{network-role}_vmi_{vmi_index}_v6_IP_{index}``
3635
3636     where
3637
3638     * ``{vm-type}`` is the vm-type
3639     * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in
3640       the VNF.  The
3641       ``{vm-type_index}`` is a numeric value that **MUST** start at zero
3642       in the VNF and
3643       **MUST** increment by one each time a new instance of a ``{vm-type}``
3644       is referenced.
3645     * ``{network-role}`` is the network-role of the network
3646       that the port is attached to
3647     * ``{vmi_index}`` references the instance of the virtual machine interface
3648       on the ``{vm-type}`` attached to ``{network-role}`` network.  The
3649       ``{vmi_index}`` is a numeric value that **MUST** start at zero on an
3650       instance of a ``{vm-type}`` and **MUST** increment by one each time a
3651       new virtual machine interface is defined on the instance of the
3652       ``{vm-type}`` attached to ``{network-role}`` network.
3653     * ``v6_IP`` signifies that an IPv6 address is being configured
3654     * ``{index}`` references the instance of the IPv6 address configured
3655       on the virtual machine interface.  The ``{index}`` is a numeric value
3656       that **MUST** start at zero on an
3657       instance of a virtual machine interface and **MUST** increment by one
3658       each time a new IPv6 address is configured on the
3659       virtual machine interface.
3660
3661
3662 .. container:: note
3663
3664     :need:`R-62187`
3665
3666     A VNF's Heat Orchestration Template's Resource
3667     ``OS::ContrailV2::InstanceIp`` Resource ID
3668     that is configuring an IPv4 Address on a virtual machine interface
3669     (i.e., OS::ContrailV2::VirtualMachineInterface)
3670     attached to an internal network
3671     **MUST** use the naming convention
3672
3673     *  ``{vm-type}_{vm-type_index}_int_{network-role}_vmi_{vmi_index}_IP_{index}``
3674
3675     where
3676
3677     * ``{vm-type}`` is the vm-type
3678     * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in
3679       the VNF.  The
3680       ``{vm-type_index}`` is a numeric value that **MUST** start at zero
3681       in the VNF and
3682       **MUST** increment by one each time a new instance of a ``{vm-type}``
3683       is referenced.
3684     * ``{network-role}`` is the network-role of the network
3685       that the port is attached to
3686     * ``{vmi_index}`` references the instance of the virtual machine interface
3687       on the ``{vm-type}`` attached to ``{network-role}`` network.  The
3688       ``{vmi_index}`` is a numeric value that **MUST** start at zero on an
3689       instance of a ``{vm-type}`` and **MUST** increment by one each time a
3690       new virtual machine interface is defined on the instance of the
3691       ``{vm-type}`` attached to ``{network-role}`` network.
3692     * ``IP`` signifies that an IPv4 address is being configured
3693     * ``{index}`` references the instance of the IPv4 address configured
3694       on the virtual machine interface.  The ``{index}`` is a numeric value
3695       that **MUST** start at zero on an
3696       instance of a virtual machine interface and **MUST** increment by one
3697       each time a new IPv4 address is configured on the
3698       virtual machine interface.
3699
3700
3701 .. container:: note
3702
3703     :need:`R-46128`
3704
3705     A VNF's Heat Orchestration Template's Resource
3706     ``OS::ContrailV2::InstanceIp`` Resource ID
3707     that is configuring an IPv6 Address on a virtual machine interface
3708     (i.e., OS::ContrailV2::VirtualMachineInterface)
3709     attached to an external network
3710     **MUST** use the naming convention
3711
3712     *  ``{vm-type}_{vm-type_index}_{network-role}_vmi_{vmi_index}_v6_IP_{index}``
3713
3714     where
3715
3716     * ``{vm-type}`` is the vm-type
3717     * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in
3718       the VNF.  The
3719       ``{vm-type_index}`` is a numeric value that **MUST** start at zero
3720       in the VNF and
3721       **MUST** increment by one each time a new instance of a ``{vm-type}``
3722       is referenced.
3723     * ``{network-role}`` is the network-role of the network
3724       that the port is attached to
3725     * ``{vmi_index}`` references the instance of the virtual machine interface
3726       on the ``{vm-type}`` attached to ``{network-role}`` network.  The
3727       ``{vmi_index}`` is a numeric value that **MUST** start at zero on an
3728       instance of a ``{vm-type}`` and **MUST** increment by one each time a
3729       new virtual machine interface is defined on the instance of the
3730       ``{vm-type}`` attached to ``{network-role}`` network.
3731     * ``v6_IP`` signifies that an IPv6 address is being configured
3732     * ``{index}`` references the instance of the IPv6 address configured
3733       on the virtual machine interface.  The ``{index}`` is a numeric value
3734       that **MUST** start at zero on an
3735       instance of a virtual machine interface and **MUST** increment by one
3736       each time a new IPv6 address is configured on the
3737       virtual machine interface.
3738
3739
3740 Requirements Removed
3741 ~~~~~~~~~~~~~~~~~~~~
3742
3743
3744 .. container:: note
3745
3746     R-20947
3747
3748     A VNF's Heat Orchestration Template's Resource ``OS::ContrailV2::InstanceIp``
3749     that is configuring an IPv4 Address on a sub-interface port attached to a
3750     sub-interface network Resource ID **MUST** use the naming convention
3751
3752     *  ``{vm-type}_{vm-type_index}_subint_{network-role}_vmi_{vmi_index}_IP_{index}``
3753
3754     where
3755
3756     * ``{vm-type}`` is the vm-type
3757     * ``{vm-type_index}`` is the instance of the ``{vm-type}``
3758     * ``{network-role}`` is the network-role of the network
3759       that the port is attached to
3760     * ``{vmi_index}`` is the instance of the the virtual machine interface
3761       (e.g., port)  on the vm-type
3762       attached to the network of ``{network-role}``
3763     * ``IP`` signifies that an IPv4 address is being configured
3764     * ``{index}`` is the index of the IPv4 address
3765
3766
3767 .. container:: note
3768
3769     R-88540
3770
3771     A VNF's Heat Orchestration Template's Resource ``OS::ContrailV2::InstanceIp``
3772     that is configuring an IPv6 Address on a sub-interface port attached to a
3773     sub-interface network Resource ID **MUST**
3774     use the naming convention
3775
3776     *  ``{vm-type}_{vm-type_index}_subint_{network-role}_vmi_{vmi_index}_v6_IP_{index}``
3777
3778     where
3779
3780     * ``{vm-type}`` is the vm-type
3781     * ``{vm-type_index}`` is the instance of the ``{vm-type}``
3782     * ``{network-role}`` is the network-role of the network
3783       that the port is attached to
3784     * ``{vmi_index}`` is the instance of the the virtual machine interface
3785       (e.g., port)  on the vm-type
3786       attached to the network of ``{network-role}``
3787     * ``v6_IP`` signifies that an IPv6 address is being configured
3788     * ``{index}`` is the index of the IPv6 address
3789
3790
3791 Resource IDs > Contrail Heat Resources Resource ID Naming Convention > OS::ContrailV2::ServiceTemplate
3792 ------------------------------------------------------------------------------------------------------
3793
3794
3795 Requirements Changed
3796 ~~~~~~~~~~~~~~~~~~~~
3797
3798
3799 .. container:: note
3800
3801     :need:`R-14447`
3802
3803     A VNF's Heat Orchestration Template's Resource ``OS::ContrailV2::ServiceTemplate``
3804     Resource ID **MAY** use the naming convention
3805
3806     * ``{vm-type}_RST_{index}``
3807
3808     where
3809
3810     * ``{vm-type}`` is the vm-type
3811     * ``RST`` signifies that it is the Resource Service Template
3812     * ``{index}`` is the index.
3813       The ``{index}`` starts at zero and increments by one
3814       (as described in R-11690).
3815
3816
3817 Resource IDs > Contrail Heat Resources Resource ID Naming Convention > OS::ContrailV2::VirtualMachineInterface
3818 --------------------------------------------------------------------------------------------------------------
3819
3820
3821 Requirements Changed
3822 ~~~~~~~~~~~~~~~~~~~~
3823
3824
3825 .. container:: note
3826
3827     :need:`R-50468`
3828
3829     A VNF's Heat Orchestration Template's Resource
3830     ``OS::ContrailV2::VirtualMachineInterface`` Resource ID
3831     that is attaching to an internal network
3832     **MUST** use the naming convention
3833
3834     * ``{vm-type}_{vm-type_index}_int_{network-role}_vmi_{vmi_index}``
3835
3836     where
3837
3838     * ``{vm-type}`` is the vm-type
3839     * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in
3840       the VNF.  The
3841       ``{vm-type_index}`` is a numeric value that **MUST** start at zero
3842       in the VNF and
3843       **MUST** increment by one each time a new instance of a ``{vm-type}``
3844       is referenced.
3845     * ``{network-role}`` is the network-role of the network
3846       that the port (i.e. virtual machine interface) is attached to
3847     * ``{vmi_index}`` references the instance of the virtual machine interface
3848       on the ``{vm-type}`` attached to ``{network-role}`` network.  The
3849       ``{vmi_index}`` is a numeric value that **MUST** start at zero on an
3850       instance of a ``{vm-type}`` and **MUST** increment by one each time a
3851       new virtual machine interface is defined on the instance of the
3852       ``{vm-type}`` attached to ``{network-role}`` network.
3853
3854
3855 .. container:: note
3856
3857     :need:`R-96253`
3858
3859     A VNF's Heat Orchestration Template's Resource
3860     ``OS::ContrailV2::VirtualMachineInterface`` Resource ID
3861     that is attaching to an external network
3862     **MUST** use the naming convention
3863
3864     * ``{vm-type}_{vm-type_index}_{network-role}_vmi_{vmi_index}``
3865
3866     where
3867
3868     * ``{vm-type}`` is the vm-type
3869     * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in
3870       the VNF.  The
3871       ``{vm-type_index}`` is a numeric value that **MUST** start at zero
3872       in the VNF and
3873       **MUST** increment by one each time a new instance of a ``{vm-type}``
3874       is referenced.
3875     * ``{network-role}`` is the network-role of the network
3876       that the port (i.e. virtual machine interface) is attached to
3877     * ``{vmi_index}`` references the instance of the virtual machine interface
3878       on the ``{vm-type}`` attached to ``{network-role}`` network.  The
3879       ``{vmi_index}`` is a numeric value that **MUST** start at zero on an
3880       instance of a ``{vm-type}`` and **MUST** increment by one each time a
3881       new virtual machine interface is defined on the instance of the
3882       ``{vm-type}`` attached to ``{network-role}`` network.
3883
3884
3885 Requirements Removed
3886 ~~~~~~~~~~~~~~~~~~~~
3887
3888
3889 .. container:: note
3890
3891     R-54458
3892
3893     A VNF's Heat Orchestration Template's Resource
3894     ``OS::ContrailV2::VirtualMachineInterface`` that is attaching to a sub-interface
3895     network Resource ID **MUST** use the naming convention
3896
3897     * ``{vm-type}_{vm-type_index}_subint_{network-role}_vmi_{vmi_index}``
3898
3899     where
3900
3901     * ``{vm-type}`` is the vm-type
3902     * ``{vm-type_index}`` is the instance of the ``{vm-type}``
3903     * ``{network-role}`` is the network-role of the network
3904       that the port (i.e. virtual machine interface) is attached to
3905     * ``{vmi_index}`` is the instance of the the vmi on the vm-type
3906       attached to the network of ``{network-role}``
3907
3908
3909 Resource IDs > Contrail Heat Resources Resource ID Naming Convention > OS::ContrailV2::VirtualNetwork
3910 -----------------------------------------------------------------------------------------------------
3911
3912
3913 Requirements Changed
3914 ~~~~~~~~~~~~~~~~~~~~
3915
3916
3917 .. container:: note
3918
3919     :need:`R-99110`
3920
3921     A VNF's Heat Orchestration Template's Resource
3922     ``OS::ContrailV2::VirtualNetwork`` Resource ID **MUST** use the naming
3923     convention
3924
3925     * ``int_{network-role}_network``
3926
3927     VNF Heat Orchestration Templates can only create internal networks.
3928     There is no ``{index}`` after ``{network-role}`` because ``{network-role}``
3929     **MUST** be unique in the scope of the VNF's
3930     Heat Orchestration Template.
3931
3932
3933 Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Cinder::Volume
3934 ------------------------------------------------------------------------------------------
3935
3936
3937 Requirements Changed
3938 ~~~~~~~~~~~~~~~~~~~~
3939
3940
3941 .. container:: note
3942
3943     :need:`R-87004`
3944
3945     A VNF's Heat Orchestration Template's Resource
3946     ``OS::Cinder::Volume``
3947     Resource ID
3948     **SHOULD**
3949     use the naming convention
3950
3951     * ``{vm-type}_volume_{index}``
3952
3953     where
3954
3955     * ``{vm-type}`` is the vm-type
3956     * ``{index}`` starts at zero and increments by one (as described in R-11690)
3957
3958
3959 Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Cinder::VolumeAttachment
3960 ----------------------------------------------------------------------------------------------------
3961
3962
3963 Requirements Changed
3964 ~~~~~~~~~~~~~~~~~~~~
3965
3966
3967 .. container:: note
3968
3969     :need:`R-86497`
3970
3971     A VNF's Heat Orchestration Template's Resource
3972     ``OS::Cinder::VolumeAttachment``
3973     Resource ID
3974     **SHOULD**
3975     use the naming convention
3976
3977     * ``{vm-type}_volume_attachment_{index}``
3978
3979     where
3980
3981     * ``{vm-type}`` is the vm-type
3982     * ``{index}`` starts at zero and increments by one (as described in R-11690)
3983
3984
3985 Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Heat::ResourceGroup
3986 -----------------------------------------------------------------------------------------------
3987
3988
3989 Requirements Removed
3990 ~~~~~~~~~~~~~~~~~~~~
3991
3992
3993 .. container:: note
3994
3995     R-64197
3996
3997     A VNF's Heat Orchestration Template's Resource ``OS::Heat::ResourceGroup``
3998     Resource ID that creates sub-interfaces **MUST** use the naming convention
3999
4000     * ``{vm-type}_{vm-type_index}_subint_{network-role}_port_{port-index}_subinterfaces``
4001
4002     where
4003
4004     * ``{vm-type}`` is the vm-type
4005     * ``{vm-type_index}`` is the instance of the ``{vm-type}``
4006     * ``{network-role}`` is the network-role of the networks
4007       that the sub-interfaces attach to
4008     * ``{port-index}`` is the instance of the the port on the vm-type
4009       attached to the network of ``{network-role}``
4010
4011
4012 Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Neutron::Port
4013 -----------------------------------------------------------------------------------------
4014
4015
4016 Requirements Changed
4017 ~~~~~~~~~~~~~~~~~~~~
4018
4019
4020 .. container:: note
4021
4022     :need:`R-68520`
4023
4024     A VNF's Heat Orchestration Template's Resource ``OS::Neutron::Port``
4025     that is creating a *Reserve Port* with an IPv6 address Resource ID
4026     **SHOULD** use the naming convention
4027
4028     * ``reserve_port_{vm-type}_{network-role}_floating_v6_ip_{index}``
4029
4030     where
4031
4032     * ``{vm-type}`` is the vm-type
4033     * ``{network-role}`` is the network-role of the network
4034       that the port is attached to
4035     * ``{index}`` is the instance of the IPv6 *Reserve Port*
4036       for the vm-type attached to the network of ``{network-role}``.
4037       The ``{index}`` starts at zero and increments by one
4038       (as described in R-11690).
4039
4040
4041 .. container:: note
4042
4043     :need:`R-27469`
4044
4045     A VNF's Heat Orchestration Template's Resource ``OS::Neutron::Port``
4046     that is creating a *Reserve Port* with an IPv4 address Resource ID
4047     **SHOULD** use the naming convention
4048
4049     * ``reserve_port_{vm-type}_{network-role}_floating_ip_{index}``
4050
4051     where
4052
4053     * ``{vm-type}`` is the vm-type
4054     * ``{network-role}`` is the network-role of the network
4055       that the port is attached to
4056     * ``{index}`` is the instance of the IPv4 *Reserve Port*
4057       for the vm-type attached to the network of ``{network-role}``.
4058       The ``{index}`` starts at zero and increments by one
4059       (as described in R-11690).
4060
4061
4062 .. container:: note
4063
4064     :need:`R-26351`
4065
4066     A VNF's Heat Orchestration Template's Resource ``OS::Neutron::Port``
4067     that is attaching to an internal network Resource ID **MUST**
4068     use the naming convention
4069
4070     * ``{vm-type}_{vm-type_index}_int_{network-role}_port_{port-index}``
4071
4072     where
4073
4074     * ``{vm-type}`` is the vm-type
4075     * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in
4076       the VNF.  The
4077       ``{vm-type_index}`` is a numeric value that **MUST** start at zero
4078       in the VNF and
4079       **MUST** increment by one each time a new instance of a ``{vm-type}``
4080       is referenced.
4081     * ``{network-role}`` is the network-role of the network
4082       that the port is attached to
4083     * ``{port_index}`` references the instance of the port on the ``{vm-type}``
4084       attached to ``{network-role}`` network.  The
4085       ``{port_index}`` is a numeric value that **MUST** start at zero on an
4086       instance of a ``{vm-type}`` and **MUST** increment by one each time a
4087       new port is defined on the instance of the ``{vm-type}`` attached to
4088       ``{network-role}`` network.
4089
4090
4091 .. container:: note
4092
4093     :need:`R-20453`
4094
4095     A VNF's Heat Orchestration Template's Resource ``OS::Neutron::Port``
4096     that is attaching to an external network Resource ID
4097     **MUST** use the naming convention
4098
4099     * ``{vm-type}_{vm-type_index}_{network-role}_port_{port-index}``
4100
4101     where
4102
4103     * ``{vm-type}`` is the vm-type
4104     * ``{vm-type_index}`` references the instance of the ``{vm-type}`` in
4105       the VNF.  The
4106       ``{vm-type_index}`` is a numeric value that **MUST** start at zero
4107       in the VNF and
4108       **MUST** increment by one each time a new instance of a ``{vm-type}``
4109       is referenced.
4110     * ``{network-role}`` is the network-role of the network
4111       that the port is attached to
4112     * ``{port_index}`` references the instance of the port on the ``{vm-type}``
4113       attached to ``{network-role}`` network.  The
4114       ``{port_index}`` is a numeric value that **MUST** start at zero on an
4115       instance of a ``{vm-type}`` and **MUST** increment by one each time a
4116       new port is defined on the instance of the ``{vm-type}`` attached to
4117       ``{network-role}`` network.
4118
4119
4120 Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Neutron::Subnet
4121 -------------------------------------------------------------------------------------------
4122
4123
4124 Requirements Changed
4125 ~~~~~~~~~~~~~~~~~~~~
4126
4127
4128 .. container:: note
4129
4130     :need:`R-59434`
4131
4132     A VNF's Heat Orchestration Template's Resource ``OS::Neutron::Subnet``
4133     Resource ID **SHOULD** use the naming convention
4134
4135     * ``int_{network-role}_subnet_{index}``
4136
4137     where
4138
4139     * ``{network-role}`` is the network-role
4140     * ``{index}`` is the ``{index}`` of the subnet of the network.
4141       The ``{index}`` starts at zero and increments by one
4142       (as described in R-11690).
4143
4144
4145 Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Nova::Keypair
4146 -----------------------------------------------------------------------------------------
4147
4148
4149 Requirements Changed
4150 ~~~~~~~~~~~~~~~~~~~~
4151
4152
4153 .. container:: note
4154
4155     :need:`R-24997`
4156
4157     A VNF's Heat Orchestration Template's Resource ``OS::Nova::Keypair`` applies to
4158     one ``{vm-type}`` Resource ID **SHOULD** use the naming convention
4159
4160     * ``{vm-type}_keypair_{index}``
4161
4162     where
4163
4164     * ``{network-role}`` is the network-role
4165     * ``{index}`` is the ``{index}`` of the keypair.
4166       The ``{index}`` starts at zero and increments by one
4167       (as described in R-11690).
4168
4169
4170 .. container:: note
4171
4172     :need:`R-65516`
4173
4174     A VNF's Heat Orchestration Template's Resource ``OS::Nova::Keypair`` applies to
4175     all Virtual Machines in the VNF, the Resource ID **SHOULD** use the naming
4176     convention
4177
4178     * ``{vnf-type}_keypair``
4179
4180     where
4181
4182     * ``{vnf-type}`` describes the VNF
4183
4184
4185 Resource IDs > OpenStack Heat Resources Resource ID Naming Convention > OS::Nova::Server
4186 ----------------------------------------------------------------------------------------
4187
4188
4189 Requirements Changed
4190 ~~~~~~~~~~~~~~~~~~~~
4191
4192
4193 .. container:: note
4194
4195     :need:`R-29751`
4196
4197     A VNF's Heat Orchestration Template's Resource ``OS::Nova::Server``
4198     Resource ID
4199     **MUST** use the naming convention
4200
4201     * ``{vm-type}_server_{index}``
4202
4203     where
4204
4205     * ``{vm-type}`` is the vm-type
4206     * ``{index}`` is the index.
4207       The ``{index}`` **MUST** starts at zero and increment by one
4208       as described in R-11690.
4209
4210
4211 Resource Property “name”
4212 ------------------------
4213
4214
4215 Requirements Changed
4216 ~~~~~~~~~~~~~~~~~~~~
4217
4218
4219 .. container:: note
4220
4221     :need:`R-85734`
4222
4223     If a VNF's Heat Orchestration Template contains the property ``name``
4224     for a non ``OS::Nova::Server`` resource, the intrinsic function
4225     ``str_replace`` **MUST** be used in conjunction with the ONAP
4226     supplied metadata parameter ``vnf_name`` to generate a unique value.
4227     Additional data **MAY** be used in the ``str_replace`` construct
4228     to generate a unique value.
4229
4230
4231 Requirements Removed
4232 ~~~~~~~~~~~~~~~~~~~~
4233
4234
4235 .. container:: note
4236
4237     R-32408
4238
4239     If a VNF's Heat Orchestration Template property ``name``
4240     for a non ``OS::Nova::Server`` resource uses the intrinsic function
4241     ``str_replace`` in conjunction with the ONAP
4242     supplied metadata parameter ``vnf_name`` and does not create
4243     a unique value, additional data **MUST** be used in the
4244     ``str_replace`` to create a unique value, such as ``OS::stack_name``
4245     and/or the ``OS::Heat::ResourceGroup`` ``index``.
4246
4247
4248 Resource: OS::Neutron::Port - Parameters > Introduction > Items to Note
4249 -----------------------------------------------------------------------
4250
4251
4252 Requirements Added
4253 ~~~~~~~~~~~~~~~~~~
4254
4255
4256 .. container:: note
4257
4258     :need:`R-681859`
4259
4260     A VNF's Heat Orchestration Template's ``OS::Neutron::Port`` resource's
4261
4262     * Resource ID (defined in R-20453)
4263     * property ``network`` parameter name (defined in R-62983 and
4264       R-86182)
4265     * property ``fixed_ips``, map property ``ip_address`` parameter name
4266       (defined in R-40971, R-04697, R-71577, R-23503, R-78380, R-85235,
4267       R-27818, and R-29765)
4268     * property ``fixed_ips``, map property ``subnet`` parameter name
4269       (defined in R-62802, R-15287, R-84123, R-76160)
4270     * property ``allowed_address_pairs`` parameter name (defined in
4271       R-41492 and R-83418)
4272
4273     **MUST** contain the identical ``{network-role}``.
4274
4275
4276 Requirements Removed
4277 ~~~~~~~~~~~~~~~~~~~~
4278
4279
4280 .. container:: note
4281
4282     R-07577
4283
4284     If the VNF's ports connected to a unique network (internal or external)
4285     and the port's IP addresses are cloud assigned IP Addresses,
4286     all the IPv4 Addresses **MUST** be from
4287     the same subnet and all the IPv6 Addresses **MUST** be from the
4288     same subnet.
4289
4290
4291 .. container:: note
4292
4293     R-13841
4294
4295     A VNF **MAY** have one or more ports connected to a unique
4296     internal network. All VNF ports connected to the unique internal
4297     network **MUST** have cloud assigned IP Addresses
4298     or **MUST** have statically assigned IP addresses.
4299
4300
4301 .. container:: note
4302
4303     R-93272
4304
4305     A VNF **MAY** have one or more ports connected to a unique
4306     external network. All VNF ports connected to the unique external
4307     network **MUST** have cloud assigned IP Addresses
4308     or **MUST** have ONAP SDN-C assigned IP addresses.
4309
4310
4311 Resource: OS::Neutron::Port - Parameters > Property: allowed_address_pairs, Map Property: ip_address
4312 ----------------------------------------------------------------------------------------------------
4313
4314
4315 Requirements Removed
4316 ~~~~~~~~~~~~~~~~~~~~
4317
4318
4319 .. container:: note
4320
4321     R-62300
4322
4323     If a VNF has two or more ports that require a Virtual IP Address (VIP),
4324     a VNF's Heat Orchestration Template's Resource
4325     ``OS::Neutron::Port`` property ``allowed_address_pairs``
4326     map property ``ip_address`` parameter
4327     **MUST** be used.
4328
4329
4330 Resource: OS::Neutron::Port - Parameters > Property: allowed_address_pairs, Map Property: ip_address > VIP Assignment, External Networks
4331 ----------------------------------------------------------------------------------------------------------------------------------------
4332
4333
4334 Requirements Added
4335 ~~~~~~~~~~~~~~~~~~
4336
4337
4338 .. container:: note
4339
4340     :need:`R-41493`
4341
4342     When the VNF's Heat Orchestration Template's resource
4343     ``OS::Neutron::Port`` is attaching to an external network
4344     (per the ONAP definition, see Requirement R-57424),
4345     and the IPv4 VIP address and/or IPv6 VIP address
4346     is **not** supported by the ONAP data model,
4347     the property ``allowed_address_pairs`` map property ``ip_address``
4348
4349     * Parameter name **MAY** use any naming convention.  That is, there is no
4350       ONAP mandatory parameter naming convention.
4351     * Parameter **MAY** be declared as type ``string`` or type
4352     ``comma_delimited_list``.
4353
4354     And the ``OS::Neutron::Port`` resource **MUST** contain
4355     resource-level ``metadata`` (not property-level).
4356
4357     And the ``metadata`` format **MUST**  must contain the
4358     key value ``aap_exempt`` with a list of all
4359     ``allowed_address_pairs`` map property ``ip_address`` parameters
4360     **not** supported by the ONAP data model.
4361
4362
4363 Requirements Changed
4364 ~~~~~~~~~~~~~~~~~~~~
4365
4366
4367 .. container:: note
4368
4369     :need:`R-35735`
4370
4371     When the VNF's Heat Orchestration Template's resource
4372     ``OS::Neutron::Port`` is attaching to an external network
4373     (per the ONAP definition, see Requirement R-57424),
4374     and the IPv6 VIP is required to be supported by the ONAP data model,
4375     the property ``allowed_address_pairs`` map property ``ip_address``
4376     parameter name **MUST** follow the naming convention
4377
4378     * ``{vm-type}_{network-role}_floating_v6_ip``
4379
4380     where
4381
4382     * ``{vm-type}`` is the {vm-type} associated with the ``OS::Nova::Server``
4383     * ``{network-role}`` is the {network-role} of the external network
4384
4385     And the parameter **MUST** be declared as type ``string``.
4386
4387     As noted in the introduction to this section, the ONAP data model
4388     can only support one IPv6 VIP address.
4389
4390
4391 .. container:: note
4392
4393     :need:`R-83412`
4394
4395     If a VNF's Heat Orchestration Template's resource
4396     ``OS::Neutron::Port`` is attaching to an external network (per the
4397     ONAP definition, see Requirement R-57424), the
4398     property ``allowed_address_pairs``
4399     map property ``ip_address`` parameter(s)
4400     **MUST NOT** be enumerated in the
4401     VNF's Heat Orchestration Template's Environment File.
4402
4403
4404 .. container:: note
4405
4406     :need:`R-41492`
4407
4408     When the VNF's Heat Orchestration Template's resource
4409     ``OS::Neutron::Port`` is attaching to an external network
4410     (per the ONAP definition, see Requirement R-57424),
4411     and the IPv4 VIP is required to be supported by the ONAP data model,
4412     the property ``allowed_address_pairs`` map property ``ip_address``
4413     parameter name **MUST** follow the naming convention
4414
4415     * ``{vm-type}_{network-role}_floating_ip``
4416
4417     where
4418
4419     * ``{vm-type}`` is the {vm-type} associated with the ``OS::Nova::Server``
4420     * ``{network-role}`` is the {network-role} of the external network
4421
4422     And the parameter **MUST** be declared as type ``string``.
4423
4424     As noted in the introduction to this section, the ONAP data model
4425     can only support one IPv4 VIP address.
4426
4427
4428 Resource: OS::Neutron::Port - Parameters > Property: allowed_address_pairs, Map Property: ip_address > VIP Assignment, External Networks, Supported by Automation
4429 -----------------------------------------------------------------------------------------------------------------------------------------------------------------
4430
4431
4432 Requirements Removed
4433 ~~~~~~~~~~~~~~~~~~~~
4434
4435
4436 .. container:: note
4437
4438     R-10754
4439
4440     If a VNF has two or more ports that
4441     attach to an external network that require a Virtual IP Address (VIP),
4442     and the VNF requires ONAP automation to assign the IP address,
4443     all the Virtual Machines using the VIP address **MUST**
4444     be instantiated in the same Base Module Heat Orchestration Template
4445     or in the same Incremental Module Heat Orchestration Template.
4446
4447
4448 .. container:: note
4449
4450     R-41956
4451
4452     If a VNF requires ONAP to assign a Virtual IP (VIP) Address to
4453     ports connected an external network, the port
4454     **MUST NOT** have more than one IPv6 VIP address.
4455
4456
4457 .. container:: note
4458
4459     R-83418
4460
4461     The VNF's Heat Orchestration Template's Resource
4462     ``OS::Neutron::Port`` property ``allowed_address_pairs``
4463     map property ``ip_address`` parameter
4464     ``{vm-type}_{network-role}_floating_v6_ip``
4465     **MUST NOT** be enumerated in the
4466     VNF's Heat Orchestration Template's Environment File.
4467
4468
4469 .. container:: note
4470
4471     R-91810
4472
4473     If a VNF requires ONAP to assign a Virtual IP (VIP) Address to
4474     ports connected an external network, the port
4475     **MUST NOT** have more than one IPv4 VIP address.
4476
4477
4478 .. container:: note
4479
4480     R-98748
4481
4482     The VNF's Heat Orchestration Template's Resource
4483     ``OS::Neutron::Port`` property ``allowed_address_pairs``
4484     map property ``ip_address`` parameter
4485     **MUST** be declared as type ``string``.
4486
4487
4488 Resource: OS::Neutron::Port - Parameters > Property: allowed_address_pairs, Map Property: ip_address > VIP Assignment, Internal Networks
4489 ----------------------------------------------------------------------------------------------------------------------------------------
4490
4491
4492 Requirements Added
4493 ~~~~~~~~~~~~~~~~~~
4494
4495
4496 .. container:: note
4497
4498     :need:`R-717227`
4499
4500     When the VNF's Heat Orchestration Template's Resource
4501     ``OS::Neutron::Port`` is attaching to an internal network (per the
4502     ONAP definition, see Requirements R-52425 and R-46461),
4503     and an IPv4 Virtual IP (VIP)
4504     address is assigned using the property ``allowed_address_pairs``
4505     map property ``ip_address``,
4506     the parameter name **MUST** follow the
4507     naming convention
4508
4509       * ``{vm-type}_int_{network-role}_floating_ip``
4510
4511     where
4512
4513       * ``{vm-type}`` is the {vm-type} associated with the
4514         OS::Nova::Server
4515       * ``{network-role}`` is the {network-role} of the external
4516         network
4517
4518     And the parameter **MUST** be declared as ``type: string``
4519     and **MUST** be enumerated in the environment file.
4520
4521     OR
4522
4523     the parameter name **MUST** follow the
4524     naming convention
4525
4526       * ``{vm-type}_int_{network-role}_floating_ips``
4527
4528     where
4529
4530       * ``{vm-type}`` is the {vm-type} associated with the
4531         OS::Nova::Server
4532       * ``{network-role}`` is the {network-role} of the external
4533         network
4534
4535     And the parameter **MUST** be declared as ``type: comma_delimited_list``
4536     and **MUST** be enumerated in the environment file.
4537
4538
4539 .. container:: note
4540
4541     :need:`R-805572`
4542
4543     When the VNF's Heat Orchestration Template's Resource
4544     ``OS::Neutron::Port`` is attaching to an internal network (per the
4545     ONAP definition, see Requirements R-52425 and R-46461),
4546     and an IPv6 Virtual IP (VIP)
4547     address is assigned
4548     using the property ``allowed_address_pairs``
4549     map property ``ip_address``,
4550     the parameter name **MUST** follow the
4551     naming convention
4552
4553       * ``{vm-type}_int_{network-role}_floating_v6_ip``
4554
4555     where
4556
4557       * ``{vm-type}`` is the {vm-type} associated with the
4558         OS::Nova::Server
4559       * ``{network-role}`` is the {network-role} of the external
4560         network
4561
4562     And the parameter **MUST** be declared as ``type: string``
4563     and **MUST** be enumerated in the environment file
4564
4565     OR
4566
4567     the parameter name **MUST** follow the
4568     naming convention
4569
4570       * ``{vm-type}_int_{network-role}_floating_v6_ips``
4571
4572     where
4573
4574       * ``{vm-type}`` is the {vm-type} associated with the
4575         OS::Nova::Server
4576       * ``{network-role}`` is the {network-role} of the external
4577         network
4578
4579     And the parameter **MUST** be declared as ``type: comma_delimited_list``
4580     and **MUST** be enumerated in the environment file.
4581
4582
4583 Resource: OS::Neutron::Port - Parameters > Property: fixed_ips, Map Property: ip_address
4584 ----------------------------------------------------------------------------------------
4585
4586
4587 Requirements Changed
4588 ~~~~~~~~~~~~~~~~~~~~
4589
4590
4591 .. container:: note
4592
4593     :need:`R-78380`
4594
4595     When the VNF's Heat Orchestration Template's Resource
4596     ``OS::Neutron::Port`` is attaching to an internal network (per the
4597     ONAP definition, see Requirements R-52425 and R-46461),
4598     and an IPv4 address is assigned
4599     using the property ``fixed_ips``
4600     map property ``ip_address`` and the parameter type is
4601     defined as a ``string``,
4602     the parameter name **MUST** follow the
4603     naming convention
4604
4605     * ``{vm-type}_int_{network-role}_ip_{index}``
4606
4607     where
4608
4609     * ``{vm-type}`` is the {vm-type} associated with the
4610       ``OS::Nova::Server``
4611     * ``{network-role}`` is the {network-role} of the internal network
4612     * ``{index}`` is a numeric value that **MUST** start at zero in a
4613       VNF's Heat Orchestration Template and **MUST** increment by one
4614
4615
4616 .. container:: note
4617
4618     :need:`R-71577`
4619
4620     When the VNF's Heat Orchestration Template's Resource
4621     ``OS::Neutron::Port`` is attaching to an external network (per the
4622     ONAP definition, see Requirement R-57424),
4623     and an IPv6 address is assigned
4624     using the property ``fixed_ips``
4625     map property ``ip_address`` and the parameter type is defined as a string,
4626     the parameter name **MUST** follow the
4627     naming convention
4628
4629     * ``{vm-type}_{network-role}_v6_ip_{index}``
4630
4631     where
4632
4633     * ``{vm-type}`` is the {vm-type} associated with the
4634       ``OS::Nova::Server``
4635     * ``{network-role}`` is the {network-role} of the external network
4636     * ``{index}`` is a numeric value that **MUST** start at zero in a
4637       VNF's Heat Orchestration Template and **MUST** increment by one
4638
4639
4640 .. container:: note
4641
4642     :need:`R-40971`
4643
4644     When the VNF's Heat Orchestration Template's Resource
4645     ``OS::Neutron::Port`` is attaching to an external network (per the
4646     ONAP definition, see Requirement R-57424),
4647     and an IPv4 address is assigned
4648     using the property ``fixed_ips``
4649     map property ``ip_address`` and the parameter type is defined as a string,
4650     the parameter name **MUST** follow the
4651     naming convention
4652
4653     * ``{vm-type}_{network-role}_ip_{index}``
4654
4655     where
4656
4657     * ``{vm-type}`` is the {vm-type} associated with the ``OS::Nova::Server``
4658     * ``{network-role}`` is the {network-role} of the external network
4659     * ``{index}`` is a numeric value that **MUST** start at zero in a
4660       VNF's Heat Orchestration Template and **MUST** increment by one
4661
4662
4663 .. container:: note
4664
4665     :need:`R-27818`
4666
4667     When the VNF's Heat Orchestration Template's Resource
4668     ``OS::Neutron::Port`` is attaching to an internal network (per the
4669     ONAP definition, see Requirements R-52425 and R-46461),
4670     and an IPv6 address is assigned
4671     using the property ``fixed_ips``
4672     map property ``ip_address`` and the parameter type is defined as a
4673     ``string``,
4674     the parameter name **MUST** follow the
4675     naming convention
4676
4677     * ``{vm-type}_int_{network-role}_v6_ip_{index}``
4678
4679     where
4680
4681     * ``{vm-type}`` is the {vm-type} associated with the ``OS::Nova::Server``
4682     * ``{network-role}`` is the {network-role} of the internal network
4683     * ``{index}`` is a numeric value that **MUST** start at zero in a
4684       VNF's Heat Orchestration Template and **MUST** increment by one
4685
4686
4687 Resource: OS::Neutron::Port - Parameters > Property: network
4688 ------------------------------------------------------------
4689
4690
4691 Requirements Changed
4692 ~~~~~~~~~~~~~~~~~~~~
4693
4694
4695 .. container:: note
4696
4697     :need:`R-86182`
4698
4699     When the VNF's Heat Orchestration Template's Resource
4700     ``OS::Neutron::Port``
4701     is in an incremental module and
4702     is attaching to an internal network (per the
4703     ONAP definition, see Requirements R-52425 and R-46461),
4704     the ``network`` parameter name **MUST**
4705
4706       * follow the naming convention ``int_{network-role}_net_id`` if the
4707         network UUID value is used to reference the network
4708       * follow the naming convention ``int_{network-role}_net_name`` if the
4709         network name in is used to reference the network.
4710
4711     where ``{network-role}`` is the network-role of the internal network and
4712     a ``get_param`` **MUST** be used as the intrinsic function.
4713
4714
4715 Requirements Removed
4716 ~~~~~~~~~~~~~~~~~~~~
4717
4718
4719 .. container:: note
4720
4721     R-93177
4722
4723     When the VNF's Heat Orchestration Template's resource
4724     ``OS::Neutron::Port`` is attaching to an internal network (per the
4725     ONAP definition, see Requirements R-52425 and R-46461),
4726     and the internal network is created in the
4727     same Heat Orchestration Template as the ``OS::Neutron::Port``,
4728     the ``network`` property value **MUST** obtain the UUID
4729     of the internal network by using the intrinsic function
4730     ``get_resource``
4731     and referencing the Resource ID of the internal network.
4732
4733
4734 Resource: OS::Nova::Server - Parameters
4735 ---------------------------------------
4736
4737
4738 Requirements Changed
4739 ~~~~~~~~~~~~~~~~~~~~
4740
4741
4742 .. container:: note
4743
4744     :need:`R-304011`
4745
4746     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource's
4747
4748     * Resource ID (defined in R-29751)
4749     * property ``image`` parameter name (defined in R-58670)
4750     * property ``flavor`` parameter name (defined in R-45188)
4751     * property ``name`` parameter name (defined in R-54171 & R-87817)
4752     * property ``networks`` map property ``port`` value which is a
4753       ``OS::Neutron::Port`` Resource ID (defined in R-20453)
4754       referenced using the intrinsic function ``get_attr``
4755
4756     **MUST** contain the identical ``{vm-type}``
4757     and **MUST** follow the naming conventions defined
4758     in R-58670, R-45188, R-54171, R-87817, and R-29751.  And the ``{index}`` in
4759     the ``OS::Nova::Server`` Resource ID (defined in R-29751) **MUST** match
4760     the ``{vm-type_index}`` defined in
4761     the ``OS::Nova::Server`` property ``networks`` map property ``port``
4762     referenced ``OS::Neutron::Port`` Resource ID (defined in R-20453).
4763
4764
4765 Resource: OS::Nova::Server - Parameters > Property: Name
4766 --------------------------------------------------------
4767
4768
4769 Requirements Changed
4770 ~~~~~~~~~~~~~~~~~~~~
4771
4772
4773 .. container:: note
4774
4775     :need:`R-54171`
4776
4777     When the VNF's Heat Orchestration Template's Resource ``OS::Nova::Server``
4778     property ``name`` parameter is defined as a ``string``,
4779     the parameter name **MUST** follow the naming convention
4780
4781     * ``{vm-type}_name_{index}``
4782
4783     where ``{index}`` is a numeric value that **MUST** start at
4784     zero in a VNF's Heat Orchestration Template and **MUST** increment by one.
4785
4786
4787 Requirements Removed
4788 ~~~~~~~~~~~~~~~~~~~~
4789
4790
4791 .. container:: note
4792
4793     R-40899
4794
4795     When the VNF's Heat Orchestration Template's Resource ``OS::Nova::Server``
4796     property ``name`` parameter is defined as a ``string``, a parameter
4797     **MUST** be delcared for
4798     each ``OS::Nova::Server`` resource associated with the ``{vm-type}``.
4799
4800
4801 .. container:: note
4802
4803     R-85800
4804
4805     When the VNF's Heat Orchestration Template's Resource ``OS::Nova::Server``
4806     property ``name`` parameter is defined as a ``comma_delimited_list``,
4807     a parameter **MUST** be delcared once for all ``OS::Nova::Server`` resources
4808     associated with the ``{vm-type}``.
4809
4810
4811 Resource: OS::Nova::Server - Parameters > Property: availability_zone
4812 ---------------------------------------------------------------------
4813
4814
4815 Requirements Changed
4816 ~~~~~~~~~~~~~~~~~~~~
4817
4818
4819 .. container:: note
4820
4821     :need:`R-98450`
4822
4823     The VNF's Heat Orchestration Template's Resource ``OS::Nova::Server``
4824     property ``availability_zone`` parameter name
4825     **MUST** follow the naming convention
4826
4827     * ``availability_zone_{index}``
4828
4829     where ``{index}`` is a numeric value that **MUST** start at zero
4830     in a VNF's Heat Orchestration Templates and **MUST**
4831     increment by one.
4832
4833
4834 Resource: OS::Nova::Server Metadata Parameters > environment_context
4835 --------------------------------------------------------------------
4836
4837
4838 Requirements Removed
4839 ~~~~~~~~~~~~~~~~~~~~
4840
4841
4842 .. container:: note
4843
4844     R-62954
4845
4846     If a VNF's Heat Orchestration Template's ``OS::Nova::Server Resource``
4847     ``metadata`` map value parameter ``environment_context`` is passed into a
4848     Nested YAML
4849     file, the parameter name ``environment_context`` **MUST NOT** change.
4850
4851
4852 Resource: OS::Nova::Server Metadata Parameters > vf_module_id
4853 -------------------------------------------------------------
4854
4855
4856 Requirements Removed
4857 ~~~~~~~~~~~~~~~~~~~~
4858
4859
4860 .. container:: note
4861
4862     R-86237
4863
4864     If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
4865     property
4866     ``metadata`` key/value pair ``vf_module_id`` is passed into a
4867     Nested YAML
4868     file, the key/value pair name ``vf_module_id`` **MUST NOT** change.
4869
4870
4871 Resource: OS::Nova::Server Metadata Parameters > vf_module_index
4872 ----------------------------------------------------------------
4873
4874
4875 Requirements Added
4876 ~~~~~~~~~~~~~~~~~~
4877
4878
4879 .. container:: note
4880
4881     :need:`R-100410`
4882
4883     A VNF's Heat Orchestration Template's ``OS::Nova::Server``
4884     resource  property ``metadata`` **MAY**
4885     contain the key/value pair ``vf_module_index``.
4886
4887
4888 Requirements Changed
4889 ~~~~~~~~~~~~~~~~~~~~
4890
4891
4892 .. container:: note
4893
4894     :need:`R-50816`
4895
4896     A VNF's Heat Orchestration Template's ``OS::Nova::Server``
4897     resource  property ``metadata``
4898     key/value pair ``vf_module_index``
4899     value **MUST** be obtained via a ``get_param``.
4900
4901
4902 Requirements Removed
4903 ~~~~~~~~~~~~~~~~~~~~
4904
4905
4906 .. container:: note
4907
4908     R-22441
4909
4910     If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
4911     property ``metadata`` key/value pair ``vf_module_index`` is passed into a
4912     Nested YAML file, the key/value pair
4913     ``vf_module_index`` **MUST NOT** change.
4914
4915
4916 Resource: OS::Nova::Server Metadata Parameters > vf_module_name
4917 ---------------------------------------------------------------
4918
4919
4920 Requirements Added
4921 ~~~~~~~~~~~~~~~~~~
4922
4923
4924 .. container:: note
4925
4926     :need:`R-100400`
4927
4928     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
4929     property metadata **SHOULD** contain the key/value pair ``vf_module_name``.
4930
4931
4932 Requirements Changed
4933 ~~~~~~~~~~~~~~~~~~~~
4934
4935
4936 .. container:: note
4937
4938     :need:`R-68023`
4939
4940     A VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
4941     property ``metadata`` key/value pair ``vf_module_name``
4942     value **MUST**
4943     be obtained via a ``get_param``.
4944
4945
4946 Requirements Removed
4947 ~~~~~~~~~~~~~~~~~~~~
4948
4949
4950 .. container:: note
4951
4952     R-49177
4953
4954     If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
4955     property ``metadata`` key/value pair ``vf_module_name`` is passed into a
4956     Nested YAML
4957     file, the key/value pair name ``vf_module_name`` **MUST NOT** change.
4958
4959
4960 Resource: OS::Nova::Server Metadata Parameters > vm_role
4961 --------------------------------------------------------
4962
4963
4964 Requirements Changed
4965 ~~~~~~~~~~~~~~~~~~~~
4966
4967
4968 .. container:: note
4969
4970     :need:`R-95430`
4971
4972     If a VNF's Heat Orchestration Template's ``OS::Nova::Server``
4973     resource property
4974     ``metadata`` key/value pair ``vm_role`` value is obtained via
4975     ``get_param``, the parameter **MAY** be declared as
4976
4977     * ``vm_role`` and the parameter defined as ``type: string``.
4978     * ``vm_roles`` and the parameter defined as ``type: comma_delimited_list``.
4979     * ``{vm-type}_vm_role`` and the parameter defined as ``type: string``.
4980
4981
4982 Requirements Removed
4983 ~~~~~~~~~~~~~~~~~~~~
4984
4985
4986 .. container:: note
4987
4988     R-70757
4989
4990     If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
4991     property ``metadata`` key/value pair ``vm_role`` is passed into a Nested
4992     YAML
4993     file, the key/value pair name ``vm_role`` **MUST NOT** change.
4994
4995
4996 Resource: OS::Nova::Server Metadata Parameters > vnf_id
4997 -------------------------------------------------------
4998
4999
5000 Requirements Removed
5001 ~~~~~~~~~~~~~~~~~~~~
5002
5003
5004 .. container:: note
5005
5006     R-44491
5007
5008     If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
5009     property
5010     ``metadata`` key/value pair ``vnf_id`` is passed into a Nested YAML
5011     file, the key/value pair name ``vnf_id`` **MUST NOT** change.
5012
5013
5014 Resource: OS::Nova::Server Metadata Parameters > vnf_name
5015 ---------------------------------------------------------
5016
5017
5018 Requirements Removed
5019 ~~~~~~~~~~~~~~~~~~~~
5020
5021
5022 .. container:: note
5023
5024     R-16576
5025
5026     If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
5027     property
5028     ``metadata`` key/value pair ``vnf_name`` is passed into a Nested YAML
5029     file, the key/value pair name ``vnf_name`` **MUST NOT** change.
5030
5031
5032 Resource: OS::Nova::Server Metadata Parameters > workload_context
5033 -----------------------------------------------------------------
5034
5035
5036 Requirements Removed
5037 ~~~~~~~~~~~~~~~~~~~~
5038
5039
5040 .. container:: note
5041
5042     R-75202
5043
5044     If a VNF's Heat Orchestration Template's ``OS::Nova::Server`` resource
5045     property ``metadata`` key/value pair ``workload_context``
5046     is passed into a Nested YAML
5047     file, the key/value pair name ``workload_context`` **MUST NOT** change.
5048
5049
5050 VNF On-boarding and package management > Compute, Network, and Storage Requirements
5051 -----------------------------------------------------------------------------------
5052
5053
5054 Requirements Changed
5055 ~~~~~~~~~~~~~~~~~~~~
5056
5057
5058 .. container:: note
5059
5060     :need:`R-96634`
5061
5062     The VNF or PNF Provider **MUST** provide human readable documentation
5063     (not in the on-boarding package) to describe scaling capabilities to manage
5064     scaling characteristics of the VNF or PNF.
5065
5066
5067 .. container:: note
5068
5069     :need:`R-26881`
5070
5071     The VNF provider **MUST** provide the binaries and images
5072     needed to instantiate the VNF (VNF and VNFC images).
5073
5074
5075 .. container:: note
5076
5077     :need:`R-35851`
5078
5079     The VNF HEAT Package **MUST** include VNF topology that describes basic
5080     network and application connectivity internal and external to the VNF
5081     including Link type, KPIs, Bandwidth, latency, jitter, QoS (if applicable)
5082     for each interface.
5083
5084
5085 VNF On-boarding and package management > Licensing Requirements
5086 ---------------------------------------------------------------
5087
5088
5089 Requirements Changed
5090 ~~~~~~~~~~~~~~~~~~~~
5091
5092
5093 .. container:: note
5094
5095     :need:`R-44569`
5096
5097     The VNF or PNF provider **MUST NOT** require additional
5098     infrastructure such as a VNF or PNF provider license server for VNF or PNF provider
5099     functions and metrics.
5100
5101
5102 .. container:: note
5103
5104     :need:`R-40827`
5105
5106     The VNF or PNF provider **MUST** enumerate all of the open
5107     source licenses their VNF or PNF(s) incorporate.
5108
5109
5110 .. container:: note
5111
5112     :need:`R-44125`
5113
5114     The VNF or PNF provider **MUST** agree to the process that can
5115     be met by Service Provider reporting infrastructure. The Contract
5116     shall define the reporting process and the available reporting tools.
5117
5118
5119 .. container:: note
5120
5121     :need:`R-97293`
5122
5123     The VNF or PNF provider **MUST NOT** require audits
5124     of Service Provider's business.
5125
5126
5127 .. container:: note
5128
5129     :need:`R-85991`
5130
5131     The VNF or PNF provider **MUST** provide a universal license key
5132     per VNF or PNF to be used as needed by services (i.e., not tied to a VM
5133     instance) as the recommended solution. The VNF or PNF provider may provide
5134     pools of Unique VNF or PNF License Keys, where there is a unique key for
5135     each VNF or PNF instance as an alternate solution. Licensing issues should
5136     be resolved without interrupting in-service VNFs or PNFs.
5137
5138
5139 .. container:: note
5140
5141     :need:`R-47849`
5142
5143     The VNF or PNF provider **MUST** support the metadata about
5144     licenses (and their applicable entitlements) as defined in this
5145     specification for VNF or PNF software, and any license keys required to authorize
5146     use of the VNF or PNF software.  This metadata will be used to facilitate
5147     onboarding the VNF or PNF into the ONAP environment and automating processes
5148     for putting the licenses into use and managing the full lifecycle of
5149     the licenses. The details of this license model are described in
5150     Tables C1 to C8 in the Appendix.
5151
5152     Note: License metadata support in ONAP is not currently available
5153     and planned for 1Q 2018.
5154
5155
5156 .. container:: note
5157
5158     :need:`R-85653`
5159
5160     The VNF or PNF **MUST** provide metrics (e.g., number of sessions,
5161     number of subscribers, number of seats, etc.) to ONAP for tracking
5162     every license.
5163
5164
5165 VNF On-boarding and package management > Resource Configuration
5166 ---------------------------------------------------------------
5167
5168
5169 Requirements Changed
5170 ~~~~~~~~~~~~~~~~~~~~
5171
5172
5173 .. container:: note
5174
5175     :need:`R-89571`
5176
5177     The VNF or PNF **MUST** support and provide artifacts for configuration
5178     management using at least one of the following technologies;
5179     a) Netconf/YANG, b) Chef, or c) Ansible.
5180
5181     Note: The requirements for Netconf/YANG, Chef, and Ansible protocols
5182     are provided separately and must be supported only if the corresponding
5183     protocol option is provided by the VNF or PNF providor.
5184
5185
5186 VNF On-boarding and package management > Resource Configuration > Configuration Management via Ansible
5187 ------------------------------------------------------------------------------------------------------
5188
5189
5190 Requirements Changed
5191 ~~~~~~~~~~~~~~~~~~~~
5192
5193
5194 .. container:: note
5195
5196     :need:`R-75608`
5197
5198     The VNF or PNF provider **MUST** provide playbooks to be loaded
5199     on the appropriate Ansible Server.
5200
5201
5202 .. container:: note
5203
5204     :need:`R-16777`
5205
5206     The VNF or PNF provider **MUST** provide a JSON file for each
5207     supported action for the VNF or PNF. The JSON file must contain key value
5208     pairs with all relevant values populated with sample data that illustrates
5209     its usage. The fields and their description are defined in Table B1
5210     in the Appendix.
5211
5212
5213 .. container:: note
5214
5215     :need:`R-46567`
5216
5217     The VNF or PNF Package **MUST** include configuration scripts
5218     for boot sequence and configuration.
5219
5220
5221 .. container:: note
5222
5223     :need:`R-16065`
5224
5225     The VNF or PNF provider **MUST** provide configurable parameters
5226     (if unable to conform to YANG model) including VNF or PNF attributes/parameters
5227     and valid values, dynamic attributes and cross parameter dependencies
5228     (e.g., customer provisioning data).
5229
5230
5231 VNF On-boarding and package management > Resource Configuration > Configuration Management via Chef
5232 ---------------------------------------------------------------------------------------------------
5233
5234
5235 Requirements Changed
5236 ~~~~~~~~~~~~~~~~~~~~
5237
5238
5239 .. container:: note
5240
5241     :need:`R-18525`
5242
5243     The VNF or PNF provider **MUST** provide a JSON file for each
5244     supported action for the VNF or PNF. The JSON file must contain key value
5245     pairs with all relevant values populated with sample data that illustrates
5246     its usage. The fields and their description are defined in Tables A1
5247     and A2 in the Appendix.
5248
5249     Note: Chef support in ONAP is not currently available and planned for 4Q 2017.
5250
5251
5252 .. container:: note
5253
5254     :need:`R-13390`
5255
5256     The VNF or PNF provider **MUST** provide cookbooks to be loaded
5257     on the appropriate Chef Server.
5258
5259
5260 VNF On-boarding and package management > Resource Configuration > Configuration Management via NETCONF/YANG
5261 -----------------------------------------------------------------------------------------------------------
5262
5263
5264 Requirements Changed
5265 ~~~~~~~~~~~~~~~~~~~~
5266
5267
5268 .. container:: note
5269
5270     :need:`R-30278`
5271
5272     The VNF or PNF provider **SHOULD** provide a Resource/Device YANG model
5273     as a foundation for creating the YANG model for configuration.
5274
5275
5276 VNF On-boarding and package management > Resource Control Loop
5277 --------------------------------------------------------------
5278
5279
5280 Requirements Changed
5281 ~~~~~~~~~~~~~~~~~~~~
5282
5283
5284 .. container:: note
5285
5286     :need:`R-33904`
5287
5288     The VNF or PNF Package **MUST** include documentation for each KPI, provide
5289     lower and upper limits.
5290
5291
5292 .. container:: note
5293
5294     :need:`R-69877`
5295
5296     The VNF or PNF Package **MUST** include documentation for each KPI,
5297     identify the suggested actions that need to be performed when a
5298     threshold crossing alert event is recorded.
5299
5300
5301 .. container:: note
5302
5303     :need:`R-01556`
5304
5305     The VNF or PNF Documentation Package **MUST** describe the
5306     fault, performance, capacity events/alarms and other event records
5307     that are made available by the VNF or PNF.
5308
5309
5310 .. container:: note
5311
5312     :need:`R-16875`
5313
5314     The VNF or PNF Documentation Package **MUST** include documentation which must
5315     include a unique identification string for the specific VNF or PNF, a description
5316     of the problem that caused the error, and steps or procedures to perform
5317     Root Cause Analysis and resolve the issue.
5318
5319
5320 .. container:: note
5321
5322     :need:`R-22680`
5323
5324     The VNF or PNF Documentation Package **MUST** describe
5325     any requirements for the monitoring component of tools for Network
5326     Cloud automation and management to provide these records to components
5327     of the VNF or PNF.
5328
5329
5330 .. container:: note
5331
5332     :need:`R-33694`
5333
5334     The VNF or PNF Package **MUST** include documentation to when applicable,
5335     provide calculators needed to convert raw data into appropriate reporting
5336     artifacts.
5337
5338
5339 .. container:: note
5340
5341     :need:`R-86235`
5342
5343     The VNF or PNF Package **MUST** include documentation about the monitoring
5344     parameters that must include latencies, success rates, retry rates, load
5345     and quality (e.g., DPM) for the key transactions/functions supported by
5346     the VNF or PNF and those that must be exercised by the VNF or PNF in order to perform
5347     its function.
5348
5349
5350 .. container:: note
5351
5352     :need:`R-73560`
5353
5354     The VNF or PNF Package **MUST** include documentation about monitoring
5355     parameters/counters exposed for virtual resource management and VNF or PNF
5356     application management.
5357
5358
5359 .. container:: note
5360
5361     :need:`R-53598`
5362
5363     The VNF or PNF Documentation Package **MUST**, when relevant,
5364     provide a threshold crossing alert point for each KPI and describe the
5365     significance of the threshold crossing.
5366
5367
5368 .. container:: note
5369
5370     :need:`R-48596`
5371
5372     The VNF or PNF Documentation Package **MUST** describe
5373     the characteristics for the VNF or PNF reliability and high availability.
5374
5375
5376 .. container:: note
5377
5378     :need:`R-01478`
5379
5380     The VNF or PNF Documentation Package **MUST** describe all
5381     parameters that are available to monitor the VNF or PNF after instantiation
5382     (includes all counters, OIDs, PM data, KPIs, etc.) that must be
5383     collected for reporting purposes.
5384
5385
5386 .. container:: note
5387
5388     :need:`R-90632`
5389
5390     The VNF Package **MUST** include documentation about KPIs and
5391     metrics that need to be collected at each VM for capacity planning
5392     and performance management purposes.
5393
5394
5395 .. container:: note
5396
5397     :need:`R-22888`
5398
5399     The VNF or PNF Documentation Package **MUST** provide the VNF or PNF
5400     Policy Description to manage the VNF or PNF runtime lifecycle. The document
5401     must include a description of how the policies (conditions and actions)
5402     are implemented in the VNF or PNF.
5403
5404
5405 .. container:: note
5406
5407     :need:`R-42018`
5408
5409     The VNF or PNF Package **MUST** include documentation which must include
5410     all events (fault, measurement for VNF or PNF Scaling, Syslogs, State Change
5411     and Mobile Flow), that need to be collected at each VM, VNFC (defined in `VNF Guidelines <https://onap.readthedocs.io/en/latest/submodules/vnfrqts/guidelines.git/docs/vnf_guidelines.html>`__ ) and for the overall VNF or PNF.
5412
5413
5414 .. container:: note
5415
5416     :need:`R-35960`
5417
5418     The VNF or PNF Package **MUST** include documentation which must include
5419     all events, severity level (e.g., informational, warning, error) and
5420     descriptions including causes/fixes if applicable for the event.
5421
5422
5423 .. container:: note
5424
5425     :need:`R-56815`
5426
5427     The VNF or PNF Documentation Package **MUST** describe
5428     supported VNF or PNF scaling capabilities and capacity limits (e.g., number
5429     of users, bandwidth, throughput, concurrent calls).
5430
5431
5432 Requirements Removed
5433 ~~~~~~~~~~~~~~~~~~~~
5434
5435
5436 .. container:: note
5437
5438     R-27711
5439
5440     The xNF provider **MUST** provide an XML file that contains a
5441     list of xNF error codes, descriptions of the error, and possible
5442     causes/corrective action.
5443
5444
5445 .. container:: note
5446
5447     R-74763
5448
5449     The xNF provider **MUST** provide an artifact per xNF that contains
5450     all of the xNF Event Records supported. The artifact should include
5451     reference to the specific release of the xNF Event Stream Common Event
5452     Data Model document it is based on. (e.g.,
5453     `VES Event Listener <https://onap.readthedocs.io/en/latest/submodules/vnfsdk/model.git/docs/files/VESEventListener.html>`__)
5454
5455
5456 VNF On-boarding and package management > Resource Description
5457 -------------------------------------------------------------
5458
5459
5460 Requirements Added
5461 ~~~~~~~~~~~~~~~~~~
5462
5463
5464 .. container:: note
5465
5466     :need:`R-025941`
5467
5468     The VNF or PNF PROVIDER **MUST** provide FM Meta Data to support the
5469     analysis of fault events delivered to DCAE. The Meta Data must be
5470     included in the VES Registration YAML file with each fault event
5471     supported by that NF at onboarding time and the Meta Data must follow
5472     the VES Event Listener and VES Event Registration Specifications.
5473
5474
5475 .. container:: note
5476
5477     :need:`R-816745`
5478
5479     The VNF or PNF PROVIDER *MUST* provide the Service Provider with
5480     PM Meta Data (PM Dictionary) to support the analysis of PM events delivered
5481     to DCAE. The PM Dictionary is to be provided as a separate YAML artifact at
5482     onboarding and must follow the VES Event Listener Specification and VES
5483     Event Registration Specification which contain the format and content
5484     required.
5485
5486
5487 Requirements Changed
5488 ~~~~~~~~~~~~~~~~~~~~
5489
5490
5491 .. container:: note
5492
5493     :need:`R-98617`
5494
5495     The VNF Provider **MUST** provide documentation regarding any dependency
5496     (e.g. affinity, anti-affinity) the VNF has on other VNFs and resources.
5497
5498
5499 .. container:: note
5500
5501     :need:`R-36280`
5502
5503     The VNF or PNF Documentation Package **MUST** describe the
5504     VNF or PNF Functional Capabilities that are utilized to operationalize the
5505     VNF or PNF and compose complex services.
5506
5507
5508 .. container:: note
5509
5510     :need:`R-00068`
5511
5512     The VNF or PNF Documentation Package **MUST** include
5513     a description of parameters that can be monitored for the VNF or PNF
5514     and event records (status, fault, flow, session, call, control
5515     plane, etc.) generated by the VNF or PNF after instantiation.
5516
5517
5518 .. container:: note
5519
5520     :need:`R-69565`
5521
5522     The VNF or PNF Documentation Package **MUST** describe the VNF or PNF
5523     Management APIs, which must include information and tools for ONAP to
5524     deploy and configure (initially and ongoing) the VNF or PNF application(s)
5525     (e.g., NETCONF APIs) which includes a description of configurable
5526     parameters for the VNF or PNF and whether the parameters can be configured
5527     after VNF or PNF instantiation.
5528
5529
5530 .. container:: note
5531
5532     :need:`R-22346`
5533
5534     The VNF or PNF package **MUST** provide :ref:`VES Event Registration <ves_event_registration_3_2>`
5535     for all VES events provided by that VNF or PNF.
5536
5537
5538 .. container:: note
5539
5540     :need:`R-384337`
5541
5542     The VNF Documentation Package **MUST** contain a list of the files within the VNF
5543     package that are static during the VNF's runtime.
5544
5545
5546 .. container:: note
5547
5548     :need:`R-84366`
5549
5550     The VNF or PNF Documentation Package **MUST** describe the
5551     VNF or PNF Functional APIs that are utilized to build network and
5552     application services. This document describes the externally exposed
5553     functional inputs and outputs for the VNF or PNF, including interface
5554     format and protocols supported.
5555
5556
5557 .. container:: note
5558
5559     :need:`R-00156`
5560
5561     The VNF or PNF Documentation Package **MUST** describe the VNF or PNF
5562     Management APIs, which must include information and tools for
5563     ONAP to monitor the health of the VNF or PNF (conditions that require
5564     healing and/or scaling responses).
5565
5566
5567 .. container:: note
5568
5569     :need:`R-12678`
5570
5571     The VNF or PNF Documentation Package **MUST** include a
5572     description of runtime lifecycle events and related actions (e.g.,
5573     control responses, tests) which can be performed for the VNF or PNF.
5574
5575
5576 .. container:: note
5577
5578     :need:`R-66070`
5579
5580     For HEAT package, the VNF Package **MUST** include VNF Identification Data to
5581     uniquely identify the resource for a given VNF provider. The identification
5582     data must include: an identifier for the VNF, the name of the VNF as was
5583     given by the VNF provider, VNF description, VNF provider, and version.
5584
5585
5586 Requirements Removed
5587 ~~~~~~~~~~~~~~~~~~~~
5588
5589
5590 .. container:: note
5591
5592     R-77707
5593
5594     The xNF provider **MUST** include a Manifest File that
5595     contains a list of all the components in the xNF package.
5596
5597
5598 VNF On-boarding and package management > Testing
5599 ------------------------------------------------
5600
5601
5602 Requirements Changed
5603 ~~~~~~~~~~~~~~~~~~~~
5604
5605
5606 .. container:: note
5607
5608     :need:`R-58775`
5609
5610     The VNF provider **MUST** provide software components that
5611     can be packaged with/near the VNF, if needed, to simulate any functions
5612     or systems that connect to the VNF system under test. This component is
5613     necessary only if the existing testing environment does not have the
5614     necessary simulators.
5615
5616
5617 .. container:: note
5618
5619     :need:`R-43958`
5620
5621     The VNF Documentation Package **MUST** describe
5622     the tests that were conducted by the VNF provider and the test results.
5623
5624
5625 .. container:: note
5626
5627     :need:`R-04298`
5628
5629     The VNF provider **MUST** provide their testing scripts to
5630     support testing.
5631
5632
5633 VNF Resiliency > Monitoring & Dashboard
5634 ---------------------------------------
5635
5636
5637 Requirements Changed
5638 ~~~~~~~~~~~~~~~~~~~~
5639
5640
5641 .. container:: note
5642
5643     :need:`R-34957`
5644
5645     The VNF **MUST** provide a method of metrics gathering for each
5646     layer's performance to identify variances in the allocations so
5647     they can be addressed.
5648
5649
5650 {network-role}
5651 --------------
5652
5653
5654 Requirements Changed
5655 ~~~~~~~~~~~~~~~~~~~~
5656
5657
5658 .. container:: note
5659
5660     :need:`R-05201`
5661
5662     When a VNF connects to two or more unique networks, each
5663     network **MUST** be assigned a unique ``{network-role}``
5664     in the context of the VNF for use in the VNF's Heat Orchestration
5665     Template.
5666
5667
5668 .. container:: note
5669
5670     :need:`R-69014`
5671
5672     When a VNF's port connects to an internal network or external network,
5673     a network role, referred to
5674     as the ``{network-role}`` **MUST** be assigned to the network for
5675     use in the VNF's Heat Orchestration Template.  The ``{network-role}``
5676     is used in the VNF's Heat Orchestration Template resource IDs
5677     and resource property parameter names.
5678
5679
5680 .. container:: note
5681
5682     :need:`R-26506`
5683
5684     A VNF's Heat Orchestration Template's ``{network-role}`` **MUST** contain
5685     only alphanumeric characters and/or underscores '_' and
5686
5687     * **MUST NOT** contain any of the following strings: ``_int`` or ``int_``
5688       or ``_int_``
5689     * **MUST NOT** end in the string: ``_v6``
5690     * **MUST NOT** contain the strings ``_#_``,  where ``#`` is a number
5691     * **MUST NOT** end in the string: ``_#``, where ``#`` is a number
5692
5693
5694 {vm-type}
5695 ---------
5696
5697
5698 Requirements Changed
5699 ~~~~~~~~~~~~~~~~~~~~
5700
5701
5702 .. container:: note
5703
5704     :need:`R-01455`
5705
5706     When a VNF's Heat Orchestration Template creates a Virtual Machine
5707     (i.e., ``OS::Nova::Server``),
5708     each "class" of VMs **MUST** be assigned a VNF unique
5709     ``{vm-type}``; where "class" defines VMs that
5710     **MUST** have the following identical characteristics:
5711
5712       1.) ``OS::Nova::Server`` resource property ``flavor`` value
5713
5714       2.) ``OS::Nova::Server`` resource property ``image`` value
5715
5716       3.) Cinder Volume attachments
5717
5718         - Each VM in the "class" **MUST** have the identical Cinder Volume
5719           configuration
5720
5721       4.) Network attachments and IP address requirements
5722
5723         - Each VM in the "class" **MUST** have the identical number of
5724           ports connecting to the identical networks and requiring the identical
5725           IP address configuration.
5726
5727
5728 Requirements Removed
5729 ~~~~~~~~~~~~~~~~~~~~
5730
5731
5732 .. container:: note
5733
5734     R-66729
5735
5736     A VNF's Heat Orchestration Template's Resource that is associated with a
5737     unique Virtual Machine type **MUST** include ``{vm-type}`` as part of the
5738     resource ID.
5739
5740
5741 .. container:: note
5742
5743     R-82481
5744
5745     A VNF's Heat Orchestration Template's Resource property parameter that is
5746     associated with a unique Virtual Machine type **MUST** include
5747     ``{vm-type}`` as part of the parameter name with two exceptions:
5748
5749      1.) The Resource ``OS::Nova::Server`` property ``availability_zone``
5750      parameter **MUST NOT** be prefixed with a common ``{vm-type}`` identifier,
5751
5752      2.) The Resource ``OS::Nova::Server`` eight mandatory and optional
5753      ``metadata``
5754      parameters (i.e., ``vnf_name``, ``vnf_id``, ``vf_module_id``,
5755      ``vf_module_name``, ``vm_role``,
5756      ``vf_module_index``, ``environment_context``, ``workload_context``)
5757      **MUST NOT** be prefixed with a common ``{vm-type}`` identifier.
5758