ISO/IEC 5965:2021

Information technology — Swordfish Scalable Storage Management API Specification

This document defines the Swordfish Scalable Storage Management API. Swordfish extends the Redfish Scalable Platforms Management API Specification, as defined by ISO 30115. It defines a comprehensive, RESTful API for storage management that addresses block storage, file systems, object storage, and storage network infrastructure. It is centered around common operational and business concerns of storage management, including: Configuration and provisioning Monitoring Event and log management Performance assessment Diagnostics Fault detection and remediation Security Accounting and resource consumption Swordfish’s storage model is built around well-defined classes of service, which provide a means to map high-level business goals and objectives to specific, storage-based actions and requirements, in a clear and consistent way that can be applied uniformly across a broad spectrum of storage configurations and storage types (e.g., block storage, file systems, object stores). Common storage management functionality covered by class of service includes snapshots, replication, mapping and masking, and provisioning. The Redfish specification provides the protocols and a core set of data models and behaviors for the management of systems. It defines the elements and behaviors that are mandatory for all Redfish implementations. Additionally it defines additional elements and behaviors that can be chosen by system vendors or manufacturers. The specifications also defines points at which OEM (system vendor) extensions can be provided by a given implementation. The specifications specifies normative requirements for Redfish Services and associated materials, such as Redfish Schema files. The Redfish specifications does not set requirements for Redfish clients, but willindicate what a Redfish client should do in order to access and utilize a Redfish Service successfully and effectively. The Swordfish specification defines additional data models and behaviors for the management of storage systems and storage infrastructure. A Swordfish implementation shall conform to all requirements specified in the Redfish specifications. Swordfish is suitable for a wide range of storage, from small-scale object drives, integrated RAID cards or RBODs providing storage services, to external disk arrays or file servers, to infrastructure providing storage services for converged, hyperscale and large scale cloud environments.

Titre manque

General Information

• Status: Withdrawn
• Publication Date: 23-Aug-2021
• ICS: 35.020 - Information technology (IT) in general
• Technical Committee: ISO/IEC JTC 1 - Information technology
• Drafting Committee: ISO/IEC JTC 1 - Information technology
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 11-May-2023
• Completion Date: 12-Feb-2026

Relations

• Revised: ISO/IEC 5965:2023 - Information technology — Swordfish Scalable Storage Management API Specification
• Effective Date: 03-Sep-2022

Standards Content (Sample)

INTERNATIONAL ISO/IEC
STANDARD 5965
First edition
2021-08
Information technology — Swordfish
Scalable Storage Management API
Specification
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: [phone]
Email: [e-mail]
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 or
www.iec.ch/members_experts/refdocs).
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 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. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by SNIA (as Swordfish Scalable Storage Management API Specification,
Version 1.1.0c) 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.
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 and www.iec.ch/national-
committees.
© ISO/IEC 2021 – All rights reserved iii

