As part of aligning ONAP to ETSI MANO interfaces, SOL 005 support will be introduced between Service Orchestrator & Virtual Functions Controller component.
Until Casablanca release, the communication between SO & VF-C is based on ONAP APIs. In Dublin, this interface will be aligned to SOL 005 and the usecase will be designed in such a way that, any SOL 005 Compliant NFV-O can interact with SO, in addition to VF-C.
Resource commitment :
Verizon : Bharath Thiruveedula Prateek Gupta Sirisha Gopigiri
Usecase Lead :
Verizon : Bharath Thiruveedula
TSC Contact :
Verizon : Viswanath Kumar Skand Priya
Participating ONAP Projects :
Implementation : SO, VF-C
Functionality enablement / support : UUI, AAI/ESR
ETSI NFV-SOL 005 Introduction
ETSI NFV-SOL 005 provides the interface specifications for Os-Ma-nfvo reference point, shared between OSS & NFV-Orchestration functions. Mapping this architecture to ONAP, SO represents the OSS functionality as it oversees E2E services and VF-C represents the NFV-O functionality as it performs network service orchestration. By aligning the interface between SO and VF-C to NFV SOL 005, any external NFV-O can utilize ONAP SO for service orchestration layer.
What ETSI NFV-SOL 005 APIs are supported in VF-C?
As of Dublin release, VFC is planning to implement the following APIs:
- NS LCM
- Create NS
- Delete NS
- Get NS
- Instantiate NS
- terminate NS
- NSD Package management
- Subscribe
- Query Subscribe Information
- Terminate Subscription
- Notify
- VNFD Package Management
- Fetch VNF Package artifacts
- Subscribe
- Query Subscription information
- Terminate Subscription
What SOL005 APIs that will be consumed by SO?
Till Casablanca release, SO supports NS LCM API and scaling of NS. We are not going to add any new APIs in this release. But we will modify existing NS LCM APIs alone to make compatible with SOL 005.
API Action | Method | URI | Description |
---|---|---|---|
Create NS | POST | /ns_instances | To create a Network Service |
Instantiate NS | POST | /ns_instances/{nsInstanceId}/instantiate | To instantiate Network service |
Get NS Details | GET | /ns_instances/{nsInstanceId} | To query the status of the Network Service |
Terminate NS | POST | /ns_instances/{nsInstanceId}/terminate | To Delete Network Service Instance |
Sequence Diagram of the flow:
Usecase Explanation:
Step - 1 Register NFV-O ( VF-C ) to ONAP via ESR:
Until Casablanca release, VF-C was the only native NFV-O and the interface between SO & VF-C happened via MSB component. As part of this usecase, we introduce a generic way to introduce any SOL 005 compliant NFV-O into ONAP Ecosystem. On that front, External System Register ( ESR ) component will be extended to have a new entity type for NFV-O, in addition to VNFM, VIM, EMS & SDN-C.
Currently, in ESR we have the option to register VNFM, VIM, EMS and SDNC. We have to add new ESR entity called NFVO to register any external NFV orchestrators.
Note: As per SOL005 spec, we can have any apiRoot for the Orchestrator base URL which makes difficult to register NFVO in MSB
Step - 2 Push the details in AAI:
As ESR one of subcomponent of AAI, all ESR entities will be pushed to AAI graph database.
Step - 3 Send NS request from UUI along with orchestrator details:
In Usecase UI, two new dropdowns will be introduced.
- To select orchestrator which is populated by querying AAI
Along with the above details, UUI will send E2E service instance request to SO.
Step - 4 VF-C/SOL 005 Adapter fetch orchestrator details from AAI:
VF-C adapter will fetch orchestrator details from AAI based on the details provided by UUI.
Saving of orchestrator details in nfvo mapping table in so request db correspond to each instance/job.
Step - 5 VF-C/SOL 005 Adapter send the requests to NFVO:
The adapter will fetch the orchestrator details from AAI and call corresponding SOL 005 APIs
Frequently Asked Questions :
What usecase to be tested with SOL 005 Flow ?
As of the Dublin release, SOL 005 flow will be tested against vFW usecase with SOL004 CSAR. However more testing will be performed with external SOL 005 compliant NFV-O to ensure ETSI NFV-SOL 005 Compliance.
Impacts to other ONAP Components ?
- AAI: New entity in ESR will be introduced to accept NFVO registrations. VF-C will also be registered as yet another NFV-O to ensure one standard path.
- UUI: A new dropdown will be added in UUI to select target NFV-O for service instantiation.
Prerequisites/ Assumptions:
- The scope of work is limited to NS LCM APIs, so Service Orchestrator (SO) won’t deal with CSAR package onboarding to VFC.
- As all the attributes that SOL005 instantiate request expects are not provided from Usecase UI, so scope of this work is limited to such requests.
- No new SO NBI is added for this usecase. SO E2E Service Instance APIs will be reused to support ETSI NFV-SOL 005
SOL 005 API Request and Response ( for reference only. These APIs will be implemented by VF-C / NFV-O)
What | CreateNS |
---|---|
Path | POST {apiRoot}/nslcm/v1/ns_instances |
When | While creating NS for Sol005 NFVO |
Request Model | |
Response Model | |
Callers | OSS/BSS or SO Sol005 Adapter |
What | InstantiateNs |
---|---|
Path | POST {apiRoot}/nslcm/v1/ns_instances/{nsInstanceId}/instantiate |
When | Calling from SO Sol005/VFC Adapter |
Request Model | |
Response Model | No Response. |
Callers | OSS/BSS, SO Sol005 Adapter |
What | Find the details of created NS |
---|---|
Path | GET {apiRoot}/nslcm/v1/ns_instances/{nsInstanceId} |
When | Calling from SO Sol005/VFC Adapter |
Request Model | NA |
Response Model | |
Callers | OSS/BSS, SO Sol005 Adapter |
What | Terminate already created NS |
---|---|
Path | POST {apiRoot}/nslcm/v1/ns_instances/{nsInstanceId}/terminate |
When | Calling from SO Sol005/VFC Adapter |
Request Model | |
Response Model | No Response |
Callers | OSS/BSS, SO Sol005 Adapter |
GAP Analysis SO E2E Service Instance NBI Vs SOL 005 API.
1. Parameter Analysis for InstantiateNS
Parameter | SO NBI Not Present(NP)/Present(P) | Mandatory(M) /Optional(O) | Significance |
---|---|---|---|
nsFlavourId | NP | M | Identifier of the NS deployment flavour to be instantiated |
sapData | NP | O | Create data concerning the SAPs of this NS |
addpnfData | NP | O | Information on the PNF(s) that are part of this NS. |
vnfInstanceData | NP | O | Specify an existing VNF instance to be used in the NS. If needed, the VNF Profile to be used for this VNF instance is also provided. |
nestedNsInstanceId | NP | O | Specify an existing NS instance to be used as a nested NS within the NS. |
localizationLanguage Structure { "vnfProfileId":"", "locationConstraints":{ "countryCode":"", "civicAddressElement":{ "caType":1, "caValue":"" } } } | Partially Provided. Only vnfProfileId is provided. More details are in following rows | O | Defines the location constraints for the VNF to be instantiated as part of the NS instantiation. An example can be a constraint for the VNF to be in a specific geographic location. |
localizationLanguage.vnfProfileId | P | M | |
localizationLanguage.locationConstraints | P | O | |
localizationLanguage.locationConstraints.countryCode | NP | M | |
localizationLanguage.locationConstraints.civicAddressElement | NP | M | |
additionalParamsForNs | P "requestInputs" Note: Present under service.parameters.requestInputs | O | Allows the OSS/BSS to provide additional parameter(s) at the NS level (as opposed to the VNF level, which is covered in additionalParamsForVnf). |
additionalParamsForVnf | P requestInputs Note: Present under service.parameters.resources.requestInputs | O | Allows the OSS/BSS to provide additional parameter(s) per VNF instance (as opposed to the NS level, which is covered in additionalParamsForNs). This is for VNFs that are to be created by the NFVO as part of the NS instantiation and not for existing VNF that are referenced for reuse. |
startTime | NP | O | Timestamp indicating the earliest time to instantiate the NS. |
nsInstantiationLevelId | NP | O | Identifies one of the NS instantiation levels declared in the DF applicable to this NS instance. If not present, the default NS instantiation level as declared in the NSD shall be used. |
additionalAffinityOrAntiAffiniityRule | NP | O | Specifies additional affinity or anti-affinity constraint for the VNF instances to be instantiated as part of the NS instantiation. Shall not conflict with rules already specified in the NSD. |
2. Parameter Analysis for createNS
Parameter | SO NBI Not Present(NP) /Present(P) | Mandatory(M) /Optional(O) | Significance |
---|---|---|---|
nsdId | P (serviceUuid) | M | Identifier of the NSD that defines the NS instance to be created. |
nsName | P (name) | M | Human-readable name of the NS instance to be created |
nsDescription | P (description) | M | Human-readable description of the NS instance to be created. |
3. Parameter Analysis for terminateNS
Parameter | SO NBI Not Present(NP) /Present(P) | Mandatory(M) /Optional(O) | Significance |
---|---|---|---|
terminationTime | NP | O | Timestamp indicating the end time of the NS, i.e. the NS will be terminated automatically at this timestamp. Cardinality "0" indicates the NS termination takes place immediately. |
API Mapping table ( SO NBI & ETSI NFV-SOL 005 )
# | SO NBI API | SO NBI Payload | SOL API | SOL 005 Payload | Identified GAPs |
---|---|---|---|---|---|
1. | Create NS and Instance NS /onap/so/infra/e2eServiceInstances/{version} | /ns_instances | Create NS Payload |
| |
2. | Query NS details /onap/so/infra/e2eServiceInstances/{version}/{serviceId}/operations/{operationId} | No Payload | /ns_instances/{nsInstanceId} | No Payload | No Gap identified |
3. | Terminate NS /onap/so/infra/e2eServiceInstances/{version}/{serviceId} | /ns_instances/{nsInstanceId}/terminate | No Gap Identified | ||
4. | InstantiateNS /onap/so/infra/e2eServiceInstances/{version} | Same API for Create and Instantiate | /ns_instances/{nsInstanceId}/instantiate | For instantiate NS the following are the data that is missing in SO NBI
|