|
DMTF Tutorial > CIM > CIM Schema > Common Models > Network Model
The Network Model describes and manages communications connectivity and the network "cloud", as well as the individual services and protocols in the network. The managed entities in the model may be grouped into broad categories describing:
The information model characterizes a network as a type of administrative domain, which in itself may contain other networks, sub-networks or domains. These may be defined according to criteria such as a business' management policy domains or geography. In order to operate the network infrastructure, networking services are required and are thus defined in the model. Given the wide use of the word "service", it is important to point out that within the context of the current information model, "service" refers to the functionality provided by infrastructure services, or required by the individual network elements to operate and exchange information. Examples of these services are Routing (for example, OSPF and BGP), Forwarding, and quality of service (QoS). Within the administrative domains/networks, there are network elements (also known as network systems or network devices). These sit at the core of the network or at its edges. There is much confusion over how to model a network system, since many companies believe that these are different than CIM_ComputerSystems. However, after detailed analysis, it was found that network systems fit the same pattern (i.e., have the same basic properties, methods and associations) as Computer Systems. This can be seen in the figure below, which depicts the various aspects of a router.
Admittedly, network elements are dedicated systems – with hardware and software tuned for network performance and functionality. (Note that Dedicated is a property defined on the ComputerSystem class!) The distinction is that the network element's hardware and software are the components OF the system, not the system itself. Therefore, a network system is modeled as an instance of ComputerSystem with associations to the LogicalDevices, Services and ServiceAccessPoints that are hosted on it, or components of it. Services are made available or accessed throughout a network via ProtocolEndpoints (a subclass of Service Access Point). Endpoints describe and manage the protocol-specific configuration, state and addressing information that is needed to transmit and receive messages on a network. Protocol Endpoint's properties provide details on total bandwidth, available bandwidth, keepalive timers, retry intervals, etc. Two Protocol Endpoints may be associated within a system or across a network. Usually, the former describes the protocol stack on a platform – for example, a TCP port running over an IP address on an Ethernet network. This is modeled via a many-to-many relationship, BindsTo. The reason that the association is many-to-many is because it is possible to combine the communication capabilities of lower level ports into a single higher level one, or take a large bandwidth interface and run several higher level interfaces over it. This requirement to describe fan-in and fan-out bindings guided the design of the BindsTo association. Connecting across a network (or even within a system), the ActiveConnection association represents this semantic (i.e., the exchange of information between two Protocol Endpoints). Typically, this association occurs between endpoints at the same protocol level within a communication stack or application. ActiveConnection is used when the potential for communication should be represented, but the connection itself is not managed. That is, the connection exists but it does not have a state nor configuration information associated with it. In situations where there is a need for a managed connection, independent of the managed endpoints, the Network Pipe class is used instead. Network Pipe is a subclass of Enabled Logical Element, and is not an association. It does have its own associations to the Protocol Endpoints that are the ends of the pipe. All of these logical entities must be associated to the PhysicalPackages and components that are being managed. Although this is not specified as part of the networks model, it is an integral part of the overall model needed to manage the network. The reader is encouraged to consult the Core, Physical and Device Common Models for further details. In addition to general aspects of the Network Model, specific technology and protocol areas are also addressed. Two commonly used routing protocols are defined in the model, OSPF and BGP. In both cases, the respective sub-models focus on the configuration of the routing protocol. The protocols are characterized in terms of the services that they offer, the endpoints through which these services are made available, and protocol specific configuration parameters. In the switching arena, the model covers Spanning Tree Protocol (STP), bridging functions, VLANs and at a slightly higher protocol layer, MPLS. The VLAN model represents a VLAN as a logical network (basically, a collection of protocol endpoints for connectivity), composed of switch and user station endpoints. The VLAN to STP relationship is defined as part of the Switching and Bridging sub-model. The MPLS sub-model focuses on the configuration aspects of Label Switched Paths (LSPs) and Traffic Engineering (TE) Tunnels, which may ride on defined LSPs. In conclusion, the Network Model broadly describes and manages general connectivity between systems, as well as network technology and protocol specifics. It covers not only the configuration and state aspects of management, but also defines statistics that may be collected from the network elements in support of performance management applications.
|
