Figure PR.04 - The Makeup of a Device - Illustrative

At this point, we need to be cognizant of existing standards. M.3100 has defined the Equipment and EquipmentHolder classes, as previously mentioned. Unfortunately, it defined those classes mostly from a logical point-of-view, and failed to take into account important physical characteristics that we need. Therefore, we’re going to use the concept of “Hardware” to represent Equipment, EquipmentHolders and AuxiliaryComponents.<br/>This will pay dividends in the future, and enable us to assign common physical attributes, such as weight, length, and others, to the Hardware class so that its subclasses can inherit them. Note that such aspects are missing from M.3100.<br/>A Device, such as a Router, is in reality represented by a PhysicalDevice, which is made up of different Hardware entities. This enables different users having different use cases to represent the router as either a single physical entity, or as a rich collection of interconnected entities.<br/>PhysicalDevice enables the router to be thought of as a single atomic object. This is necessary for a variety of different use cases. For example, many types of resource planning processes require a single object to represent one or more complex sets of objects. Even though each object in a group of objects can be individually manageable, the group of objects as a whole has meaning. This enables us to refer to the router as, for example, the “Internet Gateway Router”.<br/>The individual line cards that are contained within the Router are represented (as we will see) by subclasses of Equipment. Equipment are particular types of Hardware objects, and are related to a particular PhysicalDevice using the consistsOf aggregation. The following will expand on these concepts.<br/>It is important to be able to manage the individual components of a higher-level object. This is the purpose of the Hardware base class. Hardware consists of Equipment (e.g., a LineCard that performs routing), EquipmentHolders (e.g., a Chassis or some other managed entity whose purpose is to “hold” Equipment), and AuxiliaryComponents (physical components that are required by the “Device” to operate correctly, but whose individual purposes are orthogonal to the main purpose of the device). This is shown in the Figure below.<br/>The difference between Equipment and AuxiliaryComponents are whether or not the physical object performs a function intrinsic to the main function of the Device. This is best understood by way of example. The main function of a Router is to route and forward packets. A PowerSupply is an AuxiliaryComponent, because while it is needed for the proper operation of the Router, it does not directly help in routing and forwarding packets. A LineCard (that provides routing functionality) is an Equipment component, because its purpose is to route and forward packets. Similar examples exist for different types of equipment, where their criteria may be different. For example, instead of whether it routes or forwards packets, the criterion “does it carry signal” may be useful to appropriately classify components.<br/>The following Figure shows that what people conceptually think of a Router or a Switch is in reality a set of managed entities. (Again, it is important to remember that while this Addendum uses network device examples for consistency, the principles and models described in this Addendum apply to other types of physical entities as well.) The physical entity that one can pick up and refer to as a Router or a Switch is represented in the following Figure by an instance of the PhysicalDevice class, which is a specific type of PhysicalResource. The PhysicalDevice may consist of zero or more Hardware components, depending on the needs of the user. That is, it is perfectly reasonable for users of this model to use all or parts of it to suit their needs.<br/>Note that the cardinality of the ConsistsOf aggregation is a “may”, not a “must”, as indicated by the 0..1 cardinality of the composite end and the 0..n on the parts end of the aggregation).<br/>Hardware is an abstract base class for defining managed components that are part of a PhysicalDevice. At this level of abstraction, it consists of three principal classes - EquipmentHolder, Equipment, and AuxiliaryComponent. This enables us to satisfy one of our main requirements, in that we can refer to the Network Device as a whole (using the PhysicalDevice object), or specifically to the components of a Network Device (using entities that are subclasses of Equipment, EquipmentHolder, and AuxiliaryComponent). This latter ability is the basis for constructing Bill of Materials, Spare Inventory, and other applications that require a robust physical component model.<br/>Note that AuxiliaryComponent, Equipment, and EquipmentHolder are all subclasses (i.e., children) of the Hardware entity. This enables these objects to inherit the attributes and relationships of their superclasses (i.e., parents). Thus, instead of having to define three relationships (one each between PhysicalDevice and Equipment, EquipmentHolder and AuxiliaryComponent), all we need to do is to define a single relationship between PhysicalDevice and Hardware. This relationship, ConsistsOf, is inherited by the three subclasses of Hardware, and enables each of these subclasses to be “contained in” (or, more precisely, be a part of) a device.<br/>The above model also lays the groundwork for modelling the physical properties of different types of devices. Think again about a Router. A Router is what we refer to as a particular type of “Device”. A Switch is another type of Device. Thus, we have the notion that a “Device” can be a Router or a Switch. This is fortunate, because we don’t want to have to go through this entire procedure again for each new type of Device!<br/>Almost all such Devices are Chassis-based Devices, meaning that the Router functionality is based around a chassis that holds Hardware. The AuxiliaryComponents (e.g., a PowerSupply) are necessary for the Router to operate properly, while the Hardware components supply functionality that directly contributes to the basic functions of the Router (i.e., routing and forwarding packets).<br/>Note that there are many different types of Cards – LineCards, SystemCards, MemoryCards, and so forth. Not all of these Card types are Equipment from the Router’s point-of-view, because not all of them do routing and forwarding functions. A MemoryCard is a good example of this. We’ll deal with this added bit of complexity later in the model by more fully developing the difference between Equipment, EquipmentHolder, and AuxiliaryComponent.<br/>