Versions Compared

Old Version 1

changes.mady.by.user Pamela Dragosh

Saved on

compared with

New Version Current

changes.mady.by.user Alexander Vul

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Project Name:

  • Proposed name for the project:  Policy FrameworkDriven VNF Orchestration
  • Proposed name for the repository: 

            • policy/api - Policy CRUD and PEP enforcement client code

            • policy/common - common shared modules
            • policy/pdp - Policy Decision Engines
            • policy/pap - Policy Administration (Backend)
            • policy/gui - Policy Administration GUI (Frontend)
            • policy/docker - Policy docker image

Project description:

  • This project will be dedicated to determine how policy is captured, translated, deployed and updated when designing and on-boarding VNF's and network services.

Scope:

...

  • Classification of Policies
    • Placement
    • Resource allocation
    • Remediation Actions (eg. Scaling)
    • Compliance Checking (eg. Security)
    • SLA
    • Health
    • Control Loops
      • Support 3 Use Cases for Control Loop Policies
        • Residential Broadband Autohealing: Reboot/Restart, Rebuild (Future: Migrate/Evacuate)
        • vFW/vDNS: ModifyConfig, Scale up
        • VoLTE: Auto Scaling (Scale In/Out), Auto Healing (Reboot, Restart)
    • Platform Level Policies
    • Governance
      • Users
      • Customers
  • Deliver where/how Policies are expressed
    • Policy Domain Specific Language(s) (DSL) - work with the Modeling project to define how policy expressions are captured
    • Policy Design GUI - work with SDC project to integrate the Policy Design GUI during VNF/Service design for capturing Policy Expressions
  • Deliver requirements for Policy Conflict Detection and mitigation
  • Deliver requirements for capturing vendor-embedded policy (Stretch)

...

  • Identify how translation of DSL will work
    • Instantiation
    • Orchestration
    • Remediation
    • Controllers
    • Control Loop
      • DCAE Analytics, Collectors and Micro services: 
        • Design configuration policies and required models for the 3 Use Cases
      • CLAMP
        • Design operational policies for responding to Control Loop events for the 3 Use Cases
      • Controllers
        • Design, build and integrate required code to support 3 Use Cases for needed controller(s)
  • Identify how policy translation works
    • A common framework for the decision engines/languages used
    • The translation tools needing development
  • Identify the Enforcement points within ONAP to support the Use Cases
    • Common API design to support enforcement
  • Deliver points of interoperability for Day2Day Operations
    • Identify architecture, flow and API's for how operations teams can update/deploy/un-deploy Policies
  • Deliver points of interoperability to support Adaptive Policy (Stretch)
    • Reverse planning, inference rules, machine learning
  • Deliver architecture and points of interoperability for Policy Distribution
    • How Policy Decision Engines are deployed/un-deployed
    • What policies are supported in the various Decision Engines
    • Deliver API and flow for updating policy with the decision engines and the enforcement points

...

Some VNF products have been optimized to take advantage of hardware platform specific capabilities, such as NUMA or CPU pinning in order to maximize their performance and throughput. During VNF development, hardware platform requirements for such VNFs are defined in the "VNF descriptor" (i.e. VNF model) and stored in the VNF package (CSAR) as part of the CSAR metadata. When an "optimized" VNF is on-boarded and subsequently instantiated as part of a network service instance, it has to be deployed on specific compute resources that exhibit required hardware platform capabilities. Furthermore, some VNFs are implemented in a way that allows them to operate both in optimized and non-optimized manner, depending on resource availability, entitlements and licensing. Once instantiated, VNFs may require scaling or other remediation actions in order to maintain service levels. Additional VNF resources may need to be added or removed and existing resources may need to be "re-sized" or entirely replaced, depending on operating events and conditions.

This project will provide Policy Framework extensions to enable use of policy based constraints during instantiation, operation and remediation of VNFs. Given its cross-cutting nature and dependencies on other ONAP projects (see below), we are treating this project as a sub-project within the Policy Framework. 

Scope:

This project is limited in scope to changes and additions within the Policy Framework. Project deliverables will include:

  • A mechanism to handle ingestion of VNF vendor supplied operational policies specified in the VNF Model, and their federation with Operator-specified policies
  • Policy DSL support for specification of VNF centric policy constraints for:
    • Handling of VNF resource inventory/optimization
    • Homing and placement of VNF components
    • Allocation of VNF compute, storage and network resources
    • Handling of VNF remediation actions, including VNF scaling
  • This project will implement programmatic and declarative interfaces required to support:
    • Management of VNF related policies, including creation, modification and deletion
    • Ability to override/modify policies supplied as part of the VNF package metadata

...

Architecture Alignment:

  • How does this project fit into the rest of the ONAP Architecture?Please Include architecture diagram if possible

Image Added

NOTE - Functional components in RED DOTTED LINES denote project scope and dependencies


  • What other ONAP projects does this project depend on?
  • Modeling - provide input for Policy Expression
  • VNF SDK
  • SNIRO
  • SDC
  • Control Loop
  • CLAMP
  • DCAE
  • Orchestration
  • Controllers
    • Basically every component in ONAP should be policy-enabled
ProjectDependency
Policy FrameworkClosed loop policy specifications
Multi-VIMDiscovery of available VIM level compute resource capabilities
A&AIPersistence of VIM supplied compute resource hardware platform capabilities. Interfaces for access to persisted data.
SOEnforcement of VNF instantiation policies
APP-CEnforcement of VNF operation and remediation policies
VF-CEnforcement of VNF instantiation, operation and remediation policies
DCAE/HolmesCollection of data relevant to health and state of compute resource hardware platform level capabilities
SNIROEnforcement of VNF resource optimization policies
SDCExtraction and persistence of VNF vendor supplied hardware platform requirements


    • How does this align with external standards/specifications?
      • APIs/Interfaces
      • Information/data models
          • ETSI NFV IFA11
          • ETSI NFV SOL01
          • ETSI NFV SOL04
        • Are there dependencies with other open source projects?

      Resources:

      Other Information:

        • link to seed code (if applicable)
          • N/A
        • Vendor Neutral
          • Yes
        • Meets Board policy (including IPR)
          • Yes

      Use the above information to create a key project facts section on your project page


      Key Project Facts

      Project Name:

        • JIRA project name: Policy
        • Framework
        • Driven VNF Orchestration
        • JIRA project prefix:
        • Policy
        • policy-vnf

      Repo name:
      Lifecycle State: incubation
      Primary Contact:

      ...

      Alex Vul, Pamela Dragosh
      Project Lead: Alex Vul, Pamela Dragosh
      mailing list tag [policy-vnf] 
      Committers:
      pdragosh@research.att.com AT&T

      jh1730@att

      ...

      rs8887@att.com AT&T

      ...

      .com AT&T

      *Link to TSC approval: 

      Link to approval of additional submitters: