Shared Information/Data

(SID) Model
Addendum 5PR – Physical Resource
Business Entity Definitions
NGOSS Release 4.0

GB922 Addendum-5PR

TMF Approved Version 3.1 August, 2004

TeleManagement Forum 2004
SID Model - Addendum 5PR – Physical Resource Page ii

Notice
The TeleManagement Forum (“TM Forum”) has
made every effort to ensure that the contents of this
document are accurate. However, due to the
inherent complexity in the design and implementation
of software and systems, no liability is accepted for
any errors or omissions or for consequences of any
use made of this document. Under no circumstances
will the TM Forum be liable for direct or indirect
damages or any costs or losses resulting from the
use of this specification. The risk of designing and
implementing products in accordance with this
specification is borne solely by the user of this
specification. This document may involve a claim of
patent rights by one or more TM Forum members,
pursuant to the agreement on Intellectual Property
Rights between TM Forum and its members, and by
non-members of TM Forum.

This document is a copyrighted document of TM

Forum, and if reproduced in any manner shall clearly
acknowledge the authorship of TM Forum.

This document may involve a claim of patent rights

by one or more of the contributors to this document,
pursuant to the Agreement on Intellectual Rights
between the TM Forum and its members. Interested
parties should contact the TM Forum office to obtain
notice of current patent rights claims subject to this
document.

Direct inquiries to the TM Forum office:

89 Headquarters Plaza North - Suite 350
Morristown, NJ 07960 USA
Tel No. +1 973 292 1901
Fax No. +1 973 993 3131
TM Forum Web Page: www.tmforum.org

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page iii

Acknowledgments
This document was prepared by the members of the TeleManagement Forum SID team:

The Shared Information/Data Model is a genuinely collaborative effort. The TM Forum would
like to thank the following people for contributing their time and expertise to the production of
this document. It is just not possible to recognize all the organizations and individuals that
have contributed or influenced the introduction. We apologize to any person or organization
we inadvertently missed in these acknowledgments.

Key individuals that reviewed, provided input, managed, and determined how to utilize
inputs coming from all over the world, and really made this document happen were:

Name Affiliation
Cliff Faurer TeleManagement Forum
Ram Garg MetaSolv Software
Chris Hartley Telstra
Helen Hepburn British Telecom
Jenny Huang AT&T
Matt Izzo Agilent
Mike McLoughlin British Telecom
John Reilly MetaSolv Software
Wayne Sigley Telstra
John Strassner Intelliden (editor)

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page iv

About TeleManagement Forum

TeleManagement Forum is an international consortium of communications service providers
and their suppliers. Its mission is to help service providers and network operators automate
their business processes in a cost- and time-effective way. Specifically, the work of the TM
Forum includes:
Establishing operational guidance on the shape of business processes.
Agreeing on information that needs to flow from one process activity to
another.
Identifying a realistic systems environment to support the interconnection
of operational support systems.
Enabling the development of a market and real products for integrating
and automating telecom operations processes.
The members of TM Forum include service providers, network operators and suppliers of
equipment and software to the communications industry. With that combination of buyers
and suppliers of operational support systems, TM Forum is able to achieve results in a
pragmatic way that leads to product offerings (from member companies) as well as paper
specifications.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page v

About this document

This is a TM Forum Guidebook. The guidebook format is used when:
The document lays out a ‘core’ part of TM Forum’s approach to
automating business processes. Such guidebooks would include the
Telecom Operations Map and the Technology Integration Map, but not
the detailed specifications that are developed in support of the approach.
Information about TM Forum policy, or goals or programs is provided,
such as the Strategic Plan or Operating Plan.
Information about the marketplace is provided, as in the report on the
size of the OSS market.

Document Life Cycle

This document is being issued for Member Evaluation. The purpose of an Evaluation
Version is to encourage input based on experience of members and the public as they begin
to use the document. Following the Evaluation Period, documents that are seen to deliver
value are candidates for formal approval by the TM Forum. All documents approved by the
TM Forum undergo a formal review and approval process.

This document will continue under formal change control. Supporting work will be issued as
companions to this document. A document of this type is a “living document,” capturing and
communicating current knowledge and practices. Further inputs will be made because of
detailed work ongoing in the TM Forum and the industry.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page vi

Document History

Version Author Date Purpose

0.1 J. Strassner Jan 2002 GB915 Addendum Template created from TMF407 v1.1
Guidebook template
0.2 J. Strassner Feb 2002 Initial population using DEN-ng physical model, which
contains mined information from DEN, CIM, and M.3100
0.3 J. Strassner Mar 2002 Revisions and publication to Resource team
0.4 J. Strassner Apr 2002 Revisions from JohnR and Wayne incorporated
0.45 J. Strassner Apr 2002 Revisions to build closer link to Location model; additional
business entity definitions
0.5 J. Strassner May 2002 Final revisions per SID conference call
1.0 TMF June 2002 Formatted for Member Evaluation release
1.1 J. Strassner August Incorporation of review comments from Phase 2 work
2002
1.5 J. Strassner September Incorporated final review comments from Phase 2 work
2002 and implementation experience comments
1.6 J. Strassner October Minor revisions incorporated from final review
2002
2.0 TMF October Formatted for Member Evaluation release
2002
2.1 J. Strassner May 2003 Revisions to sync this model to other Addenda that are
part of NGOSS release 3.5
2.2 J. Strassner June 2003 Final submission to team
2.3 J. Strassner June 2003 Minor corrections to PartyRole interaction
3.0 TMF July 2003 Formatted for Member Review with NGOSS R3.5
3.1 TMF Aug 2004 To reflect TMF Approved status

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page vii

Time Stamp

This version of this document can be considered valid until further notice.

How to obtain a copy

An electronic copy of this document can be downloaded at the TM Forum Web Site
(www.tmforum.org) at Publications or through a link to Publications from a specific team’s
public project area.

If the document version has only been released to members for review and comment, the
document can only be downloaded from the TM Forum Web Site in the Members Only
Area. Depending upon the document, it could be accessible from New Items, Evaluation
Versions, or a team’s Members Only project area.

If you would like a paper version of this document, please order via the TM Forum Web Site
or contact the TM Forum office. If you are not a member, please contact the TM Forum
office on +1.973.292.1901.

How to comment on the document

Comments must be in written form and addressed to the SIM team leaders and TMF staff
sponsor for review with the project team. Please send your comments to the contacts shown
below:

John Reilly [email protected] +1 972-403-8408

John Strassner [email protected] +1 719-785-0648
Cliff Faurer [email protected] +1 303-367-1443

Team email: [email protected]

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page viii

Table of Contents
Notice ...........................................................................................................................................................................ii
Acknowledgments ....................................................................................................................................................iii
About TeleManagement Forum ..............................................................................................................................iv
About this document .................................................................................................................................................v
Document Life Cycle .............................................................................................................................................v
Document History.................................................................................................................................................vi
Time Stamp ......................................................................................................................................................... vii
How to obtain a copy........................................................................................................................................... vii
How to comment on the document .................................................................................................................... vii
Table of Contents ....................................................................................................................................................viii
Table of Figures........................................................................................................................................................ xi
Business Entities....................................................................................................................................................... 1
Physical Resource Domain.................................................................................................................................. 1
Introduction ...................................................................................................................................................1
Overview of “Physical Resource” ................................................................................................................4
Use Cases ....................................................................................................................................................5
A Starting Point – Supporting Basic Inventory Concepts...........................................................................6
Equipment Requirements In More Detail....................................................................................................9
Device Roles ..............................................................................................................................................22
PhysicalResource Business Entities in More Detail......................................................................................... 24
Filling in the Details ....................................................................................................................................24
PhysicalResource ......................................................................................................................................25
PhysicalDevice in More Detail ...................................................................................................................29
Hardware in More Detail ............................................................................................................................30
PhysicalConnector .....................................................................................................................................31
ManagedHardware ....................................................................................................................................32
PhysicalPort................................................................................................................................................34
PhysicalContainer ......................................................................................................................................36
PhysicalRoles in More Detail.....................................................................................................................38
EquipmentHolder in More Detail ...............................................................................................................40
Adapter and Holder Roles .........................................................................................................................46
Equipment in More Detail ..........................................................................................................................48
Types of Cards ...........................................................................................................................................50
AuxiliaryComponents .................................................................................................................................51
PhysicalComponents .................................................................................................................................52
Basic Business Entities That Interact with PhysicalResources ....................................................................... 53
Party and PartyRole ...................................................................................................................................54
Location ......................................................................................................................................................58
Capacity and Redundancy ........................................................................................................................60
Product........................................................................................................................................................61
Additional Examples...................................................................................................................................66
References ......................................................................................................................................................... 67
Business Entity Definitions................................................................................................................................. 68
PhysicalResource Business Entity Definition ...........................................................................................69
Business Entity Model – PhysicalResource .............................................................................................71
PhysicalResourceSpecification Business Entity Definition ......................................................................72
Business Entity Model – PhysicalResourceSpecification ........................................................................74
PhysicalResourceRole Business Entity Definition....................................................................................75
Business Entity Model – PhysicalResourceRole......................................................................................77

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page ix

PhysicalHolderRole Business Entity Definition.........................................................................................78

Business Entity Model – PhysicalHolderRole...........................................................................................80
PhysicalAdapterRole Business Entity Definition ......................................................................................81
Business Entity Model – PhysicalAdapterRole.........................................................................................82
Hardware Business Entity Definition .........................................................................................................83
Business Entity Model – Hardware ...........................................................................................................86
ManagedHardware Business Entity Definition .........................................................................................87
Business Entity Model – ManagedHardware ...........................................................................................90
PhysicalContainer Business Entity Definition ...........................................................................................91
Business Entity Model – PhysicalContainer .............................................................................................93
PhysicalDevice Business Entity Definition................................................................................................94
Business Entity Model – PhysicalDevice ..................................................................................................96
PhysicalDeviceAtomic Business Entity Definition ....................................................................................97
Business Entity Model – PhysicalDeviceAtomic.......................................................................................98
PhysicalDeviceComposite Business Entity Definition..............................................................................99
Business Entity Model – PhysicalDeviceComposite..............................................................................100
PhysicalConnector Business Entity Definition ........................................................................................101
Business Entity Model – PhysicalConnector ..........................................................................................104
PhysicalPort Business Entity Definition...................................................................................................105
Business Entity Model – PhysicalPort.....................................................................................................108
Equipment Business Entity Definition .....................................................................................................109
Business Entity Model - Equipment ........................................................................................................112
Card Business Entity Definition ...............................................................................................................113
Business Entity Model – Card .................................................................................................................117
MemoryCard Business Entity Definition..................................................................................................118
Business Entity Model – MemoryCard....................................................................................................119
NetworkCard Business Entity Definition .................................................................................................120
Business Entity Model – NetworkCard....................................................................................................121
SystemCard Business Entity Definition...................................................................................................122
Business Entity Model – SystemCard.....................................................................................................123
UnknownCard Business Entity Definition ...............................................................................................124
Business Entity Model – UnknownCard..................................................................................................125
EquipmentHolder Business Entity Definition ..........................................................................................126
Business Entity Model – EquipmentHolder ............................................................................................128
HolderAtomic Business Entity Definition.................................................................................................129
Business Entity Model – HolderAtomic...................................................................................................131
Slot Business Entity Definition.................................................................................................................132
Business Entity Model – Slot ...................................................................................................................135
HolderComposite Business Entity Definition ..........................................................................................136
Business Entity Model – HolderComposite ............................................................................................138
SecureHolder Business Entity Definition ................................................................................................139
Business Entity Model – SecureHolder...................................................................................................142
Rack Business Entity Definition...............................................................................................................143
Business Entity Model – Rack and Chassis ...........................................................................................145
Chassis Business Entity Definition ..........................................................................................................146
Business Entity Model – Chassis ............................................................................................................148
AuxiliaryComponent Business Entity Definition......................................................................................149
Business Entity Model – AuxiliaryComponent........................................................................................151
CoolingDevice Business Entity Definition ...............................................................................................152
Business Entity Model – CoolingDevice .................................................................................................154
Fan Business Entity Definition.................................................................................................................155
Business Entity Model – Fan ...................................................................................................................157
PowerSupply Business Entity Definition .................................................................................................158
Business Entity Model – PowerSupply ...................................................................................................161
PhysicalComponent Business Entity Definition......................................................................................162
Business Entity Model – PhysicalComponent........................................................................................164

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page x

Backplane Business Entity Definition......................................................................................................165

Business Entity Model – Backplane........................................................................................................166
Chip Business Entity Definition................................................................................................................167
Business Entity Model – Chip..................................................................................................................169
ASIC Business Entity Definition...............................................................................................................170
Business Entity Model – ASIC.................................................................................................................171
MemoryComponent Business Entity Definition ......................................................................................172
Business Entity Model – MemoryComponent ........................................................................................173
FlashDisk Business Entity Definition.......................................................................................................174
Business Entity Model – FlashDisk .........................................................................................................175

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page xi

Table of Figures
Figure 5PR- 1. eTOM Level 0 Concepts and Domains 2
Figure 5PR- 2. Level One of the Resource Domain of the SID Framework 3
Figure 5PR- 3. Starting Point for Modeling PhysicalResources 6
Figure 5PR- 4. Different Aspects of a Device 11
Figure 5PR- 5. Relating the Physical and Logical Aspects of a Device to Each Other 13
Figure 5PR- 6. The Makeup of a Device 16
Figure 5PR- 7. The Concept of “Holding” Hardware 18
Figure 5PR- 8. Our Simple Example Router 20
Figure 5PR- 9. The Concept of a DeviceRole 23
Figure 5PR- 10. First Attempt at Defining the Attributes of a PhysicalResource 25
Figure 5PR- 11. The Relationship Between PhysicalResource and
PhysicalResourceSpecification 26
Figure 5PR- 12. Specifying the PhysicalDevice and Hardware Classes in More Detail 29
Figure 5PR- 13. Hardware in More Detail 30
Figure 5PR- 14. Physical Connector 31
Figure 5PR- 15. ManagedHardware in More Detail 32
Figure 5PR- 16. PhysicalPort in More Detail 34
Figure 5PR- 17. PhysicalContainer in More Detail 36
Figure 5PR- 18. PhysicalDeviceRole and HardwareRole 38
Figure 5PR- 19. Examples of PhysicalDeviceRoles 39
Figure 5PR- 20. Specifying Different Types of EquipmentHolders 40
Figure 5PR- 21. HolderAtomic in More Detail 42
Figure 5PR- 22. HolderComposite in More Detail 44
Figure 5PR- 23. AdapterRoles and HolderRoles 46
Figure 5PR- 24. Equipment in More Detail 48
Figure 5PR- 25. Relating PhysicalPorts to Cards and Chassis 49
Figure 5PR- 26. Types of Cards 50
Figure 5PR- 27. Exemplary Subclasses of AuxiliaryComponent 51
Figure 5PR- 28. Example Subclasses of PhysicalComponent 52
Figure 5PR- 29. Overview of Party and PartyRole 55
Figure 5PR- 30. Representing Administering and Owning a Resource 56
Figure 5PR- 31. Representing the Physical Location of Physical Objects 58
Figure 5PR- 32. Simplified Product Model 61

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page xii

Figure 5PR- 33. Relationship Between ProductSpec, ResourceSpec and ServiceSpec62

Figure 5PR- 34. Relationship Between Product, Service and Resource 64
Figure 5PR- 35. PhysicalResource Business Entity Model 71
Figure 5PR- 36. PhysicalResourceSpecification Business Entity Model 74
Figure 5PR- 37. PhysicalResourceRole Business Entity Model 77
Figure 5PR- 38. PhysicalHolderRole Business Entity Model 80
Figure 5PR- 39. Hardware Business Entity Model 86
Figure 5PR- 40. ManagedHardware Business Entity Model 90
Figure 5PR- 41. PhysicalContainer Business Entity Model 93
Figure 5PR- 42. PhysicalDevice Business Entity Model 96
Figure 5PR- 43. PhysicalConnector Business Entity Model 104
Figure 5PR- 44. PhysicalPort Business Entity Model 108
Figure 5PR- 45. Equipment Business Entity Model 112
Figure 5PR- 46. Card Business Entity Model 117
Figure 5PR- 47. EquipmentHolder Business Entity Model 128
Figure 5PR- 48. HolderAtomic Business Entity Model 131
Figure 5PR- 49. Slot Business Entity Model 135
Figure 5PR- 50. HolderComposite Business Entity Model 138
Figure 5PR- 51. SecureHolder Business Entity Model 142
Figure 5PR- 52. Rack and Chassis Business Entity Model 145
Figure 5PR- 53. AuxiliaryComponent Business Entity Model 151
Figure 5PR- 54. CoolingDevice and Fan Business Entity Model 154
Figure 5PR- 55. PowerSupply Business Entity Model 161
Figure 5PR- 56. PhysicalComponent Business Entity Model 164
Figure 5PR- 57. Chip, ASIC, and MemoryComponent Business Entity Model 169

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 1

Business Entities

Physical Resource Domain

Introduction

One of the goals of the SID model is to enable a seamless transition from business concepts and definitions to other domains, such
as networking. This addendum covers the definition of physical resources.

In looking at ‘”Physical Resource” for the SID model, the modelers used the notion of physical devices and equipment, as defined in
the Resource domain of the eTOM [eTOM], as the basis for defining the appropriate business entities. This domain is concerned
with the management of equipment. While this Addendum concentrates on using network entities as examples of its concepts, it
should be noted that these concepts are generic in nature and all but the network-specific classes apply to other physical entities,
such as laptops, servers, and printers. Physical resources can also represent things that are sold, leased, and so forth, like a phone
and SIM card, and don’t in general have any dependency to network entities. However, this version concentrates on network
entities, and will use network entities as examples, in order to better illustrate a complete worked example and to explain some of the
more subtle parts of the model.

Network entities are described at the physical network level. The eTOM defines functionality to manage the physical inventory, plan
and control physical changes to the network, and provide mechanisms to (for example) measure performance, notify alarms / events
and cater for routine administration. Clearly, most of these functions are logical concepts, but equally clearly, appropriate entities
need to be available in the physical model to enable it to support these functions. While the initial physical model is aimed at
describing networking resources, it contains generic elements that will enable it to be used to represent other types of physical
entities as well. This activity will continue into SID phase IV.

The eTOM [eTOM] implies this separation in its Level 0 Domain map, shown in below.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 2

Customer Customer
Strategy, Infrastructure & Operations
Product

Market, Product & Customer

Market, Product and Customer

Service
Service

Resource (Application, ComputingResource

and Network)
(Application, Computing and Network)

Supplier/Partner
Supplier/Partner

Supplier/Partner Suppliers/Partners

Enterprise Management

Shareholders Employees Other Stakeholders

©TeleManagement Forum October, 2001

Figure 5PR- 1. eTOM Level 0 Concepts and Domains

The reader is encouraged to refer to the eTOM for an explanation of the various business processes that are defined to support the
concepts in the above domains.

The SID uses the SID Framework, as defined in [GB922], to link the eTOM to the SID. Level 1 of the Resource Domain of the SID
Framework is shown in Figure 5PR- 2 below. Please note that this is subject to change over time. This Addendum will concentrate
on defining the Service and ServiceSpecification Aggregate Business Entities (ABEs).

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 3

Figure 5PR- 2. Level One of the Resource Domain of the SID Framework

This Addendum will concentrate on the Resource and ResourceSpecification ABEs, and set the stage for further work on other
ABEs shown in Figure 5PR- 2 in subsequent phases of the SID.

The key concepts looked at were the support of inventory and capacity management functions, as well as support for planning
equipment installation and maintenance. Rudimentary ties to related processes and activities, such as FCAPS activities as defined
in the eTOM, as well as relation to other major SID entities (e.g., Product, Party, and others) are also included in this release. This
model represents physical resource entities from a business-oriented point-of-view, and uses the best of standard modeling patterns
for this area to build in extensibility. For example, patterns are used to capture common relationships and occurrences of physical
connections and structures, thereby making the model inherently extensible.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 4

Three important examples of patterns that will be developed in this document are:
Composite pattern, which provides a common structure for stand-alone and aggregate objects of a given type
Entity-EntitySpecification pattern, which separates the invariant characteristics and behavior of an object from its
changeable characteristics and behavior
Role Object pattern, which uses the notion of roles to extend the use and application of an object
Phase IV of the SID will further develop all aspects of this model, and specify more completely the interaction between this model
and other business entities in other SID domains. It is anticipated that this will be a straightforward effort, since this model was
derived from a System model for physical resources.

Overview of “Physical Resource”

This section outlines the approach taken to build the SID physical resource model. The approach used in this document is to build
up pieces of the model gradually due to the complexity of the domain and resulting model.

An important goal of the SID effort is to reuse standards (as opposed to reinventing the same concepts) wherever possible. There
are several important sources of information for these concepts. The most important of these are [M.3100], [DEN-ng], [DEN], and
[CIM]. (Note that problems with the CIM specification, as denoted in [CIMPROB], limited its use to mine information instead of
importing models.) Since this model is a federated model that draws from different standards, we need a starting point for resolving
the naming conflicts that inevitably arise. We have elected to start with [M.3100]. This has a number of ramifications, the most
important of which is that we will use names directly from [M.3100], or names that are compatible with the names found in [M.3100],
wherever possible. The final section of this document contains a detailed data dictionary that defines where classes, attributes,
relationships (e.g., associations, aggregations and compositions) presented in this model were derived. Note that this section has a
special “synonyms / aliases” section to provide easy correlation to these external documents.

Consistent terminology in a federated model is critical. This terminology, as the model itself, will be introduced in stages. This
enables more complex ideas to build on simpler concepts, thereby enabling both an easier as well as a more thorough
understanding of the Physical Resource domain.

Regarding terminology, it is important to be able to relate this view (i.e., the “business” view) of the Physical Resource model to other
views (e.g., the “system” and the “implementation” views) of these same concepts. By doing this, we achieve the important goal of
being able to connect the business requirements to the system representation to how the system is implemented. Thus, we will
establish at the outset two important mappings. First, we will map business concepts to system concepts, and organize the system
view in a way that facilitates various implementations. (Note that the reverse mapping is also possible – the one chosen is based on
the viewpoint of the modeler.) This mapping will be documented in a later phase of the SID.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 5

Second, we will establish a mapping of terminology. For example, business people might think of a “Device” and types of Devices,
such as Routers and Switches. The eTOM [eTOM] refers to the term “resource” in its most general sense as something that can
represent physical equipment as well as other types of entities.

(Note: we define “Device” as a synonym for Equipment and PhysicalResource. “Device” implicitly means the hardware
characteristics of a “Network Device”, such as a router or firewall. Furthermore, a guiding assumption of all SID Addenda is that we
will only model objects that we want or need to manage. While a bolt is a useful and needed object, you won’t find an object
corresponding to a bolt in this Addendum. ☺)