Swordfish SSM API Specification
Table of Contents
About SNIA
Acknowledgements
Table of Contents
1 Abstract 11
2 Scope 12
2.1 Audience Assumptions 13
3 Normative References
3.1 Overview 14
3.2 Approved references 14
3.3 References under development 16
3.4 Other references 16
4 Terms and Definitions 17
4.1 Overview 17
4.2 Swordfish-specific Terms 17
4.3 Reference to Redfish terms 18
4.4 Keywords (normative language terms) 19
5 Swordfish Overview 20
5.1 Introduction 20
5.2 Relation to Redfish 20
5.3 Storage System Models 21
5.4 The ServiceRoot and ServiceContainer entities 24
5.5 Swordfish model overview 25
6 Features and Profiles 28
6.1 Overview 28
6.2 Requirement for SupportedFeatures 28
6.3 EnergyStar for Storage Feature 28
6.4 Class of Service Feature 29
7 Schema Considerations 37
7.1 Schema Introduction 37
7.2 Default values and NULLABLE attributes 37
7.3 Common schema annotations 38
7.4 Property implementation requirements 39
7.5 Schema repository 40
7.6 Referencing other schemas 40
8 Implementation requirements 41
8.1 Security 41
8.2 General constraints 41
8.3 Discovering Swordfish resources 42
8.4 ClassOfService requirements 43
8.5 StorageSystems requirements 43
8.6 Entity Sets 43
8.7 Addressing entities within a collection 43
8.8 Addressing members of a ResourceCollection 44
8.9 HTTP status codes 44
9 Swordfish type definitions 48
9.1 Overview 48
9.2 Common properties 48
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 9 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
9.3 Complex Types 55
9.4 CapacitySource 1.1.2 56
9.5 ClassOfServiceCollection 63
9.6 ConsistencyGroup 1.0.1 64
9.7 ConsistencyGroupCollection 76
9.8 DataProtectionLoSCapabilities 1.1.3 78
9.9 DataSecurityLoSCapabilities 1.1.3 83
9.10 DataStorageLoSCapabilities 1.2.1 91
9.11 DriveCollection 95
9.12 EndpointGroup 1.2.0 97
9.13 EndpointGroupCollection 101
9.14 FeaturesRegistry 1.0.0 102
9.15 FileShare 1.1.3 105
9.16 FileShareCollection 111
9.17 FileSystem 1.2.2 112
9.18 FileSystemCollection 120
9.19 HostedStorageServices 121
9.20 IOConnectivityLoSCapabilities 1.1.3 122
9.21 IOPerformanceLoSCapabilities 1.1.3 126
9.22 LineOfService 1.0.0 130
9.23 LineOfServiceCollection 132
9.24 SpareResourceSet 1.0.1 133
9.25 StorageGroup 1.2.1 136
9.26 StorageGroupCollection 145
9.27 StoragePool 1.3.1 147
9.28 StoragePoolCollection 156
9.29 StorageReplicaInfo 1.3.0 157
9.30 StorageService 1.4.0 159
9.31 StorageServiceCollection 168
9.32 StorageSystemCollection 169
9.33 Volume 1.4.1 170
9.34 VolumeCollection 202
Annex A: Bibliography 205
A.1 Overview 205
A.2 Informational references 205
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 10 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
1 Abstract
The Swordfish Scalable Storage Management API (“Swordfish”) defines a RESTful interface and a standardized data
model to provide a scalable, customer-centric interface for managing storage and related data services. It extends the
Redfish Scalable Platforms Management API Specification (DSP0266) from the DMTF.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 11 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
2 Scope
Swordfish extends the Redfish Scalable Platforms Management API Specification, as defined by ISO 30115 It defines
a comprehensive, RESTful API for storage management that addresses block storage, file systems, object storage, and
storage network infrastructure. It is centered around common operational and business concerns of storage
management, including:
Configuration and provisioning
Monitoring
Event and log management
Performance assessment
Diagnostics
Fault detection and remediation
Security
Accounting and resource consumption
Swordfish’s storage model is built around well-defined classes of service, which provide a means to map high-level
business goals and objectives to specific, storage-based actions and requirements, in a clear and consistent way that
can be applied uniformly across a broad spectrum of storage configurations and storage types (e.g., block storage, file
systems, object stores). Common storage management functionality covered by class of service includes snapshots,
replication, mapping and masking, and provisioning.
The Redfish specification provides the protocols and a core set of data models and behaviors for the management of
systems. It defines the elements and behaviors that are mandatory for all Redfish implementations. Additionally it
defines additional elements and behaviors that can be chosen by system vendors or manufacturers. The
specifications also defines points at which OEM (system vendor) extensions can be provided by a given
implementation. The specifications specifies normative requirements for Redfish Services and associated materials,
such as Redfish Schema files. The Redfish specifications does not set requirements for Redfish clients, but will
indicate what a Redfish client should do in order to access and utilize a Redfish Service successfully and effectively.
The Swordfish specification defines additional data models and behaviors for the management of storage systems
and storage infrastructure. A Swordfish implementation shall conform to all requirements specified in the Redfish
specifications.
Swordfish is suitable for a wide range of storage, from small-scale object drives, integrated RAID cards or RBODs
providing storage services, to external disk arrays or file servers, to infrastructure providing storage services for
converged, hyperscale and large scale cloud environments.
This document defines the Swordfish Scalable Storage Management API.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 12 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
2.1 Audience Assumptions
As Swordfish is designed as an extension of the Redfish specification, this document is written with the presumption
that the reader has a detailed understanding of ISO 30115 and any updates or clarifications introduced by the DMTF.
This document cannot be fully understood without that context.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 13 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
3 Normative References
3.1 Overview
The documents listed in Table 3 is 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.
3.2 Approved references
Table 3: Approved normative references
Tag Title (Version) Author URL
ISO- Data elements and ISO/IEC http://www.iso.org/iso/home/store/catalogue_ics/
8601 interchange formats catalogue_detail_ics.htm?csnumber=70907
– Information
interchange –
Representation of
dates and times –
Part 1: Basic rules
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 14 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
Table 3: Approved normative references, cont.
Tag Title (Version) Author URL
ISO- ISO/IEC ISO/IEC http://isotc.iso.org/livelink/livelink/
Direct Directives, Part fetch/2000/2122/4230450/4230456/
2 ISO_IEC_Directives Part_2
Principles and Principles_and_rules_for_the
rules for the structure_and_drafting_of_ISO_and_IEC
structure and documents
drafting of ISO -2016%287th_edition%29-_PDF.pdf?
and IEC nodeid=17667902&vernum=-2
documents
(Seventh
Edition, 2016)
OData Open Data OASIS https://www.oasis-
Protocol (v. 4.0) open.org/standards#odatav4.0
RFC3986 Uniform The Internet http://www.rfc-base.org/txt/rfc-3986.txt
Resource Society
Identifier (URI):
Generic Syntax
(2005)
CSDL Common OASIS http://docs.oasis-open.org/odata/
Schema odata/v4.0/odata-v4.0-part3-csdl.html
Definition
Language (4.0)
ITIL ITIL Glossary ITIL https://www.axelos.com/Corporate/media/
(2011) Files/Glossaries/
ITIL_2011_Glossary_GB-v1-0.pdf
Units The Unified Regenstrief http://unitsofmeasure.org/trac
Code for Units Institute,
of Measure Inc. and the
(v2.0.1) UCUM
Organization
SPC-4 SCSI Primary T10 http://www.techstreet.com/cgi-
Commands - 4 bin/joint.cgi/incits
(SPC-4) INCITS
513-2015
Features Swordfish SNIA https://redfish.dmtf.org/registries/swordfish/v1/
Features SwordfishFeatureRegistry.1.0.1.json
Registry, version
1.0.1
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 15 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
Table 3: Approved normative references, cont.
Tag Title (Version) Author URL
Messages Swordfish SNIA https://redfish.dmtf.org/registries/swordfish/v1/
Message Swordfish.1.0.2.json
Registry, version
1.0.2
EnergyStar ENERGY STAR EPA https://www.energystar.gov/sites/default/files/ENERGY
Data Center STAR Data Center Storage Final Version 1.1 Specification
Storage Version Rev. April 2019.pdf
1.1 Updated
Program
Requirements –
April 1, 2019
ISO-20648 Information ISO/IEC https://www.iso.org/standard/68622.html
technology —
TLS
specification for
storage systemsi
ISO-30115 ISO/IEC ISO/IEC https://www.iso.org/standard/53235.html
30115(en)
Information
technology —
Redfish scalable
platforms
management
API specification
3.3 References under development
None defined in this document.
3.4 Other references
None defined in this document.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 16 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
4 Terms and Definitions
4.1 Overview
In this document, some terms have a specific meaning beyond the normal English meaning. Those terms are defined
in this clause. New terms, frequently used Redfish terms.
4.2 Swordfish-specific Terms
4.2.1 Definitions
Table 4 summarizes the terms are used in this document.
Table 4: Swordfish terms
Term Definition
Entity An instance of a schema element.
Model A set of entities and the relationships between them that define the semantics,
behavior and state of that set.
OData A REST-based service that allows resources, identified using Uniform Resource
service Locators (URLs) and defined in a model, to be published and edited by Web clients
using simple HTTP messages.
Resource A central element in a model, which represents a physical construct or a logical
service, and is further defined by other model entities.
Schema A formal language representation of a model that conforms to a metamodel.
Service A particular resource that is directly accessed via an OData service entry point. This
Document resource serves as a starting point for locating and accessing the other resources and
associated metadata that together make up an instance of a Swordfish service.
Swordfish An extension to the Redfish Service that conforms to the Swordfish specification, and
service provides REST-ful storage management functionality.
4.2.2 Symbols and abbreviated terms
None in this document.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 17 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
4.3 Reference to Redfish terms
Many terms in this document were originally defined in the Redfish Specification. Some of the more common terms
and definitions are reproduced in Table 5, as an aid to the reader.
Table 5: Redfish terms
Term Definition (as of 16 August 2019)
OData The Open Data Protocol, as defined in OData-Protocol.
OData Resource that provides information about the service root for generic OData clients.
Service
Document
Redfish Defines Redfish Resources according to OData schema representation. You can
Schema directly translate a Redfish Schema to a JSON Schema representation.
Redfish Implementation of the protocols, resources, and functions that deliver the interface
service that this specification defines and its associated behaviors for one or more managed
systems.
Request A message from a client to a service.
Service Resource that serves as the starting point for locating and accessing the other
Root resources and associated metadata that together make up an instance of a Redfish
Service.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 18 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
4.4 Keywords (normative language terms)
This document conforms to ISO/IEC Directives, Part 2 for keyword usage. The most common terms and their
intended meanings are summarized in Table 6.
Table 6: Normative language terms
Term(s) Meaning
shall / Used to identify objectively verifiable criteria to be fulfilled and from which no
shall not deviation is permitted if compliance with the document is to be claimed
should / Used to identify a suggested possible choice or course of action deemed to be
should particularly suitable without necessarily mentioning or excluding others
not
may / Used to convey consent or liberty (or opportunity) to do something
need not
can / Expected or conceivable material, physical or causal outcome
cannot
must Identifies a constraint or obligation on the user of the document, typically due to one
or more legal requirements or laws of nature, that is not stated as a provision of the
standard
NB: “must” is not an alternative for “shall”, and should only be used for constraints
that arise from outside this standard
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 19 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
5 Swordfish Overview
5.1 Introduction
The Swordfish Scalable Storage Management API (“Swordfish”) defines a RESTful interface and a standardized data
model to provide a scalable, customer-centric interface for managing storage and related data services. It extends the
Redfish Scalable Platforms Management API Specification (DSP0266) from the DMTF.
5.2 Relation to Redfish
Figure 1: Extension Overview
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 20 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
The Swordfish service interface extends the Redfish service interface, as illustrated in Figure 1. As such, a Swordfish
service is a Redfish service and includes all required elements of the Redfish model.
Storage systems managed by the Swordfish service are located in the ServiceRoot via the StorageSystems
resource collection. They are modeled using Redfish ComputerSystems. The physical infrastructure is modeled
using Redfish Chassis.
As modeling for storage systems may cover both logical and physical constructs, Swordfish management clients that
are focused on logical storage management use cases may choose to manage functionality entirely by way of logical
resources.
Each Swordfish service is accessed via well known URLs on the system supporting the Swordfish Service. Since
Swordfish is an extension of Redfish, these URLs are the same as for accessing the Redfish defined aspects of the
service.
5.3 Storage System Models
Swordfish has been designed to support a broad range of configurations, requirements, size and complexity, as well
as logical and physical architectures. As a result, there are two primary methods of modelling the storage system for
a Swordfish implementation:
1. Swordfish Integrated Configuration
The SIC uses the same ComputerSystem model instantiation as the server where the physical element resides.
The logical storage controller is modeled using the Redfish Storage and StorageController resources. The
Storage resource is located in the Redfish hierarchy contained by ComputerSystems, typically running as
ApplicationServers. The physical infrastructure is modeled using Redfish Chassis. Managed resources are
connected to the Storage resource, including Volumes the StoragePools. These relationships are illustrated in
Figure 2.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 21 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
Figure 2: Integrated Configuration Overview
This configuration works well when the storage system can be modeled by simply instantiating a new Storage object
within an existing computer system. An example of a Storage System for an integrated configuration is shown in
Figure 3.
Figure 3: Integrated Configuration Example
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 22 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
2. Swordfish Standalone Configuration
The SSC uses separate ComputerSystem/StorageSystem model instantiation(s) to represent/model the logical
controller(s) for the system.
The logical storage controller is modeled using Redfish a ComputerSystems with properties set as a
StorageSystem. The physical infrastructure is modeled using Redfish Chassis. Managed resources are then
connected to the Storage resource, including Volumes, StoragePools, ConsistencyGroups, and
StorageGroups. These relationships are illustrated in Figure 4.
Figure 4: Standalone Configuration Overview
This configuration works well when the storage system needs a new ComputerSystem instance to model the logical
controller. An example of a Storage System for a hosted service configuration is shown in Figure 5.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 23 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
Figure 5: Standalone Configuration Example
5.4 The ServiceRoot and ServiceContainer entities
5.4.1 Overview
A GET of /redfish/v1 will return the ServiceRoot entity. A GET of /redfish/v1/odata will return the
ServiceContainer instances that represents the OData service document. Each of these instances provides links to
the remainder of the system.
The following are the elements utilized for Swordfish management.
Systems: A reference to a Systems resource collection;
Chassis: A reference to a Chassis resource collection;
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 24 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
StorageSystems: A reference to a StorageSystems resource collection.
5.4.2 The Systems resource collection
A resource collection that references a set of ComputerSystem resources that each represents a general purpose
application server. Each ComputerSystem resource will have an entry with the value of “ApplicationServer” in its
HostingRoles property. A particular ComputerSystem resource can be in both the StorageSystems collection and
the Systems collection.
5.4.3 The Chassis resource collection
A resource collection that references a set of Chassis resources. Each Chassis resource represents physical
containers, (i.e. sheet-metal confined spaces and logical zones like racks, enclosures, chassis and all other
containers). Subsystems (like sensors), which operate outside of a system’s data plane (meaning the resources are not
accessible to software running on the system) are linked either directly or indirectly through this resource.
5.4.4 The StorageSystems resource collection
A reference to a ComputerSystemCollection with members of type ComputerSystem that support storage
services. These ComputerSystem resources represent systems that support Swordfish storage management services.
They will have an entry with the value of “StorageServer” in their HostingRoles property.A resource collection that
references a set of ComputerSystem resources that each represents a storage server. Each ComputerSystem
resource will have an entry with the value of “StorageServer” in its HostingRoles property. A particular
ComputerSystem resource can be a member of both the StorageSystems resource collection and the Systems
resource collection.
5.5 Swordfish model overview
5.5.1 The Storage resource
The storage system exposes logical storage, associated resources and related functionality. Storage service resources
can be found in the service root or service container via the StorageSystem resource collection, and are attached to
the Storage object within the StorageSystem (ComputerSystem).
The following are the principal properties of Storage that point to resources managed or defined by the storage
system:
Drives: A reference to a collection that collects Drive resources used for storage.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 25 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
Enclosures: A reference to a resource collection that collects Chassis resources that contain storage related
resources.
Endpoints: A reference to a resource collection that collects Endpoint resources used to access storage.
EndpointGroups: A reference to a resource collection that collects EndpointGroups resources.
FileSystems: A reference to a resource collection that collects FileSystem resources.
StorageGroups: A reference to a resource collection that collects StorageGroup resources.
ConsistencyGroups: A reference to a resource collection that collects ConsistencyGroup resources.
StoragePools: A reference to a resource collection that collects StorageGroup resources.
Volumes: A reference to a resource collection that collects Volume resources.
5.5.1.1 The Endpoint resource
Endpoints represent one end of a protocol specific connection that supports sending or receiving messages according
to a particular protocol.
5.5.1.2 The Endpoint Collection resource
The Endpoint Group is resource collection that references a set of Endpoint resources.
5.5.1.3 The ConsistencyGroup resource
ConsistencyGroups represent a set of volumes that are managed consistently and collectively as a group, to allow
system and application level activities to be performed on a set of data that spans volumes. This activities include
device-level replication activities as well as system level functions, such as reset.
When ConsistencyGroups are implemented, they are attached to a Storage resource and its internal Volumes
collection is constructed from a subset of the Volumes collection of the Storage resource.
5.5.1.4 The ConsistencyGroup Collection resource
The ConsistencyGroupCollection is a resource collection that references a set of ConsistencyGroup
resources.
5.5.1.5 The StorageGroup resource
StorageGroups represent a set of volumes that are managed as a group in order to facilitate mapping and masking, in
which the volumes of a storage group are collectively exposed or hidden to a set of clients.
The set of volumes is specified by the Mapped Volumes attribute. MappedVolumes is a resource collection of the
Mapped Volume construct (a tuple of a pointer to a volume and a corresponding Logical Unit Number for that
volume).
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 26 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
The set of client endpoints to which the volumes can be exposed is specified by the
ClientEndpointGroupsattribute. The ClientEndpointGroup resource specifies a collection of EndpointGroup
resources.
The set of server endpoints to which the volumes can be exposed is specified by the
ServerEndpointGroupsattribute. The ServerEndpointGroup resource specifies a collection of EndpointGroup
resources.
5.5.1.6 The StoragePool resource
The StoragePool resource represents unassigned storage capacity that can be used to produce storage volumes or
other storage pools.
The following are the principal properties of StoragePool that are used to identify resources provisioned or
supported by the storage pool:
AllocatedVolumes: A reference to a resource collection that collects Volume resources that have been
provisioned from the storage pool.
AllocatedPools: A reference to a resource collection that collects StoragePool resources that have been
provisioned from the storage pool.
5.5.1.7 The Volume resource
Volume resource represents a block-addressable container of storage, sometimes referred to as a “Logical Unit”,
“LU”, “LUN”, or “StorageVolume” in the storage industry.
5.5.1.8 The FileSystem resource
This FileSystem resource represents a file system. Each FileSystem may contain a collection of FileShares that
can be presented to hosts.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 27 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
6 Features and Profiles
6.1 Overview
Features are high-level descriptions of functionality which an implementation uses to advertise what functionality it
currently supports, and for some features, is capable of supporting.
The detailed definitions required to describe to implementers how to implement a feature are written in profile
definition files. A feature is generally represented in one (but may be more) profile definition file, or profile.
Profiles are detailed descriptions that describe down to the individual property level what functionality is required in
order to advertise features. Different profile definitions can exist for the same feature type but for various types of
storage configurations: Swordfish.Block.Provisioning, Swordfish.File.Provisioning
The Swordfish Features Registry shall be used to advertise what standard and Oem Features an implementation
supports.
6.2 Requirement for SupportedFeatures
SupportedFeatures entries in the Features registry represent the client’s primary initial runtime view of the
capabilities of a Swordfish implementation. Without properly formed entries in this registry, there is no visibility to
an implementation’s functionality.
Swordfish implementations shall implement the Features registry and advertise at least the
SNIA.Swordfish.Discovery supported feature in order to be considered a Swordfish implementation.
Features define coarse-grained sets of functionality. In order to advertise a feature (using the SupportedFeature
mechanism in the SupportedFeatures Registry), the implementation must support the complete set of functionality
as defined in the corresponding profile.
The Swordfish Features Registry publishes the official list of supported SNIA Features, and provides a high-level
description of their functionality. Many of those features are self-explanatory (e.g., local replication, remote
replication), but there are some features where additional context is appropriate:
Class of Service
Energy Star for Storage
6.3 EnergyStar for Storage Feature
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 28 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
The EnergyStar for Storage Feature and profile has been created to formalize the requirements from the ENERGY
STAR Data Center Storage Program Requirements on storage products. The profile indicates what properties
Swordfish implementations need to support in order to properly instrument EnergyStar reporting capability. This
functionality is intended to support EnergyStar data gathering requirements as part of the EnergyStar certification
process.
6.4 Class of Service Feature
6.4.1 Overview
Swordfish supports a ClassOfService feature. The ClassOfService functionality supports systems that are
capable of providing a greater level of management automation, where a higher-level set of goals is provided as
direction rather than requiring parameterized inputs for all configuration actions.
The Class of Service feature uses a combination of device-defined capabilities to structure LinesOfService, which are
sets of available functionality in a given system, that can then be grouped together to provide classes of service.
When Class of service functionality is implemented, the Swordfish functionality may be entirely exposed through the
StorageService resource. Each Swordfish StorageService is located in the ServiceRoot (and ServiceContainer) via the
StorageServices resource collection.

