Project Name:

• Proposed name for the project: OpenSource Access Manager

• Proposed name for the repository: osam

Project description:

OpenSource Access Manager is a vendor agnostic operation suite for managing consumer broadband network elements and capabilities disaggregated from proprietary monolithic Access Network hardware and Element Management Systems (EMS).

...

Access network is broken down into central and edge deployments.  Some functions of the control and management will be located centrally and some may be located at the edge in support of access.

Central Compute

• User interfaces in support of access.
  • Common ONAP interfaces (Portal, SDC, VID, OOM, CLAMP, CLI) will be reused
  • UI for Broadband Subscriber Access Network devices and Services
  • Reuse of ElasticStack (Kibana, Log Stash and Elastic Search)
• Reuse of the common ONAP functions (In addition to above - limited to the context of access)
  • AAI
  • DCAE
  • SO 
  • DMaaP
  • AAF
  • Policy
   

Generally Edge Compute (Could be with Central Compute)

• User interfaces in support of access.
  • Common ONAP interfaces (Portal, SDC, VID, OOM, CLAMP, CLI) will be reused
  • UI for Broadband Subscriber Access Network devices and Services
  • Reuse of ElasticStack (Kibana, Log Stash and Elastic Search)
• Reuse of the common ONAP functions (In addition to above)
  • DCAE
  • SO 
  • DMaaP
  • AAI
  • Policy
  • APP-C
  • SDN-C
  • Multi-Cloud VIM
• Access Specific Functions
  • DSC- OSAM - Control for Dynamic Control & User
  Control
  • Plane
    • Incudes the subscriber Virtual Tenant Network
    • Authentication Tenants
    • Subscriber DHCP Relay
    • Subscriber BNG Associations 
  • OSAM - HA - Network Abstraction Layer for Access Devices
  • FreeRADIUS for Subscriber 802.1X authentication
  • OpenLDAP for Subscriber policies and configurations 
  • OSAM Collector for DCAE
  • OSAM Analytics for DCAE

User stories/

...

Requirements

• Access Network services will operate as containers generally in an edge cloud environment utilizing Docker containers.
• Edge Network services will utilize Kubernetes and K8 models
• Virtualized Access containers will be deployed and lifecycle managed by ONAP core components
• Services provided for the Virtual Access Network will be orchestrated through SO

Operational User Interface - Functionality:

•    Pulls resources, interfaces and data elements from ONAP, DCAE and JSC into a cohesive interface supporting the Access Network Infrastructure.

•    Configure settings exposed by API against 1 or more devices and services

•    Ability to bulk execute a list of devices against exposed services including (Node-Red/Directed Graphs)

    o    Services directly imported into interface once deployed

•    A view of error details for functions/devices streaming with related hot links into the low level details (e.g. Abstraction Layer, OLT, Port, ONU, ONU Uplink Port, ONU UNI Ports, DPU,  CPE, MicroServices, and future components)

    o    Advanced text and regular expression based filters based on device names or event details

    o    Time range based filters

•    Customizations

    o    Customizations by a user, group or system level

    o    Context sensitive interface changes driven by exposed APIs

    o    Ability to store and share views

    o    Ability for a user to load multiple views at the same time

•    Single application for Network visualization with integrated  analytics from DCAE, Elastic Stack and Grafana

    o    Operational dashboard showing geographic distribution of the network and services health (“Heat Map”)

    o    Established links between devices/service management and the graphical representations

•    Interface for scheduling and coordinating access related devices and software

    o    Firmware Release Management and Upgrades

    o    Snapshot management of Access devices and configurations

          This will be utilized for comparison, restoral and migration activities

    o    VNF Service Versioning Management at a collection or subscriber level

    o    User Migration flows in coordination with Firmware and VNF release management

    o    Rollback and notification under failure conditions or forced action

    o    Ability to create collections of subscribers, VNFs, and devices

    o    Configurable Maintenance Window

    o    Ability to operate in serial or parallel at the collection level

    o    Ability to establish dependencies prior to execution

