API input to NSD mapping...© Netcracker 2017 2 Goal The purpose of this study is to map the Os-Ma-nfvo API input parameters to Network Service Descriptor and identify whether a “Modify

© Netcracker 2017 1

Mapping Os-Ma-nfvo API inputs to

NSD

A Deep Dive


Goal

The purpose of this study is to map the Os-Ma-nfvo API input parameters to Network Service Descriptor

and identify whether a “Modify” operation is needed to support Network Service LCM operations of ETSI

NFV.

While performing this exercise, we attempted to answer the following questions :

❑ What is the information (“inputs”) provided by each of those operations?

❑ Is this information only relevant for this specific lifecycle management operation or should values (e.g. defaults) for

this information be available/provided at service instantiation time?

❑ Does the lifecycle management change the service instance model? E.g. are property values changed? Does

substitution mapping need to be re-done (e.g. to change deployment flavors)? Are different resource assignments

needed?

❑ Do each of these lifecycle management operations require a separate workflow, or would it be possible to

construct a general-purpose “Modify” workflow that handles most of the case?


Instantiate NSAPI Inputs NSD Mapping

nsInstanceId Used by Orchestrator

flavourId Topology template Input

sapData - sapdId

- sapName

- description

- address

- sapProtocolData

o layerProtocol

o ipOverEthernet

- macAddress

- ipAddresses

- type

- fixedAddresses

- numDynamicAddresses

- addressRange

- minAddress

- maxAddress

- subnetId

Orchestrator processes these parameters and makes them available for further processing

addPnfData - pnfId

- pnfName

- pnfdId

- pnfProfileId

- cpData

o cpInstanceId

o cpdId

o cpProtocolData

- layerProtocol

- ipOverEthernet

o macAddress

o ipAddresses

o type

o fixedAddresses

o numDynamicAddresses

o addressRange

o minAddress

o maxAddress

o subnetId



Instantiate NS

vnfInstanceData - vnfInstanceId- vnfProfileId

Orchestrator in built logic uses these inputs to identify

the NS Instance

nestedNsInstanceData - nestedInstanceId- nsProfileId

Orchestrator in built logic uses these inputs to identify

the NS Instance

locationConstraints - VnfProfileId

- LocationConstraints:

• countryCode

• civicAddressElement

• caType

• caValue

Orchestrator uses these for placement of VNFs

additionalParamForNs Workflow inputs

additionalParamForNeste

dNs

Workflow inputs

additionalParamForVnf Workflow inputs

nsInstantiationLevelId Topology input

startTime Used by Orchestrator

additionalAffinityOrAntiAf

finiityRule

This additional rule is used by Orchestrator to add to the

rules created from NSD node templates

API Inputs NSD Mapping

NOTE: In place of “in built” Orchestrator logic for identifying the VNF/NS/nested NS instance, “node_filter” can be used


Update NS AddVnf , RemoveVnf ,InstantiateVnf , ChangeVnfDf , OperateVnf , ModifyVnfInformation, ChangeExtVnfConnectivity ,AddSap

,RemoveSap ,AddNestedNs ,RemoveNestedNs, AssocNewNsdVersion , MoveVnf , AddVnffg ,RemoveVnffg ,UpdateVnffg ,ChangeNsDf ,AddPnf ,ModifyPnf, RemovePnf

addVnfIstance - vnfInstanceId- vnfProfileIdINVOLVES CHANGES TO NSD FOLLOWED BY CHANGES TO NS INSTANCE. i.e. requires new NSD to be on boarded, associate the new NSD version with the running NS instance before the updates can be made to the instance

instantiateVnfData • vnfdId

• vnfFlavourId

• vnfInstantiationLevel Id

• vnfInstanceName

• vnfInstanceDescription

• extVirtualLinks

o extVirtualLinkId

o vimId

o resourceProviderId

o resourceId

o extCp

▪ cpdId

▪ cpConfig

• cpInstanceId

• linkPortId

• cpProtocolData

o extLinkPorts

▪ extLinkPortId

▪ resourceHandle

• vimId

• resourceProviderId

• resourceId

• vimLevelResourceType

• extManagedVirtualLinks

▪ extVirtualLinkId

▪ networkResource

• vimId


• resourceId


▪ extLinkPort

• extLinkPortId

• resourceHandle


vnfInstanceId and vnfProfileId used by inbuilt Orchestrator logic to identify the VNF instance

• additionalParams as workflow input

• vnfFlavourId, vnfInstantiationLevelId as topology input for VNFD

• externalVirtualLinks, extLinkPorts,extManagedVirtualLinks, ExtCpinformation, localizationLanguage passed to VNFM