6.4.2 Class of Service Model
For Swordfish with a class of service interface, the following two models apply. Either model choice results in the
same storage service, regardless of the storage system model.
1. Integrated Service Configuration
The storage systems managed by the Swordfish storage service are modeled using the Redfish Storage resource and
StorageController resource collections. The Storage resource is located in the Redfish hierarchy contained by
ComputerSystems, typically running as ApplicationServers. The physical infrastructure is modeled using Redfish
Chassis. These relationships are shown in Figure 6.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 29 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification

Figure 6: Integrated Service Overview

This configuration works well when the storage service is hosted by a storage resource within a computer system. An
example of a Storage Service for an integrated service configuration is shown in Figure 7.
Note: This diagram and the discussion of the configuration description have been simplified slightly to avoid
confusion. A full implementation would likely include additional links to the logical storage controller
resources.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 30 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification

Figure 7: Integrated Service Example
2. Hosted Service Configuration
The storage systems managed by the Swordfish storage service are located in the ServiceRoot (and
ServiceContainer) via the StorageSystems resource collection. They are modeled using Redfish
ComputerSystems. The physical infrastructure is modeled using Redfish Chassis. These relationships are shown
in Figure 8.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 31 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification

Figure 8: Hosted Service Overview

This configuration works well when the storage system hosts the storage service directly. An example of a Storage
Service for a hosted service configuration is shown in Figure 9.
Note: This diagram and the discussion of the configuration description have been simplified slightly to avoid
confusion. A full implementation would likely include additional links to the logical storage controller
resources.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 32 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification

