ISO/IEC 24775-1:2021

INTERNATIONAL ISO/IEC
STANDARD 24775-1
Second edition
2021-03
Information technology — Storage
management —
Part 1:
Overview
Reference number
©
ISO/IEC 2021
© ISO/IEC 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2021 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of document should be noted (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. Details
of any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents) or the IEC list of patent
declarations received (see http://patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the World
Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT),
see www.iso.org/iso/foreword.html.
This document was prepared by SNIA (as Storage Management Technical Specification, Part 1 Overview,
Version 1.8.0, Revision 5) and drafted in accordance with its editorial rules. It was adopted, under the
JTC 1 PAS procedure, by Joint Technical Committee ISO/IEC JTC 1, Information technology.
This second edition cancels and replaces the first edition (ISO/IEC 24775-1:2014), which has been
technically revised.
The main changes compared to the previous edition are as follows:
— USAGE text was revised to address code (now included in the front matter for all SNIA specifications)
— All recipes and their references were deleted.
— Instances of subprofile were changed to profile. In the annex, instances of subprofile were changed
to component profile (TSG meeting voice vote).
— Profile versions and related text were updated. (TSG meeting voice vote).
— Indications have been replaced by DMTF Indications, and all affected clauses updated. (TSG meeting
voice vote).
— Instances of Experimental within profiles already labeled as Experimental were removed to avoid
confusion and redundancy. (Editorial change)
— CIM/XML was changed to CIM-XML (Response to ballot comments).
© ISO/IEC 2021 – All rights reserved iii

— Annex: SMI-S Information Model.
— The CIM schema version was changed to 2.51 for V1.8.0 Rev3.
— Substantial editorial clean up to align CIM references with existing XML.
— Team WBEM server used consistently.
— Changes references from the Indication Profile to the Indications Profile in the Storage Management
Technical Specification, Part 3 Common Profiles, which now references the DMTF Indications.
A list of all parts in the ISO/IEC 24775 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
iv © ISO 2021 – All rights reserved

1 INTENDED AUDIENCE
2 This document is intended for use by individuals and companies engaged in developing, deploying, and
3 promoting interoperable multi-vendor SANs through the Storage Networking Industry Association (SNIA)
4 organization.
5 CHANGES TO THE SPECIFICATION
6 Each publication of this specification is uniquely identified by a three-level identifier, comprised of a
7 version number, a release number and an update number. The current identifier for this specification is
8 version 1.8.0. Future publications of this specification are subject to specific constraints on the scope of
9 change that is permissible from one publication to the next and the degree of interoperability and
10 backward compatibility that should be assumed between products designed to different publications of
this standard. The SNIA has defined three levels of change to a specification:
• Major Revision: A major revision of the specification represents a substantial change to the underlying scope
or architecture of the SMI-S API. A major revision results in an increase in the version number of the version
identifier (e.g., from version 1.x.x to version 2.x.x). There is no assurance of interoperability or backward
compatibility between releases with different version numbers.
• Minor Revision: A minor revision of the specification represents a technical change to existing content or an
adjustment to the scope of the SMI-S API. A minor revision results in an increase in the release number of
the specification’s identifier (e.g., from x.1.x to x.2.x). Minor revisions with the same version number preserve
interoperability and backward compatibility.
• Update: An update to the specification is limited to minor corrections or clarifications of existing specification
content. An update will result in an increase in the third component of the release identifier (e.g., from x.x.1 to
x.x.2). Updates with the same version and minor release levels preserve interoperability and backward
compatibility.
TYPOGRAPHICAL CONVENTIONS
Maturity Level
In addition to informative and normative content, this specification includes guidance about the maturity
of emerging material that has completed a rigorous design review but has limited implementation in
commercial products. This material is clearly delineated as described in the following sections. The
typographical convention is intended to provide a sense of the maturity of the affected material, without
29 altering its normative content. By recognizing the relative maturity of different sections of the standard, an
30 implementer should be able to make more informed decisions about the adoption and deployment of
31 different portions of the standard in a commercial product.
This specification has been structured to convey both the formal requirements and assumptions of the
33 SMI-S API and its emerging implementation and deployment lifecycle. Over time, the intent is that all
34 content in the specification will represent a mature and stable design, be verified by extensive
35 implementation experience, assure consistent support for backward compatibility, and rely solely on
36 content material that has reached a similar level of maturity. Unless explicitly labeled with one of the
subordinate maturity levels defined for this specification, content is assumed to satisfy these
37 requirements and is referred to as “Finalized”. Since much of the evolving specification
38 content in any given release will not have matured to that level, this specification defines three
subordinate levels of implementation maturity that identify important aspects of the content’s increasing
maturity and stability. Each subordinate maturity level is defined by its level of implementation
experience, its stability and its reliance on other emerging standards. Each subordinate maturity level is
identified by a unique typographical tagging convention that clearly distinguishes content at one maturity
model from content at another level.
© ISO/IEC 2021 – All rights reserved