INVOLVES CHANGES TO NSD FOLLOWED BY CHANGES TO NS INSTANCE


Update NS

removeVnfInstanceId IdentifierTHIS UPDATE INVOLVES CHANGES TO NSD FOLLOWED BY CHANGES TO NS INSTANCE. i.e. involves changes to NS Descriptor, requires new NSD to be on boarded, the new NSD version to be associated with the running NS instance before the updates can be made to the instance

changeVnfFlavourData • vnfInstanceId

• newFlavourId

• instantiationLevelId

• extVirtualLinks

o extVirtualLinkId

o vimId

o resourceProviderId

o resourceId

o extCp

▪ cpdId

▪ cpConfig

• cpInstanceId

• linkPortId

• cpProtocolData

o extLinkPortId

o resourceHandle

• vimId

▪ resourceProviderId

▪ resourceId

▪ vimLevelResourceType

o extLinkPorts

▪ extLinkPortId

▪ resourceHandle

• extManagedVirtualLinks

o extManagedVirtualLinkId

o vnfVirtualLinkDescId

o networkResource

o vnfLinkPort

▪ vnfLinkPortId

▪ resourceHandle

• vimId


• resourceId


• additionalParams

From NS perspective, the new DF of VNF is modelled in the service template of the VNF. This triggers a redo of substitution mapping of the VNF and causes a new VNF flavour to be added in the NS instance.


vnfInstanceId used by inbuilt Orchestrator logic to identify the VNF instance.

• Workflow input


• vnfInstanceId is used by inbuilt Orchestrator logic to identify the VNF

instance

• Orchestrator passes externalVirtualLink ,port , Cp information to

VNFM.

• newFlavourId,InstantiationLevelId : Topology inputs for VNFD


Update NS

operateVnfData • vnfInstanceId

• changeStateTo

• stopType

• gracefulStopTimeout

modifyVnfInfoData • vnfInstanceId

• vnfInstanceName

• vnfInstanceDescription

• vnfdId

• vnfConfigurableProperties

• Metadata

• extensions

THIS UPDATE OPERATES ON THE VNF INSTANCE OF THE NS INSTANCE DIRECTLY. changeExtVnfConnectivityDa

ta

• vnfInstanceId

• extVirtualLink


addSap o sapdId

o sapName

o description

o address

THIS UPDATE INVOLVES CHANGES TO NSD FOLLOWED BY CHANGES TO NS INSTANCE. i.e. requires the new NSD to be on boarded, associate the new NSD version with the running NS instance before the updates can be made to the instance

removeSapId THIS UPDATE INVOLVES CHANGES TO NSD FOLLOWED BY CHANGES TO NS INSTANCE. i.e. involves changes to NS Descriptor, requires new NSD to be on boarded, the new NSD version to be associated with the running NS instance before the updates can be made to the instance

addNestedNsData NestedNSData

• nestedNsInstanceId

• nsProfileId

THIS UPDATE INVOLVES CHANGES TO NSD FOLLOWED BY CHANGES TO NS INSTANCE. i.e. involves changes to NS Descriptor, requires new NSD

to be on boarded, the new NSD version to be associated with the running NS instance before the updates can be made to the instance


vnfInstanceId is used by inbuilt Orchestrator logic to identify the VnfInstance andpass the parameters to VNFM.



Orchestrator makes these API input parameters available for further processing

Orchestrator uses inbuilt logic to remove a Sap from the NS instance

Orchestrator uses inbuilt logic to remove NestedInstancefrom NS Instance


Update NS

removeNestedNsId Identifier

THIS UPDATE INVOLVES CHANGES TO NSD FOLLOWED BY CHANGES TO NS INSTANCE. i.e. involves changes to NS Descriptor, requires new NSD to be on boarded, the new NSD version to be associated with the running NS instance before the updates can be made to the instance

assocNewNsdVersionData • newNsdId

• sync

moveVnfInstanceData • targetNsInstanceId

• vnfInstanceId

THIS UPDATE OPERATES ON THE NS INSTANCE DIRECTLY.

addVnffg • vnffgdId

• vnffgName

• description


removeVnffgId Identifier


updateVnffg • vnffgInfoId

• nfp

• nfpInfoId

This update to NS instance involves changes to NS Descriptor, requires new NSD to be on boarded, the new NSD version to be associated with the running NS instance before the updates can be made to the instance.

In the case of addition of nfp, updates are done directly on the NS instance without involving changes to NSD.

changeNsFlavourData • newNsFlavourId

• instantiationLevelId

NS FLAVOURS ARE ALREADY DESCRIBED IN NSD, CHANGE IN NS FLAVOUR requires redo of SUBSTITUTION MAPPING FOLLOWED BY

