Return to Network_Topology.mof CVS log

Up to [Pegasus] / pegasus / Schemas / CIMPrelim291

BUG#: 4664
TITLE: CIMPrelim291 schema is obsolete
DESCRIPTION: Removing the obsolete schema.

// ===================================================================
// Title:  Network Topology
// $State: dead $
// $Date: 2006/01/17 20:13:15 $
// $Source: /cvs/MSB/pegasus/Schemas/CIMPrelim291/Attic/Network_Topology.mof,v $
// $Revision: 1.2 $
// ===================================================================
//#pragma inLine ("Includes/copyright.inc")
// Copyright 1998-2005 Distributed Management Task Force, Inc. (DMTF).
// All rights reserved.
// DMTF is a not-for-profit association of industry members dedicated
// to promoting enterprise and systems management and interoperability.
// DMTF specifications and documents may be reproduced for uses
// consistent with this purpose by members and non-members,
// provided that correct attribution is given.
// As DMTF specifications may be revised from time to time,
// the particular version and release date should always be noted.
// 
// Implementation of certain elements of this standard or proposed
// standard may be subject to third party patent rights, including
// provisional patent rights (herein "patent rights"). DMTF makes
// no representations to users of the standard as to the existence
// of such rights, and is not responsible to recognize, disclose, or
// identify any or all such third party patent right, owners or
// claimants, nor for any incomplete or inaccurate identification or
// disclosure of such rights, owners or claimants. DMTF shall have no
// liability to any party, in any manner or circumstance, under any
// legal theory whatsoever, for failure to recognize, disclose, or
// identify any such third party patent rights, or for such party's
// reliance on the standard or incorporation thereof in its product,
// protocols or testing procedures. DMTF shall have no liability to
// any party implementing such standard, whether such implementation
// is foreseeable or not, nor to any patent owner or claimant, and shall
// have no liability or responsibility for costs or losses incurred if
// a standard is withdrawn or modified after publication, and shall be
// indemnified and held harmless by any party implementing the
// standard from any and all claims of infringement by a patent owner
// for such implementations.
// 
// For information about patents held by third-parties which have
// notified the DMTF that, in their opinion, such patent may relate to
// or impact implementations of DMTF standards, visit
// http://www.dmtf.org/about/policies/disclosures.php.
//#pragma inLine
// ===================================================================
// Description: The Network Model extends the management concepts to
//              represent protocol interfaces and network/protocol
//              services.  This file defines VLAN (virtual LAN)
//              concepts.
// 
//              The object classes below are listed in an order that
//              avoids forward references. Required objects, defined
//              by other working groups, are omitted.
// ==================================================================
// 
// Change Log for v2.8
// CR1018 - Classes to define topologies
// Change Log for v2.9 - no changes
// ===================================================================

#pragma Locale ("en_US")


// ==================================================================
// DeviceConnectivityCollection
// ==================================================================
   [Experimental, Version ( "2.8.1000" ), Description (
       "DeviceConnectivityCollection describes connectivity WITHIN a "
       "single system. The system forwards packets among the members "
       "of the collection. For example, this class is used to "
       "represent connectivity within a router or switch. There may be "
       "multiple DeviceConnectivityCollection instances for a system, "
       "when multiple forwarding domains exist. For example, an "
       "Ethernet switch may separate its LANEndpoints into two groups, "
       "each associated with a different virtual LAN. The LANEndpoints "
       "for each group would be segregated into separate "
       "DeviceConnectivity Collections.")]
class CIM_DeviceConnectivityCollection : CIM_ConnectivityCollection {
};


// ==================================================================
// TopologyGraph
// ==================================================================
   [Experimental, Version ( "2.8.1000" ), Description (
       "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. \n"
       "\n"
       "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. \n"
       "\n"
       "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: \n"
       "- Router1={PE1, PE2}, a DeviceConnectivityCollection \n"
       "- Link1={PE2, PE3}, an IPConnectivitySubnet \n"
       "- Router2={PE3, PE4}, a DeviceConnectivityCollection \n"
       "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.")]
class CIM_TopologyGraph : CIM_Collection {

      [Key, Description (
          "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: \n"
          "<OrgID>:<LocalID> \n"
          "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>. \n"
          "<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. \n"
          "For DMTF defined instances, the 'preferred' algorithm MUST "
          "be used with the <OrgID> set to 'CIM'.")]
   string InstanceID;
};

// ==================================================================
// RelatedTopologyGraph
// ==================================================================
   [Association, Experimental, Version ( "2.8.1000" ), Description (
       "RelatedTopologyGraph associates a TopologyGraph instance with "
       "a ConnectivityCollection. This relationship is different from "
       "a topology graph collecting ConnectivityCollections. It "
       "describes the embedding of a lower layer topology within a "
       "ConnectivityCollection. For example, a layer 3 IP subnet "
       "(represented by an instance of IPConnectivitySubnet) collects "
       "a set of IPProtocolEndpoints. It might also be associated with "
       "a TopologyGraph describing the layer 2 switched Ethernet "
       "topology over which the IP subnet runs. This association of "
       "Layer 3 to Layer 2 is described as a Dependency relationship, "
       "where the Layer 3 connectivity is dependent on the Layer 2 "
       "topology.")]
class CIM_RelatedTopologyGraph : CIM_Dependency {

      [Override ( "Antecedent" ), Description (
          "A topology graph which underlies a ConnectivityCollection.")]
   CIM_TopologyGraph REF Antecedent;

      [Override ( "Dependent" ), Description (
          "The ConnectivityCollection which depends on the underlying "
          "topology.")]
   CIM_ConnectivityCollection REF Dependent;
};


// ===================================================================
// end of file
// ===================================================================