46 Experimental Maturity Level
No material is included in this document unless its initial architecture has been completed and reviewed.
Some content included in this document has complete and reviewed design, but lacks implementation
experience and the maturity gained through implementation experience. This content is included in order
to gain wider review and to gain implementation experience. This material is referred to as
“Experimental”. It is presented here as an aid to implementers who are interested in likely future
developments within the SMI specification. The contents of an Experimental profile may change as
implementation experience is gained. There is a high likelihood that the changed content will be included
in an upcoming revision of the specification. Experimental material can advance to a higher maturity level
as soon as implementations are available. Figure 1 is a sample of the typographical convention for
Experimental content.
EXPERIMENTAL
Experimental content appears here.
EXPERIMENTAL
Figure 1 - Experimental Maturity Level Tag
Implemented Maturity Level
Profiles for which initial implementations have been completed are classified as “Implemented”. This
indicates that at least two different vendors have implemented the profile, including at least one provider
implementation. At this maturity level, the underlying architecture and modeling are stable, and changes
in future revisions will be limited to the correction of deficiencies identified through additional
implementation experience. Should the material become obsolete in the future, it must be deprecated in a
minor revision of the specification prior to its removal from subsequent releases. Figure 2 is a sample of
the typographical convention for Implemented content.
IMPLEMENTED
Implemented content appears here.
IMPLEMENTED
Figure 2 - Implemented Maturity Level Tag
Stable Maturity Level
Once content at the Implemented maturity level has garnered additional implementation experience, it
can be tagged at the Stable maturity level. Material at this maturity level has been implemented by three
different vendors, including both a provider and a client. Should material that has reached this maturity
level become obsolete, it may only be deprecated as part of a minor revision to the specification. Material
at this maturity level that has been deprecated may only be removed from the specification as part of a
major revision. A profile that has reached this maturity level is guaranteed to preserve backward
compatibility from one minor specification revision to the next. As a result, Profiles at or above the Stable
© ISO/IEC 2021 – All rights reserved

76 maturity level shall not rely on any content that is Experimental. Figure 3 is a sample of the typographical
77 convention for Implemented content.
STABLE
Stable content appears here.
STABLE
Figure 3 - Stable Maturity Level Tag
78 Finalized Maturity Level
79 Content that has reached the highest maturity level is referred to as “Finalized.” In addition to satisfying
80 the requirements for the Stable maturity level, content at the Finalized maturity level must solely depend
81 upon or refine material that has also reached the Finalized level. If specification content depends upon
82 material that is not under the control of the SNIA, and therefore not subject to its maturity level
83 definitions, then the external content is evaluated by the SNIA to assure that it has achieved a
84 comparable level of completion, stability, and implementation experience. Should material that has
85 reached this maturity level become obsolete, it may only be deprecated as part of a major revision to the
86 specification. A profile that has reached this maturity level is guaranteed to preserve backward
87 compatibility from one minor specification revision to the next. Over time, it is hoped that all specification
content will attain this maturity level. Accordingly, there is no special typographical convention, as there is
with the other, subordinate maturity levels. Unless content in the specification is marked with one of the
typographical conventions defined for the subordinate maturity levels, it should be assumed to have
reached the Finalized maturity level.
Deprecated Material
Non-Experimental material can be deprecated in a subsequent revision of the specification. Sections
identified as “Deprecated” contain material that is obsolete and not recommended for use in new
development efforts. Existing and new implementations may still use this material, but shall move to the
newer approach as soon as possible. The maturity level of the material being deprecated determines how
long it will continue to appear in the specification. Implemented content shall be retained at least until the
next revision of the specialization, while Stable and Finalized material shall be retained until the next
major revision of the specification. Providers shall implement the deprecated elements as long as it
appears in the specification in order to achieve backward compatibility. Clients may rely on deprecated
elements, but are encouraged to use non-deprecated alternatives when possible.
Deprecated sections are documented with a reference to the last published version to include the
deprecated section as normative material and to the section in the current specification with the
replacement. Figure 4 contains a sample of the typographical convention for deprecated content.
DEPRECATED
Content that has been deprecated appears here.
DEPRECATED
Figure 4 - Deprecated Tag
© ISO/IEC 2021 – All rights reserved