We will over the course of this document define different types of Equipment. As we will see, we need to differentiate between
entities that are Equipment and entities that hold, or contain, Equipment. Therefore, we will also develop a suitable class hierarchy to
enable these and other concepts to be extended.

Use Cases

The primary use case that drove the design of this model is physical inventory. In this use case, it is important to be able to represent
how a particular physical device (equipment) is constructed. For example, for a specific router, we are interested in the number and
type of line cards installed in that router, which slots they occupy, whether it has a backup power supply, and other important
features that, taken together, describe completely the physical characteristics of this device. We are also interested in being able to
describe any spares that exist for the different components of the device being modeled.

There are many different uses of physical inventory as described above. For example, one important use is to be able to understand
how different components in a system are physically connected together. Another example is to relate the physical infrastructure and
topology to the logical topology of the system.

Another closely related use case is the ability to describe the composition and structure of a physical device as a Bill of Materials.
This use case demands a complete listing of all physical components that make up the device, as well as descriptions of where they
are located, so that the equipment may be constructed correctly.

There are many other use cases that require a detailed or partial knowledge of physical inventory. These will be explored in future
versions of this and other Addenda to GB922.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 6

A Starting Point – Supporting Basic Inventory Concepts

Let’s start by categorizing the key entities that need to be modeled:

• Equipment, such as Routers and Switches (for now, this document is focused on chassis-based devices)
• Equipment components, such as line cards
• Equipment “containers”, such as racks and chassis
• location of the Equipment (e.g., a Router is in this rack in this wiring closet…)
• location of a physical item within an Equipment (e.g., ability to distinguish between different physical ports on different
cards of a Router)
• important auxiliary Equipment (e.g., cables, connectors, and power supplies) that are necessary for the correct
operation of the Equipment
This enables us to define a simple starting model, as follows (remember, this is not the complete model, and will be refined):

0..1 EquipmentHolder 0..n

ComponentInHolder HolderLocatedAt

0..1

EquipmentInHolder
0..n 0..n 0..1
EquipmentComponent ComponentInEquipment Equipment EquipmentLocatedAt Location
0..n 0..1 0..n 0..1
0..n 0..1
ComponentLocatedAt

Figure 5PR- 3. Starting Point for Modeling PhysicalResources

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 7

Two things are important to note concerning Figure 5PR- 3. First, Location is the subject of another addendum to GB922
(Addendum 1L, to be precise). This version of this document is currently proceeding ahead of the Location addendum; hence,
Location will be referred to and represented as a placeholder. As soon as the Location addendum of GB922 is stabilized,
appropriate classes from it will be used to populate this model. Second, we have deliberately not defined any attributes yet. It is
easier to concentrate on the entities involved and then fill in the appropriate attributes in the appropriate objects.

In looking at Figure 5PR- 3, we see that we have represented 5 of the 6 main concepts defined above (we are currently missing
auxiliary Equipment, which will be fixed shortly). Let’s examine the details of Figure 5PR- 3.

The idea of Equipment containers that can contain Equipment is modeled using three concepts. Fundamental to this is the need to
have separate classes to model Equipment and containers of Equipment. We accomplish this by defining two separate classes,
called Equipment and EquipmentHolder. While this models the different type of object categories that we need, what we haven’t yet
done is model how Equipment is contained in an EquipmentHolder. This is done using the EquipmentInHolder aggregation.

It is important to know and keep separate the different states that Equipment can exist in. For example, consider the LineCard
mentioned above. The function of the LineCard is (for example) to provide routing and forwarding of packets. This means that a
LineCard can not exist in the ether – it must interact with other elements (e.g., the other components of a Router, of which the
LineCard is but one component) and therefore must be contained by a type of EquipmentHolder. However, LineCards can exist
outside of being installed in an EquipmentHolder – as spares or as part of a kit that is yet to be built in inventory storage, for
example. This model is concerned solely with modeling the physical composition of Network Devices. Thus, it will view Equipment
and EquipmentHolders in this light, and concentrate on developing a model of physical equipment that satisfies the use cases
mentioned earlier. While identifying a spare LineCard is of course very important, that identification is not done as a formal part of
this model. However, it can be easily constructed as an extension of this model (or as part of a new model) using this model and the
Location model (and possibly others as needed). Note that the Location model (Addendum 1L) can be used to provide a physical
description of where an object is.

Back to the EquipmentInHolder relationship, the multiplicity of this relationship is 0 or 1 on the aggregate side, and 0 or more on the
component side. The “0” on the aggregate side means that this aggregation is an optional relationship and does not need to be
instantiated. This makes sense, because it is certainly possible to have a rack (a type of EquipmentHolder, as we will see) and a
Router (a type of Equipment) that are both sitting in an inventory shelf prior to installation. In this case, the router is not yet installed
into the Rack, and therefore this aggregation does not yet exist. However, if the EquipmentHolder is being used (the “1” part of its
cardinality) then it may contain 0 or more Equipment. The cardinality of 0 or more is important, because it reflects the process of first
installing the EquipmentHolder and then populating it with one or more Equipment.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 8

(Note that we could have implemented this as 0..n on both sides of the relationship. The motivation for this, of course, is to be able to
use the model to represent time variances (past, present and future states). Remember, however, that this represents a “current
state” model. Time variance can be accommodated by providing multiple instances of this state model, one each to represent
different time periods. The other problem with 0..n on the EquipmentHolder side of the relationship is that this means that any
Equipment can be put in any EquipmentHolder, which is clearly wrong. We can constrain the relationship using
EquipmentSpecifications, which will be described later in this document.)

Thus, we see the peaceful coexistence between this model and the Location model. When Equipment, such as our LineCard above,
are not installed in an EquipmentHolder, then the EquipmentInHolder relationship is not instantiated, and the Location model takes
over, driving the description of where the LineCard is currently located. When the LineCard is installed in an EquipmentHolder, then
the position of the LineCard relative to its containing EquipmentHolder is determined by this model. The Location model is still useful,
and for example provides the physical location of the Equipment that the LineCard is a part of. However, it does not provide the
physical location of the LineCard within its containing EquipmentHolder.

We notice that the cardinality of EquipmentHolder, Equipment, and EquipmentComponent on the HolderLocatedAt,
EquipmentLocatedAt, and ComponentLocatedAt associations, respectively, is 0..n. This reflects the fact that each of these objects
can exist at multiple locations. The cardinality at the Location end for each of these three associations is 0..1, meaning that if this
(optional) association is instantiated, it specifies a particular Location that an EquipmentHolder, Equipment, or
EquipmentComponent is located at. Again, it is important to remember that if the respective cardinalities of these associations was
“1” instead of “0..1”, then that would mean that this entity must be instantiated. That is why these cardinalities all have a “0”
component (to indicate their optional behavior).

The above is a lot of detail. It was felt that one example was needed to orient the reader. Note that for brevity, this version of this
Addendum will not provide the amount of detail on each relationship and object as was just provided above. However, similar
thinking processes were used to construct these other relationships and objects.

Examples of EquipmentHolders include Racks and Chassis. Each of these can have other components attached to them (e.g., fans,
cable ducts, cards, and so forth). We’ll represent this set of entities by the generic name “EquipmentComponent” for now – the real
class hierarchy is more complicated and will be developed later in this Addendum. Given this type of Equipment, we see that it can
be attached to EquipmentHolders as well as Equipment. Thus, we need two additional compositions – ComponentInHolder and
ComponentInEquipment – to represent these relationships. Since EquipmentComponent is the entity that is being associated with
another entity, both of these relationships define the cardinality on the EquipmentComponent side to be 0..n. Similar to the above
reasoning, both of these relationships define the cardinality on the EquipmentHolder and Equipment side to be 0..1.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 9

Note that other parts of Figure 5PR- 3 have also been simplified. For example, in reality, EquipmentHolders can of course contain
Equipment as well as other EquipmentHolders – think of the case where a Chassis is contained inside of a Rack. Both a Chassis
and a Rack are EquipmentHolders. Details such as these were deliberately left off of Figure 5PR- 3in order to keep the diagram at
this introductory stage of this Addendum as simple as possible. These details will be added into the final model later in this
document.

The final part of this first preliminary model is to realize that every object has a physical location. Some applications do care about
the exact physical location of every physical object, while others are content to abstract this into a physical location for the overall
Equipment and perhaps physical references to key components of the Equipment (e.g., this physical Port is on this physical Card
located in this Slot). Therefore, we’ve identified three generic associations – HolderLocatedAt, EquipmentLocatedAt, and
ComponentLocatedAt – that represent this capability. We’ll consolidate this as we develop the class hierarchy throughout the
remainder of this section.

Equipment Requirements In More Detail

Equipment is at the core of the overall SID model. As such, there are two distinct requirements that Equipment must meet. First, it
must be easy to differentiate who owns and administers the Equipment. Otherwise, the Equipment will not be properly accounted
for, let alone managed. Second, it is important that customers as well as Service Providers be able to express their needs clearly in
order to determine which Equipment can support their requirements.

In the SID, the Party Model (defined in Addendum 1P) is used to describe people as well as organizations. Ownership is
represented by a Party playing a particular role. Thus, we will use an association to relate an instance of the PartyRole class to an
instance of the Equipment class.

However, this brings us up against a conceptual problem: how do we classify Equipment? Remember that the business person
wants to use concepts such as Router, Switch, Firewall in addition to different types of cards, chips, and auxiliary components, such
as fans, cables, and power supplies. Clearly, we need to start working on a hierarchy that supports the concept of different types of
Equipment.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 10

The objects that we’ve just described lend themselves to classification using three different categories:
“Devices”, such as Routers, Switches and Firewalls, that perform one or more end-user functions
“Device Components”, such as LineCards and chips, that fit into the Device and are managed components; these
objects are directly needed by the Device to perform its primary end-user function(s)
“Auxiliary Components”, such as power supplies, fans and cables; that are required for proper operation of the
Device but have a function that is different than the primary end-user function(s) of the Device.
In the above, a “Device” is a managed entity that exists in a single physical structure, or “box”. Clearly, a managed entity such as a
Router can be a very complicated device, having its functionality supplied by multiple LineCards that it contains. However, it is still
important to be able to refer to either the “Device” as a whole or to individual components of the Device (e.g., a PhysicalPort of a
particular LineCard in the Device).

Device Components and Auxiliary Components don’t form a complete function on their own – rather, their purpose is to support the
function(s) performed by their containing Device. However, the functionality of Device Components is directly related to the primary
purpose of the device, whereas the functionality of the Auxiliary Component isn’t. For example, a LineCard is a type of
DeviceComponent because it supplies routing and forwarding functions, which are related to why one uses a router and not some
other type of device. A power supply is an AuxiliaryComponent because while power is clearly required by a router, power is not one
of the salient characteristics that differentiate a router from other types of Devices.

The SIM tends to define Devices, as described above, as logical components. However, from an inventory point-of-view, a Device
usually corresponds to a single physical “box” that is located somewhere. (Alternatively, a Device could correspond to multiple
physical boxes. This gets interesting, because oftentimes such a Device appears as a single logical entity, even though it consists of
multiple physical entities. An example is a “stackable” switch, which consists of multiple physical switches that can be connected so
that they appear to be a single Device to the network). The challenge is to be able to assign one or more locations to the physical
box(es) that correspond to the Device.

By providing an entity to represent the physical manifestation of the Device, we can not only track changes to its location, but we can
also directly relate the physical manifestation of a router with its logical components (we need the System View of the Physical
Resource model to do this). Curiously, the SIM implies that Device and Auxiliary Components are physical entities; in the SID, these
have physical and logical components just like a “Device” does.

An example will help to make this clearer. Consider a Router. People think of a Router as a Device in its own right. However, a
Router is in actuality a very complex object, having many components and concepts that exist as managed objects.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 11

Some of these objects are shown conceptually in Figure 5PR- 4. The reader will notice that all but Hardware and
AuxiliaryComponent (which represents the ”Device Components” and “Auxiliary Components” categories, respectively, from the
above description) are logical in nature. The focus of this Addendum is, of course, on the physical aspects of a Device. However, we
must be cognizant of the other major entities, so that we have the correct set of classes defined to facilitate relating these logical
concepts to the appropriate objects in the physical model. The logical concept of a “Router” is really the collection of the different
aspects of a Router, some of which are shown below (note that “Device” in the figure below represents physical and logical
components).

Service

0..n
DeviceHostsService
0..1
Hardware DeviceContainsHardware Device DeviceDescribedBy ManagementEntity
0..n 0..1 0..1 0..n
0..1 0..1

DeviceContainsSoftware
DeviceHostsProtocols
Equipment 0..n 0..n
Software Protocol

EquipmentHolder

Note: these three inheritance relationships are for

AuxiliaryComponent illustrative purposes only. The real inheritance will
be shown later in this Addendum.

Figure 5PR- 4. Different Aspects of a Device

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 12

In the above figure, the “Device” is the “center of the universe”. It is the entity that provides functionality. From the point-of-view of
this Addendum, this functionality takes the form of being the physical basis for:
hosting services (conceptually represented by the DeviceHostsService aggregation – this is developed more in this
Addendum and in Addendum 4SO)
containing (not running!) software (represented by the DeviceContainsSoftware aggregation)
hosting protocols (represented by the DeviceHostsProtocols aggregation)
containing hardware, which is the main subject of this Addendum
The first three aggregations represent that services, software, and protocols (which are all logical entities) all require a physical
medium to run on. The fourth aggregation enables us to focus on the the physical composition and characteristics of a device.

Devices also are the physical basis for hosting different types of management information, such as alarms, statistics, and so forth.
This is represented by the DeviceDescribedBy aggregation. ManagementEntity is the superclass for representing entities that
represent management information obtained in a managed environment. Specifically, in the process of managing an entity,
information of various forms are created. ManagementEntity is the base class for defining and representing different types of
management information.

If we remember that a “Device” is really just a type of Resource that can be managed, we can make it more extensible. This is done
by defining two classes – PhysicalResource and LogicalResource – that show the inherent correlation between the physical and
logical aspects of a given Resource. Then, we can represent particular physical and logical aspects of a resource as subclasses of
either PhysicalResource or LogicalResource. This also enables us to define a more accurate and rigorous class structure for the
various types of managed objects that are aggregated by a “Device”. This is illustrated in Figure 5PR- 5 below.

Note that this enables the physical and logical description of managed entities to be decoupled from each other. This enables
different subject matter experts to work on the areas that they are interested in. The description of PhysicalResources is the subject
of this Addendum. The description of LogicalResources is the subject of Addendum 5LR, and an overview of how these Resources
fit together is provided in Addendum 5RO.

Please see Addendum 4SO for an overview of Service entities, and how they interact with Resource entities.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 13

Resource ServiceUtilizes Service

0..n 0..n

PhysicalResource LogicalResource
Software

0..n 0..n
1..n
PResourceSupportsLResource
HasSoftwareFeatures

1
PhysicalDevice Hardware LogicalDevice 0..n 0..n Protocol
SupportsProtocol

0..1 0..n
ConsistsOf

Figure 5PR- 5. Relating the Physical and Logical Aspects of a Device to Each Other

Note that PhysicalDevice is a subclass of PhysicalResource. PhysicalResource will be used to gather the common management
characteristics of “Devices” (which are represented by the PhysicalDevice class) and components of a “Device” (which are
represented by subclasses of the Hardware class). Similarly, the logical features seen in Figure 5PR- 5 are grouped under a
common base class, called LogicalResource. Note that LogicalResource is explained further in Addendum 5LR (for Logical
Resource), which is a separate Addendum. This Addendum also describes managed entities that are associated with a
LogicalResource, such as Software and Protocol. Similarly, Service is in a separate Addendum (Addendum 4SO). Finally,
management information (e.g., alarms, statistics, and so forth) is described in Addendum 5RO (Resource Overview) because such
concepts are more generic than PhysicalResource or LogicalResource. Management information is not shown in Figure 5PR- 5
above in order to keep the model as simple as possible for right now.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 14

This structure enables us to focus on specific relationships between PhysicalResource and other entities and LogicalResource and
other entities. It is imprecise to say that a Device hosts a Service (as we did in Figure 5PR- 4) – there are in reality several
relationships that describe this. A PhysicalResource supports LogicalResources, as indicated by the PResourceSupportsLResource
aggregation in Figure 5PR- 5 above. But the actual running of the Service is a logical concept, and hence is associated with a
LogicalResource. The value of this Addendum is that it describes all physical entities that are used to host or support logical entities.,
and corresponds to viewing a Resource as consisting of physical and logical aspects that each needs to be managed.

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.

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.

Other applicable standards include the original DEN specification, the DMTF’s CIM specification (which included some, but not all, of
the DEN work) and the new DEN-ng specification, from which this specification is based. There are similarities and differences
between the DEN and CIM specifications and this specification. These will be covered in detail in the Business Entity definitions in
the last part of this Addendum. At this point, it is appropriate to bring up two important points. First, the original DEN specification
defined a class called NetworkPackage that has the same function as the PhysicalDevice class shown above. This class was
deleted when the original DEN specification was incorporated into the CIM specification. Thus, CIM has no concept of a
PhysicalDevice. Second, both DEN and CIM have similar concepts to the Equipment and EquipmentHolder classes, though their
class structures were different. These will serve to enhance the resulting class structure of this Addendum.

DEN-ng is a holistic combination of the original DEN specification and M.3100. Its aim is to integrate the heretofore separate
modeling concepts fostered in the ITU world with those of the original DEN specification. It should also be noted that the DEN-ng
physical model will be updated to match this specification as it changes. Currently, the DEN-ng physical model is a system view; this
Addendum, which is a business view, is a subset of the complete DEN-ng physical model.

Now we can relate Figure 5PR- 5back to Figure 5PR- 3. 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.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 15

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”.

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.

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
Figure 5PR- 6 below.

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.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 16

PhysicalResource

PhysicalDevice Hardware

0..1 0..n

ConsistsOf Equipment 0..n

Router Switch
EquipmentInHolder
EquipmentHolder 0..1

These are for illustraExample classes

tive purposes only
only. AuxiliaryComponent
Such classes are modeled using roles, but
roles haven’t been introduced yet.

Figure 5PR- 6. The Makeup of a Device

Figure 5PR- 6 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 Figure 5PR- 6 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.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 17

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).

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.

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.

The above model also lays the groundwork for modeling 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!

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).

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.

Neither the LineCard nor the PowerSupply can simply exist in the ether, disconnected from the Router! Clearly, both need to be
physically contained in the Chassis, which is associated with the Router. Now the question is, are they contained in the same
EquipmentHolder, or are there different EquipmentHolders for different types of Equipment and AuxiliaryComponents?

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 18

The answer depends on the manufacturer as well as the type and complexity of the device. Some use a single Chassis as a “frame”
into which other components plug into, and others use a set of nested EquipmentHolders. Therefore, we must provide the ability for
both options to be modeled.

What’s an example of nested EquipmentHolders? For large Routers and Switches, it is quite common to see a Chassis with a
number of Slots into which different types of Cards are plugged in. The Slot functions as a type of EquipmentHolder. Therefore, we
can define a single relationship, HoldsHardware, to enable an EquipmentHolder to hold any type of Hardware. This is exactly
analogous to our earlier use of the ContainsHardware relationship. This is shown in Figure 5PR- 7 below.

PhysicalResource

PhysicalDevice Hardware HoldsHardware

0..n

0..1 0..n
0..1
ConsistsOf
EquipmentHolder 0..1

EquipmentInHolder
Equipment 0..n

AuxiliaryComponent

Figure 5PR- 7. The Concept of “Holding” Hardware

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 19

(Before we celebrate too early, we must also realize that certain Cards have connectors on them into which “DaughterCards” can
attach. This, however, is too complicated for where we’re at in our model, so we’ll deal with that later in this document.)

Recapping, this is what we know:

A Router is-a type of Device
There are two types of EquipmentHolders, Slots and Chassis
A PowerSupply is-a type of AuxiliaryComponent
A LineCard is-a type of Card, which is-a type of Hardware (for a more concrete illustration, we are substituting
different types of cards that are part of the “real” model that is being developed; a LineCard is a synonym for a
NetworkCard, but Figure 5PR- 8 shows other types of Cards as well)
A NetworkCard fits into a Slot of a Chassis
A PowerSupply fits directly into the Chassis
The physical part of the Router consists of all of the above Equipment and EquipmentHolders

Thus, what we conceptually have is the following model of our simple Router (note that not all subclasses are shown; rather, this is a
simple example to define the concepts that we have developed to date):

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 20

PhysicalResource

PhysicalDevice Hardware
0..n
HoldsHardware
0..1 0..n

ConsistsOf
0..1
Router Switch AuxiliaryComponent Equipment EquipmentHolder

0..n 0..1

EquipmentInHolder

PowerSupply Card
Chassis Slot

MemoryCard NetworkCard SystemCard

Figure 5PR- 8. Our Simple Example Router

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 21

This isn’t as bad as it looks. ☺ The power of inheritance works well for us. Since PowerSupply and NetworkCard both ultimately
inherit from Hardware, they also inherit the attributes and relationships that Hardware participates in. Thus, both a PowerSupply as
well as a LineCard can be contained in an EquipmentHolder (not necessarily the same one) via the HoldsHardware aggregation.
Similarly, both can be used to build a Router via the ConsistsOf aggregation.

As for the two EquipmentHolders, we’ve chosen to make them siblings. That is, they are two separate objects that are derived from
a common superclass (EquipmentHolder). This is an example of the object-oriented concept of specialization. Specialization is used
to take a single concept and add detail to it. The added detail is in the form of subclasses that inherit all of the attributes and
relationships (and, in the System view, methods and constraints as well) of their parent superclasses, but add their own
characteristics and behavior (in the form of attributes and relationships, as well as methods and constraints in the System view).

In this case, there is a fundamental difference between a Slot and a Chassis. However, since both of these classes are subclasses
(i.e., types) of EquipmentHolder, we can simply reuse the HoldsHardware composition to enable a Chassis to contain Slots. Finally,
the HoldsHardware aggregation can also be used to nest EquipmentHolders, as previously discussed.

We’ve also added some additional detail, showing that there are (for now) three different types of Cards – MemoryCards,
NetworkCards, and SystemCards. A MemoryCard is a type of Card that is dedicated to providing additional memory for use by other
components of a Resource. Such Cards can be used to expand memory, or provide different types of memory.

A NetworkCard is a type of Card that is dedicated to providing networking functions, such as routing and forwarding. Line cards and
port adapter cards are examples of this type of card.

Finally, a SystemCard is a type of Card that is dedicated to providing system functions. Main processor boards and controller boards
are examples of this type of Card.

Given this introduction, we will now introduce the concept of Roles. Roles are a fundamental means of providing an extensible
model. An innovative feature of DEN-ng is that it has physical as well as logical roles.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 22

Device Roles

Before we dive deeper, let’s clear up one thing that we previously hinted at. Figure 5PR- 6 defined a Switch and a Router as types of
Devices. We all know the basic difference between a Switch and a Router – the former forwards traffic, while the latter routes and
forwards traffic. But what about the so-called “Layer 3” switches, which are Switches that have Routing capability?

