# Class CIM_TopologyGraph
extends CIM_Collection

TopologyGraph is a general structure for representing network topologies. Often, a topology graph consists of a set of nodes and a set of edges which connect the nodes. The TopologyGraph structure is slightly different, in order to support multipoint links and to express the connectivity within what would normally be considered a 'node'. Multipoint links occur in entities such as IP subnets, where all of the IP endpoints on the subnet can communicate directly, and Ethernet links where all of the Ethernet interfaces on the shared media can communicate directly. An example of connectivity within a node is when the various endpoints/interfaces on a router are connected through the router's forwarding mechanism. There may be different groups of endpoints which communicate within their groups exclusively. This is modeled as a DeviceConnectivityCollection. To represent these examples in a graph structure, TopologyGraph generalizes the node and edge structures of a typical graph. It is a collection of ConnectivityCollections, which can communicate with one another, and are at the same protocol layer. ConnectivityCollections are aggregated into Topology Graphs using the MemberOfCollection relationship. The actual network topology encoded in TopologyGraph is extracted by connecting the ConnectivityCollection instances that share common ProtocolEndpoint instances. For example, if the graph contains three collections, defined as: - Router1={PE1, PE2}, a DeviceConnectivityCollection - Link1={PE2, PE3}, an IPConnectivitySubnet - Router2={PE3, PE4}, a DeviceConnectivityCollection then we can determine that the PE2 interface on Router1 is connected to the PE3 interface on Router2 via the subnet Link1. By finding all of the endpoints that are in multiple ConnectivityCollections within the graph, and connecting those Collections with common endpoints, we can construct the network topology.

### Table of Contents
Hierarchy
Direct Known Subclasses
Class Qualifiers
Class Properties
Class Methods

## Class Hierarchy

CIM_ManagedElement
|
+--CIM_Collection
|
+--CIM_TopologyGraph

## Direct Known Subclasses

## Class Qualifiers

Name | Data Type | Value
--- | --- | ---
Description | string | TopologyGraph is a general structure for representing network topologies. Often, a topology graph consists of a set of nodes and a set of edges which connect the nodes. The TopologyGraph structure is slightly different, in order to support multipoint links and to express the connectivity within what would normally be considered a 'node'. Multipoint links occur in entities such as IP subnets, where all of the IP endpoints on the subnet can communicate directly, and Ethernet links where all of the Ethernet interfaces on the shared media can communicate directly. An example of connectivity within a node is when the various endpoints/interfaces on a router are connected through the router's forwarding mechanism. There may be different groups of endpoints which communicate within their groups exclusively. This is modeled as a DeviceConnectivityCollection. To represent these examples in a graph structure, TopologyGraph generalizes the node and edge structures of a typical graph. It is a collection of ConnectivityCollections, which can communicate with one another, and are at the same protocol layer. ConnectivityCollections are aggregated into Topology Graphs using the MemberOfCollection relationship. The actual network topology encoded in TopologyGraph is extracted by connecting the ConnectivityCollection instances that share common ProtocolEndpoint instances. For example, if the graph contains three collections, defined as: - Router1={PE1, PE2}, a DeviceConnectivityCollection - Link1={PE2, PE3}, an IPConnectivitySubnet - Router2={PE3, PE4}, a DeviceConnectivityCollection then we can determine that the PE2 interface on Router1 is connected to the PE3 interface on Router2 via the subnet Link1. By finding all of the endpoints that are in multiple ConnectivityCollections within the graph, and connecting those Collections with common endpoints, we can construct the network topology.
Experimental | boolean | true
UMLPackagePath | string | CIM::Network::Topology
Version | string | 2.19.0

## Class Properties

### Local Class Properties

Name | Data Type | Default Value | Qualifiers
--- | --- | --- | ---
Name | Data Type | Value
InstanceID | string |
Description | string | Within the scope of the instantiating Namespace, InstanceID opaquely and uniquely identifies an instance of this class. In order to ensure uniqueness within the NameSpace, the value of InstanceID SHOULD be constructed using the following 'preferred' algorithm: <OrgID>:<LocalID> Where <OrgID> and <LocalID> are separated by a colon ':', and where <OrgID> MUST include a copyrighted, trademarked or otherwise unique name that is owned by the business entity creating/defining the InstanceID, or is a registered ID that is assigned to the business entity by a recognized global authority (This is similar to the <Schema Name>_<Class Name> structure of Schema class names.) In addition, to ensure uniqueness <OrgID> MUST NOT contain a colon (':'). When using this algorithm, the first colon to appear in InstanceID MUST appear between <OrgID> and <LocalID>. <LocalID> is chosen by the business entity and SHOULD not be re-used to identify different underlying (real-world) elements. If the above 'preferred' algorithm is not used, the defining entity MUST assure that the resultant InstanceID is not re-used across any InstanceIDs produced by this or other providers for this instance's NameSpace. For DMTF defined instances, the 'preferred' algorithm MUST be used with the <OrgID> set to 'CIM'.
Key | boolean | true
Override | string | InstanceID

### Inherited Properties

Name | Data Type | Class Origin
--- | --- | ---
Caption | string | CIM_ManagedElement
Description | string | CIM_ManagedElement
ElementName | string | CIM_ManagedElement
Generation | uint64 | CIM_ManagedElement

## Class Methods