Contribute a RA/Information flows from ZTE's implementation

JIRA:ESCALATOR-25
JIRA:ESCALATOR-26

Change-Id: I1bd5abd0d7264eb0f50bf5799c9bd560a2661acf
Signed-off-by: chaozhong-zte <chao.zhong@zte.com.cn>

8 files changed, 129 insertions, 4 deletions

diff --git a/doc/05-Reference_Architecture.rst b/doc/05-Reference_Architecture.rst
index 1b16dbe..4d5a64f 100644
--- a/doc/05-Reference_Architecture.rst
+++ b/doc/05-Reference_Architecture.rst
@@ -2,5 +2,82 @@ Reference Architecture
 ----------------------
 
 This section describes the reference architecture, the function blocks,
-the function entities of Escalator for the reader to well understand how
-the basic functions be organized.
\ No newline at end of file
+and the function entities of Escalator for the reader to well understand how
+the basic functions to be organized.
+
+1. Upgrade Scope
+~~~~~~~~~~~~~~~~
+Upgrade objects described in this document are software programs covered by
+red box in the picture below which includes: VIM and NFVI.
+The target of the upgrade is to reduce the impact on the applications in the
+blue box below as much as possible.
+Note that this upgrade process does not take into consideration the effects
+of Vi-Vnfm and Or-Vi. In other words, the unserviceability of the two
+interfaces during upgrade can  be accepted.
+
+.. figure:: images/figure1.png
+   :name: figure1
+   :width: 100%
+
+The software stack on each node is generally as shown in the table below.
+
+.. figure:: images/figure2.png
+   :name: figure2
+   :width: 100%
+
+Because the control node upgrade will not affect the business in the blue box,
+this scheme focuses on upgrading of compute nodes.
+
+2. Precondition of Upgrade
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+2.1 The environmental requirements
+1.  System is running normally. If there are any faults before the upgrade, it
+is difficult to distinguish between upgrade introduced and the environment
+itself.
+2.  The environment should have the redundant resources. Because the upgrade
+process is based on the business migration, in the absence of resource
+redundancy,it is impossible to realize the business migration, as well as to
+achieve a smooth upgrade.
+
+Resource redundancy in two levels:
+1)  NFVI level: This level is mainly the compute nodes resource redundancy.
+During the upgrade, the virtual machine on business can be migrated to another
+free compute node.
+2)  VNF level: This level depends on backup mechanism in VNF, such as:
+active-standby, load balance. In this case, as long as business of the target
+node on VMs is migrated to other free nodes, the migration of VM might not be
+necessary.
+
+The way of redundancy to be used is subject to the specific environment.
+Generally speaking, the impact of using NFVI redundancy on the VMs is larger
+than the rearrangement of the business on VNF level.
+
+2.2 The demand for version
+This is primarily a compatibility requirement. You can refer to Linux/Python
+Compatible Semantic Versioning 3.0.0:
+
+Given a version number MAJOR.MINOR.PATCH, increment the:
+1.  MAJOR version when you make incompatible API changes,
+2.  MINOR version when you add functionality in a backwards-compatible manner,
+3.  PATCH version when you make backwards-compatible bug fixes.
+
+The upgrade process needs to use some interfaces which require these
+interfaces to be backward compatible. Refer to "Interface" chapter for details.
+
+3.Upgrade related modules in VIM
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Upgrade operations are initiated by the user through the VIM. For VIM, upgrade
+management mainly contains the object:
+**Upgrade Manager**:Mainly responsible for upgrading process control. Physical
+nodes information of each node is saved in upgrade manager.
+**VIM Interface**:Mainly responsible for the external interface, include
+Vi-Vnfm, Or-Vi. This module stores VNFO and VNFM external information such as
+address and authentication.
+**Cloud Manager**:Mainly responsible for virtualization resources management,
+which might be considered made up of Openstack and SDN control node.
+**System Support**:Provide the upper software running environment, including:
+OS, HA, etc. To upgrade the upper software is based on this module.
+
+.. figure:: images/figure3.png
+   :name: figure3
+   :width: 100%
\ No newline at end of file
diff --git a/doc/06-Information_Flows.rst b/doc/06-Information_Flows.rst
index 14f2908..641b59b 100644
--- a/doc/06-Information_Flows.rst
+++ b/doc/06-Information_Flows.rst
@@ -4,5 +4,53 @@ Information Flows
 This section describes the information flows among the function
 entities when Escalator is in actions.
 
