[usecase] SABRE / ONAP: SO Integration

Usecase:

Improve the performance of slice creation time.  Alternatively, not requiring network administrators to manually configure Access, Transport, and Core Networks prior to slice creation; instead the network administrator provides the entire network topology to ONAP, and CBS/ONAP generate the slice across the networks.  This model would then support resource additional/subtraction without intervention by network administrators.

Background:

The SABRES team is developing methods for solving the Virtual Network Embedding (VNE) problem.  The VNE problem can be mapped to the NP-hard multiway separator problem.  Because of the difficulty of the problem, new strategies need to be employed to solve the problem.

Conflict-Based Search for the Virtual Network Embedding Problem


The CBS Algorithm is intended for use in specifically solving the question of what network resources should be allocated given a set of constraints.  In the context of ONAP, this question can be translated to: given a network topology on which to embed a slice, and a set of constraints (location, latency, bandwidth, etc) what resources should be allocated in order to guarantee the constraints.

Algorithm:

Inputs:

Substrate Network (SN)

  • Vertices are label with a unique identifier, CPU capacity label, x.y coordinates
  • Edges are labeled starting with the vertex pair followed by throughput and latency labels

Virtual Network Request (VNR)

  • Maximum Cartesian distance allowed between vertices
  • Vertices required in the embedding with CPU constraints
  • Edges required in the embedding with throughput and latency constraints

09/22/2022: This implementation is currently done using flat files as inputs, but is not a hard requirement and should be modified for ONAP Integration.

Outputs:

Virtual Network Embedding (VNE)

  • Verticies with unique identifiers
  • Edges consisting of vertex pairs

Integration:

We (the SABRES team) are not completely aware of how best to proceed with integration, as there are many components we do not understand.


We expect that as a part of the onboarding process of ONAP, a network administrator will provide the network topology to ONAP (how that is done we do not know).  The topology will then be stored in AAI for other components.  There would be an API to access and modify the network topology that can modify the AAI state.


During a Slice creation request, a VNR is created either in the portal or through REST API that will cause the network topology (SN) to be retrieved from AAI.  The VNR and SN are then submitted to CBS either as a component of the BPMN or as another OOF-HAS component/adapter.


CBS will return a VNE back to the SO.  The SO will then communicate with the VIM adapters to then provision the slice.  Upon slice allocation and/or creation the SN in AAI is updated to reflect the resource allocation of the current slice.


VNRs may also include a priority level for their Embedding, such that if there is no satisfiable embedding, the SN is modified to include lower priority slices which would be consumed back into ONAP in order to provide the resources necessary to allocate the embedding.