Skip to content

Latest commit

 

History

History
56 lines (48 loc) · 7.98 KB

two_nodes.md

File metadata and controls

56 lines (48 loc) · 7.98 KB

Two nodes in different domains (w/o Catalog)

The complete workflow showing the interaction between two nodes belonging to different domains is the following.

NOTE: currently there are ongoing discussions whether the 'supernode' concept can be simplified and the workflow among nodes belonging to different domains can be seamlessly integrated in the one already defined for the nodes belonging to one single domain.

Workflow 2

Steps

  1. A new service request is sent to the Service Handler in the form of an intent.
  2. The intent is passed to the Node Orchestrator, which translates and decomposes it to simple resources or services requests.
  3. The Node Orchestrator looks up for flavours matching the request in the Available Resources and the Ratings and Metrics tables.
  4. In case there are no suitable available resources, the request is passed to the REAR Manager to start-up the Discovery, Reservation and Peering phases.
  5. The REAR Manager looks up in the Peering Candidates table for potential peering candidates (suitable flavours) matching the request.
  6. In case there are no suitable peering candidates, the the REAR Manager builds a flavour selector and passes it to the Discovery Manager asking for a suitable peering candidate.
  7. The Discovery Manager of the Node sends a LIST_FLAVOURS message to its Supernode, already known and directly reachable.
  8. The Discovery Manager of the Supernode looks-up for suitable local flavours matching the received flavour selector in its Available Resources table.
  9. In case no suitable flavours are found, the Discovery Manager looks up in the Peering Candidates table for potential peering candidates (suitable flavours) matching the request.
  10. In case no suitable peering candidates are found, the Discovery Manager of the Consumer Supernode sends a LIST_FLAVOURS message to all the endpoints it already knows, whatever they are other Supernodes or a Catalog, attaching the flavour selector.
  11. The Discovery Manager of the Provider Supernode looks-up for suitable local flavours matching the received flavour selector in its Available Resources table.
  12. See step #9.
  13. In case one or more suitable flavours are found, the Discovery Manger of the Provider Supernode sends back an OK message to the Discovery Manager of the Consumer Supernode attaching the flavours list.
  14. The Discovery Manager of the Consumer Supernode populates the Peering Candidates table with the newly discovered flavours.
  15. The Discovery Manager of the Consumer Supernode sends back an OK message to the Discovery Manager of the Consumer Node attaching the flavours list.
  16. The Discovery Manager of the Consumer Node populates the Peering Candidates table with the newly discovered flavours.
  17. It then informs the REAR Manager that the Discovery phase has completed successfully.
  18. See step #5.
  19. Now that a suitable peering candidate is found, the REAR Manager asks the Contract Manager to start-up the Reservation phase pointing to the Provider Node.
  20. The Contract Manager of the Consumer Node sends a RESERVE_FLAVOUR message to the Contract Manager of the Consumer Supernode.
  21. The Contract Manager of the Consumer Supernode sends a RESERVE_FLAVOUR message to the Contract Manager of the Provider Supernode.
  22. The Contract Manager of the Provider Supernode sends a RESERVE_FLAVOUR message to the Contract Manager of the Provider Node.
  23. The Contract Manager of the Provider Node creates a new contract and asks its REAR Manager to reserve resources for the incoming request.
  24. The REAR Manager updates the Available Resources table by deleting the old advertised flavour and creating a new reduced flavour (suitable for other future requests) and by creating a new allocation of type "Node" in "inactive" status.
  25. The REAR Manager informs the Contract Manager that the resources have been reserved.
  26. The Contract Manager of the Provider Node answers back to the Contract Manager of the Provider Supernode with an OK message. At the same time an informer makes the Network Manager aware, so that it can deploy a virtual router to enable peering reachability.

Following the steps defined into the REAR Protocol, the couples of Contract Managers may exchange a couple of other messages to confirm the reservation on both sides, but may also directly agree following the procedure described from step X to step Y.

  1. The Contract Manager of the Provider Supernode creates a new contract and answers back to the Contract Manager of the Consumer Supernode with an OK message. At the same time an informer makes the Network Manager aware, so that it can deploy a virtual router to enable peering reachability.
  2. The Contract Manager of the Consumer Supernode creates a new contract and answers back to the Contract Manager of the Consumer Node with an OK message. At the same time an informer makes the Network Manager aware, so that it can deploy a virtual router to enable peering reachability.
  3. The Contract Manager of the Consumer Node creates a new contract and informs its REAR Manager that the resources have been reserved. At the same time an informer makes the Network Manager aware, so that it can deploy a virtual router to enable peering reachability.
  4. The REAR Manager updates the Available Resources table by creating a new allocation of type "VirtualNode" in "inactive" status.
  5. The REAR Manager solicits its Virtual Fabric Manager (LIQO) to set-up the peering.
  6. The Virtual Fabric Manager of the Consumer Node generates a ResourceRequest on the Virtual Fabric Manager of the Provider Node. Network reachability is provided by the Network Managers.
  7. The Virtual Fabric Manager of the Provider Node looks up in its Contract Manager for an already signed contract embedding a flavour matching the CustomerID of the Consumer Node: once found, it completes the peering.
  8. Once done, an informer makes the REAR Manager aware.
  9. The REAR Manager updates the Available Resources table by putting the previously created allocation to "active" state.
  10. The Virtual Fabric Manager of the Provider Node sends a ResourceOffer to the Virtual Fabric Manager of the Consumer Node.
  11. See step #34.
  12. See step #35.
  13. The REAR Manager finally informs the Node Orchestrator that all the Discovery, Reservation and Peering phases are over.
  14. The Node Orchestrator is auto-solicited to continue with the Intent Management phase.
  15. See step #3

Now that there are available resources that fulfill the request, the Node Orchestrator can finally deploy the workload described in the intent exploiting standard Kubernetes primitives and pointing to the VirtualNode retrieved in the Available Resources table.