Description:

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).

A key component to simplify multi-vendor support is a mediation layer currently under development called VOLTHA (ONF open source project).  VOLTHA uses low-level abstraction of the network device to provide a simplified approach to higher level management and analytics.  Currently xPON and G.FAST are the initial products under active development in collaboration with ONF. 

Scope:

For Casablanca, OSAM will showcase the management of the Access Peripheral POD (located in Telco Central Offices) as a PNF. Should provide monitoring capability and support 100’s of thousands of Access Peripheral POD deployment in Telco office.

Subscriber management/activation will be contained within the POD and outside the scope of ONAP.

OpenSource Access Manager module for ONAP consisting of the OA&M User interface OpenSource Access Manager is a domain specific module for ONAP consisting of the OA&M User interface, flows, web services and microservices in support of virtualized multi-access network for consumer broadband services.  At a high level, it divides into global and localized functions to operate at large scale and performance for edge networks.  The major components of Access Module that do not exist in ONAP today are the user interface (UI), the carrier grade access controller and hardware abstraction though OSAM-HA (ONF: VOLTHA).  .  Access specific data models, services, and flows will be built on existing ONAP components and may feed additional requirements.  The infrastructure elements, services, flows, data collection processes will be utilized and existing or planned feature sets should not be impacted.

Below are the functions of access network needed on top of the infrastructure services that are already provided as part of ONAP.  The requirements for Access will be isolated to the Access Module to not impact the core ONAP capabilities and deliverables.

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 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/WIP:

• 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

    o    Coordinates subscriber migrations and software updates.

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.

Image Removed

OpenSourceAccessManager_ONAP_2.png

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

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

    o    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.  

    o    Utilizes : SDC, AAI, Scheduler, MSO, DCAE, Policy, CLAMP, VID and DMaaP

•    How does this align with external standards/specifications?

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

•    Are there dependencies with other open source projects?

    o    Integration with the VOLTHA projects in ONF

    o    Integration with the OSAM - Dynamic Control & User Plane

Impacts:

ONAP Components: 

...

Inventory of the devices and user services
Creation of Models in SDC
Subscribers will utilize LDAP for Access service profiles and authentication

...

Directed Graphs
VNF Management

...

Interface CLAMP from OSAM-UI (Future Release)

...

Impacts to the Control and Abstraction output to VES

...

Small impact to reuse TCA
Small impact to call SO

...

Interface VID from OSAM-UI

...

No Core SDNC Impacts

...

OSAM

A work effort in ONAP for bridging the Open Networking Foundation (ONF) work into ONAP. Part of this was to create a higher order UI for the Access Network, Service Models, Work Flows, Policies, etc.  The goal of the project is to build out dependencies for future support of 3rd party virtualized network services for the access network.

Image Added

OSAM use case will use the similar approach to 5g use-case. OSAM consists of three components which are OSAM Gateway, OSAM Core, and SEBA. OSAM Gateway and OSAM Core and SEBA will be onboard as a service to ONAP.

• OSAM Core and OSAM Gateway will be onboarded as a VNF
• SEBA will be onboarded as a PNF
• Services will be defined for OSAM CORE and OSAM Gateway
• Another service will be defined for SEBA as a PNF and OSAM Gateway as an alloted Resource
• Auto-scaling based on fault and/or performance will be done through OSAM Gateway and OSAM Core services.

ONAP will perform the following functions for OSAM use-case which are;

• Robust environment
• Scalability
• Sharing different resources on different services
• Overview of the OSAM topology (From OSAM UI)
• Storage for SEBA configuration
• Service Provisioning

Users and Benefit:

Operators benefit from OSAM use case in the following aspects:

1. service agility: more easy design of both VNF, PNF and network service, VNF onboarding, PNF onboarding, and agile service deployment.
2. resource efficiency: through ONAP platform, the VNF resources can be utilized more efficiently, as the services which contain the OSAM Core or OSAM gateway, are deployed and scaled automatically on demand.
3. operation automation and intelligence: through ONAP platform, especially integration with DCAE and policy framework, OSAM Core and OSAM Gateway VNFs and the services as a whole are expected to be managed with much less human interference and therefore will be more robust and intelligent.

OSAM ARCHITECTURE

It currently has 5 main modules which are SEBA, ONAP, OSS/BSS, OSAM Gateway and OSAM Core.

Image Added

OSAM is addressed as PNF model of 5G use case. In 5G use case, CU and DU pairs are used. In our OSAM case, we are going to use the similar approach. SEBA is going to be mapped as DU. OSAM GW(Gateway) is going to be mapped as CU.

