Storage Network Management - SNIA

Storage Network Management

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

SNIA TE C H N I C A L TU T O R I A L


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

The SNIA Technical Tutorial booklet series provides introductions to storage technology topics for users of storage networks. The content is prepared by teamsof 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 [email protected].

Cummings_i–x_001–105 3/2/04 12:55 PM Page ii


Roger CummingsSAN Technologist, VERITAS Software

SNIA TE C H N I C A L TU T O R I A L

Cummings_i–x_001–105 3/2/04 12:55 PM Page iii

Copyright © 2004 Storage Networking Industry Association (SNIA). All rights reserved.The SNIA logo is a trademark of SNIA. This publication—photography, illustration, andtext—is protected by copyright and permission should be obtained from the publisherprior to any prohibited reproduction, storage in a retrieval system, or transmission in anyform or by any means, electronic, mechanical, photocopying, recordings, or likewise. Toobtain permission(s) to use material from this work, please submit a written request toSNIA, Permissions Department, 301 Rockrimmon Blvd, South, Colorado Springs, CO80919. 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 theoriginal document in its entirety is prohibited.

Notice to Government End Users: SNIA software and documentation are provided withrestricted 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 Dataand Computer Software clause at DFARS 252.227-7013.

Cummings_i–x_001–105 3/2/04 12:55 PM Page iv

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 v

Cummings_i–x_001–105 3/2/04 12:55 PM Page vi

Preface

Development of the Fibre Channel interface in the early 1990s presaged a majorchange 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 cablelengths. The impact of this new architecture was not immediately apparentbecause 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 numberof 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 becameintolerable.

With the advent of storage networks, for the first time servers running dis-parate operating systems (for example, Windows and UNIX) could feasibly beconnected to the same set of storage resources. Again, this advance required littlechange in the operating systems themselves, because they continued to be unawareof each other. The systems were not only incapable of sharing stored information,but could destroy information in unrecognized formats. To provide the requisiteisolation between noncooperating systems, additional services were introducedinto the storage network, together with new features, such as zoning, thatrestricted the connectivity available to each server. In addition, virtualizationbegan to be widely employed as a mechanism of separating each server’s view ofstorage from its actual physical configuration in the network. These new featuresinevitably added considerable complexity to the management of storage networks.Throughout the industry, therefore, new specialist administration groups wereformed to manage storage and its infrastructure, which in turn led to the creationof 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, storagenetworks have virtualization devices that provide both address translation andcomplex processing of the information itself. Additionally, storage networks havebridges that always terminate the SCSI command protocols and may also trans-late between different transport technologies. Both of these classes of device arelargely opaque to any management technology.

vii

Cummings_i–x_001–105 3/2/04 12:55 PM Page vii

Second, access to and definition of the information required by the applica-tion is very splintered. Information must be obtained from many differentsources, using several different technologies and architectures, to build up the pic-ture of how the storage network operates. Many designers of storage networkequipment expose management information and controls via a Web server hostedon the equipment itself and accessed via a dedicated “Management LAN” con-nection. Additional information is often accessed from an agent that also runs onthe equipment itself using a standard network management scheme such as theSimple Network Management Protocol (SNMP). However, the informationreturned 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 valuechanges, 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 sourcesthat constantly change, appear, and disappear, as often happens in a virtualizedstorage situation. Further, such network management protocols were designedbefore 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 accessiblevia 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 theinconsistent 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 presentedor defined, much effort must be dedicated to cross-correlating the information inorder to present a true picture of the state of the storage network. This dauntingtask is subject to largely unpredictable change in the face of equipment firmwarechanges.

Much effort in management application development is consumed in theacquisition and correlation of information from a multivendor storage network.Thus, little time remains to create intelligent high-level functions that will relievethe burden placed on administrators. Any attempt at significant administrationsimplification, therefore, founders on the diversity of access and inconsistency ofinformation.

The need therefore exists for a set of new definitions that will streamline the way the industry manages storage networks. Consistent information providedby 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 nolonger have to push their unique interface functionality at application develop-ers. Instead, both would be better able to concentrate on developing features andfunctions of value to administrators. With these requirements met, the manage-

viii Preface

Cummings_i–x_001–105 3/2/04 12:55 PM Page viii

ment of network storage will become simpler and cheaper than managing anequivalent amount of storage attached directly to servers. Ultimately, when thereduced costs for management are delivered, end users will be able to build largermore 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) andWeb-Based Enterprise Management (WBEM) standards as pioneered by the Dis-tributed Management Task Force (DMTF). By leveraging and extending existingdefinitions, application developers will have access to technology proven in otherapplications 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 equivalentsto the basic storage functionality found in other access schemes and informationsources 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 administrationof 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 predecessortechnologies, is clearly achievable using the definitions SMI has created. The aimof this work is simple: to remove the administrative burden as a consideration inthe decision to deploy larger and more powerful storage networks.

AcknowledgmentsMuch 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 havedevoted much time and energy to leadership roles in the SNIA standardizationeffort. 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 alsocreated key documents that have been utilized. The SMI Forum within SNIA, andin particular Roger Reich, its Chairman, has also contributed substantially to thematerials underlying this effort. Educational resources of the DMTF have alsobeen utilized.

Preface ix

Cummings_i–x_001–105 3/2/04 12:55 PM Page ix

About the Author

Roger Cummings is a SAN Technologist at VERITAS Software,reporting to the CTO. He is a Co-Chair of the SNIA SecurityTechnical Working Group and a member of the SNIA Techni-cal Council. Roger has 30 years of development experience withLogica (UK), Control Data (Canada), and StorageTek, DPT, andAdaptec (USA). He has been involved in storage standards worksince the early 1980s, most notably as an officer of the INCITS

T11 (Fibre Channel) committee from 1990, and is currently also active in theINCITS T10 (SCSI) committee and various IETF working groups.

x

Cummings_i–x_001–105 3/2/04 12:55 PM Page x

1

Introduction

Storage networks have now become so pervasive, and their configurations soextensive 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 usedin server configurations for many years previously, and as such did not representa major architectural change. Even when the first switched configurations, con-taining perhaps 16 ports, became available, the manual configuration techniquesthat system administrators had traditionally used still succeeded. But once stor-age networks with hundreds of ports and thousands of devices appeared, and newfeatures such as virtualization, zoning, and name services started to play key roleswith attendant additional complexity, the need for new methods of control andconfiguration could not be denied.

Vendors initially responded in two ways. First, they provided a managementnetwork interface and a Web-based portal hosted on their equipment, which pro-vided management information and control features. Second, they providedagents, which were accessed through that same interface, to allow for integrationwith 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 userinterface and no common functions and terminology between suites. The latter,through the use of a management information definition developed at odds withcommon 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 varioussources using multiple interfaces and communication mechanisms to provide sys-tem administrators with the features they require. This problem has slowed boththe rate at which the applications are developed and the rate at which additional

1

Cummings_i–x_001–105 3/2/04 12:55 PM Page 1

device support can be added. Users have begun to view interoperability of newdevices with their existing management schemes as being as important as, if notmore so than, the interoperability of the “data”interfaces such as SCSI or FibreChannel.

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 managementinterface suitable for various types of storage network equipment, which becamea specification called “Bluefin” that the group presented to SNIA in mid-2002 asa basis for further work. The Storage Management Initiative (SMI) that resultedhas leveraged the existing work of the Distributed Management Task Force(DMTF) to define a single interface sufficiently rich and extensible to support allof the management functions required in a storage network (see Figure 1–1). Theinterface also maximizes the commonality of the information reported and thecontrols supported. To introduce that interface, this booklet will:

• Define terminology used in established network management and developedanew 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 theInternet Engineering Task Force

2 Storage Network Management

Transport Mapping

Integration Infrastructure

Management Application

Protocol Mapping

Object Model Mapping

RPC

Command Line Telnet

CORBA

C++ Library

C Library

Java Library

XML DTD

SNMP

FC-GS

TCP/IPSocket

Discovery

Service

Security

Service

Device Types

Tape Library Switch Array Many Others

Vendor

Unique

Object

Models

... ..........

SCSI Mode Page

FIGURE 1–1 Management Information Types


• 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 CommonInformation 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 managementapplications 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 ofapplicable industry standards and a recommended bibliography.

The booklet was conceived as an educational resource for the members ofSNIA and other designers, product strategists, and developers within the storageand SAN industries. SNIA’s mission is “to ensure that storage networks becomeefficient, complete, and trusted solutions across the IT community.” Clearly, thatmission cannot be achieved unless the SNIA membership is able to employ thebest 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 detailabout SNIA’s mission and current activities can be found on its Web site atwww.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.

Chapter 1 Introduction 3


2

Definition ofTerminology

This chapter contains three sections. The first contains established terms fromcomputer networking, the second terminology specifically related to CIM, and thethird terms associated with the newer discipline of storage networking.

For greater detail or for a more comprehensive dictionary of terms usedthroughout 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 structureddata 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 LocationProtocol.

Attribute Request A request for attributes of a given type of service or attributesof 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 fortransmission over a communication channel. Generally, more bandwidth meansgreater transmission capacity.

5


BER Basic Encoding Rules. An encoding scheme which allows each data item tobe identified and excoded separately. Roughly corresponds to the Type LengthValue (TLV) scheme used in many protocols.

Communication A process by which information is transferred between at leasttwo 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), aprocess that caches SLP service advertisements registered by Service Agents andforwards the service advertisements to User Agents on demand.

DAAdvert Directory Agent Advertisement. A message by which a DirectoryAgent can advertise its presence and capabilities.

DHCP Dynamic Host Control Protocol. An Internet protocol that allows nodesto dynamically acquire (“lease”) network addresses for periods of time rather thanhaving to preconfigure them. DHCP greatly simplifies the administration of largenetworks and networks in which nodes frequently join and part.

