From 0336f0f9db1f79980d85285f2c11c0f9a2c60767 Mon Sep 17 00:00:00 2001 From: Ryota MIBU Date: Thu, 18 Jun 2015 20:32:13 +0900 Subject: Replace chapter name by reST reference labels JIRA: DOCTOR-4 Change-Id: I089eb1dcfb9f4a6c0a24f83d626ab24e46b94a57 Signed-off-by: Ryota MIBU --- requirements/02-use_cases.rst | 34 ++++++++++++++++++---------------- 1 file changed, 18 insertions(+), 16 deletions(-) (limited to 'requirements/02-use_cases.rst') 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 ---------------- -- cgit 1.2.3-korg