Abstract Topology Model

This page is related to Jira ONAPMODEL-35: ONAP internal topology modelOpen.

Motivation

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

Idea

The idea could be to define an ONAP topology model across all ONAP components and technologies and describe a kind of mapping to technology and/or use case specific topology models, such as:

PCEP
LLDP
IEEE 802.3
TAPI
OpenROADM
3GPP-EP
IETF-Interfaces
ONF:LogicalTerminationPoints
OpenConfig
kubernetes (O-RAN O2?)
Cluster?
...

Initial draft proposal

The previous sctach is now removed from this page.

Please follow Proposed Topology IM Sketch

Principals and Terminology

Principals

Topology (both concept and service) is not:

The summation of all network configuration
A collection of inventory assets
Directly responsible for the provisioning/execution of changes in the network (It is not the part of the system that orders changes in the network)

Topology (both concept and service) is:

a representation of the arrangements (relationships, associations, etc.) among important entities
provides information that is shared in the context of an ONAP system by multiple to multiple applications, components, services
multi-domain: e.g.: technology and telecom domains (Optical, wireless;); management; organizational – a logical partitioning of important entities
multi-layer: Services (potentially recursive) using telecom resources using infrastructure resources – expressing client-server relationships
multi-vendor: Important entities may be provided by different vendors, the topology is agnostic to the vendor
multi-operator: Special case of multi-domain, brought out to cover shared telecom networks
dynamically extensible (@runtime) w.r.t views, topology entities and their relationships

Abstract properties (concepts):

Connectivity: to represent the arrangements among endpoint of important entities (networking objects) across a topological domain e.g. to allow traffic flow for control and data / user plane
Containment/Composition: to represent the way networking resources (physical, virtual, logical) are instantiated, deployed and organized/structured in the network TODO example
Topology Types: E.g.: (Services, Resources, Network (E.g.: Transport; RAN; Packet core; NFV Topology; ...); ...)
Grouping: E.g: Geographical area; vendor; ORD;

Abstract needs (how does the ATM cater for...):

Responsible manager/software service/Ownership: to represent the relationship with the software owners of a particular network asset (physical or virtual) for a given perspective
Topology variations/Types: Must enable the development of these variations. E.g.: 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
Identity: Every important entity must be uniquely identifiable, and may have multiple identities.

Configuration <==> Topology (!GraphGraph) <==> 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 – This is needed to simply construct and maintain the topologies for the abstract needs above
Inventory (A&AI) and configuration (CPS) are data sources. Topology normally derived/updated based on source state. (Normally does not consider planning/intent)

We should not re-invent the wheel! Beg, borrow, reuse, apply and extend where necessary.

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

Term
Topology	ONAP ???? - to be discussed : In telecommunications, topology is the short form of "network topology" and is concerned with the properties of an object class describing the associations of important telecommunication network entities ("nodes"). Other potential definitions to consider: wikipedia: "In mathematics, topology (from the Greek words τόπος, 'place, location', and λόγος, 'study') is concerned with the properties of a geometric object that are preserved under continuous deformations, such as stretching, twisting, crumpling and bending." ietf: /sko/ could not fine a definition but the network-topology data-model description of RFC8345 Network object contains topologies that point outward from that object. IETF Traffic Engineering topology? ex. geo info can be an augmentation of the topology model 3GPP: /sko/ 23.726 talks about local topologies and network topology - but could not find a definition yet. Endpoints between local and remote systems using DN addressing. TAPI (data-model tree) " This release supports technology-agnostic interfaces to the following functional modules: Topology Service Connectivity Service" later description of grouping topology: "The ForwardingDomain (FD) object class models the ForwardingDomain topological component which is used to effect forwarding of transport characteristic information and offers the potential to enable forwarding." Each topology is contained in a context. The context is a "black box", and can be contained recursively. ONF CoreModel 1.4 TR-512.4 (== ITU-T ???) /sko/detailed information model SDN controller & SDN domains Other things to consider: Topologies can exist on different levels and are related to each other through the network entities that they connect. Topologies using different technologies on the same level may or not be interchangeable. A "horizontally-augmented" topology can add capabilities to the network entities and their associations. A network topology will probably not have a tree structure.
Network	Assumed to mean "telecommunications network" in this context
Node	Network entity in a topology
Termination point	"The anchor point contained in a node that one or more links connect to" – IETF In the context of a data tree, a point could be called a leaf (YANG), i.e. a data node that has no children
(End-point)	Equivalent to termination point
Association	In the context of network topology, this is a broader concept than a P2P link. An association could contain several aggregated / multi-point links. The association represents the logical connection. In the context of a network topology model expressed in UML, this can be a UML association between classes/types of network entities. However not all UML associations in the model are necessarily modelling links or associations in the network topology sense. ("Link" could also be a class in a UML model for topology.) Associations in UML can have different types and properties. Graphs?
Link	Relationship between two neighboring termination points on the same level. Could be uni- or bi-directional, but always P2P. (IETF) Link aggregation / multi-homing is represented using multiple P2P links.
(Edge)	Equivalent to link.
Group
Domain
Inventory	What is the boundary / relation between network topology and inventory?
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:

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

Abstract Topology Model 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
1. 1-3: Implicit requirement: Ability to create topologies.
Geographical location information aware – Look at the "place model", place object ref Ben & Jacqueline
Layering of topologies – client, server representation – Up to the specific topology design which an how to relate layers
State model (optional, for selected topology entities)
Allocation (usage, e.g. bandwidth allocation)
Logical grouping (ORD)
Technology grouping
Cater for unmanaged assets
Responsible manager/software service/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
Unique Identity plus possibly other identifiers

Topology Service Requirement:

Dynamic (Service requirement): Accurately represent the reality (current state) in the managed network;

Impact on ONAP components

Candidates:

AAI
CPS
SDC
CCSDK
DCAE