requirements/02-usecase.rst

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