DMTF Distributed Management Task Force. An industry organization thatdevelops management standards for computer system and enterprise environ-ments. DMTF standards include WBEM, CIM, DMI, DEN, and ARM. (Seehttp://www.dmtf.org.)

Ethernet A popular local-area network that uses a contention media-accessmethod over a bus topology of coaxial cable. Also used to refer to the standardspecified by IEEE 802.3.

Gateway A computer that interconnects disparate types of networks, translatingprotocols 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 protocolwidely used on the Internet.

IANA Internet Assigned Numbers Authority. The administrator of identifiersassociated 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 accessto 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 communicationchannel. For example, a single cable between two repeaters, bridges, or routers isa 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 networkfunctions. Each intermediate protocol layer uses the layer below it to provide aservice 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 asone. Repeaters can extend the length of a network beyond the physical limitationsof 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 datawhen 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 canadvertise 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 mayinvolve more than one server process distributed over one or more computer sys-tems. The collective server processes that are involved in honoring a request areknown as service providers.

Service Type The class of a network service represented by a unique string (forexample, 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 ofthe Service Location Protocol.

Service Type Template A formalized, computer-readable description of a ServiceType. A part of the Service Location Protocol.

Service URL A Uniform Resource Locator for a service containing the ServiceType name, network family, Service Access Point, and any other informationneeded to contact the service. Used in the Service Location Protocol.

SLP Service Location Protocol. An IETF-defined protocol used to dynamicallylocate service functions (e.g., printers) in a network.

TCP/IP Transport Control Protocol/Internet Protocol. Two components of theprotocol stack largely used throughout the Internet. Defined by IETF RFCs. TCPprovides a reliable service and runs over IP, which provides a datagram service.

Tunneling A technology that enables one network protocol to send its data viaanother network protocol’s connections. Tunneling works by encapsulating thefirst network protocol within packets carried by the second protocol. A tunnelmay also encapsulate a protocol within itself (e.g., an IPsec gateway operates inthis fashion, encapsulating IP in IP and inserting additional IPsec informationbetween 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 retrieveservice information from, Service Agents or Directory Agents.

URL Uniform Resource Locator. The primary address format used on the WorldWide 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 documentsand data on the World Wide Web. The World Wide Web Consortium (W3C) isresponsible 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 becalled an aggregation. An aggregation is expressed as a qualifier on the associa-tion class. Aggregation often implies, but does not require, that the aggregatedobjects have mutual dependencies.

Cardinality The number of values that may apply to an attribute for a givenentity. 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 theDistributed Management Task Force. CIM is divided into a core model and com-mon models. The core model addresses high-level concepts (such as systems anddevices), 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 coremodel and may also be subclasses of each other.

Client A process that issues requests for service. Formulating and issuing requestsmay involve multiple client processes distributed over one or more computer sys-tems. The collection of client processes involved in formulating and issuingrequests is known as a consumer.

Consumer A host, identified by HBA WWN or other identifier that is allowedaccess to a storage-addressable unit.

Cooperating clients A set of consumer processes that are aware of each other andare 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 methodreturns 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 extrinsicmethod call is represented in XML by the �METHODCALL� element and theresponse to that call is represented by the �METHODRESPONSE� element. Seealso Intrinsic method.

Intrinsic method Operations made against a CIM server and a CIM namespaceindependent 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 textstrings.

Method The name of one (or more) operations(s) performed by an instance ofan object class. Methods are distinguished from operations as follows: A methodis a name for one or more operations that may execute when the method isinvoked. For example, when the method, printSelf(), is called, the operation ofprinting the state of the reference object is executed. In most models, a methodis 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 ofeach other and compete for resources. User processes on a multiuser machine arenoncooperating 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 andevent notifications from a variety of sources, such as the system registry or anSNMP device. Providers forward this information to the CIM Object Manager forintegration and interpretation.

Semantics The meaning or behavior associated with an entity. For example, wemight say the semantics of the method, resync_mirror(), are encoded in themethod name. By contrast, the semantics of the UNIX ioctl() method are encodedin 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 ServiceLocation Protocol.

UML Unified Modeling Language. A scheme for representing the behavior ofcomplex systems.

WBEM Web-Based Enterprise Management. A set of technologies that enablesinteroperable management of an enterprise. WBEM consists of CIM, an XMLDTD 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 anunderlying information model, CIM, to create a conceptual view of the enterprise.

XML-CIM Listener A server application that receives and processes XML-CIMExport Message requests and issues XML-CIM Export Message responses.

XML-CIM Server A server that receives and processes XML-CIM Operationrequests and issues XML-CIM Operation responses.

Storage Networking Terminology

Active Zone Set The Zone Set that is currently activated. Only one Zone Set maybe 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 externalaccess 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. TheLogical Unit Number is then mapped to an external descriptor (for example: a SCSIPort, Target ID, and LU Number). An LU may be mapped for access from multipleports 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 ofthe LUN. Only LUNs that are exposed via a port are available for access.

LUN masking The process of configuring software in storage network nodes todetermine which hosts have access to exported drives. LUN masking can be eitherserver-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. Thecomponent 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 accessto exported drives. This configuration authorizes specified server HBA WWNs toaccess the secured LU while preventing other unauthorized servers/hosts fromeither 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 ofdata between computer systems and storage elements.

SCSI Small Computer System Interface. A parallel electrical interface standarddefined by INCITS Committee T10. (See http://www.t10.org.)

SCSI Command A request describing a unit of work to be performed by a deviceserver accessed through a target.

Soft Zone A Zone consisting of Zone Members that are made visible to each otherthrough Client Service requests. Typically, Soft Zones contain Zone Members thatare visible to devices via Name Server exposure of Zone Members. The fabric doesnot enforce a Soft Zone. Note that well-known addresses are implicitly includedin every Zone.

Target A device that receives and executes SCSI commands and generates statusresulting from those commands.

Virtual Disk A set of disk blocks presented to an operating environment withdisk-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 awareof each other, but not made aware of devices outside the Zone. A Zone can bedefined to exist in one or more Zone Sets.

Zone Member An N_Port (or NL_Port) to be included in a Zone, as specified byits 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, byDomain_ID and port number), the device’s N_Port_Name, the device’s addressidentifier, 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.



3

A Brief History of ManagementProtocols

The roots of the network management protocols that are in common use todaycan be traced back to developments in the late 1980s. Prior to that time, networkmanagement had typically been performed using low-level signaling techniquesto send special control information. Receipt of this information would causereceiving hardware to cease normal operation and enter a special diagnostic modein which it responded to commands contained in the information. This approachworked well in homogeneous networks, which used the same interface technol-ogy throughout. However, with the advent of protocol stacks and abstraction ofthe lower level network characteristics, networks began to support multiple dif-ferent types of interface technology, which meant that a different approach wasnecessary in order to support network-wide management. At this point, both theTCP/IP and Open System Interconnect (OSI) protocol stacks began to define net-work management protocols that operated at the application layer. This changein approach had both advantages and disadvantages. The major advantage wasthat management could now be performed using the same tools at any point inthe network; the major disadvantage was that management was only possiblewhen the entire protocol stack was active and working correctly.

The move to an application-layer approach caused the creation of aclient/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 eachof the other items of equipment in the network that required management. Inearly networks, the servers tended to reside on only two types of “other equip-ment” hosts, and computers acting as gateways between multiple physical networksegments. In fact, one of the earliest definitions for the protocol between suchclients and servers was the Internet Engineering Task Force’s (IETF’s) SimpleGateway Monitoring Protocol, defined in November 1987. This protocol intro-duced a number of approaches that are still evident in network management pro-

13


tocols. It adopted Abstract Syntax Notation 1 (ASN.1) and its Basic EncodingRules (BER) to define the contents of the protocol data units exchanged betweenthe client and the server, rather than any fixed format. Three of the primitive datatypes defined by ASN.1 were used: octet (byte) string, integer, and unique iden-tifier. The information upon which the protocol operated was defined only interms of variables identified by an octet string name, and able to contain eitheran 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 primitivehandshake operations to read and set the values contained in those variables, witha minimal number of unsolicited messages for traps. There were no “imperative”commands with more specific functions like “disable interface”; these were viewedas 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 overan unreliable, connectionless transport. The encoding rules specified that eachvariable 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.


S

SS

SS

S S

C

C

Management Client

S Management Server

Unmanaged System

gateways

hosts

FIGURE 3–1 Client/Server Architecture


When a successor protocol to Simple Gateway Monitoring Protocol wasdefined 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 ManagementInformation (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 theyears, 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, butin fact the new types are merely one of those ASN.1 primitives with specific valuerestrictions. SNMP also went beyond the concept of individual “scalar” variablesto define columnar or list variables that use the ASN.1 Sequence constructor typeand in which individual values are aggregated and each value is identified by anindex value in addition to the unique object identifier. List variables are also thenable to be conceptually aggregated into two-dimensional tables using theSequence construct and an additional index. The list and table constructs areregarded as “conceptual” because they are only defined to simplify access, and donot 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 allobjects defined in the MIB. The get and set operations of the Simple GatewayManagement Protocol are significantly extended with the addition of a “get next”request, which can be used to traverse tables without the unique object identifierof every object having to be known. The MIB definition also contains many morevariables related to interfaces, address translation, routing, and additional typesof protocols.

While SNMP was being developed in the IETF, a comparable framework wasbeing created by the International Standards Organization for its Open SystemInterconnect (OSI) protocol stack, called the Common Management InformationServices (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 groupsinitially collaborated closely, and a common MIB definition was agreed upon.However, this agreement did not endure, and a MIB-II definition was introducedthat no longer supported both protocols. MIB-II clarified the constructs, intro-duced the concept of “deprecated” objects, defined a specific Index clause, andgave 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 ofthe specific variables. A standard related to MIB-II also extended the definition ofthe 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. Thereasons 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

Chapter 3 A Brief History of Management Protocols 15


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 restrictionof the maximum length of identifiers to 64 octets, and disallowal of the use ofhyphens in identifiers (although this still widely occurs). SMIv2 introduces anadditional syntax called counter64, but RFC2576 gives explicit rules defining howthis should be handled in situations where multiple versions are employed in thesame 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 errorlogged.

SMIv3, incorporating both a user-based security model and view-basedaccess 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 andclarification since the move to application-level management in the late 1980s.The “data model” has remained largely unchanged in that time, and still consistsof independently specified variables collected into groups for ease of access only.Relationships and dependencies between the variables are still expressed only inthe text of descriptions, and therefore cannot be analyzed or checked by tools suchas compilers. Although this approach is eminently suitable for the job for whichit was first envisaged, namely the collection of statistics from gateways, it has dis-tinct limitations with respect to the overall management of today’s dynamicallychanging networks.



4

An Overview ofCurrent ManagementTechniques

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 artis 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 hostedby the WIDE project in Yokohama, Japan, which marked the first time that theIETF had met in Asia. During one of the evening plenary meetings, a report wasgiven on a network administration workshop held in Reston, Virginia, for aninvited audience of very experienced architects and managers. The conclusionsfrom that workshop were sobering: Most sites used SNMP only for collectingrouter and interface statistics, and largely employed locally developed PERLscripts or command line interface approaches for configuration control anddevice management. The subsequent discussion revealed that this approach waswidespread throughout Asia and Australia, as well.

A number of reasons were given for the pervasiveness of this approach. Manynetwork managers felt that equipment manufacturers did not implement MIBsin a timely manner, and perceived MIBs as hard to implement. The managers alsoreported that manufacturers were still largely shipping SMIv1 MIBs to gain thewidest applicability for their efforts, and many were still unwilling to commitadditional effort to support SMIv2. However, those same managers did feel thatSNMP would continue to be the scheme of choice for network monitoring for theforeseeable future, and recommended that IETF both continue to develop thetechnology 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 thatthis is an easier task than writing a MIB and creating an SNMP agent! Such pagesare by definition created for a human to view and manipulate, but requiring amanager 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 bevery different and reflect the manufacturer’s branding, thus requiring the networkmanager to climb a learning curve for each new equipment type. Use of the pagesas a source of information for management applications is also problematic. Theprocess of extracting the information from the received HTML code is known bythe 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 designchanges to the pages that would have no effect on the viewing manager can leadto the information being extracted erroneously. At the other end, even majorchanges 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.) beingdisplayed, forcing the application designer to make assumptions. Because of thesesignificant limitations, the workshop recommended that the IETF not produceany management standards based on HTTP.

The results of the workshop and the discussion reported above emphasize thefact that current management practices rely heavily on specially developed toolsand 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 MIBsand the second with use of a nonstandard MIB that is nevertheless widelyemployed in the storage networking industry.

IETF Standard MIB UsageWhen SNMP was first developed, it was assumed that there would be a singlemonolithic MIB definition containing all the parameters that would be used inall equipment types. However, implementation experience showed that a differ-ent approach was needed for scalability and to support parallel development, andtherefore in the MIB-II development (RFC1213) in 1991, described above, themonolithic approach was abandoned in favor of a number of “foundation” MIBsdefined on a functional basis. The intention was that equipment manufacturerswould then create their device-specific MIBs as extensions of the standard MIBs.

The foundation MIBs currently recommended by IETF MIB experts for usein storage and storage network applications are as follows:



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 theobject was last initialized (uptime), an administratively assigned name, con-tact details of a responsible person, physical location information, and someindication of services provided. The majority of this information is providedin textual information that cannot be parsed by a management application.

2. Interfaces MIB (RFC2863)

The Interfaces MIB contains media-independent interface informationdesigned so that any network interface can be managed in an identical man-ner through these objects. The MIB incorporates a large table structure, calledthe iftable, designed to be able to distinguish multiple layers below the IPlayer, and incorporates variables to manage character-, packet-, and bit-basedtechnologies using both fixed- and variable-length packets. A separate table,the ifstacktable, then defines how these layers relate in a stack, and an ifaliastable 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 acontainment tree defining exact component locations. This MIB introducesthe 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 objectsidentified in other standard MIBs. There is very little setable informationdefined by this MIB. There is also no straightforward method of discoveringwhich variable bindings are stored in nonvolatile storage.

4. Host Resources MIB (RFC2790)

The Host Resources MIB contains variables related to the management of hostcomputers. 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) areto 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

Chapter 4 An Overview of Current Management Techniques 19


information that also applies to FC hosts. It incorporates variable groups thataddress 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, theparameters 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. Becauseof this, it is shortly to be superseded by a new Fibre Channel Management MIBbased on foundation MIBs.

Note that for the reason described in the introduction, even though most ofthe 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. Althoughthe resultant MIBs are functionally equivalent, the translation involves convert-ing some machine-readable information to descriptive text, which thereforedecreases the information that can be parsed and verified by a compiler or anaccessing application.

Nonstandard MIB Commonly Used in Storage NetworkThe Fibre Alliance MIB was created by an industry group and was intended toinclude all of the variables needed for managing a Fibre Channel system. The MIBalso addresses management of switches, devices, ports, and software on servers. Itdoes 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 inan 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 designsuse the Fibre Channel Management MIB under development in the IETF in pref-erence to those in the TR.

SummaryThe new approach to MIB development has taken some steps toward ensuringthe 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 vendorin 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 retrievedabout the relationship between various parts of a system, and few features thatcan be actively configured. The new approach to MIB definition has done little toaddress the fundamental limitations of the modeling technique, and the new“security” features incorporated in SMIv2 have not yet led to network managersbeing willing to abandon their site-specific configuration tools, which obtain con-siderable security by their obscurity.



5

An Introduction toWeb-Based EnterpriseManagement andSMI-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 TaskForce’s Web-Based Enterprise Management (WBEM). The primer begins with ahistorical timeline of developments in the two organizations, followed by explo-ration of the fundamentals of WBEM and the extensions defined by SMI. A setof “structured” terminology definitions is contained in this chapter as a comple-ment to the earlier definitions. The richer and more extensible information modelthat underpins this work is contrasted with the more limited model described inthe previous chapter.

BackgroundThis section describes the sequence of activities in DMTF and SNIA that led to theformulation of the WBEM and SMI programs. The motivations of the pioneers inboth cases are explored, and the influences of previous work traced. Because littledocumentation exists of some of the early activities in both cases, some of theinformation contained here is the result of conversations between participants andthe 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 transportedled 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 publicdomain in 1996. These were HyperMedia Management Schema (HMMS) andHyperMedia Management Protocol (HMMP). In addition, the concept of aHyperMedia 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 managementand 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 DistributedManagement Task Force instead. The name of the schema also changed, becom-ing the Common Information Model, and two major revisions of its specificationwere 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 progressin that organization, the work was redirected to the DMTF. At this point, the wholeinitiative gained a new name, becoming Web-Based Enterprise Management(WBEM). WBEM added a third standard, a representation and serialization of theschema to simplify transport; the three resulting standards are described in detailin the following sections.

Three characteristics of the developments described above have ultimatelybecome most important in enabling the success and widespread deployment of thetechnology. First, leverage of the HyperText Transfer Protocol (HTTP) widely usedin Web applications as a transport mechanism instead of a proprietary transportprotocol allowed WBEM to take advantage of a sizable existing infrastructure. Sec-ond, use of a multilevel architecture in which multiple Object Managers (seebelow) 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 modelingapproach than earlier technologies, which only represented independent variablesarranged in tables. CIM is based on a schema that both employs object-orientedtechniques and makes use of several common modeling structures called “designpatterns” that were found in the mid-1990s to reoccur in many systems. A schemahas been defined as “an internal representation of the world; an organization ofconcepts and actions that can be revised by new information about the world.”CIM’s schema contains objects that represent the characteristics of the entitiesbeing managed by the application, whether they are a physical entity such as aswitch, a logical entity such as a software package, or a file. In addition, CIM alsomodels the complex and multilevel relationships between these entities. Thisallows the application to traverse the schema discovering types of objects and thespecific names and identifiers of the instances of those objects, just as it would ifit was accessing the equipment represented by those objects via “in-band” means.



SNIA

The SNIA SMI is the ultimate result of a private meeting of a number of SNIAmember companies held in 2000. The meeting was called as a result of severalmanagement software vendors’ frustration with the level of effort and cost theywere 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 toinvestigate 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 layerand their applications. However, as work proceeded in that direction it appearedincreasingly problematic. The common layer would need to be supported by thegroup, probably in open source fashion, and a new instrumentation “agent” wouldstill need to be hosted on each of the devices being managed. The direction wouldalso require completely new definitions and interface protocols, and the combi-nation of all of these issues caused the group to investigate existing technologiesthat 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 severaladvantages. CIM offered a rich modeling approach, with a number of existingproven 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 typesof storage network equipment, although there was early agreement that theywould require substantial rework and amplification. The approach was extensiblein that vendor-unique information and controls could be added in a manner thatdid not negatively impact the overall model. CIM already had definitions in placethat would allow a single piece of instrumentation to provide support for multi-ple different management applications. The DMTF had already defined a methodof data encoding for transmission (an XML representation) and a communica-tions protocol (using HTTP as a transport), which were regarded as strengths bythe group because of their separation from the model itself and their basis in pop-ular, existing standards. The architecture underlying CIM was scalable enough tohandle the required enterprise-class applications and incorporated the notion ofproxy 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 serverplatforms were already enhanced to participate in CIM.

Having made the decision to adopt CIM, the work went forward, and inspring 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 WorkingGroups around this effort. SNIA also forged an alliance with the DMTF under theterms of which SNIA would be the center of all storage-related work, but anychanges required to the CIM schema and related definitions would be handled bysubmitting Change Requests to the DMTF via an established procedure.



Twelve months later, at the StorageNetworkingWorld Spring 2003 conference,SNIA released to the public the SMI Specification (SMI-S), Revision 1.0. At thesame event, a heterogeneous multivendor storage network was demonstrated thatcontained 20 instrumented devices communicating with 18 storage managementapplications using SMI-S, a total of 150 points of interoperability. Significant feed-back was received on the release, and development work continued, resulting inthe release of Revision 1.0.1 in September 2003. This is by no means the end ofthe development, with work expected to continue for several years so as to addnew functionality (see Chapter 8) and optimize existing definitions as a result ofimplementation experience.

The SMI-S documentation does not itself contain the definition of the infor-mation presented by equipment to management applications, or the protocols bywhich that information is communicated between the two entities. Instead, it ref-erences the WBEM specifications produced and maintained by the DMTF for thatinformation. These specifications are introduced in the following section. WhatSMI-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 aspecific 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 ofnaming and discovery; these areas are described in the section entitled SMI-SAdditions. The structure of the CIM schema is described in some detail.

WBEM FundamentalsThe 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 topologicalorder rather than alphabetically.


CIM-XMLTransport Encoding

CIM-HTTPAccess

CIM

FIGURE 5–1 The Triumvirate


Terminology

WBEM is based on a client/server architecture, as shown in the reference modelin Figure 5–2. In this application, the terms are defined as follows:

A WBEM Client is an entity that extracts information from managed equipmentand processes that information for submission to an operator, to serve as inputto 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 WBEMClient is often called a “Requestor.”

A WBEM Server is an entity that provides a WBEM service. A WBEM service maybe 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 tothe managed equipment in response to a request from the WBEM Client.


Client

Device or

Subsystem

Agent

Proxy Model

Proprietary

0…n

0...n

Agent

Embedded

Model

0...n

Object Manager

Device

Proprietary

0Ön

Directory

Server

Directory Agent 0...n

SAService Agent (SA)

User Agent

SA

1

1 n

Provider

1

CIMxmlCIM operations over http

TCP/IP

SLPTCP/IP

Device or

Subsystem

Device or

Subsystem

Proprietary

Object Manager

Proxy Model

DeviceDevice

0...n

SA

User Agent

1

1 n

Provider

1

CIMxml

CIM operations over http

TCP/IP

SLPTCP/IP

Device or

Subsystem

FIGURE 5–2 Reference Model


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 orlegacy scheme to extract information from another piece of equipment, which isbeing 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 supportthe persistence of information. An Object Manager typically supports richer func-tionality than the other agent types defined above. An Object Manager may alsobe able to offload the processing of some functions, such as enumeration, from aWBEM Client. Typically, an Object Manager does not incorporate support for anyspecific 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 aspecific type of device.

The CIM schema is based upon object-oriented modeling techniques that arebased on the mathematical concepts of set theory and classification theory. In theschema:

• Classes are the definition of types of models.

• Properties (sometimes known as attributes) define the characteristics of aclass, e.g., the capacity of a storage volume class.

• Methods (sometimes known as functions) define the behavior of a class (suchas a format function on a physical disk class).

• Qualifiers define implementation-specific information on how a class, or itsproperties 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 dualitythat is common in much object-oriented literature.

• Subclasses are definitions of subtypes of a class, i.e., in a hierarchy. Ratherthan defining a physical relationship, the hierarchy defines specialization,with the most general objects at the top of the hierarchy. The relationshipbetween a class and its subclasses is one of either inheritance or aggregation.Inheritance defines a subclass as more specific than its class, with additionalspecialized 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 betweenclasses. CIM Associations are themselves classes with defined properties thatalso exist in a class-subclass hierarchy. An important characteristic of CIM isthat the definition of a new association referencing a class does not modifythat class.



• CIM Namespace is a subdivision of an implementation that contains a spe-cific set of instances and is addressed in an implementation-specific mannerusing 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, andenumerating both classes and properties, performing queries, and traversingthe 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. Thestandards 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 thereis good functional separation between the first two of these standards and thethird: Another communications protocol or encoding scheme can be defined withno impact on the schema.

Note that the CIM schema is not defined by a specification, but rather by aset of UML class diagrams and an associated structured textual description filecalled the Managed Object Format (MOF). Specification 3 above only defines thenotation 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.


Transfer Protocol: TCP/IP

Messaging Protocol: HTTP

Message Semantics: CIM operations over HTTP

Message Syntax: XML-CIM EncodingObject Model Independence

Transfer Protocol Independence

Message Protocol Independence

FIGURE 5–3 Transport Stack


CIM Operations over HTTP

The specification for CIM operations over HTTP defines how messages areexchanged 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 asingle HTTP POST or M-POST message, and a single response or multipleresponses in a single HTTP Response message

2. A small set of extension headers, defined in the usual “name�value” formatand 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 headersare 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 hierarchyappropriate for a different class of implementation

Note that the majority of the body of the message referenced in 1. above is notdefined in this specification but rather in the XML representation specification in thefollowing section. Either an extrinsic or an intrinsic method can be identified in aRequest, 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 replieswith 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.


Client

HTTP M-POST or POST (XML Entity)

HTTP Response (XML Entity)

Repeat...

Server

FIGURE 5–4 Request/Response Protocol


Representation of CIM in XML (XML-CIM)

The specification for the representation of CIM XML defines a grammar that canbe 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 isbased 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 ofCIM classes and identification of instances, but rather a set of metadata that canbe 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. Thisapproach has the considerable advantages of allowing a single compact DTD tobe used to validate the entire schema, and decoupling the definitions containedin 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 takesan attribute that distinguishes between the two uses. The other XML elements arecollected into groups, the names of which are listed below, together with a briefdefinition of their purpose and example members.

1. Declaration XML Elements

This group is concerned with the declaration of CIM objects. This groupincludes elements that define an object name and path, and also a qualifierand its scope.


TABLE 5–1 Extension Headers

Name Identifies Values

CIMOperation Type of message in body (invokes operation MethodCallin target Namespace or presents status) MethodResponse

CIMExport Type of message in body (communicates MethodRequestinformation about Namespace or element) MethodResponse

CIMMmethod Name of method to be invoked MethodName in safe format

CIMObject Extrinsic Method: Class or Instance ObjectPathIntrinsic 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)


2. Value XML Elements

This group is concerned with the value of CIM objects. This group includeselements 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 objectsand the paths needed to access them. This group includes elements that define


TABLE 5–2 Intrinsic Methods

Method Name Function (all relative to Mandatory (Optional) target Namespace) Parameters

GetClass (GetInstance)

DeleteClass (DeleteInstance)

CreateClass (CreateInstance)

ModifyClass (ModifyInstance)

Enumerate Subclasses(Instances) of a class

Enumerate Subclass (Instance)names of a class

Enumerate associators (refer-ences) to an object

Enumerate names of associators(references) to an object

Get (set) property value frominstance

Get (set) qualifier declaration

Enumerate (delete) qualifierdeclaration

Returns single CIM class(instance)

Deletes single CIM class(instance)

Creates single CIM class(instance)

Modifies single CIM class(instance)

Returns zero or more classesthat meet criteria

Returns zero or more names ofclasses (instances) that meetcriteria

Returns zero or more objectsthat are associated to a source(refer to a target) object

Returns zero or more objectnames that are associated to asource (refer to a target object)

Retrieve (set) single property ininstance

Retrieve (set) single qualiferdeclaration

Delete single (enumerate) quali-fier declaration

ClassName (InstanceName),PropertyList

ClassName (InstanceName),PropertyList

NewClass (NewInstance)

ModifiedClass (ModifiedIn-stance)

{ClassName, LocalOnly, IncludeQualifiers, IncludeClassOrigin (PropertyList for instance) all optional}

{ClassName optional}

ObjectName (role, PropertyList,etc., optional)

ObjectName (role, PropertyList,etc., optional)

InstanceName, PropertyName

QualifierName (QualifierDeclaration)

QualifierName (QualifierDeclaration)


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. Thisgroup includes elements that define a class, an instance of a class, a qualifier, aproperty 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 foruse 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, anintrinsic method, a response to each type of method, a parameter, an error, etc.


TABLE 5–3 Functional Groupings

Functional Group Dependency Methods

Basic Read None GetClassEnumerateClassesEnumerateClassNamesGetInstanceEnumerateInstancesEnumerateInstanceNamesGetPropety

Basic Write Basic Read SetProperty

Schema Manipulation Instance Manipulation CreateClassModifyClassDeleteClass

Instance Manipulation Basic Write CreateInstanceModifyInstanceDeleteInstance

Association Traversal Basic Read AssociatorsAssociatorNamesReferencesReferenceNames

Query Execution Basic Read ExecQuery

Qualifier Declaration Schema Manipulation GetQualifierSetQualifierDeleteQualifierEnumerateQualifiers


CIM

The specification for the Common Information Model defines the structure ofthe CIM schema, a set of metadata called the metaschema that is used to formallydefine the schema, a set of data types in which properties can be defined, namingschemes for classes and objects, sets of metaschema, standard, and optional qual-ifiers, and methods of mapping management data from legacy schemes to CIMproperties.

The structure of the CIM schema will be defined in detail in a subsequentsection.

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 ofdefined values) to reference additional unique values. This is done by defining anadditional property, usually named OtherNNN (where NNN is the name of theenumeration 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 theInterface Definition Language defined by the Open Group in its Remote Proce-dure Call (RPC) specification. MOF defines a syntax that allows objects to bedefined in a textual form, and the syntax permits comments to be included. Themain components of that syntax are textual descriptions of classes, associations,properties, references, methods, and instance declarations and their associatedqualifiers. The grammar for this syntax is described in an appendix to the speci-fication, using the Augmented Backus-Naur form defined by the IETF. Otherappendices define the CIM metaschema in MOF format and the UML notationsubset used in CIM schema diagrams. A CIM-capable system must be able to bothimport and export properly formed MOF constructs.

SMI-S AdditionsSMI-S adds a number of new definitions and concepts to those defined in CIM.These are fully compatible with the DMTF definitions, but represent furtherrefinement and restriction, and in some cases anticipate future DMTF develop-ments. Two specific additions will be described in detail here: Durable Names anda Discovery Service.

Correlatable and Durable Names

WBEM Clients need to obtain and set properties of managed objects in multipleNamespaces. Circumstances arise where an object in one namespace is associatedwith an object in another namespace, and each namespace contains some amountof 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 inthis 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 mayhave specific lifetime. The exact lifetime of a name is a function of the specificobject, 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 managedresource 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 notall 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 WideNames, Fully Qualified Domain Names, and IP Address information.

Not all formats are valid for all classes in the schema, and the name of theproperty that contains the correlatable and durable names also varies by class.SMI-S contains detailed pseudo-code describing how equality is determinedbetween the correlatable and durable names of multiple objects.

CIM requires that instance identifiers be unique across all instances of a classwithin a single namespace, but does not fully address cases in which different typesof identifiers are possible on different instances of an object. A method is there-fore needed to ensure that multiple sources of information about managedresources use the same approach for forming correlatable and durable nameswhenever different types of identifiers are possible. This is done by establishing apreferred 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 existingstandard, called the Service Location Protocol (SLP), to provide this capability.

SLP is defined by the IETF and is becoming widely used for discovery in anumber of different scenarios in a TCP/IP network. An example of more generalSLP usage is in discovering printers. Note that two separate versions of SLP havebeen standardized, and version 2 is required by SMI-S. Another IETF documentdefines an optional C language API for use with SLP.

SLP is primarily used to locate an agent, but also provides some finer grainedvisibility 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 enableits specific characteristics to be registered with the discovery service definedby SMI-S.



• A User Agent (UA) is the function supported by a WBEM Client to discoverthe 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 SAsinto what is initially a stateless repository.

Note that the above is a different use of the term agent than in CIM, andbecause of this these functions are referenced only by their abbreviations in thefollowing 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 willcommunicate with SAs directly. The DA represents an optional part that enhancesthe 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 toreregister as registrations expire. If a DA is present, a UA will query the DA forservices, rather than directly accessing an SA.

SLP consists of two parts: a message protocol and a service definition. Theprotocol can further be subdivided into five items.

1. Common Message Format

All SLP messages use a common format consisting of a 16-byte binary headerfollowed by a set of UTF-8 strings preceded by length fields. Table 5–4 definesthe contents of the header field, and Table 5–5 lists the message types andtheir usage. The layout of the strings and the information they contain arespecific to the message type. Note that SMI-S defines the default scope asalways being used.


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.


2. UA to SA/DA Communication

The messages used by a UA to communicate directly with an SA or anoptional 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 optionalfor 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.


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.


5. Multicast Convergence Algorithm

A UA or an SA can obtain the address of a DA with which to communicateby several means, such as the DHCP option by which both the address andscope of a DA are returned, or by manual configuration. In the absence ofother methods, though, the Multicast Convergence Algorithm as follows maybe used to locate a DA, and the same algorithm is always used by a UA tolocate an SA if a DA is not present. The algorithm begins when a UA or SAissues a request as above, but to a multicast address instead of a unicastaddress. One or more replies may then be generated to the unicast addressfrom which the request originated. After a wait period, the UA/SA reissuesthe request containing a “previous responders list,” which includes the uni-cast address of the sender of each reply. Upon receiving this request, thereceiving entity checks the previous responders list, and if it finds its unicastaddress it silently discards the request.

The SLP service definition consists of two parts, the service URL and the servicetype 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 beeither 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 decimalnotation 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 registeredby 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 theservice.

• Service-location-tcp—This is a list of TCP addresses that can be used to reachthe 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 methodssupported (see Table 5–3). Multiple values can be returned.

• MultipleOperationsSupported—A Boolean indication of whether multiplerequest messages (see XML-CIM) are supported.



• AuthenticationMechanismsSupported—The authentication mechanism sup-ported by the service, which can return multiple values.

• Namespace—The namespace(s) supported by the service. This attribute mayhave 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 thecorresponding namespace listed in the namespace attribute.

• RegisteredProfilesSupported—The SMI-S profile(s) supported by the serverprefixed 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, thisattribute is an array of values.

Details of the CIM SchemaThe CIM schema defines an object-oriented information model described by aset of UML class diagrams and defined by one or more MOF text files, as describedabove. 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 aset of related systems, each containing a number of discrete components, and boththe characteristics of these systems and components and their relationships arerepresented. The schema defines a set of classes, with properties and methods, to


Event

Device

Data

base

Ap

ps

User

System

Support

Policy Physic

al

Ne

two

rk

Metric

s

Interop

Core

FIGURE 5–5 Schema Organization


represent the systems and components, and a set of associations to represent therelationships 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, andproperties that provide a basic vocabulary for describing managed systems. Manyof the classes in the core are “abstract” in that they only serve as a base for otherclass 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 thedevice, interop, physical, and system models are most referenced in SMI-S. Thesemodels, 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 aredepicted 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 moreclasses. Many of the diagrams do not show the properties of association classes,


ManagedSystemElement

Name: stringDescription: stringCaption: stringStatus: stringInstallDate: datetime

Dependency

ManagedElement

Description: stringCaption: string

Association

Properties

Aggregation

(a type of association)

Component

Inheritance

Association

Aggregation

Key

FIGURE 5–6 UML Subset


but merely represent the classes as lines. In that case there is usually a separatepage of the model that shows the association hierarchy as classes. The ends ofsome associations have numbers (cardinality) indicating the valid count of objectinstances. Cardinality is expressed either as a single value (such as 1) or a rangeof values (0..1 or 1..4); * is shorthand for the range 0..n. Some associations andaggregations are marked with a “W” at one end indicating that the identity of thisclass 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 linesfor associations, and green lines for aggregation. The color coding makes largediagrams much easier to read but is an extension of UML.

The SMI-S document uses two UML conventions in addition to those usedin CIM:

1. Packages

The UML package symbol is used as a shortcut representing a group of classesthat 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 hierarchyis included and each class is depicted one time in the schema diagram.

Instance diagrams also contain classes and associations, but represent aparticular configuration. Multiple instances of an object may be depicted inan instance diagram. An instance is named with an instance name followedby 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 beginswith the abstract Managed Element class; Managed System Element, Capabilities,Location, Configuration, and Setting classes, among many others, are subclassesof 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 areference 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.




Log

ical

Ele

men

t

Man

aged

Sys

tem

Ele

men

t

Inst

allD

ate:

dat

etim

eN

ame:

str

ing

Op

erat

ion

alS

tatu

s: u

int1

6[]

{en

um

}S

tatu

sDes

crip

tio

ns

: st

rin

g[]

Sta

tus:

str

ing

{en

um

, D

}

Ph

ysic

alE

lem

ent

*C

apti

on

: st

rin

gD

escr

ipti

on

: st

rin

gE

lem

entN

ame:

str

ing

Man

aged

Ele

men

tD

epen

den

cyC

om

po

nen

t

***

Co

ncr

eteD

epen

den

cy

**

Co

ncr

eteC

om

po

nen

t* *

Log

ical

Iden

tity

* *

Co

ncr

ete

Iden

tity

**

Loca

tio

nC

apab

iliti

esC

olle

ctio

n

Ho

sted

Dep

end

ency

0

..1

*

(See

Fig

ure

5–9

)(S

ee F

igu

re 5

–9)

FIG

UR

E 5–

7Ba

sic

Abs

trac

tion


The basic abstraction also illustrates PhysicalElement and LogicalEle-ment, immediate subclasses of ManagedSystemElement. The separation ofphysical and logical elements at this level in the hierarchy is a modelingapproach that has proved to be very flexible. CIM defines PhysicalElementsas those that conform to the laws of physics, occupy space, and can be touchedand 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 DefaultSettingassociations, 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 theelement and its settings—is an example of a design pattern that has beenidentified in a number of models. This approach is used where it makes senseto be able to read and manipulate the state of settings independently of thestate 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 subclassof 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 isrequired or consumed by another. The Service class represents the notions ofthe Service that can be managed, but does not include how the service isaccessed, 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 andStopService 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 whichmanageable components are aggregated into a complex combination, whichcan itself be treated as a manageable component. This relationship is mod-eled in this piece by multiple MSEs having a SystemComponent associationwith the System class, which is itself a subclass of MSE via LogicalElement.The definition of “System” in the CIM context is quite broad, ranging fromcomputer 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.




(See

Fig

ure

5–7

)

Log

ical

Ele

men

t

Sys

tem

Cre

atio

nC

lass

Nam

e: s

trin

g {

key}

Nam

e: s

trin

g {

ove

rrid

e, k

ey}

Nam

eFo

rmat

: str

ing

Pri

mar

yOw

ner

Nam

e: s

trin

g {

wri

te}

Pri

mar

yOw

ner

Co

nta

ct: s

trin

g {

wri

te}

Ro

les:

str

ing

[ ]

{wri

te}

Log

ical

Dev

ice

(See

Co

re M

od

el)

1

Sys

tem

Co

mp

on

ent

Ser

vice

Cre

atio

nC

lass

Nam

e::

stri

ng

{w

rite

}N

ame:

str

ing

{o

verr

ide,

key

}P

rim

aryO

wn

erN

ame:

str

ing

{w

rite

} P

rim

aryO

wn

erC

on

tact:

: str

ing

{w

rite

}S

tart

Mo

de:

str

ing

(10

) {D

,en

um

}S

tart

ed:b

oo

lean

Sta

rtS

ervi

ce()

: u

int3

2S

top

Ser

vice

():

uin

t32

Ser

vice

Acc

essP

oin

t

Cre

atio

nC

lass

Nam

e: s

trin

g {

key}

Nam

e: s

trin

g {

ove

rrid

e, k

ey}

Ser

vice

Acc

ess

ByS

AP

1

Ho

sted

Ser

vice

SA

PS

AP

Dep

end

ency

Ser

vice

Ser

vice

Dep

end

ency

**

** *

*

Ser

vice

Co

mp

on

ent

*

*N

ameF

orm

at: s

trin

g{o

verr

ide,

enum

}

Ad

min

Do

mai

n

*w

*w

**

Ho

sted

Acc

essP

oin

t

Ser

vice

SA

PD

epen

den

cy

Rem

ote

Ser

vice

Acc

essP

oin

t

Acc

ess

Info

: str

ing

Info

Form

at:

uin

t16

{enu

m}

Oth

erIn

foFo

rmat

Des

crip

tio

n: st

rin

g

Rem

ote

Po

rt

Po

rtIn

fo: s

trin

gP

ort

Pro

toco

l: u

int1

6 {e

num

}O

ther

Pro

toco

lDes

crip

tio

n:

stri

ng

Act

ive

Co

nn

ecti

on

**

Co

nta

ined

Do

mai

n

**

*

Pro

toco

lEn

dp

oin

t

Nam

eFo

rmat

: str

ing

Pro

toco

lTyp

e: s

trin

g {

enu

m,D

}O

ther

Typ

eDes

crip

tio

n:

stri

ng

Pro

toco

lIFT

ype:

uin

t16

{en

um

}

*

*

Bin

dsT

o*

Pro

vid

esE

nd

po

int

*

*La

bel

edU

RI:

stri

ng

{req

uir

ed}

Ser

vice

Acc

essU

RI

*

En

able

dLo

gic

alE

lem

ent

En

able

dS

tate

: u

int1

6 {e

num

}O

ther

En

able

dS

tate

: st

rin

gR

equ

este

dS

tate

: u

int1

6 {e

num

}E

nab

led

Def

ault

: uin

t16

{enu

m}

Tim

eOfL

astS

tate

Ch

ang

e:d

atat

ime

Req

ues

tSta

teC

han

ge(

[IN

]Req

ues

ted

Sta

te {

enu

m},

[OU

T]

Job

: CIM

_Co

ncr

eteJ

ob

,[I

N]

Tim

eou

tPer

iod

: d

ateT

ime)

: u

int3

2 {e

num

}

Man

aged

Sys

tem

Elem

ent

*

*

FIG

UR

E 5–

8Lo

gica

l Cor

e Pi

ece



Ph

ysic

alE

lem

ent

Tag

: st

rin

g {

key}

Cre

atio

nC

lass

Nam

e: s

trin

g {

key}

Man

ufa

ctu

rer:

str

ing

Mo

del

: st

rin

gS

KU

: st

rin

gS

eria

lNu

mb

er:

stri

ng

Ver

sio

n:

stri

ng

Par

tNu

mb

er:

stri

ng

Oth

erId

enti

fyin

gIn

fo:

stri

ng

{w

rite

}P

ow

ered

On

: b

oo

lean

Man

ufa

ctu

reD

ata:

dat

etim

eV

end

orE

qu

ipm

entT

ype:

str

ing

Use

rTra

ckin

g: s

trin

g

Can

BeF

RU

ed: b

oo

lean

Sys

tem

(See

Fig

ure

5–8

)

En

able

dLo

gic

alE

lem

ent

(See

Fig

ure

5–8

)

Sys

tem

Pac

kag

ing

**

Cre

atio

nC

lass

Nam

e: s

trin

g {

key}

Dev

iceI

D:

stri

ng

{ke

y}P

ow

erM

anag

emen

tSu

pp

ort

ed:

bo

ole

an {

D}

Po

wer

Man

agem

entC

apab

iliti

es:

uin

t16[

] {D

, en

um

}A

vaila

bili

ty:

uin

t16

{D,

enu

m}

Sta

tusI

nfo

: u

int1

6 {D

, en

um

}La

stE

rro

rCo

de:

uin

t32

{D}

Err

orD

escr

ipti

on

: st

rin

g {

D}

Err

orC

lear

ed:

bo

ole

an {

D}

Oth

erId

enti

fyin

gIn

fo :

str

ing

[ ]

Po

wer

On

Ho

urs

: u

int6

4 {D

, u

nit

s}T

ota

lPo

wer

On

Ho

urs

: u

int6

4 {D

, u

nit

s}Id

enti

fyin

gD

escr

ipti

on

s: s

trin

g[

]A

dd

itio

nal

Ava

ilab

ility

: u

int1

6 {D

, en

um

}M

axQ

uie

sceT

ime:

uin

t64

{D,

un

its}

Set

Po

wer

Sta

te (

[IN

] P

ow

erS

tate

: u

int1

6 {e

nu

m},

[IN

] T

ime:

dat

etim

e):

uin

t32

{D}

Res

et (

):

uin

t32

En

able

Dev

ice

([IN

] E

nab

led

: b

oo

lean

): u

int3

2 {D

}O

nlin

eDev

ice

([IN

] O

nlin

e: b

oo

lean

): u

int3

2 {D

}Q

uie

sceD

evic

e ([

IN]

Qu

iesc

e:

bo

ole

an):

uin

t32

{D}

Sav

ePro

per

ties

( )

: u

int3

2R

esto

reP

rop

erti

es (

):

uin

t32

Log

ical

Dev

ice

Rea

lizes

*w

Sys

tem

Dev

ice

1

*

*

Sto

rag

eExt

ent

Dat

aOrg

aniz

atio

n:

uin

t16

{en

um

}P

urp

ose

: st

rin

gA

cces

s: u

int1

6 {e

nu

m}

Err

orM

eth

od

olo

gy:

str

ing

Blo

ckS

ize:

uin

t64

{un

its=

Byt

es}

Nu

mb

erO

fBlo

cks:

uin

t64

Co

nsu

mab

leB

lock

s: u

int6

4Is

Bas

edO

nU

nd

erly

ing

Red

un

dan

cy:

bo

ole

anS

equ

enti

alA

cces

s: b

oo

lean

Ext

entS

tatu

s: u

int1

6[ ]

{en

um

}N

oS

ing

leP

oin

tOfF

ailu

re: b

oo

lean

D

ataR

edu

nd

ancy

: uin

t16

Pac

kag

eRed

un

dan

cy: u

int1

6 D

elta

Res

erva

tio

n: u

int8

P

rim

ord

ial:

bo

ole

an

Bas

edO

n*

*

Ph

ysic

alE

lem

ent

Loca

tio

n

0..

1

*

*

Loca

tio

n

Nam

e: s

trin

g {

key}

P

hys

ical

Po

siti

on

: st

rin

g {

key}

Ad

dre

ss:

stri

ng

0..

1

*C

on

tain

edLo

cati

on

*

FIG

UR

E 5–

9Ph

ysic

al C

ore

Piec

e


3. Physical Elements (see Figure 5–9)

This piece incorporates the PhysicalElement, Location, LogicalDevice, andStorageExtent classes. Properties of PhysicalElement include strings definingthe manufacturer, part number, etc. A physical element may be associatedwith a specific Location, or with one or more Systems by the SystemPackag-ing association.

The LogicalDevice class incorporates many parameters, and a number ofmore specific classes are subclasses of LogicalDevice in the common models.A StorageExtent class is also a subclass of LogicalDevice in the core model. ARealizes association links LogicalDevice with a PhysicalElement, which inturn 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 thePhysicalElement class.

4. Collections and Groups

This piece shows how MSEs may be aggregated into Collections, which is asubclass of ManagedElement, and aggregated into a RedundancyGroup,which is a subclass of LogicalElement. StorageRedundancyGroup is a subclassof RedundancyGroup, and it is associated with multiple StorageExtentsthrough use of the ExtentRedundancyComponent association. One of thedistant 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 Realizesassociation 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 haverelationships 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 theStorage 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 StatisticalDataclasses, which themselves are direct subclasses of the ManagedElement class (alsocontained in the core model).

The physical model represents the physical composition and topology of thecomputer system, but not its functionality. That information is provided by sub-classes of the core LogicalElement classes, or as services hosted on the computersystem. The physical model provides information related to inventory and assetmanagement, including the definition of FRUs. The model describes enclosures,cards, slots, physical components, and cabling information. Many of the conceptsused are derived from the earlier DMTF Desktop Management Interface (DMI)standard.




Ph

ysic

alLi

nk

(See

Ph

ysic

al M

od

el[C

on

nec

tor,

Lin

k, &

Pac

kag

e])

Ph

ysic

alC

on

nec

tor

(See

Ph

ysic

al M

od

el[C

on

nec

tor,

Lin

k, &

Pac

kag

e])

Ph

ysic

alC

om

po

nen

t

(See

Ph

ysic

al M

od

el[P

hys

ical

Co

mp

on

ent]

)

Ele

men

tsLi

nke

dC

on

tain

er

Rep

lace

men

tSet

(See

Ph

ysic

al M

od

el[C

apac

ity

&R

epla

cem

ent]

)

Par

tici

pat

esIn

Set

Ph

ysic

alP

acka

ge

(See

Ph

ysic

al M

od

el[C

on

nec

tor,

Lin

k, &

Pac

kag

e])

Ph

ysic

alC

apac

ity

(See

Ph

ysic

al M

od

el[C

apac

ity

&R

epla

cem

ent]

)

**

*0

..1

Man

aged

Sys

tem

Ele

men

t

(See

Fig

ure

5–7

)

Ph

ysic

alE

lem

ent

(CO

RE

)

Tag

: st

rin

g {

key}

Cre

atio

nC

lass

Nam

e: s

trin

g {

key}

Man

ufa

ctu

rer:

str

ing

Mo

del

: st

rin

gS

KU

: st

rin

gS

eria

lNu

mb

er:

stri

ng

Ver

sio

n:

stri

ng

Par

tNu

mb

er:

stri

ng

Oth

erId

enti

fyin

gIn

fo:

stri

ng

Po

wer

edO

n:

bo

ole

anM

anu

fact

ure

Dat

a: d

atet

ime

Ven

do

rEq

uip

men

tTyp

e: s

trin

gU

serT

rack

ing

: st

rin

gC

anB

eFR

Ued

: b

oo

lean

(See

Fig

ure

5–7

)

Man

aged

Ele

men

t

Loca

tio

n (

CO

RE

)

Nam

e: s

trin

g {

key}

Ph

ysic

alP

osi

tio

n:

stri

ng

{ke

y}A

dd

ress

: st

rin

g

(See

Fig

ure

5–8

)

Log

ical

Ele

men

t

Sys

tem

(See

Fig

ure

5–8

)

0..

1*

(See

Fig

ure

5–8

)

En

able

dLo

gic

alE

lem

ent

Sys

tem

Pac

kag

ing

*

*

(See

Fig

ure

5–9

)

Log

ical

Dev

ice

Rea

lizes

*

*

Co

nta

ined

Loca

tio

n

Ph

ysic

alE

lem

ent

Loca

tio

n

0..

1

*

Ele

men

tCap

acit

y

*1

..n

*

*

Med

iaP

hys

ical

Sta

tDat

a

(See

Ph

ysic

al M

od

el[S

tora

ge

Sta

tist

ics]

)

(See

Co

re M

od

el)

Sta

tist

ical

Dat

a

Ele

men

tSta

tist

ical

Dat

a1

*C

olle

ctio

n

(See

Fig

ure

5–7

)

FIG

UR

E 5–

10Ph

ysic

al M

odel


The Statistics classes are included in this model; in some circumstances theinformation reported relates to boundaries defined by the physical model—thatis, 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 termsof 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 ofPhysicalCapacity.

Location information may be specified for each Physical Element via thePhysicalElement association to the Location class defined in the core model, whichincludes 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 theCollection 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 associationrelates 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 whereremovable 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 PhysicalElementstogether 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 todescribe 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 elementsthat are connected, and where a connector is involved a LinkHasConnectorassociation 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 interopmodel provides management information related to the capabilities of objectmanagers 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 twoclasses are related via the CommMechanismForManager association, and theObjectManagerCommunicationMechanism class is itself a subclass of theServiceAccessPoint class.

A ProtocolAdapter class is another subclass of the Service class in thecore model and associates via CommMechanismForAdapter to the Object-ManagerCommunicationMechanism class. For SMI-S, the ProtocolAdapterclass represents the entity that converts the representation of CIM in XML toa native format.

2. Namespace and SystemIdentification

Namespace and SystemIdentification are both subclasses of the ManagedEle-ment class, and are related by the SystemInNamespace association. TheNamespace class defines all of the namespaces supported by the Object Man-ager with which NamespaceInManager associates, and includes the type ofinformation contained in each namespace. The SystemIdentification classprovides enough information to identify the system(s) represented in theNamespace.

3. Provider

This piece describes a provider and its capabilities. The capabilities includethe class that the provider is supporting, including its properties and meth-ods. The model also defines the mechanism by which a provider is requiredto register with the Object Manager.

4. Profile

This piece contains two experimental classes: RegisteredProfile, a subclass ofManagedElement, 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 theReferencedProfile association.

5. Statistical Data

The CIMOMStatisticalData class is a subclass of the StatisticalData class inthe core model, and contains usage statistics about the Object Manager interms of CIM operations.



System Model

The system model defines computer system–related abstractions. The only partof this model relevant to SMI-S is the ComputerSystem class, a subclass from theSystem 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 andthey host services and access points.

The ComputerSystem class can describe both general-purpose and dedicatedsystems. Much of the equipment in a storage network is modeled as a computersystem dedicated to a specific function.



6

Profiles of Storage NetworkEquipment Types

The DMTF Common Information Model described in the previous chapter con-tains a rich object-oriented representation of a managed environment. The SNIASMI-S shows how storage networks can be managed as systems, using constructstaken 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 theiruse 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 managementof a particular set of subsystems for a defined set of uses. A profile can referto one or more subprofiles and in some cases to other profiles.

• A subprofile is a named subset of a profile. Typically, a formal subprofile isdefined to allow a specific set of functions to be present only in someinstances of a profile. However, a subprofile itself is an atomic unit—eitherall or none of its functionality is supported. A common subprofile is a set offunctions that may appear in more than one profile.

• A package is a set of constructs that are used together to define an aspect ofa model.

• A recipe is a WBEM service use case, a script for the interaction between aWBEM Client and Server as they follow a specific path through the schemato achieve a specific task. A recipe operates within a defined scope.

• A WBEM service advertises supported profiles and subprofiles using SLP. Theservice also reports the profiles and subprofiles that are supported throughthe 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 ControlEnhanced Zoning and Enhanced Zoning ControlFDMI

Switch BladesRouter Software

Backend PortsLUN Mapping and Masking

Hosts FC HBAHost Discovered Resources Initiator

Target

Storage Array ClusterExtra Capacity SetSoftwareAccess PointsLocationPool Manipulation, Capabilities, and SettingsExtent MappingDisk DriveBackend PortsLUN CreationLUN Mapping and MaskingCopy ServicesJob ControlDevice Credentials

In-Band Virtualization ClusterSystem Extra Capacity Set

SoftwareAccess PointsLocationPool Manipulation, Capabilities, and SettingsExtent MappingLUN CreationLUN Mapping and MaskingCopy ServicesJob ControlDevice Credentials

Storage Library SoftwareAccess PointsLocationLimited 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.

ConventionsThe 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. Itprovides 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 orsubprofile. Subprofiles inherit the standards listed in the parent profile, asonly unique standards are listed. For the majority of profiles the standardsidentified 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 ofthe CIM schema, and do not require the new functionality that has beenincluded in Version 2.8.

3. Profile Dependencies

This component contains a list of the names of profiles that are required bythis profile (or subprofile). Optional subprofiles and profiles are listed in item13 on page 55.

4. CIM Server Requirements

This component lists requirements placed on the WBEM Server that arerequired in order to support the profile or subprofile. Typically, these require-ments include the specific functional groups of intrinsic methods that needto be supported (see Table 5–3), and also any extrinsic methods needed. The



requirement to advertise support for a profile or subprofile is also addressedin this section.

A subprofile may simply declare that the support required is the same asfor the parent profile, but may also add specific requirements.

5. Instance Diagrams

This component contains one or more instance diagrams. Instance diagramsuse the UML notation defined previously to describe classes and associationsbut represent a particular configuration; multiple instances an object may bedepicted in an instance diagram.

6. Durable Names and Correlatable IDs

This component defines the Durable Names and Correlatable IDs forresources exported by the profile and identifies the Durable Names and Cor-relatable IDs used by other profiles. For the Durable Names exported by theprofile, the section identifies the valid name formats and the specific encod-ing of names for each name format. For Correlatable IDs exported by theprofile, the source for the ID is identified and the conditions that would causethe ID to be reset are identified.

7. Methods

This component lists the extrinsic and intrinsic methods that are defined asrequired by the profile.

8. Client Considerations

This component contains a summary of the implementation concerns thatare likely to be encountered by products and services that rely on the profilebeing described. This section also identifies how to locate any subprofilesrequired for this profile.

9. Recipes

This component contains a set of processes that sequence the operations andother steps defined in reference to the objects contained in this profile toaccomplish particular tasks.

10. Instrumentation Requirements

This component contains a summary of the implementation concerns thathave to be accounted for by agents that implement instances contained in thisprofile.

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 aproperty 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 areoptional for this profile.

Recipe Pseudo-Code Conventions

All SMI-S recipes use a common syntax to describe the sequence of operationsand 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:

• �condition�defines 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 notimportant 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 perusual.

Instances and Object Names

The following items relate to the naming and instantiation of objects as definedin the previous chapter. Note that arrays defined in this and subsequent sectionscan 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 theinstance.

• $name.getNameSpace() is a method that returns the namespace name forthe instance or object name.

• {value1, value2 . . .} represents an array comprised of selected values of agiven type; is not referable by a variable.

• $name[] represents an array of instances with a given variable name. Thearray 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 thearray.

General Variables

The following variables relate to all types of items:

• #name represents a general variable that is not an instance identifier or objectname as above. The variable type may be a string, number, or some otherspecial 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 methodsand execute against objects as defined in the schema. Note that arguments arealways 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 inmany programming languages. Tests for equivalency, nonequivalency, logicalAND 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 unitaryoperator 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 usagein many programming languages. “For,” “If,” and “Do/While” structures aredefined, 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 bycommas.

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 complexdata types or structures.

2. $instance � newInstance(“Classname”)

This function creates an instance that did not previously exist in the WBEMservice, 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 equivalentto the test variable. The �variable array� must be of variables of the sametype as the test variable. If equivalency is found with at least one value, thenthe function returns true; otherwise, false is returned. If the array is not asimple, or non-CIM, data type, then the test value must be a property, or avariable representing or containing a property.

5. %Argument � newArgument(“Argument Name”, �variable�)

This function creates an argument of a given name containing a value.



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 verysimilar to that used in the Java programming language.

PackagesSMI-S defines two packages: a PhysicalPackage and a Software Package. These aredescribed in SMI-S using a variant of the common format defined above fordescribed profiles and subprofiles.


System

PhysicalPackage(e.g., Chassis) Product

SystemPackaging

ProductPhysicalComponent

PhysicalPackage Product


Container(e.g., PackageInChassis)

LogicalDevice(e.g., Drive, physical tape,

device changer) Realizes

ProductParentChild

Product

ProductParentChild

FIGURE 6–1 PhysicalPackage 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 maybe done by enumerating the top-level System classes, and then traversing theSystemPackaging 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 thestructures 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 Figure6–2. The package is used to make available information about installed soft-ware to a WBEM Client. The package includes the SoftwareIdentity class thatis linked to the system using a SoftwareInstalledOnSystem association. Soft-


SoftwareIdentity

InstalledSoftwareIdentity

SoftwareIdentity

InstalledSoftwareIdentity

ComputerSystem

ExtraCapacitySet

MemberOfCollection

ConcreteIdentity

ComputerSystem

ComponentCS

FIGURE 6–2 Software Package Instance


ware information can be associated with the top level ComputerSystem (if allcomponents are using the same software) or a component ComputerSystemif the software loaded can vary by processor.

Common SubprofilesCommon subprofiles are those that are used in multiple profiles, and are thusdescribed separately. The following common subprofiles are currently defined bySMIS-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 supportdevice-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, multipleinstances 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 multipleprocessing elements that act as a cluster.

When this subprofile is used, each processing element of the cluster isrepresented by its own ComputerSystem instance, but is also collected into aComputerSystem 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 devicesto 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 redundancyoffered 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 typicallyprovide redundancy, which can be of several kinds.

a. Load Balancing This kind typically means that each path to a storagedevice 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. Eachcomputer system is associated with an ExtraCapacitySet instance usinga MemberOfCollection association. If computer systems operate asredundant pairs, then there would be multiple ExtraCapacitySetinstances, 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-overonly and have lower performance. In this case the LoadBalancedSetproperty is set to false. The priority of different access paths is shown bythe 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 thefailing computer system.

4. Disk Drive Subprofile

An instance diagram of the disk drive subprofile is shown in Figure 6–3. Thesubprofile is used to represent a random access storage device. The device ismodeled as a MediaAccessDevice (DiskDrive) containing (MediaPresent)some logical media (StorageExtent) that are realized (RealizesExtent) by somephysical 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 toa 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 higherlevel product such as a system.

The profile definition includes a recipe showing how to locate and determinethe 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 specificstorage extents and physical devices. In the StoragePool mechanism, storageallocation 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 onthe same extents. The Extent Mapping subprofile allows an agent to representthis 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 modeldescribed in Chapter 5.



7. Software Subprofile

The Software subprofile is used to represent software installed on equipmentin 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 InstalledSoftwareIdentityassociation.

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 clonesand point-in-time snapshots of nonvolatile storage. The profile also providessupport for remote replication services (either asynchronous or synchro-nous) for nonvolatile storage. The Copy Services subprofile currently only


StorageExtent

'Logical' media MediaPresent

PhysicalMedia

'Physical' media

RealizesExtent

PhysicalPackage

Physical drive

Realizes

PackagedComponent

Product

Disk drive product info


SoftwareIdentity

Firmware

DeviceSoftwareIdentity

ComputerSystem

SCSIProtocolController

ProtocolController

AccessesUnit

SystemDevice

DiskDriveLogical controller

device

SystemDevice

FIGURE 6–3 Disk Drive Subprofile Instance


specifies the storage volumes, and has only been validated for use in supportof volume snapshots, although the functionality defined is considerably moregeneral.

Copy services are addressed by the StorageSynchronized associationbetween two storage elements that defines their relationship. The modeladdresses the use of StorageSynchronized in the context of StorageVolumes(disk arrays and virtualization systems). The association is a subclass of theSynchronized association and is used to represent snapshots and mirrorcopies of storage elements. StorageSynchronized indicates that two storageobjects 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 copyof the source. Updates to the source volume are not immediately availableon 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.


StorageSynchronized

StorageVolume(SourceElement)

StorageVolume(Replica)

StorageConfigurationService

CreateReplica()ModifySynchronization()AttachReplica()

System(ComputerSystem)

HostedServiceStorageConfigurationCapabilities

SupportedAsynchronousActions[]SupportedSynchronousActions[]SupportedStorageElementTypes[]SupportedCopyTypes[]InitialReplicationState ElementCapabilities

Note: For simplicy, the StorageCapabilities,StorageSetting, and ElemenSettingData classes are not shown.

FIGURE 6–4 Copy Services Subprofile


b. Sync In this type, replication creates and maintains a synchronous copyof the source. Writes done to the source volume are reflected on thereplica volume before control is returned to the host that issued the writeto the source volume.

c. UnSyncAssoc In this type, replication creates an unsynchronized copyand 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 unsynchronizedcopy, but does not maintain the association with the source. This is asimple 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 resyncor restore request. This status also appears for UnSyncAssoc, indicatingthat the point-in-time copy (as of the WhenSynced date) has been completed.

• Synchronized—The Async or Sync relationship is active and copying isgoing 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. Therepair action would be to execute a ResyncReplica or a RestoreFrom-Replica method.

• Initialized—The relationship has been established, but the copy has notbeen 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 methodsdescribed by a profile may take some time to execute (longer than an HTTPtime-out), and allows asynchronous execution of the method as a “job.”

When the Job Control subprofile is implemented and a client executes amethod with the ConcreteJob reference as an output, a reference to aninstance of ConcreteJob is returned and the return value for the method isset to “Method parameters checked - job started.” The ConcreteJob instanceallows 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 linkedby 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 andmodifying storage pools and their capabilities and settings.

A StoragePool is an abstract notion of a blob of consumable storagespace. A pool has a certain set of “StorageCapabilities” that indicate the rangeof Quality of Service requirements that can be applied to objects created fromthe 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 createdfrom a pool have the same scope. Child objects (such as StorageVolumes orStoragePools) created from a StoragePool are linked back to the parent poolusing an AllocatedFromStoragePool association. There are two properties ofStoragePool 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 StoragePoolaggregates 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 externalinterface. In the class hierarchy they are a subclass of a StorageExtent. In SCSIterms, StorageVolumes are Logical Units.

This subprofile defines the methods to be used if the storage systemexposes functions for creating and modifying storage pools. The Storage-ConfigurationService, in conjunction with the abstract concept of a storagepool, allows generic clients to configure pools of storage within storage arrays



without having to have specific knowledge about the array configuration. Thenew service uses the following methods:

a. CreateOrModifyStoragePool—This method creates a pool of storagewith some set of capabilities defined by the input StorageSetting. Thesource 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 thefreed-up storage to the underlying entities.

c. CreateSetting—This method creates a setting for use in pool creationthat is consistent with the StorageCapabilities and may be modifiedbefore 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 aboutthe 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 sourceStoragePool.

• ReturnToStoragePool—This method returns an Element previously cre-ated with CreateOrModifyElementFromStoragePool to the originatingStoragePool.

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 theStorageCapabilities and may be modified before use in creating a StorageVolume.

The StoragePool instances provide the ability to retrieve the possible sizesfor the StorageVolume creation or modification given a StorageSetting as agoal, using the following methods:

• GetAvailableSizes—This method returns a list of discrete sizes given agoal.

• GetAvailableSizeRanges—This method returns the range of possiblesizes 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 ashared secret is required to be able to access a device. This shared secret isdifferent from the credentials used by the WBEM Client for authenticationwith the WBEM service. The client is not to be provided with the passwordof the credential, only the principal. The device credentials can be exposedthroughout 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 somestorage systems for a client to discover and manage the internal connectionsbetween the array processors and physical disks. For example, an array mayhave 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 diskscan be modeled similarly to a JBOD configuration. A property of the FCPortclass called UsageRestriction is available to indicate whether the controller isproviding a front-end (target) or back-end (initiator) interface. The RAIDcontroller itself has front-end ports (that are connected to customer hosts orswitches) 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 shownin Figure 6–5. The subprofile is used to represent the interface supplied by astorage system to allow a WBEM Client to specify which initiators (hosts orHBA 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 orread only) and the SCSI Logical Unit Number as seen by an initiator througha specific set of ports. The ability to limit access is called Device Masking; theability to specify the device address seen by particular initiators is calledDevice Mapping (for SCSI systems, these terms are known as LUN Maskingand LUN Mapping). The model described in the subprofile is generalized toinclude access management in disk arrays, virtualization systems, and routersused 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 theLogical Unit Number.



In this subprofile, the existence of a ControllerConfigurationServicewith a ConcreteDependency association to a ProtocolController governsthe high-level device mapping policy for that protocol controller. If theservice does not exist, then regardless of host port, the policy is that Pro-tocolControllerForPort connects a ProtocolController associated to aLogicalPort. If the service is present, then for a particular host port, thepolicy is that ProtocolControllerForPort connects a ProtocolControllerto a LogicalPort, but only when access is explicitly granted to either theProtocolController or the associated LogicalPort for that particular hostport.

ProtocolControllerForUnit associates a ProtocolController with its LogicalDevices; the controller-relative address (such as a SCSI LogicalUnit Number) is modeled as the DeviceNumber property of Protocol-ControllerForUnit.


ProtocolControllerProtocolControllerForPort

LogicalPort

LogicalDevice(e.g. StorageVolume)

ProtocolControllerForUnit

Privilege

SystemSpecificCollection

StorageHardwareID

AuthorizedTarget

AuthorizedSubject

D

StorageHardwareID

MemberOfCollection

ControllerConfigurationService

CIM_ProtocolControllerMaskingCapabilities

PrivilegeManagementService

StorageHardwareIDManagementService

ComputerSystem

HostedService

HostedService

HostedService

ConcreteDependency

ConcreteDependency

ElementCapabilities

*

*

*

**

*

*

*

AuthorizedSubject

*

*

AuthorizedTarget**

AssociatedProtocolController

ConcreteDependency

ConcreteDependency

*

*

*

CIM_StorageClientSettingData

ElementSettingData

HostedCollection

FIGURE 6–5 LUN Mapping and Masking Subprofile


ProtocolControllerForPort associates a controller to one or moreLogicalPorts.

c. LogicalPort This object is the superclass of target ports for varioustransports.

The methods supported by this subprofile are:

• ControllerConfigurationService creates a ProtocolController that isused as an AuthorizedTarget. If multiple target ports are passed in,all expose the same view (i.e., the same devices with the same unitnumbers and permission). This method does not create the portinstances, but does create ProtocolControllerForPort associationsbetween 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 deleteschild ProtocolControllers (those at the dependent end of Associated-ProtocolController associations from this ProtocolController) plusall child ProtocolControllers’ direct associations. If the Delete-LogicalUnits parameter is True, the provider also deletes Logical-Device instances associated via ProtocolControllerForUnit to thisProtocolController and its children. LogicalDevice instances are onlydeleted when they are not part of any ProtocolControllerForUnitassociation.

• 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 anAuthorizedTarget association, the provider should update the accessconfiguration in the underlying hardware when AttachDevice is called.

• AssignAccess associates a subject ManagedElement and a targetManagedElement. If necessary, a Privilege instance is created usingthe settings in the method parameter.

• RemoveAccess revokes all privileges or the specified Privilege for anamed target/subject. If a Privilege reference is supplied, then thismethod acts only on that specific Privilege; otherwise, all Privilegeinstances associated with the named subject/target are affected bythe operation. If a Privilege instance is left with no target associa-tions, it is deleted.

• CreateStorageHardwareID creates a StorageHardwareID and theConcreteDependency association between this service and the newStorageHardwareID.

• DeleteStorageHardwareID deletes a StorageHardwareID and theConcreteDependency 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

ProfilesSMI-S profiles are grouped into four areas, depending on their applicability in astorage 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 LibraryProfiles

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, andis abstracted as a system (in network terms, a “cloud”). The approach follows thatused 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) andplatforms (e.g., hosts, storage arrays, and tape libraries)



A storage network is modeled as containing one or more Fabrics, each ofwhich is modeled as AdminDomain. The “containment” of Fabrics in SANs isthrough the association ContainedDomain. An AdminDomain in CIM is keyedby the property Name with an associated optional property NameFormat. ForFibre 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 thereason it is defined in the Network model). A ConnectivityCollection groups a setof ProtocolEndpoints together that are able to communicate with each otherdirectly. The ProtocolEndpoint is associated with the ConnectivityCollection byMemberOfCollection. A link is represented by the association ActiveCollection,which associates two ProtocolEndpoints, defined as a connection that is currentlycarrying traffic or is configured to carry traffic.

