docs/Chapter3/index.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 Introduction
  17 ============
  18
  19 - Requirements are identified as either MUST, MUST NOT, SHOULD, SHOULD NOT,
  20   or MAY as defined in RFC 2119.
  21 - Requirements should be targeted to a restricted set of nouns related
  22   to VNFs and within the control of the VNF provider. The current list
  23   of VNF Requirement targets is:
  24
  25 +---------------------+-------------------------------------------------------+
  26 | Target              | When is it used                                       |
  27 +=====================+=======================================================+
  28 | VNF                 | Functional behavior of a VNF                          |
  29 +---------------------+-------------------------------------------------------+
  30 | PNF                 | Functional behavior of a PNF                          |
  31 +---------------------+-------------------------------------------------------+
  32 | VNF or PNF          | Function behavior to both VNFs and PNFs               |
  33 +---------------------+-------------------------------------------------------+
  34 | {VNF|PNF|VNF or PNF}| Something the provider of the VNF, PNF, or VNF/PNF    |
  35 | PROVIDER            | must do. This is often used to describe delivering    |
  36 |                     | artifacts or specific documentation that may not be   |
  37 |                     | part of a standard VNF package format.                |
  38 +---------------------+-------------------------------------------------------+
  39 | VNF HEAT PACKAGE    | The archive/zip file that includes Heat templates. The|
  40 |                     | subject of the requirement my be further refined (Ex: |
  41 |                     | Heat Environment File), but the metadata stay at the  |
  42 |                     | package level.                                        |
  43 +---------------------+-------------------------------------------------------+
  44 | {VNF|PNF|VNF or PNF}| A requirement related to the contents of what should  |
  45 | CSAR PACKAGE        | be in the CSAR package. The subject of the requirement|
  46 |                     | might be further refined (ex: CSAR manifest file, VNF |
  47 |                     | Descriptor, etc.), but the :target: metadata would    |
  48 |                     | stay at the package level.                            |
  49 +---------------------+-------------------------------------------------------+
  50 | {VNF|PNF|VNF or PNF}| VNFs and PNFs are expected to provide human readable  |
  51 | DOCUMENTATION       | documentation. This may come in the form of URLs or   |
  52 | PACKAGE             | pdfs. This documentation may vary by VNF or PNF.      |
  53 |                     | The structure of the documentation is intended for    |
  54 |                     | human consumption and is not highly structured for    |
  55 |                     | machine ingestion. The human readable documentation   |
  56 |                     | may be provided through the RFP/acquisition process.  |
  57 +---------------------+-------------------------------------------------------+
  58
  59 - Chapter 4 contains the xNF requirements involving the design and
  60   development of xNFs. These requirements help VNFs/PNFs operate
  61   efficiently within a cloud environment. Requirements cover design,
  62   resiliency, security, modularity and DevOps.
  63 - Chapter 5 describes the different data models the xNF provider
  64   needs to understand.  There are currently 2 models described in this
  65   document:
  66
  67     - The first model is the onboarding package data model. This is a TOSCA
  68       model that will describe how all the elements passed from the VNF/PNF
  69       Provider to the Service provider should be formatted and packaged.
  70     - The second model is HEAT template used for orchestrating and
  71       instantiating virtual resources in an OpenStack environment.  At this
  72       time the HEAT files will be passed to the Service provider as a data
  73       element within the TOSCA onboarding package.
  74
  75 - Chapter 6 details the requirements specific to an implementation.
  76   The current implementations documented are OpenStack and Azure.
  77 - Chapter 7 provides the comprehensive set of requirements for xNFs to
  78   be on-boarded, configured and managed by ONAP.
  79 - Chapter 8 is the appendix that provide a number of detailed data record
  80   formats. It also contains a list of the requirements that are listed
  81   in the other chapters as well as examples and models that are referenced
  82   throughout the rest of the chapters.