Figure 9: Hosted Service Example
6.4.3 ServiceRoot Additions
When the StorageService feature is implemented, the following is added to the ServiceRoot:
StorageServices: A resource collection that references a set of StorageService resources. Each
StorageService resource represents the resources and behaviors supported by that storage service.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 33 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification

6.4.4 The StorageService resource

6.4.4.1 Principal Properties
The storage service is hosted on a storage system and exposes logical storage, associated resources and related

functionality. Storage service resources can be found in the service root or service container via the
StorageServices resource collection.

The following are the principal properties of StorageService that point to resources managed or defined by the
storage service:
ClassesOfService: A reference to a resource collection that specifies the supported ClassOfService
resources.
Drives: A reference to a resource collection that collects Drive resources used for storage.
Enclosures: A reference to a resource collection that collects Chassis resources that contain storage related
resources.
Endpoints: A reference to a resource collection that collectsEndpoint resources used to access storage.

FileSystems: A reference to a resource collection that collects FileSystem resources.
EndpointGroups: A reference to a resource collection that collects EndpointGroups resources.
StorageGroups: A reference to a resource collection that collects StorageGroup resources.
StoragePools: A reference to a resource collection that collects StorageGroup resources.
Volumes: A reference to a resource collection that collects Volume resources.
HostingSystem: A reference to the ComputerSystem instance that hosts this StorageService.
6.4.4.2 Capabilities and Lines of ServiceRoot
The following properties each define a set of attributes, which describe capabilities that the storage service may
support:
DataProtectionLoSCapabilities: Replicas that protects data from loss.
DataSecurityLoSCapabilities: Data security service level requirements. The data security characteristics
enable the storage system to be used in an environment where compliance with an externally-specified security
standard or standards is required. Examples of such standards include FIPS-140, HIPAA and PCI.
DataStorageLoSCapabilities: Provisioning and access characteristics for storage of the data.
IOConnectivityLoSCapabilities: IO connectivity requirements for access to the data.
IOPerformanceLoSCapabilities: IO performance requirements for access to the data.
In each of the above, not all combinations of attribute values defined within a capability are likely to be supported by
the storage service.
Known, supported combinations of attribute values are used to construct entries in the LinesOfService array
property. Not all attributes of a line of service entry need be specified (i.e. some may be Null). If an attribute has no
value, the storage service may choose any supported values when provisioning for that entry. Otherwise, the line of
service attribute values specifies the kind or level of service to be provided.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 34 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification

6.4.4.3 The ClassOfService resource

A class of service represents a choice of utility or warranty offered to customers by a service. (ITIL uses the term

service option. See the Normative References.)

Each ClassOfService resource is a uniquely named description of the characteristics of one choice of utility or

warranty for a service. Each ClassOfService is a description of the kind and quality of service to provide and is

not intended to describe how the service provides that service.

Each ClassOfService is defined by an aggregation of lines of service. Supported lines of service are listed in the

corresponding capabilities attributes of the storage service, (see above).
Currently defined lines of service are:
Data Protection: Describes the characteristics of a replica that protects data from loss.
Data Security: Describe data security service level requirements. The data security characteristics enable the
storage system to be used in an environment where compliance with an externally-specified security standard or
standards is required. Examples of such standards include FIPS-140, HIPAA and PCI.
Data Storage: Describes provisioning and access characteristics for storage of the data.
IO Connectivity: Describes IO connectivity requirements for access to the data.
IO Performance: Describes the IO performance requirements for access to the data under a particular workload.
Some advertised ClassOfService resources are created by the service implementation. These are generally not
changeable and are intrinsic to the implementation.
A service may support creation or modification of ClassOfService resources. All must be consistent with the
capabilities of the service.
6.4.4.4 The StoragePool resource
When a Swordfish implementation advertises support for the Class of Service feature, the StoragePool resource
now presents a new method to the client to allocate unassigned storage capacity. This is automated by the system as
conformance to one or more classes of service. Requests to StoragePool shall automatically allocate capacity based
on the constraints of the selected class of service and any other selected parameters, with priority given to the class
of service constraints.
The following are the principal properties of StoragePool that are used to identify resources provisioned or
supported by the storage pool related to Class of Storage:
ClassesOfService: A reference to a resource collection that specifies the set ClassOfService resources that
can be specified when provisioning resources from the storage pool.
DefaultClassOfService: A reference to the default ClassOfService resources used for provisioning from
the storage pool.
6.4.4.5 The Volume resource
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 35 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification

Volume resource represents a block-addressable container of storage, sometimes referred to as a “Logical Unit”,
“LU”, “LUN”, or “StorageVolume” in the storage industry. Volumes optionally adhere to a ClassOfService, which
defines added functionality. Examples include:

Access capabilities
Capacity and capacity sources
Consumption tracking (e.g., LowSpaceWarningThresholdPercents)
Replication details
StorageGroup Information
6.4.4.6 The FileSystem resource
In a Swordfish implementation that advertises support for the Class of Service feature, File systems represent file-

