Abstract Topology Model

Motivaton

Based on discussion between ONAP and O-RAN-SC there is a need to provide a common model to µServices with respect to (network) topologies.

In previous proof-of concept and demonstrations several different topologies of different types were presented. Such use-case driven topologies have several "things" in common. For multi topology networks based on virtual and physical network functions a view across technologies is required to optimize the network in terms of utilization and/or latency and other criteria's.

Use case driven topology representations

Geographical Topology

Physical Topology

Ethernet Topology

PTP-Topology

Principals and Terminology

Principals

Topology is not:

A configuration DB
An inventory system
Directly involved in the provisioning/execution of changes in the network

Topology is:

a record of important entities and their relationships
relevant to multiple applications, components, services
multi-domain, multi-level, multi-vendor
dynamic (@runtime) w.r.t views, topology entities and their relationships

Abstract properties:

Connectivity: to represent the relationships between networking objects to allow traffic flow for control and data / user plane
Containment: to represent the way networking resources (physical, virtual, logical) are instantiated, deployed and organized/structured in the network
Ownership: to represent the relationship with the software owners of a particular network asset (physical or virtual) for a given perspective

Abstract needs:

Topology variations: Services, Resources, Network (E.g.: Transport; RAN; Packet core; NFV Topology; ...); ...
Grouping: to represent the way topology elements can be grouped in a topology E.g: Geographical area; vendor; ORD; ...
State: topology entity states and their transitions. E.g. LCM (Feasible; Designed; provisioned)
Labels: Any meta-data or information that a client may wish to associate with a topology entity

Configuration <==> Topology <==> Inventory

Topology is derived from inventory (subset of equipment and assets) and configuration (subset of network configuration)
Some limited replication of data as needed to provide value
Inventory and configuration are data masters. Topology normally derived/updated based on master state. (Normally does not consider planning/intent)

Visualization

It is assumed that every topology model could be visualized. The visualization is basically a case-by-case mapping of topology-nodes and topology-edges and their properties to shapes, lines, sizes, widths and colors. Therefore the topology model itself must not take the requirements for visualization into account. In some cases a kind of profile of stylesheet could describe such mapping, but it would be outside of the topology itself.

Terms and Definitions

This chapter specifies the terms used for an abstract topology model.

Term
Topology
Node
Edge
Group
Domain
Association
Link
Point
Inventory
Network
Physical
Virtual
more....

Use cases

Network Slicing

Transport to RAN - RAN to Transport - RAN to Core , ....

Alarm Correlation

Multi Domain Concepts

Multi Layer

O-RU recovery (from O-RAN-SC)

The O-RAN SC (Software community) defined a closed loop use case. A trigger (Fault-Notification) by O-RU is send to SMO (ONAP components are used to build the SMO layer). A µService should listen to this trigger and will perform an configuration on the corresponding O-DU.

Please see further details of the use case description:

https://wiki.o-ran-sc.org/pages/viewpage.action?pageId=20878423
https://wiki.o-ran-sc.org/display/OAM/Closed+loop+use+case
Unable to locate Jira server for this macro. It may be due to Application Link configuration.

The µService needs to know the connectivity between O-DUs and O-RUs for layer "Management Plane" to send the right configuration to the the right O-DU and with the right identification of the O-RU on O-DU level. Here a complete topology of the RAN connections on ONAP level could support such use case. The use case can be easyl enhanced by adding active and passive transport components between O-RU and O-DUs.

Requirements

Resource topology – Abstract Topology shall support the creation of a topology of network resources (VNF, VIM, NF, MF, etc.)
Network topology – Abstract Topology shall support the creation of a topology of how resources are connected
Service topology – Abstract Topology shall support the creation of a topology that represents how services use Network and Resource topologies
Geographical location information aware
Layering of topologies – client, server representation
State model (optional, for selected topology entities)
Allocation (usage, e.g. bandwidth allocation)
Logical grouping
Technology grouping
Dynamic
Cater for unmanaged assets
Ownership – Abstract Topology shall support association of a topology entity to the software that owns it for a given purpose (e.g.: LCM; Configuration)
Labels, meta-data