You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 28 Next »

This section describes how to design, develop, and submit a Virtual Network Function for use as a Network Resource in the OpenECOMP environment.

Additionally, this section includes an outline of actions to be taken by a service provider to design and deploy a Service containing a VNF.

The primary audiences for this documentation are

  • VNF providers: creators of VNFs (executables and related configuration files)
  • Acceptance personnel: thse tasked with certifying VNFs (approving them to run in OpenECOMP environments)
  • Service Designers: those who combine Virtual Functions (including VNFs) into Services in OpenECOMP
  • DevOps: those who deploy, operate, and monitor OpenECOMP Services containing VNFs

There are three stages in the life cycle of a VNF, shown here:

Figure 1. VNF complete life cycle stages

Reference Documents for VNF Providers

There are four reference documents for VNF Providers, summarized here.

<<DocRef: VNF Guidelines for Network Cloud and OpenECOMP>>

  • identifies audiences interested in VNFs
  • describes the VNF environment
  • gives an overview of requirements
  • points out differences between OpenECOMP VNFs and ETSI VNFs

<<DocRef: VNF Cloud Readiness Requirements for OpenECOMP (formerly: "Common Requirements...">>

  • design requirements (API versioning, decomposition, reliance on open source database, packet size limitations)
  • resiliency requirements
  • security requirements

<<DocRef: VNF Management Requirements for OpenECOMP>>

  • requirements imposed by the targeted network cloud infrastructure, including the hypervisor
  • identification requirements for the VNF and its components
  • configuration management requirements
    • a VNF must provide a Device YANG model
    • a VNF must implement a NETCONF server; the required NETCONF API's are referenced, and the supplier must demonstrate mounting the NETCONF server on OpenDaylight
  • monitoring and operations requirements
    • format of messages (event records)
    • frequency of reporting
    • security
  • licensing requirements

<<DocRef: VNF Heat Template Requirements for OpenECOMP>>

  • provides recommendations and standards for building Heat templates compatible with OpenECOMP

Example VNFs Included with OpenECOMP

The example VNFs distributed with OpenECOMP are:

  • vFW (Firewall)
  • vDNS (Domain Name Server).

The Demos page describes how to design and operate Services using these VNFs.

VNF Acceptance

Here is an outline of the steps used by a service provider to test a VNF and add it to the OpenECOMP inventory.

Pre-onboarding

  1. Create a tenant
  2. Validate VFs
  3. Generate manifest and package artifacts

Resource onboarding

  1. Create a license model
  2. Licensing
    1. Create a license key group [optional]
    2. Create an entitlement pool
    3. Create a feature group
    4. Create a license agreement
  3. Create a Vendor Software Product
  4. Update VFCs in a VSP [optional]
  5. Update a VSP [optional]

VF creation and testing

  1. Create a VF
  2. Update a VF [optional]
  3. Submit a VF for testing
  4. Test a VF

Designing a Service Using a VNF

  1. Create a service
  2. Create workflows [optional]
    1. Create a management workflow [optional]
    2. Create a network callflow [optional]
    3. Select VID inputs [optional]
  3. Update a service [optional]
  4. Submit a service for testing
  5. Test a service
  6. Assign an IP address plan

Governance Approval and Service Distribution

  1. Review a service for governance approval
  2. Request service distribution
  3. Distribute a service
  4. Verify that the blueprint is deployed

Closed Loop Design

  1. Design a model
  2. Collector
    1. Configure Collector
    2. Configure StringMatch
    3. Configure Policy

Policy Design

  1. Import a policy attribute dictionary [optional]
  2. Edit a policy attribute dictionary [optional]
  3. Add a scope
  4. Assign a scope to a user
  5. Create a policy
  6. Push a policy
  • No labels