Using this approach it will ultimately be possible to represent multipleinstances of ConnectivityCollection (for example, FC, IP [over FC]), and IP ([FCencapsulated in IP]) for the same fabric.


AdminDomainAdminDomain ContainedDomain

SAN

Fabric

LogicalNetworkComponent

ComputerSystem

Dedicated="Storage"

FCPort

HostedCollection

SystemDevice

LogicalPortGroup

MemberOfCollection

Array

ProtocolEndpoint DeviceSAPImplementation

ActiveConnection

HostedAccessPoint

ProtocolEndpoint

ProtocolEndpointMemberOfCollection

ActiveConnection

ComputerSystem

FCPort

SystemDevice

LogicalPortGroup

MemberOfCollection

HostedCollection

Host

Component

ComputerSystem

Dedicated="Switch"

FCPortSystemDevice

Switch

DeviceSAPImplementation

HostedAccessPoint

DeviceSAPImplementation

HostedAccessPoint

FIGURE 6–6 Fabric, Host, Switch, and Array Overview


The zoning services model is defined in a subprofile, and an instance modelfor 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 modelfor defining Zone Sets, Zones, and Zone Members, and for activating a Zone Setin 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, aZoneAlias as a NamedAddressCollection, and Zone Member as ZoneMember-shipSettingData. ZoneSets only contain Zones associated by MemberOfCollection.Zones only contain ZoneMembershipSettingData associated by ElementSettingDataor NamedAddressCollections associated by MemberOfCollection.

