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