addressable capacity that are conformant to a ClassOfService.

Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 36 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification

7 Schema Considerations
7.1 Schema Introduction
7.1.1 Overview
A Swordfish implementation is a Redfish implementation, and as such it minimally includes support for some
Redfish-defined schema, including ServiceRoot and ComputerSystem. Swordfish implementations include support
for Swordfish-defined schema. The Swordfish model focuses primarily on the logical model of a storage system and
does not require full representation of a physical instantiation. This is left to the implementer to complete from
available Redfish schema models.
Swordfish schema is conformant with the rules used to define Redfish schema. Redfish schema is conformant with
the Common Schema Definition Language, see CSDL. This section provides additional definition and context for the
CSDL elements used to define Swordfish schema.
7.1.2 Swordfish Extension of the Redfish ServiceRoot
The Redfish ServiceRoot has properties that provide access to Swordfish resources.
The first is StorageSystems. This property references a collection of ComputerSystem resources that each
support Swordfish functiona
...

INTERNATIONAL ISO/IEC
STANDARD 5965
First edition
2021-08
Information technology — Swordfish
Scalable Storage Management API
Specification
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: [phone]
Email: [e-mail]
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 or
www.iec.ch/members_experts/refdocs).
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 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. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by SNIA (as Swordfish Scalable Storage Management API Specification,
Version 1.1.0c) 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.
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 and www.iec.ch/national-
committees.
© ISO/IEC 2021 – All rights reserved iii

