Page History

...

• VNFM Adapter conforms to the SOL001/SOL004 standards of specification and package management and SOL003 lifecycle operations.

  • Note: in Dublin, SDC does not support SOL004 VNF package yet. SO and SO VNFM Adapter design around SOL004 handling is simplified or deferred to the El Alto release.

• Design Scope for Dublin

• • Epic and Use CasesStories
  • VNFM Adapter Design
  • SOL001/SOL004 Support & Design
  • SO BPMN Infra & VNFM Adapter Run-time Scenario
  • SOL003 API Support
  • SO VNFM Adapter SOL003 API Support Design
  • VNFM Adapter VNF Package Management (Not part of Dublin)
  • SDNC Assignment Management
  • VNFM Adapter Locating SVNFM
  • VNF Life-cycle Granting
  • VNFM Adapter Homing Decision for VNF Granting (TBD)
  • SVNFM Simulator

• Epic

...

• VNFM Adapter VNF Flow Design (Run-time Scenarios)

  • The following diagram depicts VNF flow designflows thru SO VNFM Adapter.

• VNFM Adapter Run-time Scenarios

• • The following diagram depicts BPMN Infra and VNFM Adapter Run-time scenarios.

Image Removed

• 
  
  1. SO BPMN Service workflows dispatch new resource-level workflows based on VNF request parameters (e.g., type, others).
     1. Once a Service workflow chooses a new workflow path for VNFM Adapter, the subsequent requests for the same VNF will follow the new path.
     2. an association between VNF and VNFM will be made in A&AI.
  2. SO BPMN VNF-level resource workflows handle:
     1. Assign VNF and VF-Module Network to SDNC
     2. Retrieve the VNF and VF-Module Network Assignment from SDNC
     3. Invoke VNFM Adapter Client with required parameters
  3. VNFM Adapter Client manages:
     1. Populate parameter structures based on data from SO workflows
     2. Invoke VNFM Adapter NBI with required parameters
  4. VNFM Adapter gets GenericVNF from A&AI
  5. VNFM Adapter locates the corresponding VNF and VNFM registration info form A&AI (ESR). Two methods are suggested
     1. Current one: based on VNF NF Type and VNFM Type in A&AI
     2. Could use VNFD vnfm_info:type, VNFM registration values: VNFM type, Cloud Region, vendor - logic is being designed
  6. VNFM Adapter gets VimConnectionInfo from A&AI
     1. Queries A&AI based on the cloud region and tenant id
     2. Builds the VimConnectionInfo based on the type, service-url, user-name, password, cloud-domain, etc.
  7. VNFM Adapter uses network assignment (e.g., IP Address) from SO (thru SDNC) and builds the extVirtualLinks and other parameters.

...

• • • 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.

• SO BPMN VNF Workflow

  • A new New VNF-level Building Block workflow workflows will be created.

  • Create and Instantiate VNF workflow (EtsiVnfInstantiateBB.bpmn)

...

• • Delete VNF workflow (EtsiVNFDeleteBB.bpmn)

• SO BPMN VF-Module Workflow (not for Dublin)

  • For ETSI-based VNF package, VF-Module level workflows will NOT be used. 

  • SO VNFM Adapter will interface with SVNFM at the VNF level.

...

• • SOL003 Interfaces between VNFM Adapter (Client) and SVNFM (Provider)

           Note: for the interface details, see the VNFM Adapter APIs, 

SO VNFM Adapter APIs

.

• • • Create VNF

      • HTTP Method Type: POST

      • VNFM Endpoint: /vnf_instances/

      • Request Payload: CreateVnfRequest

      • Response Header: 201 success

      • Response Body: VnfInstance

...

• • • • • Population of User Inputs for SOL003 Instantiation. Two options are discussed and the Option #1 is chosen for Dublin for simplicity. It will be revisited for the El Alto release. 
          • Option #1. Preload configuration solution (it would be an option for the Dublin release)
          • • For the VNFD, pre-configure the mapping between the external virtual links and the ip addresses
            • VNFM Adapter retrieves the mapping from preload data and fill up the extVirtualLink parameters based on the mapping
          • Option #2: model-driven user data population from UI (which is attached to VID) - TBD deferred to the next release.
            • The external virtual links user input is shown for illustration purposes. 
            • VNFD does not define external virtual links, but it lists the external virtual links as requirements for the VNF.
              • If the connection point ip_address_assignment is set to false, no extVirtualLinks ip address assignment is necessary.
              • In this case, VIM will assign IP addresses dynamically.
              • This could be an option for the Dublin release for simplifying the solution.

