Solves the duplicate figure numbering in PDF issue

JIRA: DOCTOR-13

Change-Id: Ie7349f71a6938407d439d28cf6f33e32e9301a31
Signed-off-by: bertys <souville@docomolab-euro.com>

3 files changed, 45 insertions, 63 deletions

diff --git a/requirements/02-use_cases.rst b/requirements/02-use_cases.rst
index f69151df..775f0b77 100644
--- a/requirements/02-use_cases.rst
+++ b/requirements/02-use_cases.rst
@@ -48,7 +48,7 @@ Faults
 Fault management using ACT-STBY configuration
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-In :num:`Figure #figure1`, a system-wide view of relevant functional blocks is
+In :numref:`figure1`, a system-wide view of relevant functional blocks is
 presented. OpenStack is considered as the VIM implementation (aka Controller)
 which has interfaces with the NFVI and the Consumers. The VNF implementation is
 represented as different virtual resources marked by different colors. Consumers
@@ -56,7 +56,7 @@ represented as different virtual resources marked by different colors. Consumers
 resources (VMs in this example) shown with the same colors.
 
 The first requirement in this use case is that the Controller needs to detect
-faults in the NVFI ("1. Fault Notification" in :num:`Figure #figure1`) affecting
+faults in the NVFI ("1. Fault Notification" in :numref:`figure1`) affecting
 the proper functioning of the virtual resources (labelled as VM-x) running on
 top of it. It should be possible to configure which relevant fault items should
 be detected. The VIM (e.g. OpenStack) itself could be extended to detect such
@@ -66,21 +66,20 @@ element can be considered as a component of VIM from an architectural point of
 view.
 
 Once such fault is detected, the VIM shall find out which virtual resources are
-affected by this fault. In the example in :num:`Figure #figure1`, VM-4 is
+affected by this fault. In the example in :numref:`figure1`, VM-4 is
 affected by a fault in the Hardware Server-3. Such mapping shall be maintained
 in the VIM, depicted as the "Server-VM info" table inside the VIM.
 
 Once the VIM has identified which virtual resources are affected by the fault,
 it needs to find out who is the Consumer (i.e. the owner/manager) of the
-affected virtual resources (Step 2). In the example shown in :num:`Figure
-#figure1`, the VIM knows that for the red VM-4, the manager is the red Consumer
+affected virtual resources (Step 2). In the example shown in :numref:`figure1`,
+the VIM knows that for the red VM-4, the manager is the red Consumer
 through an Ownership info table. The VIM then notifies (Step 3 "Fault
 Notification") the red Consumer about this fault, preferably with sufficient
 abstraction rather than detailed physical fault information.
 
-.. _figure1:
-
 .. figure:: images/figure1.png
+   :name: figure1
    :width: 100%
 
    Fault management/recovery use case
@@ -96,7 +95,7 @@ components, minimizing Doctor's reaction time is a necessary basic ingredient to
 fast failover times in general.
 
 Once the Consumer has switched to STBY configuration, it notifies (Step 5
-"Instruction" in :num:`Figure #figure1`) the VIM. The VIM can then take
+"Instruction" in :numref:`figure1`) the VIM. The VIM can then take
 necessary (e.g. pre-determined by the involved network operator) actions on how
 to clean up the fault affected VMs (Step 6 "Execute Instruction").
 