© ISO/IEC 2021 – All rights reserved

Contents
List of Figures . 13
List of Tables . 15
Foreword . 17
1 Scope . 19
2 Normative References. 21
2.1 Overview . 21
2.2 Approved references. 21
2.3 References under development . 21
3 Term, Definitions, Symbols, Abbreviations, and Conventions. 23
4 Introduction. 25
4.1 Preamble. 25
4.2 Business Rationale . 25
4.3 Interface Definition . 26
4.4 Technology Trends . 28
4.5 Management Environment . 29
4.6 Architectural Objectives . 30
4.7 Disclaimer . 31
5 Overview. 33
5.1 Base Capabilities . 33
5.2 Object Oriented . 33
6 Functionality Matrix. 37
6.1 Overview . 37
6.2 Multi-Level Model Of Networked Storage Management Functionality . 37
6.3 FCAPS . 38
6.4 Management Functionality Within Each Level Of The Model . 38
6.5 Referring To Levels And Capabilities In The Multi-level Model. 39
6.6 Functionality Descriptions in SMI-S Profiles . 39
6.7 Capabilities of This Version.39
7 Operational Environment. 43
7.1 General . 43
7.2 Using this Specification . 44
7.3 Language Bindings . 45
© ISO/IEC 2021 – All rights reserved

© ISO/IEC 2021 – All rights reserved

LIST OF FIGURES
Figure 1 - Experimental Maturity Level Tag . 8
Figure 2 - Implemented Maturity Level Tag . 8
Figure 3 - Stable Maturity Level Tag. 9
Figure 4 - Deprecated Tag. 9
Figure 5 - Interface Functions . 26
Figure 6 - Large SAN Topology . 29
Figure 7 - Example Client Server Distribution in a SAN. 30
Figure 8 - Object Model/Server Relationship . 34
Figure 9 - Canonical Inheritance. 35
Figure 10 - Operational Environment. 44
© ISO/IEC 2021 – All rights reserved

© ISO/IEC 2021 – All rights reserved

LIST OF TABLES
Table 1 - Functionality Matrix.37
© ISO/IEC 2021 – All rights reserved

© ISO/IEC 2021 – All rights reserved

FOREWORD
The Overview part of the Storage Management Technical Specification contains informative clauses that
provide an overview of how SMI-S works. It is a useful base for understanding the details of the technical
specification. While the normative information of the specification is contained in other parts, this part
provides high-level introductory material on key concepts of the specification.
Parts of this Standard
This standard is subdivided in the following parts:
• Storage Management Technical Specification, Part 1 Overview, 1.8.0 Rev 4
• Storage Management Technical Specification, Part 2 Common Architecture, 1.8.0 Rev 4
• Storage Management Technical Specification, Part 3 Common Profiles, 1.8.0 Rev 4
• Storage Management Technical Specification, Part 4 Block Devices, 1.8.0 Rev 4
• Storage Management Technical Specification, Part 5 Filesystems, 1.8.0 Rev 4
• Storage Management Technical Specification, Part 6 Fabric, 1.8.0 Rev 4
• Storage Management Technical Specification, Part 7 Host Elements, 1.8.0 Rev 4
• Storage Management Technical Specification, Part 8 Media Libraries, 1.8.0 Rev 4
SNIA Web Site
Current SNIA practice is to make updates and other information available through their web site at
http://www.snia.org
SNIA Address
Requests for interpretation, suggestions for improvement and addenda, or defect reports are welcome. They
should be sent via the SNIA Feedback Portal at http://www.snia.org/feedback/ or by mail to the Storage Networking
Industry Association, 4360 ArrowsWest Drive, Colorado Springs, Colorado 80907, U.S.A.
© ISO/IEC 2021 – All rights reserved