•    Support for systems, network, software, service and configuration segmentation (slicing)

    o    Can be configured by Global, Site, DMA, Service Type or Device Type and each being subdivided by Release Type

    o    Support different lifecycle states of software, firmware and configuration within

        * Examples Crawl, Walk, and Run methodology of deploying changes

        * Examples Development, Test, Incubation, and Production state of services

    o    Software Versions, Firmware, Policies, and configurations should be configured as a package

        * Deployed for a specific set of hardware

        * Ability to manage hierarchical configuration management and version controlled

    o    Tool for viewing historical changes, comparison, events, and health of a segment

Service Engines and Message Routing for the Access Network:

•    Application Interfaces exposed to north bound systems are simplified to Create, Read, Update and Delete (CRUD) functions for subscriber associated services

•    Global

    o    Provides the high level APIs that span multiple local sites and interactions with the centralized ONAP sites

    o    The Message routing will be planned to be built on the ONAP’s Direct Messaging Engine (DME)

    o    The service engine will be planned to be built on the ONAP JSC Service Framework

    o    Global Access Network Related Flows will be built utilizing Directed Graphs

    o    Provides data caching and on-demand fetch of data elements on ONAP and Local Access Services

        *   APIs can be setup with a cache, lifespan and scope (user/group/all)

        *  Cache will reload using an on-demand fetch update model

•    Local

    o    Exposes the mid-level APIs to be utilized for the Edge devices and services

    o    The service engine will be planned to be built on the ONAP JSC Service Framework

    o    Local Access Network Related Flows will be built utilizing Directed Graphs

    o    JSC will be the point of entry from the global sites for service instantiation flows

Data Store consists of the data store for the access subscriber data. Functionality:

•    Object based storage system built on existing OpenSource Object Storage technology deployed for ONAP Inventory system AAI.

•    Isolation of data from the AAI in order to ensure subscriber data stores do not impact ONAP operations and to limit subscriber data access

•    Hierarchical and horizontal scalability to support billions of subscribers and access elements (physical and virtual)

    o    Subscriber Information, Security and Polices

        *    This information will likely be stored in an existing BSS when integration into a carrier network, but will be needed for ONAP implementation

    o    Physical plant assets

    o    Access Physical and Virtual Infrastructure and Service components

    o    Subscriber Services and Service Chains

Components utilized from Open Networking Foundation (ONF) project

•    Access Application and Tenants

•    VOLTHA hardware abstraction providing disaggregation of many of the functions currently performed by OLT hardware

    o    Protocol Abstraction and Multi-Access API uniformity

    o    Device persistence

    o    Data Harmonization

Other components

•    Message Bus for event and counter collection

•    RADIUS for authentication by the fixed access network

    o    Integrated through a module within the access network controller.

•    VES data collection agents in Application Containers to provide system analytics to DCAE

    o    Events will be allocated to different DMaaP topics and partitions based on model driven classification to improve efficiency of event processing by Closed loop

•    Nagios for System, VM and Container Alerting and Monitoring

•    Zero Touch Provisioning flows are being defined and will be added to the scope of this document and will impact several components of both the Access Module and ONAP [TBD]

•    Access services, models and flows will be part of an Access module that are deployable on top of the ONAP framework with impacting the core ONAP requirements and functionality.

Access Integration into ONAP

•    Infrastructure Initialization Policies

    o    SDC and TOSCA Models

        *    TOSCA Models created for the Access Network Components

        *    Service Policy creation of the operation health and scaling

    o    MSO and HEAT Templates

        *    HEAT templates for initializing the VM/Containers, Underlay network in support of the Access Network

    o    VIM

        *    VIM will be used to manage and configure the VM/Containers

        *    VIM will not be directly interface, but interface from the Service Engines (SE) through the MSO

    o    SDN-C and Directed Graphs for in support of the underlay network

•    DCAE / DMaaP

    o    Data collection and migration to central data lake

        *    Data collection will contain information about the virtualized access hardware, software, VMs, containers, network and physical nodes

    o    Interface for Network visualization through Grafana in the Access Network

    o    Tracks the utilization of the network and compute resources

        *    The information is correlated with the Access Data Store to associate to the subscriber’s service chain

    o    Aggregate subscriber capacity reports are to be processed by DCAE

        *    DCAE will require interface or feed from the Access Data Store

•    AAI     

    o    Stores the underlying VM/Container inventory and network inventory including the relationships between elements.

    o    The information will be needed by the Web Service Framework (JSC) and associated to the Access Data Store housing the physical access elements, subscriber interfaces (e.g. xDSL, Ethernet, ONT, G.FAST, etc.), network interface, profiles and services.