Assume that our model actually did implement a router and a switch subclass of PhysicalDevice. One would then be tempted to
invent a new subclass, called Layer3Switch, which subclasses a Switch and adds routing capabilities, to handle this new type of
device. However, this is a poor solution, because now every time routing changes, we have to update the Router and the
Layer3Switch class. Besides, this implies that a Layer3Switch can do everything that a full-blown Router can do, which is almost
never the case. There are other problems too, but this is enough for now.

One may then be tempted to use multiple inheritance to solve this problem. However, this creates a new problem – one of
extensibility. What if there is a “Layer4Switch” (unfortunately, some vendors do define such an animal!)? What if we want to
differentiate between the type of routing done in a Router vs. those done in the Layer3Switch vs. those done in the Layer4Switch?
What if there is a Router that has firewalling capabilities? The list is endless. Multiple inheritance cannot be used to solve all of these
problems, and besides, many implementations don’t support multiple inheritance. We don’t want to compromise our ability to build a
system view out of this business view!

Instead, a much more elegant and extensible solution is available – we can use the notion of roles. In fact, one of the strengths of a
good model is to be able to reuse the same set of patterns over and over. Roles form a core part of the Party model, which (among
other things) describes People, Organizations, and the functions (i.e., roles) that they play. This is documented in Addendum 1P (the
Common Business Entity Addendum that defines Party and PartyRole).

Our approach is now simplified. Instead of trying to either define many subclasses or introduce multiple inheritance, we can instead
define a set of roles that the device is meant to play. (It should be noted that this is another reason why the concept of a managed
device is a good one – now, we can define a base concept of a managed device, and model its functionality by associating one or
more roles to it as appropriate). This solves the mess of having the same generic function (such as routing) assigned to two different
types of devices that implement that same generic function in different ways, producing different subsets of functionality.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 23

Since the networking industry has shown to be ever-evolving, inheritance is not appropriate for capturing this behavior, as the
behavior itself changes over time. In addition, by capturing the key functional concepts as roles, we can model present and future
Devices as entities that can play many roles at one time.

Thus, by modeling DeviceRole as a separate concept from Device, we can represent these complex behaviors in an extensible
manner.

Figure 5PR- 9 shows a simple model introducing the concept of a DeviceRole:

Device DeviceTakesOn DeviceRole

0..n
0..1

Router Switch Firewall Encryption Encoder

Figure 5PR- 9. The Concept of a DeviceRole

It should be noted that Figure 5PR- 9 does not define all of the different types of roles that a Device can take on. This concept is
clearly not a physical one, but rather a logical one, and will show up in other Addenda. It is brought up in this Addendum because
this is a critical concept for modeling different types of devices, and the Physical Resource model must be able to interface with this
concept. It also inspires us to see if there isn’t a similar concept that can be used to abstract similar differences in the physical world.
In fact, there is a similarity, and is defined in the section titled EquipmentHolder in More Detail later in this Addendum.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 24

PhysicalResource Business Entities in More Detail

The purpose of this section is to take the basic model presented in Figure 5PR- 8 and expand it to add more detail.

Filling in the Details

We’re now at the stage where we can add some detail. Given that we are building a Business Model, we will simply strive to identify
certain essential attributes and relationships for PhysicalDevice as well as Hardware. We will not define methods, low-level
attributes, association classes, and in general all of the detail that fully describe these entities. This detail will be provided in an
accompanying System model. This model has already been built and is currently being refined. It will be formalized as part of a
future phase of the SID work.

The following rules were used to define the set of attributes and relationships for this model:
Keep to high-level, business-oriented concepts (e.g., while some applications might need to know specific details
about a physical object, the purpose of this model is to simply identify the key concepts necessary for the purposes
specified in our use cases)
Note that these entities represent business concepts in a Service Provider that conforms to the eTOM process
model [eTOM] (specifically, the Resource Development and Operations processes).
This is intended as a “minimalist” model. Subtypes and attributes should be added as required to suit the needs of a
particular application. The attributes shown should be considered as suggested, not required, unless they are
specified as mandatory.
Parent attributes are not repeated in their subclasses
Only significant entities are shown in the “related business entities” cells
Entities that are outside the scope of this model facet are shown with a white fill color.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 25

PhysicalResource

We already introduced the notion of this entity as a superclass of our two main categories of physical objects: Device and Hardware.
Hardware defined three types of objects – Equipment, EquipmentHolder, and AuxiliaryComponent. We abstracted this set of entities
into a single entity, called PhysicalResource. This is defined as an abstract base class for describing different types of hardware that
constitute a Product. It has two main purposes: (1) to collect common attributes and relationships for all hardware, and (2) to provide
a convenient, single point where relationships with other managed objects can be defined.

Now, it’s time to see if we can discover common attributes that these three types of entities have in common. We’ll tie this into the
concept of a PhysicalResourceSpecification in a minute.

The most obvious types of attributes that physical objects have in common are the set of attributes that define specific characteristics
about a given physical object. These include who manufactured it and when, and what the model number of the object is. To this,
inventory encourages us to add part number, SKU number, and serial number. This gives us the following preliminary picture of a
PhysicalResource:

PhysicalResource-Preliminary
manufactureDate : String
modelNumber : String
partNumber : String
serialNumber : String
skuNumber : String
vendorName : String

Figure 5PR- 10. First Attempt at Defining the Attributes of a PhysicalResource

These six attributes are inherited by all subclasses of PhysicalResource.

The key in making the above model extensible and reusable is to use the concept of a Specification. A Specification is a way of
defining the invariant characteristics and behavior (attributes and relationships in the Business View, along with methods and
constraints in the System View) of a managed entity.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 26

Now, if we look at these attributes, we see that some of them lend themselves to being templatized, while some don’t. That is, we
can use the concept of a PhysicalResourceSpecification to supply the ModelNumber, PartNumber, SKUNumber, and VendorName
attributes, because these correspond to a generic specification describing a particular type of PhysicalResource. The other two
attributes (ManufactureDate and SerialNumber) are specific to a particular instance of a PhysicalResource object, and therefore are
not contained in the PhysicalResourceSpecification. Adding in the class inheritance from the DEN-ng system view, we get the
following revised picture:

InvolvedResourceSpecs

0..n 0..n
Resource SpecifiesResource ResourceSpecification
0..n 1

HasPhysicalResourceSpecs
0..n
LogicalResource PhysicalResource PhysicalResourceSpec LogicalResourceSpec
manufactureDate : String
0..n serialNumber : String 0..n 0..n

0..n LResSpecBindsToPResSpec

PResourceSupportsLResource 0..1
PhysicalResource PhysicalResourceSpecAtomic
SpecComposite modelNumber : String
partNumber : String
skuNumber : String
vendorName : String

Figure 5PR- 11. The Relationship Between PhysicalResource and PhysicalResourceSpecification

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 27

We separate PhysicalResourceSpecs from LogicalResourceSpecs because they are fundamentally different in nature. In addition,
they have different attributes, methods, constraints, and relationships in the System view.

Both PhysicalResourceSpecs and LogicalResourceSpecs use the composite pattern for extensibility. Only the
PhysicalResourceSpec classes are shown in Figure 5PR- 11 above for simplicity.

A PhysicalResourceSpecAtomic class is a concrete class for describing specific attributes, behavior, relationships, constraints, and
semantics for building PhysicalResource objects. The purpose of this class is to be able to track PhysicalResourceSpecifications
separately from other types of ResourceSpecifications. Note that this class inherits the SpecifiesResource aggregation, and
therefore can be used with the corresponding PhysicalResource class.

The difference between this class and the PhysicalResourceSpecComposite class is that this class represents stand-alone
PhysicalResourceSpecifications. The PhysicalResourceSpecComposite class represents a specification that is in reality made up of
a set (usually a hierarchy) of PhysicalResourceSpecifications.

The composite pattern is completed by defining the HasPhysicalResourceSpecs aggregation. This aggregation defines the set of
PhysicalResourceSpecs that are contained by this particular PhysicalResourceSpecComposite entity.

The SpecifiesResource aggregation defines the particular ResourceSpecification that is used to provide the invariant characteristics
(i.e., attributes and relationships, as well as methods and constraints in the System View) of a given Resource. This enables multiple
Resources that each use a common set of attributes, methods, constraints, and/or relationships to be related to a single invariant
specification of those characteristics and behavior. This facilitates their updating.

The cardinality of the SpecifiesResource aggregation is 1 on the ResourceSpecification side and 0..n on the Resource side. This
means that a ResourceSpecification can be written that isn't related to any specific Resources, but if a Resource is built, it must be
derived from a ResourceSpecification. Furthermore, this is an aggregation because this is a whole-part relationship: the
ResourceSpecification defines the invariant attributes and behavior of zero or more Resources, and each Resource derived from the
ResourceSpecification uses all of thee invariant attributes and behavior (and presumably adds its own instance-specific attributes
and behavior).

Since this aggregation is defined at the Resource and ResourceSpecification level, each of the subclasses of Resource and
ResourceSpecification inherit its use. This is why (for example) there isn’t a relationship connecting a PhysicalResourceSpec to a
PhysicalResource.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 28

The LResSpecBindsToPResSpec association represents the binding between a set of LogicalResourceSpecifications and a set of
PhysicalResourceSpecifications. The semantics of this binding are represented by the LogicalPhysicalResourceSpec association
class.

A convenient way to view the Entity-EntitySpecification pattern is that EntitySpecifications represent templates for building an Entity,
while Entities themselves represent instances of managed objects.

The various subclasses of the PhysicalResource class shown in earlier figures still inherit all of the attributes and relationships that
were shown in, for example, Figure 5PR- 8, because the SpecifiesResource association is used to add the attributes and
relationships of a ResourceSpecification to a Resource. In fact, inheritance means that each subclass now inherits the ability to have
its own PhysicalResourceSpecification (or subclass of PhysicalResourceSpecification). This enables any specific needs of one of
the various subclasses of PhysicalResource to be met by subclassing the PhysicalResourceSpecification corresponding to that
object.

We’ll look at the definitions of each of these major entities in the following sections.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 29

PhysicalDevice in More Detail

PhysicalDevice represents the completed physical assembly, including all components, of the network device. There are two
important aspects to a PhysicalDevice – its physical components and the role(s) that these components play in the network.

A PhysicalDevice may itself be a set of devices. This can become quite complex and will be treated in the next version of this
Addendum – the interested reader is referred to the system view of the DEN-ng Physical Resource model. Therefore, we will use
the composite pattern to model PhysicalDevices within PhysicalDevices. As an aid to applications, a special attribute
(deviceGroupID) is used to signify this.

PhysicalResource

PhysicalDevice Hardware
HasDevices configurationOrder : String
0..n deviceGroupID : String
0..n
0..1
ConsistsOf

0..1 PhysicalDeviceComposite PhysicalDeviceAtomic

Figure 5PR- 12. Specifying the PhysicalDevice and Hardware Classes in More Detail

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 30

Hardware in More Detail

The various physical components that make up a PhysicalDevice have so far been grouped into a single class called Hardware. In
looking for common attributes for these three very different types of entities, we find that dimensions and weight are all common
attributes of these three entities. Therefore, we can add these attributes to the Hardware class (not to PhysicalDevice, since we can
derive these attributes for a PhysicalDevice from the Hardware entities that make up a PhysicalDevice). Figure 5PR- 13 shows
these changes to the Hardware class.

PhysicalResource

ContainsHardware

0..1
PhysicalDevice Hardware
depth : String
height : String
0..1 measurementUnits : Integer 0..n
weight : String
weightUnits : Integer
width : String

0..n
ConsistsOf

Figure 5PR- 13. Hardware in More Detail

The ContainsHardware aggregation defines the ability for a given Hardware object to contain other Hardware objects. This enables
the different managed hardware components that make up a device to be explicitly defined.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 31

PhysicalConnector

A PhysicalConnector is a concrete class that represents any type of hardware unit that is used to connect to other hardware units
and transmit signals and/or power between them. The attributes of this entity are described in more detail in the Data Dictionary
Section of this Addendum.

PhysicalConnector is a subclass of Hardware, as is shown in Figure 5PR- 14 below.

HardwareHasConnector Hardware

0..1

PhysicalConnector ManagedHardware
cableType : Integer 0..n
0..n gender : Integer ConnectedTo
pinDescription : String 0..n

Figure 5PR- 14. Physical Connector

The cableType and gender attributes define the type of connector and the type of cable that is attached to this connector (if any).
The pinDescription attribute is a free-form string describing the pin configuration and signal usage of a PhysicalConnector.

The ConnectedTo association indicates that two or more PhysicalConnectors are connected together.

Note that a PhysicalConnector is a sibling to the ManagedHardware class, which is discussed in the next section. Thus, a
PhysicalConnector is a type of Hardware, but is not a type of ManagedHardware.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 32

ManagedHardware

ManagedHardware is a subclass of Hardware, and is an abstract base class that adds additional semantics to the Hardware base
class. These semantics are used to provide management information on the hardware. For example, attributes defined by this class
can provide the administrative and operational state of the entity, and tell whether it has any alarms. Such attributes are physical in
nature, and indicate physical things (e.g., a fiber cut). For most physical administrative and operational states, there is one or more
corresponding logical administrative and operational states. ManagedHardware is shown in Figure 5PR- 15 below.

ContainsHardware

0..1 0..n
HardwareHasConnector Hardware

0..1

0..n PhysicalConnector ManagedHardware

administrativeState : Integer
physicalAlarmReportingEnabled : Boolean = TRUE
0..n
physicalAlarmStatus : Integer = 0

PlugsInto

0..n
PhysicalPort PhysicalContainer

Figure 5PR- 15. ManagedHardware in More Detail

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 33

The main difference between ManagedHardware and Hardware is that ManagedHardware entities have more than just a physical
presence – they also have physical semantics that describe how the entity is managed. This is why PhysicalConnector is not a type
of ManagedHardware – a PhysicalConnector is managed by physically inserting and removing it.

So, what is meant by physically managing a hardware entity? This is best explained by briefly examining the three attributes of the
ManagedHardware class.

The administrativeState attribute is an enumerated integer that describes the current physical state of the ManagedHardware.
Examples of this include starting up, shutting down, and in test.

The physicalAlarmReportingEnabled attribute is a Boolean, and defines whether physical alarm reporting for this object instance is
enabled or not. Note that some physical entities are not capable of reporting physical alarms, while some are. In most cases, there
are corresponding logical alarms. The ManagementEntity class hierarchy (which is described in Addendum 5LR) defines logical
alarms, and correlates them to physical alarms.

The physicalAlarmStatus attribute is an enumerated integer that indicates the occurrence of an abnormal physical condition relating
to an object. This attribute may also function as a summary indicator of alarm conditions associated with a specific resource. This
attribute expands on the standard ITU semantics and updates them to include eTOM concepts.

The ManagedHardware class has two important subclasses, called PhysicalPort and PhysicalContainer. These are described in the
next two sections, respectively.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 34

PhysicalPort

PhysicalPorts are an important type of object to keep track of. This is where communication begins and/or ends on a
PhysicalDevice. PhysicalPorts also play a prominent role in topology and FCAPS applications, and enable Service Providers to
determine what Customers are running what Services where in the network. Unfortunately, the M.3100 Equipment class is oriented
towards PhysicalDevices, and doesn’t have the concept of a PhysicalPort. The DMTF CIM also doesn’t have this concept. However,
the DEN-ng model does.

A PhysicalPort represents an actual or potential end point of a topological (physical) link, and corresponds directly to a physical port
on a topology map. PhysicalPorts are always contained by another physical object - they can't exist by themselves. The two most
common examples are PhysicalPorts on a Card and on a Chassis. These are represented using separate aggregations, and will be
described in the sections that explain Card and Chassis. Figure 5PR- 16 illustrates the concept of a PhysicalPort.

ManagedHardware

PhysicalPort PhysicalContainer
ifType : Integer
portNumber : Integer
typeOfPPort : Integer
vendorPortName : String

Figure 5PR- 16. PhysicalPort in More Detail

PhysicalContainer, as we will see in the next section, is the superclass for Equipment, EquipmentHolders, PhysicalComponents,
and AuxiliaryComponents. Note that a PhysicalPort is not a type of PhysicalContainer. This is because a PhysicalPort contains
logical components. This is described in more detail in Addendum 5LR.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 35

The ifType attribute is an enumerated integer, and specifies the particular media type of the link. This is closely related to the
typeOfPort attribute, which is an enumerated integer that defines the particular type of PhysicalPort this instance is (e.g., Ethernet vs.
ATM). The portNumber attribute is the number of this physical port as defined by the application, and the vendorPortName is a
critical attribute that contains the name of the port according to the vendor. This enables an enterprise-wide naming scheme to be
correlated with vendor-specific names, which are necessary for configuring the port.

For example, an enterprise may need to assign either special strings, or a monotonically increasing number to distinguish all of their
PhysicalPorts. Or, an enterprise may want to reuse PhysicalPort numbers, so that “port 1” on any device has special significance.
Both of these schemes are very common, and must be accommodated in the model.

However, if an enterprise chooses to use their own naming scheme, then this makes it difficult, if not impossible, to program the
device. This is because a (logical) DeviceInterface is contained within a PhysicalPort, as described in Addendum 5LR. Programming
a device also means programming its device interfaces.

To achieve these diametrically opposite goals, the DEN-ng model provides a private (portNumber) and a vendor-specific
(vendorPortName) name for a PhysicalPort. This enables configuration management software to correlate between the two different
names of the same PhysicalPort.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 36

PhysicalContainer

A PhysicalContainer is an abstract class that is used to add additional semantics to the ManagedHardware class. Its attributes
define whether a ManagedHardware object can be removed and/or replaced, and whether this action requires power to be removed
or not when the action is performed. It is shown in Figure 5PR- 17 below.

0..1
Hardware
0..n
ContainsHardware
HoldsHardware
0..n

ManagedHardware

PhysicalContainer
hotSwappable : Boolean
removable : Boolean
replaceable : Boolean

0..1
AuxiliaryComponent PhysicalComponent Equipment EquipmentHolder

Figure 5PR- 17. PhysicalContainer in More Detail

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 37

The removable attribute is a Boolean that defines whether it is possible to insert and remove this object instance from the Equipment
in which it is installed, without impairing the function or packaging of the Equipment. TRUE means that it is HotSwappable, and
FALSE means that it is not.

The replaceable attribute is a Boolean that defines whether it is possible to replace this object instance with a physically different
instance of the same type. For example, some types of device allow various Chips to be upgraded. TRUE means that it is
HotSwappable, and FALSE means that it is not.

The hotSwappable attribute is a Boolean that defines whether it is possible to replace this object instance with a physically different,
but equivalent, object instance while the containing Equipment has power applied to it. TRUE means that it is HotSwappable, and
FALSE means that it is not. All HotSwappable PhysicalComponents are inherently Removable and Replaceable.

Thus, the purpose of the PhysicalContainer object is to add the removable, replaceable, and hotSwappable semantics to
ManagedHardware entities. By doing this, it serves as the subclass for our four remaining types of objects: PhysicalComponents
(such as chips and ASICs), AuxiliaryComponents (such as PowerSupplies), EquipmentHolders (such as Racks, Chassis and Slots)
and Equipment (such as Cards). These will be described in subsequent subsections of this section.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 38

PhysicalRoles in More Detail

We’ve talked about the different roles that a given device can have, and graphically represented this in Figure 5PR- 9. Most of the
attributes (and all of the methods) defined for a PhysicalDevice are not appropriate for the business view – it is enough simply to be
able to refer to a PhysicalDevice, such as a router, as a complete, atomic unit. Please refer to the Physical Resource System View
Addendum for more information on non-business characteristics and behavior of this entity.

Physical roles, however, are appropriate for discussion in this Addendum. There are two types of physical roles that are defined in
the DEN-ng model. These are called PhysicalDeviceRole and HardwareRole.

SpecifiesPhysicalResourceRoles RolesDescribePhysicalResource

0..1 0..n 0..n 0..1

PhysicalResourceSpec PhysicalResourceRole PhysicalResource

PhysicalDeviceRole HardwareRole

Figure 5PR- 18. PhysicalDeviceRole and HardwareRole

There is a profound difference between the SpecifiesPhysicalResourceRoles aggregation and the RolesDescribePhysicalResource
aggregation. The former defines the set of PhysicalResourceRoles that a particular PhysicalResource must have (since it is defined
by the specification for that PhysicalResource). This enables functionality to be specified for a particular physical component. The
latter aggregation defines the set of physical roles that are used to describe an instance of a particular PhysicalResource.

In other words, the difference between the SpecifiesPhysicalResourceRoles aggregation and the RolesDescribePhysicalResource
aggregation is that the former defines functionality of a PhysicalResource using PhysicalResourceRoles. In contrast, the
RolesDescribePhysicalResource describes functionality using PhysicalResourceRoles.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 39

The purpose of the PhysicalDeviceRole class is to define the different types of physical roles that a PhysicalDevice can take on. This
enables us to correlate different logical roles to specific physical devices. For example, there are different logical characteristics that
differentiate a CustomerPremise router from a ProviderEdge router, even though they are both “edge” routers. Depending on the
type of connection, different PhysicalDevices are often needed to support these logical functions. Figure 5PR- 19 shows some
example subclasses of PhysicalDeviceRole. The PhysicalRouterRole and its subclasses are explained in more detail in the MPLS
VPN Addendum.

PhysicalResourceRole

PhysicalDeviceRole HardwareRole

PhysicalEncryptionRole PhysicalRouterRole

PhysicalFirewallRole
CPEPhysicalDeviceRole

PhysicalSwitchRole
PEPhysicalDeviceRole

PPhysicalDeviceRole

Figure 5PR- 19. Examples of PhysicalDeviceRoles

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 40

EquipmentHolder in More Detail

EquipmentHolder represents a specific category of physical objects. This means that it has its own hierarchy of objects. Specifically,
we’ve already differentiated between Slots and Chassis (which are both subclasses of EquipmentHolder). The M.3100 definition of
this class describes it as representing physical objects that are both manageable as well as able to host, hold, or contain other
physical objects. Examples of physical objects that can be represented by instances of this object class are Racks, Chassis, Shelfs,
Cards, and Slots. (Note that M.3100 does not define all of these different types of EquipmentHolder.)

Some devices are built in such a way as to enable other devices to be mounted inside them. This can be modeled using the
composite pattern, which divides an entity into two subclasses. One subclass is used to model stand-alone objects, and the other
subclass is used to model objects that can contain more objects of that type. We can apply this pattern to the EquipmentHolder class
to obtain the following:

EquipmentHolder
HasHolders acceptableEquipmentList : SequenceOf String
typeOfHolder : Integer
0..n
holderStatus : Integer

