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

Compare with Current View Page History

« Previous Version 8 Next »

Project Name:

  • Proposed name for the project: APPC
  • Proposed name for the repository: appc

Project description:

Model and policy driven application controller with intrinsic VNF management capabilities.

Support of multi vendor system of VNFs with interdependence  between them. 

Provide uploading capabilities of  standard data model which describe the management, configuration and inter-dependencies of the VNF.

APPC model will be based ONAP Tosca and Yang and contain dependency model , LCM recipes , configuration templates , policies etc.

APPC provide multi protocol south bound plugin , including NETCONF ,Chef, Ansible  and ability to provide vendor specific VNFM/EMS adaptation plugin.

APPC provide VNF configuration repository with latest working configuration for each of the VNF instances it is responsible for.

Scope

  • Support for ONAP use cases V-VOLTE and VCPE
  • Provide Generic VNF  LCM commands for NB consumers (SO , Policy ,CMO, DCAE etc) . 
    • LCM commands implementation will use the uploaded VNF model for infer the execution protocol and workflow. 
    • Design time ability for attach recipe to specific VNF LCM  command implementation (DG based).
  • Provide model driven configuration API composed from Yang based VNF configuration model and  set of templates which maps the payload to the VNF configuration protocol.
    • Provide configuration repository APIs getLatestConfig , configAudit etc
  • Manages the VNF operational state including blocking/Sequencing/throttling and conflict resolution for LCM requests 
  • Provide flexible deployment options such as HA ,single node or geo distributed deployment

Proposed Architecture:

Architecture Alignment:



  • How does this project fit into the rest of the ONAP Architecture?
    • Expansion of existing ONAP component and expanding  it for more complex use cases.
    • Depends on SDNC framework  which is used as the base platform for the controller.
    • Depends on SDC for generating the model and other artifacts necessary for specifying controller runtime behavior
    • Depends on Multi VIM project for cloud infrastructure APIs
        
  • How does this align with external standards/specifications?
    • Inspierd by ETSI NFV LCM signatures
    • Use TOSCA and YANG for its model definition.
    • Use Netconf/Chef and Ansible for component SB interface 
  • Are there dependencies with other open source projects?
    • Opendaylight (part of ONAP controller framework )

Resources:

  • Primary Contact Person -Reuben Klein  AT&T
  • Avi Chapnick - Amdocs
  • Hector Anapan - AT&T
  • Jamil Chawki - Orange
  • Vimal Begwani - AT&T
  • Paul Bartoli - AT&T
  • Marcus Williams - Intel

Other Information:

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


Key Project Facts

Project Name:

  • JIRA project name:
  • JIRA project prefix:

Repo name:appc
Lifecycle State:Seed
Primary Contact: Reuben Klein
Project Lead: Hector Anapan-Lavalle
mailing list tag [Should match Jira Project Prefix] 
Committers:
avich@amdocs.com

ha076r@att.com

Marcus Williams marcus.williams@intel.com 


*Link to TSC approval: 
Link to approval of additional submitters: 

  • No labels