docs/Chapter7/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 ONAP Management Requirements
  17 ============================
  18
  19 .. toctree::
  20     :maxdepth: 2
  21
  22     Service-Design
  23     VNF-On-boarding-and-package-management
  24     Configuration-Management
  25     Monitoring-And-Management
  26     PNF-Plug-and-Play
  27
  28
  29 The ONAP platform is the part of the larger Network Function
  30 Virtualization/Software Defined Network (NFV/SDN) ecosystem that
  31 is responsible for the efficient control, operation and management
  32 of Virtual Network Function (VNF) capabilities and functions. It
  33 specifies standardized abstractions and interfaces that enable
  34 efficient interoperation of the NVF/SDN ecosystem components. It
  35 enables product/service independent capabilities for design, creation
  36 and runtime lifecycle management (includes all aspects of installation,
  37 change management, assurance, and retirement) of resources in NFV/SDN
  38 environment (see ECOMP white paper ). These capabilities are provided
  39 using two major architectural frameworks: (1) a Design Time Framework
  40 to design, define and program the platform (uniform onboarding), and
  41 (2) a Runtime Execution Framework to execute the logic programmed in
  42 the design environment (uniform delivery and runtime lifecycle
  43 management). The platform delivers an integrated information model
  44 based on the VNF package to express the characteristics and behavior
  45 of these resources in the Design Time Framework. The information model
  46 is utilized by Runtime Execution Framework to manage the runtime
  47 lifecycle of the VNFs. The management processes are orchestrated
  48 across various modules of ONAP to instantiate, configure, scale,
  49 monitor, and reconfigure the VNFs using a set of standard APIs
  50 provided by the VNF developers.
  51
  52 Although the guidelines and requirements specified in this document
  53 were originally driven by the need to standardize and automate the
  54 management of the virtualized environments (with VNFs) operated by
  55 Service Providers, we believe that most of the requirements are equally
  56 applicable to the operation of the physical network functions (PNFs),
  57 those network functions provided by traditional physical network
  58 elements (e.g. whitebox switches) or customized peripherals (e.g. a
  59 video rendering engine for augmented reality). The primary area of
  60 difference will be in how the network function is orchestrated into
  61 place – VNFs can be much more dynamically created & placed by ONAP
  62 to support varying geographic, availability and scalability needs,
  63 whereas the PNFs have to be deployed a priori in specific locations
  64 based on planning and engineering – their availability and scalability
  65 will be determined by the capabilities offered by the PNFs.
  66
  67 **PNF** is a vendor-provided Network Function(s) implemented using a
  68 bundled set of hardware and software while VNFs utilize cloud resources
  69 to provide Network Functions through virtualized software modules.  PNF
  70 can be supplied by a vendor as a Black BOX (provides no knowledge of its
  71 internal characteristics, logic, and software design/architecture) or as
  72 a White Box (provides detailed knowledge and access of its internal
  73 components and logic) or as a Grey Box (provides limited knowledge and
  74 access to its internal components).
  75
  76 * Requirements that equally apply to both VNFs and PNFs are defined as
  77   "The xNF MUST/SHOULD/..."
  78 * Requirements that only apply to VNFs are defined as "The VNF MUST/SHOULD/..."
  79 * Requirements that only apply to PNFs are defined as "The PNF MUST/SHOULD/..."