© ISO/IEC 2021 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 24775-1:2021(E)
1 1 Scope
2 This Technical Specification defines an interface for the secure, extensible, and interoperable
3 management of a distributed and heterogeneous storage system. This interface uses an object-oriented,
4 XML-based, messaging-based protocol designed to support the specific requirements of managing
5 devices and subsystems in this storage environment. Using this protocol, this Technical Specification
6 describes the information available to a WBEM Client from an SMI-S compliant WBEM Server.
© ISO/IEC 2021 – All rights reserved

© ISO/IEC 2021 – All rights reserved

ISO/IEC 14165-147:2021(E)
1 2 Normative References
2 2.1 Overview
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
6 2.2 Approved references
ISO/IEC 14776-452, SCSI Primary Commands - 3 (SPC-3) [ANSI INCITS.351-2005]
8 2.3 References under development
Storage Management Technical Specification, Part 2 Common Architecture, 1.8.0 Rev 4
Storage Management Technical Specification, Part 3 Common Profiles, 1.8.0 Rev 4
© ISO/IEC 2021 – All rights reserved

© ISO/IEC 2021 – All rights reserved

ISO/IEC 14165-147:2021(E)
1 3 Term, Definitions, Symbols, Abbreviations, and Conventions
2 For the purposes of this document, the terms, definitions, symbols, abbreviations, and conventions given
3 in Storage Management Technical Specification, Part 2 Common Architecture, 1.8.0 Rev 4 apply.
© ISO/IEC 2021 – All rights reserved

© ISO/IEC 2021 – All rights reserved

ISO/IEC 14165-147:2021(E)
1 4 Introduction
2 4.1 Preamble
3 Large Storage Systems and Storage Area Networks (SANs) are emerging as a prominent and
4 independent layer of IT infrastructure in enterprise class and midrange computing environments.
5 Examples of applications and functions driving the emergence of new storage technology include:
6 • Sharing of vast storage resources between multiple systems via networks,
7 • LAN free backup,
8 • Remote, disaster tolerant, on-line mirroring of mission critical data,
9 • Clustering of fault tolerant applications and related systems around a single copy of data.
10 • Archiving requirements for sensitive business information.
11 • Distributed database and file systems.
12 To accelerate the emergence of more functional and sophisticated storage systems in the market, the
13 industry requires a standard management interface that allows different classes of hardware and software
14 products supplied by multiple vendors to reliably and seamlessly interoperate for the purpose of
15 monitoring and controlling resources. The SNIA Storage Management Initiative (SMI) was created to
16 develop this specification (SMI-Specification or SMI-S), the definition of that interface. This standard
17 provides for heterogeneous, functionally rich, reliable, and secure monitoring/control of mission critical
18 global resources in complex and potentially broadly-distributed, multi-vendor storage topologies like
19 SANs. As such, this interface overcomes the deficiencies associated with legacy management systems
20 that deter customer uptake of more advanced storage management systems.
21 4.2 Business Rationale
22 This interface is targeted at creating broad multi-vendor management interoperability and thus increasing
23 customer satisfaction. To that end, this specification defines an “open” and extensible interface that
24 allows subsystems and devices within the global context of a large storage system to be reliably and
25 securely managed by overlying presentation frameworks and management systems in the context of the
26 rapidly evolving multi-vendor market. In specific, SAN integrators (like end-users, VARs, and SSPs) can,
27 via this standardized management interface, more flexibly select between multiple vendors when building
28 the hierarchy of software systems required to manage a large storage system independent of the
29 underlying hardware systems. Additionally, storage integrators can more flexibly select between alternate
30 hardware vendors when constructing storage configurations. Broad adoption of the standards defined
31 and extended in this specification will provide increased customer satisfaction and will:
32 • More rapidly expand the acceptance of new storage management technology like SANs and iSCSI;
33 • Accelerate customer acquisition of new storage management technology;
34 • Expand the total market.
35 Additionally, a single common management interface allows SAN vendors and integrators to decrease the
36 time required to bring new more functional technology, products, and solutions to market.
© ISO/IEC 2021 – All rights reserved

