The new branch of the frog4-orchestrator (global orchestrator) takes decisions about where VNFs should be instantiated basing on the exported capabilities.
So domain orchestrators should be extended to support the dynamic exportation of these capabilities.
The data structure that describes the domain should follow the data model defined on the frog4-domain-data-model repository (the python parser is available on the frog4-sdn-do but it will be soon separated in a new library repository).
Moreover, the domain-orchestrator should export an additional API that allows the global orchestrator to know if a specific VNF could be implemented trough an infrastructural capability.
request:
GET /vnf/{name}
response:
200: the vnf can be implemented.
404: vnf not found.
this could not be always true, it depends by the VNFs that the domain orchestrator is able to fetch from the vnf-repository.
At this moment, the only domain-orchestrator that has been extended in this way is the frog4-sdn-do.
The new branch of the frog4-orchestrator (global orchestrator) takes decisions about where VNFs should be instantiated basing on the exported capabilities. So domain orchestrators should be extended to support the dynamic exportation of these capabilities.
The data structure that describes the domain should follow the data model defined on the frog4-domain-data-model repository (the python parser is available on the frog4-sdn-do but it will be soon separated in a new library repository).
Moreover, the domain-orchestrator should export an additional API that allows the global orchestrator to know if a specific VNF could be implemented trough an infrastructural capability.
this could not be always true, it depends by the VNFs that the domain orchestrator is able to fetch from the vnf-repository.
At this moment, the only domain-orchestrator that has been extended in this way is the frog4-sdn-do.