Swordfish SSM API Specification
Table of Contents
About SNIA
Acknowledgements
Table of Contents
1 Abstract 11
2 Scope 12
2.1 Audience Assumptions 13
3 Normative References
3.1 Overview 14
3.2 Approved references 14
3.3 References under development 16
3.4 Other references 16
4 Terms and Definitions 17
4.1 Overview 17
4.2 Swordfish-specific Terms 17
4.3 Reference to Redfish terms 18
4.4 Keywords (normative language terms) 19
5 Swordfish Overview 20
5.1 Introduction 20
5.2 Relation to Redfish 20
5.3 Storage System Models 21
5.4 The ServiceRoot and ServiceContainer entities 24
5.5 Swordfish model overview 25
6 Features and Profiles 28
6.1 Overview 28
6.2 Requirement for SupportedFeatures 28
6.3 EnergyStar for Storage Feature 28
6.4 Class of Service Feature 29
7 Schema Considerations 37
7.1 Schema Introduction 37
7.2 Default values and NULLABLE attributes 37
7.3 Common schema annotations 38
7.4 Property implementation requirements 39
7.5 Schema repository 40
7.6 Referencing other schemas 40
8 Implementation requirements 41
8.1 Security 41
8.2 General constraints 41
8.3 Discovering Swordfish resources 42
8.4 ClassOfService requirements 43
8.5 StorageSystems requirements 43
8.6 Entity Sets 43
8.7 Addressing entities within a collection 43
8.8 Addressing members of a ResourceCollection 44
8.9 HTTP status codes 44
9 Swordfish type definitions 48
9.1 Overview 48
9.2 Common properties 48
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 9 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
9.3 Complex Types 55
9.4 CapacitySource 1.1.2 56
9.5 ClassOfServiceCollection 63
9.6 ConsistencyGroup 1.0.1 64
9.7 ConsistencyGroupCollection 76
9.8 DataProtectionLoSCapabilities 1.1.3 78
9.9 DataSecurityLoSCapabilities 1.1.3 83
9.10 DataStorageLoSCapabilities 1.2.1 91
9.11 DriveCollection 95
9.12 EndpointGroup 1.2.0 97
9.13 EndpointGroupCollection 101
9.14 FeaturesRegistry 1.0.0 102
9.15 FileShare 1.1.3 105
9.16 FileShareCollection 111
9.17 FileSystem 1.2.2 112
9.18 FileSystemCollection 120
9.19 HostedStorageServices 121
9.20 IOConnectivityLoSCapabilities 1.1.3 122
9.21 IOPerformanceLoSCapabilities 1.1.3 126
9.22 LineOfService 1.0.0 130
9.23 LineOfServiceCollection 132
9.24 SpareResourceSet 1.0.1 133
9.25 StorageGroup 1.2.1 136
9.26 StorageGroupCollection 145
9.27 StoragePool 1.3.1 147
9.28 StoragePoolCollection 156
9.29 StorageReplicaInfo 1.3.0 157
9.30 StorageService 1.4.0 159
9.31 StorageServiceCollection 168
9.32 StorageSystemCollection 169
9.33 Volume 1.4.1 170
9.34 VolumeCollection 202
Annex A: Bibliography 205
A.1 Overview 205
A.2 Informational references 205
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 10 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
1 Abstract
The Swordfish Scalable Storage Management API (“Swordfish”) defines a RESTful interface and a standardized data
model to provide a scalable, customer-centric interface for managing storage and related data services. It extends the
Redfish Scalable Platforms Management API Specification (DSP0266) from the DMTF.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 11 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
2 Scope
Swordfish extends the Redfish Scalable Platforms Management API Specification, as defined by ISO 30115 It defines
a comprehensive, RESTful API for storage management that addresses block storage, file systems, object storage, and
storage network infrastructure. It is centered around common operational and business concerns of storage
management, including:
Configuration and provisioning
Monitoring
Event and log management
Performance assessment
Diagnostics
Fault detection and remediation
Security
Accounting and resource consumption
Swordfish’s storage model is built around well-defined classes of service, which provide a means to map high-level
business goals and objectives to specific, storage-based actions and requirements, in a clear and consistent way that
can be applied uniformly across a broad spectrum of storage configurations and storage types (e.g., block storage, file
systems, object stores). Common storage management functionality covered by class of service includes snapshots,
replication, mapping and masking, and provisioning.
The Redfish specification provides the protocols and a core set of data models and behaviors for the management of
systems. It defines the elements and behaviors that are mandatory for all Redfish implementations. Additionally it
defines additional elements and behaviors that can be chosen by system vendors or manufacturers. The
specifications also defines points at which OEM (system vendor) extensions can be provided by a given
implementation. The specifications specifies normative requirements for Redfish Services and associated materials,
such as Redfish Schema files. The Redfish specifications does not set requirements for Redfish clients, but will
indicate what a Redfish client should do in order to access and utilize a Redfish Service successfully and effectively.
The Swordfish specification defines additional data models and behaviors for the management of storage systems
and storage infrastructure. A Swordfish implementation shall conform to all requirements specified in the Redfish
specifications.
Swordfish is suitable for a wide range of storage, from small-scale object drives, integrated RAID cards or RBODs
providing storage services, to external disk arrays or file servers, to infrastructure providing storage services for
converged, hyperscale and large scale cloud environments.
This document defines the Swordfish Scalable Storage Management API.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 12 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
2.1 Audience Assumptions
As Swordfish is designed as an extension of the Redfish specification, this document is written with the presumption
that the reader has a detailed understanding of ISO 30115 and any updates or clarifications introduced by the DMTF.
This document cannot be fully understood without that context.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 13 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
3 Normative References
3.1 Overview
The documents listed in Table 3 is 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.
3.2 Approved references
Table 3: Approved normative references
Tag Title (Version) Author URL
ISO- Data elements and ISO/IEC http://www.iso.org/iso/home/store/catalogue_ics/
8601 interchange formats catalogue_detail_ics.htm?csnumber=70907
– Information
interchange –
Representation of
dates and times –
Part 1: Basic rules
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 14 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
Table 3: Approved normative references, cont.
Tag Title (Version) Author URL
ISO- ISO/IEC ISO/IEC http://isotc.iso.org/livelink/livelink/
Direct Directives, Part fetch/2000/2122/4230450/4230456/
2 ISO_IEC_Directives Part_2
Principles and Principles_and_rules_for_the
rules for the structure_and_drafting_of_ISO_and_IEC
structure and documents
drafting of ISO -2016%287th_edition%29-_PDF.pdf?
and IEC nodeid=17667902&vernum=-2
documents
(Seventh
Edition, 2016)
OData Open Data OASIS https://www.oasis-
Protocol (v. 4.0) open.org/standards#odatav4.0
RFC3986 Uniform The Internet http://www.rfc-base.org/txt/rfc-3986.txt
Resource Society
Identifier (URI):
Generic Syntax
(2005)
CSDL Common OASIS http://docs.oasis-open.org/odata/
Schema odata/v4.0/odata-v4.0-part3-csdl.html
Definition
Language (4.0)
ITIL ITIL Glossary ITIL https://www.axelos.com/Corporate/media/
(2011) Files/Glossaries/
ITIL_2011_Glossary_GB-v1-0.pdf
Units The Unified Regenstrief http://unitsofmeasure.org/trac
Code for Units Institute,
of Measure Inc. and the
(v2.0.1) UCUM
Organization
SPC-4 SCSI Primary T10 http://www.techstreet.com/cgi-
Commands - 4 bin/joint.cgi/incits
(SPC-4) INCITS
513-2015
Features Swordfish SNIA https://redfish.dmtf.org/registries/swordfish/v1/
Features SwordfishFeatureRegistry.1.0.1.json
Registry, version
1.0.1
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 15 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
Table 3: Approved normative references, cont.
Tag Title (Version) Author URL
Messages Swordfish SNIA https://redfish.dmtf.org/registries/swordfish/v1/
Message Swordfish.1.0.2.json
Registry, version
1.0.2
EnergyStar ENERGY STAR EPA https://www.energystar.gov/sites/default/files/ENERGY
Data Center STAR Data Center Storage Final Version 1.1 Specification
Storage Version Rev. April 2019.pdf
1.1 Updated
Program
Requirements –
April 1, 2019
ISO-20648 Information ISO/IEC https://www.iso.org/standard/68622.html
technology —
TLS
specification for
storage systemsi
ISO-30115 ISO/IEC ISO/IEC https://www.iso.org/standard/53235.html
30115(en)
Information
technology —
Redfish scalable
platforms
management
API specification
3.3 References under development
None defined in this document.
3.4 Other references
None defined in this document.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 16 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
4 Terms and Definitions
4.1 Overview
In this document, some terms have a specific meaning beyond the normal English meaning. Those terms are defined
in this clause. New terms, frequently used Redfish terms.
4.2 Swordfish-specific Terms
4.2.1 Definitions
Table 4 summarizes the terms are used in this document.
Table 4: Swordfish terms
Term Definition
Entity An instance of a schema element.
Model A set of entities and the relationships between them that define the semantics,
behavior and state of that set.
OData A REST-based service that allows resources, identified using Uniform Resource
service Locators (URLs) and defined in a model, to be published and edited by Web clients
using simple HTTP messages.
Resource A central element in a model, which represents a physical construct or a logical
service, and is further defined by other model entities.
Schema A formal language representation of a model that conforms to a metamodel.
Service A particular resource that is directly accessed via an OData service entry point. This
Document resource serves as a starting point for locating and accessing the other resources and
associated metadata that together make up an instance of a Swordfish service.
Swordfish An extension to the Redfish Service that conforms to the Swordfish specification, and
service provides REST-ful storage management functionality.
4.2.2 Symbols and abbreviated terms
None in this document.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 17 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
4.3 Reference to Redfish terms
Many terms in this document were originally defined in the Redfish Specification. Some of the more common terms
and definitions are reproduced in Table 5, as an aid to the reader.
Table 5: Redfish terms
Term Definition (as of 16 August 2019)
OData The Open Data Protocol, as defined in OData-Protocol.
OData Resource that provides information about the service root for generic OData clients.
Service
Document
Redfish Defines Redfish Resources according to OData schema representation. You can
Schema directly translate a Redfish Schema to a JSON Schema representation.
Redfish Implementation of the protocols, resources, and functions that deliver the interface
service that this specification defines and its associated behaviors for one or more managed
systems.
Request A message from a client to a service.
Service Resource that serves as the starting point for locating and accessing the other
Root resources and associated metadata that together make up an instance of a Redfish
Service.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 18 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
4.4 Keywords (normative language terms)
This document conforms to ISO/IEC Directives, Part 2 for keyword usage. The most common terms and their
intended meanings are summarized in Table 6.
Table 6: Normative language terms
Term(s) Meaning
shall / Used to identify objectively verifiable criteria to be fulfilled and from which no
shall not deviation is permitted if compliance with the document is to be claimed
should / Used to identify a suggested possible choice or course of action deemed to be
should particularly suitable without necessarily mentioning or excluding others
not
may / Used to convey consent or liberty (or opportunity) to do something
need not
can / Expected or conceivable material, physical or causal outcome
cannot
must Identifies a constraint or obligation on the user of the document, typically due to one
or more legal requirements or laws of nature, that is not stated as a provision of the
standard
NB: “must” is not an alternative for “shall”, and should only be used for constraints
that arise from outside this standard
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 19 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
5 Swordfish Overview
5.1 Introduction
The Swordfish Scalable Storage Management API (“Swordfish”) defines a RESTful interface and a standardized data
model to provide a scalable, customer-centric interface for managing storage and related data services. It extends the
Redfish Scalable Platforms Management API Specification (DSP0266) from the DMTF.
5.2 Relation to Redfish
Figure 1: Extension Overview
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 20 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
The Swordfish service interface extends the Redfish service interface, as illustrated in Figure 1. As such, a Swordfish
service is a Redfish service and includes all required elements of the Redfish model.
Storage systems managed by the Swordfish service are located in the ServiceRoot via the StorageSystems
resource collection. They are modeled using Redfish ComputerSystems. The physical infrastructure is modeled
using Redfish Chassis.
As modeling for storage systems may cover both logical and physical constructs, Swordfish management clients that
are focused on logical storage management use cases may choose to manage functionality entirely by way of logical
resources.
Each Swordfish service is accessed via well known URLs on the system supporting the Swordfish Service. Since
Swordfish is an extension of Redfish, these URLs are the same as for accessing the Redfish defined aspects of the
service.
5.3 Storage System Models
Swordfish has been designed to support a broad range of configurations, requirements, size and complexity, as well
as logical and physical architectures. As a result, there are two primary methods of modelling the storage system for
a Swordfish implementation:
1. Swordfish Integrated Configuration
The SIC uses the same ComputerSystem model instantiation as the server where the physical element resides.
The logical storage controller is modeled using the Redfish Storage and StorageController resources. The
Storage resource is located in the Redfish hierarchy contained by ComputerSystems, typically running as
ApplicationServers. The physical infrastructure is modeled using Redfish Chassis. Managed resources are
connected to the Storage resource, including Volumes the StoragePools. These relationships are illustrated in
Figure 2.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 21 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
Figure 2: Integrated Configuration Overview
This configuration works well when the storage system can be modeled by simply instantiating a new Storage object
within an existing computer system. An example of a Storage System for an integrated configuration is shown in
Figure 3.
Figure 3: Integrated Configuration Example
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 22 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
2. Swordfish Standalone Configuration
The SSC uses separate ComputerSystem/StorageSystem model instantiation(s) to represent/model the logical
controller(s) for the system.
The logical storage controller is modeled using Redfish a ComputerSystems with properties set as a
StorageSystem. The physical infrastructure is modeled using Redfish Chassis. Managed resources are then
connected to the Storage resource, including Volumes, StoragePools, ConsistencyGroups, and
StorageGroups. These relationships are illustrated in Figure 4.
Figure 4: Standalone Configuration Overview
This configuration works well when the storage system needs a new ComputerSystem instance to model the logical
controller. An example of a Storage System for a hosted service configuration is shown in Figure 5.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 23 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
Figure 5: Standalone Configuration Example
5.4 The ServiceRoot and ServiceContainer entities
5.4.1 Overview
A GET of /redfish/v1 will return the ServiceRoot entity. A GET of /redfish/v1/odata will return the
ServiceContainer instances that represents the OData service document. Each of these instances provides links to
the remainder of the system.
The following are the elements utilized for Swordfish management.
Systems: A reference to a Systems resource collection;
Chassis: A reference to a Chassis resource collection;
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 24 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
StorageSystems: A reference to a StorageSystems resource collection.
5.4.2 The Systems resource collection
A resource collection that references a set of ComputerSystem resources that each represents a general purpose
application server. Each ComputerSystem resource will have an entry with the value of “ApplicationServer” in its
HostingRoles property. A particular ComputerSystem resource can be in both the StorageSystems collection and
the Systems collection.
5.4.3 The Chassis resource collection
A resource collection that references a set of Chassis resources. Each Chassis resource represents physical
containers, (i.e. sheet-metal confined spaces and logical zones like racks, enclosures, chassis and all other
containers). Subsystems (like sensors), which operate outside of a system’s data plane (meaning the resources are not
accessible to software running on the system) are linked either directly or indirectly through this resource.
5.4.4 The StorageSystems resource collection
A reference to a ComputerSystemCollection with members of type ComputerSystem that support storage
services. These ComputerSystem resources represent systems that support Swordfish storage management services.
They will have an entry with the value of “StorageServer” in their HostingRoles property.A resource collection that
references a set of ComputerSystem resources that each represents a storage server. Each ComputerSystem
resource will have an entry with the value of “StorageServer” in its HostingRoles property. A particular
ComputerSystem resource can be a member of both the StorageSystems resource collection and the Systems
resource collection.
5.5 Swordfish model overview
5.5.1 The Storage resource
The storage system exposes logical storage, associated resources and related functionality. Storage service resources
can be found in the service root or service container via the StorageSystem resource collection, and are attached to
the Storage object within the StorageSystem (ComputerSystem).
The following are the principal properties of Storage that point to resources managed or defined by the storage
system:
Drives: A reference to a collection that collects Drive resources used for storage.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 25 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
Enclosures: A reference to a resource collection that collects Chassis resources that contain storage related
resources.
Endpoints: A reference to a resource collection that collects Endpoint resources used to access storage.
EndpointGroups: A reference to a resource collection that collects EndpointGroups resources.
FileSystems: A reference to a resource collection that collects FileSystem resources.
StorageGroups: A reference to a resource collection that collects StorageGroup resources.
ConsistencyGroups: A reference to a resource collection that collects ConsistencyGroup resources.
StoragePools: A reference to a resource collection that collects StorageGroup resources.
Volumes: A reference to a resource collection that collects Volume resources.
5.5.1.1 The Endpoint resource
Endpoints represent one end of a protocol specific connection that supports sending or receiving messages according
to a particular protocol.
5.5.1.2 The Endpoint Collection resource
The Endpoint Group is resource collection that references a set of Endpoint resources.
5.5.1.3 The ConsistencyGroup resource
ConsistencyGroups represent a set of volumes that are managed consistently and collectively as a group, to allow
system and application level activities to be performed on a set of data that spans volumes. This activities include
device-level replication activities as well as system level functions, such as reset.
When ConsistencyGroups are implemented, they are attached to a Storage resource and its internal Volumes
collection is constructed from a subset of the Volumes collection of the Storage resource.
5.5.1.4 The ConsistencyGroup Collection resource
The ConsistencyGroupCollection is a resource collection that references a set of ConsistencyGroup
resources.
5.5.1.5 The StorageGroup resource
StorageGroups represent a set of volumes that are managed as a group in order to facilitate mapping and masking, in
which the volumes of a storage group are collectively exposed or hidden to a set of clients.
The set of volumes is specified by the Mapped Volumes attribute. MappedVolumes is a resource collection of the
Mapped Volume construct (a tuple of a pointer to a volume and a corresponding Logical Unit Number for that
volume).
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 26 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
The set of client endpoints to which the volumes can be exposed is specified by the
ClientEndpointGroupsattribute. The ClientEndpointGroup resource specifies a collection of EndpointGroup
resources.
The set of server endpoints to which the volumes can be exposed is specified by the
ServerEndpointGroupsattribute. The ServerEndpointGroup resource specifies a collection of EndpointGroup
resources.
5.5.1.6 The StoragePool resource
The StoragePool resource represents unassigned storage capacity that can be used to produce storage volumes or
other storage pools.
The following are the principal properties of StoragePool that are used to identify resources provisioned or
supported by the storage pool:
AllocatedVolumes: A reference to a resource collection that collects Volume resources that have been
provisioned from the storage pool.
AllocatedPools: A reference to a resource collection that collects StoragePool resources that have been
provisioned from the storage pool.
5.5.1.7 The Volume resource
Volume resource represents a block-addressable container of storage, sometimes referred to as a “Logical Unit”,
“LU”, “LUN”, or “StorageVolume” in the storage industry.
5.5.1.8 The FileSystem resource
This FileSystem resource represents a file system. Each FileSystem may contain a collection of FileShares that
can be presented to hosts.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 27 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
6 Features and Profiles
6.1 Overview
Features are high-level descriptions of functionality which an implementation uses to advertise what functionality it
currently supports, and for some features, is capable of supporting.
The detailed definitions required to describe to implementers how to implement a feature are written in profile
definition files. A feature is generally represented in one (but may be more) profile definition file, or profile.
Profiles are detailed descriptions that describe down to the individual property level what functionality is required in
order to advertise features. Different profile definitions can exist for the same feature type but for various types of
storage configurations: Swordfish.Block.Provisioning, Swordfish.File.Provisioning
The Swordfish Features Registry shall be used to advertise what standard and Oem Features an implementation
supports.
6.2 Requirement for SupportedFeatures
SupportedFeatures entries in the Features registry represent the client’s primary initial runtime view of the
capabilities of a Swordfish implementation. Without properly formed entries in this registry, there is no visibility to
an implementation’s functionality.
Swordfish implementations shall implement the Features registry and advertise at least the
SNIA.Swordfish.Discovery supported feature in order to be considered a Swordfish implementation.
Features define coarse-grained sets of functionality. In order to advertise a feature (using the SupportedFeature
mechanism in the SupportedFeatures Registry), the implementation must support the complete set of functionality
as defined in the corresponding profile.
The Swordfish Features Registry publishes the official list of supported SNIA Features, and provides a high-level
description of their functionality. Many of those features are self-explanatory (e.g., local replication, remote
replication), but there are some features where additional context is appropriate:
Class of Service
Energy Star for Storage
6.3 EnergyStar for Storage Feature
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 28 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification
The EnergyStar for Storage Feature and profile has been created to formalize the requirements from the ENERGY
STAR Data Center Storage Program Requirements on storage products. The profile indicates what properties
Swordfish implementations need to support in order to properly instrument EnergyStar reporting capability. This
functionality is intended to support EnergyStar data gathering requirements as part of the EnergyStar certification
process.
6.4 Class of Service Feature
6.4.1 Overview
Swordfish supports a ClassOfService feature. The ClassOfService functionality supports systems that are
capable of providing a greater level of management automation, where a higher-level set of goals is provided as
direction rather than requiring parameterized inputs for all configuration actions.
The Class of Service feature uses a combination of device-defined capabilities to structure LinesOfService, which are
sets of available functionality in a given system, that can then be grouped together to provide classes of service.
When Class of service functionality is implemented, the Swordfish functionality may be entirely exposed through the
StorageService resource. Each Swordfish StorageService is located in the ServiceRoot (and ServiceContainer) via the
StorageServices resource collection.

