Skip to end of metadata
Go to start of metadata


 

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


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



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

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.


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

ComponentEffortProject Impacts
Active and Available Inventory (AAI)

Maybe some model will be kept here

TBD
Application Authorization FrameworkDefine application roles and access No Impacts
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 Core, OSAM GW and SEBA alerts and events will be sent to DCAENo Core Impacts to DCAE
Data Movement as a Platform (DMaaP)Topic and Partition Creation No Core DMaaP Impacts 
Documentation

External API Framework
TBD
HolmesExisting Structure might be reused.No Impact 
Integration
No Impact
Logging Enhancements Project
No Impact
 Microservices Bus Not UsedNo Impact
ModelingOSAM specific models may be neededSmall impact for models
Multi-Cloud (VIM)Used for installation of OSAM GW and OSAM CoreNo Impacts
ONAP Operations Manager (OOM)Docker/Kubernetes Container Management for ONAPNo Impacts
Optimization Framework Will be utilized to select OSAM GW for SEBA podTBD
Policy FrameworkExisting structure will be used

No Impacts

Portal PlatformPortal Interface to the DSC and Hardware Abstraction utilizing the Portal SDKTBD
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
SDNCExisting 5G use case flow will be reused.

No Core SDNC Impacts

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


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:

Namee-MailCompany
BAINBRIDGE,   DAVIDDBAINBRI.CIENA@GMAIL.COMCIENA
BAVIER, ANDYANDY@OPENNETWORKING.ORGONF
CHAWKI, JAMILJAMIL.CHAWKI@ORANGE.COMORANGE
ELIACIK, BORABORA.ELIACIK@NETSIA.COMNETSIA
KOLBE,   HANS-JORGHANS-JOERG.KOLBE@TELEKOM.DE DT
BHOJAN, SUMITHRASB4846@ATT.COMAT&T
PETERSON,   LARRYLLP@OPENNETWORKING.ORGONF
SLOBODRIAN,   SERGIOSSLOBODR@CIENA.COMCIENA
SOYTURK,   MESUTMESUT.SOYTURK@ARGELA.COM.TRARGELA

Contributors:

ALVAREZ,   MARK DMA2516@ATT.COMAT&T
ANSCHUTZ, TOMTA2269@ATT.COMAT&T
BAKER, SCOTTSCOTTB@OPENNETWORKING.ORGONF
BAYKAL, COSARCOSAR.BAYKAL@TURKTELEKOM.COM.TRTT
BEST, GEORGEGB2726@ATT.COMAT&T
BHATIA, SAPANSAPAN@OPENNETWORKING.ORGONF
BHOJAN,   SUMITHRASB4846@ATT.COMAT&T
BILSEL,   SINASISB3462@ATT.COMAT&T
BRUNNER,   MARCUSMARKUS.BRUNNER3@SWISSCOM.COMSWISSCOM
BULLIMORE,   JOEJB6747@ATT.COMAT&T
CAPARRÓS,   DAVID PÉREZ DAVID.PEREZCAPARROS@SWISSCOM.COMSWISSCOM
CHAU, UYENUYEN@OPENNETWORKING.ORGONF
CIMEN,   SULEYMANSULEYMAN.CIMEN@TURKTELEKOM.COM.TRTT
DAS, SAURAVSAURAV.DAS@OPENNETWORKING.ORGONF
EL HOUMAIDI,   MOUNIREME4157@ATT.COMAT&T
FIEDLER, MARCMARC.FIEDLER@TELEKOM.DEDT
GARCIA, ROYRG1878@ATT.COMAT&T
GASSER,   MICHAEL DMG876P@ATT.COMAT&T
HAAG, THOMASHAAGT@TELEKOM.DEDT
HATCH, MITCHMH7576@ATT.COMAT&T
HEILKER,   CHARLESCH2558@ATT.COMAT&T
HEKMAT, ARASHARASH.HEKMAT@AMDOCS.COMAMDOCS
HODGES,   DARRYLDH8196@ATT.COMAT&T
JOSHI, OMKAR ROMKAR_JOSHI@LABS.ATT.COMAT&T
KALAYCIOGLU, TANERTANER.KALAYCIOGLU@ARGELA.COM.TRARGELA
KLUGER, YOAVYOAV.KLUGER@AMDOCS.COMAMDOCS
LAMBERTH, GEORGE MGL9714@ATT.COMAT&T
LOKMAN, ERHANERHAN.LOKMAN@ARGELA.COM.TRARGELA
LORENTZEN, JULIEJULIE_LORENTZEN@LABS.ATT.COMAT&T
MACMILLER, JAMES EJM108K@ATT.COMAT&T
MOORE, THOMASTM9646@ATT.COMAT&T
OLIER, MIKEMO2961@ATT.COMAT&T
OZDEM, MEHMETMEHMET.OZDEM@TURKTELEKOM.COM.TRTT
ÖZTOPRAK,  KASIM DR.KASIM.OZTOPRAK@TURKTELEKOM.COM.TRTT
PADHIAR, BHUSHANBP6470@ATT.COMAT&T
PAUL, MANUELMANUEL.PAUL@TELEKOM.DEDT
PETERSON, KEVIN  AKP1959@ATT.COMAT&T
ROLLWAGE, CHRIS ACR4383@ATT.COMAT&T
SOUKUP, ROBERT ROBERT.SOUKUP@TELEKOM.DEDT
SOYLU, CEMILCEMIL.SOYLU@TURKTELEKOM.COM.TRTT
STROM, WALLACEWS7779@ATT.COMAT&T
TAGET, GOPINATHGOPINATH@OPENNETWORKING.ORGONF
TAKANAY, BURHANETTINBURHANETTIN.TAKANAY@ARGELA.COM.TRARGELA
TOFIGH, TOMMT3682@ATT.COMAT&T
ULUDERYA, SERKANTSERKANT.ULUDERYA@NETSIA.COMNETSIA
VAN BRAKLE, TRACY LTV8394@ATT.COMAT&T
WOODS, CYNTHIA NCW8981@ATT.COMAT&T
YING,SHAWNSYING@LABS.ATT.COMAT&T
YOUNG, ASHASH@CACHENGO.COMCACHENGO
ZUMWALT, DANNY PDZ1317@ATT.COMAT&T
  • Names and affiliations of any other contributors
  • Project Roles (include RACI chart, if applicable)

