1 files changed, 105 insertions, 0 deletions
diff --git a/docs/requirements/impl_architecture.rst b/docs/requirements/impl_architecture.rst
new file mode 100644
index 0000000..46cbba1
--- /dev/null
+++ b/docs/requirements/impl_architecture.rst
@@ -0,0 +1,105 @@
+Detailed architecture and message flows
+=======================================
+
+Within the Promise project we consider two different architectural options,
+i.e. a *shim-layer* based architecture and an architecture targeting at full
+OpenStack *integration*.
+
+Shim-layer architecture
+-----------------------
+
+The *shim-layer architecture* is using a layer on top of OpenStack to provide
+the capacity management, resource reservation, and resource allocation
+features.
+
+
+Detailed Message Flows
+^^^^^^^^^^^^^^^^^^^^^^
+
+.. note:: This section has to be updated.
+
+Resource Capacity Management
+""""""""""""""""""""""""""""
+
+.. figure:: images/figure5.png
+    :name: figure5
+    :width: 90%
+
+    Capacity Management Scenario
+
+:numref:`figure5` shows a detailed message flow between the consumers and the
+functional blocks inside the VIM and has the following steps:
+
+Step 1: The consumer subscribes to capacity change notifications
+
+Step 2: The Capacity Manager monitors the capacity information for the various
+types of resources by querying the various Controllers (e.g. Nova, Neutron,
+Cinder), either periodically or on demand and updates capacity information in
+the Capacity Map
+
+Step 3: Capacity changes are notified to the consumer
+
+Step 4: The consumer queries the Capacity Manager to retrieve capacity detailed
+information
+
+Resource Reservation
+""""""""""""""""""""
+
+.. figure:: images/figure6.png
+    :name: figure6
+    :width: 90%
+
+    Resource Reservation for Future Use Scenario
+
+:numref:`figure6` shows a detailed message flow between the consumers and the
+functional blocks inside the VIM and has the following steps:
+
+Step 1: The consumer creates a resource reservation request for future use by
+setting a start and end time for the allocation
+
+Step 2: The consumer gets an immediate reply with a reservation status message
+"reservationStatus" and an identifier to be used with this reservation instance
+"reservationID"
+
+Step 3: The consumer subscribes to reservation notification events
+
+Step 4: The Resource Reservation Manager checks the feasibility of the
+reservation request by consulting the Capacity Manager
+
+Step 5: The Resource Reservation Manager reserves the resources and stores the
+list of reservations IDs generated by the Controllers (e.g. Nova, Neutron,
+Cinder) in the Reservation Map
+
+Step 6: Once the reservation process is completed, the VIM sends a notification
+message to the consumer with information on the reserved resources
+
+Step 7: When start time arrives, the consumer creates a resource allocation
+request.
+
+Step 8: The consumer gets an immediate reply with an allocation status message
+"allocationStatus".
+
+Step 9: The consumer subscribes to allocation notification events
+
+Step 10: The Resource Allocation Manager allocates the reserved resources. If
+not all reserved resources are allocated before expiry, the reserved resources
+are released and a notification is sent to the consumer
+
+Step 11: Once the allocation process is completed, the VIM sends a notification
+message to the consumer with information on the allocated resources
+
+
+Integrated architecture
+-----------------------
+
+The *integrated architecture* aims at full integration with OpenStack.
+
+Detailed Message Flows
+^^^^^^^^^^^^^^^^^^^^^^
+
+.. note:: to be done
+
+Resource Reservation
+""""""""""""""""""""
+
+.. note:: to be specified