6.4.2 Class of Service Model
For Swordfish with a class of service interface, the following two models apply. Either model choice results in the
same storage service, regardless of the storage system model.
1. Integrated Service Configuration
The storage systems managed by the Swordfish storage service are modeled using the Redfish Storage resource and
StorageController resource collections. The Storage resource is located in the Redfish hierarchy contained by
ComputerSystems, typically running as ApplicationServers. The physical infrastructure is modeled using Redfish
Chassis. These relationships are shown in Figure 6.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 29 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification

Figure 6: Integrated Service Overview

This configuration works well when the storage service is hosted by a storage resource within a computer system. An
example of a Storage Service for an integrated service configuration is shown in Figure 7.
Note: This diagram and the discussion of the configuration description have been simplified slightly to avoid
confusion. A full implementation would likely include additional links to the logical storage controller
resources.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 30 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification

Figure 7: Integrated Service Example
2. Hosted Service Configuration
The storage systems managed by the Swordfish storage service are located in the ServiceRoot (and
ServiceContainer) via the StorageSystems resource collection. They are modeled using Redfish
ComputerSystems. The physical infrastructure is modeled using Redfish Chassis. These relationships are shown
in Figure 8.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 31 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification

Figure 8: Hosted Service Overview

This configuration works well when the storage system hosts the storage service directly. An example of a Storage
Service for a hosted service configuration is shown in Figure 9.
Note: This diagram and the discussion of the configuration description have been simplified slightly to avoid
confusion. A full implementation would likely include additional links to the logical storage controller
resources.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 32 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification

