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 (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 | |
|---|---|
| Topology | wikipedia: ietf: /sko/ could not fine a definition but the network-topology data-model description of RFC8345 3GPP: /sko/ 23.726 talks about local topologies and network topology - but could net find a definition yet. " This release supports technology-agnostic interfaces to the following functional modules:
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." ONF CoreModel 1.4 TR-512.4 (== ITU-T ???) /sko/detailed information model 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. |
| Node | |
| Edge | |
| Group | |
| Domain | |
| Association | |
| Link | |
| Point | |
| Inventory | |
| Network | |
| Physical | |
| Virtual | |
| more.... |
