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

Versions: 00 01

    Internet Draft                                        K. Gibbons
    <draft-tseng-ips-isns-01.txt>                           J. Tseng
    Expires April 2001                                      C. Monia
                                                      Nishan Systems

                                                        October 2000


                  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.

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.  iSNS
    integrates Fibre Channel name server and DNS mechanisms into a
    common naming and resource-discovery framework.  The iSNS Protocol
    (iSNSP) defines how entities communicate with the iSNS server to
    discover and utilize available networked storage resources.  The
    iSNS server MAY be supported by a consolidated iSNS directory
    database, which serves as a repository to store information about
    various storage resources, providing easy access to topology
    information for storage entities.

2.       Conventions used in this document

    iSNS refers to the framework consisting of the storage network
    model and associated services.


Gibbons, Tseng, Monia                                                2

iSNS                         October 2000

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

3.       iSNS Overview

    IP network entities use the Domain Name System (DNS) to resolve
    mappings of DNS names to IP addresses.  Fibre Channel-based storage
    entities use a Storage Name Server (SNS) to discover other storage
    entities and their addressing information. The iSNSP provides a
    common framework to supply both DNS and SNS services for all
    storage entities.

    Although the DNS and SNS infrastructures MAY be managed separately,
    nevertheless they must provide consistent naming and addressing
    information to both IP-based and Fibre Channel-based storage
    entities.  The iSNS Protocol (iSNSP) provides a common framework
    for integration of these naming services for both IP and Fibre
    Channel-based storage entities.

    This framework builds upon the association of IP and Fibre Channel
    objects, and the resulting consistency guarantees among these
    objects. Regardless of the underlying implementation, the framework
    presents the illusion of common IP and Fibre Channel objects. .
    Some attributes of these database objects may be applicable to
    Fibre Channel-based entities, while other attributes may be
    applicable only to IP-based iSCSI entities.  Still other attributes
    such as World Wide Port Name may be used by both Fibre Channel and
    iSCSI entities.  Values stored as attributes for both iSCSI and
    Fibre Channel devices SHALL be consistent regardless of whether
    they are accessed for use by iSCSI or Fibre Channel devices.  The
    consistency guarantee MAY be implemented through a consolidated
    information base.


Gibbons, Tseng, Monia                                                3

iSNS                         October 2000

The following diagram shows an example of Fibre Channel clients and IP
clients accessing SNS and DNS data via iSNS server and DNS server:


     +------------+          +-----------+          +-----------+
     |            |   LDAP   | Directory |   LDAP   |   iSNS    |
     | DNS Server |<-------->|  Database |<-------->|  Server   |
     |            |          |           |          |           |
     +------+-----+          +-----+-----+          +-----+-----+
            |                      |                      |
            | DNS                  | LDAP           iSNSP |
            |Queries               |                      |
     +------+----------------------+----------------------+-----+
     |                                                          |
     |                         IP Network                       |
     |                                                          |
     +------+----------------------+----------------------+-----+
            |                      |                      |
            |              +-------+------+               |
            |              | FC-IP   /    |               |
            |              |Gateway /iSNS |               |
            |              | Proxy /Server|               |
            |              +-------+------+               |
            |                      |                      |
       +----+----+            +----+----+            +----+----+
       |  iSCSI  |            |  Fibre  |            |  iSCSI  |
       |Initiator|            | Channel |            |  Target |
       |         |            | Network |            |         |
       +---------+            +---------+            +---------+
                        iSNS Client Entities

    In the above example, each iSNS Client Entity has its attributes
    committed to the directory database, regardless of whether the
    client is a Fibre Channel entity, or an IP-based entity.

    A DNS server receiving a DNS resolve request can use the 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 directory update messages to the database, and
    consistently reflected in subsequent iSNSP queries and SCN's.

    The iSNS server may be a standalone entity, or it may be integrated
    into another network entity such as a Fibre Channel-iSCSI gateway
    proxy device.  The iSNS directory database may be cohosted with the
    iSNS server, or it may be a separate infrastructure based on
    distributed directory database services such as LDAP.

