docs/Chapter4/Design.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. http://creativecommons.org/licenses/by/4.0
   3 .. Copyright 2017 AT&T Intellectual Property.  All rights reserved.
   4
   5 VNF Design
   6 ----------
   7
   8 Services are composed of VNFs and common components and are designed to
   9 be agnostic of the location to leverage capacity where it exists in the
  10 Network Cloud. VNFs can be instantiated in any location that meets the
  11 performance and latency requirements of the service.
  12
  13 A key design principle for virtualizing services is decomposition of
  14 network functions using NFV concepts into granular VNFs. This enables
  15 instantiating and customizing only essential functions as needed for the
  16 service, thereby making service delivery more nimble. It provides
  17 flexibility of sizing and scaling and also provides flexibility with
  18 packaging and deploying VNFs as needed for the service. It enables
  19 grouping functions in a common cloud data center to minimize
  20 inter-component latency. The VNFs should be designed with a goal of
  21 being modular and reusable to enable using best-in-breed vendors.
  22
  23 Section 4.1 VNF Design in *VNF Guidelines* describes
  24 the overall guidelines for designing VNFs from VNF Components (VNFCs).
  25 Below are more detailed requirements for composing VNFs.
  26
  27 VNF Design Requirements
  28
  29
  30 .. req::
  31     :id: R-58421
  32     :target: VNF
  33     :keyword: SHOULD
  34
  35     The VNF **SHOULD** be decomposed into granular re-usable VNFCs.
  36
  37 .. req::
  38     :id: R-82223
  39     :target: VNF
  40     :keyword: MUST
  41
  42     The VNF **MUST** be decomposed if the functions have
  43     significantly different scaling characteristics (e.g., signaling
  44     versus media functions, control versus data plane functions).
  45
  46 .. req::
  47     :id: R-16496
  48     :target: VNF
  49     :keyword: MUST
  50
  51     The VNF **MUST** enable instantiating only the functionality that
  52     is needed for the decomposed VNF (e.g., if transcoding is not needed it
  53     should not be instantiated).
  54
  55 .. req::
  56     :id: R-02360
  57     :target: VNF
  58     :keyword: MUST
  59
  60     The VNFC **MUST** be designed as a standalone, executable process.
  61
  62 .. req::
  63     :id: R-34484
  64     :target: VNF
  65     :keyword: SHOULD
  66
  67     The VNF **SHOULD** create a single component VNF for VNFCs
  68     that can be used by other VNFs.
  69
  70 .. req::
  71     :id: R-23035
  72     :target: VNF
  73     :keyword: MUST
  74
  75     The VNF **MUST** be designed to scale horizontally (more
  76     instances of a VNF or VNFC) and not vertically (moving the existing
  77     instances to larger VMs or increasing the resources within a VM)
  78     to achieve effective utilization of cloud resources.
  79
  80 .. req::
  81     :id: R-30650
  82     :target: VNF
  83     :keyword: MUST
  84
  85     The VNF **MUST** utilize cloud provided infrastructure and
  86     VNFs (e.g., virtualized Local Load Balancer) as part of the VNF so
  87     that the cloud can manage and provide a consistent service resiliency
  88     and methods across all VNF's.
  89
  90 .. req::
  91     :id: R-12709
  92     :target: VNF
  93     :keyword: SHOULD
  94
  95     The VNFC **SHOULD** be independently deployed, configured,
  96     upgraded, scaled, monitored, and administered by ONAP.
  97
  98 .. req::
  99     :id: R-37692
 100     :target: VNF
 101     :keyword: MUST
 102
 103     The VNFC **MUST** provide API versioning to allow for
 104     independent upgrades of VNFC.
 105
 106 .. req::
 107     :id: R-86585
 108     :target: VNF
 109     :keyword: SHOULD
 110
 111     The VNFC **SHOULD** minimize the use of state within
 112     a VNFC to facilitate the movement of traffic from one instance
 113     to another.
 114
 115 .. req::
 116     :id: R-65134
 117     :target: VNF
 118     :keyword: SHOULD
 119
 120     The VNF **SHOULD** maintain state in a geographically
 121     redundant datastore that may, in fact, be its own VNFC.
 122
 123 .. req::
 124     :id: R-75850
 125     :target: VNF
 126     :keyword: SHOULD
 127
 128     The VNF **SHOULD** decouple persistent data from the VNFC
 129     and keep it in its own datastore that can be reached by all instances
 130     of the VNFC requiring the data.
 131
 132 .. req::
 133     :id: R-88199
 134     :target: VNF
 135     :keyword: MUST
 136
 137     The VNF **MUST** utilize a persistent datastore service that
 138     can meet the data performance/latency requirements. (For example:
 139     Datastore service could be a VNFC in VNF or a DBaaS in the Cloud
 140     execution environment)
 141
 142 .. req::
 143     :id: R-99656
 144     :target: VNF
 145     :keyword: MUST
 146
 147     The VNF **MUST** NOT terminate stable sessions if a VNFC
 148     instance fails.
 149
 150 .. req::
 151     :id: R-84473
 152     :target: VNF
 153     :keyword: MUST
 154
 155     The VNF **MUST** enable DPDK in the guest OS for VNF's requiring
 156     high packets/sec performance. High packet throughput is defined as greater
 157     than 500K packets/sec.
 158
 159 .. req::
 160     :id: R-54430
 161     :target: VNF
 162     :keyword: MUST
 163
 164     The VNF **MUST** use the NCSP's supported library and compute
 165     flavor that supports DPDK to optimize network efficiency if using DPDK. [1]_
 166
 167 .. req::
 168     :id: R-18864
 169     :target: VNF
 170     :keyword: MUST NOT
 171
 172     The VNF **MUST NOT** use technologies that bypass virtualization
 173     layers (such as SR-IOV) unless approved by the NCSP (e.g., if necessary
 174     to meet functional or performance requirements).
 175
 176 .. req::
 177     :id: R-64768
 178     :target: VNF
 179     :keyword: MUST
 180
 181     The VNF **MUST** limit the size of application data packets
 182     to no larger than 9000 bytes for SDN network-based tunneling when
 183     guest data packets are transported between tunnel endpoints that
 184     support guest logical networks.
 185
 186 .. req::
 187     :id: R-74481
 188     :target: VNF
 189     :keyword: MUST NOT
 190
 191     The VNF **MUST NOT** require the use of a dynamic routing
 192     protocol unless necessary to meet functional requirements.
 193
 194 .. [1]
 195    Refer to NCSP’s Network Cloud specification
 196