Replace chapter name by reST reference labels

JIRA: DOCTOR-4
Change-Id: I089eb1dcfb9f4a6c0a24f83d626ab24e46b94a57
Signed-off-by: Ryota MIBU <r-mibu@cq.jp.nec.com>

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 fee136d7..2c2eea69 100644
--- a/requirements/03-architecture.rst
+++ b/requirements/03-architecture.rst
@@ -170,9 +170,9 @@ consumer-side implementation could have different schema, location, and policies
 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
 -------------------------------------------