3.1      iSNS Functional Components


Gibbons, Tseng, Monia                                                4

iSNS                         October 2000


    There are four functional components required by devices operating
    in a IP-based storage network:

    1)  A Name Service Providing Storage Resource Discovery
    2)  State Change Notification Service
    3)  Network Zoning Service
    4)  Domain Name System (DNS) Service (see RFC 1035)

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. This allows
    an iSNS client initiator to obtain information about iSNS client
    target devices from the iSNS server. This service is modeled on the
    Fiber Channel Name Services described in FC-GS-2, with extensions,
    operating within the context of an IP network.

3.1.2    State Change Notification Service

    The State Change Notification service provides functionality for
    issuing notifications about network events that may affect the
    operational state of iSNS entities. The State Change Notification
    service gives an iSNS client the ability to register for
    notification of events detected or received by the iSNS server from
    an iSNS client entity. This service provides the Fiber Channel
    State Change Notification service, with extensions, operating
    within the context of an IP network.

3.1.3    Network Zoning Service

    The Network Zoning Service implements the functionality to support
    grouping of iSNS client devices into domains for administrative and
    access control purposes.  Devices must be in common zones in order
    to "see" each other and communicate through the network.  Devices
    can be a member of multiple zones simultaneously.

3.1.4    DNS Name Service

    The iSNS framework unifies the above storage services used in Fibre
    Channel with the Domain Name System (DNS) service in IP-based
    networks.  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, the DNS host names can be given to
    storage controllers, HBA's, gateways, and iSCSI NICs.  To create a
    unified iSNS framework, DNS naming features now coexist with
    storage concepts such as World Wide Names (WWN's).  For example,
    WWN's can now be used as a key in an iSNS query to discover the DNS
    Name and Path of a particular storage device.  Similarly, the iSNS
    directory database can be used to support queries by DNS resolvers.


Gibbons, Tseng, Monia                                                5

iSNS                         October 2000

3.2      iSNS Architectural Components

3.2.1    iSNS Client

    Entities which initiate transactions using the iSNS protocol will
    hereafter be referred to as iSNS clients.  iSNS clients register
    their attribute information in the iSNS server through use of the
    iSNS protocol.

3.2.2    iSNS Server

    The 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.
    Administration of the iSNS server is similar to established
    processes for administering DNS servers.  The primary functional
    difference between the iSNS and classical DNS is the ability for
    client entities to write information to the server database using
    the iSNSP.

    The iSNS server responds to iSNS and DNS protocol queries and
    requests, and initiates iSNS protocol State Change Notifications.
    Properly authenticated registration request information is stored
    in an internal or external database.

3.2.3    iSNS Directory Database

    The iSNS database is a repository for the iSNS server(s) and DNS
    server(s) to store information about DNS Names, IP Addresses, Fibre
    Channel storage attributes (WWNN, Port ID, etc...), and iSCSI
    storage attributes.  The 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.2.4    World Wide Name (WWN) Identifiers

    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 (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].

    Editor's note: iSCSI naming conventions are TBD by IPS working
    group.


Gibbons, Tseng, Monia                                                6

iSNS                         October 2000


3.2.5    IP Address

    The IP address is used to identify a network interface of an IP
    storage gateway or native device in an IP network.

3.2.6    DNS Name

    A DNS Name is assigned to a network node having one or more storage
    devices.  Each IP storage device is distinguished by the Path
    field.  The DNS Name uses a hierarchical name space consisting of
    one or more labels, each of at most 63 characters.  A period is
    used to separate the labels.  The iSNS uses a fully qualified
    domain name consisting of up to 255 characters.  Each Domain Name
    maps to an IP Address.  More information about the DNS Domain Name
    can be found in RFC 1035.

3.3      Compatible Naming Convention Example

    The above components of the iSNS architectural framework support
    the use of Fibre Channel naming conventions as well as the URL
    convention common in IP networking.  The framework allows iSCSI
    naming conventions to be mapped to naming conventions used in Fibre
    Channel.  For example, the following URL format can be implemented
    and translated to the Fibre Channel naming convention through use
    of the iSNS server:

     iscsi://server1.nishansystems.com/device3?WWPN=c2ae3253f3

    The iSCSI client parsing this URL would submit an iSNSP query to
    the iSNS server, using the keys DNS Name =
    "server1.nishansystems.com", Path = "device3" and WWPN =
    "c2ae3253f3".  The iSNS directory database would retrieve the
    attribute IP Address = ww.xx.yy.zz as the proxy IP gateway address
    to the Fibre Channel fabric.  DevGetNext queries to the iSNS server
    will allow the iSCSI client to further discover additional targets
    in the Fibre Channel fabric by returning their WWPN's.

3.4      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
    distributed database framework such as LDAP, iSNS functionality can
    be broadly extended to the Public Internet.  Additionally, the iSNS
    framework leverages existing DNS mechanisms, where zone transfer of
    domain information may take place from upstream authorities in the
    DNS hierarchy.


Gibbons, Tseng, Monia                                                7

iSNS                         October 2000

    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.

4.       iSCSI/Fibre Channel Database Objects

    iSNS provides the framework for archiving and retrieval of topology
    information of iSCSI and Fibre Channel-based storage devices.  This
    architecture defines objects which represent storage entity
    components in both Fibre Channel and IP-based storage devices.

    The following architecture framework includes all elements needed
    to describe both iSCSI-based and FCP-based (Fibre Channel) storage
    device attributes in the iSNS directory database.  Existing Fibre
    Channel storage resources can now be described to iSCSI-based iSNS
    clients for access through a proxy iSCSI/Fibre Channel gateway.

    Four object entities are defined in this architecture framework.
    They are IP STORAGE NODE, STORAGE ENTITY, ZONE and STORAGE PORT.
    Each of these objects are defined in sections 4.1, 4.2, 4.3, and
    4.4.

    The following diagram shows how database objects are used to
    represent storage components (with the exception of Zones).  Each
    object has a set of attributes described in section 5., which may
    be applicable in either a iSCSI or Fibre Channel network, or both.
    Objects are denoted in all CAPITAL letters.


Gibbons, Tseng, Monia                                                8

iSNS                         October 2000

    +----------------------------------------------------------------+
    |                         IP Network                             |
    +--------------------+---------------------+---------------------+
                         |                     |
            IP Address 1 o                     o IP Address 2
                         |                     |
    +--------------------|---------------------|---------------------+
    |                    |                     |                     |
    |   +----------------+---------------------+-----------------+   |
    |   |    Service Delivery Subsystem (FC or internal dev bus) |   |
    |   +--------+ +---------------------+ +-----------+ +-------+   |
    |            | |                     | |           | |           |
    |            | |                     | |           | |           |
    |   +--------+ +-------+       +-----+ +-----------+ +-------+   |
    |   |     |STORAGE|    |       |  |STORAGE|     |STORAGE|    |   |
    |   |     |  PORT |    |       |  |  PORT |     |  PORT |    |   |
    |   |     +-------+    |       |  +-------+     +-------+    |   |
    |   |                  |       |                             |   |
    |   |                  |       |    000000000000000000000    |   |
    |   |                  |       |       Logical Units         |   |
    |   |                  |       |                             |   |
    |   |     initiator    |       |          target             |   |
    |   |  STORAGE ENTITY  |       |      STORAGE ENTITY         |   |
    |   +------------------+       +-----------------------------+   |
    |                                                                |
    |                       IP STORAGE NODE                          |
    +----------------------------------------------------------------+

4.1      IP Storage Node Object

    The IP Storage Node object defines an IP endpoint node that
    originates or terminates a TCP/IP connection.  An IP End Node may
    contain one or more Storage Entity objects.  This object may be
    used to define a native iSCSI storage device, iSCSI NIC, a Fibre
    Channel-iSCSI gateway, or any other storage device with an IP
    address.  In the case of a Fibre Channel to IP gateway, the IP
    storage node object may support one or more native Fibre Channel
    storage devices.  One or more IP address attribute values may be
    assigned to an IP Storage Node object entity.

    The following are attributes of the IP Storage Node object.  Each
    attribute is described in more detail in section 5.4.
    Applicability indicates whether the attribute is used by an iSCSI
    device or a Fibre Channel device, or both.  A gateway device will
    need to support both iSCSI and Fibre Channel attributes.

    The following attributes are described in more detail in sections
    5.4.

    The Key Attribute column indicates the attribute is a search key
    used to query the database.


Gibbons, Tseng, Monia                                                9

iSNS                         October 2000

                                 Applicability
    Attribute                 iSCSI      Fibre Channel    Key Attribute
    ---------                 -----      -------------    -------------
    IP Address                  *                               *
    Management IP Address       *             *
    DNS Name                    *                               *
    Client Certificate
    Port Number

4.2      Storage Entity Object

    The Storage Entity object defines an individual storage initiator
    or target.  This entity may be a RAID device, a Fibre Channel HBA,
    or other individual storage device.  The Storage Entity may have
    one or more Storage Port objects.

    The following are attributes of the Storage Entity object. Each
    attribute is described in more detail in section 5.4. Applicability
    indicates whether the attribute is used by an iSCSI device or a
    Fibre Channel device, or both.  A gateway device will need to
    support both iSCSI and Fibre Channel attributes.

    The following attributes are described in more detail in sections
    5.4.

                                  Applicability
    Attribute                 iSCSI      Fibre Channel    Key Attribute
    ---------                 -----      -------------    -------------
    Node Name                                 *                *
    Node Symbolic Name                        *
    FC Node IPA                               *
    Node Type                   *             *

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

    A Zone entity contains one or more Storage Ports.  Storage Ports
    that are in the same Zone entity can "see" each other, and can thus
    communicate without restrictions.

    The following are attributes of the Zone object. Each attribute is
    described in more detail in section 5.4. Applicability indicates
    whether the attribute is used by an iSCSI device or a Fibre Channel
    device, or both.  A gateway device will need to support both iSCSI
    and Fibre Channel attributes.


Gibbons, Tseng, Monia                                               10

iSNS                         October 2000


    The following attributes are described in more detail in sections
    5.4.

                                 Applicability
    Attribute                 iSCSI      Fibre Channel    Key Attribute
    ---------                 -----      -------------    -------------
    Zone ID                     *             *                *
    Zone Tag                    *             *                *
    Zone Symbolic Name          *             *
    Zone Member (WWPN)          *             *
    Zone Member (IP Address)    *
    Zone Member Priority        *             *

4.4      Storage Port Object

    The Storage Port object defines an individual service delivery port
    that services a Storage Entity.  The Storage Port provides the
    interconnect between the Storage Entity and its Logical Units with
    the Service Delivery Subsystem.  The Service Delivery Subsytem may
    be a Fibre Channel interconnect, or an internal device bus,
    depending on the specific type of Storage Entity being supported by
    the Storage Port.  A Storage Port may be a member of one or more
    Zone entities.

    The following attributes are described in more detail in sections
    5.4.

                                 Applicability
    Attribute                 iSCSI      Fibre Channel    Key Attribute
    ---------                 -----      -------------    -------------
    Port Name (WWPN)            *             *                 *
    FC Hard Address                           *
    Fabric Port Name (FWWN)                   *                 *
    Port_ID                                   *
    Port_Symbolic Name                        *
    Port_Type                   *             *
    FC Class of Service                       *
    FC Port IP Address                        *
    Path                        *

5.       iSNS Message Protocol

    The following describes the format of the iSNS Protocol:


Gibbons, Tseng, Monia                                               11

iSNS                         October 2000

       Byte   MSb                              LSb
       Offset 7    6    5    4    3    2    1    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
    RESERVED                                      0x0000-8000

    The following are iSNSP response messages:


Gibbons, Tseng, Monia                                               12

iSNS                         October 2000

    Response Message Description      Abbreviation   Func_ID  Support
    ----------------------------      ------------   -------  -------
    Register Device Attribute         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      0x8006  Required
    Deregister Zone Response          DeregZoneRsp    0x8007  Required
    Register Device in Zone Response  RegDevZoneRsp   0x8008  Required
    Deregister Device in Zone Resp    DeregDevZoneRsp 0x8009  Required
    RESERVED                                       0x800A-FFFF

    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 of variable length and contains attributes
    used for registration and query operations.  Each iSNS attribute is
    specified in the iSNSP message payload using Tag-Length-Value (TLV)
    format, as shown below:

       +----------+----------+-------------------+
       | attr_id  | attr_len |     attr_val      |
       +----------+----------+-------------------+

    attr_id (ID) - a 2-byte field that identifies the attribute as
    defined in section 5.4.  This field contains the ID of the
    indicated attribute.

    attr_len (Length) - a 2-byte field that indicates the length, in
    bytes, of the attribute value to follow.


Gibbons, Tseng, Monia                                               13

iSNS                         October 2000

    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

5.3      Message Authentication

    iSNSP provides an optional message authentication capability.
    Network interactions using iSNSP occur in short transactions, and
    are generally not sesion 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
    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


Gibbons, Tseng, Monia                                               14

iSNS                         October 2000

    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.

    TIMESTAMP - This is a 4-byte unsigned, fixed-point integer giving
    the number of seconds since midnight, January 1, 1970.

    SPI STRING LENGTH - The length of the SPI STRING field.


Gibbons, Tseng, Monia                                               15

iSNS                         October 2000


    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 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:

    Attribute Name     Size(bytes)  ID   Reg Key   Query Key
    --------------     -----------  --   -------   ---------
    Node Name (WWNN)          8      1      1      1,4, 9&10 or 18&19
    Node Symbolic Name     0-255     2      1      1,4, 9&10 or 18&19
    Management IP Address    16      3      1      1,4, 9&10 or 18&19
    Port Name (WWPN)          8      4      1      1 or 9&10
    FC Node IPA               8      5      1      1,4 or 9&10
    FC Hard Address           3      6      1      1,4 or 9&10
    Fabric Port Name (FWWN)   8      7      1      1,4 or 9&10
    Node Type                 2      8      1      1,4 or 9&10
    IP Address               16      9      4      1,4 or 19
    Port ID                   3     10      4      4
    Port Symbolic Name     0-255    11      4      4 or 9&10
    Port Type                 2     12      4      4 or 9&10
    FC Class of Service       4     13      4      4 or 9&10
    FC Port IP Address       16     14      4      4 or 9&10
    FC-4 Types               32     15      4      4 or 9&10
    Port Reg Timestamp        8     16      4      4 or 9&10
    Transport Protocol        2     17      4      4 or 9&10
    DNS Name               0-255    18   1 or 9    1,4 or 9&10
    Path                   0-255    19   1 or 9    1,4 or 9&10
    Client Certificate   variable   20      1      1,4, 9&10 or 18&19
    Port Number               2     21      4      4 or 9&10

    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.

    ID - the value used to identify the attribute.


Gibbons, Tseng, Monia                                               16

iSNS                         October 2000

    Registration Key - indicates the attribute ID that is the unique
    key used for attribute registration.  This attribute is also known
    as the primary key for the iSNS directory database entry.

    Query Key - indicates the attribute ID(s) that is (are) the unique
    key used to query the iSNS directory database.

    iSNS client attributes are defined below:

5.4.1    Node Name (WWNN)

    Node Name is a 64-bit identifier that uniquely identifies the
    device node in the network.  This required field is provided by the
    iSNS client entity.  The format of the Node Name (WWNN) is as
    defined in section 3.2.4.

5.4.2    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 use of the Node Symbolic Name is
    consistent with Fibre Channel.

5.4.3    Management IP Address

    This optional field is provided by the iSNS client.  It contains
    the IP Address used to manage the node.  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.

5.4.4    Port Name (WWPN)

    This 64-bit identifier uniquely defines the device port.  This
    required field is provided by the iSNS client entity.  The format
    of the Port Name (WWPN) is defined in section 3.2.4.

5.4.5    FC Node Initial Process Associator

    This optional field is included for compatibility with Fibre
    Channel, and is provided by the iSNS client entity.  The initial
    process associator can be used for communication between Fibre
    Channel devices.

5.4.6    FC Hard Address


Gibbons, Tseng, Monia                                               17

iSNS                         October 2000

    This optional is the 24-bit NL Port Identifier, included in the
    iSNSP for compatibility with Fibre Channel Arbitrated Loop devices
    and topologies.

5.4.7    Fabric Port Name (FWWN)

    This 64-bit identifier uniquely defines the fabric port.  If the
    iSNS client is attached to a 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.4.8    Node Type

    This 16-bit field is a bitmap indicating the type of 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
           2            Proxy
           3            Switch
       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.4.9   IP Address

    This is the IP address associated with a device port in the
    network.  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.

5.4.10   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 only used for
    native Fibre Channel storage devices, and is unused for native IP-
    based storage devices.

5.4.11   Port Symbolic Name

    A variable-length text-based description of up to 256 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


Gibbons, Tseng, Monia                                               18

iSNS                         October 2000

    provided by the iSNS client during registration.  However, network
    management application can update this field as required.  The use
    of the Symbolic Name provides the user with a readable description
    of the port entry in the iSNS directory database.

5.4.12   Port Type

    Indicates the type of device port.  This is provided by the iSNS
    client entity.  Encoded values for this field are listed in the
    following table:

    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
    0xFF10           iSCSI Port
    0xFF11           RESERVED (for mFCP Port*)
    0xFF12           RESERVED (for iFCP Port*)
    0xFF13-FFFF      RESERVED

    * To be defined later.

5.4.13   Class of Service (COS)

    This is a 32-bit bit-map field that indicates the COS types that
    are supported by the registered port.  This required field is
    provided by the 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.4.14   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.


Gibbons, Tseng, Monia                                               19

iSNS                         October 2000


5.4.15   FC-4 Types

    An 8-word bit-map of the FC-4 protocol types supported by the
    associated port.  This required field is provided by the iSNS
    client.  This field can be used to support Fibre Channel devices.

5.4.16   Port Registration Timestamp

    Indicates the time that the most recent device port registration
    updates 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 is used to ensure the SNS
    directory does not contain entries for non-existent port devices.

5.4.17   Transport Protocol

    Contains a bit map that indicates the type of transport protocol
    that the iSNS client supports for transport of storage traffic.
    This bit map is indicated below:

         Bit Field          Transport Protocol Supported
         ---------          ----------------------------
             0                      UDP
             1                      TCP
             2                      SCTP
           Others                   RESERVED

5.4.18   DNS Name

    Identifies a node in the IP storage network.  The DNS Name, along
    with the Path, uniquely identify a Node Name (WWNN).  It uses
    existing naming conventions defined in RFC1035.  Each DNS Name maps
    to one IP-addressable node.  A node having an IP Address may have
    more than one storage device.  For example, a host at a single IP
    address may have several device controllers that can be
    independently addressed by initiators.  The Path attribute
    distinguishes among multiple devices which may reside in an IP-
    addressable node.

5.4.19   Path

    Along with the DNS Name, the Path uniquely identifies a native IP-
    based storage device.  The Path distinguishes among multiple IP-
    based storage entities which 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.  The
    Path field is similar to that of the UNIX file format.

5.4.20   Client Certificate


Gibbons, Tseng, Monia                                               20

iSNS                         October 2000

    This optional attribute MAY contain a X.509 certificate with the
    public key of the iSNS client.  This certificate is used by the
    iSNS client to authenticate itself for storage transfers with other
    storage entities.  Initiators wishing to communicate with a target
    storage device MAY retrieve the target's X.509 certificate from the
    name server in order to encrypt a secret session key using the
    target's public key contained in the certificate.

5.4.21   Port Number

    Contains the TCP or UDP port number being used for communication
    with the iSNS server by the iSNS client.

5.4      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:

    Attribute Name     Size(bytes)    ID      Reg Key     Query Key
    --------------     -----------    --      -------     ---------
    Zone ID                 2        101                     101
    Zone Tag                2        102        101          101
    Zone Symbolic Name     1-64      103        101          101
    Zone Member (WWN)       8        104        101          101
    Zone Member (IP Addr)  16        105        101          101
    Zone Member Priority    1        106    101,105,106  101,104,105

    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.

    Zone Tag - the tag used to identify the the zone in the network.

    Zone Symbolic Name - an ASCII, variable-length string that is
    NULL-terminated.  This is an optional user-readable field that can
    be used to assist a network administrator in tracking the zone
    function.

    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 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                                               21

iSNS                         October 2000

    Zone Member Priority - the 802.1P/Q priority being used for this
    zone member in the network.  This value can range from 0 to 7, and
    is based on valid 802.1P/Q priority tag values.

5.5      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 an SCN is sent is based on the 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 port 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


Gibbons, Tseng, Monia                                               22

iSNS                         October 2000

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


Gibbons, Tseng, Monia                                               23

iSNS                         October 2000

    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.

    Message        Source/Dest Attr   Key Attribute  Operating Attr
    -------        ----------------   -------------  --------------
    RegDevAttr        1,4,9           1,4,9,18&19    multiple[1-21]
    RegDevRsp         --                 --            --
    DevAttrQry        4,9             1,4,9,18&19    multiple[1-21]
    DevAttrQryRsp     --                 --          multiple[1-21]
    DevGetNext        4,9             1,4,9,18&19      --
    DevGetNextRsp     --                 --          1,4,9,18&19
    DeregDev          4,9             1,4,9,18&19      --
    DeregDevRsp       --                 --            --
    SCNReg            4,9             1,4,9,18&19      --
    SCNRegRsp         --                 --            --
    SCN               4,9 (dest)         --            --
    RegZone           4,9 (dest)         101         multiple[101-106]
    RegZoneRsp        --                 --            --
    DeregZone         4,9                101           --
    DeregZoneRsp      --                 --            --
    RegDevZone        4,9                101           4,9
    RegDevZoneRsp     --                 --            --
    DeregDevZone      4,9                101           4,9
    DeregDevZoneRsp   --                 --            --
    PSI               4,9 (dest)         --            --
    PSIUpdate         4,9                --            --
    Heartbeat         --                 --            --

    The above table lists attribute ID's from section 5.4 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


Gibbons, Tseng, Monia                                               24

iSNS                         October 2000

    iSNS client formulates a register attribute request by specifying a
    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
    attribute values corresponding to the key entry will be replaced
    with new values sent in the message.  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                                               25

iSNS                         October 2000

    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                                               26

iSNS                         October 2000

    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 adminstratively 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                                               27

iSNS                         October 2000

    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 midnight, 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       |    12 Bytes
              +----------------------------------+
         12   |        EVENT TYPE FLAGS          |     2 Bytes
              +----------------------------------+
         14   |           TIME STAMP             |     4 Bytes
              +----------------------------------+
                      Total Length = 18

    Destination attribute contains the IP Address or Port_Name in TLV
    format of the iSNS client to receive the SCN message.  There is no
    response message to the SCN message by the iSNS client.

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, Port Names
    can be added and deleted from the Zone.

    Zones are defined using Zone IDs, Zone tags, and Symbolic Names.
    Zone registration attributes are described in section 5.4.

    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 or WWPN], and Zone Member Priority).


Gibbons, Tseng, Monia                                               28

iSNS                         October 2000

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 or Port Name) 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 or Port Name (WWPN) to the zone
    provides access to all other device ports 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 or Port_Name], and Zone Member Priority).

6.17     Register Device in Zone Response (RegDevZoneRsp)

    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 does not contain any attributes.

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


Gibbons, Tseng, Monia                                               29

iSNS                         October 2000

    the operating attribute (IP Address or Port Name) 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
    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


Gibbons, Tseng, Monia                                               30

iSNS                         October 2000

    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 Implentation 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 6.42, June 7, 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



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


Gibbons, Tseng, Monia                                               31

iSNS                         October 2000


Full Copyright Statement

    "Copyright (C) The Internet Society, September 18, 2000. 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 implmentation 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


Gibbons, Tseng, Monia                                               32

iSNS                         October 2000


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