(file) Return to Network_Topology.mof CVS log (file) (dir) Up to [Pegasus] / pegasus / Schemas / CIMPrelim291

  1 a.dunfey 1.1 // ===================================================================
  2              // Title:  Network Topology
  3              // $State: Preliminary $
  4              // $Date: 2005/01/05 00:54:00 $
  5              // $Source: /home/dmtf2/dotorg/var/cvs/repositories/dev/Schema/MOF/Network_Topology.mof,v $
  6              // $Revision: 1.4 $
  7              // ===================================================================
  8              //#pragma inLine ("Includes/copyright.inc")
  9              // Copyright 1998-2005 Distributed Management Task Force, Inc. (DMTF).
 10              // All rights reserved.
 11              // DMTF is a not-for-profit association of industry members dedicated
 12              // to promoting enterprise and systems management and interoperability.
 13              // DMTF specifications and documents may be reproduced for uses
 14              // consistent with this purpose by members and non-members,
 15              // provided that correct attribution is given.
 16              // As DMTF specifications may be revised from time to time,
 17              // the particular version and release date should always be noted.
 18              // 
 19              // Implementation of certain elements of this standard or proposed
 20              // standard may be subject to third party patent rights, including
 21              // provisional patent rights (herein "patent rights"). DMTF makes
 22 a.dunfey 1.1 // no representations to users of the standard as to the existence
 23              // of such rights, and is not responsible to recognize, disclose, or
 24              // identify any or all such third party patent right, owners or
 25              // claimants, nor for any incomplete or inaccurate identification or
 26              // disclosure of such rights, owners or claimants. DMTF shall have no
 27              // liability to any party, in any manner or circumstance, under any
 28              // legal theory whatsoever, for failure to recognize, disclose, or
 29              // identify any such third party patent rights, or for such party's
 30              // reliance on the standard or incorporation thereof in its product,
 31              // protocols or testing procedures. DMTF shall have no liability to
 32              // any party implementing such standard, whether such implementation
 33              // is foreseeable or not, nor to any patent owner or claimant, and shall
 34              // have no liability or responsibility for costs or losses incurred if
 35              // a standard is withdrawn or modified after publication, and shall be
 36              // indemnified and held harmless by any party implementing the
 37              // standard from any and all claims of infringement by a patent owner
 38              // for such implementations.
 39              // 
 40              // For information about patents held by third-parties which have
 41              // notified the DMTF that, in their opinion, such patent may relate to
 42              // or impact implementations of DMTF standards, visit
 43 a.dunfey 1.1 // http://www.dmtf.org/about/policies/disclosures.php.
 44              //#pragma inLine
 45              // ===================================================================
 46              // Description: The Network Model extends the management concepts to
 47              //              represent protocol interfaces and network/protocol
 48              //              services.  This file defines VLAN (virtual LAN)
 49              //              concepts.
 50              // 
 51              //              The object classes below are listed in an order that
 52              //              avoids forward references. Required objects, defined
 53              //              by other working groups, are omitted.
 54              // ==================================================================
 55              // 
 56              // Change Log for v2.8
 57              // CR1018 - Classes to define topologies
 58              // Change Log for v2.9 - no changes
 59              // ===================================================================
 60              
 61              #pragma Locale ("en_US")
 62              
 63              
 64 a.dunfey 1.1 // ==================================================================
 65              // DeviceConnectivityCollection
 66              // ==================================================================
 67                 [Experimental, Version ( "2.8.1000" ), Description (
 68                     "DeviceConnectivityCollection describes connectivity WITHIN a "
 69                     "single system. The system forwards packets among the members "
 70                     "of the collection. For example, this class is used to "
 71                     "represent connectivity within a router or switch. There may be "
 72                     "multiple DeviceConnectivityCollection instances for a system, "
 73                     "when multiple forwarding domains exist. For example, an "
 74                     "Ethernet switch may separate its LANEndpoints into two groups, "
 75                     "each associated with a different virtual LAN. The LANEndpoints "
 76                     "for each group would be segregated into separate "
 77                     "DeviceConnectivity Collections.")]
 78              class CIM_DeviceConnectivityCollection : CIM_ConnectivityCollection {
 79              };
 80              
 81              
 82              // ==================================================================
 83              // TopologyGraph
 84              // ==================================================================
 85 a.dunfey 1.1    [Experimental, Version ( "2.8.1000" ), Description (
 86                     "TopologyGraph is a general structure for representing network "
 87                     "topologies. Often, a topology graph consists of a set of nodes "
 88                     "and a set of edges which connect the nodes. The TopologyGraph "
 89                     "structure is slightly different, in order to support "
 90                     "multipoint links and to express the connectivity within what "
 91                     "would normally be considered a 'node'. Multipoint links occur "
 92                     "in entities such as IP subnets, where all of the IP endpoints "
 93                     "on the subnet can communicate directly, and Ethernet links "
 94                     "where all of the Ethernet interfaces on the shared media can "
 95                     "communicate directly. An example of connectivity within a node "
 96                     "is when the various endpoints/interfaces on a router are "
 97                     "connected through the router's forwarding mechanism. There may "
 98                     "be different groups of endpoints which communicate within "
 99                     "their groups exclusively. This is modeled as a "
100                     "DeviceConnectivityCollection. \n"
101                     "\n"
102                     "To represent these examples in a graph structure, "
103                     "TopologyGraph generalizes the node and edge structures of a "
104                     "typical graph. It is a collection of ConnectivityCollections, "
105                     "which can communicate with one another, and are at the same "
106 a.dunfey 1.1        "protocol layer. ConnectivityCollections are aggregated into "
107                     "Topology Graphs using the MemberOfCollection relationship. \n"
108                     "\n"
109                     "The actual network topology encoded in TopologyGraph is "
110                     "extracted by connecting the ConnectivityCollection instances "
111                     "that share common ProtocolEndpoint instances. For example, if "
112                     "the graph contains three collections, defined as: \n"
113                     "- Router1={PE1, PE2}, a DeviceConnectivityCollection \n"
114                     "- Link1={PE2, PE3}, an IPConnectivitySubnet \n"
115                     "- Router2={PE3, PE4}, a DeviceConnectivityCollection \n"
116                     "then we can determine that the PE2 interface on Router1 is "
117                     "connected to the PE3 interface on Router2 via the subnet "
118                     "Link1. By finding all of the endpoints that are in multiple "
119                     "ConnectivityCollections within the graph, and connecting those "
120                     "Collections with common endpoints, we can construct the "
121                     "network topology.")]
122              class CIM_TopologyGraph : CIM_Collection {
123              
124                    [Key, Description (
125                        "Within the scope of the instantiating Namespace, InstanceID "
126                        "opaquely and uniquely identifies an instance of this class. "
127 a.dunfey 1.1           "In order to ensure uniqueness within the NameSpace, the "
128                        "value of InstanceID SHOULD be constructed using the "
129                        "following 'preferred' algorithm: \n"
130                        "<OrgID>:<LocalID> \n"
131                        "Where <OrgID> and <LocalID> are separated by a colon ':', "
132                        "and where <OrgID> MUST include a copyrighted, trademarked "
133                        "or otherwise unique name that is owned by the business "
134                        "entity creating/defining the InstanceID, or is a registered "
135                        "ID that is assigned to the business entity by a recognized "
136                        "global authority (This is similar to the <Schema "
137                        "Name>_<Class Name> structure of Schema class names.) In "
138                        "addition, to ensure uniqueness <OrgID> MUST NOT contain a "
139                        "colon (':'). When using this algorithm, the first colon to "
140                        "appear in InstanceID MUST appear between <OrgID> and "
141                        "<LocalID>. \n"
142                        "<LocalID> is chosen by the business entity and SHOULD not "
143                        "be re-used to identify different underlying (real-world) "
144                        "elements. If the above 'preferred' algorithm is not used, "
145                        "the defining entity MUST assure that the resultant "
146                        "InstanceID is not re-used across any InstanceIDs produced "
147                        "by this or other providers for this instance's NameSpace. \n"
148 a.dunfey 1.1           "For DMTF defined instances, the 'preferred' algorithm MUST "
149                        "be used with the <OrgID> set to 'CIM'.")]
150                 string InstanceID;
151              };
152              
153              // ==================================================================
154              // RelatedTopologyGraph
155              // ==================================================================
156                 [Association, Experimental, Version ( "2.8.1000" ), Description (
157                     "RelatedTopologyGraph associates a TopologyGraph instance with "
158                     "a ConnectivityCollection. This relationship is different from "
159                     "a topology graph collecting ConnectivityCollections. It "
160                     "describes the embedding of a lower layer topology within a "
161                     "ConnectivityCollection. For example, a layer 3 IP subnet "
162                     "(represented by an instance of IPConnectivitySubnet) collects "
163                     "a set of IPProtocolEndpoints. It might also be associated with "
164                     "a TopologyGraph describing the layer 2 switched Ethernet "
165                     "topology over which the IP subnet runs. This association of "
166                     "Layer 3 to Layer 2 is described as a Dependency relationship, "
167                     "where the Layer 3 connectivity is dependent on the Layer 2 "
168                     "topology.")]
169 a.dunfey 1.1 class CIM_RelatedTopologyGraph : CIM_Dependency {
170              
171                    [Override ( "Antecedent" ), Description (
172                        "A topology graph which underlies a ConnectivityCollection.")]
173                 CIM_TopologyGraph REF Antecedent;
174              
175                    [Override ( "Dependent" ), Description (
176                        "The ConnectivityCollection which depends on the underlying "
177                        "topology.")]
178                 CIM_ConnectivityCollection REF Dependent;
179              };
180              
181              
182              // ===================================================================
183              // end of file
184              // ===================================================================

No CVS admin address has been configured
Powered by
ViewCVS 0.9.2