HolderComposite HolderAtomic
cableManagementStrategy : String physicalDescription : String
0..1 mountingOptions : Integer uniqueLogical : Boolean
serviceApproach : SequenceOf Integer uniquePhysical : Boolean

Figure 5PR- 20. Specifying Different Types of EquipmentHolders

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 41

The acceptableEquipmentList attribute is an array of strings, based on M.3100, which identifies the types of equipment objects that
can be supported by this object. This attribute is defined for backwards compatibility with M.3100.

The typeOfHolder attribute is an enumerated integer that identifies the type of the Holder that this object instance is. It is based on
M.3100 but includes additional values.

The holderStatus attribute is also based on M.3100 (DEN-ng adds values to those defined in M.3100). It indicates the status of the
EquipmentHolder (e.g., is it installed).

The above figure has now formalized what we knew all along – there are really two different types of EquipmentHolders. One type,
designated by the AtomicHolder class, is meant to be used in a stand-alone way. This doesn’t mean that a Slot exists by itself;
rather, the Slot cannot be used to form another type of EquipmentHolder. Contrast this to either a Rack or a Chassis. Both of these
are subclasses of the CompositeHolder class, because both of them can be used to form more complex types of EquipmentHolders.
For example, a Chassis can contain either another Chassis or a Slot, and a Rack can contain either a set of Chassis or a “sub-
Rack”.

HolderAtomic

The HolderAtomic class represents atomic holders of Equipment that are individually manageable and do NOT form composite, or
nested, Equipment Holders. Each HolderAtomic object can be a Field Replaceable Unit.

The physicalDescription attribute is a free-form string that defines the physically unique characteristics of this holder. The
uniquePhysical and uniqueLogical attributes are Boolean attributes that signify that this holder is physically or logically different from
other holders.

A model of the HolderAtomic class is shown in Figure 5PR- 21 below.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 42

HasHolders EquipmentHolder
0..n

0..1 HolderComposite HolderAtomic

physicalDescription : String
uniqueLogical : Boolean
uniquePhysical : Boolean

Slot
hasAdapter : Boolean 0..n
slotNumber : Integer AdjacentSlots
slotPurpose : Integer
0..1
0..1 0..n

SlotInSlot

Figure 5PR- 21. HolderAtomic in More Detail

A Slot is a concrete class that has two main purposes. One is to model the ability of a hosting board to accept a daughter card to
add or complete the base functionality of the hosting board. The second is to represent the different expansion slots supported by a
Chassis.

All Slots have a unique number – this is represented by the slotNumber attribute. The slotPurpose is an enumerated integer that
defines the purpose of this Slot. This enables Slots to be easily identified according to their functional purpose.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 43

This leaves the hasAdapter attribute. This attribute is a Boolean attribute that, if TRUE, indicates that this slot has an adapter
installed that enables it to accept other types of cards (e.g., fitting an adapter on two Slots enable them to accept a Card that
otherwise could not be accommodated).

Adapters are very important, as they enable an organization to keep its investment in expensive line Cards. This is represented in
more detail using the SlotInSlot association. This association represents the ability of a special adapter to extend the existing Slot
structure to enable otherwise incompatible Cards to be plugged into an EquipmentHolder. The adapter effectively creates a new Slot
and can be thought of (conceptually) as a Slot in a Slot.

The AdjacentSlots association describes the layout of Slots in an EquipmentHolder. In order to do this effectively, the System view of
the DEN-ng model implements this association as a class. This association class includes attributes that are used to provide general
layout information describing the Slots in the EquipmentHolder. An important use of this association is to signal when two Slots are
so close to each other that. if one of these Slots is populated by an adapter Card, the other Slot must be left empty.

HolderComposite

The HolderComposite class represents EquipmentHolders that are made up of other EquipmentHolders (i.e., instances of this class
as well as the HolderAtomic base class). This provides the semantics of collecting a set of components, each of which is individually
manageable, and being able to manage the set of objects as a whole. This containment is modeled using the HasHolders
aggregation.

Each HolderComposite element can be a FRU.

A characteristic of this class is that its subclasses are physical objects that have complex cabling and mounting options. This class is
meant to differentiate complex holders, like a Chassis, from simple holders, like a Slot. Thus, the cableManagementStrategy
attribute is a free-form string that contains information on how the various cables contained in the Chassis, Rack, or other type of
HolderComposite object are connected and bundled.

The mountingOptions attribute defines how Equipment in this entity is mounted (e.g., rack-mounted, free-standing, or enclosed in
another Chassis). Similarly serviceApproach defines how the entity is serviced (e.g., from the top or front), whether it has sliding
trays or removable sides, and/or whether the Frame is moveable (e.g., it has rollers).

Figure 5PR- 22 shows the prominent subclasses of a HolderComposite entity.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 44

HasHolders EquipmentHolder
0..n

HolderComposite HolderAtomic
cableManagementStrategy : String
0..1
mountingOptions : Integer
serviceApproach : SequenceOf Integer

SecureHolder Bay Shelf

Rack Chassis 0..1

0..1 0..n 0..n

ChassisInRack Docked

Figure 5PR- 22. HolderComposite in More Detail

The SecureHolder is a type of HolderComposite that serves as the parent for the Rack and Chassis classes. This class generalizes
common properties that apply to Racks and Chassis. This class defines various types of locks and alarms, and adds the semantics
of being able to indicate if a breach of this entity has been made.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 45

A Bay is a type of EquipmentHolder that is usually found in optical devices. It has a logical identifier, usually a component of port
AIDs in TL1 based switches. A Bay is usually built as a pre-wired hardware assembly that contains a set of shelves and
accompanying ancillary equipment.

A Shelf is a type of EquipmentHolder that is usually found in optical devices. It has a logical identifier that is often relative to the Bay
that contains the Shelf (i.e., the unique identifier for a Shelf is often a concatenation of the network element identifier, the Bay
identifier, and the Shelf identifier). Often, a Shelf is used to contain not just pluggable components (e.g., Cards, Power Supplies, etc.)
but also cabling (e.g., both fiber and wire), with optional connections to external fuse, alarm, and other types of panels.

A Rack is a type of SecureHolder that represents an enclosure in which EquipmentHolders, such as Chassis, are placed. Typically a
Rack is nothing more than the enclosure, and all the functioning componentry is packaged in the Chassis. The Rack typically serves
as the "master enclosure" for Chassis, Shelves and Bays. In addition, Racks can have multiple instances of multiple Devices
mounted in them.

A Chassis is a type of SecureHolder that encloses other ManagedPhysicalEntities and provides a definable functionality in its own
right, such as a desktop or a network device (e.g., a router or a switch).

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 46

Adapter and Holder Roles

While this is a workable model, it still isn’t capable of modeling some important cases. For example, think of a Card that has a
physical connector on it that accepts either another (daughter) Card or even a Chip (e.g., Memory, or a routing or encryption ASIC).
The model shown in Figure 5PR- 22 above mandates the use of a Holder. However, in the above example, there is no explicit
EquipmentHolder – we are forced to either make a physical connector a holder, or insert an artificial holder. Both are incorrect.

Recall the HardwareRole from Figure 5PR- 18 above. The purpose of the PhysicalHardwareRole class is to represent the different
types of roles that various types of Hardware components can take on. For this first iteration, two specialized roles have been
defined: HolderRole and AdapterRole. Their purpose is to cover situations where an Equipment also acts like an EquipmentHolder.
Without these classes, such common situations are very difficult to model. We can use the PhysicalConnector class to connect
appropriate Hardware entities together, which transmit signals and/or power between them. Thus, our previous model is modified as
follows:

PhysicalResourceRole

PhysicalDeviceRole HardwareRole

PhysicalAdapterRole PhysicalHolderRole

Figure 5PR- 23. AdapterRoles and HolderRoles

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 47

The HolderRole enables different types of PhysicalResources, such as a Card, to take on the role of holding other Equipment. This
addresses the problem that we described above, where a Card took on the additional role of holding another Card. This enables a
single managed entity, such as a NetworkCard, to have multiple roles - it can function as a Route Processor as well as a Holder of
Equipment.

The Adapter role enables a piece of Hardware to adapt its use. For example, sometimes Cards and Chassis evolve along separate
paths, causing future versions of one to no longer be physically compatible with present and/or future versions of the other. The
solution to this is to use an intermediate piece of Hardware, called an Adapter, to extend the existing physical structure of an
EquipmentHolder to enable otherwise incompatible Equipment to be plugged into an EquipmentHolder. The Adapter conceptually
creates a new type of EquipmentHolder that fits into the existing EquipmentHolder. This enables Cards that would otherwise be
physically and/or electrically incompatible with the existing EquipmentHolder to be supported, by interfacing to the old
EquipmentHolder via the new Adapter.

The additional semantics provided by the Adapter can be captured as a second type of PhysicalResourceRole. This represents the
common practice of vendors providing special adapters that enable old Equipment or EquipmentHolders to be used with new
EquipmentHolders or Equipment, respectively.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 48

Equipment in More Detail

Equipment represents a specific category of physical objects. This means that it has its own hierarchy of objects. For example,
we’ve already identified Cards as a type of Equipment, and differentiated between Equipment and AuxiliaryComponents (which are
both subclasses of Hardware).

The M.3100 specification defines Equipment as a class of managed objects that represents physical components of a managed
element, including replaceable components. An instance of this object class is present in a single geographic location. Equipment
may be nested within another Equipment, thereby creating a containment relationship. Equipment, and other sibling classes, are
shown in Figure 5PR- 24 below.

ManagedHardware

PhysicalPort PhysicalContainer

0..n

Equipment 0..1

PortsOnCard 0..n

EquipmentInEquipment
0..1 Card

0..1
0..n

CardOnCard

Figure 5PR- 24. Equipment in More Detail

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 49

PhysicalPorts can be placed on either a Card or a Chassis. Thus, we end up with:

ManagedHardware

PhysicalContainer PhysicalPort

0..n 0..n

EquipmentHolder EquipmentInHolder Equipment 0..1

0..n
0..1 0..n
0..n
HasHolders
EquipmentInEquipment

HolderComposite HolderAtomic Card

0..1 PortsOnCard
0..1
0..1 0..n

CardOnCard
SecureHolder Slot

Chassis 0..1 PortsOnChassis

Figure 5PR- 25. Relating PhysicalPorts to Cards and Chassis

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 50

Note that the EquipmentInHolder relationship enables a LineCard to be attached to a Slot. We made two distinct relationships to
model the containment of Ports (PortsOnCard and PortsOnChassis) because the common superclass of LineCard and Chassis is
Hardware. If we had run a relationship between Hardware and PhysicalPort, then PhysicalPorts could contain PhysicalPorts, which
is not correct. In addition, this differentiation will help us in the System view, since the semantics of a PhysicalPort on a Chassis are
different than those of a PhysicalPort on a Card.

The details of the attributes defined for the Equipment class are mostly not appropriate at the Business level; please refer to the
Physical Resource System View Addendum, to be released in Phase 3, for more information on the non-business characteristics
and behavior of this entity.

Types of Cards

Figure 5PR- 26 below illustrates the superclasses for defining different types of Cards.

0..1
Card
CardOnCard
0..n

MemoryCard NetworkCard SystemCard UnknownCard

Figure 5PR- 26. Types of Cards

MemoryCards are dedicated to providing additional memory for use by other components of a Resource. NetworkCards are
dedicated to providing networking functions, such as routing and forwarding. SystemCards are dedicated to providing system
functions (e.g., controller cards). Finally, the UnknownCard object is used as a generic placeholder to represent Cards that are
known to exist but are not yet identifiable via Software means.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 51

AuxiliaryComponents

Figure 5PR- 17 showed a third important subclass of PhysicalContainer, called AuxiliaryComponent. As stated previously, an
AuxiliaryComponent is an abstract base class that represents managed entities, such as power supplies, fans and cables, wihch are
required for the proper operation of the Device but have a primary function that is different than the primary end-user function(s) of
the Device. Two exemplary subclasses of AuxiliaryComponent are shown in below.

AuxiliaryComponent

PowerSupply CoolingDevice

Fan

Figure 5PR- 27. Exemplary Subclasses of AuxiliaryComponent

The difference between AuxiliaryComponents and other subclasses of Equipment are whether or not the physical object performs a
function intrinsic to the main function of the Device. For example, a PowerSupply is an AuxiliaryComponent, because even though 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 a subclass of Equipment because its purpose is to route and forward packets.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 52

PhysicalComponents

A PhysicalComponent was also shown in Figure 5PR- 17. A PhysicalComponent is a managed entity that can reside either in an
Equipment or an EquipmentHolder object, but cannot be used as a stand-alone object. From a management point-of-view, this
object either cannot or does not need to be split into its constituent parts. Any piece of hardware that is not a PhysicalLink,
PhysicalConnector, Equipment, or EquipmentHolder, is a subclass of this class. Some important subclasses of PhysicalComponent
are shown below in Figure 5PR- 28.

PhysicalComponent

Backplane Chip FlashDisk

ASIC MemoryComponent

Figure 5PR- 28. Example Subclasses of PhysicalComponent

The example subclasses are exemplified by the following description of the Chip class. A Chip is a concrete class that models
different types of Chips that are either directly configurable by the end-user (e.g., a programmable device) and/or represent FRUs
(e.g., a special ASIC that can be upgraded by replacing it with a new version of that same ASIC).

For complete definitions of each of these objects, please see the data dictionary section of this document.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 53

Basic Business Entities That Interact with PhysicalResources

This section will outline some of the business entities that interact with business entities defined in the PhysicalResource model. This
section will of course be added to in every phase of the SID as appropriate.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 54

Party and PartyRole

This has already been referenced briefly above. To recap, Party and PartyRole are needed for a number of important reasons,
including:
Identification of an owner of the Device or Hardware
Identification of the manufacturer of the Device and possibly the manufacturer of some or all of its components
Identification of who is responsible to administer the Device or Hardware
Identification of who installed the device
Identification of what management domain the Device or Hardware is in
Identification of who in a particular management domain can administer the Resource
Identification of who last changed the device
The above are exemplary, and identify some of the links between these classes and the physical resource model. The above is not
meant to imply that these are the only links between these models.

It is important to realize that the owner of a Device or Hardware is not the same as the person or group that is responsible for
administering the Device or Hardware.

The existing PartyRole definition is driven by a section of the eTOM that defines the concept of a value network role [eTOM].
However, this definition is very high-level. Furthermore, while the eTOM talks about the need to administer different types of
managed objects, it doesn’t identify the concepts of owner and administrator. These are needed to support the inventory and other
use cases we introduced at the start of this document. Every effort will be made to take this data and feed it back to the eTOM team.

Referring to the SID Party model (Addendum 1P), there is an 0..n to 0..n association (implemented as an association class) with a
PartyInvolvement attribute that define what responsibility the PartyRole (e.g., customer, provider, employee, management domain)
plays. Example responsibilities are owner, lessee, lessor, and administrator. Note that this involvement does not have to be
established via an Interaction; there can be a direct relationship that defines this involvement. It is important that the SID not dictate
this, so that applications are free to implement the precise semantics of this relationship according to their own needs. This is shown
in Figure 5PR- 29.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 55

InvolvedPartyRoles

0..n
0..n Party 0..n PartyRole

1 0..n
HasPartyRoles
HasPeopleOrOrgs

ValueNetworkRole Employee

Organization Individual
1

Customer Intermediary ServiceProvider Vendor

ThirdPartyService Complementary
Provider Provider

Figure 5PR- 29. Overview of Party and PartyRole

Given this background, we can define additional relationships needed to represent administration and ownership of
PhysicalResources.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 56

Briefly, the owner of the Resource is the person or group that is responsible (e.g., organizational, financial, and so forth) for the
Resource. This is a different concept than the person or group that administers the Resource. From a business perspective, the
owner has to either appoint or give permission to the administrator to administer the Resource that is owned. This is shown in Figure
5PR- 30 below.

InvolvedPartyRoles

0..n 0..n
OwnsResource 1 PartyRole Party

0..n 1

HasPartyRoles
AdministersResource

0..n 0..n 0..n

Resource ValueNetworkRole Employee

Technician Administrator

ResourceInstaller TelecomTechnician

Figure 5PR- 30. Representing Administering and Owning a Resource

The modeling of an Owner and an Administrator is not as straightforward as it would first appear. First, while one could construct
new PartyRole subclasses for representing an Owner and an Adminstrator, this will be very limiting. This is because any PartyRole
can own a Resource, but only ValueNetworkRoles can administer a Resource. Thus, if separate subclasses were constructed, they
would have to have relationships to PartyRole and ValueNetworkRole, respectively.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 57

A simpler alternative is to define two associations, called OwnsResource and AdministersResource, to serve these roles. Note that
the OwnsResource aggregation defines the set of Resources (physical and/or logical) that a particular Party, playing the role of
ValueNetworkRole, can administer (through the AdministersResource association). The owner of the Resource is the person or
group that is responsible (e.g., organizational, financial, and so forth) for the Resource.

In contrast, the AdministersResource association defines the set of Resources (physical and/or logical) that a particular Party,
playing the role of ValueNetworkRole, administers. From a business perspective, the owner has to either appoint or give permission
to the administrator to administer the Resource that is owned. This is shown in the system view, by first implementing each of these
two associations as classes, and then associating the classes with each other. However, this is beyond the scope of this Addendum.

The third item, ManagementDomain, is fundamental to how network management is done. Addendum 1-POL defines a
ManagementDomain as follows: A ManagementDomain class represents a special grouping of ManagedEntities that has two
important properties. First, it is used to partition managed objects into a meaningful logical grouping. One important use of such a
grouping is to provide a means to define which EMS (as well as which NMS) manages, monitors, etc. which set of devices. It also
provides a means to show how management functions are distributed and scaled. Second, it defines a common administrative
domain that is used to administer the managed objects that it contains. This implies that all of the managed objects contained in this
ManagementDomain are administered similarly - either by the same user, group of users or policy.

ManagementDomains often have a direct correlation with DeviceRoles. For example, in an MPLS VPN, there is a fundamental
difference between routers that are operating as customer premise, provider edge, and provider core routers. (For those not familiar
with MPLS VPNs, a customer premise device provides customer access to the Service Provider network over a data link to one or
more provider edge routers; provider edge routers function as the ingress and egress routers of the Service Provider network;
provider core routers provide connectivity between the provider edge routers. An example of a high-level MPLS VPN model is
provided in part of Addendum 4). This can be done by associating a type of PartyRole (representing a ManagementDomain) with a
type of DeviceRole. Note that in this use case, there are specific hardware as well as software requirements of the different types of
routers playing the CustomerPremise, ProviderEdge, and ProviderCore roles. This is where the concepts of PhysicalDeviceRole and
LogicalDeviceRole will pay dividends in the overall model.

Thus, ManagementDomains are intelligent containers of managed entities, where different container represent different domains of
control that reflect one or more appropriate management structures, such as organizational structure. PhysicalResources within a
particular domain are administered by a particular person or group of people. While it is easy enough to define a relationship
between ManagementDomain and PartyRole, the management of PhysicalResources in ManagementDomains by Party and
PartyRole entities should be represented and controlled using policies. Thus, this topic will be deferred to the Policy Addendum.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 58

Location

Location is used in two different ways and has two very different semantics:
The place of a Device (or perhaps an Equipment or EquipmentHolder)
The position of a physical component
These are in reality two different concepts, though people tend to combine their meanings into one. At the time of this writing, the
SID Location model is still under discussion. However, we can draw on the simpler DEN-ng model to represent this as follows:

PhysicalLocationDetails
HasLocationElements

0..1 0..n
Location 0..n 0..n PhysicalResource
PhysicalResourceLocatedAt

Position Address GeographicArea Structure

Figure 5PR- 31. Representing the Physical Location of Physical Objects

Note that the HasLocationElements aggregation defines the set of Location subclasses that are contained in this particular Location
subclass. For example, this enables a GeographicArea to contain a Structure and an Address.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 59

The PhysicalResourceLocatedAt association defines the location(s) that a particular PhysicalResource can be found at. Note that
there can be multiple locations assigned for a particular PhysicalResource. For example, a router can be installed in a POSITION in
a Rack, which is in a particular PLACE (e.g., a Room in a Floor), which is in a particular STRUCTURE (e.g., a building) at a
particular ADDRESS (e.g., the postal address that the main building is located at). The PhysicalLocationDetails association class is
used to help disambiguate these overlapping locations.

Figure 5PR- 31 shows that “Location” is broken into four levels of granularity, represented by the four subclasses of Location.
Position is used to indicate a single fixed place of an object. This position may be measured as relative to another reference
object or coordinates or as an absolute position. For example, the slot number that a card occupies is defined by a Position.
An address is a structured way of textually describing how to find a Location. It is usually composed of an ordered list of
Location names based on context specific rules.
The GeographicArea class is used to represent geographic areas or regions. For example, the coverage range of a cell
phone could be modeled using this class.
Finally the Structure class is used to represent buildings, floors, rooms, and other structural entities. This is important for
physical inventory, because inventory items are often stored in a Location in a Structure.
Conceptually, what we want to have is a single relationship between a Location and a PhysicalResource. Right now, in our model
development, we don’t have a single physical entity point – we instead have multiple classes (PhysicalDevice and Hardware as a
minimum) that each need their own relationship to the Location entity.

In reality, this fits very nicely with the DEN-ng Location model and the DEN-ng PhysicalResource model. First, PhysicalDevice and
Hardware help reinforce the separation between place and position – PhysicalDevice is usually associated with either an Address, a
GeographicArea, or a Structure, and Hardware is usually associated with a Position.

This document will be updated to use the appropriate Location classes once the Location model is complete. The concept of location
is quite complex, so this is deferred to SID phase IV.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 60

Capacity and Redundancy

In theory, any physical entities can have one or both of these. However, in practice, Capacity and Redundancy are restricted in this
model to apply only to entities that have Roles. This enables us to maximize the ability to carry out performance corrections. When
Devices are identified that are negatively impacting management items of interest, such as network performance and Service
quality, the close association between Roles and Capacity / Redundancy will allow Capacity and Redundancy associated with these
Devices to be easily addressed.

Capacity implies a range of values – from a minimum acceptable level to a maximum permitted level – that a physical object can
hold, store or accommodate. For example, a Device may require a minimum of 128MB of RAM to operate correctly, prefer 256MB,
and accommodate up to 512MB.

Often, manufacturers make Devices using the same overall Chassis or frame and vary the number and type of cards that can be
installed. Different cards have different power, cooling, memory and other requirements. Therefore, it is often economically easier to
build one master frame and enable multiple variations of certain components, such as memory, to have a minimum and maximum
capacity.

Redundancy connotes additional entities of identical capabilities that can be used in case the primary entity fails or is no longer able
to provide its full capabilities. For example, Devices often have multiple power supplies to ensure that if one fails, the Device can use
a backup power supply and continue to operate. Again, most manufacturers plan for physically housing one or more redundant
components for essential physical hardware as part of the overall physical device.