The class ZoneMembershipSettingData has two properties that indicate howthe device was identified to be zoned. They are ConnectivityMemberType (suchas PermanentAddress for WWN, NetworkAddress for FCID, etc.) and Connec-tivityMemberID, which contains the actual device identifier.


Zone

ZoneSet

ZoneService

ZoneCapabilities

AdminDomain

SystemCapabilities

MemberOfCollection

ZoneMembershipSettingData

NamedAddressCollection

HostedService

MemberOfCollection

HostedCollection

ElementSettingData

FIGURE 6–7 Zoning Instance Diagram


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 toFalse, are hosted on either the AdminDomain representing the Fabric, as shownin 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 sameSystem (AdminDomain or ComputerSystem) as the Inactive Zone Sets using theassociation 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 toZones. 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 zoneset

• 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 multipleblades on a backplane—the LogicalModule class can optionally be used to modeleach submodule, and as an aggregation point for the switch ports. FCPortdescribes 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 classis expected for each instance of the FCPort class. FCPortStatistics expose real-timeport health and traffic information.

Router Profile

An instance diagram of the Router profile is shown in Figure 6–9. The instancediagram shows a system with parallel SCSI and Fibre Channel buses.




FCPortFCPort

FCPort ComputerSystemDedicated="Switch"

FCPort SystemDevice