37 4.3 Interface Definition
38 This management interface allows storage management systems to reliably identify, classify, monitor, and
39 control physical and logical resources in a storage system. The fundamental relationship of this interface
40 to storage management software, presentation frameworks, user applications, SAN physical entities (i.e.,
41 devices), SAN discovery systems, and SAN logical entities is illustrated in Figure 7: "Interface
Functions".
Command Interface Graphical Interface
Application Framework
Media Data Migration
Other
Management (HSM)
Volume
Performance Capacity Planning Database System
Management
Resource
File System Backup System
Allocation
SMI-S Interface
Objects
LU LU Tape Virtual
LU Zone Host Port Other
Clone Snapshot Volume
Removable
RAIDset Switch Array Router Fabric
Media Set
Media Disk Mgmt
HBA Extender Enclosure Card
Robot Drive Appliance
Implementation
Figure 7 - Interface Functions
43 Figure 7: "Interface Functions" illustrates that functions of the interface can be distributed across
44 multiple devices (i.e., Switches or Array Controllers) and/or software systems (i.e., Discovery Systems).
45 While the functionality of the interface is distributed within or across a storage environment, to insure that
46 monitoring and control operations by clients are consistent and reliable, the state of a given resource is
not certain to be valid if it is simultaneously available to clients from multiple unsynchronized sources.
48 EXAMPLE: A request by an SRM application and a backup engine for the bandwidth available on a
given Fibre Channel path should be coordinated by a single monitoring entity to insure
information consistency. If the SRM application and Backup engine obtain different available
bandwidth information for a given Fibre Channel path from multiple unsynchronized sources
they could function in conflict and degrade the efficiency of the environment.
53 Addressing this concern is the responsibility of parties configuring Storage and Network management
clients that rely on the primitives defined in the specification.
© ISO/IEC 2021 – All rights reserved

ISO/IEC 14165-147:2021(E)
NOTE Within this architecture (as depicted by Figure 7) entities like an appliance-based volume manager may potentially act as
both a client and a server to the interface.
EXAMPLE: A Host-based volume manager wants to construct a large storage pool from multiple SAN
appliance based volumes, as well as volumes/LUNs originating from array controllers. In this
case, the host based volume manager needs to inspect the characteristics of the volumes on
both the SAN appliance and array controller prior to allocation. Additionally, the SAN
appliance (which runs a volume manager) needs to inspect the properties of storage devices
when building its volumes. As such, the SAN appliance in this case is both a client and server
in the management environment, depending on the action being performed.
Figure 7: "Interface Functions" includes a number of strategic functional requirements for the interface.
These capabilities will be introduced to the interface implementation over time, and may not be present in
this version of the interface. The functionalities required to fully satisfy the needs of clients using a
storage management interface include:
a) Clients need to be able to obtain sufficient information to discern the topology of the SAN or
complex storage system.
b) Clients need to be able to reliably identify resources that have experienced an error/fault condi-
tion that has resulted in degraded/disabled operation.
c) Clients need to be able to construct a zone of allocation around a select group of host and stor-
age resources.
d) Clients need to be able to identify nonvolatile storage resources available to a storage manage-
ment system, to allow them to construct a storage pool of a consistent level of performance and
availability.
e) Clients need to be able to identify third-party copy engines (and associated media libraries/
robots) available to a cooperating backup engine, allowing it to allocate an engine/library/robot
to a given backup task.
f) Clients need to be able to dynamically allocate non-volatile storage resources.
g) Each volume to be utilized is subject to strict availability and performance requirements. As a
result, the file system needs to inspect the properties of each volume prior to allocation.
h) Clients need to be able to access sufficient topology and component information to allow a Stor-
age Resource Management (SRM) application like a performance monitor to examine topology
and line utilization, such that performance bottlenecks can be exposed and capacity planning
performed.
i) Clients need to be able to employ appropriate data reporting and tracking to allow capacity plan-
ning system to identify each storage pool in the SAN and then interact with the manager of each
pool to assess utilization statistics.
j) Clients need to be provided with adequate controls for a privileged, user-written application to
restrict the use of a volume to a specific host, set of hosts, or set of controller communications
ports.
k) Clients need to be assured of timely propagation of data concerning the health and performance
of the devices and subsystems in the SAN to fault isolation and analysis systems.
Example non-goals for this interface include:
a) The ability to select a logical communications port over which to send/receive data;
b) The ability to read or write data to a volume;
© ISO/IEC 2021 – All rights reserved

