Page History

...

• Internal NSD representation

TBD

...

NSD Mapping to SDC AID DM

...

SOL001

...

NSD mapping to/from

...

NS SDC AID DM

• There is no 1:1 mapping between the SOL001 tosca.nodes.nfv.VNF and The SDC NSD node type, org.openecom.resource.vfc.NSD, is modelled as a component of a VF to represent an allotted resource. But, it is not derived from the org.openecomp.resource.abstractvfc.nodes.VF.
  • SDC VF node types has very few properties.
  • a lot of common properties are added to each node type created by SDC
  • new common properties are mainly about networking and ONAP specific properties
• There is no clear mapping between the current node types
  • SDC creates new data type as ONAP deployment configuration.

...

• AllottedResource, either. 
• The SDC NSD might be designed for Volte use case support, and used by the VFC.
• It is recommended to deprecate the current SDC NSD node type, and to replace with SOL001 tosca.nodes.nfv.NSD node type.
• Solution:
  • SDC generates SOL001 tosca.nodes.nfv.

...

• • NSD node type
  • SDC takes SOL001 NSD with tosca.nodes.nfv.NSD node type as is, without mapping; i.e., no mapping is necessary
  • VFC uses the SOL001 NSD

VNFD Mapping to SDC AID DM

SOL001 VNF mapping to/from VNF SDC AID DM

• There is no 1:1 mapping between the SOL001 tosca.nodes.nfv.VNF and

...

• org.openecomp.resource.abstract.nodes.VF.
  • SDC VF node types has very few properties.
  • a lot of common properties are added to each node type created by SDC
  • new common properties are mainly about networking and ONAP specific properties
• There is no clear mapping logic between the current node types
  • SDC creates new data type as ONAP deployment configuration.

VF-Module Initial Input 

The following is a summary of initial input from Gil Bullard (AT&T).

...

• • • SOL001 concept of Aspect+ScalingDelta combination is one to one with the ONAP concept of VF Module.
    • SOL001 concept of VDU is one to one with the ONAP concept of A&AI vServer
    • SOL001 concept of a connection point associated with a VDU corresponds to the ONAP concept of the same name, as does the understanding of the meaning of “internal” versus “external” connection point.
    • ONAP-compliant SOL001 VNF Vendors will be obliged to name their HEAT files using a naming convention that encodes the SOL001 Aspect+ScalingDelta names
    • ONAP-compliant SOL001 VNF Vendors will be obliged to name their SOL001 Aspect+ScalingDelta parameters using a naming convention that readily maps to the corresponding HEAT properties.  
    • In addition, if AT&T has already deployed such a vendor’s VNF into its network, the HEAT naming will remain invariant, and (at least) the (AT&T version of that) SOL001 be written to match it.
  • What to do
    • ONAP will be extended to incorporate the constructs of Aspect and Scaling Level.  This includes SDC’s, SOs, and A&AI’s modeling of these constructs and A&AI's ability to capture and SO’s ability to set/update the "current scaling level" of a VNF for a given Aspect. 
    • If ETSI in their SOL001 VNFD had defined a "ScalingDelta" in a straightforward manner, i.e., in terms of the VNFCs that comprise it, then it would be very easy to extract VF Module information from the VNFD.  (I would like to see ETSI define "ScalingDelta" in this manner, as opposed to the current way they do so. )  However, given that they did not, ONAP SDC would need to be extended to derive the VF Module “structure” from the SOL001 document through the algorithm below.  “Structure” in this case includes the VDU topology, connection points and associated parameters.  This algorithm will:
    • Determine the set of Aspects and corresponding VDUs and associated ScalingDeltas (step_deltas) from the SOL001.
    • Determine the set of ScalingLevels associated with each Aspect and the ScalingDeltas associated with each.
    • Translate the VDU-centric representation of ScalingDeltas (step_deltas) as per SOL001 to come up with a ScalingDelta-centric representation that captures the number and type of VDUs associated with that ScalingDelta across the various VDU types.
    • Create a VF Module object that corresponds to each ScalingDelta-centric representation of a ScalingDelta calculated above.
    • Fill in the details of the VF Module object based on the SOL001 data to represent the VDU connection points, associated Networks (internal or external), and associated Parameters.
    • Determine if there is an the artifact in the SOL004 package that is a HOT YAML whose file name corresponds (through a VNF vendor obligatory naming convention) to the Aspect+ScalingDelta from which this VF Module object was derived.  If so, associate that HOT file with the VF Module.
    • Name the VF Module based on a naming convention to capture the Aspect+ScalingDelta names
    • Determine and capture the mapping from each Aspect + ScalingLevel model for the VNF to the corresponding VF Module.
    • Given a desired state Aspect+ScalingLevel, will be able to calculate (from the SDC distributed mapping of Aspect+ScalingLevel to VF Module along with the current Scaling Level for this Aspect as per A&AI) the (ordered set of) VF Module(s) needed to take that VNF from the “current scaling level” to the desired level for that Aspect.
    • Note:  As an aside, SDC enhancements are being discussed. It is not clear if the SDC changes will be available in the Dublin time frame. some “stubbing off” SDC with a simulator could be suggested to at least prove in the run-time aspects of the solution.

...

VirtualLink Mapping to SDC AID DM

...

SOL001

...

SDC AID DM

VL mapping to/from VL SDC AID DM

• Each vendor/operator defined their own VL node types (e.g., tosca.nodes.nfv.ext.zte.VL)
• The vendor/operator-specific node types have no direct 1:1 mapping to tosca.nodes.nfv.NsVirtualLink
• Solutions
  • Deprecate vendor/operator-specific VLs
  • Use SOL001 tosca.nodes.nfv.NsVirtualLink
  • ONAP SO NFVO uses the SOL001 tosca.nodes.nfv.NsVirtualLink
  • VFC needs to adapt SOL001 tosca.nodes.nfv.NsVirtualLink

...