Product

PhysicalPackage

Realizes

ProductPhysicalElements

ComputerSystemPackage

FCPortFCPort

FCPort ComputerSystem

Dedicated="Switch"

FCPortSystemDevice

LogicalModuleModule

Port

SystemDevice

DeviceStatistics

FCPortStatistics

SoftwareInstalledOn

System

(Firmware)

SoftwareIdentity

PhysicalPackage

RemoteServiceAccessPoint

HostedAccessPoint

FIGURE 6–8 Switch Instance Diagram

ComputerSystem

Dedicated[x]= 'Router'

SoftwareElement

InstalledSoftwareElement

LogicalDeviceSCSIProtocolController

ConnectionRole = 'Server'

FCPort

ProtocolControllerForPort


ConnectionRole = 'Client'

ProtocolControllerAccessesUnit LogicalDevice

1

1

ConcreteIdentity

Realizes

PhysicalPackageProduct



PhysicalPackageProduct


HostedService

ControllerConfigurationService


LogicalPortGroup

MemberOfCollection

FIGURE 6–9 Router Instance Diagram


The Router profile represents devices that translate between different typesof SCSI buses. Devices on the parallel bus are served to the Fibre Channel buswithout changing the characteristics of the device.

FC HBA Profile

An instance diagram of the FC HBA profile is shown in Figure 6–10. The instancediagram represents an HBA as a physical device that contains one or more FibreChannel ports. A single system may contain one or more HBAs.