99 c) The ability to identify and recover from data communications errors and failures;
d) The ability to log a new communications device into a network.
4.4 Technology Trends
To be broadly embraced and long lived this management interface should respect and leverage key
technology trends evolving within the industry. These include:
a) Improved Connectivity: Whether available In-band (i.e., over Fibre Channel/iSCSI) or available out-of-
band (i.e., over a LAN/MAN/WAN), or available over a mix of both, virtually all devices in a storage man-
agement environment have (or soon will have), access to a common communications transport suitable
for carrying management information content (e.g., TCP/IP), that is used to transmit a standardized
encoding (e.g., a WBEM Protocol) of recognized semantics (e.g., CIM).
b) Increased Device Manageability: Through a common, general-purpose network transport, provide
the option to provide proxy services to provide access to (e.g., general purpose computer sys-
tem) devices via this standardized management interface.
EXAMPLE: A legacy array controller is incapable of running the software necessary to implement a
management server for this interface and uses a proxy server on a SAN appliance to
communicate within the management environment.
EXAMPLE: An HBA is incapable of running the software necessary to implement a management server
for this interface and uses a proxy server on its host system to communicate within the
management environment.
c) XML Standardization: XML is providing the ability to create management protocols with an exten-
sible, platform independent, human readable, content describable communication language.
This streamlines the task of developing infrastructure to support his interface and debug sys-
tems around the interface.
d) Object Independent Protocols: These protocols provide appropriate abstraction – separating the
definition of the object model from the semantics/syntax of the protocol. Additionally, the trans-
port-independent, content-description (i.e., markup) nature of XML allows it to be utilized by
both web-enabled application and appliances.
e) Increased SAN Complexity: SANs are being configured with diverse classes of components and
widely distributed topologies. Management clients and servers in the environment need to antic-
ipate being widely distributed on systems, appliances and devices throughout large SAN topolo-
gies, while maintaining real-time distributed state for logical entities. Figure 8: "Large SAN
Topology" provides an example of a single SAN built from multiple classes of components span-
ning three physical locations (i.e., Sites A, B and C).
© ISO/IEC 2021 – All rights reserved

Snaps and Clones
ISO/IEC 14165-147:2021(E)
Site - A
Site - B
Host B1
Host A1
Host A2
Library
Router B1
Switch B1
Host An
Site - C
Switch A1
Switch A2
Host C1
Bridge A1
Host C2
Network
Bridge A2
Appliance A1
Switch C1
Appliance A2
Switch C2
Bridge C1
Bridge C2
Array A1
Array An
Appliance C1
Appliance C2
Vol A1
Vol An
Array C1
Array An
Vol C1
Vol Cn
Figure 8 - Large SAN Topology
130 4.5 Management Environment
131 Clients and Servers of this interface can be widely distributed on systems, appliances, and devices
132 across a network that includes one or more large SAN topologies.
133 The configuration in Figure 9: "Example Client Server Distribution in a SAN" provides an example client/
134 server distribution using in-band TCP/IP communications, out of band TCP/IP communications, or
135 employing proxy services to bridge legacy and/or proprietary communication interfaces. The device “Old
136 Array Controller” is incapable of appropriate communication with clients and servers in the management
137 environment to provide management access (i.e., a WBEM Server). Access to the communications
138 transport that clients and servers share for communication is achieved via a proxy service on the host
139 computer in the upper right hand corner of Figure 9: "Example Client Server Distribution in a SAN". All
140 other clients and servers communicate via direct access to a common communications transport.
© ISO/IEC 2021 – All rights reserved