...

• • • • • • • If the connection point ip_address_assignment is set to true, set extVirtualLink ip address assignment with configuration data from the user input or a preload file.
              • UI solution (build an UI configuration page and invoke it from VID; it would be an option for the post Dublin release): Impact on VID (open issue)
              • Parse VNFD and extract a list of external virtual links
              • Map the external virtual links to the corresponding connection points, and read ip_address_assignment and number_of_ip_address value
              • Render the external virtual links
              • For each external virtual link, render the ip_address_assignment entry fields based on the number_of_ip_address value
              • User configures the mapping and the UI stores the mapping in the database
              • VNFM Adapter retrieves the mapping from database and fill up the extVirtualLink parameters based the mapping
              • UI Example:

• • • VNFM and GenericVNF relationship

• • • • Trace which VNFM instance managed which VNF instance, the following rule will be added to A&AI DB Edge (DbEdgeRules_esr_v15.json, DbEdgeRules_esr_v16.json).

        • {
          "from": "generic-vnf",
          "to": "esr-vnfm",
          "label": "tosca.relationships.DependsOn",
          "direction": "OUT",
          "multiplicity": "MANY2ONE",
          "contains-other-v": "NONE",
          "delete-other-v": "NONE",
          "prevent-delete": "NONE",
          "default": "true",
          "description":""
          }

      • SO VNFM Adapter will update the relationship between generic-vnf and esr-vnfm based on the rule.

• • • Query VNF Instances (deferred to El Alto)

      • HTTP Method Type: GET

      • VNFM Endpoint: /vnf_instances  (for multiple VNFs), /vnf_instances/{vnfInstanceId}  (for single VNF)

      • Request Payload: not applicable

      • Response Header: 200 success

      • Response Body: VnfInstance[] (for multiple VNFs), VnfInstance (for single VNF) 

• • • • Design
        • If the VNFM Adapter intends to query all VNF instances, it sends a GET request to the "VNF instances" resource
        • The VNFM returns a "200 OK" response to the VNFM Adapter, and includes zero or more data structures of type "VnfInstance" in the payload body
        • If the VNFM Adapter intends to read information about a particular VNF instance, it sends a GET request to the "Individual VNF instance" resource, addressed by the appropriate VNF instance identifier in its resource URI
        • The VNFM returns a "200 OK" response to the VNFM Adapter, and includes one data structure of type "VnfInstance" in the payload body

...

1. 1. 1. 1. 1. 1. VNFM sends a POST request to the Grant resource with a “GrantRequest” in the body
               2. VNFM Adapter with SO returns to VNFM a “202 Accepted” response with an empty body, and a “Location” header indicates a callback URL
               3. VNFM Adapter with SO makes the granting decision
               4. VNFM keeps trying to obtain the grant by sending a GET request to VNFM Adapter until a “200 OK” response with a “grant” data in the body
               5. VNFM Adapter finishes the granting process and returns a “200 OK” response with a “Grant” data in the body

• • • • VNFM Adapter

        Homing Decision for

        VNF Granting

• • • • • In Dublin, the homing data will be collected during the service decomposition procedures in SO workflows. The SO VNFM Adapter will receive the homing data from the SO workflows. 
        • Some models do not have homing models and policies; i.e., use of OOF is optional. In that case, the SO VNFM Adapter will make a gran decision based on VIM registration, cloud region. 
        • The following concept is based on the current VFC granting mechanism. In the Dublin, the mechanism is not used.

1. 1. 
      
      1. 1. 1. 1. 1. VNFM Adapter sends out homing requests to OOF (OSDF) containing resource info
                  2. OOF (OSDF) pulls all the related homing constraints from Policy
                  3. OOF (HAS) checks AAI database to pull region (flavor) information
                  4. OOF (HAS) communicates with Multi-Cloud to check cloud capacity (vims which fulfill the requirements)
                  5. OOF (OSDF) returns homing allocation solution to VNFM Adapter

...