Page History

Use case driven topology representations

Geographical Topology

Physical Topology

Ethernet Topology

PTP-Topology

Initial draft proposal

''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' 
' Copyright 2021 highstreet technologies GmbH
' Licensed under the Apache License, Version 2.0 (the "License"); 
' you may not use this file except in compliance with the License. 
' You may obtain a copy of the License at 
' 
' http://www.apache.org/licenses/LICENSE-2.0 
' 
' Unless required by applicable law or agreed to in writing, software 
' distributed under the License is distributed on an "AS IS" BASIS, 
' WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 
' See the License for the specific language governing permissions and 
' limitations under the License. 

@startuml

' Diagram 
title 
  Abstract Topology Model
end title

package AbstractTopology {
  interface Top {
    UUID Identifier
    String Address
    ENUM Type
    String Name[*]
    String Label[*]
    ENUM LifeCycleState
    ENUM OperationalState
    ENUM AdminstrativeState
    Date-And-Time Timestamp
  }
  class Topology implements Top
  class Node implements Top
  class Edge implements Top
  class Path implements Top
}

Topology *--> "*" Node: hasNodes
Topology *--> "*" Edge: hasEdges
Topology *--> "*" Path: hasPaths
Node *--> "*" Node: hasChildren
Node *--> "*" Node: hasNeighborsOfSameType
Edge *--> "*" Edge: hasChildren
Edge "1" o--> "2" Node: refrencesNodesOfSameType
Path "1" o--> "*" Edge: referencesLinks


' End Diagram
' Format
header
  <b><font color=#8888ff>License</font></b>
  <b><font color=#8888ff>Apache 2.0</font></b>
end header

right footer 
  Thanks to plantUml! 
  2021-01-29 | onap.org
end footer

skinparam backgroundColor #fefefe

skinparam backgroundColor #fefefe
'skinparam handwritten true
skinparam roundcorner 15

skinparam class {
  BorderColor #444444
  BackgroundColor #ffffdd
  FontColor #444444
}

skinparam database {
  BorderColor #444444
  BackgroundColor #ffffdd
  FontColor #444444
}

skinparam sequence {
  MessageAlign left
  ArrowThickness 2
  ArrowColor #2277dd
  ArrowFontColor #444444
  ActorBorderColor #444444
  LifeLineBorderColor #444444
  LifeLineBackgroundColor #eeeeee
 
  BoxBorderColor #444444
    
  GroupBorderColor #444444
  GroupBackgroundColor #eeeeee
  
  ParticipantBorderColor #444444
  ParticipantBackgroundColor #ffffdd
  ParticipantFontColor #444444
    
  ActorBackgroundColor #ffffdd
  'ActorFontColor DeepSkyBlue
  'ActorFontSize 17
  'ActorFontName Aapex
}
@enduml

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.

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

• Jira
  server ONAP JIRA serverId 425b2b0a-557c-3c0c-b515-579789cceedb key CCSDK-3158

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.

Abstract Topology Model requirements

1. Resource topology – Abstract Topology shall support the creation of a topology of network resources (VNF, VIM, NF, MF, etc.)
2. Network topology – Abstract Topology shall support the creation of a topology of how resources are connected
3. 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.
4. Geographical location information aware – Look at the "place model", place object ref Ben & Jacqueline
5. Layering of topologies – client, server representation – Up to the specific topology design which an how to relate layers
6. State model (optional, for selected topology entities)
7. Allocation (usage, e.g. bandwidth allocation)
8. Logical grouping (ORD)
9. Technology groupingDynamic
10. Cater for unmanaged assets
11. 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)
12. Labels, meta-data
13. Unique Identity plus possibly other identifiers

Topology Service Requirement:

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

Candidates:

• AAI
• CPS
• SDC
• CCSDK
• DCAE