Skip to end of metadata
Go to start of metadata

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

Compare with Current View Page History

« Previous Version 21 Next »

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:

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.


Terminology

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.
 

OSAM-Control

A Domain Specific Controller (DSC) that provides Dynamic Control & User Plane for subscriber related flows. Framework for tenant services that support core subscriber services and flow control. Initial implementation is based on ONF projects.
 

OSAM-HA

Provides hardware abstraction layer for the physical network device providing modular protocol and device interfaces. Initial implementation is based on ONF projects (VOLTHA).
 

OSAM-Collector Agent

Collector agent is a instance built off the DCAE collector agent framework. 
 

OSAM-Analytic Agent

Analytics agent is a instance built off the DCAE analytics agent framework.
 

OSAM-UI

Provides an implementation of a centralized management interface for the access network device and services targeted for edge and deep edge deployments.

 



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 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
  • 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


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.


OSAM-Control (DSC: Domain Specific Controller)

A Domain Specific Controller (DSC) that provides Dynamic Control & User Plane for subscriber related flows. Framework for tenant services that support core subscriber services and flow control. Initial implementation is based on ONF projects.

  • 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

Provides hardware abstraction layer for the physical network device providing modular protocol and device interfaces.  Initial implementation is Open Networking Foundation (ONF) project VOLTHA.

  • 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

Collector agent is a instance built off the DCAE collector agent framework. 

  • 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

Analytics agent is a instance built off the DCAE analytics agent framework. 

  • 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 

OSAM-UI

OSAM-UI provides an implementation of a centralized management interface for the access network device and services targeted for edge and deep edge deployments.12

  • 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

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




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.

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: 

ComponentEffortProject Impacts
Active and Available Inventory (AAI)

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

No AAI Impacts 
Application Authorization FrameworkDefine application roles and access 
Application Controller (AAP-C)

Directed Graphs
VNF Management

 No Core APP-C Impacts
Closed Loop Automation Management Platform (CLAMP) CLAMP will be utilized to view and manage the automation flows

Interface CLAMP from OSAM-UI (Future Release)

 No Core CLAMP Impacts
Command Line Interface No Impacts 
Common Controller Developer Kit (CCDK) Used by SDNC and APPCNo Core CCDK Changes
Data Collection Analytics and Events (DCAE)OSAM Kafka to VES
OSAM Collector (DCAE Collector Instance)
OSAM Analytics (DCAE Analytics Instance)
No Core Impacts to DCAE
Data Movement as a Platform (DMaaP)Topic and Partition Creation No Core DMaaP Impacts 
Documentation  
External API Framework No Impact
Holmes Not UsedNo Impact 
Integration No Impact
Logging Enhancements Project No Impact
 Microservices Bus Not UsedNo Impact
ModelingWill comply with modeling standards of ONAPNo Impact
Multi-Cloud (VIM)Interface for container instantiation, management and control No Core Product Changes
ONAP Operations Manager (OOM)Docker/Kubernetes Container Management for ONAPNo Impacts
Optimization Framework Will be utilize to route the messages from the central cloud to target edge locationTBD
Policy FrameworkReuse of the existing Threshold Crossing.

Impacts to the Control and Abstraction output to VES

Small impact to reuse TCA
Small impact to call SO

Portal PlatformPortal Interface to the DSC and Hardware Abstraction utilizing the Portal SDKReference to OSAM Control and OSAM-HA interfaces
Service Design and Creation (SDC)Development of the Rules, Recipes, Flows, Models, Policies and Services for virtualized Access
OSAM team will attend SDC planned training.

No expected impacts to the SDC Project itself in Beijing.

Virtual Infrastructure Deployment (VID)VID will be utilized for the management of applications.

Interface VID from OSAM-UI

 No VID Impacts
SDNCEstablish EVPN tunnel between Access Peripheral and BNG termination point

No Core SDNC Impacts

Service Orchestration (SO)Orchestration of Access Device and Service instantiation and updatesNo Core Impacts

Access Network Components:

ComponentEffortImpact
OSAM - UIProvides High Order Management interface for Access Services and devices Built on Portal SDK 
OSAM - Control

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

Domain Specific Control
OSAM - HAHardware Abstraction layer of physical network device exposingNetwork Function Layer
FreeRADIUSProvides Subscriber Authentication services for 802.1XNetwork Function Layer
OpenLDAPProvides authentication profiles for the authentication process Network Function Layer

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.

 

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:

Namee-MailCompany
MCDONNELL, BLAINEBM2535@ATT.COMAT&T
SLOBODRIAN, SERGIOsslobodr@ciena.comCIENA
BAINBRIDGE, DAVIDdbainbri.ciena@gmail.com

CIENA

CHAWKI, JAMIL jamil.chawki@orange.comORANGE
BAVIER, ANDYandy@opennetworking.org ONF
PETERSON, LARRYllp@opennetworking.org ONF 
KOLBE, HANS-JORGHans-Joerg.Kolbe@telkom.de DT 
   

Contributors:

SOUKUP, ROBERT Robert.Soukup@telekom.deDT
HAAG, THOMAS HaagT@telekom.deDT 
BAKER, SCOTTscottb@opennetworking.org ONF 
BHATIA, SAPANsapan@opennetworking.org ONF 
PETERSON, LARRYllp@opennetworking.org ONF 

ALVAREZ, MARK D

ma2516@att.com

AT&T

ANSCHUTZ, TOM

ta2269@att.com

AT&T

BHOJAN, SUMITHRA

sb4846@att.com

AT&T

GASSER, MICHAEL D

mg876p@att.com

AT&T

HODGES, DARRYL

DH8196@att.com

AT&T

LAMBERTH, GEORGE M

GL9714@att.com

AT&T

JOSHI, OMKAR R

omkar_joshi@labs.att.com       

AT&T

LORENTZEN, JULIE

julie_lorentzen@labs.att.com

AT&T

MACMILLER, JAMES E

jm108k@att.com

AT&T

MOORE, THOMAS W

tm9646@att.com

AT&T

OLIER, MIKE

MO2961@att.com

AT&T

PADHIAR, BHUSHAN

bp6470@att.com

AT&T

PETERSON, KEVIN A

kp1959@att.com

AT&T

STROM, WALLACE

ws7779@att.com

AT&T

YING, SHAWN

sying@labs.att.com

AT&T

ZUMWALT, DANNY P

dz1317@att.com

AT&T

WOODS, CYNTHIA N

cw8981@att.com

AT&T

BEST, GEORGE

gb2726@att.com

AT&T

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

Other Information:






  • No labels