It is recommended that the concepts of capacity and redundancy be further developed in SID phase IV. They will both require
extensions to the SID that are not currently in this release, as well as require a deeper understanding of both the business and
system views of physical objects.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 61

Product

The SID Product business entities are defined in Addendum 3. The most important of these (from the point-of-view of the Physical
Resource model) are the Product, ProductOffering, and ProductSpecification entities.

A ProductSpecification defines the requirements of physical and logical objects that collectively are accessed via a Product.
Products are derived from ProductSpecifications, and Products can be wholly or partly physical objects. Products may define the
use of various Physical Resources, as shown in the following excerpt from Addendum 3:

ProdSpecMadeAvailableAs ProductOffering ProdOfferDescribes

0..n 1

1 0..n
ProductSpecification Product

0..n 0..n 0..n 0..n

ProductReferences
ProdSpecReferences

Figure 5PR- 32. Simplified Product Model

The Product model has two obvious attachments to Resources in general and PhysicalResources in particular. These are at the
ProductSpecification and Product classes.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 62

A ProductSpecification is a template for defining various ProductOfferings. Therefore, it is natural for a ProductSpecification to
specify ServiceSpecifications as well as ResourceSpecifications. This is shown in Figure 5PR- 34 below.

InvolvedServiceSpecs
InvolvedResourceSpecs

0..n 0..n 0..n 0..n

ServiceSpecification RFServiceSpecHasResourceSpecs ResourceSpecification
1..n

1
CustomerFacingServiceSpec ResourceFacingServiceSpec LogicalResourceSpec PhysicalResourceSpec

0..n 0..n 1..n 0..n 0..n 0..n

RequiresResourceFacingServiceSpec LResSpecBindsToPResSpec

ProductSpecDefinesCFSSpecs 0..n ProductSpecification 0..n

ProductSpecDefinesPRSpecs

0..n 0..n

ProdSpecReferences

Figure 5PR- 33. Relationship Between ProductSpec, ResourceSpec and ServiceSpec

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 63

The key idea that we can take from the Product Addendum (Addendum 3) of the SID is the concept of a Specification that is used to
define an object. This can be used to determine the essential physical characteristics of the PhysicalResource that can later be
customized for a particular ProductOffering. The PhysicalResourceSpecification helps integrate the otherwise diverse worlds of
Product and Physical Resources.

The ProductSpecDefinesCFSSpecs and ProductSpecDefinesPRSpecs enable a ProductSpecification to templatize the definition of

CustomerFacingServiceSpecs and PhysicalResourceSpecs, respectively.

The LResSpecBindsToPResSpec association represents the binding between a set of LogicalResourceSpecifications and a set of
PhysicalResourceSpecifications. The semantics of this binding are represented by the LogicalPhysicalResourceSpec association
class (not shown to keep Figure 5PR- 33 as simple as possible).

Thus, we may make the following important observations concerning the relationship between a ProductSpecification and
PhysicalResourceSpecs and Services:
A PhysicalResource is visible to a customer; therefore, a PhysicalResourceSpec can be directly aggregated by a
ProductSpecification
A LogicalResourceSpec is not directly visible to a customer
LogicalResources require PhysicalResources to host them, which is done using the LResSpecBindsToPResSpec
association
A CustomerFacingServiceSpec is visible to a customer; therefore, a CustomerFacingServiceSpec can be directly
aggregated by a ProductSpecification
A ResourceFacingServiceSpec is not directly visible to a customer
ResourceFacingServices are contained in CustomerFacingServices, which is done using the
RequiresResourceFacingServiceSpec aggregation
Thus, the goals of separating PhysicalResources from LogicalResources (and also CustomerFacingServices from
ResourceFacingServices) through Products has been enforced at the Specification level.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 64

Similarly, Products are related to Services and Resources as shown in Figure 5PR- 34 below.

ProductReferences

0..n 0..n
0..1 Product
0..1
0..n

ProductBundleComprisedOf

0..1 ProductBundle ProductComponent

ProductHasCustomerFacingServices

ProductHasPhysicalResources

Service Resource

0..n 0..n
ResourceFacingService CustomerFacingService LogicalResource PhysicalResource

0..1 0..1 1..n 0..n 1..n 0..n 0..n 1..n

CFServiceRequiresRFServices PResourceSupportsLResource
LogicalResourcesImplementRFS

PhysicalResourcesHostRFS

Figure 5PR- 34. Relationship Between Product, Service and Resource

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 65

The logic at the instance level (shown in Figure 5PR- 34 above) mirrors the logic at the specification level (shown in Figure 5PR- 33
above). PhysicalResources and CustomerFacingServices are directly visible to a Product, using the ProductHasPhysicalResources
and ProductHasCustomerFacingServices aggregations, respectively. A set of PhysicalResources supports a set of
LogicalResources as defined by the PResourceSupportsLResource aggregation. This enables Products to indirectly specify
LogicalResources, though the Customer is not aware of this.

Similarly, a set of CustomerFacingServices requires one or more ResourceFacingServices to be implemented, as defined by the
CFServiceRequiresRFServices aggregation. Note that the cardinality of this aggregation is 0..n to 1..n, whereas the cardinality of the
PResourceSupportsLResource aggregation is 0..n to 0..n. This is because a CustomerFacingService must have at least one
ResourceFacingService in order for it to be implemented, whereas a PhysicalResource can exist independent of any
LogicalResources.

Note that a ResourceFacingService can specify the set of LogicalResources and PhysicalResources that it requires using the
LogicalResourcesImplementRFS and PhysicalResourcesHostRFS aggregations, respectively. This enables Services that are visible
to the Customer (i.e., CustomerFacingServices) to be specified in terms of the Resources (physical and logical) that they need.

Policy

Policy is pervasive, even in the physical domain. For example, one can imagine policies for controlling:
physical access to ManagedPhysicalDevices
policies that define installation, power-up and power-down instructions for physical entities
policies that define maintenance and service instructions
Clearly, there are many more types of policies that can be defined. There are several ways to implement policy for physical objects.
The Behavior and Control Team, a sub-team of the RedTeam, has elected to use the DEN-ng policy model. Phase 3 of the SID
work will include flushing out and approving this model, and tying it to existing SID models such as this one.

The interaction between entities in the Policy domain and entities in the PhysicalResource domain are many. Numerous of these
interactions are rich in nature. Some of these relationships will be specified in the Policy Addendum (1-POL), because they require
an understanding of the Policy model. Others will be built out in SID Phase IV.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 66

Network

Modeling a network (and other similar concepts) is out of scope for the first release of the SID. It is one of the key target areas in the
third phase of SID, and has already been modeled in DEN-ng.

Service

The start of the work on the Service model is taking place in SID phase 2. An example of how Service and Physical Resources
interact using an MPLS VPN will be provided as a separate Addendum.

Interaction

The Interaction model will be used to model the various types of interactions between physical resources and other SID entities
(e.g., a PartyRole acting as an administrator that is performing maintenance on a particular Device). This is partially defined in SID
phase 2, but the details are a matter for the System view.

Additional Examples

To Be Determined and Added if Necessary

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 67

References

[053Main] TMF053, “The NGOSS Technology Neutral Architecture”, TMF

[DEN-ng] Directory Enabled Networks New Generation by John Strassner, et. al., to be published
DEN Directory Enabled Networks by John Strassner ISBN 1-57870-140-6
[Add 3] SID Product Model, GB922, Addendum 3
[Add 4SO] SID Service Overview Model, GB922, Addendum 4SO
[Add 5LR] SID LogicalResource Model, GB922, Addendum 5LR
[Add 5PR] SID PhysicalResource Model, GB922, Addendum 5PR
[GB922] SID Concepts and Principles, GB922 (main document)
m.3100 Generic Network Information Model, ITU-T recommendation
CIM Common Information Model, DMTF
http://www.dmtf.org/standards/standard_cim.php
[CIMPROB] Mining Information from the DMTF CIM into the TMF SID, ed by John Strassner (This was a deliverable from
the TMF-DMTF liaison)
Zachman Zachman Framework
http://www.zifa.com/frmwork2.htm
Larman Applying UML and Patterns, Second Edition, ISBN 0-13-095004-1
http://www.craiglarman.com/book_applying_2nd/Applying_2nd.htm
Baumer The Role Object (Design) Pattern. Download PDF from
http://www.riehle.org/computer-science-research/1997/plop-1997-role-object.pdf

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 68

Business Entity Definitions

The following sections will define the business entities referred to in the preceding portion of this Addendum. This section will consist
of a business entity definition, definition of any attributes appropriate for the business level, and finally provide a business model in
UML of that entity and its main relationships.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 69

PhysicalResource Business Entity Definition

Business PhysicalResource
Entity Name
Description This is an abstract base class for describing different types of hardware that constitute a Product. It has two main
purposes: (1) to collect common attributes and relationships for all hardware, and (2) to provide a convenient, single
point where relationships with other managed objects can be defined.
Sources DEN-ng, OSS/J Cross- Synonyms / This is a DEN-ng class. It
References Aliases is called PhysicalElement
in the DMTF CIM (this is
not a direct match with
this class, although the
concepts are similar); no
direct analog in M.3100
Related Resource (superclass), LogicalResource (sibling), PhysicalDevice (subclass), Hardware (subclass),
Business PhysicalResourceSpec (template)
Entities
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 70

PhysicalResource Business Entity Attributes Definition

Business Entity PhysicalResource

Name
Attribute Name Description Data Characteristics, Permitted Required/ Notes (used to map to
Type Values & Units Optional other models; blank is
other models don’t have it)
manufactureDate This defines the date of String Must be a legal date Optional This is a DEN-ng attribute. It
manufacture of this item in the is called ManufactureDate in
fixed format "dd/mm/yyyy". the PhysicalElement class of
the DMTF CIM. No analog in
M.3100.
powerState This is an enumerated integer Integer 0: Unknown Optional This is a DEN-ng attribute.
that defines the current power 1: Not Applicable CIM defines a PoweredOn
status of the hardware item. 2: No Power Applied attribute, but it is a Boolean.
Values include: 3: Full Power Applied No analog in M.3100
4: Power Save - Normal
5: Power Save - Degraded
6: Power Save - Standby
7: Power Save - Critical
8: Power Save - Low Power
Mode
9: Power Save - Unknown
10: Power Cycle
11: Power Warning
12: Power Off
serialNumber This defines a manufacturer- String Required This is a DEN-ng attribute. It
allocated part number assigned is called SerialNumber in the
by the organization that PhysicalElement class of the
manufactures the hardware item. DMTF CIM, but it is not
This, in combination with the required. No analog in
ModelNumber, identify different M.3100.
types of hardware items. The
SerialNumber can then be used
to differentiate between different
instances of the same type of
hardware item.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 71

Business Entity Model – PhysicalResource

InvolvedResourceSpecs

0..n 0..n
Resource SpecifiesResource ResourceSpecification
0..n 1

HasPhysicalResourceSpecs
0..n
LogicalResource PhysicalResource PhysicalResourceSpec LogicalResourceSpec
manufactureDate : String
0..n powerState : Integer 0..n 0..n
serialNumber : String
LResSpecBindsToPResSpec
0..n
0..1
PResourceSupportsLResource PhysicalResource PhysicalResourceSpecAtomic
SpecComposite modelNumber : String
partNumber : String
skuNumber : String
PhysicalDevice Hardware 0..1 vendorName : String

0..1 0..n 0..n ContainsHardware

ConsistsOf

Figure 5PR- 35. PhysicalResource Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 72

PhysicalResourceSpecification Business Entity Definition

Business PhysicalResourceSpecification
Entity Name
Description This is a concrete class for describing specific attributes, behavior, relationships, constraints, and semantics for building
PhysicalResource objects.
Sources DEN-ng, OSS/J, MetaSolv Cross- Synonyms / This is a DEN-ng class.
model References Aliases No direct analogs in the
DMTF CIM or M.3100,
though analogs of some
of the attributes can be
found in the DMTF
PhysicalElement class.
Related PhysicalResource (subject), ResourceSpecification (superclass), PhysicalResourceSpecAtomic (subclass),
Business PhysicalResourceSpecComposite (subclass), LogicalResourceSpec, LogicalResourceSpecAtomic,
Entities LogicalResourceSpecComposite
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 73

PhysicalResourceSpecification Business Entity Attributes Definition

Business Entity PhysicalResourceSpecification

Name
Attribute Name Description Data Characteristics, Required/ Notes (used to map to other
Type Permitted Optional models; blank is other
Values & Units models don’t have it)
modelNumber This represents a manufacturer-allocated String Optional This is a DEN-ng attribute; no
number used to identify the general type direct equivalent in the DMTF
and/or category of the hardware item. This, CIM; could be represented by
in combination with the PartNumber, identify either the Tag or the
different types of hardware items. The OtherIdentifyingInfo attributes
SerialNumber can then be used to of PhysicalElement. No
differentiate between different instances of analog in M.3100.
the same type of hardware item.
partNumber This defines a manufacturer-allocated part String Required This is a DEN-ng attribute; it
number assigned by the organization that is called PartNumber in the
manufactures the hardware item. This, in PhysicalElement class of the
combination with the ModelNumber, identify DMTF CIM, but it isn’t
different types of hardware items. The required. No analog in
SerialNumber can then be used to M.3100.
differentiate between different instances of
the same type of hardware item.
skuNumber This is a string that defines the String Optional This is a DEN-ng attribute; it
manufacturer-allocated Stock Keeping Unit is called SKU in the
(SKU) number of the hardware item. PhysicalElement class of the
DMTF CIM. No analog in
M.3100.
vendorName This is a string that defines the name of the String Required This is a DEN-ng attribute;
manufacturer. called Manufacturer in the
PhysicalElement class of the
DMTF CIM, but it isn’t
required. No analog in
M.3100.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 74

Business Entity Model – PhysicalResourceSpecification

InvolvedResourceSpecs

0..n 0..n
Resource SpecifiesResource ResourceSpecification
0..n 1

HasPhysicalResourceSpecs
0..n
LogicalResource PhysicalResource PhysicalResourceSpec LogicalResourceSpec

0..n 0..n 0..n 0..n

PResourceSupportsLResource LResSpecBindsToPResSpec

0..1
PhysicalResource PhysicalResourceSpecAtomic
PhysicalDevice Hardware 0..1 SpecComposite modelNumber : String
partNumber : String
skuNumber : String
0..1 0..n 0..n ContainsHardware vendorName : String

ConsistsOf

Figure 5PR- 36. PhysicalResourceSpecification Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 75

PhysicalResourceRole Business Entity Definition

Business PhysicalResourceRole
Entity Name
Description This is an abstract base class for representing the different types of roles that various physical resources can take on.
For this first iteration, two specialized roles have been defined: holder and adapter. This enables a single object, such
as a Card, to have additional functions. For example, a Card may also serve as a motherboard or hosting board for
another Card. In this situation, there isn’t a separate EquipmentHolder – rather, the Card acts as a holder in addition to
providing its normal functions. This class is the base class for defining different types of physical resource roles.
Sources DEN-ng Cross- Synonyms / This is a DEN-ng class.
References Aliases No direct analogs in the
DMTF CIM or M.3100.
Related PhysicalResource, LogicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer,
Business EquipmentHolder, Equipment, AuxiliaryComponent, PhysicalComponent
Entities
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 76

PhysicalResourceRole Business Entity Attributes Definition

Business Entity PhysicalResourceRole

Name
Attribute Name Description Data Characteristics, Required/ Notes (used to map to other
Type Permitted Optional models; blank is other
Values & Units models don’t have it)
Tbd Tbd No pertinent business
attributes exist in this class.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 77

Business Entity Model – PhysicalResourceRole

SpecifiesResourceRoles ResourceTakesOnRoles

1 0..n 0..n 0..1

RoleSpecification ResourceRole Resource

ResourceRoleSpecification PhysicalResourceRole PhysicalResource

0..n 0..n 0..1

PhysicalResourceRoleSpec RolesDescribePhysicalResource

SpecifiesPhysicalResourceRoles

Figure 5PR- 37. PhysicalResourceRole Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 78

PhysicalHolderRole Business Entity Definition

Business PhysicalHolderRole
Entity Name
Description This is a concrete class that represents any type of physical resource that can play a holding role. A common example
is a Card that can also serve as a motherboard, or a Card that can serve as a daughter card that attaches to a
motherboard.
Sources DEN-ng Cross- Synonyms / This is a DEN-ng class.
References Aliases No direct analogs in the
DMTF CIM or M.3100.
Related PhysicalDevice, PhysicalResource, Equipment, EquipmentHolder, AuxiliaryComponent, HardwareRole (superclass),
Business PhysicalAdapterRole, PhysicalDeviceRole, PhysicalResourceRole
Entities
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 79

PhysicalHolderRole Business Entity Attributes Definition

Business Entity PhysicalHolderRole

Name
Attribute Name Description Data Characteristics, Permitted Required/ Notes (used to map to other
Type Values & Units Optional models; blank is other
models don’t have it)
typeOfHolderRole This is an enumerated integer Integer 0: undefined Required This is a DEN-ng attribute; no
that defines the various types of 1: host (e.g., a analog in the DMTF CIM or
holding roles that this object can motherboard) M.3100.
play. 2: client (e.g., a
daughterboard)

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 80

Business Entity Model – PhysicalHolderRole

PhysicalResource RolesDescribePhysicalResource PhysicalResourceRole

0..1 0..n

PhysicalDeviceRole HardwareRole

PhysicalHolderRole PhysicalAdapterRole

Figure 5PR- 38. PhysicalHolderRole Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 81

PhysicalAdapterRole Business Entity Definition

Business PhysicalAdapterRole
Entity Name
Description This is a concrete class that represents any type of physical resource that can play a physical adapter role. The Adapter
role enables a piece of Hardware to adapt its use. For example, sometimes Cards and Chassis evolve along separate
paths, causing future versions of one to no longer be physically compatible with present and/or future versions of the
other. The solution to this is to use an intermediate piece of Hardware, called an Adapter, to extend the existing
physical structure of an EquipmentHolder to enable otherwise incompatible Equipment to be plugged into an
EquipmentHolder. The Adapter conceptually creates a new type of EquipmentHolder that fits into the existing
EquipmentHolder. This enables Cards that would otherwise be physically and/or electrically incompatible with the
existing EquipmentHolder to be supported, by interfacing to the old EquipmentHolder via the new Adapter.
Sources DEN-ng Cross- Synonyms / This is a DEN-ng class.
References Aliases No direct analogs in the
DMTF CIM or M.3100.
Related PhysicalDevice, PhysicalResource, Equipment, EquipmentHolder, AuxiliaryComponent, HardwareRole (superclass),
Business PhysicaHolderRole, PhysicalDeviceRole, PhysicalResourceRole
Entities
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 82

PhysicalAdapterRole Business Entity Attributes Definition

Business Entity PhysicalAdapterRole

Name
Attribute Name Description Data Characteristics, Required/ Notes (used to map to other
Type Permitted Optional models; blank is other
Values & Units models don’t have it)
typeOfAdapterRole This is an enumerated integer Integer 0: undefined Required No analog in the DMTF CIM or
that defines the various types of 1: host adaptation M.3100.
adapting roles that this object 2: client adaptation
can play.

Business Entity Model – PhysicalAdapterRole

The business entity model for the PhysicalAdapterRole is the same as that of the PhysicalHolderRole, and was shown in Figure 5PR- 38
above.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 83

Hardware Business Entity Definition

Business Hardware
Entity Name
Description This is an abstract base class that represents any type of hardware unit that exists as an atomic unit that is not a
PhysicalLink or a PhysicalConnector. Its principal subclasses are Equipment, PhysicalDevice, and PhysicalPort.
Sources DEN-ng Cross- Synonyms / This is a DEN-ng class; no
References Aliases direct analogs in the DMTF
CIM or M.3100; some parts of
the CIM PhysicalPackage can
be mapped to this class, but
that destroys the separation
achieved by splitting
PhysicalResource, Hardware,
ManagedHardware, and
PhysicalContainer
Related Resource, PhysicalResource (superclass), LogicalResource (sibling), PhysicalDevice (which consists of a set of Hardware),
Business ManagedHardware (subclass), PhysicalConnector (subclass), PhysicalResourceRole, PhysicalDeviceRole
Entities
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 84

Business Entity Attributes Definition

Business Entity Hardware

Name
Attribute Name Description Data Characteristics, Required/ Notes (used to map to other
Type Permitted Optional models; blank is other models
Values & Units don’t have it)
depth This defines the depth of the String Optional This is a DEN-ng attribute; called
Hardware using the units Depth in the PhysicalPackage
specified in the class of the DMTF CIM; datatype
MeasurementUnits attribute. is real32. No analog in M.3100.
height This defines the height of the String Optional This is a DEN-ng attribute; called
Hardware using the units Height in the PhysicalPackage
specified in the class of the DMTF CIM; datatype
MeasurementUnits attribute. is real32. No analog in M.3100.
measurementUnits This defines the Integer 0: Unknown (or Optional if none of This is a DEN-ng attribute; not
MeasurementUnits for the not measured) Depth, Height and present in the DMTF CIM.
Depth, Height, and Width 1: inches Width are present;
attributes of this object. 2: feet otherwise required
3: millimeters
4: centimeters
5: meters
weight This defines the weight of String Optional This is a DEN-ng attribute; called
the Hardware using the units Weight in the PhysicalPackage
specified in the WeightUnits class of the DMTF CIM; datatype
attribute. is real32. No analog in M.3100.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 85

Business Entity Hardware (continued)

Name
Attribute Name Description Data Characteristics, Required/ Notes (used to map to other
Type Permitted Optional models; blank is other
Values & Units models don’t have it)
weightUnits This defines the Units for the Weight Integer 0: Unknown (Not Optional if This is a DEN-ng attribute; not
attribute of this object. Values include: Measured) Weight is present in the DMTF CIM.
1: ounces not
2: pounds present;
3: grams otherwise
4: kilograms required
width This defines the width of the Hardware String Optional This is a DEN-ng attribute;
using the units specified in the called Width in the
MeasurementUnits attribute. PhysicalPackage class of the
DMTF CIM; datatype is real32.
No analog in M.3100.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 86

Business Entity Model – Hardware

PhysicalResource RolesDescribePhysicalResource PhysicalResourceRole

0..1 0..n
ContainsHardware

0..1
PhysicalDevice Hardware HardwareRole PhysicalDeviceRole
depth : String
height : String 0..n
0..1 0..1 0..n 0..n
measurementUnits : Integer
weight : String
weightUnits : Integer HardwareHasConnector
width : String
0..1

0..n
ConsistsOf

ManagedHardware PhysicalConnector 0..n

0..1
HasHardwareRoles

HasPhysicalDeviceRoles

Figure 5PR- 39. Hardware Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 87

ManagedHardware Business Entity Definition