OSAM CORE

OSAM core will be designed as a VNF. It consists of

• OSAM UI
• OSAM DB
• Portal Service Layer
• Service Flow Manager
• GW Locator
• OSAM GW Adaptor Layer

Image Added

OSAM Core is responsible for taking the required actions from OSAM UI or OSS/BSS inputs. These actions are related to technology profile management, ONT/OLT management, topology management, fcaps and subscriber management. OSAM core applies set of actions to SEBA through OSAM GW.

• OSAM UI

Technology profile management, subscriber information, service activation for the subscriber, alarm/event monitoring, ONT/OLT management and monitoring are applied from UI. OSAM UI has fully interacted with Portal Service Layer which provides PNF information and data such as technology profiles, subscribers information, ONT devices information, and OSAM network topology. In other words, Portal Service Layer provides a backend for OSAM UI with its API and callback interfaces.

• OSAM DB

OSAM DB is responsible for storing OSAM related data such as: 

• • Subscriber information and its relation with PNF
  • Id, Ip and Location information are going to be stored for **PNF**
  • OSAM Gateway information 
  • PNF relation with OSAM gateway
  • OLT information and its relation with PNF
  • ONT information(Serial Number)
  • Technology profiles and their relationship with the subscriber
  • OSAM topology
  • Subscriber information with its relation with PNF and technology profile is going to be stored
  • Alarms, events, and metrics(will be fetched from ONAP)
• Portal Framework

Portal Framework is the backend for the OSAM UI and OSS/BSS. Provides APIs and callbacks to OSAM UI and OSS/BSS. Technology profile management, ONT/OLT management, subscriber management and subscriber's service purchase operations are conveyed from Portal Framework to Service Flow Manager. PNFs(SEBAs) information and their relation with OSAM gateways are collected from GW Locator to show on OSAM UI.

• Service Flow Manager

Service Flow Manager is the coordinator module for OSAM Core. Service Flow Manager can be triggered by Portal Framework or OSAM Gateway. It decides how the incoming/outgoing requests are going to be applied or conveyed. It applies requested set of actions to OSAM DB or OSAM GW Adaptor layer. Service Flow Manager uses OSAM DB for storing information or configurations related to subscriber, ont/olt or technology profile and creating the relationship between subscriber information and pnfId. OSAM GW Adaptor layer is used for sending the information to PNF.

• GW Locator

GW Locator is responsible for locating PNFs of OSAM gateway. PNFId plays a critical role for Service Flow Manager. Also, PNF information and its relation with OSAM gateway are saved by GW Locator. PnfId, OSAM Gateway ip address and user credentials for authentication plays a mandatory role for PNF storage in OSAM DB. OSAM GW Adaptor Layer can callback to GW Locator to store OSAM Gateway and connected PNFs relation.

• OSAM GW Adaptor Layer

OSAM GW Adapter Layer is the communication layer between OSAM Core and OSAM Gateway. It interacts with GW locator and OSAM GW API services. The interaction between OSAM Gateway and Adapter Layer needs to be bidirectional. GRPC protocol is a good candidate for this purpose.  Adapter Layer conveys registered technology profiles, subscriber information and ont registration. (Can be expanded more) to OSAM Gateway from Service Flow Manager. Osam Gateway Adapter layer learns osam gateway ip address from GW Locator using pnfId.

OSAM Gateway

OSAM Gateway is another VNF running near the SEBA pods that can be implemented within the POD as a local OSAM function. OSAM Gateway is a bridge between SEBA and OSAM core. 

In OSAM use case, every SEBA(PNF) pod must be matched with OSAM Gateway. OSAM Gateway can connect to multiple SEBA pods. SEBA's bridge gateway(OSAM GW) will be decided by ONAP side. OOF module chooses OSAM Gateway according to location input parameters in ONAP runtime.

Image Added

• OSAM Core Adaptor Layer

Provides a northbound interface to OSAM Core.

API interfaces should provide the following:

• Retrieve ONT devices for PnfId
• Retrieve OLT devices for PnfId
• Delete OLT device
• Disable ONT device
• Configure Access Node(OLT/ONT)
• Subscriber information and their statuses from PNF
• Telemetry data per Subscriber and SEBA pod
• Service Profile management(Ex: technology profile)

The callback should provide the following:

• ONT, OLT and subscriber alarms
• SEBA deregistration alarm
• ONT, OLT and subscriber events