•    CLAMP

    o    Policy Rules and Execution Development

        *    Subscriber based profile management will be executed in the Access Applications

•    When profile SLAs are not being met a message is communicated on the DMaaP in a dedicated Topic.  Control Loop polices would be configured using CLAMP to detect messages placed on DMaaP.

    o    Fault Detection

    o    Auto-Scaling

•    Scheduler

• VNF Management functions will be controlled by APPC
• Inventory for the access domain will be modeled for AAI
  • Tenant service relationships will be modeled in AAI between OSAM - Control and OSAM - HA
  • Broadband Subscriber profiles will be modeled for AAI
  • AAI will be the DOR for the Broadband Subscriber profiles, but pulled to a domain specific OpenLDAP system
• TOSCA resource models, K8's, Service Models, Images will be created for the OSAM components
• OSAM-UI (Suite of Docker based microservices)
• OSAM-Control (Karaf based Controller)
• OSAM-HA (Suite of Docker based microservices)
  • VOLTHA Core, NETCONF Server, REST Ser 
• FreeRADIUS
• OpenLDAP
• OSAM Collector Agent
• OSAM Analytics Agent 
• Subscriber Broadband Service  
• Access related flows will be modeled in BMPN2 for the SO
• SDC will distribute
  • SDC→SO: Distribute the Service Template(s)
  • SDC→AAI: Distribute the Inventory Model(s)
  • SDC→SDNC: Distribute the network underlay connectivity
  • SDC→APPC: Distribute the Directed Graph(s)
  • SDC→Policy: Distribute the policy Template(s)
    • Initial focus will be limited to Threshold Crossing Analytics
  • SDC→DCAE: Distribute Configuration(s)
  • SDC→DMaaP: Distribute the topic and partition configuration(s) 
• SO Flows
• Add/Update/Remove Broadband Subscriber
• Add/Remove VNFs
• Migrate Broadband Subscriber Services
• Scale Up/Down OSAM-Control and OSAM-HA
  

DSC/OSAM-Control

• Integration of existing Domain specific controller for broadband subscriber services 
• Provides dynamic control & user plane capabilities
• Provides REST/OpenAPI Spec Interfaces
• Provides 802.1X for RADIUS authentication
• Provides the DHCP Proxy and Client Agent
  • This may differ by implementation
• Provides the mapping from the Subscriber to the BNG 
• Log data provided by Kafka. 
  • Data will be mediated through a VES converter (OPNFV) to the DCAE Collector agent  

OSAM-HA

• Integration of existing Domain Specific abstraction layer that provides uniform access to Broadband Access hardware
• Provides REST/OpenAPI Spec and NETCONF/YANG Interfaces/Models
• Log data provided by Kafka. 
  • Data will be mediated through a VES converter (OPNFV) to the DCAE Collector agent  

• VOLTHA hardware abstraction providing disaggregation of many of the functions currently performed by OLT hardware

  • Protocol Abstraction and Multi-Access API uniformity

  • Device persistence

  • Data Harmonization

 OSAM Collector Agent

• Built off of the DCAE collector agent framework
• Receives the VES data from the OSAM-Control and OSAM-HA
• OSAM-Control→Kafka→VES Adapter→DCAE Collector Agent→DCAE
• OSAM-HA→Kafka→VES Adapter→DCAE Collector Agent→DCAE
• Provides data to DCAE

OSAM Analytics Agent

• Built off of the DCAE collector agent framework
• Receives the VES data from the OSAM-Control and OSAM-HA
• Provides Analytics for Access and interacts with the Policy Framework
• Existing Threshold Crossing analytics and policies will be reused and models will be built to reference a scaling SO developed OSAM 

Service Orchestration

• Carriers need the ability to create, update and remove broadband subscriber instances from the virtualized access components
  • The interactions with the access components will be orchestrated through SO
• Carriers need support for orchestration on the edge where limited ONAP infrastructure will exist
• The flows will interact with AAI to retrieve the inventory of the access network
•  Carriers need the ability to manage the firmware on the physical device with coordination with the disaggregated network services
• Flows will need to make coordinated events to ensure the network services are moved, restored and tested 

