Page History

SO NFVO needs to support ETSI NFVO functional Microservice plugin capabilities, leveraging MSB, SpringBoot and Kubernetes,  for hosting NFVO function components by configuration. So, the SO NFVO can be customized in a future by operators.

• Support for substitution of existing function plugins
  
  • Supports registration of a new substitution Microservice with version control (leverage a mechanism like AAI ESR)
  • supports plug-in mechanism of substitution Microservices
  • Dynamic dispatching/launching plugin instances based on configuration/policy
• Support for extension of existing function plugins
  
  • Default function plugin extension with version control
  • Dynamic dispatching/launching an extended plugin instance based on configuration/policy
• Test Service Discovery
• Test Inter-Service Communication (for Honolulu, SOL003 Adapter)

Note: we are not building the Microservice service registration, aggregation, discovery and routing engine itself, but we are leveraging the engine's capability (e.g., MSB, API Fabric, Kong, or Kubernetes & service discovery) to offer configuration of NFVO Microservice components access. 

In Honolulu, the following will be supported

• Configure Microservice registration
  • The following default function Microservices will be plugged in: 
    • NS LCM Manager including:
      • SOL005 NBI API Handler
      • NS Workflows and Logic
      • Embedded Camunda Workflow Engine
      • MultiCloud Adapter client
      • ETSI Catalog Manager Adapter
      • AAI Client
    • SOL003 Adapter
    • Shared Camunda Workflow Engine (allow to use ONAP SO Camunda engine) - if ONAP SO Dynamic BPMN is available - Stretch goal
    • ETSI Catalog Manager Adapter (in Honolulu, it is part of NS LCM Manager)
    • NS Resource Infra Management (RIM) Manager
    • MultiCloud Adapter (in Honolulu, reuse of ONAP SO MultiCloud Adapter)
    • Inventory DB Adapter (In Honolulu, reuse of ONAP SO AAI client)
    • Notification Manager (not for Honolulu)
    • Policy Adapter (not for Honolulu)
    • K8S Client (not for Honolulu)
    • Configuration Adapter (not for Honolulu)
    • FM/PM Event Adapter (not for Honolulu)

Image Modified

SO NFVO NBI API Handler needs to enhance its NBI APIs to support:

• ETSI 3.3.1 SOL005 APIs 
• existing ETSI 2.7.1 SOL005 APIs for the one-level backward compatibility
  • Since SOL005 2.7.1 and 3.3.1 have the same main version number (2), the RESTful endpoint will be shared
• secure communication thru HTTPs leveraging ONAP SO certificate

Preconditions:

• ETSI SOL007 NS packages are onboarded into SDC and distributed to ETSI Catalog Manager.
• In Honolulu, the UUI - SO - E2E Workflows - NS Workflows - SOL005 Adapter - SO NFVO sequences are supported (checking with Verizon)
• The curl command-based SOL005 client continues to be supported but it uses secure communication thru HTTPs. 

Image Modified

SO NFVO NBI API Handler provides SOL005-compliant Restful Northbound APIs for SO/SOL005 Adapter/External RESTful client

