Merge changes I1fd9a83f,I3df017ec,Iba2a6e46,I74b51e91,I8dff0d11, ...

* changes:
  Scenario Analysis Doc - Section 3 - communication Interfaces HA scheme
  Scenario Analysis doc - multisite scenario
  cenario analysis doc - general issues for VNF HA
  Scenario Analysis doc - multisite scenario
  Scenario analysis doc - general issues for VNF HA
  Scenario Analysis doc - multisite scenario

3 files changed, 224 insertions, 0 deletions

diff --git a/Scenario_1/Scenario_Analysis_Communication_Interfaces.rst b/Scenario_1/Scenario_Analysis_Communication_Interfaces.rst
new file mode 100644
index 0000000..c97776b
--- /dev/null
+++ b/Scenario_1/Scenario_Analysis_Communication_Interfaces.rst
@@ -0,0 +1,80 @@
+3. Communication Interfaces for VNF HA schemes
+===========================================================
+
+This section will discuss some general issues about communication interfaces
+in the VNF HA schemes. In sections 2, the usecases of both stateful and
+stateless VNFs are discussed. While in this section, we would like to discuss
+some specific issues which are quite general for all the usecases proposed
+in the previous sections.
+
+3.1. VNF External Interfaces
+
+Regardless whether the VNF is stateful or stateless, all the VNFCs should act as
+a union from the perspective of the outside world. That means all the VNFCs should
+share a common interface where the outside modules (e.g., the other VNFs) can
+access the service from. There could be multiple solutions for this share of IP
+interface. However, all of this sharing and switching of IP address should be
+ignorant to the outside modules.
+
+There are several approaches for the VNFs to share the interfaces. A few of them
+are listed as follows and will be discussed in detail. 
+
+1) IP address of VMs for active/stand-by VM.
+
+2) Load balancers for active/active use cases
+
+Note that combinition of these two approaches is also feasible.
+
+For active/standby VNFCs, there is a common IP address shared by the VMs hosting
+the active and standby VNFCs, so that they look as one instance from outside.
+The HA manager will manage the assignment of the IP address to the VMs.
+(The HA manager may not be aware of this, I.e. the address may be configured
+and the active/standby state management is linked to the possession of the IP
+address, i.e. the active VNFC claims it as part of becoming active.) Only the
+active one possesses the IP address. And when failover happens, the standby
+is set to be active and can take possession of the IP address to continue traffic
+process.
+
+
+For active/active VNFCs, a LB(Load Balancer) could be used. In such scenario, there
+could be two cases for the deployment and usage of LB.
+
+Case 1: LB used in front of a cluster of VNFCs to distribute the traffic flow.
+
+In such case, the LB is deployed in front of a cluster of multiple VNFCs. Such
+cluster can be managed by a seperate cluster manager, or can be managed just
+by the LB,  which uses heartbeat to monitor each VNFC. When one of VNFCs fails,
+the cluster manager should first exclude the failed VNFC from the cluster so that
+the LB will re-route the traffic to the other VNFCs, and then the failed one should
+be recovered. In the case when the LB is acting as the cluster manager, it is
+the LB's responsibility to inform the VNFM to recover the failed VNFC if possible.
+
+
+Case 2: LB used in front of a cluster of VMs to distribute traffic flow.
+
+In this case, there exists a cluster manager(e.g. Pacemaker) to monitor and manage
+the VMs in the cluster. The LB sits in front of the VM cluster so as to distribute
+the traffic. When one of the VM fails, the cluster manager will detect that and will
+be in charge of the recovery. The cluster manager will also exclude the failed VM
+out of the cluster, so that the LB won't route traffic to the failed one.
+ 
+In both two cases, the HA of the LB should also be considered.
+
+
+3.2. Intra-VNF Communication
+
+For stateful VNFs, data synchronization is necessary between the active and standby VMs.
+The HA manager is responsible for handling VNFC failover, and do the assignment of the
+active/standby states between the VNFCs of the VNF. Data synchronization can be handled
+either by the HA manager or by the VNFC itself.
+
+The state synchronization can happen as
+
+- direct communication between the active and the standby VNFCs
+
+- based on the information received from the HA manager on channel or messages using a common queue,
+
+- it could be through a shared storage assigned to the whole VNF
+
+- through the checkpointing of state information via underlying memory and/or
+database checkpointing services to a separate VM and storage repository.
diff --git a/Scenario_1/scenario_analysis_VNF_external_interface.rst b/Scenario_1/scenario_analysis_VNF_external_interface.rst
new file mode 100644
index 0000000..c634c20
--- /dev/null
+++ b/Scenario_1/scenario_analysis_VNF_external_interface.rst
@@ -0,0 +1,99 @@
+3. Communication Interfaces for VNF HA schemes
+===========================================================
+
+This section will discuss some general issues about communication interfaces
+in the VNF HA schemes. In sections 2, the usecases of both stateful and
+stateless VNFs are discussed. While in this section, we would like to discuss
+some specific issues which are quite general for all the usecases proposed
+in the previous sections.
+
+3.1. VNF External Interfacece
+
+Regardless whether the VNF is stateful or stateless, all the VNFCs should act as
+a union from the perspective of the outside world. That means all the VNFCs should
+share a common interface where the outside modules (e.g., the other VNFs) can
+access the service from. There could be multiple solutions for this share of IP
+interface. However, all of this sharing and switching of IP address should be
+ignorant to the outside modules.
+
+There are several approaches for the VNFs to share the interfaces. A few of them
+are listed as follows and will be discussed in detail. 
+
+1) IP address of VMs for active/stand-by VM.
+
+2) Load balancers for active/active use cases
+
+Note that combinition of these two approaches is also feasible.
+
+For active/standby VNFCs, there is a common IP address shared by the VMs hosting
+the active and standby VNFCs, so that they look as one instance from outside.
+The HA manager will manage the assignment of the IP address to the VMs.
+(The HA manager may not be aware of this, I.e. the address may be configured
+and the active/standby state management is linked to the possession of the IP
+address, i.e. the active VNFC claims it as part of becoming active.) Only the
+active one possesses the IP address. And when failover happens, the standby
+is set to be active and can take possession of the IP address to continue traffic
+process.
+
+..[MT] In general I would rather say that the IP address is managed by the HA
+manager and not provided. But as a concrete use case "provide" works fine.
+So it depends how you want to use this text.
+..[fq] Agree, Thank you!
+
+For active/active VNFCs, a LB(Load Balancer) could be used. In such scenario, there
+could be two cases for the deployment and usage of LB.
+
+Case 1: LB used in front of a cluster of VNFCs to distribute the traffic flow.
+
+In such case, the LB is deployed in front of a cluster of multiple VNFCs. Such
+cluster can be managed by a seperate cluster manager, or can be managed just
+by the LB,  which uses heartbeat to monitor each VNFC. When one of VNFCs fails,
+the cluster manager should recover the failed one, and should also exclude the 
+failed VNFC from the cluster so that the LB will re-route the traffic to
+to the other VNFCs. In the case when the LB is acting as the cluster manager, it is
+the LB's responsibility to inform the VNFM to recover the failed VNFC if possible.
+
+
+Case 2: LB used in front of a cluster of VMs to distribute traffic flow.
+
+In this case, there exists a cluster manager(e.g. Pacemaker) to monitor and manage
+the VMs in the cluster. The LB sits in front of the VM cluster so as to distribute
+the traffic. When one of the VM fails, the cluster manager will detect that and will
+be in charge of the recovery. The cluster manager will also exclude the failed VM
+out of the cluster, so that the LB won't route traffic to the failed one.
+ 
+In both two cases, the HA of the LB should also be considered.
+
+..[MT] I think this use case needs to show also how the LB learns about the new VNFC.
+Also we should distinguish VNFC and VM failures as VNFC failure wouldn't be detected
+in the NFVI e.g. LB, so we need a resolution, an applicability comment at least.
+..[fq] I think I have made a mistake here by saying the VNFC. Actually if the failure
+only happens in VNFC, the VNFC should reboot itself rather than have a new VNFC taking
+its place. So in this case, I think I should modify VNFC into VMs. And as you mentioned,
+the NFVI level can hardly detect VNFC level failure.
+
+..[MT] There could also be a combined case for the N+M redundancy, when there are N
+actives but also M standbys at the VNF level.
+..[fq] It could be. But I actually haven't see such a deployed case. So I am not sure
+if I can discribe the schemes correctly:)
+
+3.2. Intra-VNF Communication
+
+For stateful VNFs, data synchronization is necessary between the active and standby VMs.
+The HA manager is responsible for handling VNFC failover, and do the assignment of the
+active/standby states between the VNFCs of the VNF. Data synchronization can be handled
+either by the HA manager or by the VNFC itself.
+
+The state synchronization can happen as
+
+- direct communication between the active and the standby VNFCs
+
+- based on the information received from the HA manager on channel or messages using a common queue,
+
+..[MT] I don't understand the yellow inserted text
+..[fq] Neither do I, actually. I think it is added by some one else and I can't make
+out what it means as well:)
+
+- it could be through a shared storage assigned to the whole VNF
+
+- through in-memory database (checkpointing), when the database (checkpoint service) takes care of the data replication.
diff --git a/Scenario_2/scenario_analysis_multi_site.rst b/Scenario_2/scenario_analysis_multi_site.rst
new file mode 100644
index 0000000..2e43471
--- /dev/null
+++ b/Scenario_2/scenario_analysis_multi_site.rst
@@ -0,0 +1,45 @@
+6, Multisite Scenario
+====================================================
+
+The Multisite scenario refers to the cases when VNFs are deployed on multiple VIMs.
+There could be three typical usecases for such scenario.
+
+One is in one DC, multiple openstack clouds are deployed. Taking into consideration that the
+number of compute nodes in one openstack cloud are quite limited (nearly 100) for
+both opensource and commercial product of openstack, multiple openstack clouds will
+have to be deployed in the DC to manage thousands of servers. In such a DC, it should
+be possible to deploy VNFs accross openstack clouds.
+
+
+Another typical usecase is Geographic Redundancy (GR). GR deployment is to deal with more
+catastrophic failures (flood, earthquake, propagating software fault, and etc.) of a single site.
+In the Geographic redundancy usecase, VNFs are deployed in two sites, which are
+geographically seperated and are deployed on NFVI managed by seperate VIM. When
+such a catastrophic failure happens, the VNFs at the failed site can failover to
+the redundant one so as to continue the service. Different VNFs may have specified
+requirement of such failover. Some VNFs may need stateful failover, while others 
+may just need their VMs restarted on the redundant site in their initial state. 
+The first would create the overhead of state replication. The latter may still 
+have state replication through the storage. Accordingly for storage we don't want
+to loose any data, and for networking the NFs should be connected the same way as
+they were in the original site. We probably want also to have the same number of
+VMs on the redundant site coming up for the VNFs.
+
+
+The other usecase is the maintainance. When one site is planning for a maintaining,
+it should first replicate the service to another site before it stops them. Such
+replication should not disturb the service, nor should it cause any data loss. The
+service at the second site should be excuted, before the first site is stopped and
+began maintenance. In such case, the multisite schemes may be used.
+
+The multisite scenario is also captured by the Multisite project, in which specific
+requirements of openstack are also proposed for different usecases. However,
+the multisite project mainly focuses on the requirement of these multisite
+usecases on openstack. HA requirements are not necessarily the requirement
+for the approaches discussed in multisite. While the HA project tries to
+capture the HA requirements in these usecases. The following links are the scenarios
+and Usecases discussed in the Multisite project.
+https://gerrit.opnfv.org/gerrit/#/c/2123/
+https://gerrit.opnfv.org/gerrit/#/c/1438/.
+
+