OpenLDAP

• OpenLDAP will store the subscriber authentication and profile information
• SO will interact with OpenLDAP for updating the subscriber data, security and service profiles
• System will be utilized as a reference implementation and not intended for production use
• This functionality is isolated from ONAP capabilities to support scale of the broadband authentication processes

OSAM-UI

While the goal is to automate and centralize as much as possible, operations will still need tooling to diagnose and manage all of the edge and deep edge environments. 

• User interface provides capabilities for operations to manage and diagnose problems in the access network.
• Provides a view of the relationship of broadband subscriber services and health of the service chain
• Provides a centralized view of the access network deployed at edge compute locations
• User interface will leverage the Portal SDK.
• Security will utilize groups and roles created in AAF
• Interface to AAI APIs to pull OSAM Network Resources
• Ability for operations to build and deploy advanced services utilizing Node-Red that directly interact with the OSAM-UI
• Interface allows for the bulk execution of flows against many devices and services selected in the OSAM-UI against an enabled service
  • Services are automatically enabled through the management UI using OpenAPI specs generated from Node-Red
• A view of error details for functions/devices streaming with related hot links into the low level details (e.g. Abstraction Layer, OLT, Port, ONU, ONU Uplink Port, ONU UNI Ports, DPU,  CPE, MicroServices, and future components)
  • Advanced text and regular expression based filters based on device names or event details
  • Time range based filters
• Customizations
  • Customizations by a user, group or system level
  • Context sensitive interface changes driven by exposed APIs
  • Ability to store and share views
  • Ability for a user to load multiple views at the same time
• Single application for Network visualization with integrated  analytics from DCAE, Elastic Stack and Grafana
  • Operational dashboard showing geographic distribution of the network and services health (“Heat Map”)
  • Established links between devices/service management and the graphical representations
•  Interface for scheduling and coordinating access related devices and software
  • Firmware Release Management and Upgrades
  • Snapshot management of Access devices and configurations
  • This will be utilized for comparison, restoral and migration activities
  • VNF Service Versioning Management at a collection or subscriber level
  • User Migration flows in coordination with Firmware and VNF release management
  • Rollback and notification under failure conditions or forced action
  • Ability to create collections of subscribers, VNFs, and devices
  • Configurable Maintenance Window
  • Ability to operate in serial or parallel at the collection level
  • Ability to establish dependencies prior to execution

• Support for systems, network, software, service and configuration segmentation (slicing)

  • Can be configured by Global, Site, DMA, Service Type or Device Type and each being subdivided by Release Type

  • Support different lifecycle states of software, firmware and configuration within

    • Examples Crawl, Walk, and Run methodology of deploying changes

    • Examples Development, Test, Incubation, and Production state of services

  • Software Versions, Firmware, Policies, and configurations should be configured as a package

    • Deployed for a specific set of hardware

    • Ability to manage hierarchical configuration management and version controlled

  • Tool for viewing historical changes, comparison, events, and health of a segment

    o    Coordinates subscriber migrations and software updates.Image Added

Architecture Alignment:

OpenSource Access Manager is a domain specific management and services stack interfacing and interacting with the core ONAP capabilities that support and maintain the underlying virtual and physical infrastructure.

...

OpenSourceAccessManager_ONAP_2.png•    How

How does this project fit into the rest of the ONAP Architecture?

...

• ONAP manages the physical infrastructure hosting the virtual network function and the underlay network.

...

• Access Management will leverage many of the existing infrastructure components (AAI, DME, JSC, and Directed Graphs).

...

• Access Network Models, Flows and API’s will be developed as part of the project.

...

...

How

...

does this align with external standards/specifications?

...

• Alignment with the ONF, OpenAPI, BBF, IETF and ITU Standards

...

Are there dependencies with other open source projects?

...

• Integration with the VOLTHA projects in ONF

...

• Integration with the OSAM - Dynamic Control & User Plane

Impacts:

ONAP Components: 

...

S3P:

The project is an effort to utilize the Dynamic Control & User Plane and Hardware abstraction efforts developed with the ONF community.  OSAM is not targeted to change any of the core ONAP components.

Scale:

Access Network functions are built to cluster horizontally and scale to meet carrier performance and response requirements.

...