-.. <hujie> We should consider a generic procedure / frameworks of upgrading. And
-  may provide plug-ins interface for specialized tasks
\ No newline at end of file
+1. Upgrade process of Compute nodes
+
+1.1 consider VIM as a whole
+
+.. figure:: images/figure4.png
+   :name: figure4
+   :width: 100%
+
+process is:
+1. Operators add new version files on the VIM,initiate the upgrade.
+2. VIM chooses some compute nodes as the upgrade target nodes, and set them
+into maintenance mode. VIM queries the list of running VMs on target nodes.
+3. VIM notice VNFM corresponding to  the virtual machine, to migrate the
+business.
+4. VNFM migrates the business. If the business is in active of active-standby
+mode, it will initiate switch-over. If the business is in loading balance mode,
+it will move the business to other node.
+5. After VNFM moves business, it notifies the VIM.
+6. VIM judges whether the business on the target VM has all been moved. If
+not, VIM migrates the VM with business loaded to other free nodes. Then VIM
+upgrades the target computer nodes. After upgrade, VIM set the target compute
+nodes into normal nodes.
+7. If there are computer nodes remained to be upgraded, goto step 2.
+
+4.2 from inside VIM
+
+.. figure:: images/figure5.png
+   :name: figure5
+   :width: 100%
+
+.. figure:: images/figure6.png
+   :name: figure6
+   :width: 100%
+
+process is:
+1. Upgrade manager receives user operation commands. Add new version files.
+Upgrade is began.
+2. Upgrade Manager selects compute node A to Upgrade. Query list of the VMs
+running the compute nodes A to the Cloud Manager, and set the node to
+maintenance mode, that is to say creation or migration of new VM on this node
+is impossible anymore.
+3. Upgrade Manager notifies VNFM compute node A  into maintenance mode by VIM
+interface, temporarily disabling the inserting of business, and business on
+compute node A need move to the other available compute nodes.
+4. When receives the VNFM reply, or waited for a timeout, Upgrade Manager
+notifies the system support on compute node A to do software upgrade.
+5. After upgraded, Upgrade Manager removes maintenance mode for the compute
+node A.
+6. Upgrade Manager claims VNFM computing nodes A available.
+7. Select computer node B to upgrade
\ No newline at end of file
diff --git a/doc/images/figure1.png b/doc/images/figure1.png
new file mode 100644
index 0000000..da48655
--- /dev/null
+++ b/doc/images/figure1.png
diff --git a/doc/images/figure2.png b/doc/images/figure2.png
new file mode 100644
index 0000000..38346de
--- /dev/null
+++ b/doc/images/figure2.png
diff --git a/doc/images/figure3.png b/doc/images/figure3.png
new file mode 100644
index 0000000..70d16c7
--- /dev/null
+++ b/doc/images/figure3.png
diff --git a/doc/images/figure4.png b/doc/images/figure4.png
new file mode 100644
index 0000000..e74e24b
--- /dev/null
+++ b/doc/images/figure4.png
diff --git a/doc/images/figure5.png b/doc/images/figure5.png
new file mode 100644
index 0000000..a49955d
--- /dev/null
+++ b/doc/images/figure5.png
diff --git a/doc/images/figure6.png b/doc/images/figure6.png
new file mode 100644
index 0000000..efe7d6f
--- /dev/null
+++ b/doc/images/figure6.png