[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-tseng-ips-isns) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 RFC 4171

    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."


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/