An HBA is represented by FCPorts associated to a ComputerSystem throughthe SystemDevice association.

The containment aspect of the HBA’s physical implementation is modeled bythe FCPorts being associated to PhysicalPackage (typically Card) through theRealizes association. If the HBA has logical operations that apply to the HBA andnot to an individual port, then the PortController can also be instantiated. ThePortController is associated to the ComputerSystem through the SystemDeviceassociation and associated to the ports through the controlled by association.

Host Discovered Resources Profile

The Host Discovered Resources profile represents the discovery of SAN resourcesand presentation of those resources to the Host Operating System by an HBA.


ComputerSystem

FCPort

LogicalPortGroup

MemberOfCollection

HostedCollection

SystemDevice

SCSIController FCPort Statistics

Product

ComputerSystem

FCPort FCPortStatistics

MemberOfCollection

PortController

InstalledSoftwareElement

(Driver)

SoftwareIdentity

LogicalPortGroup

(ROM BIOS)SoftwareIdentity

(Firmware)SoftwareIdentity

PhysicalPackage



SystemDevice

SCSIProtocolController ConcreteIdentity




HostedCollection

ControlledBy

Realizes

SystemDevice

FIGURE 6–10 FC HBA Instance Diagram


The Host Discovered Resources agent uses the HBA API—first standardizedby SNIA, and now taken up by INCITS T11—to create a generic model of thelogical SAN and attached storage. The agent models elements also exposed byHBA, storage, and switch agents. A client can use durable names to equate objectsfrom 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 agentduplicate those exposed by canonical HBA, storage, or switch agents that providethe physical model.