API Inputs Additional comments

Inbuilt Orchestrator logic to remove the NestedInstance from the NS instance

Orchestrator associates the new version with the NSD

Orchestrator moves a Vnf instance to the target NS instance.

Orchestrator makes these parameters available for further processing

Inbuilt Orchestrator logic to remove the Vnffg from NS instance

Orchestrator makes these parameters available for further processing

Topology input


Update NS

addPnfData • pnfId

• pnfName

• pnfdId

• pnfProfileId

• cpData

o cpInstanceId

o cpdId

o cpProtocolData

THIS UPDATE INVOLVES CHANGES TO NSD FOLLOWED BY CHANGES TO NS INSTANCE. i.e. involves changes to NS Descriptor, requires new NSD to be on boarded, new NSD version to be associated with the running NS instance before updates can be made to the instance.

modifyPnfData • pnfId

• pnfName

• cpData

o cpInstanceId

o cpdId

o cpProtocolData

THIS UPDATE INVOLVES CHANGES TO NSD FOLLOWED BY CHANGES TO NS INSTANCE. i.e. involves changes to NS Descriptor, requires new NSD to be on boarded, new NSD version to be associated with the running NS instance before updates can be made to the instance.

removePnfId Identifier


updateTime


Orchestrator processes and makes these parameters available for further processing


Orchestrator inbuilt logic removes the Pnf from NS instance

Used by Orchestrator


Scale NSAPI Inputs NSD Mapping

scaleType

Used by Orchestrator

scaleNsData - vnfInstanceToBeAdded

o vnfInstanceId

o vnfProfileId

- vnfInstanceToBeRemoved

- scaleNsByStepsData

o scalingDirection

o aspectId

o numberOfSteps

- scaleNsToLevelData

- nsInstantiationLevel

- nsScaleInfo

o nsScalingAspectId

o nsScaleLevelId

- additionalParamForNs

- additionalParamForVnf

o vnfProfileId

o additionalParam

- locationConstraints

o vnfProfileId

o locationConstraints

o additional parameters are described as workflow inputs

o nsInstantiationLevel as topology input

o Location constraints utilized by Orchestrator

o nsScaleInfo, scaleNsToLevelData , scaleNsByStepsData processed and made available by

Orchestrator for further processing

o Inbuilt Orchestrator logic to identify vnfInstanceToBeAdded, vnfInstanceToBeRemoved

scaleVnfData - vnfInstanceId

- type

- scaleByStepData

o aspectId

o numberOfSteps

o additionalParam

- scaleToLevelData

o instantiationLevelId

o scaleInfo

o aspectId

o scaleLevel

o additionalParam

o additional parameters are described as workflow inputs of VNFD

o ScaleInfo, instantiationLevelId, scaleToLevelData , scaleByStepsData sent to VNFM


Heal NS

nsInstanceId Used by Orchestrator inbuilt logic to identify

the NS instance

healNsData - degreeHealing

- actionsHealing

- healScript

- additionalParamForNs

Additional Parameters are Workflow inputs

ActionsHealing - translated by the Orchestrator

to workflow actions/steps

degreeHealing - workflow input

healScript - translated by the Orchestrator as

workflow steps

healVnfData - vnfInstanceId

- cause

- additionalParam

Additional Parameters are workflow inputs

Orchestrator uses inbuilt logic to identify VNF

instance


Heal NS updates the NS instance directly


Terminate NS

nsInstanceId Identifier Used by Orchestrator inbuilt logic to identify

the NS instance

terminateTime Utilized by Orchestrator



How is the instance model updated with new topology template inputs?

❑ Orchestrator computes a different instance from the template with an updated input parameter

value at run time

❑ Orchestrator compares the desired and actual instance and computes the difference

❑ Orchestrator applies this difference by means of workflow

❑ How is the proposed “modify” operation different from this?


Summary

❑ API inputs can be:

❖topology template inputs

❖workflow inputs

❖Inbuilt Orchestrator logic/node_filter

❖Orchestrator processes some inputs and makes them available for further processing

❑ Some inputs are run time parameters and do not qualify to be stored in the instance model, they are

more appropriate to be described as workflow inputs e.g. for scaling , healing operations

❑ Some API calls require the descriptor to be updated , the new version of NSD to be on boarded, new

version of NSD to be associated with the NS instance before the instance model is updated.

❑ Some inputs are described as topology template inputs; require the Orchestrator to compute and apply

the “difference” to the instance model

❑ What would the proposed “modify” operation do?


Thank You

Documents

API input to NSD mapping...© Netcracker 2017 2 Goal The purpose of this study is to map the Os-Ma-nfvo API input parameters to Network Service Descriptor and identify whether a “Modify