Sniasnmbooklet Final

S N I A T E C H N I C A L T U T O R I A L
Storage Network Management

Cummings_i–x_001–105 3/2/04 12:55 PM Page i
SNIA TECHNICAL TUTORIAL

Cummings_i–x_001–105 3/2/04 12:55 PM Page ii
The SNIA Technical Tutorial booklet series provides introductions to storage

technology topics for users of storage networks. The content is prepared by teams
of SNIA technical experts and is open to review by the entire SNIA membership.
Each booklet corresponds with tutorials delivered by instructors at Storage
Networking World and other conferences. To learn more about SNIA Technical
Tutorials, email snia-tutorialmanagers-chair@snia.org.
Cummings_i–x_001–105 3/2/04 12:55 PM Page iii
SNIA TECHNICAL TUTORIAL
Storage
Network
Management
Roger Cummings
SAN Technologist, VERITAS Software
Cummings_i–x_001–105 3/2/04 12:55 PM Page iv
Copyright © 2004 Storage Networking Industry Association (SNIA). All rights reserved.
The SNIA logo is a trademark of SNIA. This publication—photography, illustration, and
text—is protected by copyright and permission should be obtained from the publisher
prior to any prohibited reproduction, storage in a retrieval system, or transmission in any
form or by any means, electronic, mechanical, photocopying, recordings, or likewise. To
obtain permission(s) to use material from this work, please submit a written request to
SNIA, Permissions Department, 301 Rockrimmon Blvd, South, Colorado Springs, CO
80919. For information regarding permissions, call (719) 884-8903.
Photography, illustration, and text incorporated into SNIA printed publications are copy-
right protected by SNIA or other owners and/or representatives. Downloading, screen cap-
turing or copying these items in any manner for any use other than personally viewing the
original document in its entirety is prohibited.
Notice to Government End Users: SNIA software and documentation are provided with
restricted rights. Use, duplication or disclosure by the Government is subject to the restric-
tions set forth in FAR 52.227-19 and subparagraph (c)(1)(ii) of Rights in Technical Data
and Computer Software clause at DFARS 252.227-7013.
Cummings_i–x_001–105 3/2/04 12:55 PM Page v
Contents
Preface vii
About the Author x
Chapter 1 Introduction 1
Chapter 2 Definition of Terminology 5
Chapter 3 A Brief History of Management Protocols 13
Chapter 4 An Overview of Current Management Techniques 17
Chapter 5 An Introduction to Web-Based
Enterprise Management and SMI-S 21
Chapter 6 Profiles of Storage Network Equipment Types 51
Chapter 7 Available Tools and Development Facilities 83
Chapter 8 Future Developments and Goals 89
Chapter 9 Summary 93
Appendix A Applicable Standards 95
Appendix B Recommended Bibliography 101
Publications 101
Web Sites 102
Cummings_i–x_001–105 3/2/04 12:55 PM Page vi
Cummings_i–x_001–105 3/2/04 12:55 PM Page vii
Preface
Development of the Fibre Channel interface in the early 1990s presaged a major
change in computer architecture: the separation of storage peripherals from
processing complexes. This change allowed storage capacities to increase almost
without limit, regardless of the physical limitations of server cabinets and cable
lengths. The impact of this new architecture was not immediately apparent
because the new interface still used the Small Computer System Interface (SCSI)
command sets that had been used by a predecessor interface for many years,
and thus did not require any major operating system changes. The small number
of disks in the initial Fibre Channel configurations could be discovered, managed,
and configured using exactly the same schemes as for that predecessor interface.
As these configurations grew to incorporate hundreds of devices connected
by switches, the load placed on the administrators using these schemes became
intolerable.
With the advent of storage networks, for the first time servers running dis-
parate operating systems (for example, Windows and UNIX) could feasibly be
connected to the same set of storage resources. Again, this advance required little
change in the operating systems themselves, because they continued to be unaware
of each other. The systems were not only incapable of sharing stored information,
but could destroy information in unrecognized formats. To provide the requisite
isolation between noncooperating systems, additional services were introduced
into the storage network, together with new features, such as zoning, that
restricted the connectivity available to each server. In addition, virtualization
began to be widely employed as a mechanism of separating each server’s view of
storage from its actual physical configuration in the network. These new features
inevitably added considerable complexity to the management of storage networks.
Throughout the industry, therefore, new specialist administration groups were
formed to manage storage and its infrastructure, which in turn led to the creation
of applications specifically tailored to support this task.
Such applications, however, proved difficult to develop for two major reasons.
First, storage infrastructure is much more fragmented, and of much less end-to-
end nature, than a comparable network infrastructure. Although network infra-
structure management is complicated by network address translators, storage
networks have virtualization devices that provide both address translation and
complex processing of the information itself. Additionally, storage networks have
bridges that always terminate the SCSI command protocols and may also trans-
late between different transport technologies. Both of these classes of device are
largely opaque to any management technology.
vii
Cummings_i–x_001–105 3/2/04 12:55 PM Page viii
viii Preface
Second, access to and definition of the information required by the applica-

tion is very splintered. Information must be obtained from many different
sources, using several different technologies and architectures, to build up the pic-
ture of how the storage network operates. Many designers of storage network
equipment expose management information and controls via a Web server hosted
on the equipment itself and accessed via a dedicated “Management LAN” con-
nection. Additional information is often accessed from an agent that also runs on
the equipment itself using a standard network management scheme such as the
Simple Network Management Protocol (SNMP). However, the information
returned from such an agent is often unique and does not conform to the mod-
els developed for other types of networking equipment. Those models are ori-
ented to the report static data structures and simple monotonic data value
changes, such as performance counters, rather than the complex state manipula-
tions and dynamic changes encountered in many storage applications. Addition-
ally, many of the existing schemes have difficulty coping with information sources
that constantly change, appear, and disappear, as often happens in a virtualized
storage situation. Further, such network management protocols were designed
before network security and reliability became paramount, and they do not incor-
porate any viable schemes for restricting access to vital control functions.
Some storage network equipment also has functions that are only accessible
via a command line interface, which is accessed via either telnet or a special-
purpose serial interface.
Each new type of equipment challenges application designers because of the
inconsistent provision of management and control facilities. Many of those facil-
ities are designed for direct use by human operators rather than applications,
which involves the application in repugnant practices like “screen scraping.”
Because information obtained from different devices is not consistently presented
or defined, much effort must be dedicated to cross-correlating the information in
order to present a true picture of the state of the storage network. This daunting
task is subject to largely unpredictable change in the face of equipment firmware
changes.
Much effort in management application development is consumed in the
acquisition and correlation of information from a multivendor storage network.
Thus, little time remains to create intelligent high-level functions that will relieve
the burden placed on administrators. Any attempt at significant administration
simplification, therefore, founders on the diversity of access and inconsistency of
information.
The need therefore exists for a set of new definitions that will streamline
the way the industry manages storage networks. Consistent information provided
by every vendor and a single flexible interface are the key requirements. Manage-
ment application developers would then no longer have to integrate incompati-
ble feature-poor interfaces into their products. Equipment developers would no
longer have to push their unique interface functionality at application develop-
ers. Instead, both would be better able to concentrate on developing features and
functions of value to administrators. With these requirements met, the manage-
Cummings_i–x_001–105 3/2/04 12:55 PM Page ix
Preface ix
ment of network storage will become simpler and cheaper than managing an
equivalent amount of storage attached directly to servers. Ultimately, when the
reduced costs for management are delivered, end users will be able to build larger
more powerful networks and to adopt storage networks more rapidly.
The Storage Networking Industry Association (SNIA) is working on defini-
tions to meet the above requirements as part of its Storage Management Initia-
tive (SMI). SMI is based on the Common Information Model (CIM) and
Web-Based Enterprise Management (WBEM) standards as pioneered by the Dis-
tributed Management Task Force (DMTF). By leveraging and extending existing
definitions, application developers will have access to technology proven in other
applications and information definitions that promote the maximum common-
ality among all similar types of equipment, even beyond storage applications.
Early versions of applications using this technology have already been demon-
strated at industry conferences, and the definitions have reached a level of stabil-
ity that is appropriate for widespread deployment.
This booklet is therefore being created at a highly significant time in the devel-
opment of storage network management. The work in SMI to support equivalents
to the basic storage functionality found in other access schemes and information
sources is drawing to a close, and production-grade applications utilizing these def-
initions are being deployed. But the work to incorporate additional definitions nec-
essary to provide significant simplification of the management and administration
of storage networks is just beginning. Substantial work lies ahead, but the foun-
dations necessary to support that work have been put in place. The goal of an intel-
ligent, self-administering storage network, regarded as impossible with predecessor
technologies, is clearly achievable using the definitions SMI has created. The aim
of this work is simple: to remove the administrative burden as a consideration in
the decision to deploy larger and more powerful storage networks.
Acknowledgments
Much of the information contained in this booklet is based upon the manage-
ment tutorials that have been presented at the twice-yearly StorageNetworking-
World conferences by Mark Carlson, John Crandall, and Steve Jerman, who have
devoted much time and energy to leadership roles in the SNIA standardization
effort. Creating the tutorial series was an initiative of the SNIA Education Com-
mittee, and in particular of Paul Massiglia. Steve Peters and Mike Walker have also
created key documents that have been utilized. The SMI Forum within SNIA, and
in particular Roger Reich, its Chairman, has also contributed substantially to the
materials underlying this effort. Educational resources of the DMTF have also
been utilized.
Cummings_i–x_001–105 3/2/04 12:55 PM Page x
About the Author
Roger Cummings is a SAN Technologist at VERITAS Software,

reporting to the CTO. He is a Co-Chair of the SNIA Security
Technical Working Group and a member of the SNIA Techni-
cal Council. Roger has 30 years of development experience with
Logica (UK), Control Data (Canada), and StorageTek, DPT, and
Adaptec (USA). He has been involved in storage standards work
since the early 1980s, most notably as an officer of the INCITS
T11 (Fibre Channel) committee from 1990, and is currently also active in the
INCITS T10 (SCSI) committee and various IETF working groups.
x
Cummings_i–x_001–105 3/2/04 12:55 PM Page 1
Introduction
Storage networks have now become so pervasive, and their configurations so

extensive that it is somewhat difficult to remember their rather humble begin-
nings as loops of fewer than 100 devices. Those early Fibre Channel configura-
tions only provided minor extensions to the parallel SCSI ones that had been used
in server configurations for many years previously, and as such did not represent
a major architectural change. Even when the first switched configurations, con-
taining perhaps 16 ports, became available, the manual configuration techniques
that system administrators had traditionally used still succeeded. But once stor-
age networks with hundreds of ports and thousands of devices appeared, and new
features such as virtualization, zoning, and name services started to play key roles
with attendant additional complexity, the need for new methods of control and
configuration could not be denied.
Vendors initially responded in two ways. First, they provided a management
network interface and a Web-based portal hosted on their equipment, which pro-
vided management information and control features. Second, they provided
agents, which were accessed through that same interface, to allow for integration
with existing network management schemes. Neither of these schemes was par-
ticularly successful. The former presented administrators with a plethora of sin-
gle-vendor management application suites, each with its own graphical user
interface and no common functions and terminology between suites. The latter,
through the use of a management information definition developed at odds with
common practice, did not find widespread support and in any case was some-
what unsuited to the active control methodology desired. As a result, cross-
vendor management applications now need to obtain information from various
sources using multiple interfaces and communication mechanisms to provide sys-
tem administrators with the features they require. This problem has slowed both
the rate at which the applications are developed and the rate at which additional
1
2 Storage Network Management
Management Application
Integration Infrastructure
Object Model Mapping
Discovery Security
Service Protocol Mapping Service
Transport Mapping
SNMP
Command CORBA
Telnet SCSI XML ..... . TCP/IP
RPC Line
C++ C Java Mode DTD ... .
.
Library Socket
Library Library Page FC-GS
Device Types
Tape Library Switch Array Many Others

Vendor
Unique
Object
Models
FIGURE 1–1 Management Information Types
device support can be added. Users have begun to view interoperability of new
devices with their existing management schemes as being as important as, if not
more so than, the interoperability of the “data”interfaces such as SCSI or Fibre
Channel.
These difficulties caused several members of the Storage Networking Indus-
try Association (SNIA) to meet in private session in 2000 to discuss ways to obvi-
ate this bottleneck. They spent two years defining a consistent management
interface suitable for various types of storage network equipment, which became
a specification called “Bluefin” that the group presented to SNIA in mid-2002 as
a basis for further work. The Storage Management Initiative (SMI) that resulted
has leveraged the existing work of the Distributed Management Task Force
(DMTF) to define a single interface sufficiently rich and extensible to support all
of the management functions required in a storage network (see Figure 1–1). The
interface also maximizes the commonality of the information reported and the
controls supported. To introduce that interface, this booklet will:
• Define terminology used in established network management and developed
anew for storage networking
• Provide a brief history of the development of management tools for net-
works, covering both the advent of the Internet and developments in the
Internet Engineering Task Force
Chapter 1 Introduction 3
• Describe current network management approaches, with particular empha-

sis on the Simple Network Management Protocol (SNMP)
• Explain object modeling techniques, with specific reference to the Common
Information Model (CIM) and related DMTF definitions
• Detail specific models of types of equipment found in a storage network
• Introduce tools that can be used in the development of both management
applications and device support
• Highlight the goals of continuing development within the SMI
A summary is found on page 93, and the two appendices contain a list of
applicable industry standards and a recommended bibliography.
The booklet was conceived as an educational resource for the members of
SNIA and other designers, product strategists, and developers within the storage
and SAN industries. SNIA’s mission is “to ensure that storage networks become
efficient, complete, and trusted solutions across the IT community.” Clearly, that
mission cannot be achieved unless the SNIA membership is able to employ the
best technologies, techniques, and practices to create storage networking prod-
ucts. Therefore, an important part of SNIA’s mission is the education of its mem-
bers, and this booklet forms one part of many initiatives in this area. More detail
about SNIA’s mission and current activities can be found on its Web site at
www.snia.org.
The intended audience of this booklet includes people who are storage liter-
ate, but not necessarily familiar with the development of network management.
Thus, although this booklet provides an introduction to a number of manage-
ment architectures, it is not a storage network primer.
Definition of
Terminology
This chapter contains three sections. The first contains established terms from
computer networking, the second terminology specifically related to CIM, and the
third terms associated with the newer discipline of storage networking.
For greater detail or for a more comprehensive dictionary of terms used
throughout storage networking, please see the Web site at www.snia.org.
Established Networking Terminology