Figure 9: Hosted Service Example
6.4.3 ServiceRoot Additions
When the StorageService feature is implemented, the following is added to the ServiceRoot:
StorageServices: A resource collection that references a set of StorageService resources. Each
StorageService resource represents the resources and behaviors supported by that storage service.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 33 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification

6.4.4 The StorageService resource

6.4.4.1 Principal Properties
The storage service is hosted on a storage system and exposes logical storage, associated resources and related

functionality. Storage service resources can be found in the service root or service container via the
StorageServices resource collection.

The following are the principal properties of StorageService that point to resources managed or defined by the
storage service:
ClassesOfService: A reference to a resource collection that specifies the supported ClassOfService
resources.
Drives: A reference to a resource collection that collects Drive resources used for storage.
Enclosures: A reference to a resource collection that collects Chassis resources that contain storage related
resources.
Endpoints: A reference to a resource collection that collectsEndpoint resources used to access storage.

FileSystems: A reference to a resource collection that collects FileSystem resources.
EndpointGroups: A reference to a resource collection that collects EndpointGroups resources.
StorageGroups: A reference to a resource collection that collects StorageGroup resources.
StoragePools: A reference to a resource collection that collects StorageGroup resources.
Volumes: A reference to a resource collection that collects Volume resources.
HostingSystem: A reference to the ComputerSystem instance that hosts this StorageService.
6.4.4.2 Capabilities and Lines of ServiceRoot
The following properties each define a set of attributes, which describe capabilities that the storage service may
support:
DataProtectionLoSCapabilities: Replicas that protects data from loss.
DataSecurityLoSCapabilities: Data security service level requirements. The data security characteristics
enable the storage system to be used in an environment where compliance with an externally-specified security
standard or standards is required. Examples of such standards include FIPS-140, HIPAA and PCI.
DataStorageLoSCapabilities: Provisioning and access characteristics for storage of the data.
IOConnectivityLoSCapabilities: IO connectivity requirements for access to the data.
IOPerformanceLoSCapabilities: IO performance requirements for access to the data.
In each of the above, not all combinations of attribute values defined within a capability are likely to be supported by
the storage service.
Known, supported combinations of attribute values are used to construct entries in the LinesOfService array
property. Not all attributes of a line of service entry need be specified (i.e. some may be Null). If an attribute has no
value, the storage service may choose any supported values when provisioning for that entry. Otherwise, the line of
service attribute values specifies the kind or level of service to be provided.
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 34 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification

6.4.4.3 The ClassOfService resource

A class of service represents a choice of utility or warranty offered to customers by a service. (ITIL uses the term

service option. See the Normative References.)

Each ClassOfService resource is a uniquely named description of the characteristics of one choice of utility or

warranty for a service. Each ClassOfService is a description of the kind and quality of service to provide and is

not intended to describe how the service provides that service.

Each ClassOfService is defined by an aggregation of lines of service. Supported lines of service are listed in the

corresponding capabilities attributes of the storage service, (see above).
Currently defined lines of service are:
Data Protection: Describes the characteristics of a replica that protects data from loss.
Data Security: Describe data security service level requirements. The data security characteristics enable the
storage system to be used in an environment where compliance with an externally-specified security standard or
standards is required. Examples of such standards include FIPS-140, HIPAA and PCI.
Data Storage: Describes provisioning and access characteristics for storage of the data.
IO Connectivity: Describes IO connectivity requirements for access to the data.
IO Performance: Describes the IO performance requirements for access to the data under a particular workload.
Some advertised ClassOfService resources are created by the service implementation. These are generally not
changeable and are intrinsic to the implementation.
A service may support creation or modification of ClassOfService resources. All must be consistent with the
capabilities of the service.
6.4.4.4 The StoragePool resource
When a Swordfish implementation advertises support for the Class of Service feature, the StoragePool resource
now presents a new method to the client to allocate unassigned storage capacity. This is automated by the system as
conformance to one or more classes of service. Requests to StoragePool shall automatically allocate capacity based
on the constraints of the selected class of service and any other selected parameters, with priority given to the class
of service constraints.
The following are the principal properties of StoragePool that are used to identify resources provisioned or
supported by the storage pool related to Class of Storage:
ClassesOfService: A reference to a resource collection that specifies the set ClassOfService resources that
can be specified when provisioning resources from the storage pool.
DefaultClassOfService: A reference to the default ClassOfService resources used for provisioning from
the storage pool.
6.4.4.5 The Volume resource
Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 35 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification

Volume resource represents a block-addressable container of storage, sometimes referred to as a “Logical Unit”,
“LU”, “LUN”, or “StorageVolume” in the storage industry. Volumes optionally adhere to a ClassOfService, which
defines added functionality. Examples include:

Access capabilities
Capacity and capacity sources
Consumption tracking (e.g., LowSpaceWarningThresholdPercents)
Replication details
StorageGroup Information
6.4.4.6 The FileSystem resource
In a Swordfish implementation that advertises support for the Class of Service feature, File systems represent file-

addressable capacity that are conformant to a ClassOfService.

Swordfish SSM TECHNICAL POSITION
© ISO/IEC 2021 – All rights reserved
Page 36 of 205
API Specification Version 1.1.0d (29 September 2020)

Swordfish SSM API Specification

7 Schema Considerations
7.1 Schema Introduction
7.1.1 Overview
A Swordfish implementation is a Redfish implementation, and as such it minimally includes support for some
Redfish-defined schema, including ServiceRoot and ComputerSystem. Swordfish implementations include support
for Swordfish-defined schema. The Swordfish model focuses primarily on the logical model of a storage system and
does not require full representation of a physical instantiation. This is left to the implementer to complete from
available Redfish schema models.
Swordfish schema is conformant with the rules used to define Redfish schema. Redfish schema is conformant with
the Common Schema Definition Language, see CSDL. This section provides additional definition and context for the
CSDL elements used to define Swordfish schema.
7.1.2 Swordfish Extension of the Redfish ServiceRoot
The Redfish ServiceRoot has properties that provide access to Swordfish resources.
The first is StorageSystems. This property references a collection of ComputerSystem resources that each
support Swordfish functiona
...