summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
authorIldiko Vancsa <ildiko.vancsa@ericsson.com>2015-12-17 00:05:58 +0100
committerIldiko Vancsa <ildiko.vancsa@ericsson.com>2016-04-19 12:05:09 +0200
commitafe0ea2244a2b203a3b7c2d1a8de79a0fa03e084 (patch)
treedf50d32f3e95d1c6717d0ee8995c2387838a6525 /docs
parent4b32e041ae6f50ffab8c3421324438d299055efa (diff)
WIP: Add scenario descriptions to the deliverable document
JIRA: PROMISE-59 Change-Id: Ida74b34ccfe9ca1e7a7754a920c3dfe47d15e7a8 Signed-off-by: Ildiko Vancsa <ildiko.vancsa@ericsson.com>
Diffstat (limited to 'docs')
-rw-r--r--docs/requirements/usecase.rst24
1 files changed, 20 insertions, 4 deletions
diff --git a/docs/requirements/usecase.rst b/docs/requirements/usecase.rst
index 8eeb485..bdf8888 100644
--- a/docs/requirements/usecase.rst
+++ b/docs/requirements/usecase.rst
@@ -5,6 +5,9 @@
Use cases and scenarios
=======================
+Use cases
+=========
+
Resource reservation is a basic feature in any virtualization-based network
operation. In order to perform such resource reservation from NFVO to VIM, NFVI
capacity information is also necessary at the NFVO side. Below, four use cases
@@ -18,7 +21,7 @@ release is described in :ref:`uc-brahmaputra`.
#. Co-existence of reservations and allocation requests without reservation
Resource capacity management
-============================
+----------------------------
NFVO takes the first decision on in which NFVI it would instantiate a VNF. Along
with NFVIs resource attributes (e.g. availability of hardware accelerators,
@@ -36,7 +39,7 @@ NFVI at a pre-determined abstraction, either by a query-response, or in an
event-based, or in a periodical way.
Resource reservation for immediate use
-======================================
+--------------------------------------
Reservation is inherently for the future. Even if some reserved resources are to
be consumed instantly, there is a network latency between the issuance of a
@@ -54,7 +57,7 @@ Reservations requests for immediate use do not have a start time but may have
an end time.
Resource reservation for future use
-===================================
+-----------------------------------
Network operators may want to reserve extra resources for future use. Such
necessity could arise from predicted congestion in telecom nodes e.g. due to
@@ -71,7 +74,7 @@ request and the actual allocation is outside the scope of this requirement
project.
Co-existence of reservations and allocation requests without reservation
-========================================================================
+------------------------------------------------------------------------
In a real environment VIM will have to handle allocation requests without any
time reference, i.e. time-unbound, together with time-bound reservations and
@@ -103,3 +106,16 @@ implicit or explicit priority scheme:
.. [#unbound] In this case, the consumer (VNFM or NFVO) requests to immediately
instantiate and assign virtualized resources without having
reserved the resources beforehand
+
+Scenarios
+=========
+
+This section describes the expected behavior of the system in different
+scenarios.
+
+As we are targeting a cloud platform with the above use cases, it is crucial to
+keep the flexibility in the system. By this means it is hard to explicitely
+block hardware resources for the future and ensure their availablility for
+allocation therefore it can happen that the reservation plan cannot be fulfilled
+due to certain changes in the underlying environment. We need to ensure that we
+are prepared for error and edge cases during the design period.