summaryrefslogtreecommitdiffstats
path: root/docs/Chapter4
diff options
context:
space:
mode:
authorBozawglanian, Hagop (hb755d) <hb755d@att.com>2018-07-17 18:24:46 +0000
committerBozawglanian, Hagop (hb755d) <hb755d@att.com>2018-07-17 18:28:56 +0000
commit0294677e9afcf9cc2dc24c69575cea5201d9efcb (patch)
tree19e52d4fefc237f67ac88dddd305fa146bfa8661 /docs/Chapter4
parent08d21cd6dbf52cd968282e4548508fcbe63b5412 (diff)
VNFRQTS - Testing Chapter 4 with new directive
Test push to see if the new directive introduced will build properly. Change-Id: I5a582351e728ad8ff99b4d0d99b4647b6def8e9d Issue-ID: VNFRQTS-236 Signed-off-by: Bozawglanian, Hagop (hb755d) <hb755d@att.com>
Diffstat (limited to 'docs/Chapter4')
-rw-r--r--docs/Chapter4/Design.rst214
1 files changed, 164 insertions, 50 deletions
diff --git a/docs/Chapter4/Design.rst b/docs/Chapter4/Design.rst
index e9003e6..35acd65 100644
--- a/docs/Chapter4/Design.rst
+++ b/docs/Chapter4/Design.rst
@@ -26,57 +26,171 @@ Below are more detailed requirements for composing VNFs.
VNF Design Requirements
-* R-58421 The VNF **SHOULD** be decomposed into granular re-usable VNFCs.
-* R-82223 The VNF **MUST** be decomposed if the functions have
- significantly different scaling characteristics (e.g., signaling
- versus media functions, control versus data plane functions).
-* R-16496 The VNF **MUST** enable instantiating only the functionality that
- is needed for the decomposed VNF (e.g., if transcoding is not needed it
- should not be instantiated).
-* R-02360 The VNFC **MUST** be designed as a standalone, executable process.
-* R-34484 The VNF **SHOULD** create a single component VNF for VNFCs
- that can be used by other VNFs.
-* R-23035 The VNF **MUST** be designed to scale horizontally (more
- instances of a VNF or VNFC) and not vertically (moving the existing
- instances to larger VMs or increasing the resources within a VM)
- to achieve effective utilization of cloud resources.
-* R-30650 The VNF **MUST** utilize cloud provided infrastructure and
- VNFs (e.g., virtualized Local Load Balancer) as part of the VNF so
- that the cloud can manage and provide a consistent service resiliency
- and methods across all VNF's.
-* R-12709 The VNFC **SHOULD** be independently deployed, configured,
- upgraded, scaled, monitored, and administered by ONAP.
-* R-37692 The VNFC **MUST** provide API versioning to allow for
- independent upgrades of VNFC.
-* R-86585 The VNFC **SHOULD** minimize the use of state within
- a VNFC to facilitate the movement of traffic from one instance
- to another.
-* R-65134 The VNF **SHOULD** maintain state in a geographically
- redundant datastore that may, in fact, be its own VNFC.
-* R-75850 The VNF **SHOULD** decouple persistent data from the VNFC
- and keep it in its own datastore that can be reached by all instances
- of the VNFC requiring the data.
-* R-88199 The VNF **MUST** utilize a persistent datastore service that
- can meet the data performance/latency requirements. (For example:
- Datastore service could be a VNFC in VNF or a DBaaS in the Cloud
- execution environment)
-* R-99656 The VNF **MUST** NOT terminate stable sessions if a VNFC
- instance fails.
-* R-84473 The VNF **MUST** enable DPDK in the guest OS for VNF’s requiring
- high packets/sec performance. High packet throughput is defined as greater
- than 500K packets/sec.
-* R-54430 The VNF **MUST** use the NCSP’s supported library and compute
- flavor that supports DPDK to optimize network efficiency if using DPDK. [1]_
-* R-18864 The VNF **MUST** NOT use technologies that bypass virtualization
- layers (such as SR-IOV) unless approved by the NCSP (e.g., if necessary
- to meet functional or performance requirements).
-* R-64768 The VNF **MUST** limit the size of application data packets
- to no larger than 9000 bytes for SDN network-based tunneling when
- guest data packets are transported between tunnel endpoints that
- support guest logical networks.
-* R-74481 The VNF **MUST** NOT require the use of a dynamic routing
- protocol unless necessary to meet functional requirements.
+.. req::
+ :id: R-58421
+ :target: VNF
+ :keyword: SHOULD
+
+ The VNF **SHOULD** be decomposed into granular re-usable VNFCs.
+
+.. req::
+ :id: R-82223
+ :target: VNF
+ :keyword: MUST
+
+ The VNF **MUST** be decomposed if the functions have
+ significantly different scaling characteristics (e.g., signaling
+ versus media functions, control versus data plane functions).
+
+.. req::
+ :id: R-16496
+ :target: VNF
+ :keyword: MUST
+
+ The VNF **MUST** enable instantiating only the functionality that
+ is needed for the decomposed VNF (e.g., if transcoding is not needed it
+ should not be instantiated).
+
+.. req::
+ :id: R-02360
+ :target: VNF
+ :keyword: MUST
+
+ The VNFC **MUST** be designed as a standalone, executable process.
+
+.. req::
+ :id: R-34484
+ :target: VNF
+ :keyword: SHOULD
+
+ The VNF **SHOULD** create a single component VNF for VNFCs
+ that can be used by other VNFs.
+
+.. req::
+ :id: R-23035
+ :target: VNF
+ :keyword: MUST
+
+ The VNF **MUST** be designed to scale horizontally (more
+ instances of a VNF or VNFC) and not vertically (moving the existing
+ instances to larger VMs or increasing the resources within a VM)
+ to achieve effective utilization of cloud resources.
+
+.. req::
+ :id: R-30650
+ :target: VNF
+ :keyword: MUST
+
+ The VNF **MUST** utilize cloud provided infrastructure and
+ VNFs (e.g., virtualized Local Load Balancer) as part of the VNF so
+ that the cloud can manage and provide a consistent service resiliency
+ and methods across all VNF's.
+
+.. req::
+ :id: R-12709
+ :target: VNF
+ :keyword: SHOULD
+
+ The VNFC **SHOULD** be independently deployed, configured,
+ upgraded, scaled, monitored, and administered by ONAP.
+
+.. req::
+ :id: R-37692
+ :target: VNF
+ :keyword: MUST
+
+ The VNFC **MUST** provide API versioning to allow for
+ independent upgrades of VNFC.
+
+.. req::
+ :id: R-86585
+ :target: VNF
+ :keyword: SHOULD
+
+ The VNFC **SHOULD** minimize the use of state within
+ a VNFC to facilitate the movement of traffic from one instance
+ to another.
+
+.. req::
+ :id: R-65134
+ :target: VNF
+ :keyword: SHOULD
+
+ The VNF **SHOULD** maintain state in a geographically
+ redundant datastore that may, in fact, be its own VNFC.
+
+.. req::
+ :id: R-75850
+ :target: VNF
+ :keyword: SHOULD
+
+ The VNF **SHOULD** decouple persistent data from the VNFC
+ and keep it in its own datastore that can be reached by all instances
+ of the VNFC requiring the data.
+
+.. req::
+ :id: R-88199
+ :target: VNF
+ :keyword: MUST
+
+ The VNF **MUST** utilize a persistent datastore service that
+ can meet the data performance/latency requirements. (For example:
+ Datastore service could be a VNFC in VNF or a DBaaS in the Cloud
+ execution environment)
+
+.. req::
+ :id: R-99656
+ :target: VNF
+ :keyword: MUST
+
+ The VNF **MUST** NOT terminate stable sessions if a VNFC
+ instance fails.
+
+.. req::
+ :id: R-84473
+ :target: VNF
+ :keyword: MUST
+
+ The VNF **MUST** enable DPDK in the guest OS for VNF's requiring
+ high packets/sec performance. High packet throughput is defined as greater
+ than 500K packets/sec.
+
+.. req::
+ :id: R-54430
+ :target: VNF
+ :keyword: MUST
+
+ The VNF **MUST** use the NCSP's supported library and compute
+ flavor that supports DPDK to optimize network efficiency if using DPDK. [1]_
+
+.. req::
+ :id: R-18864
+ :target: VNF
+ :keyword: MUST NOT
+
+ The VNF **MUST NOT** use technologies that bypass virtualization
+ layers (such as SR-IOV) unless approved by the NCSP (e.g., if necessary
+ to meet functional or performance requirements).
+
+.. req::
+ :id: R-64768
+ :target: VNF
+ :keyword: MUST
+
+ The VNF **MUST** limit the size of application data packets
+ to no larger than 9000 bytes for SDN network-based tunneling when
+ guest data packets are transported between tunnel endpoints that
+ support guest logical networks.
+
+.. req::
+ :id: R-74481
+ :target: VNF
+ :keyword: MUST NOT
+
+ The VNF **MUST NOT** require the use of a dynamic routing
+ protocol unless necessary to meet functional requirements.
.. [1]
Refer to NCSP’s Network Cloud specification
+