Host
Host Host
Database Mgmt
WBEM Service
WBEM Service
WBEM Service
Volume Manager
FileSystem  FileSystem
FileSystem  Legacy Array
Provider
Provider
WBEM Client
Provider Provider
Host Provider
Host Provider
Host Provider Router Provider
Management
HBA Provider
HBA Provider
HBA Provider Switch Provider
Appliance
Discovery and
Directory Service
WBEM Service
Storage Area Network
Host Provider
General Purpose  HBA Provider
LAN
Switch
Proprietary
Management
Management
Service Appliance
SRM
Legacy Array
Data Migration
Proprietary
Mgmt
Management
WBEM Client
Service
WBEM Service
Array Bridge to ATM
Host Provider
Router
HBA Provider
Proprietary  WBEM Service WBEM Service
Media Library Management
Array Provider Bridge Provider
Service
WBEM Service Storage Area Network
Media Library
Provider
Figure 9 - Example Client Server Distribution in a SAN
141 4.6 Architectural Objectives
142 The following reflect architectural objectives of the interface. Some of these capabilities are not present
143 in the initial release of the interface, but are inherent in its architecture and intended extensibility. They
144 are intended to provide guidance concerning the present and future direction of development of the
145 Storage Management Technical Specification.
146 a) Consistency: State within a managed object and between objects remains consistent independent of the
147 number of clients simultaneously exerting control, the distribution of objects in the environment, or the
148 management action being performed.
149 b) Isolation: A client that needs to execute an atomic set of management actions against one or
150 more managed objects is able to do so in isolation of other clients, who are simultaneously exe-
151 cuting management actions against those same objects.
152 c) Durability: Consistency, and isolation are preserved independent of the failure of any entity or
153 communications path in the management environment.
154 d) Consistent Name Space: Managed objects in a single management domain adhere to a consis-
155 tent naming convention independent of state or reliability of any object, device, or subsystem in
156 the SAN.
© ISO/IEC 2021 – All rights reserved

ISO/IEC 14165-147:2021(E)
157 e) Distributed Security: Monitoring and control operations are secure. The architecture supports:
158 1) Client authentication
159 2) Privacy (encryption) of the content of the messages in this protocol
160 3) Client authorization
161 f) Physical Interconnect Independence: The interface will function independent of any particular
162 physical interconnect between components, any supplier, or any topology.
163 g) Multi-vendor Interoperability: Clients and servers should use a common communication trans-
164 port and message/transfer syntax to promote seamless plug compatibility between heteroge-
165 neous multi-vendor components that implement the interface.
166 h) Scalability: The size, physical distribution, or heterogeneity of the storage system does not
167 degrade the quality or function of the management interface.
168 i) Vendor Unique Extension: The interface allows vendors to implement proprietary functionality
169 above and beyond the definitions here-in to distinguish their products and services in the market
170 independent of the release of a new version of the interface.
171 j) Volatility of State: This interface does not assume that objects are preserved in non-volatile
172 repositories. Clients and servers may preserve object state across failures, but object preserva-
173 tion is not mandatory.
174 k) Replication: This interface provides no support for the automatic replication of object state within
175 the management environment.
176 l) Functional Layering Independence: The design of this interface is independent of any functional
177 layering a vendor chooses to employ in constructing the storage management systems (hard-
178 ware and software) necessary to manage a storage environment.
179 m) Asynchronous or Synchronous execution: Management actions may execute either asynchro-
180 nously or synchronously.
181 n) Events: This interface provides for the reliable asynchronous delivery of events to one or more
182 registered clients.
183 o) Cancelable Management Actions: Long running synchronous or asynchronous directives need to
184 be capable of being cancelled by the client. Cancellation needs to result in the termination of
185 work by the server and resource consumed being released.
186 p) Durable Reference: Object classes that persist across power cycles and need to be monitored
187 and controlled independent of SAN reconfiguration (i.e., logical volumes) need be identified via
188 “Durable Names” to insure consistent reference by clients.
189 q) Dynamic installation and reconfiguration: New clients and servers need to be capable of being
190 added to or removed from an SMI-S management environment without disrupting the operation
191 of other clients or servers. In most cases, clients should be capable of dynamically managing
192 new servers that have been added to an SMI-S environment.
193 r) Automatic discovery of new servers: When new management servers are added to the manage-
194 ment system they should automatically become available to management clients without the
195 need for manual co
...