Faults
------
+.. _uc-fault1:
+
Fault management using ACT-STBY configuration
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
----------------
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
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
-----------------
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
--------
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.
- PhysicalResourceState [1] (String)
- ZoneID [0..1] (Identifier)
+.. _impl_nbi:
+
Detailed northbound interface specification
-------------------------------------------