Summary: Edge Scoping
...
- Cloud SW Capability example
- Cloud region "x" with SR-IOV, GPU, Min-guarantee support
- Cloud region "y" with SR-IOV support
- Cloud HW Capability example
- Resource cluster "xa" in Cloud region "x" with SR-IOV and GPU support
- Resource cluster "xb" in Cloud region "x" with GPU support
- Resource cluster "ya" in Cloud region "y" with SR-IOV support
Note 3:
- 5G Service/VNF placement example
- Constraints used by Optimization Framework (OOF)
5G CU-UP VNF location to be fixed to a specific physical DC based on 5G DU, bounded by a max distance from 5G DU
- Optimization Policy used by OOF
Choose optimized cloud region (or instance) for the placement of 5G CU UP for subscriber group based on the above constraints
- Constraints used by Optimization Framework (OOF)
Note 4:
- For the 5G Service/VNF placement example in Note 3
- 5G CU-UP VNF preferably maps to a specific Cloud region & Physical DC End Point
Note 5:
- For the 5G Service/VNF placement example in Note 3
- OOF will pass the Physical DC End Point to SO as a opaque data
Note 6:
- For the 5G Service/VNF placement example in Note 3
- SO passes the Physical DC End Point to Multi-Cloud as a opaque data, besides the Cloud Region
Cloud-agnostic Placement/Networking & Homing Policies (Phase 1 - Casablanca MVP, Phase 2 - Stretch Goal)
...
3a) OOF Processing - Perform Cloud Agnostic Capability check for each <cloud owner, cloud region>. OOF will prune any <cloud owner, cloud region> which is not satisfying the standardized capabilities.
Step 4, OOF --> MC evaluate cost of deployment (aligned to the SO/MC API defined by SO Casablanca HPA Design to minimize the terminology set)
*** Assume: VNFC is equalivent to VM, VNF is equivalent of heat stack.
| Code Block | ||||
|---|---|---|---|---|
| ||||
Request URI:
POST http://{msb ip}:{msb port}/api/multicloud/v1/cost_evaluation
Request body:
[
{
"cloud-owner": "owner1",
"cloud-region-id": "region1",
"directives":[
{
"vnfc_directives":[
{
"vnfc_id":"<ID of VNFC>", /*optional, but keep aligned to OOF/SO/MC API to make it simple*/
"directives":[
{
"directive_name":"<Name of directive,example flavor_directive>",
"attributes":[
{
"attribute_name":"<name of attribute, such as flavor label>",
"attribute_value":"<value such as cloud specific flavor>"
}
]
},
{
"directive_name":"<Name of directive,example vnic-info>",
"attributes":[
{
"attribute_name":"<name of attribute, such as vnic-type>",
"attribute_value":"<value such as direct/normal>"
},
{
"attribute_name":"<name of attribute, such as provider netweork>",
"attribute_value":"<value such as physnet>"
}
]
}
]
}
]
},
{
"vnf_directives":{
"directives":[
{
"directive_name":"<Name of directive>",
"attributes":[
{
"attribute_name":"<name of attribute>",
"attribute_value":"<value>"
}
]
},
{
"directive_name":"<Name of directive>",
"attributes":[
{
"attribute_name":"<name of attribute>",
"attribute_value":"<value >"
},
{
"attribute_name":"<name of attribute>",
"attribute_value":"<value >"
}
]
}
]
}
}
]
},
{
"cloud-owner": "owner2",
"cloud-region-id": "region2",
"directives": []
}
]
Response:
[
{
"cloud-owner": "owner1",
"cloud-region-id": "region1",
"net-value": 100
},
{
"cloud-owner": "owner2",
"cloud-region-id": "region2",
"net-value": 101
}
]
|
Step 4. OOF → MC - Push Cloud Agnostic Policy for the Service Instance
4a) OOF Processing
The OOF ↔ MC cloud selection API, described below, is filled based on the Cloud Selection Policy for Homing retrieved in step 2) – need OOF code changes.
OOF <-> MC Cloud Selection API -- JSON Schema with Use Case Examples as runnable python code:
...
| View file | ||||
|---|---|---|---|---|
|
ONAP Edge Analytics with DCAE/DMaaP independent of closed loop (Beyond Casablanca)
Value
- 5G Analytics
| ONAP Component | Life cycle phase | Enhancements |
|---|---|---|
| OOM - ONAP Central | Deploy |
|
...