Other Information:






25 Comments

  1. Hi,

    It took a while to digest the proposal.  It is good one. Few questions.

    • As mentioned in the proposal, this is domain specific proposal (Access related proposal) with ONAP being one of the infrastructure pieces in the solution. It is not clear on whether this project proposal is to enhance ONAP with missing functionality to realize this 'vAccess' use case.  Or is the project proposal intend to provide code (green items in the picture) related to vAccess global and local sites (OSAM)?
    • As per opencord,  ONOS is controlled by XOS.  I guess, the intention to replace XOS with ONAP and OSAM?
    • VF-C, SDN-C and APP-C are shown below the red line in 'Local' section.  My understanding so far is that these are at global location.  There are some initial thoughts (Parvez presented this in one of the architecture meetings) to provide site specific controllers, managed by  global SDN/APP-C controllers. If this proposal needs worker SDN&APP controllers in each site, then this project depends on that master-worker controller model. From the cursor look of architecture, OSAM does not depend on SDN-C and APP-C. So, you really mean to put the those controllers in global side of the picture?
    • VIM term in above picture mean to indicate "Multi-VIM"?
    • I see both "Openstack" and "Kubernetes" VIMs in local site? Does OSAM require both kinds of VIMs in one location? Is it because there are some workloads realized as VMs and some as containers? Note that VOLTHA can be realized as container (as per last opencord conference). Also, I heard from last opencord conference, they intend to orchestrate ONOS also a set of containers via Kubernetes. 
    • Is the local site openstack & Kubernetes meant to bringup/bring down green workloads only or for some other things too? If it is for other things, what are those?
    • There is a line between MSO and JSC (on local site). What kind of interactions are expected between those two components?
    • You mentioned TOSCA model?  Is it meant to bring up green components via MSO/Multi-VIM/Kubernetes?  Who is going to bring up green components in global site? Is it going to be done by ONAP OOM or something a at high level?
    1. Srinivasa, As we are developing this we are open to great new ideas.

      [Srinivasa] As mentioned in the proposal, this is domain specific proposal (Access related proposal) with ONAP being one of the infrastructure pieces in the solution. It is not clear on whether this project proposal is to enhance ONAP with missing functionality to realize this 'vAccess' use case.  Or is the project proposal intend to provide code (green items in the picture) related to vAccess global and local sites (OSAM)?

      [Blaine] It is a proposal to both converge work efforts that are done with ONF and extend ONAP to support the Access Network.


      [Srinivasa] As per opencord,  ONOS is controlled by XOS.  I guess, the intention to replace XOS with ONAP and OSAM?

      [Blaine] Some of what is done today will be supplied by ONAP.


      [Srinivasa] VF-C, SDN-C and APP-C are shown below the red line in 'Local' section.  My understanding so far is that these are at global location.  There are some initial thoughts (Parvez presented this in one of the architecture meetings) to provide site specific controllers, managed by  global SDN/APP-C controllers. If this proposal needs worker SDN&APP controllers in each site, then this project depends on that master-worker controller model. From the cursor look of architecture, OSAM does not depend on SDN-C and APP-C. So, you really mean to put the those controllers in global side of the picture?

      [Blaine] I removed that image with the SDN-C/APP-C Global and Local Distinction.  The Access control is a reactive flow control needing to be near the edge site while the SDN-C/APP-C is managing the underlay network.


      [Srinivasa] VIM term in above picture mean to indicate "Multi-VIM"?

      [Blaine] Yes, that is the intent - I will update in the text, but still use VIM for images.


      [Srinivasa] I see both "Openstack" and "Kubernetes" VIMs in local site? Does OSAM require

      both kinds of VIMs in one location? Is it because there are some workloads realized as VMs and some as containers? Note that VOLTHA can be realized as container (as per last opencord conference). Also, I heard from last opencord conference, they intend to orchestrate ONOS also a set of containers via Kubernetes.

      [Blaine] OSAM will be container based on Kubernetes.  Providers were removed to recover space.  OpenStack is also utilized for other aspects within AT&T.


      [Srinivasa] Is the local site openstack & Kubernetes meant to bringup/bring down green workloads only or for some other things too? If it is for other things, what are those?

      [Blaine]  Local Kubernetes would be for bring up/down/add/remove containers used for OSAM


      [Srinivasa] There is a line between MSO and JSC (on local site). What kind of interactions are expected between those two components?

      [Blaine] Removed that depiction, in the new image it is represented as just OSAM which would provide the distributed service and flow abstractions for the access edge.


      [Srinivasa] You mentioned TOSCA model?  Is it meant to bring up green components via MSO/Multi-VIM/Kubernetes?  Who is going to bring up green components in global site? Is it going to be done by ONAP OOM or something a at high level?

      [Blaine]  The image has been updated.  The instances of the green components will be brought up by the infrastructure orchestrator.

      1. Thanks Blaine.  It seems very clear now.

  2. Since OLT is a physical network function,  I guess this  project depend on PNF Modelling Capability.  Please confirm/correct.

    1. We can integrate the PNF Modeling Capability into the Hardware Abstraction requirements which is intended to be the abstraction layer for the Access PNF.

  3. Thank you for the proposal. 

    You call this a "domain specific module".  One of the architecture principles of ONAP is that it should be service agnostic, so I'd be very concerned about having projects or modules that are service-specific.  Of course, if ONAP does not support certain services, service-agnostic enhancements could be made to projects so that those services are supported... typically we do that via the use cases driving requirements into the projects.  Have you looked at that route?

    1. Thank you very much for reviewing this proposal.  The reason for the use of "domain specific" is that it is the work effort to integrate the Virtualized Access work effort into ONAP while trying to not impact the core functionality of the ONAP platform.  While the intent is not to impact the core I expect enhancements and optimizations to come out of the work effort.   We did discuss creating this as a "use case" rather than a stand alone project and it was the suggestion by ATT's TSC members to not create it as a "use case".   

  4. As I understand, VNF (container and VM) orchestration is done by ONAP and there is no specific OSAM related requirement in this path. Is the OSAM block in ONAP meant for configuration of Access-VNFs/ OLTs etc..?  If so, Is it going to use APP-C to make the configuration updates?  If that is the case, shouldn't the thin green OSAM box be on top of ONAP and connect APP-C to domain specific controller (OSAM-Control)?

    Or OSAM box in ONAP meant for something else? if so, can you describe that functionality?

    Thanks

    Srini


  5. Thanks for sharing this great proposal - has there been any consideration how this might/might-not with another proposal on ONAP - External Domain Management systems, and also what is the target northbound API for the OSAM-DSC? 

    1. Owen,
      Thank you for reviewing the proposal. By the name it sounds like it would be related, can you please point me to the reference materials? NBI on the Access DSC currently is REST w/OpenAPI/Swagger Spec.

      Thank you,
      Blaine

  6. Hi OSAM team,

    Regarding the OSAM DB placed in OSAM CORE, do we have a proposal how to provide persistence when a scale-up/scale-down event occurs? 

  7. Hi, perhaps we could use standalone AAI for OSAM DB. A new instance of AAI service within OSAM Core with a customised schema according to OSAM needs. This will likely make easier the migration to ONAP's AAI in future releases of OSAM, where we plan to use ONAP components to implement most of the OSAM Core functionalities. As far as I know, AAI relies on Cassandra and it is scalable.

    1. Hi David,

      AAI has dependencies to other ONAP components so using a standalone AAI would require us to clean all dependencies which would take some efforts. I don't have any experience using Cassandra but it may be a good option. 

      I quickly checked other use cases and it seems OSAM use case will be the first one using a standalone DB in a VF. 

      1. Hi Serkant, I thought AAI is mostly consumed by other ONAP components. It only interacts with DMaaP (sending object creation/deletion... notifications) and SDC (aai-model-loader to register as SDC distribution client). Are there other dependencies?

        We should think about the type of information that needs to be stored before choosing a DB technology. So far we discussed about OSAM core architecture and workflows, but the modeling of subscriber services within OSAM Core and how they relate to the infrastructure service (POD) is missing. Any thoughts on this?

        1. Hi David, I think, at the last meeting or before that meeting(I couldn't remember). We have decided on Casablanca to focus on Infrastructure related services. (You can see their test cases). I am not sure how is customer related flows are going to be. But we would like to use Ext API and AAI for customer services. We need to discuss and research the interaction for it. Since we have delayed customer services for Dublin, I am currently working on OSAM Core and OSAM GW development details. But, if you have a proposal for it, we would like to hear it.

          1. Hi Cem, I thought OSAM Core would still be used for creating and monitoring customer facing services, but without relying on ONAP components for that (e.g. see OSAM flows, steps 6.0 and 6.1). If so, at some point we need to define how to model the CFS (or product) offered to subscribers (e.g. residential internet access 10G, residential internet access 1G, enterprise internet access 10G...) and the information that needs to be kept in OSAM DB once they are instantiated (e.g. Access POD ID, Service ID, Service profile ID, Subscriber ID...). The resource service catalog offered by the Access POD should also be captured somewhere in OSAM Core, so that OSAM knows what type of subscription is being offered by each POD (some PODs may offer 10G connection, others only up to 1G...).
            I was suggesting to use standalone AAI with an extended schema for implementing OSAM DB within OSAM Core to store information related to customer services, CFS instances and there relation to physical PODs, together with OLT/ONT topology and status information. This is to get familiar with AAI in the process and reuse some work in R4. But this is to be discussed, of course.

            1. Hi David,

              As I mention, since we have delayed the customer services for Dublin, we can change the flows like service subscription to profile flows for Dublin easily. Your proposal is okay with me. We can work on it together when the infrastructure related service implementation is completed. Btw for Casablanca, we are considering a basic structure for the topology that can be migrated to AAI with minimal effort. Also, this work will allow us to identify the AAI models as well for topology.

          2. Hi David, Cem, one of AT&T's goal for OSAM Core is subscriber provisioning/management. I would like for that to be part of what we deliver in 2018. If we don't have that as part of the plan in 2018, I don't think OSAM would prove worthwhile for the ONAP community if it's just device management. Agree, we need to line up on resource and contribution. 

  8. In the documentation and in the integration test cases, there are many references to SEBA, but I could not find the explanation of what it is.
    I would propose to use a generic name instead, such as Access POD. Ideally, OSAM Core and Gateway should not be tightly coupled with any specific implementation of the Access POD OAM platform.

    1. Agree, we can keep it generic and open API's for southbound interface to Access POD. This can also be driven through contribution. One use case would be to interact with the SEBA POD, which will be presented as an abstracted OLT. I don't enough to say if a generic Access POD would have the same level of abstraction as the SEBA POD.

  9. Cem Türker is the OSAM Gateway a VNF that is onboarded in ONAP (thus LCM that ONAP controls) or is it a VNF that that is part of the CORD environment (thus LCM that CORD controls)?

    1. We might support both cases. I think AT&T and Turk Telekom want to move OSAM Gateway inside of the CORD environment(So LCM will be managed by CORD if it is moved in). But if we are going to talk about existing propose, YES, ONAP will handle the LCM of OSAM Gateway, in other words OSAM gateway will be onboarded as a VNF to ONAP.

      1. Thanks - That helps.

  10. Hello

    is the UC OSAM still ongoing?

    thanks

    Cecilia Corbi

  11. Is this project still available for Dublin?

    Can anyone provide the installation guide link to it?