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

Compare with Current View Page History

Version 1 Next »

Project Name:

  • Proposed name for the project: Policy Framework
  • 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:

  • Deliver points of interoperability within ONAP for VNF and network service On-boarding to capture policy/rule expressions VNF vendor specific policies and network service policies.
    • 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)
  • Deliver points of interoperability within ONAP in which captured policies are translated into enforceable actions/outcomes
    • 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
  • Support new policy related to the scaling and healing in VoLTE use case
    • How to design scaling and healing policy with Policy Designer
    • How Policy Designer and Policy Decision Engines use

Architecture Alignment:

  • How does this project fit into the rest of the ONAP Architecture?
    • Please Include architecture diagram if possible
    • 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
  • How does this align with external standards/specifications?
    • APIs/Interfaces
    • Information/data models
  • Are there dependencies with other open source projects?

Resources:

  • Primary Contact Person
    • Pamela Dragosh - AT&T
  • Names, gerrit IDs, and company affiliations of the committers
    • Pamela Dragosh - AT&T
    • Jorge Hernandez-Herraro - AT&T
    • Ralph Straubs - AT&T
    • Jim Hahn - AT&T
  • Names and affiliations of any other contributors
    • Alex Vul - Intel
    • Avinash S - Huawei
    • Nermin Mohamed - Huawei
    • Bobby Mander - AT&T
    • ding yi-ZTE
    • xinyuan wang-ZTE
  • Project Roles (include RACI chart, if applicable)

Other Information:


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
  • JIRA project prefix: Policy

Repo name:
Lifecycle State: incubation
Primary Contact: Pamela Dragosh
Project Lead: Pamela Dragosh
mailing list tag [policy] 
Committers:
pdragosh@research.att.com AT&T

jh1730@att.com AT&T

rs8887@att.com AT&T

jh7358@att.com AT&T

*Link to TSC approval: 

Link to approval of additional submitters: 

  • No labels