ARCHITECTURE WORK

WIKI LINK

ARCHITECTURE FLOWS

ARCHCOM: InfoFlow - RunTime Config DB Information Flow

COMPONENT DESCRIPTION

ARC RunTime DB Component Description - R6 Frankfurt

PROJECT PROPOSAL

RunTime Config DB Project Proposal (Oct 25 2019)

R6

CCSDK-based Solution

Project as part of CCSDK ( @Yuriy Malakov  )

R7

Project Proposal

RunTime Config DB Project Proposal (Oct 25 2019)

R7

Separate

Component

Email from @Dan Timoney Nov 14, 2019 

My understanding from Sandeep was that this work was very much a stretch for Frankfurt.  So, I’m okay with work starting in Frankfurt, as long as its structured so that it’s a separable component (i.e. as long as, if it’s not completed in Frankfurt, the platform is not fundamentally broken). I would NOT support creating a separate repository, since there is a fair amount of overhead involved in maintaining each repository on an ongoing basis – both machine and human resources.  The Linux Foundation itself has been pushing back on the number of repositories the ONAP projects have and there is now a new approval process needed in order to add new ones.  If a new repository is needed, then this team will need to convince me why no existing repository can be used AND will need to provide a resource who is willing to maintain that repository (i.e dealing with security vulnerabilities; policing code coverage ; doing release builds, etc).

R7 Guilin

Content / requirements

Requests for R7 Requirements are up.

Guilin release - functional requirements proposed list

Timeline -  Sign-off for R6 is May 7. Historically M0 kickoff for R7 is May 7th

PROPOSALS FOR R7 GUILIN FOR WHAT WE PLAN TO BE DOING IN R7:

1. R7 Project Proposal (identify PTL, Project proposal, setup repo)

2. =STEP 0= (Design time), (Setup DB) Yang Model development ORAN specification Yang Model in line with 3GPP. SQL structure.

3. =STEP 0= Schema design/setup & API

4. =STEP 1= CMnotify generated by RanSIM extended (final standard format).

5. =STEP 1= VES generation, Nokia Simulate DU → simulate VES CMNotify message.

6. =STEP 1-6= CMNotify (Nokia) Integration Step 2,3,4 with SON work Step 1,5,6

7. =STEP 5/6= Mapping CMnotify contents into DB

8. =STEP 5a= New Development for Independent component to get VES off of DMaaP

9. =STEP 6= API Updates

10. =STEP 6= Interface to RTCDB (writing DB from SDN-R or RCDB-stand-alone-component)

SUMMARY OF THE STEPS FOR RTCDB "HOW IT OPERATES" (Reference):

• STEP 0: Design time, Setup DB schema & API (Onboarding).

• STEP 1: xNF (RAN Simulator) GENERATES a VES CMNotify - Wipro SON (R6 Done)
  
  

• STEP 1a: Simulator of VES CMNotify/"Standardsdefined/CM" (Nokia) (R7)

• STEP 2: DCAE VES Collector RECEIVES the CMNotify (VES) - Nokia (R7)
  
  

• STEP 3: DCAE PROCESSES VES Event- Nokia (R7)
  
  

• STEP 4: DCAE PUBLISHES onto DMaaP - Nokia (R7)
  
  

• STEP 5: CCSDK (Controller) LISTENS to DMaaP - @Sandeep Shah  (R6 Done) → (R7)
  
  

• STEP 5a: RTCDB (stand-alone component) LISTENS to DMaaP (R7 new)

• STEP 6: RTCfgDB UPDATES DB with info - @Sandeep Shah / Techmahindra (R6 Done) → (R7)
  
  

A&AI FLOWS:

STEP 1...6: Initial A&AI setup of DB (the setup of the DB with the initial set of all xNFs a "getall")

STEP 1...6: A&AI Update (e.g. a new xNF is added or deleted)

Renaming the Project

RENAMING THE PROJECT ("Service" vs "Database")

Database

#1 HISTORICAL PRECEDENCE - The original idea was a configuration database available at Runtime. Use cases to store. Historical been with the project since the beginning. Name Inertia. Operators will use. Historical precedence within AT&T. SON & Slicing depend on this project (scope)

#2 Contents that it holds - Contents is configuration parameters from the network. Name reflects the initial content of database.

Service

Since working on project proposal, it has grown, the same argument works against use.

#1 QUALIFIERS - A wide variety of qualifiers could be put there and it still won't cover. Would move to something more abstract. Abose and beyond a standard IT database. For example service information, policy information, CLAMP information, exo-inventory (information outside of A&AI), topology information, application information - it is conceivable that many other types of information could before. Config if someone wants to add additional information a place to hold information. e.g. in Bell Canada's case they store more than just configuration, the Operational Data & Current state of network. Collectors that gather metrics in VES consumed put in stateDB. Tied to inventory objects in A&AI self-link from A&AI want to know about interface PNF trying to keep two together, the configuration & the metrics representative what is currently happening in the network. state of I/F being up-down that's more of a state vs a configuration. OpenDaylight Operational data store. Scalability. Collectors & StateDB is yang-driven if collector follows yang-model data store can hold-values. Monitoring interface track as state.

#2 Confederation of Databases - Core/Edge/Far Edge - Historical DB - current DB

#3 MEANS VS ENDS - Database is a "means" technology not an "end" goal

An engine, hubcap is a part of a automobile that provides a service: vehicular motion. A database is a specific technology and implementation.

Requirements around for current data & historical (temporal) careful not to talk about the technology. Potentially more than one database.

Data Persistency Service → "functional" / Zu Tony Ben

Configuration & Persistency Service / Joanne Tony Ben

Operational Persistency Service / Bruno Tony Ben

Run-Time Configuration DataBase → "technology"

State (of Network) Database → what is state of network (storing more than just config)

Configuration Operations Database (C.Op.DB) / Swami

Golden Configuration Database / Fred

(RunTime)(Operational)(Persistency) Policy Topology State Network Configuration Service Exo-Inventory Database

R7 GuiLin Development

CMNotify specification

Zoom

Audio Only

Chat