Business ManagedHardware
Entity Name
Description This is an abstract base class that adds additional semantics to the Hardware base class. These semantics are used to
provide management information on the hardware. For example, attributes defined by this class can provide the administrative
and operational state of the entity, and tell whether it has any alarms.
Sources DEN-ng Cross- Synonyms / This is a DEN-ng class. No
References Aliases direct analog in the DMTF CIM
or M.3100.
Related Resource, PhysicalResource, PhysicalDevice, Hardware (superclass), PhysicalContainer (subclass), Equipment,
Business EquipmentHolder, PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Entities
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 88

ManagedHardware Business Entity Attributes Definition

Business Entity Name ManagedHardware

Attribute Name Description Data Characteristics, Required/ Notes (used to map to
Type Permitted Optional other models; blank is
Values & Units other models don’t
have it)
administrativeState This attribute is an enumerated Integer 0: Unknown Required This is based on similar
integer that describes the current 1: Unlocked M.3100 concepts, but
physical state of the 2: Locked extends their semantics.
ManagedHardware. 3: Shutting Down No real analog in the
4: Starting Up DMTF CIM.
5: Testing
6: Maintenance
7: Not Applicable
8: Not able to inform
physicalAlarmReporting This is a Boolean attribute, and Boolean Required No concept of this in
Enabled defines whether physical alarm either M.3100 or the
reporting for this object instance is DMTF CIM.
enabled or not. TRUE means that
reporting is allowed, and FALSE
means that reporting is inhibited.

Note that some physical entities are

not capable of reporting physical
alarms, while some are. For those
that are not capable of reporting
physical alarms, this value MUST be
set to FALSE.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 89

Business Entity Name ManagedHardware

(continued)
Attribute Name Description Data Characteristics, Required/ Notes (used to map to
Type Permitted Optional other models; blank is
Values & Units other models don’t have it)
physicalAlarmStatus This is an enumerated integer that Integer 0: unknown This attribute expands on
indicates the occurrence of an 1: the standard ITU semantics
abnormal physical condition relating activeReportable- and updates them to include
to an object. This attribute may also Critical eTOM concepts.
function as a summary indicator of 2:
alarm conditions associated with a activeReportable- No concept of this in the
specific resource. It is used to indicate Major DMTF CIM.
the existence of an alarm condition, a 3:
pending alarm condition such as activeReportable-
threshold situations, or (when used as Minor
a summary indicator) the highest 4:
severity of active alarm conditions. activeReportable-
Indeterminate
5:
activeReportable-
Warning
6:
activePendingDe
cision
7: active-
underRepair
8: active-
beingReplaced
9: cleared

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 90

Business Entity Model – ManagedHardware

ContainsHardware

0..1 0..n
HardwareHasConnector Hardware

0..1

0..n PhysicalConnector ManagedHardware

administrativeState : Integer
0..n physicalAlarmReportingEnabled : Boolean = TRUE
physicalAlarmStatus : Integer = 0

PlugsInto

0..n
PhysicalPort PhysicalContainer

Figure 5PR- 40. ManagedHardware Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 91

PhysicalContainer Business Entity Definition

Business PhysicalContainer
Entity Name
Description This is an abstract class that is used to add additional semantics to the ManagedHardware class. Its attributes define whether
a ManagedHardware object can be removed and/or replaced, and whether this action requires power to be removed or not
when the action is performed.
Sources DEN-ng Cross- Synonyms / This is a DEN-ng class. No
References Aliases direct analog in the DMTF CIM
or M.3100.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware (superclass), Equipment (subclass),
Business EquipmentHolder (subclass), AuxiliaryComponent (subclass), PhysicalComponent (subclass), PhysicalResourceRole,
Entities PhysicalDeviceRole, HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 92

PhysicalContainer Business Entity Attributes Definition

Business Entity Name PhysicalContainer

Attribute Name Description Data Characteristics, Required/ Notes (used to map
Type Permitted Optional to other models;
Values & Units blank is other
models don’t have it)
hotSwappable This is a Boolean attribute that defines Boolean Required This is a DEN
whether it is possible to replace this object attribute, and is also
instance with a physically different, but present in the DMTF
equivalent, object instance while the CIM
containing Equipment has power applied to PhysicalComponent
it. TRUE means that it is HotSwappable. class. Not present in
All HotSwappable PhysicalComponents are M.3100.
inherently Removable and Replaceable.
removable This is a Boolean that defines whether it is Boolean Required This is a DEN
possible to insert and remove this object attribute, and is also
instance from the Equipment in which it is present in the DMTF
installed, without impairing the function or CIM
packaging of the Equipment. TRUE means PhysicalComponent
that it is removable. class. Not present in
M.3100.
A Package can still be Removable if power
must be 'off' in order to perform the removal.
If power can be 'on' and this object instance
can still be removed, then this object
instance is both Removable and
HotSwappable.
replaceable This is a Boolean that defines whether it is Boolean Required This is a DEN
possible to replace this object instance with attribute, and is also
a physically different instance of the same present in the DMTF
type. For example, some types of device CIM
allow various Chips to be upgraded. TRUE PhysicalComponent
means that it is replaceable. class. Not present in
M.3100.
All Removable packages are inherently
Replaceable.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 93

Business Entity Model – PhysicalContainer

0..1
Hardware
0..n
ContainsHardware
HoldsHardware
0..n

ManagedHardware

PhysicalContainer
hotSwappable : Boolean
removable : Boolean
replaceable : Boolean

0..1
AuxiliaryComponent PhysicalComponent Equipment EquipmentHolder

Figure 5PR- 41. PhysicalContainer Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 94

PhysicalDevice Business Entity Definition

Business PhysicalDevice
Entity Name
Description This is an abstract base class for representing hardware devices that can be managed. This class represents a
convenient aggregation point for combining different aspects of a device (e.g., its physical composition as well as the
set of services that it offers). It also enables the device itself to have a physical manifestation. Examples of this class
include routers and switches, computers, and other end-devices that are managed.
Sources DEN-ng Cross- Synonyms / This is a DEN-ng class.
References Aliases No direct analogs in the
DMTF CIM or M.3100;
this is similar to the DEN
NetworkPackage class.
Related Resource, PhysicalResource (superclass), LogicalResource, PhysicalDeviceAtomic (subclass) ,
Business PhysicalDeviceComposite (subclass), Hardware, PhysicalResourceRole, PhysicalDeviceRole
Entities
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 95

PhysicalDevice Business Entity Attributes Definition

Business Entity PhysicalDevice

Name
Attribute Name Description Data Characteristics Required/ Notes (used to map to other
Type , Permitted Optional models; blank is other
Values & Units models don’t have it)
configurationOrder This is a free-form string that provides any String Optional This is a DEN-ng attribute; not
order-specific instructions for configuring present in the DMTF CIM or in
the set of components that together M.3100.
constitute this PhysicalDevice.
deviceGroupID This is a string, and is used to uniquely String Optional This is a DEN-ng attribute; not
identify this device as a member of a group present in the DMTF CIM or in
of devices M.3100.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 96

Business Entity Model – PhysicalDevice

PhysicalResourceRole 0..n RolesDescribePhysicalResource 0..1 PhysicalResource

HasPhysicalDeviceRoles

0..n 0..1
HardwareRole PhysicalDeviceRole HasDevices PhysicalDevice ConsistsOf Hardware
0..n configurationOrder : String 0..1 0..n
deviceGroupID : String
0..1 0..n

ContainsHardware
0..1
PhysicalDeviceComposite PhysicalDeviceAtomic

Figure 5PR- 42. PhysicalDevice Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 97

PhysicalDeviceAtomic Business Entity Definition

Business PhysicalDeviceAtomic
Entity Name
Description This is a concrete base class for representing hardware devices that can be managed that contains no sub-ordinate
devices. In other words, this physical device is a stand-alone physical device.
This class represents a convenient aggregation point for combining different aspects of a device (e.g., its physical
composition as well as the set of services that it offers). It also enables the device itself to have a physical
manifestation. Examples of this class include routers and switches, computers, and other end-devices that are
managed.
Sources DEN-ng Cross- Synonyms / This is a DEN-ng class.
References Aliases No direct analogs in the
DMTF CIM or M.3100.
Related Resource, PhysicalResource, LogicalResource, PhysicalDevice (superclass) , PhysicalDeviceComposite (sibling),
Business Hardware, PhysicalResourceRole, PhysicalDeviceRole
Entities
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 98

PhysicalDeviceAtomic Business Entity Attributes Definition

Business Entity PhysicalDeviceAtomic

Name
Attribute Name Description Data Characteristics Required/ Notes (used to map to other
Type , Permitted Optional models; blank is other
Values & Units models don’t have it)
Tbd

Business Entity Model – PhysicalDeviceAtomic

The business entity model for the PhysicalDeviceAtomic class is the same as that for the PhysicalDevice class, which was shown in
Figure 5PR- 42 above.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 99

PhysicalDeviceComposite Business Entity Definition

Business PhysicalDeviceComposite
Entity Name
Description This is a concrete base class for representing hardware devices that can be managed that contains one or more sub-
ordinate devices. In other words, this physical device is not a stand-alone physical device; rather, it represents an
aggregation of physical devices. Each physical device in this aggregation can be managed.
This class represents a convenient aggregation point for combining different aspects of a device (e.g., its physical
composition as well as the set of services that it offers). It also enables the device itself to have a physical
manifestation. Examples of this class include routers and switches, computers, and other end-devices that are
managed.
Sources DEN-ng Cross- Synonyms / This is a DEN-ng class.
References Aliases No direct analogs in the
DMTF CIM or M.3100.
Related Resource, PhysicalResource, LogicalResource, PhysicalDevice (superclass) , PhysicalDeviceAtomic (sibling),
Business Hardware, PhysicalResourceRole, PhysicalDeviceRole
Entities
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 100

PhysicalDeviceComposite Business Entity Attributes Definition

Business Entity PhysicalDeviceComposite

Name
Attribute Name Description Data Characteristics Required/ Notes (used to map to other
Type , Permitted Optional models; blank is other
Values & Units models don’t have it)
tbd
Tbd

Business Entity Model – PhysicalDeviceComposite

The business entity model for the PhysicalDeviceComposite class is the same as that for the PhysicalDevice class, which was
shown in Figure 5PR- 42 above.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 101

PhysicalConnector Business Entity Definition

Business PhysicalConnector
Entity Name
Description This is a concrete class that represents any type of hardware unit that is used to connect to other hardware units and
transmit signals and/or power between them.
Sources DEN-ng, DEN, CIM, Cross- Synonyms / This is a DEN-ng class.
MetaSolv References Aliases Not present in M.3100.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, Equipment, EquipmentHolder, AuxiliaryComponent,
Business PhysicalComponent, PhysicalPort
Entities
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 102

PhysicalConnector Business Entity Attributes Definition

Business Entity PhysicalConnector

Name
Attribute Name Description Data Characteristics, Permitted Required/ Notes (used to map to other
Type Values & Units Optional models; blank is other
models don’t have it)
cableType This is an enumerated Integer 0: Unknown Required This is a DEN-ng attribute. It is
integer, and defines the 1: RS-232 similar to the ConnectorType
particular type of cable that 2: RS-422 attribute of the DMTF CIM
this connector is. 3: RS-423 PhysicalConnector class. Main
4: RS-449 difference is that the DMTF
5: RS-485 attribute was an array that
6: RS-530 combined this, gender, and
7: V.35 other attributes into one. Also,
8: X.21 this was not a required
9: 9 um single-mode attribute in the DMTF CIM. Not
10: 62.5/125 um multi-mode present in M.3100.
11: USB
gender This is an enumerated integer Integer 0: Unknown Required This is a DEN-ng attribute. It is
that defines the gender type 1: Not Applicable similar to the ConnectorType
of the connector. 2: Male attribute of the DMTF CIM
3: Female PhysicalConnector class. Main
difference is that the DMTF
attribute was an array that
combined this, gender, and
other attributes into one. This
was not a required attribute in
the DMTF CIM. Not present in
M.3100.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 103

Business Entity PhysicalConnector (continued)

Name
Attribute Name Description Data Characteristics Required/ Notes (used to map to other
Type , Permitted Optional models; blank is other
Values & Units models don’t have it)
inUse This is a Boolean attribute that, if TRUE, Boolean Optional This is a DEN-ng attribute; not
indicates that this PhysicalConnector is in present in the DMTF CIM or
use by some other component of the M.3100.
system.
pinDescription This is a string attribute that is used to String Required This is a DEN-ng attribute; it is
provide a free-form string describing the pin similar to the ConnectorPinout
configuration and signal usage of a of the DMTF CIM
PhysicalConnector. PhysicalConnector class. Not
present in M.3100.
type This is an enumerated integer that defines Integer 0: Unknown Required This is a DEN-ng attribute; it is
the type of connector that this instance is. 1: DB-9 similar to the ConnectorType
Values include: 2: DB-15 attribute of the DMTF CIM
3: DB-25 PhysicalConnector class. Main
4: DB-36 difference is that the DMTF
5: DB-60 attribute was an array that
6: SC combined this, gender, and
7: SG other attributes into one. This
was not a required attribute in
the DMTF CIM. Not present in
M.3100.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 104

Business Entity Model – PhysicalConnector

PhysicalResource RolesDescribePhysicalResource PhysicalResourceRole

0..1 0..n
ContainsHardware

0..1
PhysicalDevice Hardware 0..n

0..1 0..n 0..1

ConsistsOf HardwareHasConnector

0..n
ManagedHardware PhysicalConnector
cableType : Integer
gender : Integer
inUse : Boolean
pinDescription : String
typeOfConnector : Integer

0..n 0..n

ConnectedTo

Figure 5PR- 43. PhysicalConnector Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 105

PhysicalPort Business Entity Definition

Business PhysicalPort
Entity Name
Description This class represents an actual or potential end point of a topological (physical) link, and corresponds directly to a
physical port on a topology map. PhysicalPorts are always contained by another physical object - they can't exist by
themselves. The two most common examples are PhysicalPorts on a Card and on a Chassis.
Sources DEN-ng Cross- Synonyms / This is a DEN-ng class.
References Aliases No direct analogs in the
DMTF CIM or M.3100.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, Equipment, EquipmentHolder, Card,
Business Chassis, ResourceRole, PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Entities
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 106

PhysicalPort Business Entity Attributes Definition

Business Entity PhysicalPort

Name
Attribute Name Description Data Characteristics, Required/ Notes (used to map to other
Type Permitted Optional models; blank is other
Values & Units models don’t have it)
duplexMode This is an enumerated integer that Integer 0: Unknown Required This is a DEN-ng attribute; no
defines the duplex mode of this port. 1: Full Duplex analog in the DMTF CIM or
2: Half Duplex M.3100 since no PhysicalPort
exists.
ifType This is an enumerated integer, and Integer 0: Unknown Required This is a DEN-ng attribute; no
specifies the particular media type of 1: 10BaseT analog in the DMTF CIM or
the link. This attribute provides 2: 100BaseT M.3100 since no PhysicalPort
additional detail beyond that provided 3: 10-100BaseT exists.
in the ifType of an ifEntry of a MIB 4: 1000BaseT
(e.g., distinguishing between 10Base 5: 10000BaseT
and 100Base ethernet). 6: DS-0
7: DS-1
8: DS-3
9: OC-3
10: OC-12
11: OC-48
12: OC-192
portNumber This is a non-zero integer that uniquely Integer Required This is a DEN-ng attribute; no
identifies this PhysicalPort instance analog in the DMTF CIM or
from all other instances. M.3100 since no PhysicalPort
exists.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 107

Business Entity PhysicalPort (continued)

Name
Attribute Name Description Data Characteristics, Required/ Notes (used to map to other
Type Permitted Optional models; blank is other
Values & Units models don’t have it)
typeOfPort This is an enumerated integer that Integer 0: Unknown Required This is a DEN-ng attribute; no
defines the particular type of 1: Ethernet analog in the DMTF CIM or
PhysicalPort this instance is. 2: FastEthernet M.3100 since no PhysicalPort
3: Auto-Sensing exists.
Note: auto-sensing is the ability to 4: GigabitEthernet
differentiate between (Ethernet 5: FastGigabitEthernet
and FastEthernet). This 6: DS-0
enumeration is not done! 7: DS-1
8: DS-3
9: T1
10: T3
11: E1
12: E3
13: OC-3
14: OC-12
15: OC-48
16: OC-192
17: RS-232C
vendorPortName This is a string that contains the String Optional This is a DEN-ng attribute; no
vendor-specific name of this port. analog in the DMTF CIM or
This is different from the M.3100 since no PhysicalPort
commonName attribute, which exists.
represents a system-wide naming
structure for all ManagedEntities.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 108

Business Entity Model – PhysicalPort

ManagedHardware

PhysicalPort PhysicalContainer
duplexMode : Integer
ifType : Integer
portNumber : Integer
typeOfPPort : Integer
vendorPortName : String
Equipment EquipmentInHolder EquipmentHolder
0..n 0..n
0..n 0..1

0..1 HolderComposite
Card
PortsOnCard

SecureHolder

PortsOnChassis 0..1 Chassis

Figure 5PR- 44. PhysicalPort Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 109

Equipment Business Entity Definition

Business Equipment
Entity Name
Description This class is based on the M.3100 specification, and represents a class of managed objects that represents physical
components of a Resource, including replaceable components. An instance of this object class is present in a single
geographic location. An Equipment may be nested within another Equipment, thereby creating a containment
relationship. The Equipment type shall be identified by sub-classing this object class. Either the name of the sub-class
or an attribute may be used for identifying the Equipment type.
Sources DEN-ng, M.3100 Cross- Synonyms / This is an M.3100 class
References Aliases that has been modified in
DEN-ng. No direct analog
in the DMTF CIM.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer, EquipmentHolder,
Business Card, Chassis, AuxiliaryComponent, PhysicalComponent, PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Entities
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 110

Equipment Business Entity Attributes Definition

Business Entity Name Equipment

Attribute Name Description Data Characteristics, Permitted Required/ Notes (used to map to
Type Values & Units Optional other models; blank is
other models don’t
have it)
expectedEquipmentType This attribute identifies the type String Optional This is a DEN-ng
of the expected resource. For attribute; no analog in
example, "Fan" or "STM16" for the DMTF CIM or
the Equipment class and "Line M.3100.
Shelf" for the Equipment Holder
class. This is an empty string if
there is no expected
equipment.
installedEquipmentType This attribute identifies the type String Optional This is a DEN-ng
of the installed resource. For attribute; no analog in
example, "Fan" or "STM16" for the DMTF CIM or
the Equipment class and "Line M.3100.
Shelf" for the Equipment Holder
class. The installed equipment
type is invariant for the lifetime
of the hardware. This is an
empty string if there is no
installed equipment.
installedVersion This attribute identifies the String Optional This is a DEN-ng
version of the installed attribute; no analog in
equipment. If this is not the DMTF CIM or
available or unknown, the string M.3100.
"UNKNOWN" shall be used.
(NULL is a bad choice because
some software may choose to
initialize the string as a null
string).

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 111

Business Entity Name Equipment (continued)

Attribute Name Description Data Characteristics, Permitted Required/ Notes (used to map to
Type Values & Units Optional other models; blank is
other models don’t
have it)
redundancy This is an enumerated integer Integer 0: Unknown Optional This is a DEN-ng
that describes the redundancy 1: Primary (supported by attribute; no analog in
capabilities of this particular Redundant Equipment) the DMTF CIM or
Equipment. 2: Redundant M.3100.
3: Stand-alone (no
redundancy possible)

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 112

Business Entity Model - Equipment

ManagedHardware

PhysicalPort PhysicalContainer

0..n

Equipment EquipmentHolder
expectedEquipmentType : String
installedEquipmentType : String
installedVersion : String 0..1
0..n
redundancy : Integer
EquipmentInHolder

PortsOnCard 0..1 Card

Figure 5PR- 45. Equipment Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 113

Card Business Entity Definition

Business Card
Entity Name
Description This class is based on the M.3100 specification, and represents a class of managed objects that represents physical
components of a Resource, including replaceable components. An instance of this object class is present in a single
geographic location. An Equipment may be nested within another Equipment, thereby creating a containment
relationship. The Equipment type shall be identified by sub-classing this object class. Either the name of the sub-class
or an attribute may be used for identifying the Equipment type.
Sources DEN-ng, M.3100 Cross- Synonyms / This is an M.3100 class
References Aliases that has been modified in
DEN-ng. No direct analog
in the DMTF CIM.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer (superclass),
Business EquipmentHolder, MemoryCard (subclass), NetworkCard (subclass), SystemCard (subclass), UnknownCard
Entities (subclass), Chassis, AuxiliaryComponent, PhysicalComponent, PhysicalResourceRole, PhysicalDeviceRole,
HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 114

Card Business Entity Attributes Definition

Business Entity Name Card

Attribute Name Description Data Characteristics, Permitted Required/ Notes (used to map to
Type Values & Units Optional other models; blank is
other models don’t
have it)
daughterCardInstallStatus This is an enumerated Integer 0: Not Applicable (doesn't Optional This is a DEN-ng
integer that defines the have any daughter Cards) attribute; no analog in
current installation status of 1: All daughter Cards are the DMTF CIM or
this Card's daughter Cards. installed M.3100.
Note that this defines the 2: Some daughter Cards are
status of daughter Cards as installed
viewed by the hosting Card. 3: No daughter Cards are
Status values of individual installed
daughter Cards are defined
by attributes in the daughter
card itself.

daughterCardOperating This is an enumerated Integer 0: Not Applicable (doesn't Optional This is a DEN-ng
Status integer that defines the have any DaughterCards) attribute; no analog in
current operating status of 1: All Daughter Cards are the DMTF CIM or
this Card's daughter Cards. operating correctly M.3100.
Note that this defines the 2: Some Daughter Cards are
operating status of daughter operating incorrectly
Cards as viewed by the 3: No Daughter Cards are
hosting Card. Status values operating correctly
of individual daughter Cards
are defined by attributes in
the daughter card itself.

This attribute only defines

the physical operating
characteristics of the
daughter card. It does not
say whether the daughter
Card is functioning correctly,
as that is a logical attribute.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 115

Business Entity Name Card (continued)

Attribute Name Description Data Characteristics, Permitted Required/ Notes (used to map to
Type Values & Units Optional other models; blank is
other models don’t
have it)
daughterCardRequirements This is an enumerated Integer 0: Unknown Optional This is a DEN-ng
integer that defines the 1: No DaughterCard can be attribute; no analog in
relationship between this attached M.3100. Called
Card and all daughter 2: Requires 1 or more RequiresDaughterBoard
Cards. daughter Cards to function in the CIM, but lacks the
correctly semantics of the DEN-
3: Can optionally use 1 or ng attribute.
more DaughterCards
isConfigurablePhysically This is a boolean attribute Boolean Optional This is a DEN-ng
that, if TRUE, indicates attribute; no analog in
that this Card has one or the DMTF CIM or
more options that can be M.3100.
physically configured.
Each of these options has
a distinct physical
manifestation (e.g.,
additional memory, or
faster CPU) that usually
(but not always) results in
occupying more room in
the Card.
isMotherBoard This is a Boolean attribute Boolean Optional This is a DEN-ng
that, if TRUE, defines this attribute; no analog in
Card as either a M.3100. Called
motherboard or another HostingBoard in the
type of hosting board. CIM, though the
When FALSE, it isn't. semantics are slightly
different.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 116

