diff options
| -rw-r--r-- | requirements/02-use_cases.rst | 34 | ||||
| -rw-r--r-- | requirements/03-architecture.rst | 6 | ||||
| -rw-r--r-- | requirements/05-implementation.rst | 8 |
3 files changed, 27 insertions, 21 deletions
diff --git a/requirements/02-use_cases.rst b/requirements/02-use_cases.rst index 0a119521..f69151df 100644 --- a/requirements/02-use_cases.rst +++ b/requirements/02-use_cases.rst @@ -43,6 +43,8 @@ operation. Faults ------ +.. _uc-fault1: + Fault management using ACT-STBY configuration ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ @@ -115,22 +117,22 @@ ACT-STBY case), or if more active instances are needed as well. Preventive actions based on fault prediction ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The fault management scenario explained in Clause 2.1.1 can also be performed -based on fault prediction. In such cases, in VIM, there is an intelligent fault -prediction module which, based on its NFVI monitoring information, can predict -an imminent fault in the elements of NFVI. A simple example is raising -temperature of a Hardware Server which might trigger a pre-emptive recovery -action. The requirements of such fault prediction in the VIM are investigated in -the OPNFV project "Data Collection for Failure Prediction" [PRED]_. - -This use case is very similar to "Fault management using ACT-STBY configuration" -in Clause 2.1.1. Instead of a fault detection (Step 1 "Fault Notification in" -:num:`Figure #figure1`), the trigger comes from a fault prediction module in the -VIM, or from a third party module which notifies the VIM about an imminent -fault. From Step 2~5, the work flow is the same as in the "Fault management -using ACT-STBY configuration" use case, except in this case, the Consumer of a -VM/VNF switches to STBY configuration based on a predicted fault, rather than an -occurred fault. +The fault management scenario explained in :ref:`uc-fault1` can also be +performed based on fault prediction. In such cases, in VIM, there is an +intelligent fault prediction module which, based on its NFVI monitoring +information, can predict an imminent fault in the elements of NFVI. +A simple example is raising temperature of a Hardware Server which might +trigger a pre-emptive recovery action. The requirements of such fault +prediction in the VIM are investigated in the OPNFV project "Data Collection +for Failure Prediction" [PRED]_. + +This use case is very similar to :ref:`uc-fault1`. Instead of a fault +detection (Step 1 "Fault Notification in" :num:`Figure #figure1`), the trigger +comes from a fault prediction module in the VIM, or from a third party module +which notifies the VIM about an imminent fault. From Step 2~5, the work flow is +the same as in the "Fault management using ACT-STBY configuration" use case, +except in this case, the Consumer of a VM/VNF switches to STBY configuration +based on a predicted fault, rather than an occurred fault. NVFI Maintenance ---------------- diff --git a/requirements/03-architecture.rst b/requirements/03-architecture.rst index 984f254e..82a13f06 100644 --- a/requirements/03-architecture.rst +++ b/requirements/03-architecture.rst @@ -185,9 +185,9 @@ https://wiki.openstack.org/wiki/Fencing_Instances_of_an_Unreachable_Host . Recovery Action ^^^^^^^^^^^^^^^ -In the basic "Fault management using ACT-STBY configuration" use case, no -automatic actions will be taken by the VIM, but all recovery actions executed by -the VIM and the NFVI will be instructed and coordinated by the Consumer. +In the basic :ref:`uc-fault1` use case, no automatic actions will be taken by +the VIM, but all recovery actions executed by the VIM and the NFVI will be +instructed and coordinated by the Consumer. In a more advanced use case, the VIM shall be able to recover the failed virtual resources according to a pre-defined behavior for that resource. In principle diff --git a/requirements/05-implementation.rst b/requirements/05-implementation.rst index a4048df7..6fbf613c 100644 --- a/requirements/05-implementation.rst +++ b/requirements/05-implementation.rst @@ -12,6 +12,8 @@ the related northbound interface and the related information elements. Finally, Section 5.6 provides a first set of blueprints to address selected gaps required for the realization functionalities of the Doctor project. +.. _impl_fb: + Functional Blocks ----------------- @@ -88,7 +90,7 @@ to users with relevant ownership, whereas the latter is related to raw devices or small entities which should be handled with an administrator privilege. The northbound interface between the Notifier and the Consumer/Administrator is -specified in Section 5.5. +specified in :ref:`impl_nbi`. Sequence -------- @@ -144,7 +146,7 @@ shall be less than 1 second. Fault management scenario :num:`Figure #figure8` shows a more detailed message flow (Steps 4 to 6) between -the 4 building blocks introduced in Section 5.1. +the 4 building blocks introduced in :ref:`impl_fb`. 4. The Monitor observed a fault in the NFVI and reports the raw fault to the Inspector. @@ -428,6 +430,8 @@ and :num:`Figure #figure14`): - PhysicalResourceState [1] (String) - ZoneID [0..1] (Identifier) +.. _impl_nbi: + Detailed northbound interface specification ------------------------------------------- |