• Supports NS Lifecycle Management (LCM) APIs, including subscription and notification
  • Create NS  (POST “/api/nslcm/v1/ns_instances”)
  •  Instantiate NS (POST “/api/nslcm/v1/ns_instances/{nsInstanceId}/instantiate”)
  • Terminate NS (“/api/nslcm/v1/ns_instances/{nsInstanceId}/terminate”)
  • Delete NS (DELETE “/api/nslcm/v1/ns_instances/{nsInstanceId}”)
  • Get Operation Status ( GET /api/nslcm/v1/ns_lcm_op_occs, 
    • / api/nslcm/v1/ns_lcm_op_occs
  • Subscription and Notification support for LCCN LCM
• Leverages SOL005 Swagger Files for SO NFVO SOL005 NBI API Handler
  • SOL005-NSLifecycleManagement-API.json
  • SOL005-NSLifecycleManagementNotification-API.json

SO NFVO NBI API Handler needs to enhance its

Instantiate NS to ETSI 3.3.1 from ETSI 2.7.1

• Leveraging ETSI 3.3.1 swagger upgrade, upgrade the

• Instantiate NS NBI code to support 3.3.1
• Follow and confirm 3.3.1 changes on the message sequencing, request, response, pre- and post-conditions.
• Preconditions:

• • NS instance is NOT_INSTNANTIATED state
  • SOL007 NS packages are stored in ETSI Catalog Manager.

• • the Cli-based (Postman

• • ) SO NFVO Client is ready to send the SOL005-compliant

• • Instantiate NS request

• • The SO-NFVO (so-etsi-nfvo) pod is ready
• Test the following scenarios: 

• • Supports the SOL005-compliant

• • Instantiate NS API 
    • Supports

• • • Instantiate NS request API: POST /api/nslcm/v1/ns_instances

• • • /{nsInstanceId}/instantiate (InstantiateNsRequest)
    • Supports

• • • responses

• • • 202 Accepted with an empty payload body
      
      • Returns a dummy

• • • • 202 until the backend business logic is ready 

• • • Supports NS Lifecycle Operation Occurrence Notification
      • Use a Location HTTP header that points to the new individual NS Lifecycle Operation Occurrence resource; i.e. the URI of that resource (.../ns_lcm_op_occs/{nsLcmOpOccId}
      • Supports the Sends nsLcmOperationOccurrenceNotifiation (start, result) notification operation until the result status becomes COMPLETED
    • Optionally, Instantiate NS operations uses the GET individual NS LCM operation occurrence request and response
    • Error handling: if the operation is failed, error information is provided in the notification message

• Post conditions: the NS Instance is

• as

• the INSTANTIATED state

Note: secure communication is handled by a separate user story, SO-3165.

SO NFVO NBI API Handler needs to enhance its

Terminate NS to ETSI 3.3.1 from ETSI 2.7.1

• Leveraging ETSI 3.3.1 swagger upgrade, upgrade the

• Terminate NS NBI code to support 3.3.1
• Follow and confirm 3.3.1 changes on the message sequencing, request, response, pre- and post-conditions.

• Precondition:
  • NS instance is

• • INSTANTIATED state
  • SOL007 NS packages are stored in ETSI Catalog Manager.
  • the Cli-based (Postman) SO NFVO Client is ready to send the SOL005-compliant

• • Terminate NS request
  • The SO-NFVO (so-etsi-nfvo) pod is ready
• Test the following scenarios

• • SO NFVO NBI API Handler needs to supports

• • the SOL005-compliant

• • Terminate NS API - check for 3.3.1 update
    • Supports

• • • Terminate NS request API: POST /api/nslcm/v1/ns_instances/{nsInstanceId}/

• • • terminate (

• • • TerminateNsRequest)
    • Supports responses 202 Accepted with an empty payload body
      • Returns a dummy 202 until the backend business logic is ready 

• • • • Use a Location HTTP header that points to the new individual NS Lifecycle Operation Occurrence resource; i.e. the URI of that resource (.../ns_lcm_op_occs/{nsLcmOpOccId}
    • Supports the Sends nsLcmOperationOccurrenceNotifiation with nsLcmOpOccId, notificationStatus (start, result)

• • • until the result status becomes

• • • COMPLETED 
    • Optionally,

• • • Terminate NS operations uses the GET individual NS LCM operation occurrence request and response
  • Error handling: if the operation is failed, error information is provided in the notification message

• Post conditions: the NS Instance is set as the

• TERMINATED state

Note: secure communication is handled by a separate user story, SO-3165.

SO NFVO NBI API Handler needs to enhance its

Delete NS to ETSI 3.3.1 from ETSI 2.7.1

• Leveraging ETSI 3.3.1 swagger upgrade, upgrade the Terminate NS NBI code to support 3.3.1
• Follow and confirm 3.3.1 changes on the message sequencing, request, response, pre- and post-conditions.
• Precondition:
  • NS instance

• • in NOT_INSTANTIATED state
  • SOL007 NS packages are stored in ETSI Catalog Manager.
  • the Cli-based

• • SO NFVO Client is ready to send the SOL005-compliant

• • Create NS request
  • The SO-NFVO (so-etsi-nfvo) pod is ready
• Test the following scenarios
  • SO NFVO NBI API Handler needs to

• • support the SOL005-compliant

• • Delete NS API - check for 3.3.1 update
    • Supports

• • • Delete NS request API:

• • • DELETE /api/nslcm/v1/ns_instances/{nsInstanceId}

• • • Supports

• • • the Sends 204 No Content with an empty payload body
      • Returns a dummy

• • • • 204 until the

• • • • business logic is

• • • • ready
    • Sends NsIdentifierDeletionNotification to the NFVO subscriber(s) (e.g., ONAP SO SOL005 Adapter)
      
      • Note: this will be handled by the separate user story: Sends NsIdentifierCreationNotification to the NFVO subscriber(s) (e.g., ONAP SO SOL005 Adapter)

• • Error handling: if the

• • individual NS instance is not in NOT_INSTANTIATED state, it rejects the deletion request

• Postconditions: the resource representing the NS instance has been removed from the list of NS instance resources

Note: secure communication is handled by a separate user story, SO-3165.

SO NFVO NBI API Handler needs to

support 3.3.1

SOL005-based Subscription APIs

Supports SOL005-compliant Restful Northbound Subscription and Notification APIs for SO/SOL005 Adapter

Supports the following SOL005 Subscription APIs, which are defined in the sub-tasks:

• Create NS Subscription NBI
• Get NS Subscription NBI
• Delete NS Subscription NBI

Note: if the SOL005 Adapter is not enhanced for SO NFVO, its simulator will be developed for simulating the subscription handling.

Image Added

• Note: secure communication is handled by a separate user story, SO-3165.

SO NFVO NBI API Handler needs to support Create NS subscription NBI

Image Added

• Support Subscription API: POST /api/nslcm/v1/subscriptions (LccnSubscriptionRequest)
• Support testing of the callback notification endpoint
  • GET <<callback uri>>
  • Handles 204 No Content response from the subscriber (e.g., SO SOL005 Adapter)
• Support subscription responses with 201 Created (LccnSubscription)

SO NFVO NBI API Handler needs to support the optional Get NS Subscription NBI

Image Added

• Supports Get all subscriptions

• request API: GET /api/nslcm/v1/

• subscriptions/
• Supports responses

• with 200 OK (

• LccnSubscription[])
• Supports Get individual subscription request API: GET /api/nslcm/v1/subscriptions/{subscriptionId}
• Supports individual subscription responses with 200 OK (LccnSubscription)

SO NFVO NBI API Handler needs to support

Delete NS Subscription NBI

Image Added

• Supports Delete subscription request API: DELETE /api/nslcm/v1/subscriptions/{subscriptionId}
• Supports Delete subscription responses with 204 No Content

SO NFVO NBI API Handler needs to support

sending NS notifications to the subscribed component (e.g.,

SOL005 Adapter)

• SO NFVO NBI API Handler needs to support the Subscription (POST ”/subscriptions”) API

Image Added

• SO NFVO NBI API Handler needs to support

• sending the Notification to SOL005 Adapter by using the SO SOL005 Adapter client-provided interface;
  • POST notification based on the callbackUrl from the subscription) 

• As a client, supports the sends notifications to the subscriber(s) for NS LCM: POST <<callback URI>> (<<Notification>>)
  • <<Notification>> follows NsLcmOperationOccurrenceNotification, NsIdentifierCreationNotification, NsIdentifierDeletionNotification or NsChangeNotification (see, SOL005 v3.3.1 specification 6.5.2.5 - 6.5.2.8)
• Supports the Gets response: 204 No Content from the subscriber (e.g, SO SOL005 Adapter

• )

SO NFVO

needs to enhance the Create NS backend operations and workflows which do the following sequence - validate if it works with 3.3.1

• Upgrade the

• NS LCM

• and workflows for 3.3.1

• and test the existing functions.
• Test the following scenarios are still working:
  • Supports SOL005-compliant CreateNSRequest request and parameters
    • For AAI, supports global_customer_id and service_type as part of HTTP header
      • This is not SOL005 standards, but for AAI, these parameters would be necessary.
      • Note: if there is an alternative way, please propose.
  • Supports getting NS Package from ETSI Catalog Manager
    • Query ETSI Catalog Manager for an NS package with the given csar_id (nsdId)
  • Supports NSD Validation check:
    • check if the NSD package exists in the ETSI Catalog Manager DB; otherwise generates errors
  • Supports check of an existing NS Instance
    • If an existing NS instance is found, it is an error condition. Returns a proper error.
    • else 
      • Creates NS Instance in the NS Instance DB:
        • stores the NS instance data into the NS Instance DB with the status= 'NOT_INSTANTIATED'
      • Creates a unique ns instance id (uuid)
      • Stores NS instance attribute data into the NS Instance DB.
        • e.g., ns_instance_id, ns_name, ns_package_id, nsd_id, nsd_invariant_id, description, lastuptime, global_customer_id, service_type
        • Adds additional attributes as needed
  • Prerequisite: before calling the Create NS workflows, the Service and Service-subscription objects should be in AAI.
  • Create an NS instance in AAI:
    • Stores an NS instance to the AAI Service Instance with required attributes as follows.
      • Note: shares the AAI Service Instance with the NetworkService type and role.
      • service-instance-id = ns_inst_id
      • service-instance-name = ns-name
      • service-type = SERVICE_TYPE (NetworkService)
      • service-role = SERVICE_ROLE (NetworkService)
  • For the response, gets the nsInstance data from GetNSInfoService
    • Collects only the NS related mandatory information, not VnfInstance, VlInstance, or else
    • Note: CreateVNF and InstantiateVNF happen during the InstantiateNS, not part of Create NS
  • Supports return of 201 Created with the NsInstance (with NS related mandatory information)
  • Register SO NFVO in MSB

SO NFVO needs to enhance the Instantiate NS backend operations and workflows which do the following sequence: - validate if it works with 3.3.1

• Upgrade the NS LCM and workflows for 3.3.1 and test the existing functions.
• Test the following scenarios are still working:
  • Support VLs (see the VL user stories)
  • Test Instantiate NS including VLs support
  • Supports SOL005-compliant InstantiateNSRequest request and parameters
    • Creates BPMN workflows and business logic for the following Instantiate NS operations
      • Create a Job Id
        
        • Updates NS_Instance Status to INSTANTIATING to the NFVO NS Instance database table
        • Handles input parameters from the InstantiateNsRequest
          • additionalParamsForNs
            • the VnfProfileId is the vnf descriptor idfrom the tosca.nodes.nfv.VNF vnf_profile (tosca.datatypes.nfv.VnfProifle) properties in NSD
              • note: the VnfProfile data type properties are: instantiation_Level, min_number_of_instances, max_number_of_instances
              • note: this property is only used in an NSD service template when describing a VNF node template with the corresponding VnfProfile information.
            • pass vim_id with tenant id
          • additionalParamsForVnf
            • If it is provided in the request, use additionalParamsForVnf attributes when invoking SOL003 Adapter.
            • Otherwise, formulate additionalParams for SOL003 Adapter invocation from the NSD plus additional user input
            • use of VNF input for additionalParamsForVnf is under investigation
          • pseudo logic:
            
            • plan_input = job_id, ns_inst_id, dst_plan, additionalParamsForNs, additionalParamsForVnf, additionalParamsForPnf
            • dst_plan = get nsd with the given nspackage_id, input parameters
            • Get an ns instance id from the parameter
            • get job id and occ id from the NS LCM Mgr
        • Gets VNF VIM from the location_constraints
        • Gets NSD from ETSI Catalog Manager and parses NSD (by using either SDC parser or ETSI Catalog Manager parser)
          • Note: until either SDC parser or ETSI Catalog Manager parser is ready, use the current SO NFVO internal TOSCA parser
        • If ETSI Catalog Manage parser is used, use the following ETSI Catalog Manager API:

curl -X POST /api/parser/v1/parsernsd' \

-H 'Content-Type: application/json' \

--data-raw '{

    "csarId": "csarid",

    "packageType": "ns",

    "inputs": "[]"

}'

• Updates NFVO_INST db to modify nsd model
  • Gets VNFs from the NSD
  • For each VNF, invokes the SOL003 Adapter with SOL003-compliant requests
    • To call the SOL003 Adapter, use the current SOL003 Adapter Rest API (which is internal to SO)
      • Note: exposing ETSI SOL003-compliant SOL003 Adapter REST API will be handled by the separate user story (most likely in the Honolulu release). 
      • The SOL003 Adapter internal REST API will be enhanced to carry additional attribute(s), such as tenant id, VNF package id
      • The Create VNF internal API in SOL003 Adapter will invoke both Create and Instantiate VNFs
      • Send parameters such as vnfd_id, vnfm_type, vimId, s_vimId (with "cloud_owner"_"cloud_regionid") and tenant id to SOL003 Adapter
      • For Granting VNF, support VNF granting based on the existing SOL003 Adapter.
    • Note: 
      • Currently SOL003 adapter uses “ModelVersionId" fromgeneric-vnfto retrieve the VNFD from SDC/etsi catalog. In order to creategeneric-vnfit also need model invariant id because of the relationship defined betweengeneric-vnfandservice-design-and-creation/models.
  • Supports VirtualLink connections between VNFs
    • Supports createVLs (call MultiCloud through MultiCloud Adapter)
      • Follow the Create VLs user story
  • Updates NFVO_NSINST db table: update NFVO_NSINST with the nsd model
  • Sets job status = NS Instantiate ends
  • Updates NsLcmOpOCC to COMPLETED
  • Note: Sends nsLcmOperationOccurrenceNotification
    • Note: this notification will be handled by a separate notification and subscription user story.

SO

NFVO needs to enhance the Terminate NS backend operations and workflows which do the following sequence: - validate if it works with 3.3.1

• Upgrade the NS LCM and workflows for 3.3.1 and test the existing functions.
• Test the following scenarios are still working:
  • Support Terminate VLs (see the VL user stories)
  • Test Terminate NS including VLs support
  • Supports SOL005-compliant TerminateNSRequest request and parameters
    • Only support for the immediate Terminate request; i.e., terminateTime field is empty.
  • Creates BPMN workflows and business logic for the following Terminate NS operations
    • Supports input parameter handling
      • Initialize Parameters: Get an ns_inst_d, job_id and request_data from the parameters
        • set terminate_type, terminate_timeout from request_data 
        • set job_id, ns_inst_id
        • set occ_id by creating a record in NsLcmOpOccModel DB
    • Checks if the NS instance already exists
      • if there no matching NS instance from the NFVO_NSINT database table, consider there is nothing to terminate, and return (not an error, but log that there is no matching NS instance)
    • Sets Job Status to Starting: set job status as "Starting terminate..."
    • Updates the NFVO_NSINST database table with the status = TERMINATING
    • Cancels VNF list (through SOL003 Adapter)
      • Gets a VNF instance list from the NFVO_NFINST
        • for each vnf inst
          • delete_vnf (nf_instid)
            • POST /api/nslcm/v1/ns/terminateVnf/{instId} to the SOL003 Adapter
      • For the Terminate VNF internal request, the SOL003 Adapter will invoke both Terminate and Delete VNF operations
    • Cancels VL list (through MultiCloud Adapter)
      • Follow the Delete VLs user story; pass the VL list
    • Modifies the NFVO_NSINST database table, status = NOT_INSTANTIATED
    • Sets job status = NS terminate ends
    • Updates NsLcmOpOCC to COMPLETED
    • Note: Send nsLcmOperationOccurrenceNotification
      • Note: this notification will be handled by a separate notification and subscription user story.

SO NFVO needs to enhance the Delete NS backend operations and workflows which do the following sequence: - validate if it works with 3.3.1

• Upgrade the NS LCM and workflows for 3.3.1 and test the existing functions.
• Test the following scenarios are still working:
  • Supports SOL005-compliant DeleteNS operation with nsInstanceId
  • Creates BPMN workflows and business logic for the following Delete NS operations
    • Supports input parameter handling
      • Initialize Parameters: get ns_inst_id
    • Deletes ns instance in AAI
      • Gets ns_instances from NFVO_NSINST database table
      • if there are ns_instances, 
        • Queries AAI for global_customer_id, service_type, ns_inst_id
          • set resource_version from ns_info "resource-version"
        • Invokes delete_ns_aai with global_customer_id, service_type, ns_inst_id, resource_version
          • Formulates the resource url with parameters
          • Invoke AAI Rest API: call_aaI (resource, "DELETE")
      • note: if there are discrepancies between VNF and NS status in AAI (e.g., VNF was not deleted yet), it is an error condition
    • Deletes ns_inst_id row from the NFVO_NSINST database table
      • note: if multiple records for the givin ns_inst_id are found, it is an error condition
    • Deletes ns_inst_id row from the t_lcm_inputparam_mapping database table
    • Deletes ns_inst_id row from the t_lcm_defPackage_mapping database table
    • Deletes ns_inst_id row from the t_lcm_servicebaseinfo database table
    • Returns 204 No Content
    • Send NsIdentifierDeletionNotification
      • Note: this notification will be handled by a separate notification and subscription user story.

SO NFVO needs to enhance the Get NS Operation Status operation and workflows which do the following sequence: - validate if it works with 3.3.1

• Upgrade the NS LCM and workflows for 3.3.1 and test the existing functions.
• Test the following scenarios are still working:
  • Supports SOL005-compliant Get NS Operation Status operation
  • Supports input parameters handling:
    • Initialize Parameters: set lcm_op_occ_id, parameter
  • If the nsLcmOpOccId exists, 
    • Queries NSLCMOPOCCS DB for the nsLcmOpOccId
    • Returns NsLcmOpOcc
  • else
    • Queries NSLCMOPOCCS DB for all
    • Returns NsLcmOpOcc[]
  • In Honolulu, support only the individual GET nsLCMOPOCCS.

SO NFVO needs to support the Create NS Subscription operation and workflows which do the following sequence:

<Create NS Subscription: note: the following workflow is a template, and it can be enhanced as needed.>

Image Modified

• Supports SOL005-compliant Create NS Subscription operation
• Supports input parameters handling:
  • Initializes Parameters: set subscription filters
    • callback_uri
    • authentication
    • notification_types
    • operation_types
    • operation_states
    • ns_component_types
    • lcm_opname_impactin_nscomponent
    • lcm_opoccstatus_impacting_nscomponent
    • nsInstanceSubscriptionFilter
  • Creates Subscription ID: create subscription id
  • Checks valid auth info:
  • Checks Filter Type:
    • checks if the notification is NOTIFICATION_TYPE.NSLCM_OPERATION_OCCURRENCE_NOTIFICATION
  • Checks Valid:
    • Checks Callback_URI: check callback Uri
      • checks if the callbackUri exists in the NFVO_SUBSCRIPTION DB
        • if no subscription, return true
        • else 
          • checks additional filter types, notificationTypes, operationTypes, operationStates
            • if the filters are NOT equal, return false
          • checks ns instance filter, If the filter type is not equal, return false
        • return true
  • saves subscription request to database
  • returns response with subscription

SO NFVO needs to support the Get NS Subscription operation and workflows which do the following sequence:

<Get NS Subscription: note: the following workflow is a template, and it can be enhanced as needed.>

Image Modified

• Supports SOL005-compliant Get NS Subscription operation
• Supports input parameters handling:
  • Initializes Parameter: set subscription_id, params
• if there is no param, 
  • Queries NFVO_SUBSCRIPTION DB for all
  • Returns LccSubscription[]
• else if there is param, subscriptionId,
  • Queries NFVO_SUBSCRIPTION DB for the subscriptionId
  • Returns LccSubscription

SO NFVO needs to support the Delete NS Subscription operation and workflows which do the following sequence:

<Delete NS Subscription: note: the following workflow is a template, and it can be enhanced as needed.>

Image Modified

• Supports SOL005-compliant Delete NS Subscription operation
• Supports input parameters handling:
  • Initialize Parameters: set subscriptonId
• Deletes NFVO_SUBSCRIPTION DB for the subscriptionId
• if success, return 204 No Content
• else, return error

SO NFVO needs to support the Send NS Notification operation and workflows which do the following sequence:

<Send NS Notification: note: the following workflow is a template, and it can be enhanced as needed.>

Image Modified

• Supports SOL005-compliant Send NS Notification operation
• Supports input parameters handling:
  • Initialize Parameter:
    • query NFVO_SUBSCRIPTION DB for the given key
    • get the callback URI from the return subscription 
• Formulates notification data (one of the followings)
  • NsLcmOperationOccurrenceNotification,
  • NsIdentifierCreationNotification,
  • NsIdentifierDeletionNotification or
  • NsChangeNotification
• Sends notifications to the subscriber(s) for NS LCM: POST <<callback URI>> (<<Notification>>)
• Gets response: 204 No Content from the subscriber (e.g, SO SOL005 Adapter)

• SO NFVO needs to query ETSI Catalog Manager for NS/PNF/VNF packages by using the ETSI Catalog Manager package management swagger
  • Note: for VNF packages, refer to the existing SOL003 Adapter ETSI Catalog Manager access mechanism
  • ETSI Catalog Manager package management swagger (could be updated for v2.7.1):
  • note: for SO NFVO, only NS and VNF package management API will be used, not PNF
  • note: it is done in Guilin for VNF/NS.

Image Modifiedetsicatalog.swagger.json

• SO NFVO needs to provide the notification endpoint for NS/PNF/VNF packages by using the ETSI Catalog Manager package management notification swagger.
  • SO NFVO should support SOL005-NSDManagementNotification-API compliant Notification API.
    • https://forge.etsi.org/jenkins/view/

• • • All+jobs/job/

• • • NFV+-+Network+Functions+Virtualisation/job/sol005-master/lastSuccessfulBuild/artifact/build/SOL005-NSDManagementNotification-API.yaml
    • POST /URI_is_provided_by_the_client_when_creating_the_subscription_NsdOnBoardingNotification
    • GET /URI_is_provided_by_the_client_when_creating_the_subscription_NsdOnBoardingNotification
    • POST /URI_is_provided_by_the_client_when_creating_the_subscription_NsdOnBoardingFailureNotification
    • GET /URI_is_provided_by_the_client_when_creating_the_subscription_NsdOnBoardingFailureNotification
    • POST /URI_is_provided_by_the_client_when_creating_the_subscription_NsdChangeNotification
    • GET /URI_is_provided_by_the_client_when_creating_the_subscription_NsdChangeNotification
    • POST /URI_is_provided_by_the_client_when_creating_the_subscription_NsdDeletionNotification
    • GET /URI_is_provided_by_the_client_when_creating_the_subscription_NsdDeletionNotification
    • POST /URI_is_provided_by_the_client_when_creating_the_subscription_PnfdOnBoardingNotification
    • GET /URI_is_provided_by_the_client_when_creating_the_subscription_PnfdOnBoardingNotification
    • POST /URI_is_provided_by_the_client_when_creating_the_subscription_PnfdOnBoardingFailureNotification
    • GET /URI_is_provided_by_the_client_when_creating_the_subscription_PnfdOnBoardingFailureNotification
    • POST /URI_is_provided_by_the_client_when_creating_the_subscription_PnfdDeletionNotification
    • GET /URI_is_provided_by_the_client_when_creating_the_subscription_PnfdDeletionNotification

• Note: for VNF package notification, refer the existing SOL003 Adapter ETSI Catalog Manager access mechanism
• Note: use the notification endpoint as callback uri during subscription
• Note: ETSI Catalog Manager needs to invoke one of the above notifications that are provided by SO NFVO.

SO NFVO needs to subscribe to ETSI Catalog Manager to receive Nsd{x} Notification(s)

• SO NFVO needs to conform to the following SOL005 subscription sequences.

Image Modified