One document matched: draft-ietf-ips-isns-00.txt
Internet Draft Kevin Gibbons
<draft-ietf-ips-isns-00.txt> Josh Tseng
Expires July 2001 Charles Monia
Nishan Systems
Franco Travostino
Nortel Networks
Murali Rajagopal
LightSand Communications
Mark Bakke
Cisco Systems
Jim Hafner
IBM Research
Howard Hall
Pirus Networks
January 2001
iSNS Internet Storage Name Service
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Acknowledgements
Numerous individuals contributed to the creation of this draft
through their careful review and submissions of comments and
recommendations. We acknowledge the following persons for their
technical contributions to this document: John Hufferd (IBM),
Julian Satran (IBM), Kaladhar Voruganti(IBM), Joe Czap (IBM), Yaron
Klein (Sanrad), Larry Lamers (SAN Valley), Jack Harwood (EMC),
David Black (EMC), and David Robinson (Sun).
Gibbons, Tseng, Monia 2
iSNS January 2001
Comments
Comments should be sent to the IPS mailing list (ips@ece.cmu.edu)
or to the authors.
1. Abstract
The Internet Storage Name Service (iSNS) provides a generic
framework for configuring and managing various storage entities and
their usage attributes in an IP-based storage network. This
framework includes the iSNS Protocol (iSNSP), which defines how
entities communicate with the iSNS server to discover and utilize
available networked storage resources.
2. Conventions used in this document
iSNS refers to the framework consisting of the storage network
model and associated services.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
All frame formats are in big endian network byte order.
3. iSNS Overview
IP network entities use the Domain Name System (DNS) to resolve
mappings of DNS names to IP addresses. In Fibre Channel networks,
clients use the Storage Name Service (SNS) not only for name-to-
address resolution, but also to discover the managed universe of
available networked storage resources. The iSNS provides a common
framework used to supply both naming and resource discovery
services for IP-based storage entities. iSNS supports multiple IP-
based storage protocols, and provides capabilities such as state
change notification, "soft" partitioning of discovery domains,
distribution of crypto keys required for secure iSCSI login
control, and FCIP tunnel endpoint discovery.
The framework described in this document allows integrated
operation of storage-related naming and discovery services and
existing Domain Name System (DNS) naming services. This allows both
DNS and iSNS infrastructures to coexist in the same network.
Storage entities may use either DNS or iSNS for naming services,
although the storage name-resolution services available through DNS
are a small subset of those that can be obtained through iSNS.
The iSNS Protocol (iSNSP) is a flexible and lightweight protocol
suitable for various platforms, including switches and targets as
well as server hosts. An iSNS server can be implemented as an
Gibbons, Tseng, Monia 3
iSNS January 2001
independent standalone entity to support smaller networks, or the
iSNS can be a distributed cluster supported with a back-end LDAP
database.
The following diagram displays examples of where and how iSNS can
be deployed, and of the various IP-based storage entities that it
can support.
+------------+ +-----------+ +-----------+
| | LDAP | Directory | LDAP | iSNS |
| DNS Server |<-------->| Database |<-------->| Server |
| | | | | |
+------+-----+ +-----+-----+ +-----+-----+
| | |
| DNS | LDAP iSNSP |
|Queries | |
+------+----------------------+----------------------+---------+
| |
| IP Network |
| |
+----+-----------+----------+---------------+-------------+----+
| | | | |
| | +-----+-----+ +------+-----+ +----+----+
| | |iSCSI-/ | |iFCP / | | FCIP |
| | | FC /iSNS | |Switch/iSNS | | Gateway |
| | |Gtwy/Server| | /Server| | |
| | +----+------+ +-+-------+--+ +----+----+
| | | | | |
+----+----+ +----+---+ +---+----+ +----+-+ +---+----+ +---+----+
| iSCSI | | iSCSI | | Fibre | | FC | | Fibre | | Fibre |
|Initiator| | Target | |Channel | |Device| |Channel | |Channel |
+---------+ +--------+ |Network | +------+ |Network | |Network |
+--------+ +--------+ +--------+
iSNS Client Entities
A back end LDAP directory MAY be used to store Domain Name-to-IP
address mappings for both DNS and iSNS. Using this approach, a DNS
server receiving a DNS resolve request MAY use the common LDAP
directory database to resolve DNS names to IP addresses. Changes
to DNS name mappings due to DNS Zone transfers and other DNS
protocol events will be reflected in directory update messages to
the database, and consistently reflected in subsequent iSNSP
queries and State Change Notifications (SCNs).
3.1 iSNS Functional Components
There are three main functional components of the iSNS:
Gibbons, Tseng, Monia 4
iSNS January 2001
1) A Name Service Providing Storage Resource Discovery
2) Network Zoning and Login Control Service
3) State Change Notification Service
3.1.1 Name Registration Service
The iSNS provides a registration function to allow all entities in
a storage network to register and query the directory. Both
targets and initiators can register in the iSNS, as well as query
for information from the iSNS. This allows, for example, a client
initiator to obtain information about target devices from the iSNS
server. This service is modeled on the Fibre Channel Generic
Services Name Server described in FC-GS-3, with extensions,
operating within the context of an IP network.
In order to maintain consistency between DNS Name-to-IP address
mappings stored in the iSNS, and the same mapping which can also be
obtained from existing DNS servers, a common backend database
storing such mappings MAY be implemented to support both DNS and
iSNS. This backend database can be based upon a standard network
directory service such as LDAP.
The naming registration service also provides the ability to obtain
a network unique Domain ID for iFCP gateways, when required.
3.1.2 Network Zoning and Login Control Service
The Network Zoning Service implements the functionality to support
partitioning of iSNS client devices into domains for administrative
and login control purposes. iSNS clients must be in at least one
common zone in order to obtain information about each other from
the iSNS. iSNS clients can be a member of multiple zones
simultaneously.
Network Zoning is an administrative function that can be used to
prevent initiators from learning about each and every target
registered in the name server from the name server, and attempting
a login into every such target. With Zoning, an administrator can
partition groups of initiators and targets into more manageable
"Discovery Domains", in order to limit the login process to the
more appropriate subset of targets registered in the iSNS. This
functionality is the equivalent of the "Soft Zoning" functionality
in a Fibre Channel network.
The zoning information stored in the iSNS can be used by various
enforcement points in the network to provide enhanced enforcement.
For example, a Network Zoning-aware switch can block storage
initiators from accessing targets that are not in the same zone,
even if the initiator somehow obtained or has statically programmed
address parameters for a target outside of its zone(s). This
Gibbons, Tseng, Monia 5
iSNS January 2001
functionality is the equivalent of the _Hard Zoning_ functionality
in a Fibre Channel network.
Login Control allows targets to learn about which initiators are
authorized access to them. The target simply downloads the list of
authorized initiators from the iSNS. Each initiator is uniquely
identified by an iSCSI WWUI, iFCP Port Name, or FCIP IP Address,
depending on the protocol supported by the entity. Optionally, the
list of downloaded initiator attributes MAY include the initiator's
Entity Identifier (DNS Name) and Path, and/or World Wide Node Name
(WWNN). Only initiators that match the required identification and
authenticating information provided by the iSNS will be allowed
access by that target during the initiator's session login (e.g.,
the iSCSI login process). If spoofing of initiators is a concern,
the target MAY use the public key certificate of the authorized
initiator, obtained from the iSNS server, to authenticate the
initiator.
If authorized, a target can control the Login Control list. The
target registers the list of authorized initiators to the iSNS,
creating a zone.
3.1.3 State Change Notification Service
The State Change Notification (SCN) service allows the iSNS to
issue notifications about network events that may affect the
operational state of iSNS client entities. The iSNS client has the
ability to register for these notifications of events detected by
the iSNS. The types of events, for which SCNs can be sent, include
change in network zone membership and device registration updates.
The State Change Notification service utilizes the Network Zoning
Service, as described in section 3.1.2, to control the distribution
of notification messages. Notifications about changes within a
zone are contained within that zone.
If the iSNS is unable to service an SCN registration it SHALL
reject the SCN registration request, returning a SCN Registration
Rejected error code. The rejection might occur in situations where
the network size, or current level of SCN registrations, has passed
an implementation specific threshold. A client not allowed to
register for SCNs SHOULD monitor connections directly.
The specific notification mechanism by which the iSNS learns of the
events is implementation-specific, but can include examples such as
explicit notification messages from an iSNS client to the iSNS
server, or a hardware interrupt to a switch-hosted iSNS as a result
of link failure. The iSNS is equivalent to the Fibre Channel State
Change Notification service, with extensions, operating within the
context of an IP network.
Gibbons, Tseng, Monia 6
iSNS January 2001
3.2 iSNS Architectural Components
3.2.1 iSNS Client
Entities that initiate transactions using the iSNS are referred to
as iSNS clients. Using the iSNSP, iSNS clients can register their
attribute information, download information about other registered
clients in a common zone, and receive asynchronous notification of
topology events that occur in their zone(s).
3.2.2 iSNS Server
An iSNS server resides at an IP address in the network, and
responds to TCP and UDP-based iSNSP messages at a TBD port. It may
be implemented on a stand-alone host computer or network management
station, or integrated into one or more switches in the network.
It may even be hosted on a storage device. Administration of the
iSNS server is similar to established processes for administering
DNS servers. The primary functional differences between the iSNS
and classical DNS is the ability for client entities to write
information to the server database using the iSNSP, and receive
asynchronous notification of changes to the iSNS database.
The iSNS server responds to iSNS protocol queries and requests, and
initiates iSNS protocol State Change Notifications. Properly
authenticated information submitted by a registration request is
stored in an internal or external database.
The iSNS server MAY be discovered by iSNS clients through a
multicast discovery message, although the protocol format for this
discovery mechanism is beyond the scope of this document.
3.2.3 iSNS Directory Database
The iSNS database is the information repository for the iSNS
server(s) and possibly the DNS server(s). It maintains information
about DNS Names, IP Addresses, and other attributes of the storage
entities. If used to maintain DNS information, the iSNS directory
database SHALL guarantee consistency between data stored and
retrieved by iSNS server(s) and DNS server(s). This database may
be implemented using a distributed directory database such as LDAP,
and may be implemented using a single common database for both iSNS
servers and DNS servers.
3.3 Storage Attributes
3.3.1 World Wide Name (WWN) Identifiers
Fibre Channel-based iSNS client entities use a set of identifiers
to uniquely identify the device (Node) and each network interface
(Port) associated with the device. A unique 64-bit World Wide Name
Gibbons, Tseng, Monia 7
iSNS January 2001
(WWN) is assigned to each node and each port on the device. The
three WWN types are Node Name (WWNN), Port Name (WWPN), and Fabric
Port Name (FWWN). These globally unique identifiers are used
during the device registration process, and are assigned values
conforming to IEEE Naming Assignment Authority (NAA) type 1, 2, 5,
or 6. This format is found in ANSI/IEEE Std 802-1990 [802-1990].
3.3.2 World Wide Unique Identifiers (WWUI)
iSCSI-based iSNS clients use World Wide Unique Identifiers. The
format of the WWUI is TBD.
3.3.3 IP Address & Port Number
The IP address and Port Number is used to identify a PORTAL to an
IP storage gateway or native storage device in an IP network. The
PORTAL addressed by the IP Address and Port Number can be used to
access any of the STORAGE ENTITIES in the STORAGE NODE.
3.3.4 Entity Identifier (DNS Name)
Entity Identifiers are assigned to network entities registered in
the iSNS. Network entities registered in the iSNS contain one or
more storage devices. By convention, the Entity Identifier is the
DNS Name used by the entity, but use of the DNS Name for this field
is not a requirement. The Path field, in conjunction with the
Entity Identifier, uniquely distinguishes each storage device in
the entity. If an Entity Identifier is not provided during
registration, the iSNS SHALL generate one that is unique within the
iSNS.
3.4 Co-existence with Domain Name System (DNS)
A detailed description of the Domain Name System (DNS) protocol is
found in [RFC 1035], and is beyond the scope of this document. In
the iSNS framework, DNS host names may be given to IP-based
storage devices. Domain Name-to-IP Address mappings can now be
obtained not only from DNS servers, but also through the iSNS.
In order to avoid conflict between independently-administered DNS
and iSNS infrastructure, a common back-end directory database can
be used to store Domain Name-to-IP Address mappings for both DNS
and iSNS. Such a database MAY be based on a standard directory-
access protocol such as LDAP.
3.5 iSNS Applicability
iSNSP functions in networks under cooperative administrative
control. Such networks permit a policy to be implemented regarding
security, multicast routing, and organization of services and
clients into groups. Through leveraging of an Internet-based
Gibbons, Tseng, Monia 8
iSNS January 2001
distributed database framework such as LDAP, the iSNS can be scaled
up to support large networked storage architectures.
Additionally, the iSNS framework allows leverage of existing DNS
mechanisms, where zone transfer of domain information may take
place from upstream authorities in the DNS hierarchy.
The iSNSP provides a common framework for providing the above
services for IP-based storage devices such as native iSCSI storage
products, as well as FCP-based devices such as existing Fibre
Channel storage devices.
3.6 Impact of Network Address Translation (NAT)
The existence of NAT will have an impact upon information retrieved
from the iSNS. If the iSNS client exists in a different addressing
domain than the iSNS server, then IP address information stored in
the iSNS server may not be correct when interpreted in the domain
of the iSNS client.
There are several possible approaches to allow operation of iSNS
within a NAT network. The first approach is to require use of the
canonical TCP port number by both targets and initiators when
addressing targets across a NAT boundary, and for the iSNS client
to not query for nominal IP addresses. Rather, an iSNS client
initiator SHALL query for the DNS name and path when seeking
addressing information. Once retrieved, the DNS name can be
interpreted in each address domain and mapped to the appropriate IP
address by local DNS servers.
A second approach is to deploy a distributed network of iSNS
servers. Local iSNS servers are deployed inside and outside NAT
boundaries, with each local server storing relevant IP addresses
for their respective NAT domains. Updates among the network of
decentralized, local iSNS servers are handled using LDAP and using
appropriate NAT translation rules implemented within the update
mechanism in each server.
The final approach is to simply disallow use of NAT in between
communication between the iSNS server and any iSNS client.
4. iSCSI/Fibre Channel Database Objects
iSNS provides the framework for the registration and discovery of
iSCSI devices, Fibre Channel-based devices using iFCP, and FCIP
tunnel endpoint gateways. This architecture defines common objects
that can be used to represent components referenced by each of
these three protocols. In iSCSI, the IP-based storage end devices
(NICs, controllers, etc...) are registered in the iSNS. In iFCP,
the iFCP gateway and its supported Fibre Channel-based storage end
devices (HBA's, controllers, etc...) have their attributes
Gibbons, Tseng, Monia 9
iSNS January 2001
registered in the iSNS by the iFCP gateway. Finally, for FCIP,
only the FCIP gateway and its supported tunnel endpoints are
registered in the iSNS by the FCIP gateway.
The following architecture framework provides elements needed to
describe various storage device objects and attributes that may
exist on an IP storage network. Five object entities are defined
in this architecture framework. They are PORTAL, NETWORK ENTITY,
STORAGE NODE, STORAGE PORT, and ZONE. Each of these objects are
described in greater detail in sections 4.1 to 4.5.
The object containment hierarchy starts with the ZONE. The ZONE
contains a set of NETWORK ENTITIES. The NETWORK ENTITY can be
contained in multiple ZONES. The NETWORK ENTITY object describes a
device or gateway visible to the IP network. It can contain one or
more STORAGE NODE objects, and one or more PORTAL objects. STORAGE
NODE objects are used to represent an initiator or target storage
controller, while a PORTAL represents an IP Address and Port Number
which can be used to access any of the STORAGE NODE objects within
that NETWORK ENTITY object. Within the STORAGE NODE are one or
more STORAGE PORTS. Each object has a set of attributes described
in section 5. Not all objects are applicable to each protocol
(i.e., iSCSI, iFCP, and FCIP) supported by iSNS. For example, the
STORAGE PORT object is not used in iSCSI. In the diagrams below,
objects are denoted in all CAPITAL letters.
The following diagram models how a simple iSCSI-based initiator and
target is represented using database objects stored in the iSNS.
In this implementation, each target and initiator is attached to a
single PORTAL. Since the devices shown are iSCSI, the STORAGE PORT
object does not apply. All required attributes are also shown in
this diagram:
Gibbons, Tseng, Monia 10
iSNS January 2001
+----------------------------------------------------------------+
| IP Network |
+------------+--------------------------------------+------------+
| |
| |
+-----+------+------+-----+ +-----+------+------+-----+
| | PORTAL | | | | PORTAL | |
| | -IP Addr 1 | | | | -IP Addr 2 | |
| | -TCP Port 1 | | | | -TCP Port 2 | |
| +-----+ +-----+ | | +-----+ +-----+ |
| | | | | | | |
| | | | | | | |
| +--------+ +--------+ | | +-------+ +--------+ |
| | | | | | | |
| | STORAGE NODE | | | | STORAGE NODE | |
| | -WWUI | | | | -WWUI | |
| | -Path: "server1" | | | | -Path: "disk1" | |
| | -Type: initiator | | | | -Type: target | |
| | | | | | | |
| +-------------------+ | | +------------------+ |
| | | |
| NETWORK ENTITY | | NETWORK ENTITY |
| -Entity ID (DNS): | | -Entity ID (DNS): |
| "strg1.foo.com" | | "strg2.bar.com" |
| -Type: iSCSI | | -Type: iSCSI |
| | | |
+-------------------------+ +-------------------------+
The object model can be expanded to describe more complex devices,
such as an iSCSI device with more than one storage controller, each
controller accessible through any of multiple PORTAL interfaces.
The storage controllers on this highly-available device which can
be accessed through alternate PORTAL interfaces, if any original
interface should fail. The following diagram describes such a
device:
Gibbons, Tseng, Monia 11
iSNS January 2001
+---------------------------------------------------------------+
| IP Network |
+-------------------+-----------------------+-------------------+
| |
| |
+------------+------+------+---------+------+------+------------+
| | PORTAL | | PORTAL | |
| | -IP Addr 1 | | -IP Addr 2 | |
| | -TCP Port 1 | | -TCP Port 2 | |
| +-----+ +-----+ +-----+ +-----+ |
| | | | | |
| +---------------+ +---------------------+ +---------------+ |
| +-------+ +----------------+ +-------------------+ +------+ |
| | | | | | | |
| +-------+ +-------+ +------+ +--------+ +--------+ +------+ |
| | | | | | | |
| | STORAGE NODE | | STORAGE NODE | | STORAGE NODE | |
| | -WWUI 1 | | -WWUI 2 | | -WWUI 3 | |
| | -Path: "disk1" | | -Path: "disk2" | | -Path: "disk3" | |
| | -Type: target | | -Type: target | | -Type: target | |
| | | | | | | |
| +-----------------+ +-----------------+ +-----------------+ |
| |
| NETWORK ENTITY |
| -Entity ID (DNS Name): "dev1.foo.com" |
| -Type: iSCSI |
| |
+---------------------------------------------------------------+
The iFCP protocol allows native Fibre Channel devices, or Fibre
Channel fabrics connected to an iFCP gateway, to be directly
internetworked using IP.
When supporting iFCP, the iSNS stores the attributes of the Fibre
Channel devices themselves, attributes of the iFCP gateway, as well
as Fibre Channel fabric switch attributes that might also be stored
in an FC name server.
The following diagram shows a representation of a gateway
supporting multiple Fibre Channel devices behind it. The two
PORTAL objects represent IP interfaces on the iFCP gateway that can
be used to access the two Fibre Channel devices behind it. The
NETWORK ENTITY object represents the iFCP gateway itself, while
each of the STORAGE NODE objects represents an actual Fibre Channel
device. One of the target devices has two ports, each represented
by a STORAGE PORT object.
Gibbons, Tseng, Monia 12
iSNS January 2001
+---------------------------------------------------------------+
| IP Network |
+-------------------+-----------------------+-------------------+
| |
| |
+------------+------+------+---------+------+------+------------+
| | PORTAL | | PORTAL | |
| | -IP Addr 1 | | -IP Addr 2 | |
| | -TCP Port 1 | | -TCP Port 2 | |
| +-----+ +-----+ +-----+ +-----+ |
| | | | | |
| +---------------+ +---------------------+ +---------------+ |
| | Fibre Channel Loop or Fabric | |
| +-------+ +-----------------+ +----------------+ +--------+ |
| | | | | | | |
| +-+-----+ +-----+-+ +--+----+ +------+---+-----+ +-----+--+ |
| | |STORAGE PORT | | | |STORAGE PORT | |STORAGE PORT | | |
| | | -WWPN 1 | | | | -WWPN 2 | | -WWPN 3 | | |
| | | -Port ID 1 | | | | -Port ID 2 | | -Port ID 3 | | |
| | | -FWWN 1 | | | | -FWWN 2 | | -FWWN 3 | | |
| | | -FC COS | | | | -FC COS | | -FC COS | | |
| | +-------------+ | | +-------------+ +-------------+ | |
| | | | | |
| | STORAGE NODE | | STORAGE NODE | |
| | -WWNN 1 | | -WWNN 2 | |
| | -Symbolic Name| | -Symbolic Name | |
| | -FC Node IPA | | -FC Node IPA | |
| | -Type: target | | -Type: target | |
| | | | | |
| +-----------------+ +-------------------------------------+ |
| |
| NETWORK ENTITY |
| -Entity ID (DNS): "gtwy1.foo.com" |
| -Type: iFCP |
| |
+---------------------------------------------------------------+
In each of the following subsections, the attributes described for
each object are covered in more detail in section 5.4. The Key
Attribute column indicates that the attribute is a search key which
can be used to query for that object.
Gibbons, Tseng, Monia 13
iSNS January 2001
The following diagram depicts FCIP gateways stored in the iSNS. In
FCIP, the iSNS is only used for tunnel endpoint discovery.
Therefore, no information about the storage end nodes are
registered in the iSNS, and the STORAGE PORT and STORAGE NODE
objects are not applicable.
+----------------------------------------------------------------+
| IP Network |
+-------------+-------------------------+----------------+-------+
| | |
| | |
+-----+-------+------+----+ +-+------+------+--+------+-----+-+
| | PORTAL | | | | PORTAL | | PORTAL | |
| | -IP Addr 1 | | | | -IP Addr 2 | | -IP Addr 3 | |
| | -TCP Port 1 | | | | -TCP Port 2 | | -TCP Port 3| |
| +--------------+ | | +-------------+ +------------+ |
| | | |
| NETWORK ENTITY | | NETWORK ENTITY |
| -Entity ID (DNS): | | -Entity ID (DNS): |
| "Tunnelgtwy1.foo.com" | | "Tunnelgtwy2.bar.com" |
| -Type: FCIP | | -Type: FCIP |
+-------------------------+ +---------------------------------+
4.1 NETWORK ENTITY Object
The NETWORK ENTITY object represents a device or gateway that is
accessible from the IP network. This device or gateway may support
one or more initiators or target controllers that are either
internal to the storage device, or accessible through a network
behind the gateway. Each individual initiator or target controller
is represented by subordinate STORAGE NODE objects.
Applicability
Attribute iSCSI iFCP FCIP Key Attribute
--------- ----- ---- ---- -------------
Entity Identifier * * * *
Entity Type * * *
Management IP Address * * *
Heartbeat / Timestamp * * *
4.2 PORTAL Object
The PORTAL object is a port through which access to any STORAGE
NODE within the NETWORK ENTITY can be obtained. A NETWORK ENTITY
must have one or more PORTALs, each of which is usable by STORAGE
NODEs contained in that NETWORK ENTITY to gain access to the IP
network.
Gibbons, Tseng, Monia 14
iSNS January 2001
Applicability
Attribute iSCSI iFCP FCIP Key Attribute
--------- ----- ---- ---- -------------
Portal Index * * *
IP Address * * * *
TCP/UDP Port * * * *
Note that if the IP Address and TCP/UDP Port fields are used as the
search key, then both fields must be used in the query to identify
the portal.
4.3 STORAGE NODE Object
The STORAGE NODE object defines an individual storage initiator or
target. This entity may be a RAID controller, a Fibre Channel HBA,
or other individual storage controller. The STORAGE NODE may have
one or more STORAGE PORT objects. There may be one or more STORAGE
NODE objects within the NETWORK ENTITY.
Applicability
Attribute iSCSI iFCP FCIP Key Attribute
--------- ----- ---- ---- -------------
WWUI * *
Path *
Node Type * *
Node Name (WWNN) * *
Node Symbolic Name * *
FC Node IPA *
FC Node IP-Address *
Client Certificate * *
The primary key used to uniquely identify an iSCSI-based STORAGE
ENTITY is WWUI, while the key for an iFCP/Fibre Channel-based
STORAGE ENTITY is WWNN. iFCP/Fibre Channel-based Nodes contain 1
or more STORAGE PORT objects, which are keyed with a WWPN.
4.4 ZONE Object
Zoning is a security and management mechanism used to partition
storage resources. Zoning prevents initiators from potentially
logging in to every possible target during device discovery. When
queried, the iSNS server will only provide information on storage
entities in a common zone. Initiators will thus not be able to
"see" devices that are not in a common zone.
Gibbons, Tseng, Monia 15
iSNS January 2001
Applicability
Attribute iSCSI iFCP FCIP Key Attribute
--------- ----- ---- ---- -------------
Zone ID * * *
Zone Symbolic Name * * * *
Zone Member (WWUI) * *
Zone Member (WWPN) * *
Zone Member (WWNN) * *
Zone Member (IP Address) * * *
4.5 STORAGE PORT Object
The STORAGE PORT object defines an individual service delivery port
that services a STORAGE ENTITY. An iSCSI device does not have a
STORAGE PORT, and this object is therefore unused for an iSCSI
device. For a Fibre Channel device, the STORAGE PORT describes an
N_PORT interface.
Applicability
Attribute iSCSI iFCP FCIP Key Attribute
--------- ----- ---- ---- -------------
Port Name (WWPN) * *
Port_ID *
Port_Type *
Port_Symbolic Name *
FC Hard Address *
FC Fabric Port Name (FWWN) *
FC Class of Service *
FC Port IP Address *
FC FC-4 Types/Features *
FC FC-4 Descriptors *
5. iSNS Message Protocol
The iSNS message format is similar to the format of other common
protocols such as DHCP, DNS and BOOTP. The following describes the
format of the iSNS Protocol:
Gibbons, Tseng, Monia 16
iSNS January 2001
Byte MSb LSb
Offset 15 0
+----------------------------------+
0 | iSNSP VERSION | 2 Bytes
+----------------------------------+
2 | FUNCTION ID | 2 Bytes
+----------------------------------+
4 | MESSAGE LENGTH | 2 Bytes
+----------------------------------+
6 | FLAGS | 2 Bytes
+----------------------------------+
8 | TRANSACTION ID | 2 Bytes
+----------------------------------+
10 | MESSAGE PAYLOAD | N Bytes
+----------------------------------+
10 + N | AUTHENTICATION BLOCK (if present)| L Bytes
+----------------------------------+
Total Length = 10 + N + L
5.1 iSNS Message Header
The iSNSP header contains the iSNSP VERSION, FUNCTION ID, MESSAGE
LENGTH, FLAGS, and TRANSACTION ID fields as defined below:
iSNSP VERSION - Currently 0x0001
FUNCTION ID defines the type of iSNS message. It contains a value
as defined in the "ID" column in the tables below. The following
messages are iSNSP request messages:
Message Description Abbreviation Func ID Support
------------------- ------------ ------- -------
Register Device Attribute Req RegDevAttr 0x0001 Required
Device Attribute Query Request DevAttrQry 0x0002 Required
Device Get Next Request DevGetNext 0x0003 Optional
Deregister Device Request DeregDev 0x0004 Required
SCN Register Request SCNReg 0x0005 Required
State Change Notification SCN 0x0006 Required
Register Zone RegZone 0x0007 Required
Deregister Zone DeregZone 0x0008 Required
Register Device in Zone RegDevZone 0x0009 Required
Deregister Device in Zone DeregDevZone 0x000A Required
Port Status Inquiry PSI 0x000B Optional
PSI Update PSIUpdate 0x000C Optional
Name Service Heartbeat Heartbeat 0x000D Required
Request Domain ID RqstDmnId 0x000E Optional
Release Domain ID RlseDmnId 0x000F Optional
RESERVED 0x0010-0x8000
The following are iSNSP response messages:
Gibbons, Tseng, Monia 17
iSNS January 2001
Response Message Description Abbreviation Func_ID Support
---------------------------- ------------ ------- -------
Register Device Attribute Rsp RegDevRsp 0x8001 Required
Device Attribute Query Response DevAttrQryRsp 0x8002 Required
Device Get Next Response DevGetNextRsp 0x8003 Optional
Deregister Device Response DeregDevRsp 0x8004 Required
SCN Register Response SCNRegRsp 0x8005 Required
Register Zone Response RegZoneRsp 0x8007 Required
Deregister Zone Response DeregZoneRsp 0x8008 Required
Register Device in Zone Response RegDevZoneRsp 0x8009 Required
Deregister Device in Zone Resp DeregDevZoneRsp 0x800A Required
Request Domain ID Response RqstDmnIdRsp 0x800E Optional
Release Domain ID Response RlseDmnIdRsp 0x800F Optional
RESERVED 0x8010-0xFFFF
iSNS MESSAGE LENGTH - Specifies the length of the MESSAGE PAYLOAD
field in bytes.
FLAGS - Indicates additional information about the message and the
type of iSNS entity that generated the message. The following
table displays the valid flags:
Bit Field Flag
--------- ----
0-12 RESERVED
13 Authentication Block Present
14 Sender is the iSNS server
15 Sender is the iSNS client
TRANSACTION ID - Is set to a unique value for each request message.
Replies must use the same TRANSACTION ID value as the associated
iSNS request message. If a message is retransmitted, the same
TRANSACTION ID value must be used.
5.2 iSNS Message Payload
The MESSAGE PAYLOAD is variable length and contains attributes used
for registration and query operations. The attribute data items
use a format similar to other protocols, such as DHCP (RFC 2131)
options. Each iSNS attribute is specified in the iSNSP message
payload using Tag-Length-Value (TLV) data format, as shown below:
+----------+----------+-------------------+
| attr_id | attr_len | attr_val |
+----------+----------+-------------------+
attr_id (ID) - a 2-byte tag field that identifies the attribute as
defined in section 5.5. This field contains the ID of the
indicated attribute.
Gibbons, Tseng, Monia 18
iSNS January 2001
attr_len (Length) - a 2-byte field that indicates the length, in
bytes, of the attribute value to follow.
attr_val (Value) - a variable-length field containing the attribute
value.
The above format is used to identify each attribute in the iSNS
message payload. Each iSNSP request message contains several
attributes in the above format to identify the requesting iSNS
client and register or query for attribute values in the iSNS
server.
For iSNS response messages sent by the iSNS server to the client, a
4-byte ERROR CODE field is prepended to the MESSAGE PAYLOAD. This
field contains 0x0000 (NO ERROR) if the original iSNSP request
message was processed normally by the iSNS server. Error codes are
described in the following table:
Error Code Error Description
---------- -----------------
0 No Error
1 Unknown Error
2 Format Error
3 Invalid Registration
4 Scope Not Supported
5 Authentication Unknown
6 Authentication Absent
7 Authentication Failed
8 Entry Requested Not Found
9 Version Not Supported
10 Internal Bus Error
11 Busy Now
12 Option Not Understood
13 Invalid Update
14 Message Not Supported
15 Refresh Rejected
16 SCN Registration Rejected
17 Heartbeat Not Available
5.3 Message Authentication
iSNSP provides an optional message authentication capability.
Network interactions using iSNSP occur in short transactions, and
are generally not session based. The iSNS client connects to the
iSNS server only when information needs to be registered or
queried.
Public Key Encryption MAY be used for message authentication. If a
public key infrastructure is not available, a shared secret
algorithm MAY alternatively be used. A shared secret mechanism may
Gibbons, Tseng, Monia 19
iSNS January 2001
leverage a Kerberos server, or may involve manual distribution of a
private key to the iSNS server and each iSNS client.
If a PKI is available with an X.509 certificate authority, then
public key authentication of clients is possible. The
authentication block leverages the DSA with SHA-1 algorithm, which
can easily integrate into a public key infrastructure.
The SNSP optional authentication block is a digital signature for
the message. The authentication block contains the following
information:
1. A time stamp, to prevent replay attacks
2. A structured authenticator containing a signature calculated
over the time stamp and the message being secured
3. An indicator of the cryptographic algorithm that was used to
calculate the signature.
4. An indicator of the keying material and algorithm parameters,
used to calculate the signature.
The authentication block is described in the following figure:
Byte MSb LSb
Offset 7 6 5 4 3 2 1 0
+----------------------------------+
0 | BLOCK STRUCTURE DESCRIPTOR | 2 Bytes
+----------------------------------+
2 | AUTHENTICATION BLOCK LENGTH | 2 Bytes
+----------------------------------+
4 | TIMESTAMP | 4 Bytes
+----------------------------------+
8 | SPI STRING LENGTH | 1 Byte
+----------------------------------+
9 | SPI STRING | N Bytes
+----------------------------------+
9 + N | STRUCTURED AUTHENTICATOR | M Bytes
+----------------------------------+
Total Length = 9 + N + M
BLOCK STRUCTURE DESCRIPTOR (BSD) - Defines the structure and
algorithm to use for the STRUCTURED AUTHENTICATOR. Currently, the
only defined value for BSD is 0x0002, which represents DSA with
SHA-1. Details on DSA can be found in [DSS]. BSD values from
0x0000 to 0x7FFF are assigned by IANA, while 0x8000 to 0x8FFF are
for private use. The BSD value 0x0002 is compatible with the X.509
PKI specification, allowing easy integration of the STRUCTURED
AUTHENTICATOR format with an existing PKI infrastructure.
AUTHENTICATION BLOCK LENGTH - Defines the length of the
authentication block, beginning with the BSD field and running
through the last byte of the STRUCTURED AUTHENTICATOR.
Gibbons, Tseng, Monia 20
iSNS January 2001
TIMESTAMP - This is a 4-byte unsigned, fixed-point integer giving
the number of seconds since 00:00:00 GMT on January 1, 1970.
SPI STRING LENGTH - The length of the SPI STRING field.
SPI STRING (Security Parameters Index) - Index to the key and
algorithm used by the message recipient to decode the STRUCTURED
AUTHENTICATOR field.
STRUCTURED AUTHENTICATOR - Contains the digital signature. For the
default BSD value of 0x0002, this field contains the binary ASN.1
encoding of output values from the DSA with SHA-1 signature
calculation.
5.4 iSNS Attributes For Storage Systems
The iSNS provides the ability to register and provide information
for storage systems that support multiple protocols.
5.4.1 Attributes for iSCSI Storage Systems
The iSNS attributes used to represent iSCSI Storage Systems are
shown in the following figure:
- iSCSI NETWORK ENTITY
|
- Entity Type
| Indicates this is an iSCSI registration
- Entity Identifier
| By convention this is the DNS name of the
| Portal IP-Address(es). If it is not registered
| the iSNS will assign a unique alphanumeric
| identifier to it.
- Mgt IP-Address (Optional)
| If it is not registered then in-band management
| is assumed.
- Timestamp
| Timestamp of last registration update
- Heartbeat (Optional)
| If 0 no heartbeat is used
|
- PORTAL (1 - n per ENTITY)
| |
| - Index
| - IP-Address
| - TCP/UDP Port
| The IP-Addr and Port combined uniquely
| define a portal.
|
- STORAGE NODE (1 - m per ENTITY)
Gibbons, Tseng, Monia 21
iSNS January 2001
|
- WWUI (World-Wide Unique Identifier)
- Path
- Type (initiator / target / ...)
- Node Symbolic Name (Optional)
- Client Certificate (Optional)
- iSNS TCP/UDP Port (Optional)
5.4.2 Attributes for iFCP Storage Systems
The iSNS attributes used to represent iFCP Storage Systems are
shown in the following figure:
- iFCP NETWORK ENTITY
|
- Entity Type
| Indicates this is an iFCP registration
- Entity Identifier
| By convention this is the DNS name of the
| Portal IP-Address(es). If it is not registered
| the iSNS will assign a unique alphanumeric
| identifier to it.
- Mgt IP-Address (Optional)
| If it is not registered then in-band management
| is assumed.
- Timestamp
| Last registration update
- Heartbeat (Optional)
| If 0 no heartbeat is used
|
- PORTAL (1 - n per ENTITY)
| |
| - Index
| - IP-Address
| - TCP/UDP Port
| The IP-Addr and Port combined uniquely
| define a portal.
|
- NODE (1 - m per ENTITY)
|
- Node Name (WWNN)
- Type (initiator / target / ...)
- Node Symbolic Name (Optional)
- FC Node IP-Address (Optional)
- FC Node IPA (Optional)
- Client Certificate (Optional)
- iSNS TCP/UDP Port (Optional)
|
- PORT (1 - k per NODE)
|
- Port Name (WWPN)
Gibbons, Tseng, Monia 22
iSNS January 2001
- Port ID
- Port Type
- Port Symbolic Name (Optional)
- FC Hard Address (Optional)
- FC Fabric Port Name (FWWN)
- FC Class of Service
- FC Port IP Address
- FC FC-4 Types
- FC FC-4 Descriptor/Features
5.4.3 Attributes for FCIP Storage Systems
The iSNS attributes used to represent FCIP Storage Systems are
shown in the following figure:
- FCIP NETWORK ENTITY
|
- Entity Type
| Indicates this is an FCIP registration
- Entity Identifier
| By convention this is the DNS name of the
| Portal IP-Address(es). If it is not registered
| the iSNS will assign a unique alphanumeric
| identifier to it.
- Mgt IP-Address (Optional)
| If it is not registered then in-band management
| is assumed.
- Heartbeat (Optional)
| If 0 no heartbeat is used
- Timestamp
| Last registration update / heartbeat received
- PORTAL (1 - n per ENTITY)
|
- Index
- IP-Address
- TCP/UDP Port
The IP-Addr and Port combined uniquely
define a portal.
5.4.4 Attributes for Network Zone Registration
The iSNS attributes for Network Zone registration are shown in the
following figure:
NETWORK ZONE
|
- Zone ID
- Zone Symbolic Name
ZONE MEMBER
|
Gibbons, Tseng, Monia 23
iSNS January 2001
- Zone ID
- Entity Identifier, WWUI, WWNN, WWPN, IP-Address or FWWN
Members of a zone can be defined by registering one of the
following storage entity attributes in a zone:
- Entity Identifier: this places all contained iSCSI or
iFCP storage nodes, or FCIP gateways,
in the zone
- WWUI : this places the individual iSCSI
storage node in the zone
- WWNN : this places all associated iFCP
ports in the zone
- WWPN : this places the associated iFCP
port in the zone
- FWWN : this places all iFCP ports
attached to the Fabric Port in
the zone
- IP-Address : this places all associated iSCSI storage
nodes or FCIP storage entities in the
zone
Network Zoning partitions groups of initiators and targets into
more manageable "Discovery Domains" in order to limit the login
process to the appropriate subset of devices registered in the
iSNS. Network Zoning is described in Section 3.1.2.
5.5 iSNS Client Registration Attributes
When an iSNS client registers with the iSNS server, it provides
attribute values to describe the entity characteristics and
capabilities. The attributes are also returned by the iSNS server
in response to queries.
The following table lists all iSNSP message attributes for device
registration and queries:
Gibbons, Tseng, Monia 24
iSNS January 2001
Attribute Name Size(bytes) Tag Reg Key Query Keys
-------------- ----------- --- ------- ----------
Entity Identifier 1-255 1 1 1,3,17&18,32,34,64
Entity Type 2 2 1 1,3,17&18,32,34,64
Management IP Address 16 3 1 1,3,17&18,32,34,64
Entity Reg Timestamp 8 4 1 1,3,17&18,32,34,64
Entity Heartbeat 2 5 1 1,3,17&18,32,34,64
Portal Index 2 16 1 1,1&16,17&18
Portal IP Address 16 17 1 or 1,16 1,1&16,17&18
Portal TCP/UDP Port 2 18 1 or 1,16 1,1&16,17&18
WWUI TBD 32 1 1,32,1&33
Path 0-255 33 32 32,1&33
Node Name (WWNN) 8 34 1 1,34,64
Node Type 2 35 32 or 34 32,1&33,34,64
Node Symbolic Name 0-255 36 32 or 34 32,1&33,34,64
FC Node IP Address 16 37 34 34,64
FC Node IPA 8 38 34 34,64
Client Certificate variable 39 32 or 34 32,1&33,34,64
iSNS TCP/UDP Port 2 40 32 or 34 32,1&33,34,64
Port Name (WWPN) 8 64 34 1,34,66,68,71,72
Port ID 4 65 64 64,17&18&65
Port Type 2 66 64 64,17&18&65
Port Symbolic Name 0-255 67 64 64,17&18&65
Fabric Port Name (FWWN) 8 68 64 64,17&18&65
FC Hard Address 4 69 64 64,17&18&65
FC Port IP Address 16 70 64 64,17&18&65
FC Class of Service 4 71 64 64,17&18&65
FC FC-4 Types 32 72 64 64,17&18&65
FC FC-4 Descriptor 0-255 73 64 64,17&18&65
FC FC-4 Features 128 74 64 64,17&18&65
Domain ID 2 75 1 1,75
The following is a description of the columns used in the above
table:
Size - indicates the attribute length. Variable-length identifiers
are NULL character terminated, which is included in the length.
Tag - the value used to identify the attribute. All undefined tag
values are reserved.
Reg Key - indicates the attribute ID(s) that is (are) the unique
key used for attribute registration. This attribute is also known
as the primary key for the iSNS directory database entry.
Query Keys - indicates the attribute IDs that can be used to query
the iSNS directory database.
iSNS client attributes are defined below.
5.5.1 Entity Identifier (DNS Name) Attribute
Gibbons, Tseng, Monia 25
iSNS January 2001
The Entity Identifier is a variable length identifier that uniquely
identifies an entity registered in the iSNS. The attribute length
varies from 1 to 255 bytes, and is a unique value within the iSNS.
By convention the Entity Identifier is the DNS Name used by the
entity. The Entity Identifier along with the Path can be used to
uniquely identify and address any associated STORAGE NODE.
If the iSNS client does not provide an Entity Identifier during
registration, the iSNS shall generate one that is unique within the
iSNS. The Entity Identifier is described in further detail in
section 3.3.4.
5.5.2 Entity Type
Entity Type is a 2-byte field that indicates the type of network
entity that is being registered and is provided by the iSNS client.
The valid types are defined as below.
Type Value Entity Type
---------_ -----------
1 iSCSI
2 iFCP
3 FCIP
All Others RESERVED
5.5.3 Management IP Address
This optional field is provided by the iSNS client. It contains
the IP Address used to manage the entity. The Management IP
Address is a 16-byte field that may contain either a 32-bit IPv4 or
128-bit IPv6 address. When this field contains an IPv4 value, the
most significant 12 bytes are set to 0x00. If the network entity
is capable of being managed and this field is not set, then in-band
management is assumed.
5.5.4 Entity Registration Timestamp
Indicates the time the most recent entity registration update
occurred. It is the time, in milliseconds, after the standard base
time of 00:00:00 GMT on January 1, 1970, that the last update
occurred. The timestamp can be used to ensure the SNS directory
does not contain entries for non-existent port devices.
5.5.5 Entity Heartbeat
This optional field is provided by the iSNS client. It indicates
the minimum time, in seconds, between entity status inquiry
messages sent from the iSNS to a client. Entity status inquiry
messages can be used to verify that a client registration continues
Gibbons, Tseng, Monia 26
iSNS January 2001
to be valid. To request monitoring by the iSNS heartbeat, an iSNS
client registers a non-zero value for this attribute using a
RegDevAttr message. If the value is 0 then entity status messages
SHALL not be sent.
If the iSNS is unable to issue additional entity status inquiry
messages, it SHALL reject the heartbeat request by returning a
"Heartbeat Not Available" error code. The rejection might occur in
situations where the resulting frequency of entity status inquiry
messages being issued to clients would pass an implementation-
specific threshold. If the registration is part of a multi-
attribute RegDevAttr message and the registration is rejected with
_Heartbeat Not Available_, then the multi-attribute registration
SHALL be resent with an Entity Heartbeat value of 0.
5.5.6 Portal Index
The Portal Index is an integer value that uniquely identifies a
portal associated with a NETWORK ENTITY.
If the iSNS client does not provide a Portal Index during Portal IP
Address and Portal TCP/UDP Port registration, the iSNS shall
generate one that is unique within the entity.
5.5.7 Portal IP Address
The IP address of the PORTAL through which a STORAGE NODE can
transmit and receive storage data. This required field is provided
by the iSNS client. When an IPv4 value is contained in this field,
the most significant 12 bytes are set to 0x00. The Portal IP
Address along with the Portal TCP/UDP Port number uniquely
identifies a Network Entity Portal. This attribute is further
described in section 3.3.3.
5.5.8 Portal TCP/UDP Port
The TCP/UDP port of the PORTAL through which a STORAGE NODE can
transmit and receive storage data. This required field is provided
by the iSNS client. If the value is 0, then the port number is the
implied canonical port number of the protocol being used. The
Portal IP Address along with the Portal TCP/UDP Port number
uniquely identifies a Network Entity Portal. This attribute is
further described in section 3.3.3.
5.5.9 World Wide Unique Identifier (WWUI)
This identifier uniquely defines an iSCSI STORAGE NODE. This field
is required for iSCSI STORAGE NODEs, and is provided by the iSNS
client. This attribute is further described in section 3.3.2.
5.5.10 Path
Gibbons, Tseng, Monia 27
iSNS January 2001
The iSNS client provides this optional field. Along with the Entity
Identifier, the Path uniquely identifies and addresses a STORAGE
ENTITY. The Path distinguishes among multiple IP-based storage
entities that may reside at the same IP address. Note that the
Path is used only with native IP-based storage devices, and native
Fibre Channel devices do not need a Path. This is a variable-length
text-based value from 0 to 255 bytes. The text field contains
user-readable ASCII text, and is terminated with at least one NULL
character. The Path field is similar to that of the UNIX file
format. This attribute is further described in section 3.3.4.
5.4.11 Node Name (WWNN)
Node Name is a 64-bit identifier that uniquely identifies the iFCP
device node in the network. This field is provided by the iFCP-
based iSNS client entity. The format of the Node Name (WWNN) is as
defined in section 3.3.1.
5.5.12 Node Type
This 16-bit field is a bitmap indicating the type of STORAGE NODE.
The fields are defined as below. An enabled bit indicates the node
has the corresponding characteristics.
Bit Field Node Type
--------- ---------
0 (Lsb) Target
1 Initiator
All Others RESERVED
This field will be consistent with the FC-4 Feature bits described
in [FC-GS-3] if the node represents a Fibre Channel device. The
default value for this field is 0x0000, which is "unknown".
5.5.13 Node Symbolic Name
This is a variable-length text-based description of up to 255
bytes, that is associated with the device node in the network. The
text field contains user-readable ASCII text and is terminated with
at least one NULL character. This optional field is normally
provided by the iSNS client during registration. However, a
network management application can update this field as required.
The Node Symbolic Name provides a user-readable description of the
device entry in the iSNS. The Node Symbolic Name is available for
use by both Fibre Channel and iSCSI clients.
5.5.14 FC Node IP Address
This optional IP address is associated with the device node in the
network. This field is included for compatibility with Fibre
Gibbons, Tseng, Monia 28
iSNS January 2001
Channel. When an IPv4 value is contained in this field, the most
significant 12 bytes are set to 0x00. This value is provided by
the iSNS client.
5.5.15 FC Node IPA
This optional 8 byte Fibre Channel Initial Process Associator (IPA)
is associated with the device node in the network. This field is
included for compatibility with Fibre Channel, and is provided by a
Fibre Channel-based iSNS client entity. The initial process
associator can be used for communication between Fibre Channel
devices.
5.5.16 Client Certificate
This optional attribute MAY contain a X.509 certificate with the
public key of the iSNS client. This certificate is uploaded and
registered to the iSNS by clients wishing to allow other clients to
authenticate them. Targets wishing to allow access by
authenticated initiators MAY retrieve the X.509 certificate of
those specified initiators from the name server, in order to
authenticate the identity of those initiators prior to
establishment of active communication sessions with them.
5.5.17 iSNS TCP/UDP Port
Contains the TCP or UDP port number being used for communication
with the iSNS server by the iSNS client. If the value is 0, then
the port number is the implied canonical port number of the
protocol being used.
5.5.18 Port Name (WWPN)
This 64-bit identifier uniquely defines the iFCP device port. This
field is provided by a Fibre Channel-based iSNS client entity. The
format of the Port Name (WWPN) is further defined in section 3.3.1.
5.5.19 Port ID
Along with the IP Address, this field uniquely identifies a native
Fibre Channel device port in the network, and maps one-to-one to a
specific Port Name (WWPN) entry. The Port ID is used for iFCP
based storage devices.
5.5.20 Port Type
Indicates the type of iFCP device port. This is provided by the
iSNS client entity. Encoded values for this field are listed in
the following table:
Gibbons, Tseng, Monia 29
iSNS January 2001
Type Description
---- -----------
0x0000 Unidentified/Null Entry
0x0001 Fibre Channel N_Port
0x0002 Fibre Channel NL_Port
0x0003 Fibre Channel F/NL_Port
0x0004-0080 RESERVED
0x0081 Fibre Channel F_Port
0x0082 Fibre Channel FL_Port
0x0083 RESERVED
0x0084 Fibre Channel E_Port
0x0085-00FF RESERVED
0xFF11 mFCP Port
0xFF12 iFCP Port
0xFF13-FFFF RESERVED
5.5.21 Port Symbolic Name
A variable-length text-based description of up to 255 bytes, that
is associated with the iSNS-registered device port in the network.
The text field contains user-readable ASCII text and is terminated
with at least one NULL character. This optional field is normally
provided by the iSNS client during registration. However, network
management application can update this field as required.
5.5.22 Fabric Port Name (FWWN)
This 64-bit identifier uniquely defines the fabric port. If the
iSNS client is attached to a Fibre Channel fabric port with a
registered Port Name, then that fabric Port Name shall be indicated
in this field. This field is included in the iSNSP for
compatibility with Fibre Channel fabric devices and topologies.
5.5.23 FC Hard Address
This optional is the requested hard address 24-bit NL Port
Identifier, included in the iSNSP for compatibility with Fibre
Channel Arbitrated Loop devices and topologies.
5.5.24 FC Port IP Address
The IP address associated with the device port in the network.
This optional field is included for compatibility with Fibre
Channel. When an IPv4 value is contained in this field, the most
significant 12 bytes are set to 0x00. This value is provided by
the iSNS client.
5.5.25 FC Class of Service (COS)
This 32-bit bit-map field indicates the FC COS types that are
supported by the registered port. This field is provided by the
Gibbons, Tseng, Monia 30
iSNS January 2001
Fibre Channel-based iSNS client. The COS values are equivalent to
Fibre Channel COS values. The valid COS types, and associated bit-
map, are listed in the following table:
Class of Service Description Bit-Map
---------------- ----------- ---------
2 Delivery Confirmation Provided bit 2 set
3 Delivery Confirmation Not Provided bit 3 set
RESERVED other
5.5.26 FC FC-4 Types
This 32-byte field indicates the FC-4 protocol types supported by
the associated port. This required field for iFCP ports is
provided by the iSNS client. This field can be used to support
Fibre Channel devices.
5.5.27 FC FC-4 Descriptor
A variable-length text-based description of up to 255 bytes, that
is associated with the iSNS-registered device port in the network.
This optional field for iFCP ports is provided by the iSNS client.
This field can be used to support Fibre Channel devices.
5.5.28 FC FC-4 Features
This is a 128-byte array, 4 bits per type, for the FC-4 protocol
types supported by the associated port. This optional field for
iFCP ports is provided by the iSNS client. This field can be used
to support Fibre Channel devices.
5.5.29 Domain ID
This is a 2-byte field, with a valid value range of 1 _ 239. This
optional field is for iFCP Transparent Mode. When in iFCP
Transparent Mode, the Request Domain ID message SHALL be used by an
iFCP gateway to reserve an available Domain ID for use. When a
Domain ID is no longer required, it SHALL be released by the iFCP
gateway using the Release Domain ID message. The iSNS MAY use the
Port Status Inquiry message to determine if an iFCP gateway is
still present on the network.
5.6 Zone Registration Attributes
iSNS clients can be placed into zoned areas of control. When an
iSNS client or Network Management System registers a zone, it
provides attribute values to describe the zone characteristics and
capabilities. The following table lists the iSNSP zone attributes:
Gibbons, Tseng, Monia 31
iSNS January 2001
Attribute Name Size(bytes) ID Reg Key Query Key
-------------- ----------- -- ------- ---------
Zone ID 2 101 101
Zone Symbolic Name 1-64 102 101 101
Zone Member (WWUI) TBD 104 101 101
Zone Member (WWPN) 8 105 101 101
Zone Member (WWNN) 8 106 101 101
Zone Member (FWWN) 8 107 101 101
Zone Member (IP Addr) 16 108 101 101
Zone ID - a unique identifier used in the iSNS directory database
to indicate the zone. This value is used as the key for any zone
attribute query. If the iSNS client does not provide a Zone ID in a
Zone registration request message, the iSNS shall generate a Zone
ID value that is unique within the iSNS database for that new Zone
(i.e., the iSNS client will be registered in a new Zone).
Zone Symbolic Name - an ASCII, variable-length string that is
NULL-terminated. This is an optional user-readable field used to
assist a network administrator in tracking the zone function. When
registered by a client, the zone symbolic name SHALL be verified
unique by the iSNS. If the zone symbolic name is not unique, then
the zone registration SHALL be rejected with an _Invalid
Registration_ error code. The invalid attribute(s), in this case
the zone symbolic name, SHALL be included in the response.
Zone Member (WWUI) - the World Wide Unique Identifier of an iSNS
client that is a member of the zone. The zone may have a list of 0
to n members. Membership is represented by the WWUI of the iSNS
client being listed.
Zone Member (WWPN) - the Port Name of an iSNS client that is a
member of the zone. The zone may have a list of 0 to n members.
Membership is represented by the Port Name (WWPN) of the iSNS
client being listed.
Zone Member (WWNN) - the Node Name of an iSNS client that is a
member of the zone. The zone may have a list of 0 to n members.
Membership is represented by the Node Name (WWNN) of the iSNS
client being listed.
Zone Member (FWWN) - the Fabric World Wide Name of an iSNS client
that is a member of the zone. The zone may have a list of 0 to n
members. Membership is represented by the FWWN of the iSNS client
being listed.
Zone Member (IP Addr) - the IP address of an iSNS client that is a
member of the zone. The zone may have a list of 0 to n members.
This IP address indicates that all storage entities using this IP
address are members of the zone.
Gibbons, Tseng, Monia 32
iSNS January 2001
5.7 State Change Notification and Port Status Inquiry Flags
A State Change Notification (SCN) allows an iSNS client to be
notified of changes within a zone, network, or existing device
attribute values in the iSNS directory database. An iSNS client
registers for SCN's using the SCN Registration Request command.
The SCN message is sent to the iSNS client by the iSNS server.
The types of changes for which SCNs are sent is based on flags set
in the EVENT TYPE FLAGS field. The EVENT TYPE FLAGS field is a 16-
bit mask containing flags for different event types.
Port Status Inquiry (PSI) allows an iSNS server to verify that an
iSNS client entity is still connected to the network. The PSI
message is sent to the iSNS client by the server to verify port
status. If enabled, the iSNS server will send a PSI to request a
Port Status Inquiry Update message from the SCE.
The following table displays the flags in the EVENT TYPE FLAGS
field used in SCNReg, SCN and PSI messages:
Bit Field Flag Description
--------- ----------------
0 CHANGE IN ZONE MEMBERSHIP
1 CHANGE IN NETWORK
2 CHANGE IN DEVICE REGISTRATION PARAMETERS
3 DEVICE ADDED
4 DEVICE REMOVED
5 PORT STATUS UPDATE REQUESTED (for PSI message)
CHANGE IN ZONE MEMBERSHIP - indicates a change has occurred in a
zone that the iSNS client is a member of. A client can be a member
of multiple zones. This flag indicates that a change in
registration parameters or membership has occured, either an
addition or deletion, to a zone that the client is a member of.
CHANGE IN NETWORK - indicates a change in the network has occurred.
The change may be anywhere in the network of devices. This flag is
administratively controlled, and may not be allowed by the iSNS
server except for use by an IP address associated with a Network
Management Station.
CHANGE TO DEVICE REGISTRATION PARAMETERS - indicates a change in a
device registration in the network or zones that the client is a
member of. This flag is used in conjunction with CHANGE IN ZONE
MEMBERSHIP and CHANGE IN NETWORK flags indicate whether the change
in device registration occurred in a zone or the network. This
flag may be administratively enabled/disabled.
DEVICE ADDED - indicates a device addition has occurred in the
network or zone. This flag is used in conjunction with CHANGE IN
Gibbons, Tseng, Monia 33
iSNS January 2001
ZONE MEMBERSHIP and CHANGE IN NETWORK flags indicate whether the
addition occurred in a zone or the network.
DEVICE REMOVED - indicates a device removal has occurred in the
network or zone. This flag is used in conjunction with CHANGE IN
ZONE MEMBERSHIP and CHANGE IN NETWORK flags indicate whether the
removal occurred in a zone or the network.
6. iSNSP Message Descriptions
The message payload follows the iSNSP header described in section
5.1. The request message payload contains a list of attributes,
each in TLV format described in section 5.2.
The iSNSP request message payload contains a list of attributes,
and has the following format:
+----------------------------------------+
| Source Attribute |
+----------------------------------------+
| Key Attribute[1] |
+----------------------------------------+
| Key Attribute[2] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
| Op Attribute[1] |
+----------------------------------------+
| Op Attribute[2] (if present) |
+----------------------------------------+
| Op Attribute[3] (if present) |
+----------------------------------------+
| . . . |
+----------------------------------------+
The source attribute is used to identify the iSNS client to the
iSNS server. The key attribute is used to identify the entry (or
entries) in the iSNS server for the request operation. Following
the key attribute is a list of one or more operating attributes
directly related to the actual iSNS request message. The number of
each attribute (key & operating) depends on the specific iSNSP
request or operation being performed. Some iSNSP messages may not
specify any attributes.
The response message contains a 4-byte ERROR CODE field, and
depending on the specific iSNSP request, may be followed by a list
of attributes.
The following table lists each iSNSP message, allowable source
attribute ID's, key attribute ID's, and operating attribute ID's.
Gibbons, Tseng, Monia 34
iSNS January 2001
Message Source/Dest Attr Key Attribute Operating Attr
------- ---------------- ------------- --------------
RegDevAttr 1,32,64 1,16,32,34,64 multiple[1-74]
RegDevRsp -- -- --
DevAttrQry 32,64 1,3,17&18,32, multiple[1-74]
34,64,1&16,
1&33
DevAttrQryRsp -- -- multiple[1-74]
DevGetNext 32,64 1,16,32,64 --
DevGetNextRsp -- -- multiple[1-74]
DeregDev 32,64 1,16,32,64 --
DeregDevRsp -- -- --
SCNReg 32,64 -- --
SCNRegRsp -- -- --
SCN 32,64 (dest) -- --
RegZone 32,64 (dest) 101 multiple[101-106]
RegZoneRsp -- -- --
DeregZone 32,64 101 --
DeregZoneRsp -- -- --
RegDevZone 32,64 104-108 --
RegDevZoneRsp -- -- --
DeregDevZone 32,64 104-108 --
DeregDevZoneRsp -- -- --
PSI 32,64 (dest) -- --
PSIUpdate 32,64 -- --
Heartbeat -- -- --
RqstDmnId 1 -- --
RqstDmnIdRsp -- -- --
RlseDmnId 1,75 -- --
RlseDmnIdRsp -- -- --
The above table lists attribute ID's from section 5.5 that can be
used for each role (source, key, and operating attribute) in the
iSNSP message. The source attribute is that of the iSNS client,
used in the registration or query message. The key attribute is
the attribute used to look up the operating attribute in the iSNS
directory database. The operating attribute(s) is the attribute(s)
in the iSNS directory database which is to be added, modified,
deleted, or queried.
If more than one operating attribute can be used, "multiple" is
noted in the entry. A "--" entry indicates that the iSNSP message
does not use the attribute role (source/dest, key, or operating
attribute). Note that the SCN and PSI messages specify the
destination attribute in place of the source attribute.
6.1 Register Device Attribute Request (RegDevAttr)
The Register Device Attribute Request (RegDevAttr) message provides
an iSNS client with the means to register device attributes. The
iSNS client formulates a register attribute request by specifying a
Gibbons, Tseng, Monia 35
iSNS January 2001
source, query key(s), and list of attributes to register. All
values are in Tag Length Value format.
The source attribute of the request is the IP address or the 8-byte
Port Name (WWPN) of the iSNS client performing the query. The key
attribute(s) is based on the type of attributes being registered,
and is the IP Address, DNS Name & Path, Node Name (WWNN), or Port
Name (WWPN) of the client being registered. If the key attribute
matches an existing entry in the iSNS directory database, then the
new attribute values corresponding in the registration request
SHALL be added to existing values corresponding to the key entry.
Multiple attributes associated with the one database key attribute
can be registered.
The source attribute does not need to have been previously
registered for the registration to succeed. The use of a Port Name
(WWPN) as source does not automatically register it in the
database--it is registered by including the attribute as part of a
registration using a Node Name (WWNN) as a key. However, a Node
Name (WWNN) is registered the first time it is used as a key, so it
does not necessarily have to be listed among the attributes to be
registered.
The RegDevAttr request message payload includes the source
attribute (IP Address, Node Name, or Port Name), the key attribute
(IP Address, DNS Name & Path, Node Name or Port Name), and one or
more operating attributes.
6.2 Register Device Attribute Response (DevAttrRsp)
If device attributes are successfully addded to the iSNS directory
database as a result of DevAttrReg, then an acknowledgement with an
error code of NO ERROR (0) is returned to the iSNS client. If the
registration request is unsuccessful, the appropriate error code
will be returned.
6.3 Device Attribute Query Request (DevAttrQry)
Once iSNS client attributes have been registered in the name
service, queries can be made to obtain attributes related to a
specific key. The Device Attribute Query Request (DevAttrQry)
messages provide an iSNS client with the means to query the iSNS
server for device attributes.
The key attribute for the DevAttrQry is Node Name (WWNN), Port Name
(WWPN), or a key set consisting of DNS Name and Path. The
attribute list contains desired attributes. The length field for
each requested attribute shall be of length 0.
Gibbons, Tseng, Monia 36
iSNS January 2001
The iSNS server uses the key in the request message to query its
database, and then returns the corresponding entry or entries for
each requested attribute back to the client.
The DevAttrQry request message payload includes the source
attribute (IP Address or Port Name), the key attribute(s), and one
or more operating attributes.
6.4 Device Attribute Query Response (DevAttrQryRsp)
The iSNS server uses the DevAttrQryRsp message to send back the
attribute query results back to the iSNS client. A successful
query will result in attribute values and length fields in the
original TLV-formatted DevAttrQry request to be appropriately
filled in. A failed query as a result of an inappropriate source
and/or key attribute(s) will result in the message payload being
replaced with the 4-byte ERROR CODE field. If there is no entry
for queried attributes, the TLV-formatted attribute block will be
returned with the length field set to 0 or a negative value error
code.
In addition to the ERROR CODE field, the DevAttrQryRsp message
contains a list of operating attributes corresponding to the
original request message. The attribute values resulting from the
query are represented in the TLV format described in section 5.2.
6.5 Device Get Next Request (DevGetNext)
This message provides the iSNS client with the means to
sequentially retrieve IP Addresses, DNS Name & Paths, Node Names
and Port Names from devices in zones to which the client has
access. The source of the query is represented by the IP Address
or 8-byte Port Name (WWPN) of the client performing the query. The
key tag is the IP Address, DNS Name & Path, Node Name (WWNN), or
Port Name (WWPN). If the key length value entered is zero,
signifying an empty key value field, the first accessible IP
Address, DNS Name, Node Name, or Port Name instance shall be
returned to the client.
The DevGetNext request message payload contains a source attribute
(IP Address or Port Name) and a key attribute (IP Address, DNS Name
& Path, Node Name or Port Name).
6.6 Device Get Next Response (DevGetNextRsp)
The iSNS server uses the DevGetNextRsp to return the results of the
DevGetNext request message. If the DevGetNext query does not
identify an IP Address, DNS Name & Path, Node Name, or Port Name
following the key provided in the query, and the query completed
properly, the attribute value length field is set to zero.
Gibbons, Tseng, Monia 37
iSNS January 2001
The DevGetNextRsp response message payload returns the queried
attribute resulting from the original DevGetNext request (IP
Address, DNS Name & Path, Node Name, or Port Name).
6.7 Deregister Device Request (DeregDev)
An iSNS client port or device is removed from the iSNS directory
database by using the Deregister Device Request (DeregDev). Upon
receiving the DeregDev, the iSNS server removes all attributes
associated with the IP Address, DNS Name & Path, Node Name (WWNN)
or Port Name (WWPN) key, and sends state change notifications
(SCNs) to registered iSNS clients that are in the same Zone as the
removed device or port. After removing the port or device, the
iSNS server sends back an acknowledgement to the iSNS client.
The DeregDev request message payload contains a single source
attribute (IP Address or Port Name) and key attributes (IP Address,
DNS Name & Path, Node Name or Port Name).
6.8 Deregister Device Response (DeregDevRsp)
If device attributes are successfully removed from the iSNS
directory database as a result of a Deregister Device Request
(DeregDev), the DeregDevRsp message with error code of NO ERROR(0)
is returned to the original iSNS client. The DeregDevRsp response
message payload does not contain any attributes.
6.9 SCN Registration Request (SCNReg)
The State Change Notification Registration Request (SCNReg) message
allows an iSNS client to register an IP Address or Port Name (WWPN)
for State Change Notification (SCN) messages. SCN messages allow
an iSNS client to be notified of changes within the zone or network
(if administratively allowed) that the device port is a member of.
In place of the attribute list for other iSNSP message types, the
SCNReg has the 16-bit INTERESTED EVENT TYPE FLAGS field described
in section 5.5, which comes immediately after the key attribute.
The following displays the format of the SCNReg message payload:
Byte MSb LSb
Offset 7 6 5 4 3 2 1 0
+----------------------------------+
0 | source attribute | 12 Bytes
+----------------------------------+
12 | key attribute | 12 Bytes
+----------------------------------+
24 | EVENT TYPE FLAGS | 2 Bytes
+----------------------------------+
Total Length = 26
Gibbons, Tseng, Monia 38
iSNS January 2001
Section 5.5 describes each flag used in the EVENT TYPE FLAGS field.
6.10 SCN Registration Response (SCNRegRsp)
If the iSNS client successfully registered for state change
notifications, an acknowledgement with the ERROR CODE field set to
NO ERROR(0) is returned to the client. This message does not
contain any attributes.
6.11 State Change Notification (SCN)
The State Change Notification is a special message which allows a
registered iSNS client to be notified of changes within a zone,
network (if administratively allowed), or other device registration
parameters in the iSNS directory database. The notification is
indicated in the EVENT TYPE FLAGS field described in section 5.5.
A time stamp is included in this message following the EVENT TYPE
FLAGS field. This time stamp is a 4-byte unsigned, fixed-point
integer giving the number of seconds since 00:00:00 GMT on January
1, 1970. The format of the message payload of the SCN message is
as follows:
Byte MSb LSb
Offset 7 6 5 4 3 2 1 0
+----------------------------------+
0 | destination attribute | M Bytes
+----------------------------------+
M | source attribute | N Bytes
+----------------------------------+
N+M | EVENT TYPE FLAGS | 2 Bytes
+----------------------------------+
N+M+2 | TIME STAMP | 4 Bytes
+----------------------------------+
Total Length = N+M+6
Destination attribute contains the IP Address, Node Name, Port_Name
or WWUI in TLV format of the iSNS client to receive the SCN
message.
Source attribute contains the IP Address, Node Name, Port Name, or
WWUI in TLV format of the iSNS client that instigated the SCN
message.
*Editor's Note: Format of the response message to the SCN is TBD.
6.12 Register Zone (RegZone)
This message allows an iSNS client to create a new Zone to be
stored in the iSNS directory database. Once created, devices
identified by IP Address, WWNN, WWPN, or WWUI can be added and
deleted from the Zone.
Gibbons, Tseng, Monia 39
iSNS January 2001
Zones are defined using Zone IDs, Zone tags, and Symbolic Names.
Zone registration attributes are described in section 5.5.
The RegZone message payload contains the source attribute (IP
Address or Port Name), key attribute (Zone ID), and one or more
Zone attributes (Zone Tag, Zone Symbolic Name, Zone Member [IP
Address, WWNN, WWPN, or WWUI]).
6.13 Register Zone Response (RegZoneRsp)
The Register Zone Response (RegZoneRsp) message is used by the iSNS
server to acknowledge a RegZone message. If a Zone is successfully
created with the requested attributes, the RegZoneRsp is returned
to the client with an ERROR CODE of NO ERROR(0). The message
payload contains no attributes.
6.14 Deregister Zone (DeregZone)
This message allows an iSNS client to delete an existing Zone from
the iSNS directory database. A zone with non-zero membership
cannot be deleted. The DeregZone message payload contains the
source attribute (IP Address, Node Name, Port Name, or WWUI) and
key attribute (Zone ID).
6.15 Deregister Zone Response (DeregZoneRsp)
This message is used by the iSNS server to acknowledge a DeregZone
request. If the zone was successfully deregistered, an
acknowledgement is sent with an ERROR CODE of NO ERROR(0). The
DeregZoneRsp message payload does not contain any attributes.
6.16 Register Device in Zone (RegDevZone)
Devices can be added to a zone by registering the port names of the
devices. Adding an IP Address, Node Name (WWNN), Port Name (WWPN),
or WWUI to the zone provides access to all other devices in the
zone.
The RegDevZone message payload contains the source attribute (IP
Address or Port Name), key attribute (Zone ID), and one or more
Zone attributes (Zone Tag, Zone Symbolic Name, Zone Member [IP
Address, Node Name, Port_Name or WWUI]).
If a NULL value is contained in the Zone_ID key attribute, then the
iSNS SHALL create a new Zone with a unique Zone_ID, and register
the specified Zone Member in that Zone.
6.17 Register Device in Zone Response (RegDevZoneRsp)
Gibbons, Tseng, Monia 40
iSNS January 2001
This message provides confirmation that the RegDevZone message was
received and processed by the iSNS server. If the device was
successfully registered in the zone, an acknowledgement is sent
with an ERROR CODE of NO ERROR(0). The RegDevZoneRsp message
payload contains the Zone_ID of the Zone receiving the Zone Member.
6.18 Deregister Device in Zone (DeregDevZone)
Devices can be removed from a Zone by deleting their IP Address or
Port Names (WWPN) from the Zone. Deleting devices from a zone
removes access to that device from all other devices in that Zone.
The DeregDevZone request message payload contains the source
attribute (IP Address or Port Name), key attribute (Zone ID), and
the operating attribute (IP Address, Node Name, Port Name, or WWUI)
of the device being deregistered.
6.19 Deregister Device in Zone Response (DeregDevZoneRsp)
This message provides confirmation that the DeregDevZone message
was received and processed by the iSNS server. If the device was
successfully deregistered from the zone, an acknowledgement is sent
with an ERROR CODE of NO ERROR(0). The DeregDevZoneRsp message
payload does not contain any attributes.
6.20 Port Status Inquiry (PSI)
The Port Status Inquiry (PSI) message provides the iSNS server with
the ability to verify that a registered iSNS client is still
accessible. The format of the PSI is similar to the SCN message,
and uses the same EVENT TYPE FLAGS field. The types of events and
flags are listed in section 5.5.
The PSI request message payload contains the attribute (IP Address
or Port Name) of the device being inquired for status.
6.21 Port Status Inquiry Update (PSIUpdate)
This message provides confirmation that the PSI message was
received and processed by the iSNS client. If the client is still
accessible by the iSNS server, then it will respond and confirm
accessibility through the PSIUpdate message.
The PSIUpdate response message payload contains the source
attribute (IP Address or Port Name) of the responding device.
6.22 Name Service Heartbeat (Heartbeat)
The iSNS server sends out a multicast heartbeat message. The
heartbeat can be used by iSNS clients to verify connectivity, as
well as to discover the iSNS server. The period of the heartbeat
Gibbons, Tseng, Monia 41
iSNS January 2001
is included in the message, with default period of 15 seconds.
There is no response to the Heartbeat message.
7. Security Considerations
7.1 Data Integrity and Authentication
Data integrity and authentication requirements for communication
between iSNS clients and server can be achieved through use of the
authentication block.
7.2 Security Model
The iSNS server will leverage existing security mechanisms
currently used to secure resources such as DNS servers, e-mail
relays servers, and other sensitive and otherwise vulnerable
network resources. Existing firewalls with stateful inspection
technology can examine incoming traffic from the Public Internet,
and protect against active attacks.
8. References
[RFC1035] Domain Implementation and Specification
[STD0035] Domain Name System
[RFC2065] Domain Name System Security Extensions
[FC-GS-2] Fibre Channel Generic Services-2, ANSI NCITS 288
[FC-GS-3] Fibre Channel Generic Services-3, NCITS Working
Draft Rev 7.01, November 28, 2000
[RFC2609] Service Templates and Service
[IEEE802.1Q] Standard for Virtual Bridged Local Area Networks
[RFC1510] The Kerberos Network Authentication Service
[DSS] FIPS PUB 186-2, National Institute of Standards and
Technology, Digital Signature Standard(DSS),
Technical Report
[802-1990] ANSI/IEEE Std 802-1990, Name: IEEE Standards for
Local and Metropolitan Area Networks: Overview and
Architecture
[SPC] SCSI-3 Primary Commands, ANSI NCITS 995D, Revision
11a
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
Gibbons, Tseng, Monia 42
iSNS January 2001
9. Author's Addresses
Josh Tseng
Kevin Gibbons
Charles Monia
Nishan Systems
3850 North First Street
San Jose, CA 95134-1702
Phone: (408) 519-3749
Email: jtseng@nishansystems.com
Franco Travostino
Nortel Networks
3 Federal Street
Billerica, MA 01821
Phone: 978-288-7708
Email: travos@nortelnetworks.com
Murali Rajagopal
LightSand Communications
375 Los Coches St.
Milpitas, CA 95035
Phone: (408) 404-3164
Mark Bakke
Cisco Systems
6450 Wedgewood Road
Maple Grove, MN 55311
Phone: 763-398-1054
Email: mbakke@cisco.com
Jim Hafner
IBM Research
Almaden Research Center K53-B2
650 Harry Road
San Jose, CA 95120-6099
Email: hafner@almaden.ibm.com
Phone: 408-927-1892
Howard Hall
Pirus Networks
43 Nagog Park
Acton, MA 01720
Email: howard@pirus.com
Phone: 978-206-9103
Gibbons, Tseng, Monia 43
iSNS January 2001
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
| PAFTECH AB 2003-2026 | 2026-04-19 19:45:26 |