docs/requirements/usecase.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2 .. http://creativecommons.org/licenses/by/4.0
   3
   4 =======================
   5 Use cases and scenarios
   6 =======================
   7
   8 Use cases
   9 =========
  10
  11 Resource reservation is a basic feature in any virtualization-based network
  12 operation. In order to perform such resource reservation from NFVO to VIM, NFVI
  13 capacity information is also necessary at the NFVO side. Below, four use cases
  14 to show typical requirements and solutions for capacity management and resource
  15 reservation is presented. A typical use case as considered for the Brahmaputra
  16 release is described in :ref:`uc-brahmaputra`.
  17
  18 #.  Resource capacity management
  19 #.  Resource reservation for immediate use
  20 #.  Resource reservation for future use
  21 #.  Co-existence of reservations and allocation requests without reservation
  22
  23 Resource capacity management
  24 ----------------------------
  25
  26 NFVO takes the first decision on in which NFVI it would instantiate a VNF. Along
  27 with NFVIs resource attributes (e.g. availability of hardware accelerators,
  28 particular CPU architectures etc.), NFVO needs to know available capacity of an
  29 NFVI in order to make an informed decision on selecting a particular NFVI. Such
  30 capacity information shall be in a coarser granularity than the respective VIM,
  31 as VIM maintains capacity information of its NFVI in fine details.  However a
  32 very coarse granularity, like simply the number of available virtual CPU cores,
  33 may not be sufficient. In order to allow the NFVO to make well founded
  34 allocation decisions, an appropriate level to expose the available capacity may
  35 be per flavor. Capacity information may be required for the complete NFVI, or
  36 per partition or availability zone, or other granularities. Therefore, VIM
  37 requires to inform the NFVO about available capacity information regarding its
  38 NFVI at a pre-determined abstraction, either by a query-response, or in an
  39 event-based, or in a periodical way.
  40
  41 Resource reservation for immediate use
  42 --------------------------------------
  43
  44 Reservation is inherently for the future. Even if some reserved resources are to
  45 be consumed instantly, there is a network latency between the issuance of a
  46 resource reservation request from the NFVO, a response from the VIM, and actual
  47 allocation of the requested resources to a VNF/VNFM. Within such latency,
  48 resource capacity in the NFVI in question could change, e.g., due to failure,
  49 allocation to a different request. Therefore, the response from a VIM to the
  50 NFVO to a resource reservation request for immediate use should have a validity
  51 period which shows until when this VIM can hold the requested resources. During
  52 this time, the NFVO should proceed to allocation if it wishes to consume the
  53 reserved requested. If allocation is not performed within the validity period,
  54 the response from VIM for a particular resource reservation request becomes
  55 invalid and VIM is not liable to provide those resources to NFVO/VNFM anymore.
  56 Reservations requests for immediate use do not have a start time but may have
  57 an end time.
  58
  59 Resource reservation for future use
  60 -----------------------------------
  61
  62 Network operators may want to reserve extra resources for future use. Such
  63 necessity could arise from predicted congestion in telecom nodes e.g. due to
  64 local traffic spikes for concerts, natural disasters etc. In such a case, the
  65 NFVO, while sending a resource reservation request to the VIM, shall include a
  66 start time (and an end time if necessary). The start time indicates at what
  67 time the reserved resource shall be available to a designated consumer e.g. a
  68 VNF/VNFM. Here, the requirement is that the reserved resources shall be
  69 available when the start time arrives. After the start time has arrived, the
  70 reserved resources are allocated to the designated consumer(s). An explicit
  71 allocation request is needed. How actually these requested resources are held
  72 by the VIM for the period in between the arrival of the resource reservation
  73 request and the actual allocation is outside the scope of this requirement
  74 project.
  75
  76 Co-existence of reservations and allocation requests without reservation
  77 ------------------------------------------------------------------------
  78
  79 In a real environment VIM will have to handle allocation requests without any
  80 time reference, i.e. time-unbound, together with time-bound reservations and
  81 allocation requests with an explicitly indicated end-time. A granted
  82 reservation for the future will effectively reduce the available capacity for
  83 any new time-unbound allocation request. The consequence is that reservations,
  84 even those far in the future, may result in denial of service for new
  85 allocation requests.
  86
  87 To alleviate this problem several approaches can be taken. They imply an
  88 implicit or explicit priority scheme:
  89
  90 * Allocation requests without reservation and which are time-unbound will be
  91   granted resources in a best-effort way: if there is instant capacity, but the
  92   resources may be later withdrawn due to the start time of a previously
  93   granted reservation
  94 * Both allocation requests and reservation requests contain a priority which
  95   may be related to SLAs and contractual conditions between the tenant and the
  96   NFVI provider. Interactions may look like:
  97
  98   * A reservation request for future use may cancel another, not yet
  99     started, reservation with lower priority
 100   * An allocation request without reservations and time-unbound [#unbound]_
 101     may be granted resources and prevent a future reservation with lower
 102     priority from getting resources at start time
 103   * A reservation request may result in terminating resources allocated to a
 104     request with no reservation, if the latter has lower priority
 105
 106 .. [#unbound] In this case, the consumer (VNFM or NFVO) requests to immediately
 107               instantiate and assign virtualized resources without having
 108               reserved the resources beforehand
 109
 110 Scenarios
 111 =========
 112
 113 This section describes the expected behavior of the system in different
 114 scenarios.
 115
 116 As we are targeting a cloud platform with the above use cases, it is crucial to
 117 keep the flexibility in the system. By this means it is hard to explicitely
 118 block hardware resources for the future and ensure their availablility for
 119 allocation therefore it can happen that the reservation plan cannot be fulfilled
 120 due to certain changes in the underlying environment. We need to ensure that we
 121 are prepared for error and edge cases during the design period.