Business Entity Name Card (continued)

Attribute Name Description Data Characteristics, Required/ Notes (used to map to
Type Permitted Optional other models; blank is
Values & Units other models don’t
have it)
isUniquePhysical This is a boolean attribute that, if Boolean Required This is a DEN-ng
TRUE, defines this Card to be attribute; no analog in
physically different from other Cards of M.3100. The CIM has a
the same type and therefore requires a similar attribute called
special slot. The unique aspects of this SpecialRequirements but
Card are described in the there is a bug in the text.
UniqueRequirementsPhysical attribute.
An example might be a different form
factor than other Cards of its type, or
the ability to set jumpers on the Card
to control its functionality (e.g.,
clocking).
slotLayout This is a free-form string that describes String Optional This is a DEN-ng
the positioning, spacing, typical usage, attribute; no analog in
restrictions, and any other pertinent M.3100. Called
information that defines how the Card SlotLayout in the CIM.
is to be positioned into the Slot.
slotsRequired This is an integer that defines the Integer Required This is a DEN-ng
number of slots required to hold this attribute; no analog in the
Card. Since this is usually 1, that value DMTF CIM or M.3100.
is assigned as its default value.
uniqueRequirementsPhysical This is a free-form string that contains String Optional This is a DEN-ng
the physically unique requirements of attribute; no analog in
this Card. For example, it must go in a M.3100. Called
certain slot number because it has RequirementsDescription
special dimensions. This attribute in the CIM
should only be filled in if the value of
the IsUniquePhysical attribute is
TRUE; otherwise, it should be NULL.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 117

Business Entity Model – Card

ManagedHardware

PhysicalPort PhysicalContainer

0..n
0..1
Equipment
EquipmentInEquipment
0..n
PortsOnCard

Card
daughterCardInstallStatus : Integer
daughterCardOperatingStatus : Integer 0..1
daughterCardRequirements : Integer
isConfigurablePhysically : Boolean
0..1 isMotherBoard : Boolean CardOnCard
isUniquePhysical : Boolean
slotLayout : String
0..n
slotsRequired : Integer = 1
uniqueRequirementsPhysical : String

MemoryCard NetworkCard SystemCard UnknownCard

Figure 5PR- 46. Card Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 118

MemoryCard Business Entity Definition

Business MemoryCard
Entity Name
Description This is a type of Card that is dedicated to providing additional memory for use by other components of a Resource.
Cards that are used to expand memory, or provide different types of memory, are examples of this type of Card. DEN-
ng differentiates between this and other types of Cards, such as NetworkCards and MemoryCards.
Sources DEN-ng Cross- Synonyms / This is a DEN-ng class.
References Aliases No direct analog in the
DMTF CIM or M.3100.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer, EquipmentHolder,
Business Card, NetworkCard, SystemCard, UnknownCard, Chassis, AuxiliaryComponent, PhysicalComponent,
Entities PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 119

MemoryCard Business Entity Attributes Definition

Currently, no attributes have been defined for this object since it is there primarily for classification purposes. Attributes may be
added to this object in the next phase of the SID once a more complete survey of MemoryCards has been completed.

Business Entity Name MemoryCard

Attribute Name Description Data Characteristics, Required/ Notes (used to map to
Type Permitted Optional other models; blank is
Values & Units other models don’t
have it)
Tbd

Business Entity Model – MemoryCard

The MemoryCard business entity model is the same as that of the Card business entity model, which was shown in Figure 5PR- 46
above.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 120

NetworkCard Business Entity Definition

Business NetworkCard
Entity Name
Description This is a type of Card that is dedicated to providing networking functions, such as routing and forwarding. Line cards
and port adapter cards are examples of this type of card. DEN-ng differentiates between this and other types of Cards,
such as NetworkCards and MemoryCards.
Sources DEN-ng Cross- Synonyms / This is a DEN-ng class.
References Aliases No direct analog in the
DMTF CIM or M.3100.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer, EquipmentHolder,
Business Card, MemoryCard, SystemCard, UnknownCard, Chassis, AuxiliaryComponent, PhysicalComponent,
Entities PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 121

NetworkCard Business Entity Attributes Definition

Currently, no attributes have been defined for this object since it is there primarily for classification purposes. Attributes may be
added to this object in the next phase of the SID once a more complete survey of NetworkCards has been completed. However,
since NetworkCards are so diverse (both in form as well as in function), it is highly likely that this class will remain as is and function
as a means to classify different types of Cards.

Business Entity Name NetworkCard

Attribute Name Description Data Characteristics, Required/ Notes (used to map to
Type Permitted Optional other models; blank is
Values & Units other models don’t
have it)
Tbd

Business Entity Model – NetworkCard

The NetworkCard business entity model is the same as that of the Card business entity model, which was shown in Figure 5PR- 46
above.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 122

SystemCard Business Entity Definition

Business SystemCard
Entity Name
Description This is a type of Card that is dedicated to providing system functions. Main processor boards and controller boards are
examples of this type of Card. DEN-ng differentiates between this and other types of Cards, such as NetworkCards and
MemoryCards.
Sources DEN-ng Cross- Synonyms / This is a DEN-ng class.
References Aliases No direct analog in the
DMTF CIM or M.3100.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer, EquipmentHolder,
Business Card, MemoryCard, NetworkCard, UnknownCard, Chassis, AuxiliaryComponent, PhysicalComponent,
Entities PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 123

SystemCard Business Entity Attributes Definition

Currently, no attributes have been defined for this object since it is there primarily for classification purposes. Attributes may be
added to this object in the next phase of the SID once a more complete survey of SystemCards has been completed. However,
since SystemCards are so diverse (both in form as well as in function), it is highly likely that this class will remain as is and function
as a means to classify different types of Cards

Business Entity Name SystemCard

Attribute Name Description Data Characteristics, Required/ Notes (used to map to
Type Permitted Optional other models; blank is
Values & Units other models don’t
have it)
Tbd

Business Entity Model – SystemCard

The SystemCard business entity model is the same as that of the Card business entity model, which was shown in Figure 5PR- 46
above.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 124

UnknownCard Business Entity Definition

Business UnknownCard
Entity Name
Description This object is used as a generic placeholder to represent Cards that are known to exist but are not yet identifiable via
Software means.
Sources DEN-ng Cross- Synonyms / This is a DEN-ng class.
References Aliases No direct analog in the
DMTF CIM or M.3100.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer, EquipmentHolder,
Business Card, MemoryCard, SystemCard, UnknownCard, Chassis, AuxiliaryComponent, PhysicalComponent,
Entities PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 125

UnknownCard Business Entity Attributes Definition

Currently, no attributes have been defined for this object since it is there primarily for classification purposes. It is unlikely that any
business attributes will be added to this object, since the purpose of this Card is to serve as a placeholder to log unknown Cards as
part of an inventory process. Thus, it is highly likely that this class will remain as is and function as a means to classify different types
of unknown Cards.

Business Entity Name UnknownCard

Attribute Name Description Data Characteristics, Required/ Notes (used to map to
Type Permitted Optional other models; blank is
Values & Units other models don’t
have it)
Tbd

Business Entity Model – UnknownCard

The UnknownCard business entity model is the same as that of the Card business entity model, which was shown in Figure 5PR- 46
above.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 126

EquipmentHolder Business Entity Definition

Business EquipmentHolder
Entity Name
Description This class is based on the M.3100 specification, and is a base class that represents physical objects that are both
manageable as well as able to host, hold, or contain other physical objects. Examples of physical objects that can be
represented by instances of this object class are Racks, Chassis, Shelfs, Cards, and Slots.
Sources DEN-ng, M.3100 Cross- Synonyms / This is a DEN-ng class,
References Aliases based on an M.3100
class. No direct analog in
the DMTF CIM.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer (superclass),
Business Equipment, Card, EquipmentHolderAtomic (subclass), EquipmentHolderComposite (subclass), SecureHolder, Chassis,
Entities Rack, Slot, Shelf, Bay, PhysicalHolderRole, PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 127

EquipmentHolder Business Entity Attributes Definition

Business Entity Name EquipmentHolder

Attribute Name Description Data Characteristics, Required/ Notes (used to map to
Type Permitted Optional other models; blank is
Values & Units other models don’t
have it)
acceptableEquipmentList This is an array of strings, based Array of Optional This is a DEN-ng
on M.3100, that identifies the types String attribute, based on an
of equipment objects that can be M.3100 class; no analog
supported by this object. in the DMTF CIM.
typeOfHolder This is an enumerated integer that Integer 0: Unknown Optional This is a DEN-ng
identifies the type of the Holder 1: Rack attribute, based on an
that this object instance is. It is 2: Bay M.3100 class; no analog
based on M.3100 but includes 3: Chassis in the DMTF CIM.
additional values. 4: Shelf
5: Slot
6: Subslot
holderStatus This attribute, based on M.3100, Integer 0: Unknown Optional This is a DEN-ng
indicates the status of the 1: Installed And attribute, based on an
EquipmentHolder. Acceptable M.3100 class; no analog
2: Installed And Not in the DMTF CIM.
Acceptable
3: Not Installed
4: Mismatch Of Installed
and Acceptable
5: Unavailable

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 128

Business Entity Model – EquipmentHolder

ManagedHardware

PhysicalPort PhysicalContainer

0..n

Equipment 0..1 EquipmentHolder

0..n
EquipmentInHolder acceptableEquipmentList : SequenceOf String
holderStatus : Integer 0..n
typeOfHolder : Integer

0..1 Card
HasHolders
PortsOnCard

HolderAtomic HolderComposite 0..1

Figure 5PR- 47. EquipmentHolder Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 129

HolderAtomic Business Entity Definition

Business HolderAtomic
Entity Name
Description This class represents atomic holders of Equipment that are individually manageable and do NOT form composite, or nested,
Equipment Holders.

Each HolderAtomic object can be a FRU.

Sources DEN-ng Cross- Synonyms / This is a DEN-ng class, based
References Aliases on an M.3100 class. No direct
analog in the DMTF CIM,
because there is no difference
between HolderAtomic and
HolderComposite objects.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer, Equipment, Card,
Business EquipmentHolder (superclass), EquipmentHolderComposite (sibling), SecureHolder, Chassis, Rack, Slot (subclass), Shelf,
Entities Bay, PhysicalHolderRole, PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 130

HolderAtomic Business Entity Attributes Definition

Business Entity Name HolderAtomic

Attribute Name Description Data Characteristics, Required/ Notes (used to map to
Type Permitted Optional other models; blank is
Values & Units other models don’t
have it)
physicalDescription This is a free-form string that String Optional This is a DEN-ng
defines the physically unique attribute, based on an
characteristics of this holder. M.3100 class; no analog
in the DMTF CIM.
uniquePhysical This is a Boolean attribute that, if Boolean Optional This is a DEN-ng
TRUE, means that this holder is attribute, based on an
physically different from other M.3100 class; no analog
holders, and is intended to hold a in the DMTF CIM.
special type of equipment (e.g., a
doublewide card, or a longer card
than normal).

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 131

Business Entity Model – HolderAtomic

EquipmentHolder 0..n

HasHolders

HolderAtomic HolderComposite 0..1

physicalDescription : String
uniquePhysical : Boolean

Slot 0..1
SlotInSlot
0..n
0..1 0..n

AdjacentSlots

Figure 5PR- 48. HolderAtomic Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 132

Slot Business Entity Definition

Business Slot
Entity Name
Description This is a concrete class that has two main purposes. One is to model the ability of a hosting board to accept a daughter
card to add or complete the base functionality of the hosting board. The second is to represent the different expansion
slots supported by a Chassis.
Sources DEN-ng Cross- Synonyms / This is a DEN-ng class.
References Aliases No counterpart in
M.3100; the DMTF CIM
has a Slot class but the
semantics are different.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer, Equipment, Card,
Business EquipmentHolder, EquipmentHolderAtomic (superclass), EquipmentHolderComposite, SecureHolder, Chassis, Rack,
Entities Shelf, Bay, PhysicalHolderRole, PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 133

Slot Business Entity Attributes Definition

Business Entity Name Slot

Attribute Name Description Data Characteristics, Required/ Notes (used to map to
Type Permitted Optional other models; blank is
Values & Units other models don’t
have it)
hasAdapter This is a Boolean attribute that, if Boolean Optional This is a DEN-ng; no
TRUE, indicates that this slot has analog in the DMTF CIM
an adapter installed that enables it or M.3100.
to accept other types of cards
(e.g., fitting an adapter on two
Slots enable them to accept a
Card that otherwise could not be
accommodated). If its value is
FALSE, then no adapter is
present.
slotNumber This is a 16-bit unsigned integer Integer Required This is a DEN-ng
attribute that represents an index attribute; no analog in
into the system slot table. For M.3100. The DMTF CIM
example, this could be the has an attribute named
hardware ID number (starting with SlotNumber; however,
1) for each expansion slot. The the semantics of the Slot
number is independent of whether class are different.
or not the Slot is occupied.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 134

Business Entity Name Slot (continued)

Attribute Name Description Data Characteristics, Required/ Notes (used to map to
Type Permitted Optional other models; blank is
Values & Units other models don’t
have it)
slotPurpose This is an enumerated integer that Integer 0: Unknown Optional This is a DEN-ng
defines the purpose of this Slot. A 1: System attribute; no analog in
specific value below, such as 2: Networking M.3100. The DMTF CIM
System, means that the Slot is 3: Port Adapter has an attribute called
intended only to accept System 4: Memory SpecialPurpose, but it is
cards. 5: Hardware Assist only a Boolean and thus
6: Video has more restricted
7: General Computing semantics.
8: General Purpose
purposeDescription This is a free-form string that String Optional This is a DEN-ng
defines the physically unique attribute; no analog in
characteristics of this Slot. M.3100. The DMTF CIM
has an attribute called
PurposeDescription, but
the Slot class has
different semantics.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 135

Business Entity Model – Slot

0..n EquipmentHolder
HasHolders

0..1 HolderComposite HolderAtomic

Slot
hasAdapter : Boolean 0..1
purposeDescription : String
slotNumber : Integer SlotInSlot
slotPurpose : Integer 0..n

0..1 0..n

AdjacentSlots

AdjacentSlotDetails
sharedSlots : Boolean
slotSpacingMax : Integer
slotSpacingMin : Integer

Figure 5PR- 49. Slot Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 136

HolderComposite Business Entity Definition

Business HolderComposite
Entity Name
Description This class represents EquipmentHolders that are made up of other EquipmentHolders (i.e., instances of this class as well as
the HolderAtomic base class). This provides the semantics of collecting a set of components, each of which is individually
manageable, and being able to manage the set of objects as a whole. This containment is modeled using the HasHolders
aggregation.

Each HolderComposite element can be a FRU.

A characteristic of this class is that its subclasses are physical objects that have complex cabling and mounting options. This
class is meant to differentiate complex holders, like a Chassis, from simple holders, like a Slot.
Sources DEN-ng Cross- Synonyms / This is a DEN-ng class, based
References Aliases on an M.3100 class. No direct
analog in the DMTF CIM,
because there is no difference
between HolderAtomic and
HolderComposite objects.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer, Equipment, Card,
Business EquipmentHolder (superclass), EquipmentHolderAtomic (sibling), SecureHolder (subclass), Chassis, Rack, Slot, Shelf, Bay,
Entities PhysicalHolderRole, PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 137

HolderComposite Business Entity Attributes Definition

Business Entity Name HolderComposite

Attribute Name Description Data Characteristics, Required/ Notes (used to map to
Type Permitted Optional other models; blank is
Values & Units other models don’t
have it)
cableManagementStrategy This is a free-form string that String Optional This is a DEN-ng
contains information on how the attribute; no analog in
various cables contained in the M.3100. The DMTF
Chassis, Rack, or other type of CIM has a similarly
HolderComposite object are named attribute in its
connected and bundled. This PhysicalFrame class,
property contains information to though the semantics
aid in the assembly and service of are slightly different.
the cables contained in a
SecureHolder object.
mountingOptions This is an enumerated 16-bit Integer 0: Unknown Optional This is a DEN-ng class;
unsigned integer that defines how 1: Stand-alone no analog in the DMTF
Equipment in this entity is 2: Rack-mounted, free CIM or M.3100.
mounted. access
3: Rack-mounted,
restricted access
4: Enclosed in another
chassis
serviceApproach This is an enumerated, integer- Integer 0: Unknown Optional This is a DEN-ng class;
valued array that defines how this 1: Custom no analog in the DMTF
entity is serviced (e.g., from the top 2: Service From Top CIM or M.3100.
or front), whether it has sliding 3: Service From Front
trays or removable sides, and/or 4: Service From Back
whether the Frame is moveable 5: Service From Side
(e.g., it has rollers). 6: Sliding Trays
7: Removable Sides
8: Moveable

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 138

Business Entity Model – HolderComposite

EquipmentHolder HasHolders
0..n

0..1
HolderAtomic HolderComposite
cableManagementStrategy : String
mountingOptions : Integer
serviceApproach : SequenceOf Integer

SecureHolder

Figure 5PR- 50. HolderComposite Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 139

SecureHolder Business Entity Definition

Business SecureHolder
Entity Name
Description This class is a type of HolderComposite that serves as the parent for the Rack and Chassis classes. This class generalizes
common properties that apply to Racks and Chassis.
Sources DEN-ng Cross- Synonyms / This is a DEN-ng class, based
References Aliases on the original DEN spec. No
direct analog in M.3100. The
DMTF CIM defines similar
attributes, but as part of the
PhysicalFrame class, and
lacks the semantics and
classification of the DEN-ng
hierarchy.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer, Equipment, Card,
Business EquipmentHolderAtomic, EquipmentHolderComposite (superclass), Chassis (subclass), Rack (subclass), Slot, Shelf, Bay,
Entities PhysicalHolderRole, PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 140

SecureHolder Business Entity Attributes Definition

Business Entity Name SecureHolder

Attribute Name Description Data Characteristics, Required/ Notes (used to map to
Type Permitted Optional other models; blank is
Values & Units other models don’t
have it)
audibleAlarm This is a boolean attribute that, if Boolean Optional No analog in M.3100;
TRUE, indicates that this the DMTF CIM has a
SecureHolder is equipped with an similarly named
audible alarm. attribute in
PhysicalFrame.
audibleAlarmDescription This is a free-form string that String Optional No analog in M.3100;
provides supplementary the DMTF CIM defines
information for the AudibleAlarm an array called
attribute. It should only be filled in ServiceDescriptions in
when the value of the PhysicalFrame to do
AudibleAlarm attribute is TRUE. the same thing.
lockPresent This is a boolean attribute that, if Boolean Optional No analog in M.3100;
TRUE, indicates that this the DMTF CIM has a
SecureHolder is protected by similarly named
some type of lock. attribute in
PhysicalFrame.
securityBreach This is an enumerated 16-bit Integer 0: Unknown Optional No analog in M.3100;
unsigned integer attribute 1: Other the DMTF CIM has a
indicating whether a breach of the 2: No Breach similarly named
Rack was attempted. 3: Unsuccessful Breach attribute in
(but attempted) PhysicalFrame.
4: Successful Breach
securityBreachDescription This is a free-form string attribute String Optional No analog in M.3100;
that provides supplementary the DMTF CIM has a
information for the SecurityBreach similarly named
attribute. It should only be filled in attribute in
when the value of SecurityBreach PhysicalFrame.
is 1 (“Other”).

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 141

Business Entity Name SecureHolder (continued)

Attribute Name Description Data Characteristics, Required/ Notes (used to map to
Type Permitted Optional other models; blank is
Values & Units other models don’t
have it)
visibleAlarm This is a boolean attribute that, if Boolean Optional No analog in M.3100;
TRUE, indicates that the the DMTF CIM has a
SecureHolder is equipped with one similarly named
or more visible alarms (e.g., LEDs attribute in
or gauges). PhysicalFrame.
visibleAlarmDescription This is a free-form string attribute String Optional No analog in M.3100;
that provides supplementary the DMTF CIM defines
information for the VisibleAlarm an array called
attribute. It should only be filled in ServiceDescriptions in
when the value of VisibleAlarm is PhysicalFrame to do
TRUE. the same thing.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 142

Business Entity Model – SecureHolder

EquipmentHolder HasHolders
0..n

0..1
HolderAtomic HolderComposite

SecureHolder
audibleAlarm : Boolean
audibleAlarmDescription : String
lockPresent : Boolean
securityBreach : Integer
securityBreachDescription : String
visibleAlarm : Boolean
visibleAlarmDescription : String

Rack ChassisInRack Chassis

0..1 0..n
0..1 0..n

Docked

Figure 5PR- 51. SecureHolder Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 143

Rack Business Entity Definition

Business Rack
Entity Name
Description A Rack is a type of SecureHolder that represents an enclosure in which EquipmentHolders, such as Chassis, are
placed. Typically a Rack is nothing more than the enclosure, and all the functioning componentry is packaged in the
Chassis.

Note that the logical identifier of a Rack is NOT typically associated with the Device (i.e., the NetworkElement).
Compare this to either a Bay or a Shelf, whose logical identifier IS associated with the Device. This means that the
Rack is explicitly NOT a part of the logical model of a network.

The Rack typically serves as the "master enclosure" for Chassis, Shelves and Bays. In addition, Racks can have
multiple instances of multiple Devices mounted in them.
Sources DEN-ng Cross- Synonyms / This is a DEN-ng class,
References Aliases based on the original
DEN spec. No direct
analog in M.3100. The
DMTF CIM has a Rack
class, but its semantics
are slightly different.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer (superclass),
Business Equipment, Card, EquipmentHolderAtomic, EquipmentHolderComposite, SecureHolder (superclass), Chassis (sibling),
Entities Slot, Shelf, Bay, PhysicalHolderRole, PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 144

Rack Business Entity Attributes Definition

Business Entity Name Rack

Attribute Name Description Data Characteristics, Required/ Notes (used to map to
Type Permitted Optional other models; blank is
Values & Units other models don’t
have it)
country This is the designation of the String Optional No analog in M.3100;
country for which the Rack is the DMTF CIM has a
designed. Country code strings are similar attribute named
as defined by ISO/IEC 3166. CountryDesignation.
heightInUs This is the height of the Rack in Integer Optional No analog in M.3100;
'U's. A 'U' is a standard unit of the DMTF CIM has a
measure for the height of a Rack height attribute higher in
or rack-mountable components. It the hierarchy and
is equal to 1.75 inches or 4.445 overrides that attribute
cm. in the Rack class.
typeOfRack This is an enumerated integer that Integer 0: Unknown Optional No analog in M.3100;
defines the type of Rack. 1: Standard 19 Inch the DMTF CIM has a
2: Telco similarly name attribute.
3: Equipment Shelf
4: Non-Standard

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 145