• OSAM GW Coordinator

The coordinator is responsible to deliver NEM Adaptor requests to OSAM Core adaptor and vice versa. Moreover, it decides the callback action for PM requests(etc) from NEM adaptor Layer. Such as, if telemetry data is received from SEBA. It sends to Ves Agent. If SEBA register request is received, it stores the request in distributed cache and conveys the request to OSAM core via OSAM Core Adaptor Layer. Addition to that if any request is received from OSAM Core Adaptor Layer, converts to SEBA's GRPC

format and delivers the message to SEBA pod.

• Ves Agent

Delivers telemetry data to ONAP from Ves Agent. This module is also responsible for sending telemetry data for connected SEBA pods(PNFs) as well. 

• NEM Adaptor Layer

Connection point to SEBAs. It provides a GRPC callback and APIs to communicate with multiple SEBAs.

SEBA api interface should provide the following APIs:

• ConfigureTechnologyProfile
• ConfigureAlarms
• ConfigureAccessNode(AccessNode)
• AccessNode Inventory Information
• RetrieveAccessNodeInformation(AccessNode)
• RetrieveONTDevicesOfOLT(OLT)
• DeleteOLT
• DisableONT
• ActivateBroadbandServiceForSubscriber
• UpdateBroadbandServiceForSubscriber

SEBA callback interface should provide the following:

• RegisterPoD(Capabilities)
• DeregisterPoD
• RetrieveSubscriberPlan
• RequestServiceAccessForSubscriber(ONT_SerialNumber)
• RetrieveTelemetryData
• RetrievePerformanceMonitoringData
• RetrieveAlarms
• SEBA PoD Registration
• Broadband Service Activation

• Distributed Cache

Caches the PNFId, location and Ip address information. In any OSAM GW failure can recover each other by using distributed cache.

OSS/BSS

Technology service order for a user is done from OSS/BSS.

OSAM Design Time In ONAP

• OSAM Core and OSAM Gateway are going to onboard as a VNF. VNFD is needed to be prepared for each
• SEBA is going to be onboard as a PNF. PNFD is needed to be prepared.
• OSAM needs three services for working full functionally.
• OSAM Core VF resource will be used for OSAM Core service.
• OSAM Gateway VF resource will be used for OSAM Gateway service. (In other use-cases OSAM Gateway might be in the SEBA Pod)
• For SEBA service, SEBA PNF and OSAM Gateway as an alloted resource will be used.

Impacts:

ONAP Components: 

Since the OSAM use-case is similar to 5G use-case, most impacts will be common. However, some specific design materials (such as PNFD, VNFD, configuration ) will be different due to the nature of OSAM.

• Modeling/Models

Provide OSAM Core, OSAM Gateway, and SEBA specific models

Modeling will need to be added to describe how OSAM Core and OSAM Gateway VNFs are to be instantiated, removed, healed (restart, rebuild), scaled, how metrics related are gathered, how events are received.

Modeling will need to be added to describe the connection between OSAM Gateway and SEBA, plus  OSAM Gateway and OSAM Core.

• SDC

Design OSAM Gateway, OSAM Core and SEBA network service, TOSCA based. VNF and PNF templates will be provided by OSAM community
Design Auto-healing policy  for OSAM Core and OSAM Gateway
Design or provide ansible script for PNF

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

• Access Management will leverage the PNF management approach and 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 and SEBA projects in ONF

Resources:

• Primary Contact Person: Sumithra Bhojan (sb4846@att.com) 
• Names, gerrit IDs, and company affiliations of the committers

Outlook Contact List
VCF Contact List

Committers:

Contributors:

Access Network Components:

...

Provides Dynamic Control & User Plane
Provides setup of subscriber service flow over the underlay established by he SDN-C

...

S3P:

Scale:

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

Stability:

All Access network components are designed to operate in a horizontal scale in order to provide a seamless user operation.

Security:

The reside on ONAP secured infrastructure.

Performance:

All Access Network components have been developed and tested to support high performance.  If performance issues are found during testing the application

Resources:

• Primary Contact Person: Blaine McDonnell (bm2535@att.com) 
• Names, gerrit IDs, and company affiliations of the committers

Committers:

...

CIENA

...

Contributors:

• Names and affiliations of any other contributors
• Project Roles (include RACI chart, if applicable)

Other Information:

• link to seed code (if applicable)
• https://github.com/opencord
• Vendor Neutral
• Meets Board policy (including IPR)

...