ANSI American National Standards Institute. (See http://www.ansi.org.)
ASN.1 Abstract Syntax Notation 1. An ISO standard for transmitting structured
data on networks. ASN.1 separates the syntax of the information from the encod-
ing rules, and a number of different encodings are defined, with the Basic Encod-
ing Rules (BER) being the most common.
Attributes A collection of tags and values describing the characteristics of a
service.
Attribute Reply A reply to an Attribute Request. A part of the Service Location
Protocol.
Attribute Request A request for attributes of a given type of service or attributes
of a given service. A part of the Service Location Protocol.
Backbone The main trunk of a network communication channel.
Bandwidth The difference between the highest and lowest frequencies used for
transmission over a communication channel. Generally, more bandwidth means
greater transmission capacity.
5
BER Basic Encoding Rules. An encoding scheme which allows each data item to
be identified and excoded separately. Roughly corresponds to the Type Length
Value (TLV) scheme used in many protocols.
Communication A process by which information is transferred between at least
two parties.
Communication channel The medium through which information is transmitted.
CSMA Carrier Sense Multiple Access. A contention media-access strategy.
CSMA/CD CSMA with Collision Detection.
DA Directory Agent. In the context of the Service Location Protocol (SLP), a
process that caches SLP service advertisements registered by Service Agents and
forwards the service advertisements to User Agents on demand.
DAAdvert Directory Agent Advertisement. A message by which a Directory
Agent can advertise its presence and capabilities.
DHCP Dynamic Host Control Protocol. An Internet protocol that allows nodes
to dynamically acquire (“lease”) network addresses for periods of time rather than
having to preconfigure them. DHCP greatly simplifies the administration of large
networks and networks in which nodes frequently join and part.
DMTF Distributed Management Task Force. An industry organization that
develops management standards for computer system and enterprise environ-
ments. DMTF standards include WBEM, CIM, DMI, DEN, and ARM. (See
http://www.dmtf.org.)
Ethernet A popular local-area network that uses a contention media-access
method over a bus topology of coaxial cable. Also used to refer to the standard
specified by IEEE 802.3.
Gateway A computer that interconnects disparate types of networks, translating
protocols as necessary. For example, a gateway might connect personal comput-
ers on a LAN to a mainframe computer.
Host Computer that controls network communication in a hierarchical network.
HTTP HyperText Transfer Protocol. A request–reply application-level protocol
widely used on the Internet.
IANA Internet Assigned Numbers Authority. The administrator of identifiers
associated with IETF RFCs.
IEEE Institution of Electrical and Electronic Engineers. A worldwide organiza-
tion incorporating a Standards Association (IEEE-SA), which is an ANSI-accred-
ited standards developer in a number of areas, including LANs and wireless LANs.
(See http://www.ieee.org.)
IETF Internet Engineering Task Force. A large, open international community
of network designers, operators, vendors, and researchers concerned with the
evolution of the Internet architecture and the smooth operation of the Internet.
(See http://www.ietf.org.)
Interconnect element Nonterminal network elements, such as switches, hubs,
routers, and directors.
IP Internet Protocol.
ISO International Standards Organization. A worldwide organization headquar-
tered in Geneva. (See http://www.iso.ch.)
LAN Local-Area Network. A network that is limited to a small geographic area.
MAC Media-Access Control. Portion of the Data Link layer that controls access
to the communication channel.
Network A collection of hardware and software that enables a group of com-
puters to communicate and provide users with access to shared resources.
Network adapter A device that enables a computer to attach to a network.
Network architecture A description of how communication occurs within a spe-
cific type of network.
Network segment An uninterrupted length of the network communication
channel. For example, a single cable between two repeaters, bridges, or routers is
a segment.
OSI Open Systems Interconnection. A protocol stack for network communica-
tion, now largely superseded by TCP/IP.
Protocol A code or set of rules by which communication is initiated, maintained,
and terminated.
Protocol stack A layered set of protocols that work together to provide network
functions. Each intermediate protocol layer uses the layer below it to provide a
service to the layer above.
Receiver The component on the “hearing” end of a transmission.
Repeater A device that connects two network segments to make them work as
one. Repeaters can extend the length of a network beyond the physical limitations
of a single cable.
RFC Request for Comments. Documents published by the IETF.
Ring A network topology that connects network devices in a continuous loop.
Router A device that connects networks and can determine the best path for data
when there are multiple paths.
Scope A set of services, typically making up a logical administrative group.
SA Service Agent. A process working on behalf of one or more services to adver-
tise the services in the network.
SAAdvert Service Agent Advertisement. A message by which a Service Agent can

advertise its presence and capabilities.
SAServer Service Agent Server. A process working on behalf of one or more Ser-
vice Agents to listen on a particular port number for SLP service requests.
Server A process that fields and/or dispatches requests. Honoring a request may
involve more than one server process distributed over one or more computer sys-
tems. The collective server processes that are involved in honoring a request are
known as service providers.
Service Type The class of a network service represented by a unique string (for
example, a namespace assigned by IANA).
Service Type Reply A reply to a Service Type Request. A part of the Service Loca-
tion Protocol.
Service Type Request A request for all types of service on the network. A part of
the Service Location Protocol.
Service Type Template A formalized, computer-readable description of a Service
Type. A part of the Service Location Protocol.
Service URL A Uniform Resource Locator for a service containing the Service
Type name, network family, Service Access Point, and any other information
needed to contact the service. Used in the Service Location Protocol.
SLP Service Location Protocol. An IETF-defined protocol used to dynamically
locate service functions (e.g., printers) in a network.
TCP/IP Transport Control Protocol/Internet Protocol. Two components of the
protocol stack largely used throughout the Internet. Defined by IETF RFCs. TCP
provides a reliable service and runs over IP, which provides a datagram service.
Tunneling A technology that enables one network protocol to send its data via
another network protocol’s connections. Tunneling works by encapsulating the
first network protocol within packets carried by the second protocol. A tunnel
may also encapsulate a protocol within itself (e.g., an IPsec gateway operates in
this fashion, encapsulating IP in IP and inserting additional IPsec information
between the two IP headers).
Transmitter The component on the “speaking” end of a transmission.
UA User Agent. A process that attempts to establish contact with, and retrieve
service information from, Service Agents or Directory Agents.
URL Uniform Resource Locator. The primary address format used on the World
Wide Web. The format of a URL is defined by the IETF in RFC1738.
W3C World Wide Web Consortium. A body dedicated to creating standard def-
initions for the World Wide Web.
WWW World Wide Web. An Internet-wide distributed hypertext system.
XML eXtensible Markup Language. A universal format for structured documents

and data on the World Wide Web. The World Wide Web Consortium (W3C) is
responsible for the XML specification. (See http://www.w3.org/XML/.)
CIM Terminology
Aggregation A strong form of an association. For example, the containment rela-
tionship between a system and the components that make up the system can be
called an aggregation. An aggregation is expressed as a qualifier on the associa-
tion class. Aggregation often implies, but does not require, that the aggregated
objects have mutual dependencies.
Cardinality The number of values that may apply to an attribute for a given
entity. Refer to the Unified Modeling Language.
CIM Common Information Model. An object oriented description of the enti-
ties and relationships in a business’s management environment maintained by the
Distributed Management Task Force. CIM is divided into a core model and com-
mon models. The core model addresses high-level concepts (such as systems and
devices), as well as fundamental relationships (such as dependencies). The com-
mon models describe specific problem domains such as computer system, net-
work, user, or device management. The common models are subclasses of the core
model and may also be subclasses of each other.
Client A process that issues requests for service. Formulating and issuing requests
may involve multiple client processes distributed over one or more computer sys-
tems. The collection of client processes involved in formulating and issuing
requests is known as a consumer.
Consumer A host, identified by HBA WWN or other identifier that is allowed
access to a storage-addressable unit.
Cooperating clients A set of consumer processes that are aware of each other and
are able to coordinate access to (and control of) resources among themselves.
Enumerate An operation used to determine the subclasses, subclass names,
instances, and instance names in the target namespace. If successful, the method
returns zero or more requested elements that meet the required criteria.
Extrinsic method A method defined as part of the CIM schema. Extrinsic meth-
ods are invoked on a CIM Class (if static) or Instance (otherwise). An extrinsic
method call is represented in XML by the METHODCALL element and the
response to that call is represented by the METHODRESPONSE element. See
also Intrinsic method.
Intrinsic method Operations made against a CIM server and a CIM namespace
independent of the implementation of the schema defined in the server. Exam-
ples of intrinsic methods in XML include the IMETHODCALL element and
the response to that call is represented by the IMETHODRESPONSE element.

See also Extrinsic method.
Marshalling The set of operations by which a message is converted into a trans-
fer syntax. In HTTP, requests and replies are marshaled into formatted ASCII text
strings.
Method The name of one (or more) operations(s) performed by an instance of
an object class. Methods are distinguished from operations as follows: A method
is a name for one or more operations that may execute when the method is
invoked. For example, when the method, printSelf(), is called, the operation of
printing the state of the reference object is executed. In most models, a method
is characterized by its name, return type, parameters, completion semantics (asyn-
chronous or synchronous), and side effects (e.g., event generation, message prop-
agation, etc.). Method specifications are language independent.
Namespace A collection of object definitions and instances that are logically
consistent.
Noncooperating clients A set of consumer processes that are independent of
each other and compete for resources. User processes on a multiuser machine are
noncooperating clients with respect to the operating system.
Operation An action executed within the body of a method (also known as pro-
cedure, function, or subroutine). Operations are distinct from methods.
Provider An entity that communicates with managed objects to access data and
event notifications from a variety of sources, such as the system registry or an
SNMP device. Providers forward this information to the CIM Object Manager for
integration and interpretation.
Semantics The meaning or behavior associated with an entity. For example, we
might say the semantics of the method, resync_mirror(), are encoded in the
method name. By contrast, the semantics of the UNIX ioctl() method are encoded
in the command parameter.
Service access point The network address and port number of a process offer-
ing a service.
Service Reply A reply to a Service Request. A part of the Service Location Protocol.
Service Request A request for a service on the network. A part of the Service
Location Protocol.
UML Unified Modeling Language. A scheme for representing the behavior of
complex systems.
WBEM Web-Based Enterprise Management. A set of technologies that enables
interoperable management of an enterprise. WBEM consists of CIM, an XML
DTD defining the tags (XML encodings) to describe the CIM schema and its data,
and a set of HTTP operations for exchanging the XML-based information. CIM
joins the XML data description language and HTTP transport protocol with an
underlying information model, CIM, to create a conceptual view of the enterprise.
XML-CIM Listener A server application that receives and processes XML-CIM
Export Message requests and issues XML-CIM Export Message responses.
XML-CIM Server A server that receives and processes XML-CIM Operation
requests and issues XML-CIM Operation responses.
Storage Networking Terminology

Active Zone Set The Zone Set that is currently activated. Only one Zone Set may
be activated at any time.
Fabric Any interconnect between two or more Fibre Channel N_Ports, includ-
ing point-to-point, loop, and switched fabric.
FC Fibre Channel. A serial interface standard defined by INCITS Committee T11
(see http://www.t11.org) that uses both optical and electrical media.
HBA Host Bus Adapter. A card that contains ports for host systems.
Hub An interconnect element that supports a ring topology.
INCITS International Committee for Information Technology Standardization.
Initiator A device that transmits SCSI commands.
Loop A Fibre Channel interconnection scheme that does not require a switch.
LU Logical Unit.
LUN Logical Unit Number. The SCSI identifier of a logical unit within a target.
LUN mapping The process of creating a disk resource and defining its external
access paths, by configuring LUs (Logical Units) from the disk array logical disk vol-
umes, either by grouping them as a single larger LU or by creating partitions. The
Logical Unit Number is then mapped to an external descriptor (for example: a SCSI
Port, Target ID, and LU Number). An LU may be mapped for access from multiple
ports and/or multiple target IDs, providing alternate paths for nonstop data avail-
ability. LUN mapping is a necessary task to be able to export the LUN to the fabric,
server, etc. It can be done independently of any knowledge of the intended use of
the LUN. Only LUNs that are exposed via a port are available for access.
LUN masking The process of configuring software in storage network nodes to
determine which hosts have access to exported drives. LUN masking can be either
server-based address masking or storage-based port mapping. See also Port mapping.
N_Port Node Port. An addressable entity connected to an I/O bus or network.
Used primarily to refer to computers, storage devices, and storage subsystems. The
component of a node that connects to the bus or network is a port.
Out-of-Band Transmission of management information for Fibre Channel com-

ponents outside of the Fibre Channel network, typically over Ethernet.
Port A connection point for links.
Port mapping A storage subsystem function that defines which hosts have access
to exported drives. This configuration authorizes specified server HBA WWNs to
access the secured LU while preventing other unauthorized servers/hosts from
either seeing the secured LU or accessing the data contained on the secured LU.
See also LUN masking.
SAN Storage Area Network. A network whose primary purpose is the transfer of
data between computer systems and storage elements.
SCSI Small Computer System Interface. A parallel electrical interface standard
defined by INCITS Committee T10. (See http://www.t10.org.)
SCSI Command A request describing a unit of work to be performed by a device
server accessed through a target.
Soft Zone A Zone consisting of Zone Members that are made visible to each other
through Client Service requests. Typically, Soft Zones contain Zone Members that
are visible to devices via Name Server exposure of Zone Members. The fabric does
not enforce a Soft Zone. Note that well-known addresses are implicitly included
in every Zone.
Target A device that receives and executes SCSI commands and generates status
resulting from those commands.
Virtual Disk A set of disk blocks presented to an operating environment with
disk-like storage and I/O semantics.
Volume Set Synonym for virtual disk.
Zone A collection of Zone Members. Zone Members in a Zone are made aware
of each other, but not made aware of devices outside the Zone. A Zone can be
defined to exist in one or more Zone Sets.
Zone Member An N_Port (or NL_Port) to be included in a Zone, as specified by
its Zone Member Definition. N_Ports at well-known addresses shall not be spec-
ified as Zone Members.
Zone Member Definition The parameter by which a Zone Member is specified.
A Zone Member may be specified by a port on a switch (specifically, by
Domain_ID and port number), the device’s N_Port_Name, the device’s address
identifier, or the device’s Node_Name.
Zone Set One or more Zones that may be activated or deactivated as a group.
Zone Set Name The name assigned to a Zone Set.
Zone Set State The state of a Zone Set, which may be either activated or deactivated.
A Brief History
of Management
Protocols
The roots of the network management protocols that are in common use today
can be traced back to developments in the late 1980s. Prior to that time, network
management had typically been performed using low-level signaling techniques
to send special control information. Receipt of this information would cause
receiving hardware to cease normal operation and enter a special diagnostic mode
in which it responded to commands contained in the information. This approach
worked well in homogeneous networks, which used the same interface technol-
ogy throughout. However, with the advent of protocol stacks and abstraction of
the lower level network characteristics, networks began to support multiple dif-
ferent types of interface technology, which meant that a different approach was
necessary in order to support network-wide management. At this point, both the
TCP/IP and Open System Interconnect (OSI) protocol stacks began to define net-
work management protocols that operated at the application layer. This change
in approach had both advantages and disadvantages. The major advantage was
that management could now be performed using the same tools at any point in
the network; the major disadvantage was that management was only possible
when the entire protocol stack was active and working correctly.
The move to an application-layer approach caused the creation of a
client/server architecture that is still in widespread use (see Figure 3–1). A man-
agement client that executed under the user account of the network administra-
tor on a host computer communicated with management servers resident on each
of the other items of equipment in the network that required management. In
early networks, the servers tended to reside on only two types of “other equip-
ment” hosts, and computers acting as gateways between multiple physical network
segments. In fact, one of the earliest definitions for the protocol between such
clients and servers was the Internet Engineering Task Force’s (IETF’s) Simple
Gateway Monitoring Protocol, defined in November 1987. This protocol intro-
duced a number of approaches that are still evident in network management pro-
13
S S
S
S
gateways
C
S
S
C Management Client
hosts S Management Server
Unmanaged System
FIGURE 3–1 Client/Server Architecture
tocols. It adopted Abstract Syntax Notation 1 (ASN.1) and its Basic Encoding
Rules (BER) to define the contents of the protocol data units exchanged between
the client and the server, rather than any fixed format. Three of the primitive data
types defined by ASN.1 were used: octet (byte) string, integer, and unique iden-
tifier. The information upon which the protocol operated was defined only in
terms of variables identified by an octet string name, and able to contain either
an integer or octet string value. Three general variables, and two sets of nine vari-
ables each, instrumenting network interface performance and IP addressing/rout-
ing, were all that was included. The protocol was defined in terms of primitive
handshake operations to read and set the values contained in those variables, with
a minimal number of unsolicited messages for traps. There were no “imperative”
commands with more specific functions like “disable interface”; these were viewed
as being unnecessarily specific. Such actions were expected to be triggered by set-
ting a variable to a specific value. The protocol was also designed to operate over
an unreliable, connectionless transport. The encoding rules specified that each
variable be encoded as a type, a length, and a value.
An effort contemporary with the Simple Gateway Monitoring Protocol
(SGMP) in the IETF, called the High-Level Entity Management system, also estab-
lished a precedent by having its protocol, control language, and information vari-
ables defined in separate documents.
Chapter 3 A Brief History of Management Protocols 15
When a successor protocol to Simple Gateway Monitoring Protocol was

defined in 1988, it followed this convention of having the protocol, called the Sim-
ple Network Management Protocol (SNMP), the information structure and trans-
fer syntax (identification and encoding), called the Structure of Management
Information (SMI), and the definition of the management variables themselves,
called the Management Information Base (MIB), defined by separate documents.
These documents have undergone minor modification and correction over the
years, but this set, now generally called SNMP, is still in widespread use through-
out the network industry. The latest versions are listed in Appendix A.
SNMP defined new primitive types of IPaddress, counter, gauge, timeticks,
and opaque in addition to the ASN.1 primitives integer, octet string, and null, but
in fact the new types are merely one of those ASN.1 primitives with specific value
restrictions. SNMP also went beyond the concept of individual “scalar” variables
to define columnar or list variables that use the ASN.1 Sequence constructor type
and in which individual values are aggregated and each value is identified by an
index value in addition to the unique object identifier. List variables are also then
able to be conceptually aggregated into two-dimensional tables using the
Sequence construct and an additional index. The list and table constructs are
regarded as “conceptual” because they are only defined to simplify access, and do
not include any definition of the relationships between the variables that they con-
tain. SMI defined a variant of the ASN.1 object-type macro that is the basis of all
objects defined in the MIB. The get and set operations of the Simple Gateway
Management Protocol are significantly extended with the addition of a “get next”
request, which can be used to traverse tables without the unique object identifier
of every object having to be known. The MIB definition also contains many more
variables related to interfaces, address translation, routing, and additional types
of protocols.
While SNMP was being developed in the IETF, a comparable framework was
being created by the International Standards Organization for its Open System
Interconnect (OSI) protocol stack, called the Common Management Information
Services (CMIS) and Protocol (CMIP). A version of the protocol defined to oper-
ate over TCP/IP, called CMOT, was also being defined in the ITEF. The two groups
initially collaborated closely, and a common MIB definition was agreed upon.
However, this agreement did not endure, and a MIB-II definition was introduced
that no longer supported both protocols. MIB-II clarified the constructs, intro-
duced the concept of “deprecated” objects, defined a specific Index clause, and
gave explicit guidance as to how rows could be added to or deleted from an exist-
ing conceptual table. It also significantly extended and amended the definition of
the specific variables. A standard related to MIB-II also extended the definition of
the object-type macro.
After adoption of MIB-II, the development of SNMP took a number of dif-
ferent and ultimately fruitless directions, including the definition of secure vari-
ants, v2 with and without security, and other experimental approaches. The
reasons for this, and the details involved, are beyond the scope of this document.
Suffice to say that a widely agreed-on set of SNMP version 2 documents did not
appear until the late 1990s, and did not become full Internet standards until 1999.
SMIv2 is more restrictive than SMIv1 in a number of areas, including restriction
of the maximum length of identifiers to 64 octets, and disallowal of the use of
hyphens in identifiers (although this still widely occurs). SMIv2 introduces an
additional syntax called counter64, but RFC2576 gives explicit rules defining how
this should be handled in situations where multiple versions are employed in the
same system. Any variables in the counter64 syntax are reported as a “noSuch-
Name” exception to an SMIv1 client, and any Request from such a client that con-
tains a variable binding with the counter64 syntax is discarded and a parse error
logged.
SMIv3, incorporating both a user-based security model and view-based
access control, was completed in 1999 but has not yet gone beyond Draft Stan-
dard status at the IETF.
The history described above, therefore, is one of incremental extension and
clarification since the move to application-level management in the late 1980s.
The “data model” has remained largely unchanged in that time, and still consists
of independently specified variables collected into groups for ease of access only.
Relationships and dependencies between the variables are still expressed only in
the text of descriptions, and therefore cannot be analyzed or checked by tools such
as compilers. Although this approach is eminently suitable for the job for which
it was first envisaged, namely the collection of statistics from gateways, it has dis-
tinct limitations with respect to the overall management of today’s dynamically
changing networks.
An Overview of
Current Management
Techniques
This chapter describes the techniques presently being used by managers of net-
works in general, and storage networks in particular. The current state of the art
is defined. Standardized information definitions presently used with the proto-
cols defined in the previous chapter are also described in detail.
“State of the Art”

In July 2002, the 54th meeting of the Internet Engineering Task Force was hosted
by the WIDE project in Yokohama, Japan, which marked the first time that the
IETF had met in Asia. During one of the evening plenary meetings, a report was
given on a network administration workshop held in Reston, Virginia, for an
invited audience of very experienced architects and managers. The conclusions
from that workshop were sobering: Most sites used SNMP only for collecting
router and interface statistics, and largely employed locally developed PERL
scripts or command line interface approaches for configuration control and
device management. The subsequent discussion revealed that this approach was
widespread throughout Asia and Australia, as well.
A number of reasons were given for the pervasiveness of this approach. Many
network managers felt that equipment manufacturers did not implement MIBs
in a timely manner, and perceived MIBs as hard to implement. The managers also
reported that manufacturers were still largely shipping SMIv1 MIBs to gain the
widest applicability for their efforts, and many were still unwilling to commit
additional effort to support SMIv2. However, those same managers did feel that
SNMP would continue to be the scheme of choice for network monitoring for the
foreseeable future, and recommended that IETF both continue to develop the
technology and simplify the process for creating a MIB.
The workshop also noted the emergence of the HyperText Transport Proto-
col (HTTP) as a management information transport. Many equipment vendors,
17
it seems, are making management data and configuration control facilities avail-
able via HTML pages hosted on the equipment itself; apparently they believe that
this is an easier task than writing a MIB and creating an SNMP agent! Such pages
are by definition created for a human to view and manipulate, but requiring a
manager to create a separate connection with each piece of equipment is oner-
ous. There are also no standards for such pages, and each therefore tends to be
very different and reflect the manufacturer’s branding, thus requiring the network
manager to climb a learning curve for each new equipment type. Use of the pages
as a source of information for management applications is also problematic. The
process of extracting the information from the received HTML code is known by
the graphic term “screen scraping,” and it tends to be unstable in the face of equip-
ment firmware changes. At one end of the stability spectrum, simple design
changes to the pages that would have no effect on the viewing manager can lead
to the information being extracted erroneously. At the other end, even major
changes to the information displayed by the pages can go undetected, again lead-
ing to erroneous information. As HTML is a rendering technology, it contains lit-
tle information about the type of information (integer, string, etc.) being
displayed, forcing the application designer to make assumptions. Because of these
significant limitations, the workshop recommended that the IETF not produce
any management standards based on HTTP.
The results of the workshop and the discussion reported above emphasize the
fact that current management practices rely heavily on specially developed tools
and on SNMP, and will continue to do so for the foreseeable future. The remain-
der of this section therefore addresses SNMP as it is used in a wide variety of cur-
rent management tools. The first section deals with use of IETF standard MIBs
and the second with use of a nonstandard MIB that is nevertheless widely
employed in the storage networking industry.
IETF Standard MIB Usage

When SNMP was first developed, it was assumed that there would be a single
monolithic MIB definition containing all the parameters that would be used in
all equipment types. However, implementation experience showed that a differ-
ent approach was needed for scalability and to support parallel development, and
therefore in the MIB-II development (RFC1213) in 1991, described above, the
monolithic approach was abandoned in favor of a number of “foundation” MIBs
defined on a functional basis. The intention was that equipment manufacturers
would then create their device-specific MIBs as extensions of the standard MIBs.
The foundation MIBs currently recommended by IETF MIB experts for use
in storage and storage network applications are as follows:
Chapter 4 An Overview of Current Management Techniques 19
1. SNMPv2 MIB (RFC3418)

The SNMPv2 MIB contains a set of variables referenced by many other MIBs.
Included in these variables are a display string that provides a basic descrip-
tion of the object, an object identifier, the number of time ticks since the
object was last initialized (uptime), an administratively assigned name, con-
tact details of a responsible person, physical location information, and some
indication of services provided. The majority of this information is provided
in textual information that cannot be parsed by a management application.
2. Interfaces MIB (RFC2863)
The Interfaces MIB contains media-independent interface information
designed so that any network interface can be managed in an identical man-
ner through these objects. The MIB incorporates a large table structure, called
the iftable, designed to be able to distinguish multiple layers below the IP
layer, and incorporates variables to manage character-, packet-, and bit-based
technologies using both fixed- and variable-length packets. A separate table,
the ifstacktable, then defines how these layers relate in a stack, and an ifalias
table resolves naming. Limited support for enumerating the network inter-
faces in a system is provided by walking the iftable. A standard MIB for a spe-
cific interface type is then created as an extension to the tables of this MIB,
and a vendor-specific interface MIB further extends the same tables. Creat-
ing those MIBs is therefore likely to be a very complex task.
3. Entity MIB (RFC2737)
The Entity MIB contains information associated with both logical and phys-
ical managed entities, with the latter type being defined with reference to a
containment tree defining exact component locations. This MIB introduces
the concept of a naming scope, to allow multiple agents to coexist in a man-
aged system, but there is no provision for discovering multiple scopes. A map-
ping table is provided to link physical information in this MIB with objects
identified in other standard MIBs. There is very little setable information
defined by this MIB. There is also no straightforward method of discovering
which variable bindings are stored in nonvolatile storage.
4. Host Resources MIB (RFC2790)
The Host Resources MIB contains variables related to the management of host
computers. Variable groups for storage, devices, running software and its per-
formance, and installed software are included, but each group is defined inde-
pendently and little information about their relationship is included.
Other frequently referenced MIBs include the SNMP Notification MIB
(RFC3418), containing variables that define which SNMP notifications (traps) are
to be sent to which systems, and the Notification Log MIB (RFC3014), contain-
ing variables that provide access to the history of generated notifications.
There is also a standards track MIB that applies specifically to Fibre Chan-
nel–based systems. Despite its name, the Fabric Element MIB (RFC2837) includes
information that also applies to FC hosts. It incorporates variable groups that

address the configuration of an element and its ports, the capability of the com-
plete element and each port, the physical and log-in status of those ports, the
parameters established at each port, the errors detected by each port, and statis-
tical data suitable for deriving performance information. This MIB does not ref-
erence or extend the tables in either the Entity MIB or the Interfaces MIB. Because
of this, it is shortly to be superseded by a new Fibre Channel Management MIB
based on foundation MIBs.
Note that for the reason described in the introduction, even though most of
the ongoing MIB development related to SNMP is created using the SMIv2 defi-
nitions and based on the SMIv2 MIBs described above, many companies trans-
late their MIBs to comply with SMIv1 and only ship them in that form. Although
the resultant MIBs are functionally equivalent, the translation involves convert-
ing some machine-readable information to descriptive text, which therefore
decreases the information that can be parsed and verified by a compiler or an
accessing application.
Nonstandard MIB Commonly

Used in Storage Network
The Fibre Alliance MIB was created by an industry group and was intended to
include all of the variables needed for managing a Fibre Channel system. The MIB
also addresses management of switches, devices, ports, and software on servers. It
does not reference any other IETF MIBs, and therefore does not reuse any exist-
ing definitions. Three revisions of the MIB were recently documented by T11 in
an INCITS Technical Report (TR-332:2003) as a service to the industry to docu-
ment existing practice. The introduction to the TR recommends that new designs
use the Fibre Channel Management MIB under development in the IETF in pref-
erence to those in the TR.
Summary
The new approach to MIB development has taken some steps toward ensuring
the consistency of similar information reported by all types of managed equip-
ment, but at the cost of considerable design complexity. Many separate docu-
ments, in various stages of development, now have to be consulted by a vendor
in the course of creating a MIB for a new product. And despite the wealth of infor-
mation available, there is still relatively little information that can be retrieved
about the relationship between various parts of a system, and few features that
can be actively configured. The new approach to MIB definition has done little to
address the fundamental limitations of the modeling technique, and the new
“security” features incorporated in SMIv2 have not yet led to network managers
being willing to abandon their site-specific configuration tools, which obtain con-
siderable security by their obscurity.
5
An Introduction to
Web-Based Enterprise
Management and
SMI-S
This chapter provides a primer on both SNIA’s Storage Management Initiative

(SMI) and the technology on which it is based, the Distributed Management Task
Force’s Web-Based Enterprise Management (WBEM). The primer begins with a
historical timeline of developments in the two organizations, followed by explo-
ration of the fundamentals of WBEM and the extensions defined by SMI. A set
of “structured” terminology definitions is contained in this chapter as a comple-
ment to the earlier definitions. The richer and more extensible information model
that underpins this work is contrasted with the more limited model described in
the previous chapter.
Background
This section describes the sequence of activities in DMTF and SNIA that led to the
formulation of the WBEM and SMI programs. The motivations of the pioneers in
both cases are explored, and the influences of previous work traced. Because little
documentation exists of some of the early activities in both cases, some of the
information contained here is the result of conversations between participants and
the author, who takes full responsibility for any incorrect representation.
DMTF
The technology on which WBEM is based had its genesis in the mid-1990s
at Microsoft. Dissatisfaction with both the fidelity of existing management
information definitions and the way in which that information was transported
led to a desire to define a more scalable and resilient scheme that would be capa-
ble of supporting enterprise-grade management of heterogeneous systems by
21
distributed means. An initial set of partners was then recruited, including Cisco,
Compaq, and Intel, and two separate specifications were placed in the public
domain in 1996. These were HyperMedia Management Schema (HMMS) and
HyperMedia Management Protocol (HMMP). In addition, the concept of a
HyperMedia Object Manager was introduced as an aggregation point for man-
agement data from multiple devices, which was capable of consistent presenta-
tion of that information to an operator or management application.
Prior to 1996, the DMTF was known as the Desktop Management Task Force,
and the organization was focused on producing standards for the management
and inventory of desktop PCs, mostly based on the Desktop Management Inter-
face (DMI) specification. However, after agreeing to work on HMMS, the orga-
nization changed both its direction and its name, becoming the Distributed
Management Task Force instead. The name of the schema also changed, becom-
ing the Common Information Model, and two major revisions of its specification
were released in 1997 and 1998.
The original intention was that HMMP would be standardized by the IETF,
but after an extended period during which the original proposal made no progress
in that organization, the work was redirected to the DMTF. At this point, the whole
initiative gained a new name, becoming Web-Based Enterprise Management
(WBEM). WBEM added a third standard, a representation and serialization of the
schema to simplify transport; the three resulting standards are described in detail
in the following sections.
Three characteristics of the developments described above have ultimately
become most important in enabling the success and widespread deployment of the
technology. First, leverage of the HyperText Transfer Protocol (HTTP) widely used
in Web applications as a transport mechanism instead of a proprietary transport
protocol allowed WBEM to take advantage of a sizable existing infrastructure. Sec-
ond, use of a multilevel architecture in which multiple Object Managers (see
below) can perform aggregation and some other processing on management infor-
mation before it is presented to an application provided considerable scalability.
Finally, and most importantly, CIM employs a much richer modeling
approach than earlier technologies, which only represented independent variables
arranged in tables. CIM is based on a schema that both employs object-oriented
techniques and makes use of several common modeling structures called “design
patterns” that were found in the mid-1990s to reoccur in many systems. A schema
has been defined as “an internal representation of the world; an organization of
concepts and actions that can be revised by new information about the world.”
CIM’s schema contains objects that represent the characteristics of the entities
being managed by the application, whether they are a physical entity such as a
switch, a logical entity such as a software package, or a file. In addition, CIM also
models the complex and multilevel relationships between these entities. This
allows the application to traverse the schema discovering types of objects and the
specific names and identifiers of the instances of those objects, just as it would if
it was accessing the equipment represented by those objects via “in-band” means.
Chapter 5 An Introduction to Web-Based Enterprise Management and SMI-S 23
SNIA
The SNIA SMI is the ultimate result of a private meeting of a number of SNIA
member companies held in 2000. The meeting was called as a result of several
management software vendors’ frustration with the level of effort and cost they
were expending to support new devices and obtain reliable connectivity and inter-
operability. These difficulties resulted in a high cost of ownership and an extended
“time to market” for new versions as viewed by customers. The group agreed to
investigate methods by which they could pool resources to address those prob-
lems, and the project that became known as “Bluefin” was born.
The group’s initial approach was to try to define a common hardware abstrac-
tion layer that they could all use, plus a clearly defined interface between that layer
and their applications. However, as work proceeded in that direction it appeared
increasingly problematic. The common layer would need to be supported by the
group, probably in open source fashion, and a new instrumentation “agent” would
still need to be hosted on each of the devices being managed. The direction would
also require completely new definitions and interface protocols, and the combi-
nation of all of these issues caused the group to investigate existing technologies
that could be extended and leveraged. At that point CIM came to the fore.
Adopting CIM as the basis for Bluefin seemed to the group to offer several
advantages. CIM offered a rich modeling approach, with a number of existing
proven definitions that could be leveraged, and a defined method of incorporat-
ing definitions from older management information models (e.g., SNMP MIBs).
CIM even already contained some basic definitions for managing various types
of storage network equipment, although there was early agreement that they
would require substantial rework and amplification. The approach was extensible
in that vendor-unique information and controls could be added in a manner that
did not negatively impact the overall model. CIM already had definitions in place
that would allow a single piece of instrumentation to provide support for multi-
ple different management applications. The DMTF had already defined a method
of data encoding for transmission (an XML representation) and a communica-
tions protocol (using HTTP as a transport), which were regarded as strengths by
the group because of their separation from the model itself and their basis in pop-
ular, existing standards. The architecture underlying CIM was scalable enough to
handle the required enterprise-class applications and incorporated the notion of
proxy agents to simplify support for equipment instrumented for previous man-
agement schemes such as SNMP. And finally, because CIM was an existing tech-
nology, some SAN equipment was already being instrumented and some server
platforms were already enhanced to participate in CIM.
Having made the decision to adopt CIM, the work went forward, and in
spring 2002 the participant in the Bluefin project presented the work to SNIA,
under an agreement that it be completed and offered for industry standardiza-
tion. SNIA named this work the SMI, and reorganized its Technical Working
Groups around this effort. SNIA also forged an alliance with the DMTF under the
terms of which SNIA would be the center of all storage-related work, but any
changes required to the CIM schema and related definitions would be handled by
submitting Change Requests to the DMTF via an established procedure.
CIM
CIM-XML CIM-HTTP
Transport Encoding Access
FIGURE 5–1 The Triumvirate
Twelve months later, at the StorageNetworkingWorld Spring 2003 conference,

SNIA released to the public the SMI Specification (SMI-S), Revision 1.0. At the
same event, a heterogeneous multivendor storage network was demonstrated that
contained 20 instrumented devices communicating with 18 storage management
applications using SMI-S, a total of 150 points of interoperability. Significant feed-
back was received on the release, and development work continued, resulting in
the release of Revision 1.0.1 in September 2003. This is by no means the end of
the development, with work expected to continue for several years so as to add
new functionality (see Chapter 8) and optimize existing definitions as a result of
implementation experience.
The SMI-S documentation does not itself contain the definition of the infor-
mation presented by equipment to management applications, or the protocols by
which that information is communicated between the two entities. Instead, it ref-
erences the WBEM specifications produced and maintained by the DMTF for that
information. These specifications are introduced in the following section. What
SMI-S does define is subsets or “profiles” of the CIM schema that are appropri-
ate to each of the different types of equipment found in a SAN, and “recipes,”
which are snippets of pseudo-code that illustrate the use of a profile to fulfill a
specific management function. The profiles will be described in detail in the fol-
lowing chapter. SMI-S also goes beyond the WBEM definitions in the areas of
naming and discovery; these areas are described in the section entitled SMI-S
Additions. The structure of the CIM schema is described in some detail.
WBEM Fundamentals
The DMTF WBEM initiative is based on three major standards, as shown in Fig-
ure 5–1. These standards are described in the following sections, after some com-
mon terminology is established. The terms are listed in a logical or topological
order rather than alphabetically.
Directory
Server Client
Directory User
Agent 0...n Agent 0...n
SLP
TCP/IP
CIMxml
CIMxml
CIM
CIM operations
operations over
over http http
TCP/IP
TCP/IP
SA Service Agent (SA) SA Object Manager

Agent
Agent
0…n Device or
0...n Provider
Provider
Subsystem
1 1 0...n
0Ön
Proprietary Proprietary n
1
Embedded
Device or
Subsystem Model Device or
Device
Subsystem
Proxy Model Proxy Model
FIGURE 5–2 Reference Model
Terminology
WBEM is based on a client/server architecture, as shown in the reference model
in Figure 5–2. In this application, the terms are defined as follows:
A WBEM Client is an entity that extracts information from managed equipment
and processes that information for submission to an operator, to serve as input
to a decision-making system, or for consumption by a special-purpose applica-
tion such as a volume manager. In terms of the underlying transport, a WBEM
Client is often called a “Requestor.”
A WBEM Server is an entity that provides a WBEM service. A WBEM service may
be provided by one or more types of Agent. In terms of the underlying transport,
an Agent is often called a “Responder,” because it provides information related to
the managed equipment in response to a request from the WBEM Client.
An Embedded Agent is an Agent that executes on the equipment being managed.

A Proxy Agent operates on one piece of equipment and uses a proprietary or
legacy scheme to extract information from another piece of equipment, which is
being managed.
An Object Manager is an entity capable of performing some processing on infor-
mation received from multiple managed pieces of equipment. It may also support
the persistence of information. An Object Manager typically supports richer func-
tionality than the other agent types defined above. An Object Manager may also
be able to offload the processing of some functions, such as enumeration, from a
WBEM Client. Typically, an Object Manager does not incorporate support for any
specific devices, but defines an interface into which multiple Providers may be
“plugged.”
A Provider is a entity that can be installed in an Object Manager to support a
specific type of device.
The CIM schema is based upon object-oriented modeling techniques that are
based on the mathematical concepts of set theory and classification theory. In the
schema:
• Classes are the definition of types of models.
• Properties (sometimes known as attributes) define the characteristics of a
class, e.g., the capacity of a storage volume class.
• Methods (sometimes known as functions) define the behavior of a class (such
as a format function on a physical disk class).
• Qualifiers define implementation-specific information on how a class, or its
properties and methods, might be used, provided, or displayed.
• Instance is a specific realization of a class, generally defined by a unique iden-
tifier or unique set of properties.
• Object in CIM terms may be a class, instance, property, method, or qualifier.
Referring to both a class and an instance of a class as an object is a duality
that is common in much object-oriented literature.
• Subclasses are definitions of subtypes of a class, i.e., in a hierarchy. Rather
than defining a physical relationship, the hierarchy defines specialization,
with the most general objects at the top of the hierarchy. The relationship
between a class and its subclasses is one of either inheritance or aggregation.
Inheritance defines a subclass as more specific than its class, with additional
specialized properties and methods. Aggregation defines a class that is a col-
lection of subclasses, based on certain criteria.
• Associations are a mechanism for defining an explicit mapping between
classes. CIM Associations are themselves classes with defined properties that
also exist in a class-subclass hierarchy. An important characteristic of CIM is
that the definition of a new association referencing a class does not modify
that class.
Message Syntax: XML-CIM Encoding

Object Model Independence
Message Semantics: CIM operations over HTTP

Message Protocol Independence
Messaging Protocol: HTTP
Transfer Protocol Independence
Transfer Protocol: TCP/IP
FIGURE 5–3 Transport Stack
• CIM Namespace is a subdivision of an implementation that contains a spe-

cific set of instances and is addressed in an implementation-specific manner
using the part of a Uniform Resource Locator (URL) that precedes the iden-
tification of a class and instance.
• Intrinsic method is a method that executes against a Namespace and per-
forms functions such as reading and setting properties, creating, deleting, and
enumerating both classes and properties, performing queries, and traversing
the schema via associations.
• Extrinsic method is one defined by a specific class in the schema and exe-
cuted against an instance of that class.
The Triumvirate
The three major specifications that comprise WBEM are described below. The
standards define:
1. A communications protocol—CIM operations over HTTP
2. An encoding scheme—representation of CIM in XML
3. An object-oriented schema—CIM
These are used in a transport stack as shown in Figure 5–3. Note that there
is good functional separation between the first two of these standards and the
third: Another communications protocol or encoding scheme can be defined with
no impact on the schema.
Note that the CIM schema is not defined by a specification, but rather by a
set of UML class diagrams and an associated structured textual description file
called the Managed Object Format (MOF). Specification 3 above only defines the
notation for the UML diagrams and the syntax of the text file. The schema is there-
fore defined in a subsequent section after the three specifications have been intro-
duced.
HTTP M-POST or POST (XML Entity)
Client HTTP Response (XML Entity) Server
Repeat...
FIGURE 5–4 Request/Response Protocol
CIM Operations over HTTP

The specification for CIM operations over HTTP defines how messages are
exchanged between WBEM Clients and Services using either HTTP 1.0 or 1.1.
The specification consists of three major sections, namely:
1. A syntax capable of supporting a single requestor or multiple requests in a
single HTTP POST or M-POST message, and a single response or multiple
responses in a single HTTP Response message
2. A small set of extension headers, defined in the usual “namevalue” format
and in accordance with IETF RFC2274, that give some visibility into the con-
tents of the message (if the M-POST message is used, the extension headers
are declared using the namespace defined by the “man” extension header)
3. A set of intrinsic method definitions, each with associated parameters, col-
lected into a hierarchy of functional groups with each level of the hierarchy
appropriate for a different class of implementation
Note that the majority of the body of the message referenced in 1. above is not
defined in this specification but rather in the XML representation specification in the
following section. Either an extrinsic or an intrinsic method can be identified in a
Request, but only intrinsic methods are defined in this specification.
The protocol is a request/response type, in which a Request is sent in an M-
POST or POST message from a WBEM Client to a WBEM Server, which replies
with a Response message (see Figure 5–4).
The specification describes the use of basic and digest HTTP authentication,
but does not require their use.
Table 5–1 contains an overview of the most commonly used extension head-
ers and their functionality.
Table 5–2 contains an overview of the most commonly used intrinsic meth-
ods, their definitions, and their parameters.
Table 5–3 lists the functional groups into which the intrinsic methods are
collected.
TABLE 5–1 Extension Headers
Name Identifies Values

CIMOperation Type of message in body (invokes operation MethodCall
in target Namespace or presents status) MethodResponse
CIMExport Type of message in body (communicates MethodRequest
information about Namespace or element) MethodResponse
CIMMmethod Name of method to be invoked MethodName in safe format
CIMObject Extrinsic Method: Class or Instance ObjectPath
Intrinsic Method: Namespace
CIMError CIM-specific diagnostic information Unsupported-CIM-version,
etc.
CIMProtocolVersion Version of mapping being used by sender Digit.Digit (e.g., 1.0)
Representation of CIM in XML (XML-CIM)

The specification for the representation of CIM XML defines a grammar that can
be used to represent both CIM declarations (defined as classes, instances, or qual-
ifiers) and the bodies of the messages defined in the CIM mapping to HTTP ref-
erenced in the previous section. A single Document Type Definition (DTD)
defines the grammar and is available from the DMTF.
The grammar is not based on the structure of the CIM schema; rather, it is
based on a metadata structure defined in the CIM specification. In other words,
the names of the XML tags do not reflect the names, properties, and methods of
CIM classes and identification of instances, but rather a set of metadata that can
be used to describe those classes and instances. The names, properties, methods,
etc., of a CIM class are then mapped to values of those metaschema tags. This
approach has the considerable advantages of allowing a single compact DTD to
be used to validate the entire schema, and decoupling the definitions contained
in that DTD from changes in the definitions contained in the schema.
Every XML structure is either a set of object declarations or a message defi-
nition. The root element of each document is the CIM element, which takes
an attribute that distinguishes between the two uses. The other XML elements are
collected into groups, the names of which are listed below, together with a brief
definition of their purpose and example members.
1. Declaration XML Elements
This group is concerned with the declaration of CIM objects. This group
includes elements that define an object name and path, and also a qualifier
and its scope.
TABLE 5–2 Intrinsic Methods
Method Name Function (all relative to Mandatory (Optional)

target Namespace) Parameters
GetClass (GetInstance) Returns single CIM class ClassName (InstanceName),
(instance) PropertyList
DeleteClass (DeleteInstance) Deletes single CIM class ClassName (InstanceName),
(instance) PropertyList
CreateClass (CreateInstance) Creates single CIM class NewClass (NewInstance)
(instance)
ModifyClass (ModifyInstance) Modifies single CIM class ModifiedClass (ModifiedIn-
(instance) stance)
Enumerate Subclasses Returns zero or more classes {ClassName, LocalOnly,
(Instances) of a class that meet criteria IncludeQualifiers,
IncludeClassOrigin
(PropertyList for instance)
all optional}
Enumerate Subclass (Instance) Returns zero or more names of {ClassName optional}
names of a class classes (instances) that meet
criteria
Enumerate associators (refer- Returns zero or more objects ObjectName (role, PropertyList,
ences) to an object that are associated to a source etc., optional)
(refer to a target) object
Enumerate names of associators Returns zero or more object ObjectName (role, PropertyList,
(references) to an object names that are associated to a etc., optional)
source (refer to a target object)
Get (set) property value from Retrieve (set) single property in InstanceName, PropertyName
instance instance
Get (set) qualifier declaration Retrieve (set) single qualifer QualifierName
declaration (QualifierDeclaration)
Enumerate (delete) qualifier Delete single (enumerate) quali- QualifierName
declaration fier declaration (QualifierDeclaration)
2. Value XML Elements

This group is concerned with the value of CIM objects. This group includes
elements that define a single value, value array, object, named instance,
named object, etc.
3. Naming and Location XML Elements
This group is concerned with the names and identification of CIM objects
and the paths needed to access them. This group includes elements that define
TABLE 5–3 Functional Groupings
Functional Group Dependency Methods

Basic Read None GetClass
EnumerateClasses
EnumerateClassNames
GetInstance
EnumerateInstances
EnumerateInstanceNames
GetPropety
Basic Write Basic Read SetProperty
Schema Manipulation Instance Manipulation CreateClass
ModifyClass
DeleteClass
Instance Manipulation Basic Write CreateInstance
ModifyInstance
DeleteInstance
Association Traversal Basic Read Associators
AssociatorNames
References
ReferenceNames
Query Execution Basic Read ExecQuery
Qualifier Declaration Schema Manipulation GetQualifier
SetQualifier
DeleteQualifier
EnumerateQualifiers
a namespace, class name, instance name, key value, and a path (with or with-
out the host component) to a namespace, object, class, instance, etc.
4. Object Definition XML Elements
This group is concerned with expressing the definition of CIM objects. This
group includes elements that define a class, an instance of a class, a qualifier, a
property or parameter (each may be a single value or an array), a method, etc.
5. Message XML Elements
This group is concerned with expressing the definition of CIM messages for
use in the mapping described in the previous section. This group includes ele-
ments that define a simple request message, a multiple request message, a sim-
ple response message, a multiple response message, an extrinsic method, an
intrinsic method, a response to each type of method, a parameter, an error, etc.
CIM
The specification for the Common Information Model defines the structure of
the CIM schema, a set of metadata called the metaschema that is used to formally
define the schema, a set of data types in which properties can be defined, naming
schemes for classes and objects, sets of metaschema, standard, and optional qual-
ifiers, and methods of mapping management data from legacy schemes to CIM
properties.
The structure of the CIM schema will be defined in detail in a subsequent
section.
CIM also makes specific provision for extensibility in terms of allowing prop-
erties of classes that are defined by enumeration (that is, must be one of a set of
defined values) to reference additional unique values. This is done by defining an
additional property, usually named OtherNNN (where NNN is the name of the
enumeration property), and allowing “other” as a value in the enumeration prop-
erty to indicate its use.
The CIM specification also defines the MOF in detail. MOF is based on the
Interface Definition Language defined by the Open Group in its Remote Proce-
dure Call (RPC) specification. MOF defines a syntax that allows objects to be
defined in a textual form, and the syntax permits comments to be included. The
main components of that syntax are textual descriptions of classes, associations,
properties, references, methods, and instance declarations and their associated
qualifiers. The grammar for this syntax is described in an appendix to the speci-
fication, using the Augmented Backus-Naur form defined by the IETF. Other
appendices define the CIM metaschema in MOF format and the UML notation
subset used in CIM schema diagrams. A CIM-capable system must be able to both
import and export properly formed MOF constructs.
SMI-S Additions
SMI-S adds a number of new definitions and concepts to those defined in CIM.
These are fully compatible with the DMTF definitions, but represent further
refinement and restriction, and in some cases anticipate future DMTF develop-
ments. Two specific additions will be described in detail here: Durable Names and
a Discovery Service.
Correlatable and Durable Names

WBEM Clients need to obtain and set properties of managed objects in multiple
Namespaces. Circumstances arise where an object in one namespace is associated
with an object in another namespace, and each namespace contains some amount
of information about the same managed resource using different objects.
The WBEM Client therefore needs a way to understand when objects in
different namespaces represent the same managed resource. A unique identifier,
referred to as a correlatable name, has been defined by SMI-S as a required
property for any objects representing managed resources that might be viewed in
this way. These names provide the client with a reliable means of relating infor-
mation from multiple sources about the same managed resource in a SAN.
Correlatable names may also have an aspect of durability, that is, they may
have specific lifetime. The exact lifetime of a name is a function of the specific
object, but no name is permanent. Such durable names provide a means of relat-
ing information obtained at different points in time, such as when a managed
resource is returned to a SAN after having been removed for some period of time.
A number of different formats are supported for these names, because not
all of the information required to support every format is available in all situa-
tions. The types of information used for these formats include SCSI Device Iden-
tifiers from the Inquiry Vital Product Data Page #83, Fibre Channel World Wide
Names, Fully Qualified Domain Names, and IP Address information.
Not all formats are valid for all classes in the schema, and the name of the
property that contains the correlatable and durable names also varies by class.
SMI-S contains detailed pseudo-code describing how equality is determined
between the correlatable and durable names of multiple objects.
CIM requires that instance identifiers be unique across all instances of a class
within a single namespace, but does not fully address cases in which different types
of identifiers are possible on different instances of an object. A method is there-
fore needed to ensure that multiple sources of information about managed
resources use the same approach for forming correlatable and durable names
whenever different types of identifiers are possible. This is done by establishing a
preferred durable name format for each class, and also a prioritized list of alter-
nate name formats.
Discovery Service
CIM does not define an explicit mechanism by which a WBEM Client can discover,
enumerate, and locate all of the WBEM services available to it that meet certain cri-
teria in a network. SMI-S does stipulate such a mechanism and leverages an existing
standard, called the Service Location Protocol (SLP), to provide this capability.
SLP is defined by the IETF and is becoming widely used for discovery in a
number of different scenarios in a TCP/IP network. An example of more general
SLP usage is in discovering printers. Note that two separate versions of SLP have
been standardized, and version 2 is required by SMI-S. Another IETF document
defines an optional C language API for use with SLP.
SLP is primarily used to locate an agent, but also provides some finer grained
visibility in terms of the profiles (see the next chapter) supported by the agent.
SLP establishes a framework for resource discovery that includes three “agents”
that operate on behalf of the network-based software. These are shown in the ref-
erence model in Figure 5–2, and are defined as follows:
• A Service Agent (SA) is the function supported by a WBEM Service to enable
its specific characteristics to be registered with the discovery service defined
by SMI-S.
TABLE 5–4 SLP Header Fields
Header Field Description

Version SLP protocol version: 1 and 2 are defined.
Length Length of the entire SLP message.
Function ID Message type that follows the SLP Header.
Flags Indicate special treatment of the message.
Next Extension Offset Offset, in bytes, to the first SLP Extension.
XID Unique number for each unique request.
Language Tag Length Length of the Language Tag that follows.
Language Tag Indicates the language of all human-readable
strings included in the SLP message.
• A User Agent (UA) is the function supported by a WBEM Client to discover

the location and characteristics of available WBEM Services through the dis-
covery service specified by SMI-S.
• A Directory Agent (DA) aggregates service information from multiple SAs
into what is initially a stateless repository.
Note that the above is a different use of the term agent than in CIM, and
because of this these functions are referenced only by their abbreviations in the
following descriptions.
SLP provides a framework for a UA to find and utilize services that are adver-
tised by SAs. Two modes of operation are supported. If no DA is present, UAs will
communicate with SAs directly. The DA represents an optional part that enhances
the performance and scalability of the protocol by acting as a cache for all ser-
vices that have been advertised. DAs also provide scalability to support large net-
works by reducing the load on SAs. SAs register with DAs and are required to
reregister as registrations expire. If a DA is present, a UA will query the DA for
services, rather than directly accessing an SA.
SLP consists of two parts: a message protocol and a service definition. The
protocol can further be subdivided into five items.
1. Common Message Format
All SLP messages use a common format consisting of a 16-byte binary header
followed by a set of UTF-8 strings preceded by length fields. Table 5–4 defines
the contents of the header field, and Table 5–5 lists the message types and
their usage. The layout of the strings and the information they contain are
specific to the message type. Note that SMI-S defines the default scope as
always being used.
TABLE 5–5 SLP Message Types
SLP Message Type ID Description
Service Request 1 UAs find service by type, scope, and search filter.
Service Reply 2 DA (or SA) returns Service URLs and their lifetimes.
Service Register 3 SAs register Service URLs and attributes.
Service Deregister 4 SAs deregister Service URLs and attributes.
Service Acknowledgment 5 DAs acknowledge a successful registration or deregistration.
Attribute Request 6 UAs find attributes by service type or by Service URL.
Attribute Reply 7 DA (or SA) returns attribute information.
DAAdvert 8 DA sends its Service URL, scope, and attributes.
Service Type Request 9 UAs find service types by scope.
Service Type Reply 10 DA (or SA) returns a list of service types.
SAAdvert 11 SA sends its Service URL, scope, and attributes.
2. UA to SA/DA Communication
The messages used by a UA to communicate directly with an SA or an
optional DA are identical. They consist of three pairs, namely:
a. Service Request and Reply
b. Attribute Request and Reply
c. Service Type Request and Reply
which are used as described in Table 5–5. SMI-S defines item c as optional.
3. SA to DA Communication
The messages used by an SA to communicate with a DA are:
a. Service Request and Reply
b. Service Register
c. Service Deregister
d. Service Acknowledgment
which are used as described in Table 5–5. SMI-S defines item c as optional
for an SA, and all are required to be supported by a DA.
4. Advertisements (SAAdvert or DAAdvert)
There are separate messages by which SAs and DAs can advertise their pres-
ence and capabilities. These are normally transmitted to a multicast address.
5. Multicast Convergence Algorithm

A UA or an SA can obtain the address of a DA with which to communicate
by several means, such as the DHCP option by which both the address and
scope of a DA are returned, or by manual configuration. In the absence of
other methods, though, the Multicast Convergence Algorithm as follows may
be used to locate a DA, and the same algorithm is always used by a UA to
locate an SA if a DA is not present. The algorithm begins when a UA or SA
issues a request as above, but to a multicast address instead of a unicast
address. One or more replies may then be generated to the unicast address
from which the request originated. After a wait period, the UA/SA reissues
the request containing a “previous responders list,” which includes the uni-
cast address of the sender of each reply. Upon receiving this request, the
receiving entity checks the previous responders list, and if it finds its unicast
address it silently discards the request.
The SLP service definition consists of two parts, the service URL and the service
type template. The service URL defines an access point for the service and iden-
tifies a unique resource in the network. SMI-S states that service URLs may be
either existing generic URLs or a special type as follows:
service:srvtype>://addrspec
where:
srvtype is the type of service derived from the service registration
addrspec is a hostname (which should be used if possible) or dotted decimal
notation for a hostname, followed by an optional ‘:’ and port number.
The service template is a text file in the format defined by IETF RFC2609.
SMI-S defines a standard WBEM service type template that has been registered
by the DMTF. The template defines a number of service attributes, including:
• Service-hi-name—This is the name of the service for use in human interfaces.
• Service-hi-description—This is a description of the CIM service that is suit-
able for use in human interfaces.
• Service-id—A unique identification for the CIM server that is providing the
service.
• Service-location-tcp—This is a list of TCP addresses that can be used to reach
the service.
• CommunicationMechanism—This will identify XML-CIM for WBEM ser-
vices compatible with SMI-S.
• ProtocolVersion—The version of the XML-CIM protocol.
• FunctionalProfilesSupported—The functional groups of Intrinsic methods
supported (see Table 5–3). Multiple values can be returned.
• MultipleOperationsSupported—A Boolean indication of whether multiple
request messages (see XML-CIM) are supported.
Apps
e
as
er
b
Us
ta
ce
m
Da
te s vi
Sy De
Support
Core Event
Po In
icy l te
ro
Ph
p
Network
M
ys
et
ic
ric
al
s
FIGURE 5–5 Schema Organization
• AuthenticationMechanismsSupported—The authentication mechanism sup-

ported by the service, which can return multiple values.
• Namespace—The namespace(s) supported by the service. This attribute may
have multiple values (one for each namespace defined in the service), and is lit-
eral because the namespace names may not be translated into other languages.
• Classinfo—The CIM schema version, etc., for the namespaces defined in the
corresponding namespace listed in the namespace attribute.
• RegisteredProfilesSupported—The SMI-S profile(s) supported by the server
prefixed by “SNIA.” Each entry includes a RegisteredOrganization (i.e.,
SNIA), a profile name, and possibly a subprofile name. Each name is sepa-
rated by a colon. As a single SMI-S server can support multiple profiles, this
attribute is an array of values.
Details of the CIM Schema

The CIM schema defines an object-oriented information model described by a
set of UML class diagrams and defined by one or more MOF text files, as described
above. The class diagrams use a very restricted subset of the complete UML def-
inition, which is defined in the following section.
The structure of the model allows a managed environment to be viewed as a
set of related systems, each containing a number of discrete components, and both
the characteristics of these systems and components and their relationships are
represented. The schema defines a set of classes, with properties and methods, to
ManagedElement Key
Description: string
Inheritance
Caption: string
Association Association
Aggregation
Dependency ManagedSystemElement Component

Name: string
Description: string
Caption: string
Status: string
InstallDate: datetime Aggregation
(a type of association)
Properties
FIGURE 5–6 UML Subset
represent the systems and components, and a set of associations to represent the
relationships between the classes.
The schema is subdivided on a functional basis into a number of different
“models,” as shown in Figure 5–5. The core model captures notions that are appli-
cable to all areas of management and contains a set of classes, associations, and
properties that provide a basic vocabulary for describing managed systems. Many
of the classes in the core are “abstract” in that they only serve as a base for other
class definitions, and instances of those classes cannot be separately created.
The common models capture notions that are common to particular man-
agement areas, but independent of any particular technology or implementation.
The common models are the “petals” shown in Figure 5–5, and of this set the
device, interop, physical, and system models are most referenced in SMI-S. These
models, along with the core model, are described in detail in the subsections fol-
lowing the description of UML notation.
UML Notation
The subset of UML used in CIM is illustrated in Figure 5–6. Most classes are
depicted as rectangles. The class name shown is in the upper part and properties
(also known as attributes or fields) are listed in the lower part. A third subdivi-
sion is added for methods when they are included.
An association is used to describe the relationship between two or more
classes. Many of the diagrams do not show the properties of association classes,
but merely represent the classes as lines. In that case there is usually a separate
page of the model that shows the association hierarchy as classes. The ends of
some associations have numbers (cardinality) indicating the valid count of object
instances. Cardinality is expressed either as a single value (such as 1) or a range
of values (0..1 or 1..4); * is shorthand for the range 0..n. Some associations and
aggregations are marked with a “W” at one end indicating that the identity of this
class depends on the class at the other end of the association.
The notation defines three types of lines connecting classes. The CIM docu-
ments generally follow the convention of using arrows for inheritance, red lines
for associations, and green lines for aggregation. The color coding makes large
diagrams much easier to read but is an extension of UML.
The SMI-S document uses two UML conventions in addition to those used
in CIM:
1. Packages
The UML package symbol is used as a shortcut representing a group of classes
that work together as an entity. After the initial explanation of these objects,
a single package symbol is used to represent the entire group of objects.
2. Instance Representations
Schema diagrams include both classes and associations. The class hierarchy
is included and each class is depicted one time in the schema diagram.
Instance diagrams also contain classes and associations, but represent a
particular configuration. Multiple instances of an object may be depicted in
an instance diagram. An instance is named with an instance name followed
by a colon and an underlined class name.
Core Model
The core model includes the most general classes in the managed environment,
along with the most widely used properties (variables). The class hierarchy begins
with the abstract Managed Element class; Managed System Element, Capabilities,
Location, Configuration, and Setting classes, among many others, are subclasses
of that class. From the classes in the core model, the model expands in many direc-
tions, as defined by the common models.
The most relevant pieces of the core model to SMI-S are:
1. Basic Abstraction (see Figure 5–7)
This piece incorporates base classes such as ManagedElement, ManagedSys-
temElement, etc., and base association classes such as Dependency, Compo-
nent, and LogicalIdentity.
The ManagedElement class is the root of the entire schema. It acts as a
reference for associations that apply to all entities in the hierarchy.
ManagedSystemElements (MSEs) represent Systems, components of Sys-
tems, any kinds of services (functionality), software, and networks.
Concrete
40
Identity
Component *
*ManagedElement * * Dependency
* Caption: string
*
ConcreteComponent * Description: string
* ConcreteDependency
* *
LogicalIdentity * ElementName: string 0..1 HostedDependency
* *
Capabilities Collection Location
ManagedSystemElement
InstallDate: datetime
Name: string
OperationalStatus: uint16[] {enum}
StatusDescriptions : string[]
Status: string {enum, D}
PhysicalElement LogicalElement
(See Figure 5–9)
(See Figure 5–9)
FIGURE 5–7 Basic Abstraction

The basic abstraction also illustrates PhysicalElement and LogicalEle-

ment, immediate subclasses of ManagedSystemElement. The separation of
physical and logical elements at this level in the hierarchy is a modeling
approach that has proved to be very flexible. CIM defines PhysicalElements
as those that conform to the laws of physics, occupy space, and can be touched
and labeled with physical tags. All other manageable components are sub-
classes of the LogicalElement class.
A fundamental feature of the basic abstraction is the Setting class. Set-
tings are groups of parameters that determine the state of a ManagedSys-
temElement, and the setting class has both ElementSetting and DefaultSetting
associations, and a CollectionSetting association to a CollectionofMSEs,
which in turn is a subclass of Collection. A number of Settings are also aggre-
gated into a configuration. The schema topology here—the separation of the
element and its settings—is an example of a design pattern that has been
identified in a number of models. This approach is used where it makes sense
to be able to read and manipulate the state of settings independently of the
state of the equipment being managed. System boot parameters are an exam-
ple of a situation in which this separation is useful.
2. Logical Elements (see Figure 5–8)
This piece incorporates the Service, ServiceAccessPoint, and System classes,
which are subclasses of EnabledLogicalElement, which in turn is a subclass
of LogicalElement. Note that LogicalDevice is also a subclass of EnabledLog-
icalElement, but this is described in the next item for convenience.
Two design patterns are evident in this piece. The “service” design pat-
tern describes a case where the capability provided by one managed entity is
required or consumed by another. The Service class represents the notions of
the Service that can be managed, but does not include how the service is
accessed, which is abstracted by the ServiceAccessPoint class. Two associa-
tions (ServiceAccessBySAP and ServiceSAPDependency) model an “N N”
relationship between access point and service, and both have a “hosted” asso-
ciation to the same instance of a system class. Note that the StartService and
StopService methods are included in the Service class definition. Multiple lev-
els of service, and dependencies between services, are modeled by the Ser-
viceComponent association and ServiceService dependency.
The “composite” design pattern describes a common situation in which
manageable components are aggregated into a complex combination, which
can itself be treated as a manageable component. This relationship is mod-
eled in this piece by multiple MSEs having a SystemComponent association
with the System class, which is itself a subclass of MSE via LogicalElement.
The definition of “System” in the CIM context is quite broad, ranging from
computer systems and dedicated devices to application systems and net-
works. AdminDomain is also a subclass of System, and it is the “entry point”
for many storage functions that will be described in the following chapter.
Again, a hierarchy of administrative domains is modeled by the Contained-
Domain hierarchy.
42
LogicalElement
(See Figure 5–7)
EnabledLogicalElement
EnabledState: uint16 {enum}

OtherEnabledState: string
RequestedState: uint16 {enum}
EnabledDefault: uint16 {enum}
TimeOfLastStateChange:datatime ManagedSystemElement
RequestStateChange(
[IN]RequestedState {enum},
[OUT] Job: CIM_ConcreteJob,
[IN] TimeoutPeriod: dateTime): uint32 {enum} SystemComponent
*
*
* *Service ServiceAccess ServiceAccessPoint LogicalDevice System *
* BySAP
*
* CreationClassName:: string {write}
* CreationClassName: string {key} (See Core Model) CreationClassName: string {key}
ServiceService Name: string {override, key} ServiceSAP Name: string {override, key} Name: string {override, key}
Dependency PrimaryOwnerName: string {write} Dependency NameFormat: string

* PrimaryOwnerContact:: string {write} * * *Active* w 1 PrimaryOwnerName: string {write}
StartMode: string (10) {D,enum}
*SAPSAP* * HostedAccessPoint PrimaryOwnerContact: string {write}
Connection Roles: string[ ] {write}
Started: boolean BindsTo Dependency
* StartService(): uint32 1
ServiceComponent StopService(): uint32
*
ProtocolEndpoint ServiceAccessURI RemoteServiceAccessPoint AdminDomain
w
* * LabeledURI: string AccessInfo: string
* NameFormat: string NameFormat: string
{required} InfoFormat: uint16 {enum}
ProtocolType: string {enum,D} {override, enum}
OtherInfoFormatDescription: string
OtherTypeDescription: string
ProtocolIFType: uint16 {enum}
* *
ContainedDomain
RemotePort
*
PortInfo: string
Provides PortProtocol: uint16 {enum}
Endpoint OtherProtocolDescription: string
HostedService
FIGURE 5–8 Logical Core Piece

0..1
Contained *
Location
Location * Name: string {key}
PhysicalPosition: string {key}
Address: string
0..1
PhysicalElement
PhysicalElement Tag: string {key}
Location CreationClassName: string {key}
Manufacturer: string
Model: string
SKU: string EnabledLogicalElement
SerialNumber: string
Version: string
* (See Figure 5–8)
PartNumber: string
Chapter 5
OtherIdentifyingInfo: string {write}

PoweredOn: boolean
ManufactureData: datetime
VendorEquipmentType: string System LogicalDevice

UserTracking: string
CanBeFRUed: boolean (See Figure 5–8) CreationClassName: string {key}
DeviceID: string {key}
* * PowerManagementSupported: boolean {D}
PowerManagementCapabilities: uint16[] {D, enum}
1 Availability: uint16 {D, enum}
* StatusInfo: uint16 {D, enum}
LastErrorCode: uint32 {D}
SystemPackaging ErrorDescription: string {D}
ErrorCleared: boolean {D}
OtherIdentifyingInfo : string[ ]
PowerOnHours: uint64 {D, units}
TotalPowerOnHours: uint64 {D, units}
IdentifyingDescriptions: string[ ] StorageExtent
AdditionalAvailability: uint16 {D, enum}
MaxQuiesceTime: uint64 {D, units} DataOrganization: uint16 {enum}
Purpose: string
SetPowerState ( Access: uint16 {enum}
[IN] PowerState: uint16 {enum}, ErrorMethodology: string
[IN] Time: datetime): uint32 {D} BlockSize: uint64 {units=Bytes}
Reset ( ): uint32 NumberOfBlocks: uint64
EnableDevice ([IN] Enabled: boolean): uint32 {D} ConsumableBlocks: uint64
OnlineDevice ([IN] Online: boolean): uint32 {D} IsBasedOnUnderlyingRedundancy: boolean
QuiesceDevice ([IN] Quiesce: boolean): uint32 {D} SequentialAccess: boolean
SaveProperties ( ): uint32 ExtentStatus: uint16[ ] {enum}
RestoreProperties ( ): uint32 NoSinglePointOfFailure: boolean
DataRedundancy: uint16
PackageRedundancy: uint16
w
SystemDevice * DeltaReservation: uint8
* * Primordial: boolean
Realizes
*BasedOn *
An Introduction to Web-Based Enterprise Management and SMI-S
FIGURE 5–9 Physical Core Piece

43
3. Physical Elements (see Figure 5–9)

This piece incorporates the PhysicalElement, Location, LogicalDevice, and
StorageExtent classes. Properties of PhysicalElement include strings defining
the manufacturer, part number, etc. A physical element may be associated
with a specific Location, or with one or more Systems by the SystemPackag-
ing association.
The LogicalDevice class incorporates many parameters, and a number of
more specific classes are subclasses of LogicalDevice in the common models.
A StorageExtent class is also a subclass of LogicalDevice in the core model. A
Realizes association links LogicalDevice with a PhysicalElement, which in
turn is associated with one or more Systems.
Although not shown in the figure, the Product and FRU (Field Replace-
able Unit) classes are subclasses of ManagedElement, and have ProductPhys-
icalSupport and FRUPhysicalElements aggregations, respectively, with the
PhysicalElement class.
4. Collections and Groups
This piece shows how MSEs may be aggregated into Collections, which is a
subclass of ManagedElement, and aggregated into a RedundancyGroup,
which is a subclass of LogicalElement. StorageRedundancyGroup is a subclass
of RedundancyGroup, and it is associated with multiple StorageExtents
through use of the ExtentRedundancyComponent association. One of the
distant subclasses of the Collection class is a StorageRedundancySet.
Device Model
The device model mostly consists of a large number of subclasses of the Logi-
calDevice class (contained in the core model) that are appropriate to many dif-
ferent device types. Currently, the model has the following pieces:
Cooling and Power
Processors
Controllers
PCI Controllers
Logical Ports
Logical Port Group
Protocol Controllers
Network Adapters
Fibre Channel
Fibre Channel Services and Zoning
InfiniBand
Storage Devices
Storage Extents
SCC Extent Model
Storage Services
Storage Capabilities and Settings
Storage Library
User Devices (Keyboards, Monitor, Mouse)
Memory
Modems
Printers, Print Jobs, Print Services
Sensors and Alarms
USB and Disk Group
The device model describes the functionality provided by a physical device,
along with information on its configuration and state. Each device has a Realizes
association with the objects representing the physical equipment that comprise it.
In many cases, the same physical element provides multiple separate functions,
which are modeled as separate LogicalDevice classes. Logical Devices are aggre-
gated to a System via the SystemDevice association, and many devices also have
relationships to other devices for reasons such as identifying a controller, meet-
ing a need for cooling, etc., that are modeled by a variety of other associations.
There are also generic provisions for making error data and counts available.
SMI-S makes much use of the Logical Ports and Port Group, and all of the
Storage pieces of the model. Further details are given when the profiles for spe-
cific equipment types are described.
Physical Model (see Figure 5–10)

The physical model consists of a large number of subclasses of the PhysicalEle-
ment class (contained in the core model), but also involves subclasses of the Col-
lection, PhysicalCapacity, Location, StatisticalInformation, and StatisticalData
classes, which themselves are direct subclasses of the ManagedElement class (also
contained in the core model).
The physical model represents the physical composition and topology of the
computer system, but not its functionality. That information is provided by sub-
classes of the core LogicalElement classes, or as services hosted on the computer
system. The physical model provides information related to inventory and asset
management, including the definition of FRUs. The model describes enclosures,
cards, slots, physical components, and cabling information. Many of the concepts
used are derived from the earlier DMTF Desktop Management Interface (DMI)
standard.
1
ManagedElement
46
ElementStatisticalData
(See Figure 5–7)
Location (CORE) ManagedSystemElement

*
Collection PhysicalCapacity StatisticalData
Name: string {key}
(See Figure 5–7) (See Physical Model (See Figure 5–7) (See Core Model)
PhysicalPosition: string {key}
[Capacity &
Contained Address: string
Replacement]) *
Location
0..1 0..1
ReplacementSet
* PhysicalElement PhysicalElement (CORE) LogicalElement MediaPhysicalStatData
(See Physical Model Location
Tag: string {key} (See Figure 5–8) (See Physical Model
[Capacity &
Replacement]) CreationClassName: string {key} [Storage Statistics])
Manufacturer: string
Model: string
*
SKU: string EnabledLogicalElement
* 1..n SerialNumber: string
ElementCapacity (See Figure 5–8)
Version: string *
ParticipatesInSet
PartNumber: string
SystemPackaging
OtherIdentifyingInfo: string
PoweredOn: boolean
* System
ManufactureData: datetime * *
VendorEquipmentType: string (See Figure 5–8)
UserTracking: string Realizes
*CanBeFRUed: boolean
LogicalDevice
* * (See Figure 5–9)
ElementsLinked
Container
0..1
*
PhysicalLink PhysicalConnector PhysicalComponent PhysicalPackage
(See Physical Model (See Physical Model (See Physical Model (See Physical Model
[Connector, Link, & [Connector, Link, & Package]) [Physical Component]) [Connector, Link, &
Package]) Package])
FIGURE 5–10 Physical Model

The Statistics classes are included in this model; in some circumstances the
information reported relates to boundaries defined by the physical model—that
is, it is associated with a particular item such as a tape cartridge.
An ElementCapacity association relates each PhysicalElement to the Physi-
calCapacity class contained in the core model. This capacity is defined in terms
of the element’s ability to support a minimum and a maximum number of logi-
cal objects, the specific class of objects referenced being defined by subclasses of
PhysicalCapacity.
Location information may be specified for each Physical Element via the
PhysicalElement association to the Location class defined in the core model, which
includes physical position and address properties.
Multiple PhysicalElement instances may also be aggregated by the Partici-
patesInSet association into a Replacement Set, which is in itself a subclass of the
Collection class defined in the core model.
The major subclasses of PhysicalElement are:
1. PhysicalPackage
This class describes general containers and frames, and provides manage-
ment, maintenance, and repair information. The Container association
relates this class to the other PhysicalElements that it contains. Frame, Chas-
sis, Rack, Card, and StorageMediaLocation are further subclasses of Physi-
calPackage. StorageMediaLocation defines the shelf/hole/slot where
removable media (such as tape) can be stored.
2. PhysicalComponent
This class describes low-level hardware, such as chips and physical media,
which are defined by further subclasses.
3. PhysicalConnector
This class describes the connectors used to attach or link PhysicalElements
together and can be further refined by a Slot subclass where necessary.
A slot describes the connector used to attach one card to another (for exam-
ple, a backplane or motherboard). A PackageInConnector association is used to
describe a PhysicalPackage that is inserted into the PhysicalConnector.
4. PhysicalLink
This class describes the cabling used between PhysicalElements, often Physi-
calConnectors as above. An ElementsLinked association relates the elements
that are connected, and where a connector is involved a LinkHasConnector
association is also employed.
Interop Model
The interop model contains a set of object models that describe the WBEM ser-
vice itself. In terms of the reference model contained in Figure 5–2, the interop
model provides management information related to the capabilities of object
managers and providers, along with statistics related to their use.
The model has the following pieces:

1. Object Manager and Communications
The ObjectManager class is a subclass of the Service class in the core model.
Access to the Object Manager is provided by the ObjectManagerCommuni-
cationMechanism class, the properties of which provide much of the infor-
mation for the SLP WBEM service template described previously. The two
classes are related via the CommMechanismForManager association, and the
ObjectManagerCommunicationMechanism class is itself a subclass of the
ServiceAccessPoint class.
A ProtocolAdapter class is another subclass of the Service class in the
core model and associates via CommMechanismForAdapter to the Object-
ManagerCommunicationMechanism class. For SMI-S, the ProtocolAdapter
class represents the entity that converts the representation of CIM in XML to
a native format.
2. Namespace and SystemIdentification
Namespace and SystemIdentification are both subclasses of the ManagedEle-
ment class, and are related by the SystemInNamespace association. The
Namespace class defines all of the namespaces supported by the Object Man-
ager with which NamespaceInManager associates, and includes the type of
information contained in each namespace. The SystemIdentification class
provides enough information to identify the system(s) represented in the
Namespace.
3. Provider
This piece describes a provider and its capabilities. The capabilities include
the class that the provider is supporting, including its properties and meth-
ods. The model also defines the mechanism by which a provider is required
to register with the Object Manager.
4. Profile
This piece contains two experimental classes: RegisteredProfile, a subclass of
ManagedElement, and RegisteredSubProfile, a subclass of RegisteredProfile.
These classes are used to indicate the names and versions of profiles sup-
ported by ManagedElements. A hierarchy of profiles is supported through the
ReferencedProfile association.
5. Statistical Data
The CIMOMStatisticalData class is a subclass of the StatisticalData class in
the core model, and contains usage statistics about the Object Manager in
terms of CIM operations.
System Model
The system model defines computer system–related abstractions. The only part
of this model relevant to SMI-S is the ComputerSystem class, a subclass from the
System class in the core model. The System class describes the aggregation of parts
(or components) into a single manageable whole (the system), which places lim-
its on the information available to its parts. Systems are not modeled as a collec-
tion, because they are more than the sum of their parts. Systems have status and
they host services and access points.
The ComputerSystem class can describe both general-purpose and dedicated
systems. Much of the equipment in a storage network is modeled as a computer
system dedicated to a specific function.
Profiles of
Storage Network
Equipment Types
The DMTF Common Information Model described in the previous chapter con-
tains a rich object-oriented representation of a managed environment. The SNIA
SMI-S shows how storage networks can be managed as systems, using constructs
taken from CIM. It does not define any extensions to CIM, or any new classes,
methods, or properties, but merely groups the existing definitions to simplify their
use for the specific purpose of managing a storage network.
This chapter introduces five additional terms:
• A profile is a named set of functions for WBEM service–based management
of a particular set of subsystems for a defined set of uses. A profile can refer
to one or more subprofiles and in some cases to other profiles.
• A subprofile is a named subset of a profile. Typically, a formal subprofile is
defined to allow a specific set of functions to be present only in some
instances of a profile. However, a subprofile itself is an atomic unit—either
all or none of its functionality is supported. A common subprofile is a set of
functions that may appear in more than one profile.
• A package is a set of constructs that are used together to define an aspect of
a model.
• A recipe is a WBEM service use case, a script for the interaction between a
WBEM Client and Server as they follow a specific path through the schema
to achieve a specific task. A recipe operates within a defined scope.
• A WBEM service advertises supported profiles and subprofiles using SLP. The
service also reports the profiles and subprofiles that are supported through
the interop model. Packages are not advertised or reported.
Much of the SMI-S document is concerned with defining profiles, subprofiles,
and packages. A registry of the profile and subprofile names is shown in
51
TABLE 6–1 Profile and Subprofile Registry
Area Registered Profile Name Registered Subprofile Name

Fabric Fabric Zone Control
Enhanced Zoning and Enhanced Zoning Control
FDMI
Switch Blades
Router Software
Backend Ports
LUN Mapping and Masking
Hosts FC HBA
Host Discovered Resources Initiator
Target
Storage Array Cluster
Extra Capacity Set
Software
Access Points
Location
Pool Manipulation, Capabilities, and Settings
Extent Mapping
Disk Drive
Backend Ports
LUN Creation
Copy Services
Job Control
Device Credentials
In-Band Virtualization Cluster
System Extra Capacity Set
Software
Access Points
Location
Pool Manipulation, Capabilities, and Settings
Extent Mapping
LUN Creation
Copy Services
Job Control
Device Credentials
Storage Library Software
Access Points
Location
Limited Access Port Elements
Server Server Protocol Adapter
Table 6–1. Only two packages are defined: physical and software. The packages,
profiles, and subprofiles are described in detail in the sections following the con-
ventions section.
Conventions
The SMI-S document contains two new conventions:
1. A common format used to describe profiles and all subprofiles
2. A pseudo-code syntax used to describe recipes
These are described in detail in the following sections.
Common Format for Profile and Subprofile Descriptions

SMI-S defines a common format that is used to describe each profile and sub-
profile in the document. The components of this format are as follows:
1. Description
This component contains a textual introduction to the subset being profiled. It
provides a high-level foundation for the more detailed descriptions to follow.
2. Standard Dependencies
This component contains the list of standards required for each profile or
subprofile. Subprofiles inherit the standards listed in the parent profile, as
only unique standards are listed. For the majority of profiles the standards
identified are:
a. CIM Specification, Version 2.2
b. CIM Operations over HTTP, Version 1.1
c. CIM Schema, Version 2.8 Preliminary
Note that some profiles and packages are defined against Version 2.7 of
the CIM schema, and do not require the new functionality that has been
included in Version 2.8.
3. Profile Dependencies
This component contains a list of the names of profiles that are required by
this profile (or subprofile). Optional subprofiles and profiles are listed in item
13 on page 55.
4. CIM Server Requirements
This component lists requirements placed on the WBEM Server that are
required in order to support the profile or subprofile. Typically, these require-
ments include the specific functional groups of intrinsic methods that need
to be supported (see Table 5–3), and also any extrinsic methods needed. The
requirement to advertise support for a profile or subprofile is also addressed

in this section.
A subprofile may simply declare that the support required is the same as
for the parent profile, but may also add specific requirements.
5. Instance Diagrams
This component contains one or more instance diagrams. Instance diagrams
use the UML notation defined previously to describe classes and associations
but represent a particular configuration; multiple instances an object may be
depicted in an instance diagram.
6. Durable Names and Correlatable IDs
This component defines the Durable Names and Correlatable IDs for
resources exported by the profile and identifies the Durable Names and Cor-
relatable IDs used by other profiles. For the Durable Names exported by the
profile, the section identifies the valid name formats and the specific encod-
ing of names for each name format. For Correlatable IDs exported by the
profile, the source for the ID is identified and the conditions that would cause
the ID to be reset are identified.
7. Methods
This component lists the extrinsic and intrinsic methods that are defined as
required by the profile.
8. Client Considerations
This component contains a summary of the implementation concerns that
are likely to be encountered by products and services that rely on the profile
being described. This section also identifies how to locate any subprofiles
required for this profile.
9. Recipes
This component contains a set of processes that sequence the operations and
other steps defined in reference to the objects contained in this profile to
accomplish particular tasks.
10. Instrumentation Requirements
This component contains a summary of the implementation concerns that
have to be accounted for by agents that implement instances contained in this
profile.
11. Required CIM Elements
This component contains a table listing the classes, associations, subprofiles,
packages, and indications that are required by this profile.
12. Required Properties for CIM Elements
This component contains one or more tables (typically one per instance)
listing the properties and methods that are required to be supported by the
profile. Some properties are required, whereas others are optional. All prop-
erties that CIM defines explicitly (e.g., with a Required qualifier) or implic-
itly (e.g., identified as a Key) as required are also required by SMI-S. If a
property can not be produced, a null value is returned.
13. Optional Subprofiles and Profiles
This component lists the names of the profiles and subprofiles that are
optional for this profile.
Recipe Pseudo-Code Conventions

All SMI-S recipes use a common syntax to describe the sequence of operations
and manipulation of data structures involved. The syntax is described in func-
tional terms in the following subsections.
General Syntax
The general syntax of the pseudo-code consists of only four items, as follows:
• conditiondefines a logical statement that evaluates to true (Boolean).
• !condition defines a logical statement that evaluates to false (Boolean).
• action represents an unspecified list of programming logic that is not
important to the understanding of the reader for a particular recipe.
• @{recipe} references another recipe.
The syntax uses the “{}” delimiters to define blocks, sets, and levels as per
usual.
Instances and Object Names

The following items relate to the naming and instantiation of objects as defined
in the previous chapter. Note that arrays defined in this and subsequent sections
can be indexed by another variable.
• $name represents a single instance with a given variable name.
• $name.property represents a property of a single instance.
• $name.getObjectPath() is a method that returns an object name, REF, to the
instance.
• $name.getNameSpace() is a method that returns the namespace name for
the instance or object name.
• {value1, value2 . . .} represents an array comprised of selected values of a
given type; is not referable by a variable.
• $name[] represents an array of instances with a given variable name. The
array is initialized by constructing an anonymous array as above.
• $name- represents an object path name.
• $name-[] represents an array of object names of a given name.
• $name-property represents a property of an object.

• $name$name[].size() returns the number of instances in the array.
• $name-[].length returns the number of object names in the array.
• #name[].length returns the number of variable elements in the array.
• %name[].length returns the number of method argument elements in the
array.
General Variables
The following variables relate to all types of items:
• #name represents a general variable that is not an instance identifier or object
name as above. The variable type may be a string, number, or some other
special type.
• #name[] represents an array of variables as in item 1 above.
• “literal” represents a string literal.
Extrinsic Method Arguments

The following items relate to arguments that are supplied with extrinsic methods
and execute against objects as defined in the schema. Note that arguments are
always retrieved from arrays by name, and not by a positional index.
• %name represents an argument that can contain any variable.
• %name[] represents an array of arguments.
Operations
The syntax supports a set of comparison operators that reflect common usage in
many programming languages. Tests for equivalency, nonequivalency, logical
AND and OR, etc., are included. The operators that may be less familiar are:
• // precedes a comment.
• nameof returns an object name given an instance identifier. This unitary
operator does nothing in other usages.
• ISA tests for the name of the instance.
Block Control Structures

The syntax supports a set of block control structures that reflect common usage
in many programming languages. “For,” “If,” and “Do/While” structures are
defined, including a “break” definition to terminate the block and an “exit” defi-
nition to terminate the recipe unconditionally.
Functions
Functions may be defined within a recipe to simplify or clarify the logic flow.
Where used, they must be defined at the beginning of the recipe using the form:
sub functionName() {
actions
}
If parameters are to be passed to a function, they are expressed as a comma-
separated list of arguments within the parentheses following the function name.
Each argument is comprised of a data type and an accompanying argument name.
The function is then invoked where needed in the form:
&functionName()
with any required parameters contained within the parentheses and separated by
commas.
A number of built-in functions are also defined by the syntax as follows:
1. boolean compare(variable, variable)
This function is used to determine if two variables of the same type are equiv-
alent. The variables must not be instances, object names, or other complex
data types or structures.
2. $instance newInstance(“Classname”)
This function creates an instance that did not previously exist in the WBEM
service, which can later be filled in with properties and passed to CreateIn-
stance. The namespace is inferred from the positioning in the recipe.
3. $instance - newInstance(“Namespacename”, “Classname”)
This function creates an instance in a defined preexisting namespace identi-
fied by the supplied name.
4. boolean contains(test value, variable array)
This function is used to test if the variable array contains a value equivalent
to the test variable. The variable array must be of variables of the same
type as the test variable. If equivalency is found with at least one value, then
the function returns true; otherwise, false is returned. If the array is not a
simple, or non-CIM, data type, then the test value must be a property, or a
variable representing or containing a property.
5. %Argument newArgument(“Argument Name”, variable)
This function creates an argument of a given name containing a value.
System
Product
SystemPackaging
ProductParentChild
PhysicalPackage
(e.g., Chassis) Product
ProductPhysicalComponent
Container
(e.g., PackageInChassis) ProductParentChild
LogicalDevice
PhysicalPackage Product
(e.g., Drive, physical tape,
Realizes
device changer)
FIGURE 6–1 PhysicalPackage Instance
6. $objectPath- newObjectPath(“Classname”, “NameSpacename”)

This function returns a new ObjectPath, built from the supplied arguments.
The function is required to perform the EnumerateInstances and Enumer-
ateInstanceNames operations.
Exception Handling
The syntax allows exceptions to be tried, caught, and thrown in a manner very
similar to that used in the Java programming language.
Packages
SMI-S defines two packages: a PhysicalPackage and a Software Package. These are
described in SMI-S using a variant of the common format defined above for
described profiles and subprofiles.
ComputerSystem
InstalledSoftwareIdentity
SoftwareIdentity
ConcreteIdentity
ExtraCapacitySet
ComponentCS
MemberOfCollection
ComputerSystem
InstalledSoftwareIdentity
SoftwareIdentity
FIGURE 6–2 Software Package Instance
1. PhysicalPackage
An instance diagram of the PhysicalPackage definition is shown in Figure 6–1.
The package is used to make available product information such as the ven-
dor name, product serial number, and version to a WBEM Client. This may
be done by enumerating the top-level System classes, and then traversing the
SystemPackaging association to locate the physical packages and their asso-
ciated products. Packages may be defined at several levels within a system,
with a Container relationship being defined between a level and its subcom-
ponents. The same information may also be accessed by traversing the Real-
izes association from the LogicalDevice class.
Many of the profiles in SMI-S reference the PhysicalPackage, and the
structures defined herein may optionally be used to make additional envi-
ronmental information available to a WBEM Client.
2. Software Package
An instance diagram of the Software Package definition is shown in Figure
6–2. The package is used to make available information about installed soft-
ware to a WBEM Client. The package includes the SoftwareIdentity class that
is linked to the system using a SoftwareInstalledOnSystem association. Soft-
ware information can be associated with the top level ComputerSystem (if all
components are using the same software) or a component ComputerSystem
if the software loaded can vary by processor.
Common Subprofiles
Common subprofiles are those that are used in multiple profiles, and are thus
described separately. The following common subprofiles are currently defined by
SMIS-S:
1. Access Points Subprofile
The Access Points subprofile is used to indicate remote access points for
management tools. Many SAN devices now have a Web GUI to support
device-specific configuration management. This is modeled using a Remote-
ServiceAccessPoint class linked to the managed element using a HostedAc-
cessPoint association. Where several access points are provided, multiple
instances of the class and association are instantiated and linked to the spe-
cific ComputerSystem class by SAPAvailableForElement.
2. Cluster Subprofile
The Cluster subprofile is used to represent equipment that contains multiple
processing elements that act as a cluster.
When this subprofile is used, each processing element of the cluster is
represented by its own ComputerSystem instance, but is also collected into a
ComputerSystem that represents the system image of the collection of proces-
sors. The linkages between these instances are ComponentCS associations.
There are several subtleties with regard to the association of system devices
to a cluster, depending on whether the device is only available when a par-
ticular constituent processing element is available.
3. Extra Capacity Set Subprofile
The Extra Capacity Set subprofile is used to represent the specific redundancy
offered by a collection of computer systems in a configuration. Thus, this sub-
profile goes beyond the Cluster subprofile described above to specify the rela-
tionship among the systems. Some of these configurations also typically
provide redundancy, which can be of several kinds.
a. Load Balancing This kind typically means that each path to a storage
device through the participating computer systems has equal function-
ality and priority. This type of redundancy is modeled using the Extra-
CapacitySet class with the LoadBalancedSet property set to true. Each
computer system is associated with an ExtraCapacitySet instance using
a MemberOfCollection association. If computer systems operate as
redundant pairs, then there would be multiple ExtraCapacitySet
instances, with one for each pair.
b. Fail-Over This kind typically means that the paths to storage are asym-
metrical. One path will be the primary one, the other(s) are for fail-over
only and have lower performance. In this case the LoadBalancedSet
property is set to false. The priority of different access paths is shown by
the AccessPriority property on the ProtocolControllerForUnit associa-
tions between the StorageVolume and ProtocolController instances.
c. Load Balancing and Fail-Over This kind typically means that load bal-
ancing is occurring across the ExtraCapacitySet and in the event of a fail-
ure another computer system in the set can take over the work of the
failing computer system.
4. Disk Drive Subprofile
An instance diagram of the disk drive subprofile is shown in Figure 6–3. The
subprofile is used to represent a random access storage device. The device is
modeled as a MediaAccessDevice (DiskDrive) containing (MediaPresent)
some logical media (StorageExtent) that are realized (RealizesExtent) by some
physical media. The Disk Drive subprofile ties into the remainder of a stor-
age profile via a number of important associations, as follows:
a. ConcreteComponent associates an extent exported by the DiskDrive to
a StoragePool.
b. BasedOn associates an extent exported by the DiskDrive to another
(higher level) extent (or a Volume).
c. Container associates the physical package of the DiskDrive to the phys-
ical package of the system.
d. ProductParentChild associates the product of the DiskDrive to a higher
level product such as a system.
The profile definition includes a recipe showing how to locate and determine
the capacity of all of the “physical” disk drives in a system.
5. Extent Mapping Subprofile
The Extent Mapping subprofile is used to represent the mapping of specific
storage extents and physical devices. In the StoragePool mechanism, storage
allocation is focused on a logical use of storage in a device. There is little infor-
mation exposed to clients about how data is laid out on underlying extents.
Storage administrators may want to know specifically which disk (or underly-
ing extent) a LUN is on so they can avoid locating frequently used LUNs on
the same extents. The Extent Mapping subprofile allows an agent to represent
this information to the level of a single disk drive or underlying extent.
6. Location Subprofile
The Location subprofile is used to represent the location of a physical device,
using the Location class that is part of the physical elements of the core model
described in Chapter 5.
ComputerSystem
SystemDevice
SoftwareIdentity
Firmware
SystemDevice
DeviceSoftwareIdentity
StorageExtent
DiskDrive
MediaPresent Logical controller
'Logical' media
device
Protocol
RealizesExtent Realizes Controller
AccessesUnit
PhysicalMedia PhysicalPackage
'Physical' media PackagedComponent Physical drive
SCSIProtocolController
Product
Disk drive product info
FIGURE 6–3 Disk Drive Subprofile Instance
7. Software Subprofile
The Software subprofile is used to represent software installed on equipment
in a storage network. It uses the software package as defined above. Infor-
mation on the installed controller software is given using the SoftwareIden-
tity class. This is linked to the controller using an InstalledSoftwareIdentity
association.
8. Copy Services Subprofile
An instance diagram of the Copy Services subprofile is shown in Figure 6–4.
The subprofile is used by an agent to represent the ability to support clones
and point-in-time snapshots of nonvolatile storage. The profile also provides
support for remote replication services (either asynchronous or synchro-
nous) for nonvolatile storage. The Copy Services subprofile currently only
System
(ComputerSystem)
StorageConfigurationCapabilities HostedService
SupportedAsynchronousActions[]
SupportedSynchronousActions[] StorageConfigurationService
SupportedStorageElementTypes[]
SupportedCopyTypes[] CreateReplica()
InitialReplicationState ElementCapabilities ModifySynchronization()
AttachReplica()
StorageVolume StorageVolume
(SourceElement) (Replica)
StorageSynchronized
Note: For simplicy, the StorageCapabilities,

StorageSetting, and ElemenSettingData classes are not shown.
FIGURE 6–4 Copy Services Subprofile
specifies the storage volumes, and has only been validated for use in support
of volume snapshots, although the functionality defined is considerably more
general.
Copy services are addressed by the StorageSynchronized association
between two storage elements that defines their relationship. The model
addresses the use of StorageSynchronized in the context of StorageVolumes
(disk arrays and virtualization systems). The association is a subclass of the
Synchronized association and is used to represent snapshots and mirror
copies of storage elements. StorageSynchronized indicates that two storage
objects were replicated at the specified point in time.
Several different types of replication between the volumes are supported,
as follows:
a. Async In this type, replication creates and maintains an asynchronous copy
of the source. Updates to the source volume are not immediately available
on the copy. The copy is done in the background. This is often used to main-
tain a geographically remote copy of the source volume if the latency over-
head of write synchronization would be too expensive or too slow.
b. Sync In this type, replication creates and maintains a synchronous copy

of the source. Writes done to the source volume are reflected on the
replica volume before control is returned to the host that issued the write
to the source volume.
c. UnSyncAssoc In this type, replication creates an unsynchronized copy
and maintains an association to the source. This type of copy is gener-
ally referred to as a persistent “snapshot” or “point-in-time” copy.
d. UnSyncUnAssoc In this type, replication creates an unsynchronized
copy, but does not maintain the association with the source. This is a
simple copy of a volume, where there is no StorageSynchronized associ-
ation instantiated between the source and the replica.
The following status is also provided on the StorageSynchronized
association:
• Fractured—The relationship has been fractured and is ready for a resync
or restore request. This status also appears for UnSyncAssoc, indicating
that the point-in-time copy (as of the WhenSynced date) has been
completed.
• Synchronized—The Async or Sync relationship is active and copying is
going on.
• Prepared—The association is in a prepared state and ready to be resyn-
chronized.
• Quiesced—The association is in a quiesced state and ready to be
fractured.
• Broken—The source element and the replica have become unsynchro-
nized. Repair actions are required to reestablish the relationship. The
repair action would be to execute a ResyncReplica or a RestoreFrom-
Replica method.
• Initialized—The relationship has been established, but the copy has not
been initiated.
• Idle—The relationship has been established and the copy has been ini-
tiated and completed (for UnSyncAssoc associations).
The Copy Services subprofile supports the following methods:
• Create Replica
• Modify Synchronization (the types of modification defined are: Detach,
Fracture, ResyncReplica, RestoreFromReplica, Prepare, Unprepare, Qui-
esce, Unquiesce, ResetToSync, and ResetToAsync)
• Attach Replica
The methods used are supported in the StorageConfigurationService,
which is hosted (HostedService) on the system that represents the storage
device that supports the service. The specific Copy Service capabilities sup-
ported are specified in the StorageConfigurationCapabilities instance.
9. Job Control Subprofile
The Job Control subprofile is used where some or all of the methods
described by a profile may take some time to execute (longer than an HTTP
time-out), and allows asynchronous execution of the method as a “job.”
When the Job Control subprofile is implemented and a client executes a
method with the ConcreteJob reference as an output, a reference to an
instance of ConcreteJob is returned and the return value for the method is
set to “Method parameters checked - job started.” The ConcreteJob instance
allows the progress of the method to be checked. The associations Own-
ingJobElement and AffectedJobElement are used to indicate the service that
“owns” the job and the element being affected by the job. The element linked
by AffectedJobElement may change through the execution of the job.
10. Pool Manipulation, Capabilities, and Settings Subprofile
The Pool Manipulation, Capabilities, and Settings subprofile is used to rep-
resent the mechanisms exposed by storage systems functions for creating and
modifying storage pools and their capabilities and settings.
A StoragePool is an abstract notion of a blob of consumable storage
space. A pool has a certain set of “StorageCapabilities” that indicate the range
of Quality of Service requirements that can be applied to objects created from
the pool. In this top-level profile, StorageCapabilities are informational only.
Storage pools are defined with a scope that is relative to the Computer-
System (indicated by the HostedStoragePool association). Objects created
from a pool have the same scope. Child objects (such as StorageVolumes or
StoragePools) created from a StoragePool are linked back to the parent pool
using an AllocatedFromStoragePool association. There are two properties of
StoragePool that describe the size of the “underlying” storage. TotalMan-
agedStorage describes the total raw storage in the pool and RemainingMan-
agedStorage describes the storage currently remaining in the pool.
The Primordial Pool is a type of StoragePool. Raw storage capacity—
unformatted or unprepared capacity—is drawn from the Primordial Stor-
agePool to create concrete StoragePools. The Primordial StoragePool
aggregates storage capacity that has not been assigned to a concrete Storage-
Pool. StorageVolumes are allocated from concrete StoragePools and are con-
figured pieces of storage that are exposed from a system through an external
interface. In the class hierarchy they are a subclass of a StorageExtent. In SCSI
terms, StorageVolumes are Logical Units.
This subprofile defines the methods to be used if the storage system
exposes functions for creating and modifying storage pools. The Storage-
ConfigurationService, in conjunction with the abstract concept of a storage
pool, allows generic clients to configure pools of storage within storage arrays
without having to have specific knowledge about the array configuration. The
new service uses the following methods:
a. CreateOrModifyStoragePool—This method creates a pool of storage
with some set of capabilities defined by the input StorageSetting. The
source of the storage can be other pool(s) or storage extents. Alterna-
tively, an existing pool can be modified.
b. DeleteStoragePool—This method deletes a storage pool and returns the
freed-up storage to the underlying entities.
c. CreateSetting—This method creates a setting for use in pool creation
that is consistent with the StorageCapabilities and may be modified
before use in creating a StoragePool.
11. LUN Creation Subprofile

The LUN Creation subprofile is used to represent the ability of a storage sys-
tem that exposes functions for creating storage volumes from storage pools.
The StorageConfigurationService allows generic clients to configure
storage arrays with volumes without having to have specific knowledge about
the storage system capacity. The service uses the following methods for
StorageVolume manipulation:
• CreateOrModifyElementFromStoragePool—This method creates a
StorageVolume, possibly with a specific StorageSetting, from a source
StoragePool.
• ReturnToStoragePool—This method returns an Element previously cre-
ated with CreateOrModifyElementFromStoragePool to the originating
StoragePool.
The StorageCapabilities instances provide the ability to create settings
for use in volume creation using the following method (also part of the
StorageCapabilities class).
• CreateSetting—This method creates a setting that is consistent with the
StorageCapabilities and may be modified before use in creating a
StorageVolume.
The StoragePool instances provide the ability to retrieve the possible sizes
for the StorageVolume creation or modification given a StorageSetting as a
goal, using the following methods:
• GetAvailableSizes—This method returns a list of discrete sizes given a
goal.
• GetAvailableSizeRanges—This method returns the range of possible
sizes given a goal.
Two recipes are included in the definition of this subprofile, as follows:
• Create StoragePool and StorageVolume on an array
• Expand StorageVolume on a storage array
12. Device Credentials Subprofile

The Device Credentials subprofile is used to represent situations in which a
shared secret is required to be able to access a device. This shared secret is
different from the credentials used by the WBEM Client for authentication
with the WBEM service. The client is not to be provided with the password
of the credential, only the principal. The device credentials can be exposed
throughout the CIM model as shared secrets such that a client may manip-
ulate them.
13. Backend Ports Subprofile
The Backend Ports subprofile is used to represent the ability provided by some
storage systems for a client to discover and manage the internal connections
between the array processors and physical disks. For example, an array may
have an interface to acquire and optimize the utilization of separate buses,
loops, or fabrics to back-end storage. In this case, the ports to individual disks
can be modeled similarly to a JBOD configuration. A property of the FCPort
class called UsageRestriction is available to indicate whether the controller is
providing a front-end (target) or back-end (initiator) interface. The RAID
controller itself has front-end ports (that are connected to customer hosts or
switches) and back-end ports (that are connected to the internal disks).
14. LUN Masking and Mapping
An instance diagram of the LUN Masking and Mapping subprofile is shown
in Figure 6–5. The subprofile is used to represent the interface supplied by a
storage system to allow a WBEM Client to specify which initiators (hosts or
HBA ports by WWN) can access which volumes, through which target ports
(by WWN). The effect is that the given volume is only visible to SCSI com-
mands that originate from the specified initiators through specific sets of tar-
get ports. There may also be a capability to select access rights (read write or
read only) and the SCSI Logical Unit Number as seen by an initiator through
a specific set of ports. The ability to limit access is called Device Masking; the
ability to specify the device address seen by particular initiators is called
Device Mapping (for SCSI systems, these terms are known as LUN Masking
and LUN Mapping). The model described in the subprofile is generalized to
include access management in disk arrays, virtualization systems, and routers
used in tape libraries. The model incorporates three object types, as follows:
a. LogicalDevice This object is the superclass of volumes and tape drives.
b. ProtocolController This object is the superclass for controllers of vari-
ous protocols.
A ProtocolController is an implied namespace (or “view”) for
LogicalDevices. The DeviceNumber property of the ProtocolController-
ForUnit class represents the name of the LogicalDevice in the Protocol-
Controller’s namespace. For SCSI protocol storage, the name is the
Logical Unit Number.
StorageHardwareID
* StorageHardwareI * StorageHardwareID
ConcreteDependency
D ManagementService
D
MemberOfCollection
ConcreteDependency
AuthorizedSubject
SystemSpecificCollection CIM_ProtocolController
* MaskingCapabilities
*
AuthorizedSubject
* Privilege
* Privilege
*ConcreteDependency ManagementService
Hosted
Service
LogicalPort
* * AuthorizedTarget
* Element
AuthorizedTarget Capabilities
* LogicalDevice
*
ProtocolController (e.g. StorageVolume)
ProtocolController
ForPort * * HostedService
ProtocolController *
Associated ForUnit
ProtocolController
ConcreteDependency
HostedService
CIM_StorageClient ComputerSystem
ControllerConfigurationService
SettingData
ElementSettingData
HostedCollection
FIGURE 6–5 LUN Mapping and Masking Subprofile
In this subprofile, the existence of a ControllerConfigurationService

with a ConcreteDependency association to a ProtocolController governs
the high-level device mapping policy for that protocol controller. If the
service does not exist, then regardless of host port, the policy is that Pro-
tocolControllerForPort connects a ProtocolController associated to a
LogicalPort. If the service is present, then for a particular host port, the
policy is that ProtocolControllerForPort connects a ProtocolController
to a LogicalPort, but only when access is explicitly granted to either the
ProtocolController or the associated LogicalPort for that particular host
port.
ProtocolControllerForUnit associates a ProtocolController with its
LogicalDevices; the controller-relative address (such as a SCSI Logical
Unit Number) is modeled as the DeviceNumber property of Protocol-
ControllerForUnit.
ProtocolControllerForPort associates a controller to one or more

LogicalPorts.
c. LogicalPort This object is the superclass of target ports for various
transports.
The methods supported by this subprofile are:
• ControllerConfigurationService creates a ProtocolController that is
used as an AuthorizedTarget. If multiple target ports are passed in,
all expose the same view (i.e., the same devices with the same unit
numbers and permission). This method does not create the port
instances, but does create ProtocolControllerForPort associations
between the ports and the new ProtocolController. The new Proto-
colController is weak to the same system as the ControllerConfigu-
rationService.
• DeleteProtocolController deletes the ProtocolController and all as-
sociations that are directly connected to it. If the DeleteChildren-
Protocol-Controllers parameter is True, the provider also deletes
child ProtocolControllers (those at the dependent end of Associated-
ProtocolController associations from this ProtocolController) plus
all child ProtocolControllers’ direct associations. If the Delete-
LogicalUnits parameter is True, the provider also deletes Logical-
Device instances associated via ProtocolControllerForUnit to this
ProtocolController and its children. LogicalDevice instances are only
deleted when they are not part of any ProtocolControllerForUnit
association.
• AttachDevice associates a LogicalDevice subclass to a ProtocolCon-
troller. The agent verifies that unit numbers are unique for each ini-
tiator. When the ProtocolController is already part of an
AuthorizedTarget association, the provider should update the access
configuration in the underlying hardware when AttachDevice is called.
• AssignAccess associates a subject ManagedElement and a target
ManagedElement. If necessary, a Privilege instance is created using
the settings in the method parameter.
• RemoveAccess revokes all privileges or the specified Privilege for a
named target/subject. If a Privilege reference is supplied, then this
method acts only on that specific Privilege; otherwise, all Privilege
instances associated with the named subject/target are affected by
the operation. If a Privilege instance is left with no target associa-
tions, it is deleted.
• CreateStorageHardwareID creates a StorageHardwareID and the
ConcreteDependency association between this service and the new
StorageHardwareID.
• DeleteStorageHardwareID deletes a StorageHardwareID and the
ConcreteDependency association between the ID and the service.
The subprofile contains the following recipes:

• Get the path to a ControllerConfigurationService for a StorageSys-
tem
• Find a service
• Define a permissions view in a ProtocolController
• Remove a permissions view
• Define initiator authorization for a storage volume (read, read/write,
none)
• Deny initiator access to a storage volume
• Remove specific authorization for an initiator
• Set the default access for a storage volume
• Define a view for a SCSIProtocolController
• Remove a SCSIProtocolController View
Profiles
SMI-S profiles are grouped into four areas, depending on their applicability in a
storage network, as follows:
1. Fabric Area, comprising Fabric, Switch, and Router profiles
2. Host Area, comprising Fibre Channel (FC) HBA profile, and Host Discov-
ered Resources profiles
3. Storage Area, comprising Array, In-Band Virtualization, and Storage Library
Profiles
4. Server Area, comprising a Server profile
The profiles are described below. An overview instance diagram of the Fab-
ric, Host, Switch, and Array profiles is shown in Figure 6–6.
Fabric Profile
The Fabric profile represents the interconnection fabric of a storage network, and
is abstracted as a system (in network terms, a “cloud”). The approach follows that
used in the CIM network model, and is logically composed of:
• A set of services such as zoning
• A set of components such as interconnecting elements (e.g., switches) and
platforms (e.g., hosts, storage arrays, and tape libraries)
AdminDomain Contained AdminDomain

Fabric
HostedAccess Component
Domain Point
Component Host Hosted
SAN LogicalNetwork LogicalPortGroup Collection ComputerSystem
MemberOf System
MemberOf Collection Device
Collection ProtocolEndpoint FCPort
DeviceSAP
Implementation
Active
Connection
ProtocolEndpoint Switch FCPort
System
ComputerSystem
Device
DeviceSAP Dedicated="Switch"
Implementation
HostedAccessPoint
Array
Hosted
LogicalPortGroup ComputerSystem
Active Collection
Connection Dedicated="Storage"
MemberOf
Collection System
ProtocolEndpoint FCPort Device
DeviceSAP HostedAccess
Implementation Point
FIGURE 6–6 Fabric, Host, Switch, and Array Overview
A storage network is modeled as containing one or more Fabrics, each of

which is modeled as AdminDomain. The “containment” of Fabrics in SANs is
through the association ContainedDomain. An AdminDomain in CIM is keyed
by the property Name with an associated optional property NameFormat. For
Fibre Channel Fabrics, the identifier is the Fabric WWN that is based on the prin-
cipal switch; the NameFormat should indicate that it is a WWN.
The Fabric profile minimally contains a ConnectivityCollection, and its com-
ponent systems are associated with the Fabric by the Component association.
ConnectivityCollection represents the foundation necessary for routing (and the
reason it is defined in the Network model). A ConnectivityCollection groups a set
of ProtocolEndpoints together that are able to communicate with each other
directly. The ProtocolEndpoint is associated with the ConnectivityCollection by
MemberOfCollection. A link is represented by the association ActiveCollection,
which associates two ProtocolEndpoints, defined as a connection that is currently
carrying traffic or is configured to carry traffic.
Using this approach it will ultimately be possible to represent multiple
instances of ConnectivityCollection (for example, FC, IP [over FC]), and IP ([FC
encapsulated in IP]) for the same fabric.
ZoneMembership
SettingData
ZoneSet
Element
ZoneCapabilities
SettingData MemberOf
System
Collection
Capabilities
Zone Hosted AdminDomain
Collection
Hosted
ZoneService Service
MemberOf
Collection
NamedAddress
Collection
FIGURE 6–7 Zoning Instance Diagram
The zoning services model is defined in a subprofile, and an instance model

for that subprofile is shown in Figure 6–7. The model is based on the Fibre Chan-
nel Generic Service (FC-GS) definitions, and represents the management model
for defining Zone Sets, Zones, and Zone Members, and for activating a Zone Set
in a fabric. The following terms are abstracted from FC-GS for this discussion:
• Active ZoneSet—The Zone Set currently enforced by the Fabric
• Zone Set Database—The database of the Zone Sets not enforced by the
Fabric; referred to in this document as Inactive Zone Sets
• Zoning Definitions—A generic term used to indicate either of the above
concepts
The zoning services model refers to a Zone Set as ZoneSet, a Zone as Zone, a
ZoneAlias as a NamedAddressCollection, and Zone Member as ZoneMember-
shipSettingData. ZoneSets only contain Zones associated by MemberOfCollection.
Zones only contain ZoneMembershipSettingData associated by ElementSettingData
or NamedAddressCollections associated by MemberOfCollection.
The class ZoneMembershipSettingData has two properties that indicate how
the device was identified to be zoned. They are ConnectivityMemberType (such
as PermanentAddress for WWN, NetworkAddress for FCID, etc.) and Connec-
tivityMemberID, which contains the actual device identifier.
The Active Zone Set, defined by an instance of ZoneSet with the Active prop-
erty set to True, is hosted on the AdminDomain representing the Fabric. The Inac-
tive Zone Sets, defined by an instance of ZoneSet with the Active property set to
False, are hosted on either the AdminDomain representing the Fabric, as shown
in Figure 6–6, or the ComputerSystem representing the switch, as shown in Fig-
ure 6–8. The ZoneService and ZoneCapabilities are also associated to the same
System (AdminDomain or ComputerSystem) as the Inactive Zone Sets using the
association HostedService or ElementCapabilities, respectively.
The zoning services model includes extrinsic methods for creating Zone Sets,
Zones, and Zone Members and adding Zones to Zone Sets and Zone Members to
Zones. Additionally, SMI-S defines intrinsic methods for removing Zone Mem-
bers from Zones and Zone Aliases, remaining Zones from Zone Sets, and delet-
ing Zone Members, Zones, and Zone Sets.
The zoning services subprofile defines the following recipes:
• Add new or existing zone member to existing zone
• Create new zone, add new/existing zone member, and add to existing zone
set
• Create new zone set and add existing zone
• Delete zone
• Delete zone set
• Create zone member
• Delete zone member
A separate subprofile defines enhanced zoning services.
Switch Profile
An instance diagram of the Switch profile is shown in Figure 6–8. The switch pro-
file represents the physical and logical aspects of a Fibre Channel fabric intercon-
nect element. The ComputerSystem class constitutes the core of the switch model,
with the Dedicated property set to “switch.”
If a switch is modular—for instance, if the switch is comprised of multiple
blades on a backplane—the LogicalModule class can optionally be used to model
each submodule, and as an aggregation point for the switch ports. FCPort
describes the logical aspects of the port link and the data layers. PhysicalConnec-
tor models the physical aspects of a port. An instance of the FCPortStatistics class
is expected for each instance of the FCPort class. FCPortStatistics expose real-time
port health and traffic information.
Router Profile
An instance diagram of the Router profile is shown in Figure 6–9. The instance
diagram shows a system with parallel SCSI and Fibre Channel buses.
SoftwareIdentity
(Firmware)
Software RemoteService
HostedAccess
InstalledOn AccessPoint
Point
System
FCPort System ComputerSystem
FCPort
System
FCPort FCPort Device Dedicated="Switch"
DeviceFCPortComputerSystem ComputerSystem PhysicalPackage
FCPort
FCPort Dedicated="Switch" Package
Device FCPort
Statistics System ProductPhysical
Device Elements
Module
LogicalModule PhysicalPackage
Port Realizes
FCPortStatistic
s
Product
FIGURE 6–8 Switch Instance Diagram
ControllerConfiguration
MemberOfCollection
Service
FCPort LogicalPortGroup
HostedService
ProtocolControllerForPort
Installed
SoftwareElement
SCSIProtocolController LogicalDevice
ComputerSystem 1 ProtocolControllerForUnit
SoftwareElement ConnectionRole = 'Server'
Dedicated[x]= 'Router' ConcreteIdentity
1
LogicalDevice
ProtocolControllerAccessesUnit
ComputerSystemPackage ConnectionRole = 'Client'
ProductPhysicalComponent Realizes
Product PhysicalPackage
Product PhysicalPackage
FIGURE 6–9 Router Instance Diagram

Product
ProductPhysical FCPortStatistic
SCSIProtocolController Concrete FCPort
Elements SCSIController FCPort Statistics s
Identity
PhysicalPackage
Realizes
SystemLogicalPortGroup Hosted
ComputerSystem MemberOf
ComputerSystem
Device Collection LogicalPortGroup
Package Collection
MemberOf HostedCollection System
Collection Device ControlledBy
ComputerSystem SystemFCPort
PortController
Device
Device
Software Device
Identity Software
Installed Device
Identity
SoftwareElement Software
Identity
SoftwareIdentity SoftwareIdentity SoftwareIdentity
(Driver) (Firmware) (ROM BIOS)
FIGURE 6–10 FC HBA Instance Diagram
The Router profile represents devices that translate between different types
of SCSI buses. Devices on the parallel bus are served to the Fibre Channel bus
without changing the characteristics of the device.
FC HBA Profile
An instance diagram of the FC HBA profile is shown in Figure 6–10. The instance
diagram represents an HBA as a physical device that contains one or more Fibre
Channel ports. A single system may contain one or more HBAs.
An HBA is represented by FCPorts associated to a ComputerSystem through
the SystemDevice association.
The containment aspect of the HBA’s physical implementation is modeled by
the FCPorts being associated to PhysicalPackage (typically Card) through the
Realizes association. If the HBA has logical operations that apply to the HBA and
not to an individual port, then the PortController can also be instantiated. The
PortController is associated to the ComputerSystem through the SystemDevice
association and associated to the ports through the controlled by association.
Host Discovered Resources Profile

The Host Discovered Resources profile represents the discovery of SAN resources
and presentation of those resources to the Host Operating System by an HBA.
FCPort
SystemDevice ProtocolControllerForPort
ComputerSystem SCSIProtocolController
ProtocolControllerForUnit
SystemDevice
StorageVolume StorageSetting
ElementSettingData
AllocatedFromStoragePool
StoragePool StorageCapabilities
ElementCapabilities
HostedStoragePool
FIGURE 6–11 Array Instance Diagram
The Host Discovered Resources agent uses the HBA API—first standardized
by SNIA, and now taken up by INCITS T11—to create a generic model of the
logical SAN and attached storage. The agent models elements also exposed by
HBA, storage, and switch agents. A client can use durable names to equate objects
from different agents. The profile is restricted to FCP (SCSI over FibreChannel)
discovery.
Because the objects in this profile are discovered remotely through an HBA,
only their logical aspects are available. In general, the objects exposed by this agent
duplicate those exposed by canonical HBA, storage, or switch agents that provide
the physical model.
The Host SAN Resources are independently instantiated for each HBA
FCPort on a host. They include its discovered (remote) FCP ports and SCSI
Targets.
The profile includes two optional subprofiles, an Initiator subprofile and
a Target subprofile. SCSI Targets are modeled by FCPorts with a ProtocolCon-
trollerForPort to a SCSIProtocolController that, in turn, has at least one
ProtocolControllerForUnit association to a LogicalDevice. The SCSIProtocol-

Controller and FCPort combination represents a SCSI Port with Target capabil-
ity. The LogicalDevice in such associations represents SCSI Target Logical Units.
SCSI Initiators (HBA ports) are also modeled with a SCSIProtocolController
and FCPort combination. Initiator SCSIProtocolControllers have ProtocolCon-
trollerAccessesUnit associations to logical units (LogicalDevice subclasses) that
are mapped to the HBA host.
Array Profile
An instance diagram of the Array profile is shown in Figure 6–11. The profile rep-
resents the manageable features of external RAID arrays and disk storage systems.
The key classes contained in the profile are:
• ComputerSystems that represent the array as a whole
• StorageVolumes that are equivalent to SCSI Logical Units visible to con-
sumers
• StoragePools that are the allocatable/available space on the array
• FCPorts through which the LUNs are made available
The basic Array profile provides a high-level read-only “view” of an array. An
additional set of (common) subprofiles extends this description and also enables
active configuration of the array. The terminology used in the description of this
profile, storage pools, primordial pools, and storage volumes, was defined in the
Pool Manipulation, Capabilities, and Settings subprofile above.
In-Band Virtualization Profile

An instance diagram of the In-Band Virtualization profile is shown in Figure 6–12.
This profile represents a virtualization system that uses storage provided by array
controllers to create a seamless pool of storage. The virtualization system in turn
allocates volumes from the pool for host systems to use.
The basic Virtualization System profile provides a read-only view of the sys-
tem information. The Virtualization system is modeled using the ComputerSys-
tem class with the Dedicated properties set to “BlockServer” and
“InBandVirtualization.” The model allows the system to be a cluster or contain
redundant components, but the components act as a single system. The Comput-
erSystem class and common Cluster Subprofile model this behavior. The Storage-
Pool classes in the center of the diagram represent the mapping from array storage
to volumes for host access. The pool is hosted on the ComputerSystem and serv-
ices to control it are hosted on the same controller. The StorageExtent at the bot-
tom of the figure represents the storage from external arrays used by the mapping.
These StorageExtents are connected to the pool using the ConcreteComponent
association. StorageVolumes at the upper right of the figure are the volumes cre-
ated from the StoragePool and are accessible from hosts. The associations to the
ProtocolControllerForUnit ProtocolControllerForPort
ComputerSystem StorageVolume FCPort

Dedicated[x]=
'InbandVirtualization' LUID: //VPD pg 83 ID
DefaultAccessMode
HostedStoragePool
ElementSettingData
StoragePool
StorageSetting
ProtocolControllerAccessesUnit ProtocolControllerForPort
ConcreteComponent
FCPort
StorageExtent SCSIProtocolContoller
Name: //VPD pg 83 ID
DefaultAccessMode
FIGURE 6–12 In-Band Virtualization Instance Diagram
SCSIProtocolController and to the FCPort indicate ports to which the volume is

mapped. The StorageVolumes are described by the StorageSetting class connected
by the ElementSettingData association.
Storage Library Profile

The Storage Library profile represents various forms of removable media libraries.
The profile incorporates three different instance diagrams for different compo-
nents of the library.
1. System level
An instance diagram of the system level of the Storage Library profile is
shown in Figure 6–13.
2. Media Access Devices
Both MediaAccessDevice and ProtocolController are connected to a Stor-
ageLibrary instance through the SystemDevice association. Note that in some
libraries, notably small autoloaders, external hosts access a library’s Chang-
erDevice through the ProtocolController of a MediaAccessDevice. For such
libraries, an additional ProtocolControllerForUnit association should be
instantiated between the MediaAccessDevice’s ProtocolController and the
affected ChangerDevice. ProtocolControllerForUnit is a many-to-many asso-
ciation, so a single ProtocolController can be connected to multiple Logi-
calDevices if this accurately represents a library’s configuration.
Product
ProductPhysicalElements
Chassis
LibraryPackage
StorageLibrary
SystemDevice
SystemDevice
ProtocolController
MediaAccessDevice SystemDevice
ProtocolControllerForUnit
ChangerDevice
TapeDrive
FIGURE 6–13 Storage Library System-Level Instance Diagram
3. Media Changers
Media Changers are modeled using StorageMediaLocation and Magazine.
Two implementation alternatives are presented by SMI-S:
a. Instantiate multiple Magazines associated to Chassis via Container, then
instantiate StorageMediaLocations that are contained (again via Con-
tainer) within each Magazine.
b. Instantiate multiple StorageMediaLocations directly associated to Chas-
sis via Container, without the use of Magazines. Other optional classes,
such as Panel, may also be used to group StorageMediaLocations.
For each LogicalDevice that can hold media, at least one StorageMedia-
Location must be associated via Realizes.
The profile contains a Limited Access Port Elements subprofile that rep-
resents the limited access ports elements (items such as mail slots, cartridge
access port, or import/export elements) found in many libraries. This sub-
profile defines the required classes necessary to publish information about
these elements.
80
ObjectManager System
HostedService
Name (InstanceID)
ElementName
Namespace
CommMechanismForManager
InManager
Namespace
CIMXMLCommunicationMechanism
[Propagated Keys]
CreationClassName [Default CommunicationMechanism = "XML over HTTP"]
Name CIMValidated
ClassInfo
DescriptionOfClassInfo
ManagedElement
(e.g., System)
ReferencedProfile
ElementConformsToProfile
RegisteredProfile
InstanceID
RegisteredOrganization
OtherRegisteredOrganization
RegisteredName
RegisteredVersion
AdvertiseTypes[]
AdvertiseTypeDescriptions[]
SubProfile SubProfile
RequiresProfile RequiresProfile
RegisteredSubProfile RegisteredSubProfile
InstanceID InstanceID
RegisteredOrganization RegisteredOrganization
OtherRegisteredOrganization OtherRegisteredOrganization
RegisteredName RegisteredName
RegisteredVersion RegisteredVersion
AdvertiseTypes[] AdvertiseTypes[]
AdvertiseTypeDescriptions[] AdvertiseTypeDescriptions[]
FIGURE 6–14 Server Instance Diagram

Server Profile
An instance diagram of the Server profile is shown in Figure 6–14. The profile is
used to represent the functionality of the WBEM service itself, using the interop
model defined in Chapter 5.
The profile defines the interop Namespace and the use of the interop Name-
space for finding RegisteredProfiles and other related classes associated with the
Server profile. The interop Namespace refers to the first namespace found in the
InteropSchemaNamespace attribute of the SLP Template.
A Server is modeled as a System with a HostedService association to an
ObjectManager. The ObjectManager is a subclass of Service, and defines the capa-
bilities of an Object Manager based on the communication mechanisms that it
supports.
The namespace model of the Server profile describes the namespaces man-
aged by the ObjectManager and the type of information contained within the
namespace. All namespaces supported by the Server can be identified by the
Namespace class and associated to the ObjectManager via the NamespaceInMan-
ager association. All classes of the Server profile are in the interop Namespace,
with the exception of the ManagedElement instance that is referenced from the
RegisteredProfile.
The RegisteredProfile part of the model is used to specify the profiles sup-
ported by the ObjectManager. It also includes the specification of subprofiles that
are supported by the profile. A profile is modeled using the RegisteredProfile class.
One instance is created for each ManagedElement that is covered by a profile and
is managed by the Server. The RegisteredProfile instances can be found by enu-
merating RegisteredProfiles within the Interop Namespace. A WBEM Client
would find all profiles supported by the Server by enumerating RegisteredProfiles,
enumerating RegisteredSubprofiles, and subtracting the second list from the first
list. This will yield the list of profiles supported by the ObjectManager. For each
profile instance, the subprofiles that have been implemented (for the instance)
should be identified via the SubprofileRequiresProfile association. Subprofiles are
modeled using the RegisteredSubprofile class. The ElementConformsToProfile
association ties the RegisteredProfile to one or more ManagedElements. These
ManagedElements are typically ComputerSystems or AdminDomains, and may
have zero or more ElementConformsToProfile associations to RegisteredProfiles.
Available Tools and

Development Facilities
A number of development tools and facilities are available to developers of CIM,

WBEM, and SMI-S functionality. This chapter describes open source code, devel-
opment environments, established practices, test programs, and interoperability
facilities that are available to developers wishing to instrument their products to
conform to, or obtain information through, the storage management interface.
Development Tools
The following items have been found useful by developers in the SNIA commu-
nity to date. No representation is made here as to the suitability of any of these
tools; they are merely listed for information. In addition, many of these items are
licensed under specific terms, which must be investigated before any code is used.
CIM Object Managers

Three open source CIMOMs are available.
SNIA
SNIA has made a source package available to its members that is a Java-based
implementation of an Object Manager. The SNIA implementation provides both
client and server CIM/WBEM technologies. Use of Java as the implementation
language allows adoption of the technology without the need for porting or long-
running test and integration periods. The first version of this source became avail-
able in June 2000 and was last updated in August 2000. For more details, see
http://www.snia.org/smi/developers/cimom.
83
Pegasus
Pegasus has been developed as a project of The Open Group’s Enterprise Man-
agement Forum. It was conceived as an open source reference implementation of
the DMTF WBEM specifications, but has become a set of production-quality open
source code designed to be used in high-volume server implementations. Many
existing SMI-S-compatible Object Managers are based on this code.
Pegasus defines a modular, powerful instrumentation environment with the
intention of speeding up the process of making equipment manageable. It only
implements the WBEM service, and is therefore not a complete management envi-
ronment.
Pegasus was designed from the beginning for multiplatform, multi-OS, mul-
ticompiler implementation. It has so far been ported to various UNIX (AIX,
HPUX, Solaris, Tru-Unix), Linux, and Windows platforms (NT, 2000, 9x), and the
Compaq Himalaya (Tandem) platform.
For full details on Pegasus, including the code and a development manual,
see http://www.openpegasus.com/.
OpenWBEM
The OpenWBEM project is an open source implementation of Web-Based Enter-
prise Management suitable for commercial and noncommercial applications.
OpenWBEM is intended to be built using GNU compilers and a number of other
GNU tools. It supports the integration of SLP with the Object Manager using
OpenSLP. It includes a C Client API library, and an MOF Compiler with an
embeddable library.
The source code for OpenWBEM is maintained in a project at SourceForge
(see https://sourceforge.net/project/showfiles.php?group_id=16214 for access).
CIM Miner
CIM Miner is a utility that “mines” a specified CIMOM namespace for instances
and associations, and stores the discovered information in an XML format file.
This file can be viewed directly using the supplied XSLT file. It can also be trans-
formed into HTML using the “transform” batch file and a supplied XSLT file. CIM
Miner was developed by SNIA SMI participants, but has now been made avail-
able to the DMTF and is available from the latter’s tools page (see below).
DMTF Tools
The Members section of the DMTF Web page lists a number of tools related to
the WBEM definitions, including:
1. Nortel Networks MOF to HTML Converter
Nortel Networks has developed the mof2html tool to convert the CIM
schema and any extension MOF files into browsable HTML files. The tool is
released in C source code format. Instructions for building and running
it are contained in the README.txt file. This is an initial but usable release
of this tool, and extensions are encouraged.
2. Microsoft MOF Editor
Microsoft has developed an MOF Editor, and has granted distribution rights
to the DMTF.
3. Intel CIM Compatibility Checker
The CIM Compatibility Checker (CCX) is a platform-independent applica-
tion that tests a system’s CIM implementation for conformance with the
DMTF’s CIM v2.3 definitions. Additionally, the CCX tool conforms to the
DMTF’s “Specification for CIM Operations over HTTP v1.0” and “xmlCIM
v2.0.” Two tests are provided: class definitions testing and class instance and
associations testing. In both tests, schema definitions and class definitions
such as class properties and associations are verified for existence and correct
data type.
CCX may also function as a design and debug tool. A CIM parser reports
any syntax errors encountered while parsing the schema and requirements
files.
For more information, see http://www.dmtf.org/members/tools.
CIM Navigator
CIM Navigator is a Java client application that can be used to graphically browse
CIM objects and their associations in various CIM Object Managers. The appli-
cation can be downloaded from either http://www.cimnavigator.com or from
http://www.wbemsource.org (the pages of The Open Group’s WBEMSource
Initiative).
Development Facilities
The SMI program at SNIA is a wide-ranging effort and incorporates activities
beyond merely creating the SMI specification (see Figure 7–1). Other aspects of
the program include:
1. ICTP
ICTP is a SNIA-wide initiative called the SNIA Interoperability Conformance
Test Program. ICTP consists of master test suites that are developed, owned,
and operated by SNIA. ICTP is an integral step toward providing verification
that a storage vendor’s product implementation complies with the SMI spec-
ification. For more information, including the costs of participation in the
program, see http://www.snia.org/tech_activities/ictp/.
2. SMI-Lab
SMI-Lab is the SNIA-hosted program that is used by storage vendors to
pretest their SMI implementation before entering formal ICTP testing.
Management In
rage itiat
iv
to SMI-S
e
S
Open Technical
Interface Steering
Group
Storage
Management
Forum Education
SMI-Lab ICTP
Developer’s
Network
SMI
... m o r e t h a n a s p e c ifi c a ti o n
FIGURE 7–1 SMI Program
Although participation in SMI-Lab is not mandatory, it is highly recom-

mended. SMI-Lab provides manufacturers with access to multivendor stor-
age devices as well as a neutral environment in which to run through the
ICTP master test suites and fine-tune their code to the specification. SMI-
Lab is hosted at the SNIA Technology Center in Colorado Springs, Colorado
(see http://www.snia.org/tech_center/ for more information). SMI-Lab is also
used as a prestaging event for SMI operability demonstrations that take place
at the twice-yearly StorageNetworkingWorld conferences.
3. Education
SNIA regularly schedules week-long classes to introduce developers to the
WBEM technologies, and an annual conference (“summit”) focused on all
technical and business aspects of storage management. For the latest infor-
mation on these events, see http://www.snia.org/smi/education.
4. Developer’s Network
The Storage Management Developer’s Network has been created to assist
worldwide SMI developers in implementing the SMI Specification (SMI-S)
from project conception to product delivery. The SMI-S Developer’s Network
is focused on the following:
• Increasing understanding of the specification by providing online access
to tutorials, training, and a place to get questions answered
• Providing technical assistance in getting started by providing access to

the basic information needed to start developing and a Consultants
Directory for those who need additional assistance
• Providing ongoing support throughout the development process by cre-
ating an online community where SMI-S developers worldwide can meet
to share information and knowledge and assist each other throughout
the development process.
• Providing support during the testing process through the SMI-Lab and
ICTP programs
For more information, see http://www.snia.org/smi/developers.
Future Developments
and Goals
One of the major advantages of the WBEM definitions underlying SMI is their
leverage of existing standards such as XML and definition of an extensible schema.
This flexibility will be exploited to the full in future versions.
Future revisions of SMI-S will be synchronized with the release of new ver-
sions of the CIM schema. The final version of future SMI-S revisions will closely
follow the final release of a specific CIM schema version.
Both SNIA and DMTF have plans to add considerable functionality to the
definitions available for storage management, and these are described separately
below. DMTF’s approach to the addition of functionality to the schema is often
to declare that new class definitions are “experimental” so as to highlight the fact
that the definitions are likely to change in the next version after implementation
experience is gained. Following this convention, SMI-S contains an annex of
experimental profiles that are expected to be developed further and included in a
future revision as mandatory items.
SNIA SMI
The following sections detail plans already in place for enhancements to SMI-S
functionality in future revisions.
Revision 1.0.1
The existing SMI-S document contains an annex that describes a number of
enhancements to the SMI definitions that have already been worked on to some
extent, and will be finalized for a future revision. The following experimental pro-
files are defined in the annex:
89
• A Common Sparing subprofile

• SML InterLibrary Port Connection, Partitioned/Virtual Library, Fibre Chan-
nel Connection, Library Capacity, and LibraryAlert Events/Indications for
Library Device subprofiles
• An Extender profile
• A Management Appliance profile
• An Out-of-Band Virtualizer profile
• A JBOD (Just a Bunch of Disks) profile
A provider subprofile is also defined in a separate annex.
Revision 1.1
SMI-S revision 1.1 will be synchronized with CIM schema version 2.9. Items being
considered for SMI-S revision 1.1 include:
• Integration of HBA LUN masking and persistent binding with other
standards
• Definition of managed hubs as a storage networking component
• Support for IP storage, including IP security and authentication
• Extension of the array profile to support multipathing
• Support for non-FC fabrics such as InfiniBand and IP networks
• Support for a multilevel agent hierarchy (in which a given agent could pro-
vide a management interface to higher level devices while simultaneously
relying on the management interface provided by agents below it)
• In-depth support for network-attached storage
• Support for an additional profile addressing recursive extent mapping
Revision 1.x Wish List

The following items have also been discussed for inclusion in a future SMI-S revi-
sion:
• A mechanism for interoperably referencing device icons/pictures
• An ability to display and manipulate device control information, including
representations of SCSI Mode Pages
• Support for internationalization, for example, the ability to deal with local-
ized text and captions
• Support for storage Quality of Service definitions
Chapter 8 Future Developments and Goals 91
Future Revisions
Two major items, locking and policy, are also being addressed for inclusion in
SMI-S at some future point. These items may well require work by both SNIA
and DMTF.
Locking
A locking model is required to assure data integrity in situations where multiple
WBEM Clients are actively managing the same storage network. Locking will
allow the execution of multiple methods across multiple objects within a protec-
tion boundary. This may require the addition of a Lock Manager to the reference
model defined in Figure 5–2.
Policy
CIM schema version 2.8 already incorporates a rich (common) policy model, and
use of this model is expected to be a key inclusion in future SMI-S revisions in
order to provide the following capabilities:
• Provide a mechanism for a persistent repository of policies expressed in a
standard interchange format that can be read and acted on by the appropri-
ate policy mechanisms in the environment
• Allow SMI-S policy clients to enter and edit storage management policy
information in the persistent repository
• Allow a policy manager to be notified when policies that it processes are
added or changed
• Enable SMI-S agents by defining events that trigger policy actions
The objectives for policies in SMI-S are to:
• Define a mechanism that allows separation of policy specification and policy
execution
• Define a mechanism that supports distributed policy management
• Define a mechanism that allows common interchange of policy specification
information
• Define a mechanism that standardizes “triggers” for policy-based manage-
ment and augments SMI-S agents as needed to reveal triggering events
• Identify methods that SMI-S agents need in order to support a standard set
of policy actions
• Provide a mechanism that can be scaled to handle enterprise environments
• Enable one or more Policy Managers to analyze, invoke, and maintain poli-
cies in the policy server
This will require the addition of a Policy Manager to the reference model
defined in Figure 5–2, and also the definition of Policy Client, Server, and Man-
ager.
Long-Term Approach
SNIA’s ultimate intention with regard to SMI-S is to develop higher order func-
tionality than is now defined in Revision 1.0.1, thus relieving the burden placed
on WBEM Clients to perform low-level management functions and enhancing
scalability and interoperability in a heterogeneous storage network.
DMTF
DMTF is already planning for a major new revision of CIM (3.x), and items that
have been discussed include the following:
• Transactions
• Management console standards
• Application hooks and quiescence
• LDP/single sign-on
• Fault isolation and problem detection
• Policy compliance and configuration
Summary
This booklet has provided a basic grounding in the history of network manage-
ment interfaces and interface definitions as a background and introduction to the
work being performed by the SNIA as part of the Storage Management Initiative.
It has contrasted the characteristics of predecessor definitions with the SNIA SMI,
and described how the richness of the information model and extensibility of the
definitions can support new functionality. It has provided an overview of tech-
nology underlying the definitions produced by SMI and the application of those
definitions to the management of types of equipment commonly found in a stor-
age network. Development tools that are available to speed the adoption of the
underlying technologies in management applications have been described, and
future developments in those technologies anticipated. In short, the booklet has
provided a primer for SNIA members to the exciting developments in manage-
ment technologies now taking place. The SMI program in SNIA is building toward
the “holy grail” of storage management—namely, the situation in which an appli-
cation can discover a previously unseen type of device in a storage network and
immediately bind to it and provide a level of management functionality. SNIA
members are requested to use the information provided in this text and the ref-
erences contained in the appendices to enhance their products and management
applications and significantly simplify the administrative burden imposed by
storage networks, thus literally helping to fulfill the “efficient” part of the SNIA
mission.
93
APPENDIX
Applicable Standards
The following is a list of industry standard activities that define, or are relevant
to, the management technologies described in the text of this document. The list
is divided into two sections, one of which deals with completed and/or published
standards and the other with known works in progress. Wherever possible, sources
of each document are identified, whether they be available online or only in print.
By definition, all of these documents have a life cycle; new standards are being
approved, new versions are constantly becoming available, and old versions get
withdrawn. Therefore, if a specific version referenced here is not available, it is
recommended that the relevant accredited standards organization be contacted to
obtain the most up-to-date information. The contact information for each accred-
ited standards body mentioned is given at the end of the list.
Published and/or Completed Standards

Chapter 3 A Brief History of Management Protocols
CCITT recommendation X.409
ISO International Standard 8824 Information Processing Systems - Open Systems
Interconnection - Specification of Abstract Syntax Notation One (ASN.1), Inter-
national Organization for Standardization, December 1987.
ISO International Standard 8825 Information Processing Systems - Open Systems
Interconnection - Specification of Basic Encoding Rules for Abstract Notation
One (ASN.1), International Organization for Standardization, December 1987.
IETF RFC1028 Simple Gateway Monitoring Protocol. J. Davin, J. D. Case,
M. Fedor, M. L. Schoffstall. Nov-01-1987. (Format: TXT82440 bytes) (Status:
HISTORIC)
95
SNMP is defined by the following IETF RFCs:

IETF RFC1157 Simple Network Management Protocol (SNMP). J. D. Case, M.
Fedor, M. L. Schoffstall, C. Davin. May 1990. (Format: TXT74894 bytes) (Obso-
letes RFC1098) (Also STD0015) (Status: STANDARD)
IETF RFC1213 Management Information Base for Network Management of
TCP/IP-Based Internets: MIB-II. K. McCloghrie, M. T. Rose. March 1991. (For-
mat: TXT146080 bytes) (Status: STANDARD)
IETF RFC1441 Introduction to Version 2 of the Internet-Standard Network Man-
agement Framework. J. Case, K. McCloghrie, M. Rose, S. Waldbusser. April 1993.
(Format: TXT25386 bytes) (Status: PROPOSED STANDARD)
IETF RFC1901 Introduction to Community-Based SNMPv2. J. Case, K.
McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT15903 bytes)
(Status: EXPERIMENTAL)
IETF RFC1902 Structure of Management Information for Version 2 of the Sim-
ple Network Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose,
S. Waldbusser. January 1996. (Format: TXT77453 bytes) (Status: DRAFT STAN-
DARD)
IETF RFC1905 Protocol Operations for Version 2 of the Simple Network Man-
agement Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. Jan-
uary 1996. (Format: TXT55526 bytes) (Obsoletes RFC1448) (Status: DRAFT
STANDARD)
IETF RFC1906 Transport Mappings for Version 2 of the Simple Network Man-
agement Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Waldbusser. Jan-
uary 1996. (Format: TXT27465 bytes) (Obsoletes RFC1449) (Status: DRAFT
STANDARD)
IETF RFC1907 Management Information Base for Version 2 of the Simple Net-
work Management Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S. Wald-
busser. January 1996. (Format: TXT34881 bytes) (Obsoletes RFC1450) (Status:
DRAFT STANDARD)
IETF RFC1908 Coexistence between Version 1 and Version 2 of the Internet-
Standard Network Management Framework. J. Case, K. McCloghrie, M. Rose, S.
Waldbusser. January 1996. (Format: TXT21463 bytes) (Obsoletes RFC1452)
(Obsoleted by RFC2576) (Status: DRAFT STANDARD)
IETF RFC2571 An Architecture for Describing SNMP Management Frameworks.
B. Wijnen, D. Harrington, R. Presuhn. April 1999. (Format: TXT139260 bytes)
(Obsoletes RFC2271) (Status: DRAFT STANDARD)
IETF RFC2576 Coexistence between Version 1, Version 2, and Version 3 of the
Internet-Standard Network Management Framework. R. Frye, D. Levi, S.
Routhier, B. Wijnen. March 2000. (Format: TXT98589 bytes) (Obsoletes
RFC1908, RFC2089) (Status: PROPOSED STANDARD)
IETF RFC2578 Structure of Management Information Version 2 (SMIv2). K.

McCloghrie, D. Perkins, J. Schoenwaelder. April 1999. (Format: TXT89712
bytes) (Obsoletes RFC1902) (Also STD0058) (Status: STANDARD)
IETF RFC2579 Textual Conventions for SMIv2. K. McCloghrie, D. Perkins, J.
Schoenwaelder. April 1999. (Format: TXT59039 bytes) (Obsoletes RFC1903)
(Also STD0058) (Status: STANDARD)
IETF RFC2580 Conformance Statements for SMIv2. K. McCloghrie, D. Perkins,
J. Schoenwaelder. April 1999. (Format: TXT54253 bytes) (Obsoletes RFC1904)
(Also STD0058) (Status: STANDARD)
Chapter 4 An Overview of Current Management Techniques

IETF RFC2837 Definitions of Managed Objects for the Fabric Element in Fibre
Channel Standard. K. Teow. May 2000. (Format: TXT87860 bytes) (Status:
PROPOSED STANDARD)
INCITS 332:2003 MIB-FA. May 2003.
Chapter 5 An Introduction to Web-Based Enterprise Management and SMI-S

DMTF DSP200 Specification for CIM Operations over HTTP, Version 1.1, Janu-
ary 2003.
DMTF DSP201 Specification for the Representation of CIM in XML, Version 2.1,
January 2003.
W3C “Extensible Markup Language (XML),” Version 1.0 (Second Edition), Octo-
ber 2000.
DMTF DSP004 Common Information Model (CIM) Specification, Version 2.2,
June 1999.
The Open Group C706 DCE 1.1: Remote Procedure Call, 1997.
IETF RFC2608 Service Location Protocol, Version 2. E. Guttman, C. Perkins, J.
Veizades, M. Day. June 1999. (Format: TXT129475 bytes) (Updates RFC2165)
(Updated by RFC3224) (Status: PROPOSED STANDARD)
IETF RFC2609 Service Templates and Service: Schemes. E. Guttman, C. Perkins,
J. Kempf. June 1999. (Format: TXT72842 bytes) (Updates RFC2165) (Status:
PROPOSED STANDARD)
IETF RFC2610 DHCP Options for Service Location Protocol. C. Perkins, E. Gutt-
man. June 1999. (Format: TXT10859 bytes) (Status: PROPOSED STANDARD)
IETF RFC2614 An API for Service Location. J. Kempf, E. Guttman. June 1999.
(Format: TXT164002 bytes) (Status: INFORMATIONAL)
IETF RFC2279 UTF-8, a Transformation Format of ISO 10646. F. Yergeau. Janu-
ary 1998. (Format: TXT21634 bytes) (Obsoletes RFC2044) (Status: DRAFT
STANDARD)
Chapter 6 Profiles of Storage Network Equipment Types.

INCITS 348:2000 FC Generic Services 3 (FC-GS-3), August 2000.
INCITS X3.269:1996 [R2001] Fibre Channel Protocol (FCP), October 1996.
INCITS 350:2003 Fibre Channel Protocol - 2 (FCP-2), May 2003.
INCITS TR-30:2002 Fibre Channel - Methodologies for Interconnects, December
2001.
Significant Works in Progress

Chapter 5 An Introduction to Web-Based Enterprise Management and SMI-S
SNIA Storage Management Initiative Specification (SMI-S), Version 1.0.1, Sep-
tember 2003.
Chapter 6 Profiles of Storage Network Equipment Types

INCITS T11/04-031v0 FC Generic Services 4 (FC-GS-4), January 2004.
INCITS T11/03-108v6 FC HBA API, December 2003.
Publishing Organization Information

Storage Networking Industry Association (SNIA)
The SNIA’s main Web site is: http://www.snia.org
See: http://www.snia.org/smi/home to access the latest documents listed
above.
See: http://www.snia.org/members/ to access pages of the active SNIA
working groups, committees, and forums (membership is required to
access these pages). SNIA has organizations in Europe and Japan, in addi-
tion to North America.
The SNIA Secretariat is located at:

Storage Networking Industry Association
50 California Street, Suite 1500
San Francisco, CA 94111 USA
1.415.277.5415 (voice)
Many activities related to storage management are held at the following location:
SNIA Technology Center
301 Rockrimmon Blvd. South
Colorado Springs, CO 80919 USA
1.719.884.8902 (voice)
1.719.884.8912 (fax)
Distributed Management Task Force (DMTF)

The DMTF’s main Web site is: http://www.dmtf.org.
See: http://www.dmtf.org/standards to access the latest documents listed
above.
See: http://www.dmtf.org/members to access pages of active working
groups (membership is required to access these pages).
The DMTF Secretariat is located at:

Distributed Management Task Force
c/o Kavi Corporation
225 SE Main St.
Portland, OR 97214 USA
1.503.963.3505 (voice)
1.503.238.8721 (fax)
Internet Engineering Task Force (IETF)

The IETF’s main Web site is: http://www.ietf.org.
See: http://www.ietf.org/rfc/rfcNNNN.txt. (NNNN is the RFC number
prefixed with zeroes as necessary to make a four-digit number to gain
access to the IETF standards listed above.)
See: http://www.ietf.org/html.charters/wg-dir.html to access pages of the
active IETF Working Groups engaged in standards creation.
See: http://www.ietf.org/ID.html to access all current working drafts directly.
The IETF Secretariat is hosted by the Corporation for National Research Initia-
tives. It can be reached at:
IETF Secretariat
c/o Corporation for National Research Initiatives
1895 Preston White Drive, Suite 100
Reston, VA 20191-5434 USA
1.703.620.8990 (voice)
1.703.620.9071 (fax)
The Open Group

The Open Group’s main Web site is: http://www.opengroup.org.
See: http://www.opengroup.org/products/publications/catalog/code.htm to
access the latest documents listed above.
See: http://www.opengroup.org/forums/ to access pages of active working

groups (membership is required to access these pages).
The Open Group Secretariat is located at:

The Open Group
44 Montgomery Street, Suite 960
San Francisco, CA 94104-4704 USA
1.415.374.8280 (voice)
1.415.374.8293 (fax)
The Open Group also has offices in the UK and Japan, and a number of regional
chapters. See http://www.opengroup.org/contacts/ for more information.
World Wide Web Consortium

The World Wide Web Consortium’s (W3C’s) main Web site is: http://www.w3.org.
See: http://www.w3.org/QA/TheMatrix to access the latest documents listed
above.
See: http://www.w3.org/2002/03/new-to-w3c to find out how to participate
in W3C.
See: http://www.w3.org/Consortium/Offices/ for information on the W3C
offices hosted by organizations in the US, Europe, and Japan.
International Committee for Information Technology

Standardization (INCITS)
The main INCITS Web site is at: http://www.incits.org.
See: http://www.techstreet.com/incitsgate.html to purchase copies of
INCITS standards.
See: http://www.incits.org/tcs.html to access pages of the active INCITS
Working Groups engaged in standards creation. For works in progress, see
the Web sites of INCITS Technical Committee T10 (responsible for stan-
dardizing SCSI) at http://www.t10.org, and INCITS Technical Committee
T11 (responsible for standardizing Fibre Channel) at http://www.t11.org.
The INCITS Secretariat is administered by staff of the Information Technology

Industry Council (http://www.itic.org), located at:
Information Technology Industry Council
1250 Eye Street NW, Suite 200
Washington, DC 20005 USA
1.202.737.8888 (voice)
1.202.638.4922 (fax)
APPENDIX
Recommended
Bibliography
The following is an annotated bibliography of information that the author of this

document, and other members of the SNIA SMI, have found useful in learning
about management technologies and techniques. The bibliography is divided into
two sections, one of which deals with publications and the other with online infor-
mation sources. All of the items in the second section were determined to be oper-
able at the time of publication, but obviously no guarantee can be made of their
continued availability. An up-to-date version of this list can be obtained from the
SNIA Web site at http://www.snia.org.
Publications
For information on CIM and WBEM see:
Bumpus, Winston, et al., Common Information Model, New York: Wiley, August
2000 (ISBN 0-471-35342-6).
For information on SLP see:
Kempf, J. and P. St. Pierre, Service Location Protocol for Enterprise Networks, New
York: Wiley, May 1999 (ISBN 0-471-31587-7).
Guttman, Erik, Service Location Protocol: Automatic Discovery of IP Network Ser-
vices, IEEE Internet Computing, July 1999.
There are many publications related to XML, each with a different approach and
focus. See:
Harold, Eliotte Rusty, XML Bible, New York: IDG Books, 1999 (ISBN 0-7645-
3236-7), for a general introduction to the technology. A CD with a number
of free tools is also included.
103
Web Sites
The SNIA site has a wealth of information related to storage management,
including the latest released version of SMI-S, that can be found at
http://www.snia.org/smi/home.
The DMTF Web site has a wealth of information on CIM, including an updated
tutorial and access to all of the CIM and WBEM specifications referenced above;
it can be found at http://www.dmtf.org/.
The Open Group’s support site for the Pegasus CIM Object Manager can be found
at http://www.openpegasus.org/.
Open source WBEM software is located at http://www.wbemsource.org.
Information on the Service Location Protocol (SLP) can be found at
http://www.srvloc.org/.
An HTTP tutorial can be found at http://www.jmarshall. com/easy/http/.
Information on the full definition of the Unified Modeling Language (UML) can
be found at http://www.omg.org/technology/documents/formal/uml.htm.
Information on XML can be found at http://www.w3c.org/XML/.
S T O R A G E N E T W O R K I N G I N D U S T R Y A S S O C I A T I O N
About the SNIA
The Storage Networking Industry Association (SNIA) is
a not-for-profit organization, made up of over 300
companies and individuals worldwide spanning the
entire storage industry. SNIA members share a com-
mon goal: to set the pace of the industry by ensuring
that storage networks become efficient, complete, and
trusted solutions across the IT community. To this end,
the SNIA is uniquely committed to delivering stan-
dards, education, and services that will propel open
storage networking solutions into the broader market.
For information, contact the SNIA at 650-949-6720
or via e-mail at executivedirector@snia.org, or
visit the SNIA Web site at http://www.snia.org.

Sniasnmbooklet Final

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sniasnmbooklet Final

Uploaded by

Copyright:

Available Formats

S N I A T E C H N I C A L T U T O R I A L

Storage Network Management

SNIA TECHNICAL TUTORIAL

Storage Network Management

The SNIA Technical Tutorial booklet series provides introductions to storage

SNIA TECHNICAL TUTORIAL

Second, access to and definition of the information required by the applica-

About the Author

Roger Cummings is a SAN Technologist at VERITAS Software,

Storage networks have now become so pervasive, and their configurations so

2 Storage Network Management

Tape Library Switch Array Many Others

FIGURE 1–1 Management Information Types

• Describe current network management approaches, with particular empha-

Established Networking Terminology

6 Storage Network Management

Chapter 2 Definition of Terminology 7

8 Storage Network Management

SAAdvert Service Agent Advertisement. A message by which a Service Agent can

Chapter 2 Definition of Terminology 9

XML eXtensible Markup Language. A universal format for structured documents

10 Storage Network Management

the response to that call is represented by the IMETHODRESPONSE element.

Chapter 2 Definition of Terminology 11

Storage Networking Terminology

12 Storage Network Management

Out-of-Band Transmission of management information for Fibre Channel com-

14 Storage Network Management

FIGURE 3–1 Client/Server Architecture

Chapter 3 A Brief History of Management Protocols 15

When a successor protocol to Simple Gateway Monitoring Protocol was

16 Storage Network Management

“State of the Art”

18 Storage Network Management

IETF Standard MIB Usage

Chapter 4 An Overview of Current Management Techniques 19

1. SNMPv2 MIB (RFC3418)

20 Storage Network Management

information that also applies to FC hosts. It incorporates variable groups that

Nonstandard MIB Commonly

This chapter provides a primer on both SNIA’s Storage Management Initiative

22 Storage Network Management

Chapter 5 An Introduction to Web-Based Enterprise Management and SMI-S 23

24 Storage Network Management

FIGURE 5–1 The Triumvirate

Twelve months later, at the StorageNetworkingWorld Spring 2003 conference,

Chapter 5 An Introduction to Web-Based Enterprise Management and SMI-S 25

SA Service Agent (SA) SA Object Manager

Proxy Model Proxy Model

FIGURE 5–2 Reference Model

26 Storage Network Management

An Embedded Agent is an Agent that executes on the equipment being managed.

Chapter 5 An Introduction to Web-Based Enterprise Management and SMI-S 27

Message Syntax: XML-CIM Encoding

Message Semantics: CIM operations over HTTP

FIGURE 5–3 Transport Stack

• CIM Namespace is a subdivision of an implementation that contains a spe-

28 Storage Network Management

HTTP M-POST or POST (XML Entity)

Client HTTP Response (XML Entity) Server

FIGURE 5–4 Request/Response Protocol

CIM Operations over HTTP

Chapter 5 An Introduction to Web-Based Enterprise Management and SMI-S 29