Business Entity Model – Rack and Chassis

HolderComposite

SecureHolder

Rack
Chassis
country : String
chassisType : Integer
heightInUs : Integer
heatGeneration : Integer
typeOfRack : Integer
installationOrder : String
numberOfChassisSlots : Integer
0..1
0..n 0..1 0..n

ChassisInRack Docked

Figure 5PR- 52. Rack and Chassis Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 146

Chassis Business Entity Definition

Business Chassis
Entity Name
Description A Chassis is a type of SecureHolder that encloses other ManagedPhysicalEntities and provides a definable functionality
in its own right, such as a desktop or a network device (e.g., a router or a switch).
Sources DEN-ng Cross- Synonyms / This is a DEN-ng class,
References Aliases based on the original
DEN spec. No direct
analog in M.3100. The
DMTF CIM has a Chassis
class, but its semantics
are slightly different.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer (superclass),
Business Equipment, Card, EquipmentHolderAtomic, EquipmentHolderComposite, SecureHolder (superclass), Rack (sibling),
Entities Slot, Shelf, Bay, PhysicalHolderRole, PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 147

Chassis Business Entity Attributes Definition

Business Entity Name Chassis

Attribute Name Description Data Characteristics, Permitted Required/ Notes (used to map to
Type Values & Units Optional other models; blank is
other models don’t
have it)
heatGeneration This is an integer that defines Integer Optional No analog in M.3100;
the amount of heat generated the DMTF CIM has a
by the Chassis in BTU/hour. similarly name attribute.
installationOrder This is a free-form string that String Optional No analog in M.3100 or
defines the order of the DMTF CIM.
installation of components
into the Chassis.
numberOfChassisSlots This defines the number of Integer Optional No analog in M.3100 or
Slots that are in the Chassis. the DMTF CIM.
This does NOT account for
any SlotAdapters used -
these are described by the
CardInSlot association.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 148

Business Entity Name Chassis (continued)

Attribute Name Description Data Characteristics, Permitted Required/ Notes (used to map to
Type Values & Units Optional other models; blank is
other models don’t
have it)
chassisType This is an enumerated integer Integer 0: Unknown Optional No analog in M.3100;
that defines the type of 1: Desktop the DMTF CIM has a
Chassis that this object is. 2: Low Profile Desktop similarly name attribute.
3: Pizza Box
4: Mini Tower
5: Tower
6: Portable
7: LapTop
8: Notebook
9: Sub-Notebook
10: Hand Held
11: Docking Station
12: Main System Chassis
13: Expansion Chassis
14: Bus Expansion Chassis
15: Peripheral Chassis
16: Storage Chassis
17: Rack Mount Chassis

Business Entity Model – Chassis

The Chassis business entity model is the same as the Rack business entity model, which was shown in Figure 5PR- 52 above.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 149

AuxiliaryComponent Business Entity Definition

Business AuxiliaryComponent
Entity Name
Description This is an abstract base class that represents managed entities, such as power supplies, fans and cables, wihch are
required for the proper operation of the Device but have a primary function that is different than the primary end-user
function(s) of the Device.

The difference between AuxiliaryComponents and other subclasses of Equipment 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. Consider a
Router. Its main function is to route and forward packets. A PowerSupply is an AuxiliaryComponent, because even
though 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 a subclass of Equipment 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.
Sources DEN-ng Cross- Synonyms / This is a DEN-ng class.
References Aliases No direct analog in the
DMTF CIM or M.3100.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer (superclass),
Business PowerSupply, CoolingDevice, Equipment, Card, EquipmentHolder, Chassis, Rack, Slot, Shelf, Bay,
Entities PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 150

AuxiliaryComponent Business Entity Attributes Definition

The purpose of this class is to serve as a base class for defining different types of AuxiliaryComponents. Thus, it is primarily used for
classification purposes, and has no business attributes. Additional types of AuxiliaryComponents will be added in a future phase of
the SID.

Business Entity Name AuxiliaryComponent

Attribute Name Description Data Characteristics Required/ Notes (used to map to
Type , Permitted Optional other models; blank is
Values & Units other models don’t
have it)
Tbd

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 151

Business Entity Model – AuxiliaryComponent

ManagedHardware

PhysicalContainer

Equipment 0..n 0..1 EquipmentHolder AuxiliaryComponent

EquipmentInHolder
0..1 0..1

PerformsCooling 0..n CoolingDevice PowerSupply

0..n

Fan

SuppliesPower

Figure 5PR- 53. AuxiliaryComponent Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 152

CoolingDevice Business Entity Definition

Business CoolingDevice
Entity Name
Description This class represents the capabilities of a generic cooling device.

Additional detail will be supplied in a later version of the SID. It is present to provide an example of a type of
AuxiliaryComponent.
Sources DEN-ng, CIM Cross- Synonyms / No direct analog in
References Aliases M.3100. (Note that the
CIM has a completely
different class hierarchy).
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer, AuxiliaryComponent
Business (superclass), PowerSupply, Fan, Equipment, Card, EquipmentHolder, Chassis, Rack, Slot, Shelf, Bay,
Entities PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 153

CoolingDevice Business Entity Attributes Definition

The purpose of this class is to serve as a base class for defining different types of AuxiliaryComponents. Thus, it is primarily used for
classification purposes, and has no business attributes. Additional types of AuxiliaryComponents will be added in a future phase of
the SID.

Business Entity Name CoolingDevice

Attribute Name Description Data Characteristics, Required/ Notes (used to map to
Type Permitted Optional other models; blank is
Values & Units other models don’t
have it)
hasActiveCooling This is a Boolean that, if TRUE, means Boolean Required Not present in M.3100.
that this CoolingDevice provides active Present in the
cooling. If it is false, then cooling is CoolingDevice class of
provided by a passive means. the CIM, and called
ActiveCooling. However,
this class is in the
LogicalDevice model.
Thus, the class
hierarchy and semantics
are completely different
than those of DEN-ng.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 154

Business Entity Model – CoolingDevice

PhysicalContainer

Equipment 0..1 EquipmentHolder AuxiliaryComponent

0..n
EquipmentInHolder
0..1 0..1

CoolingDevice PowerSupply
PerformsCooling 0..n
hasActiveCooling : Boolean

0..n

Fan
currentSpeed : String
desiredSpeed : Integer
isVariableSpeed : Boolean

SuppliesPower

Figure 5PR- 54. CoolingDevice and Fan Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 155

Fan Business Entity Definition

Business Fan
Entity Name
Description This class represents the capabilities of a generic Fan.

Additional detail will be supplied in a later version of the SID. It is present to provide an example of a type of
AuxiliaryComponent.
Sources DEN-ng, CIM Cross- Synonyms / No direct analog in
References Aliases M.3100. (Note that the
CIM has a completely
different class hierarchy).
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer, AuxiliaryComponent,
Business PowerSupply, CoolingDevice (superclass), Equipment, Card, EquipmentHolder, Chassis, Rack, Slot, Shelf, Bay,
Entities PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 156

Fan Business Entity Attributes Definition

The purpose of this class is to serve as a base class for defining different types of AuxiliaryComponents. Thus, it is primarily used for
classification purposes, and has no business attributes. Additional types of AuxiliaryComponents will be added in a future phase of
the SID.

Business Entity Name Fan

Attribute Name Description Data Characteristics, Required/ Notes (used to map to
Type Permitted Optional other models; blank is
Values & Units other models don’t
have it)
currentSpeed This is the current speed of the Fan in Integer Required Not present in M.3100.
revolutions per minute. The CIM derives this
attribute through an
association with a
tachometer.
isVariableSpeed This is a Boolean attribute that, if TRUE, Boolean Required Not present in M.3100.
means that this fan supports variable Present in the Fan class
cooling speeds. If it is FALSE, then this of the CIM. However,
fan only provides a single cooling speed. this class is in the
LogicalDevice model.
Thus, the class
hierarchy and semantics
are completely different
than those of DEN-ng.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 157

Business Entity Name Fan (continued)

Attribute Name Description Data Characteristics, Required/ Notes (used to map to
Type Permitted Optional other models; blank is
Values & Units other models don’t
have it)
desiredSpeed This is an integer attribute that defines the Integer Optional Not present in M.3100.
currently requested fan speed, defined in Present in the Fan class
revolutions per minute. of the CIM. However,
this class is in the
For non-variable speed Fans, this LogicalDevice model.
attribute has the same semantics as Thus, the class
turning the Fan on or off. For variable- hierarchy and semantics
speed Fans, this attribute represents the are completely different
desired speed of the Fan. than those of DEN-ng. In
addition, the CIM only
allows this attribute for
variable speed Fans.

Business Entity Model – Fan

The Fan business entity model is the same as the CoolingDevice business entity model, which was shown in Figure 5PR- 54 above.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 158

PowerSupply Business Entity Definition

Business PowerSupply
Entity Name
Description This class represents the capabilities of a generic PowerSupply.

Additional detail will be supplied in a later version of the SID. It is present to provide an example of a type of
AuxiliaryComponent.
Sources DEN-ng, CIM Cross- Synonyms / No direct analog in
References Aliases M.3100. (Note that the
CIM has a completely
different class hierarchy).
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer, AuxiliaryComponent
Business (superclass), CoolingDevice, Equipment, Card, EquipmentHolder, Chassis, Rack, Slot, Shelf, Bay,
Entities PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 159

PowerSupply Business Entity Attributes Definition

Note: the CIM has a similarly named class. However, it is in the LogicalDevice model. Thus, the class hierarchy, attributes, and
semantics are completely different than those of DEN-ng.

Business Entity Name PowerSupply

Attribute Name Description Data Characteristics, Required/ Notes (used to map to
Type Permitted Optional other models; blank is
Values & Units other models don’t
have it)
acFrequencyLow This defines the low value of the AC String Optional Not present in M.3100.
Frequency range in Hertz. If this is a DC The CIM has two
PowerSupply, this value is not applicable attributes for defining
and should be set to NULL. two ranges, which are
Integer datatypes.
acFrequencyHigh This defines the high value of the AC String Optional Not present in M.3100.
Frequency range in Hertz. If this is a DC The CIM has two
PowerSupply, this value is not applicable attributes for defining
and should be set to NULL. two ranges, which are
Integer datatypes.
isAC This is a Boolean attribute that, if TRUE, Boolean Required Not present in M.3100 or
signifies this to be an AC PowerSupply. If the CIM (it can be
FALSE, then it is a DC PowerSupply. derived by examining
various other attributes).
isSwitching This is a Boolean attribute that, if TRUE, Boolean Required Not present in M.3100.
indicates that this PowerSupply is a The CIM calls this
switching (vs linear) PowerSupply. IsSwitchngSupply.
dcOutputPower This is the maximum value of the output String Optional Not present in M.3100.
power of the DC PowerSupply. If this is The CIM calls this
an AC PowerSupply, then this attribute TotalOutputPower.
must be set to NULL.
isRedundant This is a Boolean attribute that, if TRUE, Boolean Required Not present in M.3100 or
signifies this PowerSupply as a redundant the CIM.
PowerSupply.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 160

Business Entity Name PowerSupply (continued)

Attribute Name Description Data Characteristics, Required/ Notes (used to map to
Type Permitted Optional other models; blank is
Values & Units other models don’t
have it)
inputVoltageLow This is a string that defines the low value String Optional Not present in M.3100.
for the Input Voltage Range for this Power The CIM has two
Supply. attributes for defining
two ranges, which are
Integer datatypes.
inputVoltageHigh This is a string that defines the high value String Optional Not present in M.3100.
for the Input Voltage Range for this Power The CIM has two
Supply. attributes for defining
two ranges, which are
Integer datatypes.
inputCurrentMax This is a string that defines the input String Optional Not present in M.3100 or
current rating in amperes for a fully the CIM.
populated chassis. For a DC power
supply, this is the maximum current drawn
when operating at the lowest permissible
value of its input voltage range. For an AC
power supply, the value of this attribute is
the same as the value of the
InputCurrentMin attribute.
inputCurrentMin This is a string that defines the input String Optional Not present in M.3100 or
current rating in amperes for a fully the CIM.
populated chassis. For a DC power
supply, this is the minimum current drawn
when operating at the lowest permissible
value of its input voltage range. For an AC
power supply, the value of this attribute is
the same as the value of the
InputCurrentMax attribute.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 161

Business Entity Model – PowerSupply

PhysicalContainer

Equipment 0..1 EquipmentHolder AuxiliaryComponent

0..n
EquipmentInHolder
0..1 0..1

PerformsCooling 0..n CoolingDevice PowerSupply

acFrequencyHigh : String
acFrequencyLow : String
dcOutputPower : String
inputCurrentMax : String
Fan inputCurrentMin : String
inputVoltageHigh : String
inputVoltageLow : String
isAC : Boolean
isRedundant : Boolean
isSwitching : Boolean

0..n
SuppliesPower

Figure 5PR- 55. PowerSupply Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 162

PhysicalComponent Business Entity Definition

Business PhysicalComponent
Entity Name
Description This is the base class for different types of PhysicalComponents that can reside either in an Equipment or an
EquipmentHolder object. They can NOT be used as a stand-alone object.

From a management point-of-view, this object either can not or does not need to be split into its constituent parts. For
example, an ASIC (or Chip) can not , and a tape for data storage does not, need to be split up into their constituent parts. Any
piece of hardware that is not a PhysicalLink, PhysicalConnector, Equipment, or EquipmentHolder, is a subclass of this class.
Sources DEN-ng Cross- Synonyms / No direct analog in M.3100.
References Aliases (Note that the CIM has a
similarly named class, but its
function is different. The DEN-
ng PhysicalContainer class
contains those attribute. There
is no configuration notion in the
current version of the CIM, and
hence there is no counterpart in
the CIM to this class.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer (superclass), Equipment,
Business Card, EquipmentHolder, Chassis, Rack, Slot, Shelf, Bay, AuxiliaryComponent, PhysicalResourceRole, PhysicalDeviceRole,
Entities HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 163

PhysicalComponent Business Entity Attributes Definition

Business Entity Name PhysicalComponent

Attribute Name Description Data Characteristics, Required/ Notes (used to map
Type Permitted Optional to other models;
Values & Units blank is other
models don’t have it)
isConfigurable This is a Boolean attribute that, if TRUE, Boolean Optional No analog in either the
means that this PhysicalComponent is M.3100 or the DMTF
configurable by the end-user. CIM.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 164

Business Entity Model – PhysicalComponent

ManagedHardware

PhysicalContainer

Equipment 0..1 EquipmentHolder AuxiliaryComponent

0..n PhysicalComponent
EquipmentInHolder isConfigurable : Boolean

Backplane Chip FlashDisk

ASIC MemoryComponent

Figure 5PR- 56. PhysicalComponent Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 165

Backplane Business Entity Definition

Business Backplane
Entity Name
Description This class models the backplane that is present in devices.

The current version of this class is serving as a placeholder to illustrate different types of PhysicalComponents. It will be
further developed in the next version of the SID.
Sources DEN-ng Cross- Synonyms / No direct analog in M.3100 or
References Aliases the CIM.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer, Equipment, Card,
Business EquipmentHolder, Chassis, Rack, Slot, Shelf, Bay, AuxiliaryComponent, PhysicalComponent (superclass),
Entities PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 166

Backplane Business Entity Attributes Definition

Attributes and behavior will be defined for this class in the next phase of the SID.

Business Entity Name Backplane

Attribute Name Description Data Characteristics, Required/ Notes (used to map
Type Permitted Optional to other models;
Values & Units blank is other
models don’t have it)
Tbd No analog in M.3100
or the CIM.

Business Entity Model – Backplane

The Backplane Business Entity Model is the same as that for PhysicalComponent, and is shown in Figure 5PR- 56 above.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 167

Chip Business Entity Definition

Business Chip
Entity Name
Description This is a concrete class that models different types of chips that are either directly configurable by the end-user (e.g., a
programmable device) and/or represent FRUs (e.g., a special ASIC that can be upgraded by replacing it with a new version of
that same ASIC).

Note that capacity characteristics (e.g., how much memory can a Flash chip hold) are defined through the PhysicalCapacity
association.
Sources DEN-ng Cross- Synonyms / No direct analog in M.3100.
References Aliases The CIM has a similarly named
class, but its position in the CIM
class hierarchy is different than
the position of this class in the
DEN-ng class hierarchy.
Therefore, the semantics are
different.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer, Equipment, Card,
Business EquipmentHolder, Chassis, Rack, Slot, Shelf, Bay, AuxiliaryComponent, PhysicalComponent (superclass), ASIC,
Entities MemoryComponent, Backplane, PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 168

Chip Business Entity Attributes Definition

Business Entity Name Chip

Attribute Name Description Data Characteristics, Required/ Notes (used to map
Type Permitted Optional to other models;
Values & Units blank is other
models don’t have it)
formFactor This is an enumerated integer that defines Integer 0: Unknown Optional No analog in M.3100;
the form factor of this PhysicalComponent. 1: Other this is a subset of the
2: Custom DMTF CIM attributes.
3: SIP
4: DIP
5: ZIP
6: SOJ
7: SIMM
8: DIMM
9: PGA
10: RIMM
11: SRIMM
12: SODIMM
13: SOIC
14: LCC
15: PLCC

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 169

Business Entity Model – Chip

PhysicalContainer

Equipment EquipmentHolder AuxiliaryComponent PhysicalComponent

isConfigurable : Boolean
0..n 0..1

EquipmentInHolder

Backplane Chip FlashDisk

formFactor : Integer memorySize : String

ASIC MemoryComponent
functionalPurpose : Integer typeOfMemoryComponent : Integer
isMandatoryASIC : Boolean

Memory functionality is
defined through an
association to Memory

Figure 5PR- 57. Chip, ASIC, and MemoryComponent Business Entity Model

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 170

ASIC Business Entity Definition

Business ASIC
Entity Name
Description An ASIC is an Application Specific Integrated Circuit.

This class represents a special type of Chip that is used to upgrade the functionality of a networking device. Examples include
upgrading the modem function of a device, increasing the processing capability of a Card or Device, and implementing some
type of networking functionality, such as fast switching, directly in hardware (as opposed to emulating it in software).
Sources DEN-ng Cross- Synonyms / No direct analog in M.3100 or
References Aliases the CIM.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer, PhysicalComponent, Chip
Business (superclass), MemoryComponent, Equipment, Card, EquipmentHolder, Chassis, Rack, Slot, Shelf, Bay, AuxiliaryComponent,
Entities PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 171

ASIC Business Entity Attributes Definition

Business Entity Name ASIC

Attribute Name Description Data Characteristics, Permitted Required/ Notes (used to map
Type Values & Units Optional to other models;
blank is other
models don’t have it)
functionalPurpose This is an enumerated integer Integer 0: Unknown Optional No analog in either the
that defines the functional 1: Routing Traffic M.3100 or the DMTF
purpose of this ASIC. 2: Forwarding Traffic CIM.
3: Encrypting Traffic
Additional values will be added in 4: Firewalling
the next release of DEN-ng. 5: Encoding
6: General Computational
Functions

isMandatoryASIC This is a Boolean attribute that, if Boolean Required No analog in either the
TRUE, signifies that this ASIC is M.3100 or the DMTF
mandatory for the correct CIM.
operation of the
PhysicalResource that contains it.

Business Entity Model – ASIC

The ASIC Business Entity Model is the same as that for Chip, and is shown in Figure 5PR- 57 above.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 172

MemoryComponent Business Entity Definition

Business MemoryComponent
Entity Name
Description This class represents memory devices that are implemented as Chips. Note that this only represents the physical packaging
of the Memory Chip – the logical functionality is defined in a separate class, called Memory, that is part of the
LogicalResource model.

The current version of this class is serving as a placeholder to illustrate different types of PhysicalComponents. It will be
further developed in the next version of the SID.
Sources DEN-ng Cross- Synonyms / No direct analog in M.3100 or
References Aliases the CIM. (Note that the CIM has
a class named Memory, but its
(class) derivation is different.
Hence, there is no counterpart
in the CIM to this class.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer, PhysicalComponent, Chip
Business (superclass), ASIC, Backplane, Equipment, Card, EquipmentHolder, Chassis, Rack, Slot, Shelf, Bay, AuxiliaryComponent,
Entities PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 173

MemoryComponent Business Entity Attributes Definition

Business Entity Name MemoryComponent

Attribute Name Description Data Characteristics, Required/ Notes (used to map
Type Permitted Optional to other models;
Values & Units blank is other
models don’t have it)
typeOfMemoryComponent This is an enumerated integer that Boolean 0: Unknown Optional No analog in either the
defines the type of memory that 1: Proprietary M.3100 or the DMTF
this Chip is. 2: RAM CIM.
3: DRAM
4: Synchronous DRAM
5: Cache DRAM
6: EDRAM
7: VRAM
8: SRAM
9: EDO
10: ROM
11: PROM
12: EPROM
13: EEPROM
14: FEPROM
15: Flash
16: CDRAM
17: 3DRAM
18: SDRAM
19: SGRAM
20: RDRAM
21: DDR

Business Entity Model – MemoryComponent

The MemoryComponent Business Entity Model is the same as that for Chip, and is shown in Figure 5PR- 57 above.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 174

FlashDisk Business Entity Definition

Business FlashDisk
Entity Name
Description FlashDisk are memory-based devices that conform to the PC Card (formerly PCMCIA) standard, and that present an ATA (AT
Attachment) interface to the device. The Flash Disk has controller circuitry that allows it to emulate a hard disk and that
automatically maps out bad blocks and performs automatic block erasure. Furthermroe, the Flash Disk provides the capability
to allocate noncontiguous sectors, which a Flash memory device can't.
Sources DEN-ng Cross- Synonyms / No direct analog in M.3100 or
References Aliases the CIM.
Related Resource, PhysicalResource, PhysicalDevice, Hardware, ManagedHardware, PhysicalContainer, PhysicalComponent
Business (superclass), Chip, ASIC, MemoryComponent, Backplane, Equipment, Card, EquipmentHolder, Chassis, Rack, Slot, Shelf,
Entities Bay, AuxiliaryComponent, PhysicalResourceRole, PhysicalDeviceRole, HardwareRole
Business To be determined
Rules

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1

SID Model - Addendum 5PR – Physical Resource Page 175

FlashDisk Business Entity Attributes Definition

Business Entity Name FlashDisk

Attribute Name Description Data Characteristics, Required/ Notes (used to map
Type Permitted Optional to other models;
Values & Units blank is other
models don’t have it)
memorySize This is the size of the Flash disk in MBytes. String Required No analog in either the
M.3100 or the DMTF
CIM.

Business Entity Model – FlashDisk

The FlashDisk Business Entity Model is the same as that for Chip, and is shown in Figure 5PR- 57 above.

TeleManagement Forum 2004 GB922 Addendum 5PR v3.1