From afe0ea2244a2b203a3b7c2d1a8de79a0fa03e084 Mon Sep 17 00:00:00 2001 From: Ildiko Vancsa Date: Thu, 17 Dec 2015 00:05:58 +0100 Subject: WIP: Add scenario descriptions to the deliverable document JIRA: PROMISE-59 Change-Id: Ida74b34ccfe9ca1e7a7754a920c3dfe47d15e7a8 Signed-off-by: Ildiko Vancsa --- docs/requirements/usecase.rst | 24 ++++++++++++++++++++---- 1 file 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. -- cgit 1.2.3-korg