@@ -127,7 +126,7 @@ 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
+detection (Step 1 "Fault Notification in" :numref:`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,
@@ -163,11 +162,11 @@ mark them with an appropriate flag (i.e. "maintenance" state) such that these
 servers are not considered for hosting of virtual machines until the maintenance
 flag is cleared (i.e. nodes are back in "normal" status).
 
-A high-level view of the maintenance procedure is presented in :num:`Figure
-#figure2`. VIM/OpenStack, through its northbound interface, receives a
-maintenance notification (Step 1 "Maintenance Request") from the Administrator
-(e.g. a network operator) including information about which hardware is subject
-to maintenance. Maintenance operations include replacement/upgrade of hardware,
+A high-level view of the maintenance procedure is presented in :numref:`figure2`.
+VIM/OpenStack, through its northbound interface, receives a maintenance notification
+(Step 1 "Maintenance Request") from the Administrator (e.g. a network operator)
+including information about which hardware is subject to maintenance.
+Maintenance operations include replacement/upgrade of hardware,
 update/upgrade of the hypervisor/host OS, etc.
 
 The consequent steps to enable the Consumer to perform ACT-STBY switching are
@@ -183,9 +182,8 @@ Hardware Servers so that consequent maintenance operations could be performed.
 Due to the similarity for Steps 2~6, the maintenance procedure and the fault
 management procedure are investigated in the same project.
 
-.. _figure2:
-
 .. figure:: images/figure2.png
+   :name: figure2
    :width: 100%
 
    Maintenance use case
diff --git a/requirements/03-architecture.rst b/requirements/03-architecture.rst
index 2f9d24be..58fa7968 100644
--- a/requirements/03-architecture.rst
+++ b/requirements/03-architecture.rst
@@ -47,7 +47,7 @@ Architecture Overview
 ---------------------
 
 NFV and the Cloud platform provide virtual resources and related control
-functionality to users and administrators. :num:`Figure #figure3` shows the high
+functionality to users and administrators. :numref:`figure3` shows the high
 level architecture of NFV focusing on the NFVI, i.e., the virtualized
 infrastructure. The NFVI provides virtual resources, such as virtual machines
 (VM) and virtual networks. Those virtual resources are used to run applications,
@@ -79,12 +79,10 @@ applications (e.g., MME, S/P-GW) and the Network Services:
 
 The time interval between the instant that an event is detected by the
 monitoring system and the Consumer notification of unavailable resources shall
-be < 1 second (e.g., Step 1 to Step 4 in :num:`Figure #figure4` and :num:`Figure
-#figure5`).
-
-.. _figure3:
+be < 1 second (e.g., Step 1 to Step 4 in :numref:`figure4` and :numref:`figure5`).
 
 .. figure:: images/figure3.png
+   :name: figure3
    :width: 100%
 
    High level architecture
@@ -218,15 +216,14 @@ request/response message exchange allows the Consumer to find out about active
 alarms at the VIM. A filter can be used to narrow down the alarms returned in
 the response message.
 
-.. _figure4:
-
 .. figure:: images/figure4.png
+   :name: figure4
    :width: 100%
 
    High-level message flow for fault management
 
 The high level message flow for the fault management use case is shown in
-:num:`Figure #figure4`.
+:numref:`figure4`.
 It consists of the following steps:
 
 1. The VIM monitors the physical and virtual resources and the fault management
@@ -256,15 +253,14 @@ maintenance action to be executed. After the request was executed successfully
 error state, the VIM sends a MaintenanceResponse message back to the
 Administrator.
 
-.. _figure5:
-
 .. figure:: images/figure5.png
+   :name: figure5
    :width: 100%
 
    High-level message flow for NFVI maintenance
 
 The high level message flow for the NFVI maintenance use case is shown in
-:num:`Figure #figure5`.
+:numref:`figure5`.
 It consists of the following steps:
 
 1. Maintenance trigger received from administrator.
diff --git a/requirements/05-implementation.rst b/requirements/05-implementation.rst
index 6fbf613c..ace93f5b 100644
--- a/requirements/05-implementation.rst
+++ b/requirements/05-implementation.rst
@@ -19,11 +19,10 @@ Functional Blocks
 
 This section introduces the functional blocks to form the VIM. OpenStack was
 selected as the candidate for implementation. Inside the VIM, 4 different
-building blocks are defined (see :num:`Figure #figure6`).
-
-.. _figure6:
+building blocks are defined (see :numref:`figure6`).
 
 .. figure:: images/figure6.png
+   :name: figure6
    :width: 100%
 
    Functional blocks
@@ -98,8 +97,7 @@ Sequence
 Fault Management
 ^^^^^^^^^^^^^^^^
 
-The detailed work flow for fault management is as follows (see also :num:`Figure
-#figure7`):
+The detailed work flow for fault management is as follows (see also :numref:`figure7`):
 
 1. Request to subscribe to monitor specific virtual resources. A query filter
    can be used to narrow down the alarms the Consumer wants to be informed
@@ -130,22 +128,19 @@ In order to allow for quick reaction to failures, the time interval between
 fault detection in step 3 and the corresponding recovery actions in step 7 and 8
 shall be less than 1 second.
 
-.. _figure7:
-
 .. figure:: images/figure7.png
+   :name: figure7
    :width: 100%
 
    Fault management work flow
 
-
-.. _figure8:
-
 .. figure:: images/figure8.png
+   :name: figure8
    :width: 100%
 
    Fault management scenario
 
-:num:`Figure #figure8` shows a more detailed message flow (Steps 4 to 6) between
+:numref:`figure8` shows a more detailed message flow (Steps 4 to 6) between
 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
@@ -169,7 +164,7 @@ the 4 building blocks introduced in :ref:`impl_fb`.
 NFVI Maintenance
 ^^^^^^^^^^^^^^^^
 
-The detailed work flow for NFVI maintenance is shown in :num:`Figure #figure9`
+The detailed work flow for NFVI maintenance is shown in :numref:`figure9`
 and has the following steps. Note that steps 1, 2, and 5 to 8a in the NFVI
 maintenance work flow are very similar to the steps in the fault management work
 flow and share a similar implementation plan in Release 1.
@@ -198,22 +193,19 @@ flow and share a similar implementation plan in Release 1.
     the queried resource(s). In case the resource is in "maintenance" state,
     information about the related maintenance operation is returned.
 
-.. _figure9:
-
 .. figure:: images/figure9.png
+   :name: figure9
    :width: 100%
 
    NFVI maintenance work flow
 
-
-.. _figure10:
-
 .. figure:: images/figure10.png
+   :name: figure10
    :width: 100%
 
    NFVI Maintenance implementation plan
 
-:num:`Figure #figure10` shows a more detailed message flow (Steps 4 to 6)
+:numref:`figure10` shows a more detailed message flow (Steps 4 to 6)
 between the 4 building blocks introduced in Section 5.1..
 
 3. The Administrator is sending a StateChange request to the Controller residing
@@ -243,7 +235,7 @@ Implementation plan for OPNFV Release 1
 Fault management
 ^^^^^^^^^^^^^^^^
 
-:num:`Figure #figure11` shows the implementation plan based on OpenStack and
+:numref:`figure11` shows the implementation plan based on OpenStack and
 related components as planned for Release 1. Hereby, the Monitor can be realized
 by Zabbix. The Controller is realized by OpenStack Nova [NOVA]_, Neutron
 [NEUT]_, and Cinder [CIND]_ for compute, network, and storage,
@@ -252,7 +244,7 @@ script querying Nova in order to map between physical and virtual resources. The
 Notifier will be realized by Ceilometer [CEIL]_ receiving failure events
 on its notification bus.
 
-:num:`Figure #figure12` shows the inner-workings of Ceilometer. After receiving
+:numref:`figure12` shows the inner-workings of Ceilometer. After receiving
 an "event" on its notification bus, first a notification agent will grab the
 event and send a "notification" to the Collector. The collector writes the
 notifications received to the Ceilometer databases.
@@ -261,8 +253,8 @@ In the existing Ceilometer implementation, an alarm evaluator is periodically
 polling those databases through the APIs provided. If it finds new alarms, it
 will evaluate them based on the pre-defined alarm configuration, and depending
 on the configuration, it will hand a message to the Alarm Notifier, which in
-turn will send the alarm message northbound to the Consumer. :num:`Figure
-#figure12` also shows an optimized work flow for Ceilometer with the goal to
+turn will send the alarm message northbound to the Consumer. :numref:`figure12`
+also shows an optimized work flow for Ceilometer with the goal to
 reduce the delay for fault notifications to the Consumer. The approach is to
 implement a new notification agent (called "publisher" in Ceilometer
 terminology) which is directly sending the alarm through the "Notification Bus"
@@ -276,17 +268,15 @@ data", and "fired". It is representing a persistent alarm database. In order to
 realize the Doctor requirements, we need to define new "meters" in the database
 (see Section 5.6.1).
 
-.. _figure11:
-
 .. figure:: images/figure11.png
+   :name: figure11
    :width: 100%
 
    Implementation plan in OpenStack (OPNFV Release 1 ”Arno”)
 
 
-.. _figure12:
-
 .. figure:: images/figure12.png
+   :name: figure12
    :width: 100%
 
    Implementation plan in Ceilometer architecture
@@ -366,8 +356,8 @@ Simple information elements:
 * Metadata (Key-Value-Pairs): provides additional information of a physical
   resource in maintenance/error state.
 
-Complex information elements (see also UML diagrams in :num:`Figure #figure13`
-and :num:`Figure #figure14`):
+Complex information elements (see also UML diagrams in :numref:`figure13`
+and :numref:`figure14`):
 
 * VirtualResourceInfoClass:
 
@@ -452,15 +442,14 @@ Fault management interface
 This interface allows the VIM to notify the Consumer about a virtual resource
 that is affected by a fault, either within the virtual resource itself or by the
 underlying virtualization infrastructure. The messages on this interface are
-shown in :num:`Figure #figure13` and explained in detail in the following
+shown in :numref:`figure13` and explained in detail in the following
 subsections.
 
 Note: The information elements used in this section are described in detail in
 Section 5.4.
 
-.. _figure13:
-
 .. figure:: images/figure13.png
+   :name: figure13
    :width: 100%
 
    Fault management NB I/F messages
@@ -550,12 +539,11 @@ also allows the Administrator to query the state of physical machines, e.g., in
 order to get details in the current status of the maintenance operation like a
 firmware update.
 
-The messages defined in these northbound interfaces are shown in :num:`Figure
-#figure14` and described in detail in the following subsections.
-
-.. _figure14:
+The messages defined in these northbound interfaces are shown in :numref:`figure14`
+and described in detail in the following subsections.
 
 .. figure:: images/figure14.png
+   :name: figure14
    :width: 100%
 
    NFVI maintenance NB I/F messages
@@ -690,7 +678,7 @@ Event Publisher for Alarm  (Ceilometer) [*]_
   send to the Consumer, whereas one requirement of Doctor is to react on faults
   as fast as possible.
 
-  The existing message flow is shown in :num:`Figure #figure12`: after receiving
+  The existing message flow is shown in :numref:`figure12`: after receiving
   an "event", a "notification agent" (i.e. "event publisher") will send a
   "notification" to a "Collector". The "collector" is collecting the
   notifications and is updating the Ceilometer "Meter" database that is storing