The Host SAN Resources are independently instantiated for each HBAFCPort 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


ComputerSystem

FCPort


StorageVolume

StoragePool



AllocatedFromStoragePool

AllocatedFromStoragePool StorageCapabilities

StorageSetting

SystemDevice

ElementCapabilities

ElementSettingData

HostedStoragePool

SystemDevice

FIGURE 6–11 Array Instance Diagram


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 SCSIProtocolControllerand FCPort combination. Initiator SCSIProtocolControllers have ProtocolCon-trollerAccessesUnit associations to logical units (LogicalDevice subclasses) thatare 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. Anadditional set of (common) subprofiles extends this description and also enablesactive configuration of the array. The terminology used in the description of thisprofile, storage pools, primordial pools, and storage volumes, was defined in thePool 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 arraycontrollers to create a seamless pool of storage. The virtualization system in turnallocates 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 containredundant 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 storageto 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 ConcreteComponentassociation. 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



SCSIProtocolController and to the FCPort indicate ports to which the volume ismapped. The StorageVolumes are described by the StorageSetting class connectedby 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 isshown 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 somelibraries, notably small autoloaders, external hosts access a library’s Chang-erDevice through the ProtocolController of a MediaAccessDevice. For suchlibraries, an additional ProtocolControllerForUnit association should beinstantiated between the MediaAccessDevice’s ProtocolController and theaffected 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.




StorageVolume

LUID: //VPD pg 83 IDDefaultAccessMode

StorageExtent

Name: //VPD pg 83 IDDefaultAccessMode

SCSIProtocolContoller

ProtocolControllerAccessesUnit

FCPort

StoragePool


StorageSetting

ElementSettingData



ComputerSystem

Dedicated[x]='InbandVirtualization'

HostedStoragePool

ConcreteComponent

FCPort


FIGURE 6–12 In-Band Virtualization Instance Diagram



StorageLibrary

Product

Chassis

MediaAccessDevice

ChangerDevice

SystemDevice

SystemDevice


LibraryPackage

ProtocolController



TapeDrive

SystemDevice

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, theninstantiate 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, cartridgeaccess port, or import/export elements) found in many libraries. This sub-profile defines the required classes necessary to publish information aboutthese elements.



Nam

e (I

nst

ance

ID)

Ele

men

tNam

e

Ob

ject

Man

ager

[Pro

pag

ated

Key

s]C

reat

ion

Cla

ssN

ame

Na

me

Cla

ssIn

foD

escr

ipti

on

OfC

lass

Info

Nam

esp

ace

