Return to Network28_Topology.mof CVS log

Up to [Pegasus] / pegasus / Schemas / CIMPrelim28

PEP#: 215
TITLE: Remove old schemas

DESCRIPTION:

Removing old, unneeded schema files from the repository:

CIM 2.7
CIM 2.7.1 Preliminary
CIM 2.8 Preliminary
CIM 2.9 Preliminary

// ===================================================================
// Title:       Network Topology 2.8
// Filename:    Network28_Topology.mof
// Version:     2.8
// Status:      Preliminary
// Date:        June 6, 2003
// ===================================================================
// Copyright 1998-2003 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.
// ===================================================================
// 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
// ===================================================================

#pragma Locale ("en_US")


// ==================================================================
// DeviceConnectivityCollection
// ==================================================================
   [Experimental, Version ("2.7.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.7.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.7.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
// ===================================================================