[Def

ault

Co

mm

un

icat

ion

Mec

han

ism

= "

XM

L o

ver

HT

TP

"]C

IMV

alid

atedC

IMX

MLC

om

mu

nic

atio

nM

ech

anis

m

Nam

esp

ace

InM

anag

erC

om

mM

ech

anis

mFo

rMan

ager

Inst

ance

IDR

egis

tere

dO

rgan

izat

ion

Oth

erR

egis

tere

dO

rgan

izat

ion

Reg

iste

red

Nam

eR

egis

tere

dV

ersi

on

Ad

vert

iseT

ypes

[]A

dve

rtis

eTyp

eDes

crip

tio

ns[

]

Reg

iste

red

Pro

file

Inst

ance

IDR

egis

tere

dO

rgan

izat

ion

Oth

erR

egis

tere

dO

rgan

izat

ion

Reg

iste

red

Nam

eR

egis

tere

dV

ersi

on

Ad

vert

iseT

ypes

[]A

dve

rtis

eTyp

eDes

crip

tio

ns[

]

Reg

iste

red

Su

bP

rofi

le

Inst

ance

IDR

egis

tere

dO

rgan

izat

ion

Oth

erR

egis

tere

dO

rgan

izat

ion

Reg

iste

red

Nam

eR

egis

tere

dV

ersi

on

Ad

vert

iseT

ypes

[]A

dve

rtis

eTyp

eDes

crip

tio

ns[

]

Reg

iste

red

Su

bP

rofi

le

Su

bP

rofi

leR

equ

ires

Pro

file

Su

bP

rofi

leR

equ

ires

Pro

file

Man

aged

Ele

men

t

Ele

men

tCo

nfo

rmsT

oP

rofi

leSys

tem

Ho

sted

Ser

vice

Ref

eren

ced

Pro

file

(e.g

., S

yste

m)

FIG

UR

E 6–

14Se

rver

Inst

ance

Dia

gram


Server Profile

An instance diagram of the Server profile is shown in Figure 6–14. The profile isused to represent the functionality of the WBEM service itself, using the interopmodel 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 theServer profile. The interop Namespace refers to the first namespace found in theInteropSchemaNamespace attribute of the SLP Template.

A Server is modeled as a System with a HostedService association to anObjectManager. The ObjectManager is a subclass of Service, and defines the capa-bilities of an Object Manager based on the communication mechanisms that itsupports.

The namespace model of the Server profile describes the namespaces man-aged by the ObjectManager and the type of information contained within thenamespace. All namespaces supported by the Server can be identified by theNamespace 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 theRegisteredProfile.

The RegisteredProfile part of the model is used to specify the profiles sup-ported by the ObjectManager. It also includes the specification of subprofiles thatare 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 andis managed by the Server. The RegisteredProfile instances can be found by enu-merating RegisteredProfiles within the Interop Namespace. A WBEM Clientwould find all profiles supported by the Server by enumerating RegisteredProfiles,enumerating RegisteredSubprofiles, and subtracting the second list from the firstlist. This will yield the list of profiles supported by the ObjectManager. For eachprofile instance, the subprofiles that have been implemented (for the instance)should be identified via the SubprofileRequiresProfile association. Subprofiles aremodeled using the RegisteredSubprofile class. The ElementConformsToProfileassociation ties the RegisteredProfile to one or more ManagedElements. TheseManagedElements are typically ComputerSystems or AdminDomains, and mayhave zero or more ElementConformsToProfile associations to RegisteredProfiles.



7

Available Tools andDevelopment 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 interoperabilityfacilities that are available to developers wishing to instrument their products toconform to, or obtain information through, the storage management interface.

Development ToolsThe 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 thesetools; they are merely listed for information. In addition, many of these items arelicensed 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-basedimplementation of an Object Manager. The SNIA implementation provides bothclient and server CIM/WBEM technologies. Use of Java as the implementationlanguage 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, seehttp://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 ofthe DMTF WBEM specifications, but has become a set of production-quality opensource code designed to be used in high-volume server implementations. Manyexisting SMI-S-compatible Object Managers are based on this code.

Pegasus defines a modular, powerful instrumentation environment with theintention of speeding up the process of making equipment manageable. It onlyimplements 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 theCompaq 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 otherGNU tools. It supports the integration of SLP with the Object Manager usingOpenSLP. It includes a C�� Client API library, and an MOF Compiler with anembeddable 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 instancesand 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. CIMMiner 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 tothe WBEM definitions, including:

1. Nortel Networks MOF to HTML Converter

Nortel Networks has developed the mof2html tool to convert the CIMschema and any extension MOF files into browsable HTML files. The tool isreleased in C�� source code format. Instructions for building and running



it are contained in the README.txt file. This is an initial but usable releaseof this tool, and extensions are encouraged.

2. Microsoft MOF Editor

Microsoft has developed an MOF Editor, and has granted distribution rightsto 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 theDMTF’s CIM v2.3 definitions. Additionally, the CCX tool conforms to theDMTF’s “Specification for CIM Operations over HTTP v1.0” and “xmlCIMv2.0.” Two tests are provided: class definitions testing and class instance andassociations testing. In both tests, schema definitions and class definitionssuch as class properties and associations are verified for existence and correctdata type.

CCX may also function as a design and debug tool. A CIM parser reportsany syntax errors encountered while parsing the schema and requirementsfiles.

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 browseCIM objects and their associations in various CIM Object Managers. The appli-cation can be downloaded from either http://www.cimnavigator.com or fromhttp://www.wbemsource.org (the pages of The Open Group’s WBEMSource Initiative).

Development FacilitiesThe SMI program at SNIA is a wide-ranging effort and incorporates activitiesbeyond merely creating the SMI specification (see Figure 7–1). Other aspects ofthe program include:

1. ICTP

ICTP is a SNIA-wide initiative called the SNIA Interoperability ConformanceTest Program. ICTP consists of master test suites that are developed, owned,and operated by SNIA. ICTP is an integral step toward providing verificationthat a storage vendor’s product implementation complies with the SMI spec-ification. For more information, including the costs of participation in theprogram, see http://www.snia.org/tech_activities/ictp/.

2. SMI-Lab

SMI-Lab is the SNIA-hosted program that is used by storage vendors topretest their SMI implementation before entering formal ICTP testing.



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 theICTP 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 alsoused as a prestaging event for SMI operability demonstrations that take placeat the twice-yearly StorageNetworkingWorld conferences.

3. Education

SNIA regularly schedules week-long classes to introduce developers to theWBEM technologies, and an annual conference (“summit”) focused on alltechnical 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 assistworldwide SMI developers in implementing the SMI Specification (SMI-S)from project conception to product delivery. The SMI-S Developer’s Networkis focused on the following:

• Increasing understanding of the specification by providing online accessto tutorials, training, and a place to get questions answered


Storage Management InitiativeStorage Management Initiative

SMI ... more than a specificationSMI ... more than a specification

SMI-SSMI-SOpen

InterfaceOpen

Interface

StorageManagement

Forum

StorageManagement

Forum

SMI-LabSMI-LabDeveloper’s

NetworkDeveloper’s

Network

ICTPICTP

EducationEducation

TechnicalSteeringGroup

TechnicalSteeringGroup

FIGURE 7–1 SMI Program


• Providing technical assistance in getting started by providing access tothe basic information needed to start developing and a ConsultantsDirectory 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 meetto share information and knowledge and assist each other throughoutthe development process.

• Providing support during the testing process through the SMI-Lab andICTP programs

For more information, see http://www.snia.org/smi/developers.



8

Future Developmentsand Goals

One of the major advantages of the WBEM definitions underlying SMI is theirleverage 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 closelyfollow the final release of a specific CIM schema version.

Both SNIA and DMTF have plans to add considerable functionality to thedefinitions available for storage management, and these are described separatelybelow. DMTF’s approach to the addition of functionality to the schema is oftento declare that new class definitions are “experimental” so as to highlight the factthat the definitions are likely to change in the next version after implementationexperience is gained. Following this convention, SMI-S contains an annex ofexperimental profiles that are expected to be developed further and included in afuture revision as mandatory items.

SNIA SMIThe following sections detail plans already in place for enhancements to SMI-Sfunctionality in future revisions.

Revision 1.0.1

The existing SMI-S document contains an annex that describes a number ofenhancements to the SMI definitions that have already been worked on to someextent, 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 forLibrary Device subprofiles

• An Extender profile

• A Management Appliance profile

• An Out-of-Band Virtualizer profile

• A JBOD (Just a Bunch of Disks) profileA 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 beingconsidered 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 simultaneouslyrelying 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, includingrepresentations 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



Future Revisions

Two major items, locking and policy, are also being addressed for inclusion inSMI-S at some future point. These items may well require work by both SNIAand DMTF.

Locking

A locking model is required to assure data integrity in situations where multipleWBEM Clients are actively managing the same storage network. Locking willallow the execution of multiple methods across multiple objects within a protec-tion boundary. This may require the addition of a Lock Manager to the referencemodel defined in Figure 5–2.

Policy

CIM schema version 2.8 already incorporates a rich (common) policy model, anduse of this model is expected to be a key inclusion in future SMI-S revisions inorder to provide the following capabilities:

• Provide a mechanism for a persistent repository of policies expressed in astandard 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 policyinformation in the persistent repository

• Allow a policy manager to be notified when policies that it processes areadded 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 policyexecution

• Define a mechanism that supports distributed policy management

• Define a mechanism that allows common interchange of policy specificationinformation

• 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 setof 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

Chapter 8 Future Developments and Goals 91


This will require the addition of a Policy Manager to the reference modeldefined 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 placedon WBEM Clients to perform low-level management functions and enhancingscalability and interoperability in a heterogeneous storage network.

DMTFDMTF is already planning for a major new revision of CIM (3.x), and items thathave 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



9

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 thework 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 thedefinitions can support new functionality. It has provided an overview of tech-nology underlying the definitions produced by SMI and the application of thosedefinitions to the management of types of equipment commonly found in a stor-age network. Development tools that are available to speed the adoption of theunderlying technologies in management applications have been described, andfuture developments in those technologies anticipated. In short, the booklet hasprovided a primer for SNIA members to the exciting developments in manage-ment technologies now taking place. The SMI program in SNIA is building towardthe “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 andimmediately bind to it and provide a level of management functionality. SNIAmembers are requested to use the information provided in this text and the ref-erences contained in the appendices to enhance their products and managementapplications and significantly simplify the administrative burden imposed by storage networks, thus literally helping to fulfill the “efficient” part of the SNIAmission.

93


APPENDIX

A

Applicable Standards

The following is a list of industry standard activities that define, or are relevantto, the management technologies described in the text of this document. The listis divided into two sections, one of which deals with completed and/or publishedstandards and the other with known works in progress. Wherever possible, sourcesof 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 beingapproved, new versions are constantly becoming available, and old versions getwithdrawn. Therefore, if a specific version referenced here is not available, it isrecommended that the relevant accredited standards organization be contacted toobtain 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 StandardsChapter 3 A Brief History of Management Protocols

CCITT recommendation X.409

ISO International Standard 8824 Information Processing Systems - Open SystemsInterconnection - Specification of Abstract Syntax Notation One (ASN.1), Inter-national Organization for Standardization, December 1987.

ISO International Standard 8825 Information Processing Systems - Open SystemsInterconnection - Specification of Basic Encoding Rules for Abstract NotationOne (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: TXT�82440 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: TXT�74894 bytes) (Obso-letes RFC1098) (Also STD0015) (Status: STANDARD)

IETF RFC1213 Management Information Base for Network Management ofTCP/IP-Based Internets: MIB-II. K. McCloghrie, M. T. Rose. March 1991. (For-mat: TXT�146080 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: TXT�25386 bytes) (Status: PROPOSED STANDARD)

IETF RFC1901 Introduction to Community-Based SNMPv2. J. Case, K.McCloghrie, M. Rose, S. Waldbusser. January 1996. (Format: TXT�15903 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: TXT�77453 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: TXT�55526 bytes) (Obsoletes RFC1448) (Status: DRAFTSTANDARD)

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: TXT�27465 bytes) (Obsoletes RFC1449) (Status: DRAFTSTANDARD)

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: TXT�34881 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: TXT�21463 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: TXT�139260 bytes)(Obsoletes RFC2271) (Status: DRAFT STANDARD)

IETF RFC2576 Coexistence between Version 1, Version 2, and Version 3 of theInternet-Standard Network Management Framework. R. Frye, D. Levi, S.Routhier, B. Wijnen. March 2000. (Format: TXT�98589 bytes) (ObsoletesRFC1908, RFC2089) (Status: PROPOSED STANDARD)



IETF RFC2578 Structure of Management Information Version 2 (SMIv2). K.McCloghrie, D. Perkins, J. Schoenwaelder. April 1999. (Format: TXT�89712bytes) (Obsoletes RFC1902) (Also STD0058) (Status: STANDARD)

IETF RFC2579 Textual Conventions for SMIv2. K. McCloghrie, D. Perkins, J.Schoenwaelder. April 1999. (Format: TXT�59039 bytes) (Obsoletes RFC1903)(Also STD0058) (Status: STANDARD)

IETF RFC2580 Conformance Statements for SMIv2. K. McCloghrie, D. Perkins,J. Schoenwaelder. April 1999. (Format: TXT�54253 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 FibreChannel Standard. K. Teow. May 2000. (Format: TXT�87860 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: TXT�129475 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: TXT�72842 bytes) (Updates RFC2165) (Status:PROPOSED STANDARD)

IETF RFC2610 DHCP Options for Service Location Protocol. C. Perkins, E. Gutt-man. June 1999. (Format: TXT�10859 bytes) (Status: PROPOSED STANDARD)

IETF RFC2614 An API for Service Location. J. Kempf, E. Guttman. June 1999.(Format: TXT�164002 bytes) (Status: INFORMATIONAL)

IETF RFC2279 UTF-8, a Transformation Format of ISO 10646. F. Yergeau. Janu-ary 1998. (Format: TXT�21634 bytes) (Obsoletes RFC2044) (Status: DRAFTSTANDARD)



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, December2001.

Significant Works in ProgressChapter 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 InformationStorage 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 listedabove.

See: http://www.snia.org/members/ to access pages of the active SNIAworking groups, committees, and forums (membership is required toaccess these pages). SNIA has organizations in Europe and Japan, in addi-tion to North America.

The SNIA Secretariat is located at:

Storage Networking Industry Association50 California Street, Suite 1500San Francisco, CA 94111 USA�1.415.277.5415 (voice)



Many activities related to storage management are held at the following location:

SNIA Technology Center301 Rockrimmon Blvd. SouthColorado 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 listedabove.

See: http://www.dmtf.org/members to access pages of active workinggroups (membership is required to access these pages).

The DMTF Secretariat is located at:

Distributed Management Task Forcec/o Kavi Corporation225 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 numberprefixed with zeroes as necessary to make a four-digit number to gainaccess to the IETF standards listed above.)

See: http://www.ietf.org/html.charters/wg-dir.html to access pages of theactive 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 Secretariatc/o Corporation for National Research Initiatives1895 Preston White Drive, Suite 100Reston, 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 toaccess the latest documents listed above.

See: http://www.opengroup.org/forums/ to access pages of active workinggroups (membership is required to access these pages).

The Open Group Secretariat is located at:

The Open Group44 Montgomery Street, Suite 960San 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 regionalchapters. 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 listedabove.

See: http://www.w3.org/2002/03/new-to-w3c to find out how to participatein W3C.

See: http://www.w3.org/Consortium/Offices/ for information on the W3Coffices 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 ofINCITS standards.

See: http://www.incits.org/tcs.html to access pages of the active INCITSWorking Groups engaged in standards creation. For works in progress, seethe Web sites of INCITS Technical Committee T10 (responsible for stan-dardizing SCSI) at http://www.t10.org, and INCITS Technical CommitteeT11 (responsible for standardizing Fibre Channel) at http://www.t11.org.



The INCITS Secretariat is administered by staff of the Information TechnologyIndustry Council (http://www.itic.org), located at:

Information Technology Industry Council1250 Eye Street NW, Suite 200Washington, DC 20005 USA�1.202.737.8888 (voice)�1.202.638.4922 (fax)



APPENDIX

B

RecommendedBibliography

The following is an annotated bibliography of information that the author of thisdocument, and other members of the SNIA SMI, have found useful in learningabout management technologies and techniques. The bibliography is divided intotwo 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 theircontinued availability. An up-to-date version of this list can be obtained from theSNIA Web site at http://www.snia.org.

PublicationsFor information on CIM and WBEM see:

Bumpus, Winston, et al., Common Information Model, New York: Wiley, August2000 (ISBN 0-471-35342-6).

For information on SLP see:

Kempf, J. and P. St. Pierre, Service Location Protocol for Enterprise Networks, NewYork: 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 andfocus. 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 numberof 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 updatedtutorial 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 foundat 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 athttp://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) canbe found at http://www.omg.org/technology/documents/formal/uml.htm.

Information on XML can be found at http://www.w3c.org/XML/.



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 [email protected], or

visit the SNIA Web site at http://www.snia.org.

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

Storage Network Management - SNIA

Documents

Transcript of Storage Network Management - SNIA