[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-01.txt>                          Josh Tseng
    Expires September 2001                             Charles Monia
                                                      Nishan Systems

                                                   Franco Travostino
                                                     Nortel Networks

                                                          Ken Hirata
                                                   Vixel Corporation

                                                          Mark Bakke
                                                       Cisco Systems

                                                          Jim Hafner
                                                        IBM Research

                                                         Howard Hall
                                                      Pirus Networks

                                                          March 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


Gibbons, Tseng, Monia      Standards Track
iSNS                          March 2001

    Klein (Sanrad), Larry Lamers (SAN Valley), Jack Harwood (EMC),
    David Black (EMC), and David Robinson (Sun).

Comments

    Comments should be sent to the IPS mailing list (ips@ece.cmu.edu)
    or to the authors.

1.       Abstract

    This document provides a generic framework centering around use of
    the iSNS for discovery and management of storage entities in an
    enterprise-scale IP storage network.  iSNS is an application that
    stores client attributes and monitors the availability and
    reachability of storage assets in an integrated IP storage network.
    Due to its role as a consolidated information repository, iSNS
    provides for more efficient and scalable management of IP storage
    assets.

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

    The iSNS provides a common framework used to provide naming,
    discovery, and resource management services for enterprise-scale IP
    storage networks. iSNS can be implemented to support iSCSI, iFCP,
    and/or FCIP protocols as needed; an iSNS implementation MAY provide
    support for any one, two, or all three of these protocols as
    desired by the implementer.  Implementation requirements within
    each of these protocols is further discussed in section 5. Although
    use of iSNS is optional for iSCSI and FCIP, these protocols will
    benefit from iSNS as the number of devices in the storage network
    increases.

3.1      iSNS Architectural Components

3.1.1    iSNS Client

    Entities that initiate transactions using the iSNSP 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 DD, and receive asynchronous notification of
    topology events that occur in their DD(s). Management stations are


Gibbons, Tseng, Monia      Standards Track                           2
iSNS                          March 2001

    a special type of iSNS client that have access to all DDs stored in
    the iSNS.

3.1.2    iSNS Server

    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.1.3    iSNS Database

    The iSNS database is the information repository for the iSNS
    server(s).  It maintains information about iSNS client attributes.
    A directory-enabled implementation of iSNS may store client
    attributes in an LDAP directory infrastructure.

3.1.4    iSNS Protocol (iSNSP)

    The iSNS Protocol (iSNSP) is a flexible and lightweight protocol
    that specifies how iSNS clients and servers communicate.  It is
    suitable for various platforms, including switches and targets as
    well as server hosts.

3.2      iSNS Functional Components

    There are three main functional components of the iSNS:

    1)  A Name Service Providing Storage Resource Discovery
    2)  Discovery Domain (DD) and Login Control Service
    3)  State Change Notification Service

3.2.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 about other initiators and targets.  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 may exist
    in 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.

Gibbons, Tseng, Monia      Standards Track                           3
iSNS                          March 2001


    The naming registration service also provides the ability to obtain
    a network unique Domain ID for iFCP gateways and Fibre Channel
    Autonomous Regions (AR's), when required.

3.2.2    Discovery Domain and Login Control Service

    The Discovery Domain (DD) Service facilitates the partitioning of
    iSNS client devices into more manageable groupings for
    administrative and login control purposes. With DD's, an
    administrator can partition groups of initiators and targets into
    more manageable groups in order to limit the login process to the
    more appropriate subset of targets registered in the iSNS.  iSNS
    clients must be in at least one common DD in order to obtain
    information about each other from the iSNS.  iSNS clients can be a
    member of multiple DD's simultaneously.

    The DD information stored in the iSNS can be used by various
    enforcement points in the network to provide enhanced security.
    For example, a DD-aware switch can block storage initiators from
    accessing targets that are not in the same DD, even if the
    initiator somehow obtained address information for a target outside
    of its DD.  This functionality is the equivalent of the _Hard
    Zoning_ functionality in a Fibre Channel network.

    Login Control allows targets to "slave" their access control
    mechanism to the iSNS.  The target 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.  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 initiator identities is a concern, the
    target MAY use the public key certificate of the authorized
    initiator, obtained from the iSNS server, to authenticate the
    initiator.

    DD's can be managed offline by a separate management workstation,
    through the iSNSP or through SNMP.  If the target opts to use the
    Login Control feature of the iSNS, the target subordinates
    management of access control policy (i.e., the list of initiators
    allowed to login to that target) to the management workstations
    that are manipulating information in the iSNS database.

    If authorized, a target can upload its own Login Control list.
    This is accomplished using the RegDevDD message and listing the
    WWUI of each initiator to be registered in the Target's DD.

    Devices that do not belong to any Discovery Domain SHALL NOT be
    accessible to any other device (except the management station).
    Depending on the implementation, newly registered devices that have
    not explicitly been placed into a DD by the management station MAY
    be placed into a "default DD" where they are visible to other

Gibbons, Tseng, Monia      Standards Track                           4
iSNS                          March 2001

    devices in that DD.  Other implementations MAY decide that they are
    registered with no DD, making them inaccessible to any other
    devices in the iSNS database.

3.2.3    State Change Notification Service

    The State Change Notification (SCN) service allows the iSNS to
    issue notifications about network events that 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 Discovery Domain (DD) membership and device registration
    updates.

    The State Change Notification service utilizes the Discovery Domain
    Service, as described in section 3.1.2, to control the distribution
    of notification messages.  Notifications about changes within a DD
    are limited to members of that DD.

    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 its sessions with other storage
    devices 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.

3.3      iSNS and Domain Name System (DNS)

    A directory-enabled iSNS implementation may use LDAP to store iSNS
    client attributes.  If this is the case, then LDAP can be used to
    support both the iSNS and DNS server infrastructures, maintaining
    consistency in Domain Name-to-IP address mappings used by DNS and
    iSNS.

    A detailed description of the Domain Name System (DNS) protocol is
    found in [RFC 1035], and is beyond the scope of this document. If a
    common LDAP information base is used to support both DNS and iSNS
    servers, then Domain-Name-to-IP address mappings for storage
    devices can be obtained from either DNS servers or the iSNS.

3.4       iSNS and LDAP

    LDAP is a generic protocol to access directory services through the
    network.  It is a passive service designed to deliver scalable

Gibbons, Tseng, Monia      Standards Track                           5
iSNS                          March 2001

    directory services using a get/set model.  Applications designed
    and tailored to specific user requirements interact with LDAP for
    their generic directory service needs.  On the other hand, iSNS is
    an application that goes beyond the simple get/set model, and
    provides specific capabilities needed to monitor and manage an
    enterprise-scale storage network.  iSNS is one example of an
    application that can leverage the services of LDAP.  By layering
    iSNS on top of LDAP, the capabilities of both iSNS and LDAP can be
    leveraged to manage and scale the enterprise IP storage network.

    The iSNS application provides capabilities that LDAP alone is not
    designed to achieve.  This includes the following:

    1)  Client Attribute Awareness - The iSNS server application
    interprets attribute values submitted by clients in registration
    messages, and can take appropriate action based upon specific
    registered attribute values.

    2)  State Change Notification - An iSNS server may initiate
    notification messages to clients in the event of a change in the
    network, such as the non-availability or reachability of a storage
    device, or a specific change in the value of a client attribute.

    3)  Monitoring of Clients - iSNS provides a Entity Status Inquiry
    message to verify the availability and reachability of storage
    devices.

    4)  Lightweight - iSNSP is a simple and lightweight protocol
    suitable for implementation on embedded devices such as switches
    and targets.  There are no unused or "wasted" features that may bog
    down the performance of the host device.

3.5       iSNS Discovery and SLP

    The Service Location Protocol (SLP) provides a flexible and
    scalable framework for providing hosts with access to information
    about the existence, location, and configuration of networked
    services.  SLP MAY be used by iSNS clients to discover the IP
    address of the iSNS server.  To implement discovery through SLP, a
    Service Agent (SA) should be cohosted in the iSNS server, and a
    User Agent (UA) should be in each iSNS client. Each client
    multicasts a discovery message requesting the IP address of the
    iSNS server(s).  The SA responds to this request.  Optionally, the
    location of the iSNS can be stored in the SLP Directory Agent (DA).

    If iSNS is not used, then the IP address of the iSNS server should
    be manually configured in each iSNS client.

    Note that a complete description and specification of SLP can be
    found in [RFC2608], and is beyond the scope of this document.
    Additional details on use of SLP to discover iSNS can be found in
    the document draft-bakke-iscsi-slp-00.txt.


Gibbons, Tseng, Monia      Standards Track                           6
iSNS                          March 2001

3.6     iSNS and 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 Fully Qualified Domain Name
    (i.e., Entity Identifier) 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.

    A final approach is to simply disallow use of NAT in between
    communication between the iSNS server and any iSNS client.

3.7     Interactions Between iSNS Infrastructures

    Each individual iSNS deployment is designed to be operated in
    networks under the control of a single administrative authority.
    This administrative authority facilitates a seamless, integrated
    policy for iSNS usage, including security, naming and registration
    of storage assets, and management of Discovery Domains.  Through
    leverage of an Internet-based database framework such as LDAP, the
    iSNS not only scales to large storage networks, but also to support
    interactions among multiple independently managed storage
    infrastructures, each managed by its own administrative authority.

    The information registered in the iSNS can be shared with other
    iSNS servers managed by other administrative authorities through
    out-of-band, non-iSNS protocols.  By importing registration
    information from a remote iSNS server, storage connectivity can be
    established to devices managed by that server.

    The following examples illustrate possible methods to transfer iSNS
    records of devices between autonomous, independently-administered
    iSNS servers.  In the first example, a back-end LDAP information
    base is used to support the iSNS server.  The following diagram
    illustrates use of the LDAP protocol to import iSNS registration

Gibbons, Tseng, Monia      Standards Track                           7
iSNS                          March 2001

    information from one iSNS server to another.  Once the record
    transfer of the remote device is completed, it becomes visible and
    accessible to local devices on the local iSNS server.  This allows
    local devices to establish sessions with remote devices (provided
    firewall boundaries can be negotiated).

    +-------------------------+           +-------------------------+
    |+------+ iSNSP           |           |           iSNSP +-----+ |
    ||dev A |<----->+------+  |           |  +------+<----->|dev C| |
    |+------+       |      |  |           |  |      |       +-----+ |
    |+------+ iSNSP |local |  |           |  |remote| iSNSP +-----+ |
    ||dev B |<----->| iSNS |  |           |  | iSNS |<----->|dev D| |
    |+------+       |      |  |           |  |      |       +-----+ |
    |........       +--+---+  |   WAN     |  +---+--+               |
    |.dev C'.          |      |   Link    |      |                  |
    |........          |      =============      |                  |
    |                  |      |           |      |                  |
    |               +--+---+  |           |  +---+--+               |
    |               | local|<--- <--- <--- <-|remote|               |
    |               | LDAP |  |  LDAP:    |  | LDAP |               |
    |               +------+  Xfer "dev C"|  +------+               |
    +-------------------------+           +-------------------------+

           Enterprise                           Enterprise
           Network A                            Network B

    In the above diagram, two business partners wish to share storage
    "dev C". Using LDAP, the record for "dev C" can be transfered from
    Network B to Network A.  Once accessible to the local iSNS in
    Network A, local devices A and B can now discover and connect to
    "dev C".























Gibbons, Tseng, Monia      Standards Track                           8
iSNS                          March 2001

    +-------------------------+           +-------------------------+
    |+------+ iSNSP           |           |           iSNSP +-----+ |
    ||dev A |<----->+------+  |           |  +------+<----->|dev C| |
    |+------+       |      |  |           |  |      |       +-----+ |
    |+------+ iSNSP |local |  |           |  |remote| iSNSP +-----+ |
    ||dev B |<----->| iSNS |  |           |  | iSNS |<----->|dev D| |
    |+------+       |      |  |           |  |      |       +-----+ |
    |........       +------+  |   WAN     |  +---+--+               |
    |.dev C'.          ^      |   Link    |      |                  |
    |........          |      =============      v                  |
    |                  |      |           |      |SNMP              |
    |                  |      |           |      |                  |
    |               +--+----+ |           |      v                  |
    |               | SNMP  |<--- <--- <--- <----                   |
    |               | Mgmt  | |  SNMP: Xfer "dev C"                 |
    |               |Station| |           |                         |
    |               +-------+ |           |                         |
    +-------------------------+           +-------------------------+

           Enterprise                           Enterprise
           Network A                            Network B

    The above diagram illustrates a second example of how iSNS records
    can be shared.  In this case, the iSNS servers are not using LDAP
    to store records.  This method uses an SNMP-based management
    station to manually download the desired record for "dev C", and
    then directly upload it to the local iSNS. Once the record is
    transfered to the local iSNS in Network A, "dev C" becomes visible
    and accessible (provided firewall boundaries can be negotiated) to
    other devices in Network A.

    Other methods, including proprietary protocols, can be used to
    transfer device records between independently-administered iSNS
    servers.  Further discussion and explanation of these methodologies
    is beyond the scope of this document.

3.8      Deployment Architecture Diagram

    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.













Gibbons, Tseng, Monia      Standards Track                           9
iSNS                          March 2001


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

4.       iSNS Object Model

    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
    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 DISCOVERY DOMAIN.  Each of these
    objects are described in greater detail in sections 4.1 to 4.5.

    The object containment hierarchy starts with the DISCOVERY DOMAIN.
    The DISCOVERY DOMAIN contains a set of NETWORK ENTITY objects,
    STORAGE NODE objects, and/or PORTAL objects.  Conversely, an
    individual NETWORK ENTITY, STORAGE NODE, or PORTAL can be contained

Gibbons, Tseng, Monia      Standards Track                          10
iSNS                          March 2001

    in one or more DISCOVERY DOMAIN objects.  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.

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            Primary
    Attribute                 iSCSI     iFCP     FCIP     Key Attribute
    ---------                 -----     ----     ----     -------------
    Entity Identifier           *         *        *            *
    Entity Type                 *         *        *
    Management IP Address       *         *        *
    ESI Interval                *         *        *
    Timestamp                   *         *        *
    Entity Certificate          *         *        *
    SCN Event Bitmap            *         *        *
    ESI TCP/UDP Port            *         *        *

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.

                                    Applicability            Primary
    Attribute                 iSCSI     iFCP     FCIP     Key Attribute
    ---------                 -----     ----     ----     -------------
    IP Address                  *        *         *            *
    TCP/UDP Port                *        *         *            *
    Portal Symbolic Name        *        *         *

4.3      STORAGE NODE Object



Gibbons, Tseng, Monia      Standards Track                          11
iSNS                          March 2001

    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            Primary
    Attribute                 iSCSI     iFCP     FCIP     Key Attribute
    ---------                 -----     ----     ----     -------------
    WWUI                        *                              *
    Node Name (WWNN)                      *                    *
    Node Type                   *         *
    Alias/Node Symbolic Name    *         *
    FC Node IP-Address                    *
    FC Node IPA                           *
    Node 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      DISCOVERY DOMAIN Object

    DISCOVERY DOMAINS are 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 DD.  Initiators will
    thus not be able to "see" devices that are not in a common DD.

                                    Applicability            Primary
    Attribute                 iSCSI     iFCP     FCIP     Key Attribute
    ---------                 -----     ----     ----     -------------
    DD_ID                      *         *        *           *
    DD_Symbolic Name           *         *        *           *
    DD_Member (WWUI)           *                              *
    DD_Member (WWPN)                     *                    *
    DD_Member (WWNN)                     *                    *
    DD_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.






Gibbons, Tseng, Monia      Standards Track                          12
iSNS                          March 2001

                                    Applicability            Primary
    Attribute                 iSCSI     iFCP     FCIP     Key Attribute
    ---------                 -----     ----     ----     -------------
    Port Name (WWPN)                      *                    *
    Port_ID                               *
    Port_Type                             *
    Port_Symbolic Name                    *
    FC Fabric Port Name (FWWN)            *
    FC Hard Address                       *
    FC Port IP Address                    *
    FC Class of Service                   *
    FC FC-4 Types                         *
    FC FC-4 Descriptors                   *
    FC FC-4 Features                      *

4.6      Diagram Examples

    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.

4.6.1    iSCSI

    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      Standards Track                          13
iSNS                          March 2001

    +----------------------------------------------------------------+
    |                         IP Network                             |
    +------------+--------------------------------------+------------+
                 |                                      |
                 |                                      |
    +-----+------+------+-----+            +-----+------+------+-----+
    |     | PORTAL      |     |            |     | PORTAL      |     |
    |     | -IP Addr 1  |     |            |     | -IP Addr 2  |     |
    |     | -TCP Port 1 |     |            |     | -TCP Port 2 |     |
    |     +-----+ +-----+     |            |     +-----+ +-----+     |
    |           | |           |            |           | |           |
    |           | |           |            |           | |           |
    |  +--------+ +--------+  |            |   +-------+ +--------+  |
    |  |                   |  |            |   |                  |  |
    |  |  STORAGE NODE     |  |            |   |  STORAGE NODE    |  |
    |  |  -WWUI            |  |            |   |   -WWUI          |  |
    |  |  -Alias: "server1"|  |            |   |   -Alias: "disk1"|  |
    |  |  -Type: initiator |  |            |   |   -Type: target  |  |
    |  |                   |  |            |   |                  |  |
    |  +-------------------+  |            |   +------------------+  |
    |                         |            |                         |
    |    NETWORK ENTITY       |            |    NETWORK ENTITY       |
    |   -Entity ID (FQDN):    |            |   -Entity ID (FQDN):    |
    |    "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      Standards Track                          14
iSNS                          March 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        |  |
    |  |  -Alias: "disk1"| |  -Alias: "disk2"| |  -Alias: "disk3"|  |
    |  |  -Type: target  | |  -Type: target  | |  -Type: target  |  |
    |  |                 | |                 | |                 |  |
    |  +-----------------+ +-----------------+ +-----------------+  |
    |                                                               |
    |                         NETWORK ENTITY                        |
    |                    -Entity ID (FQDN): "dev1.foo.com"          |
    |                    -Type: iSCSI                               |
    |                                                               |
    +---------------------------------------------------------------+

4.6.2    iFCP

    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      Standards Track                          15
iSNS                          March 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 (FQDN): "gtwy1.foo.com"           |
    |                  -Type: iFCP                                  |
    |                                                               |
    +---------------------------------------------------------------+

4.6.3     FCIP
















Gibbons, Tseng, Monia      Standards Track                          16
iSNS                          March 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 (FQDN):     |    |     -Entity ID (FQDN):          |
    |   "Tunnelgtwy1.foo.com" |    |      "Tunnelgtwy2.bar.com"      |
    |  -Type: FCIP            |    |     -Type: FCIP                 |
    +-------------------------+    +---------------------------------+

5.       iSNS Implementation Requirements

    iSNS can be implemented with features to support any combination of
    the following protocols: iSCSI, iFCP, and FCIP.  Implementation of
    support for any or all of these protocols is OPTIONAL. IF iSNS is
    implemented to support a particular protocol, then a minimum set of
    attributes and iSNSP commands is REQUIRED for support of that
    protocol. This section details specific requirements for support of
    each of these IP storage protocols.

5.1      iSCSI Requirements

    Use of iSNS in support of iSCSI is OPTIONAL.  iSCSI devices MAY be
    manually configured with the WWUI and IP address of peer devices,
    without the aid or intervention of iSNS.  iSCSI devices also MAY
    use SLP [RFC 2608] to discover peer iSCSI devices.  However, for
    scaling a storage network to a larger number of iSCSI devices, use
    of iSNS is RECOMMENDED.

5.1.1    Required Attributes for Support of iSCSI

    The following attributes are available to support iSCSI.
    Attributes indicated in the REQUIRED TO IMPLEMENT column MUST be
    supported by an iSNS server used to support iSCSI.  Attributes
    indicated in the REQUIRED TO USE column MUST be supported by an
    iSCSI device that elects to use the iSNS.





Gibbons, Tseng, Monia      Standards Track                          17
iSNS                          March 2001

                                                REQUIRED     REQUIRED
    Object                Attribute           to Implement   to Use
    ------                ---------           ------------   --------
    NETWORK ENTITY     Entity Identifier            *           *
                       Entity Type                  *           *
                       Management IP Address
                       ESI Interval                 *
                       Timestamp                    *
                       Entity Certificate           *
                       SCN Event Bitmap             *
                       ESI TCP/UDP Port             *           *

    PORTAL             IP Address                   *           *
                       TCP/UDP Port                 *           *
                       Portal Symbolic Name         *

    STORAGE NODE       WWUI                         *           *
                       Node Type                    *           *
                       Alias/Symbolic Node Name     *
                       Node Certificate             *

    DISCOVERY DOMAIN   DD_ID                        *           *
                       DD_Symbolic Name             *
                       DD Member (Entity ID)        *
                       DD_Member (WWUI)             *           *
                       DD_Member (IP Address)       *

    All iSCSI user-specified and vendor-specified attributes are
    optional to implement and use.

5.1.2    Attribute Descriptions for iSCSI Storage Systems

    The iSNS attributes used to represent iSCSI Storage Systems are
    shown and described in the following diagram:




















Gibbons, Tseng, Monia      Standards Track                          18
iSNS                          March 2001

    - iSCSI NETWORK ENTITY
        |
        - 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.
        - Entity Type
        |    Indicates this is an iSCSI registration
        - Mgt IP-Address
        |    If it is not registered then in-band management
        |    is assumed.
        - Entity Status Inquiry Interval
        |    If 0 no status inquiry is used
        - Timestamp
        |    Timestamp of last registration update
        - Entity Certificate
        |    X.509 certificate bound to the Entity (FQDN)
        - SCN Event Bitmap
        |    Indicates current SCN state
        - ESI TCP/UDP Port
             Destination port number for ESI messages
        - PORTAL (1 - n per ENTITY)
        |   |
        |   - IP-Address
        |   - TCP/UDP Port
        |   |    The IP-Addr and Port together uniquely
        |   |    define a portal.
        |   - Portal Symbolic Name
        |
        - STORAGE NODE (1 - m per ENTITY)
            |
            - WWUI (World-Wide Unique Identifier)
            - Node Type (initiator / target / ...)
            - Alias/Symbolic Node Name
            - Node Certificate

5.1.3    Example iSCSI Object Model Diagrams

    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      Standards Track                          19
iSNS                          March 2001

    +----------------------------------------------------------------+
    |                         IP Network                             |
    +------------+--------------------------------------+------------+
                 |                                      |
                 |                                      |
    +-----+------+------+-----+            +-----+------+------+-----+
    |     | PORTAL      |     |            |     | PORTAL      |     |
    |     | -IP Addr 1  |     |            |     | -IP Addr 2  |     |
    |     | -TCP Port 1 |     |            |     | -TCP Port 2 |     |
    |     +-----+ +-----+     |            |     +-----+ +-----+     |
    |           | |           |            |           | |           |
    |           | |           |            |           | |           |
    |  +--------+ +--------+  |            |   +-------+ +--------+  |
    |  |                   |  |            |   |                  |  |
    |  |  STORAGE NODE     |  |            |   |  STORAGE NODE    |  |
    |  |  -WWUI            |  |            |   |   -WWUI          |  |
    |  |  -Alias: "server1"|  |            |   |   -Alias: "disk1"|  |
    |  |  -Type: initiator |  |            |   |   -Type: target  |  |
    |  |                   |  |            |   |                  |  |
    |  +-------------------+  |            |   +------------------+  |
    |                         |            |                         |
    |    NETWORK ENTITY       |            |    NETWORK ENTITY       |
    |   -Entity ID (FQDN):    |            |   -Entity ID (FQDN):    |
    |    "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      Standards Track                          20
iSNS                          March 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        |  |
    |  |  -Alias: "disk1"| |  -Alias: "disk2"| |  -Alias: "disk3"|  |
    |  |  -Type: target  | |  -Type: target  | |  -Type: target  |  |
    |  |                 | |                 | |                 |  |
    |  +-----------------+ +-----------------+ +-----------------+  |
    |                                                               |
    |                         NETWORK ENTITY                        |
    |                    -Entity ID (FQDN): "dev1.foo.com"          |
    |                    -Type: iSCSI                               |
    |                                                               |
    +---------------------------------------------------------------+

5.1.4    Required Commands and Response Messages for Support of iSCSI

    The following are iSNSP messages and responses are available in
    support of iSCSI.  Messages indicated in the REQUIRED TO IMPLEMENT
    column MUST be implemented in iSNS servers used for iSCSI devices.
    Messages indicated in the REQUIRED TO USE column must be
    implemented in iSCSI devices that elect to use the iSNS.


















Gibbons, Tseng, Monia      Standards Track                          21
iSNS                          March 2001

                                                      REQUIRED TO:
       Message Description    Abbreviation  Func ID  Implement  Use
       -------------------    ------------  -------  ---------  ---
    Register Dev Attr Req     RegDevAttr    0x0001       *       *
    Dev Attr Query Request    DevAttrQry    0x0002       *       *
    Dev Get Next Request      DevGetNext    0x0003       *
    Deregister Dev Request    DeregDev      0x0004       *       *
    SCN Register Request      SCNReg        0x0005       *
    SCN Deregister Request    SCNDereg      0x0006       *
    SCN Event                 SCNEvent      0x0007       *
    State Change Notification SCN           0x0008       *
    Register DD               RegDD         0x0009       *       *
    Deregister DD             DeregDD       0x000A       *       *
    Register Dev in DD        RegDevDD      0x000B       *       *
    Deregister Dev in DD      DeregDevDD    0x000C       *       *
    Entity Status Inquiry     ESI           0x000D       *
    Name Service Heartbeat    Heartbeat     0x000E
    NOT USED                                0x000F
    Request Network Time      RqstTime      0x0010
    NOT USED                                0x0011-0x0012
    RESERVED                                0x0013-0x8000

    The following are iSNSP response messages used in support of iSCSI:

                                                      REQUIRED TO:
    Response Message Desc     Abbreviation  Func_ID  Implement  Use
    ---------------------     ------------  -------  ---------  ---
    Register Dev Attr Rsp     RegDevRsp     0x8001       *       *
    Dev Attr Query Resp       DevAttrQryRsp 0x8002       *       *
    Dev Get Next Resp         DevGetNextRsp 0x8003       *
    Deregister Dev Resp       DeregDevRsp   0x8004       *       *
    SCN Register Resp         SCNRegRsp     0x8005       *
    SCN Deregister Resp       SCNDeregRsp   0x8006       *
    SCN Event Resp            SCNEventRsp   0x8007       *
    SCN Response              SCNRsp        0x8008       *
    Register DD Resp          RegDDRsp      0x8009       *       *
    Deregister DD Resp        DeregDDRsp    0x800A       *       *
    Register Dev in DD Resp   RegDevDDRsp   0x800B       *       *
    Deregister Dev in DD Resp DeregDevDDRsp 0x800C       *       *
    Entity Stat Inquiry Resp  ESIRsp        0x800D       *
    NOT USED                                0x800E-0x800F
    Request Net Time Resp     RqstTimeRsp   0x8010
    NOT USED                                0x8011-0x8012
    RESERVED                                0x8013-0xFFFF

5.2      iFCP Requirements

    In iFCP, use of iSNS is REQUIRED.  No alternatives exist for
    support of iFCP Naming & Discovery functions.  iSNS is integral to
    the operation of iFCP, in order to allow iFCP gateways to execute
    Fibre Channel S_ID and D_ID address mappings to remote gateways.

5.2.1    Required Attributes for Support of iFCP

Gibbons, Tseng, Monia      Standards Track                          22
iSNS                          March 2001


    The following table displays attributes that are used by iSNS to
    support iFCP.  Attributes indicated in the REQUIRED TO IMPLEMENT
    column MUST be supported by the iSNS server that supports iFCP.
    Attributes indicated in the REQUIRED TO USE column MUST be
    supported by iFCP gateways.

                                                REQUIRED     REQUIRED
    Object                Attribute           to Implement    to Use
    ------                ---------           ------------   --------
    NETWORK ENTITY     Entity Identifier            *           *
                       Entity Type                  *           *
                       Management IP Address
                       ESI Interval                 *           *
                       Timestamp                    *
                       Entity Certificate           *
                       SCN Event Bitmap             *
                       ESI TCP/UDP Port             *           *

    PORTAL             IP Address                   *           *
                       TCP/UDP Port                 *           *
                       Portal Symbolic Name         *

    STORAGE NODE       Node Name                    *           *
                       Node Type                    *           *
                       Alias/Node Symbolic Name     *
                       FC Node IP Address           *
                       FC Node IPA                  *
                       Node Certificate             *

    DISCOVERY DOMAIN   DD_ID                        *           *
                       DD_Symbolic Name             *
                       DD Member (Entity ID)        *
                       DD_Member (IP Address)       *
                       DD Member (WWPN)             *           *
                       DD Member (WWNN)             *

    STORAGE PORT       Port Name (WWPN)             *           *
                       Port_ID                      *           *
                       Port Type                    *           *
                       Port Symbolic Name           *
                       FC Fabric Port Name (FWWN)   *
                       FC Hard Address              *
                       FC Port IP Address           *
                       FC Class of Service          *
                       FC FC-4 Types                *
                       FC FC-4 Descriptors          *
                       FC FC-4 Features             *

5.2.2    Attribute Descriptions for iFCP Gateways and FC devices

    The iSNS attributes used to represent iFCP Storage Systems are
    shown and described in the following figure:

Gibbons, Tseng, Monia      Standards Track                          23
iSNS                          March 2001


    - iFCP NETWORK ENTITY
        |
        - 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.
        - Entity Type
        |    Indicates this is an iFCP registration
        - Management IP-Address
        |    If it is not registered then in-band management
        |    is assumed.
        - Entity Status Inquiry Interval
        |    0 if no status inquiry is used
        - Timestamp
        |    Last registration update.  Maintained by the iSNS.
        - Entity Certificate
        |    X.509 certificate bound to the Entity (FQDN)
        - SCN Event Bitmap
        |    Indicates current SCN state
        - ESI TCP/UDP Port
        |    Destination port number for ESI messages
        |
        - PORTAL (1 - n per ENTITY)
        |   |
        |   - IP-Address
        |   - TCP/UDP Port
        |   |    The IP-Address and Port combined uniquely
        |   |    define a portal.
        |   - Portal Symbolic Name
        |
        - NODE (1 - m per ENTITY)
           |
           - Node Name (WWNN)
           - Node Type (initiator / target / ...)
           - Alias/Node Symbolic Name
           - FC Node IP-Address
           - FC Node IPA
           - Node Certificate
           |
           - PORT (1 - k per NODE)
              |
              - Port Name (WWPN)
              - Port ID
              - Port Type
              - Port Symbolic Name
              - FC Fabric Port Name (FWWN)
              - FC Hard Address
              - FC Port IP Address
              - FC Class of Service
              - FC FC-4 Types
              - FC FC-4 Descriptor

Gibbons, Tseng, Monia      Standards Track                          24
iSNS                          March 2001

              - FC FC-4 Features

5.2.3    iFCP Attribute Requirements

5.2.3.1  Port_ID

    Port_ID assignments for each STORAGE PORT object within a single
    NETWORK ENTITY SHALL be unique.  For each NETWORK ENTITY (i.e.,
    iFCP gateway), no more than one STORAGE PORT can be assigned a
    given PORT_ID value.

5.2.4    Example iFCP Object Model Diagram

    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      Standards Track                          25
iSNS                          March 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 (FQDN): "gtwy1.foo.com"           |
    |                  -Type: iFCP                                  |
    |                                                               |
    +---------------------------------------------------------------+

5.2.5    Required Commands and Response Messages for Support of iFCP

    The iSNSP messages and responses displayed in the following tables
    are available to support iFCP gateways.  Messages indicated in the
    REQUIRED TO IMPLEMENT column MUST be supported by the iSNS server
    used by iFCP gateways.  Messages indicated in the REQUIRED TO USE
    column MUST be supported by the iFCP gateways themselves.










Gibbons, Tseng, Monia      Standards Track                          26
iSNS                          March 2001

                                                      REQUIRED TO:
       Message Description    Abbreviation  Func ID  Implement  Use
       -------------------    ------------  -------  ---------  ---
    Register Dev Attr Req     RegDevAttr    0x0001       *       *
    Dev Attr Query Request    DevAttrQry    0x0002       *       *
    Dev Get Next Request      DevGetNext    0x0003       *
    Deregister Dev Request    DeregDev      0x0004       *       *
    SCN Register Request      SCNReg        0x0005       *
    SCN Deregister Request    SCNDereg      0x0006       *
    SCN Event                 SCNEvent      0x0007       *
    State Change Notification SCN           0x0008       *
    Register DD               RegDD         0x0009       *       *
    Deregister DD             DeregDD       0x000A       *       *
    Register Dev in DD        RegDevDD      0x000B       *       *
    Deregister Dev in DD      DeregDevDD    0x000C       *       *
    Entity Status Inquiry     ESI           0x000D       *
    Name Service Heartbeat    Heartbeat     0x000E       *
    Reserved                  Reserved      0x000F
    Request Network Time      RqstTime      0x0010
    Request Domain ID         RqstDmnId     0x0011
    Release Domain ID         RlseDmnId     0x0012
    Get Domain IDs            GetDmnIds     0x0013
    RESERVED                                0x0014-0x8000

    The following are iSNSP response messages in support of iFCP:

                                                      REQUIRED TO:
    Response Message Desc     Abbreviation  Func_ID  Implement  Use
    ---------------------     ------------  -------  ---------  ---
    Register Dev Attr Rsp     RegDevRsp     0x8001       *       *
    Dev Attr Query Resp       DevAttrQryRsp 0x8002       *       *
    Dev Get Next Resp         DevGetNextRsp 0x8003       *
    Deregister Dev Resp       DeregDevRsp   0x8004       *       *
    SCN Register Resp         SCNRegRsp     0x8005       *
    SCN Deregister Resp       SCNDeregRsp   0x8006       *
    SCN Event Resp            SCNEventRsp   0x8007       *
    SCN Response              SCNRsp        0x8008       *
    Register DD Resp          RegDDRsp      0x8009       *       *
    Deregister DD Resp        DeregDDRsp    0x800A       *       *
    Register Dev in DD Resp   RegDevDDRsp   0x800B       *       *
    Deregister Dev in DD Resp DeregDevDDRsp 0x800C       *       *
    Entity Stat Inquiry Resp  ESIRsp        0x800D       *
    NOT USED                                0x800E-0x800F
    Request Net Time Resp     RqstTimeRsp   0x8010
    Request Domain ID Resp    RqstDmnIdRsp  0x8011
    Release Domain ID Resp    RlseDmnIdRsp  0x8012
    Get Domain IDs            GetDmnIds     0x0013
    RESERVED                                0x8014-0xFFFF

5.3      FCIP Requirements

    Use of iSNS in support of FCIP is OPTIONAL.  iSNS MAY be used to
    provide dynamic tunnel endpoint discovery.  iSNS MAY also be used

Gibbons, Tseng, Monia      Standards Track                          27
iSNS                          March 2001

    to allocate DOMAIN_ID addresses, in an FCIP/Fibre Channel fabric
    implementation with multiple Autonomous Regions.

5.3.1    Required Attributes for Support of FCIP

    The following lists attributes used in support of FCIP.  Attributes
    indicated in the REQUIRED TO IMPLEMENT column MUST be supported by
    the iSNS server.  Attributes indicated in the REQUIRED TO USE
    column MUST be supported by an FCIP gateway that elects to use the
    iSNS for dynamic tunnel endpoint discovery.

                                                REQUIRED     REQUIRED
    Object                Attribute           to Implement    to Use
    ------                ---------           ------------   --------
    NETWORK ENTITY     Entity Identifier            *           *
                       Entity Type                  *           *
                       Management IP Address
                       ESI Interval                 *           *
                       Timestamp                    *
                       Entity Certificate           *
                       SCN Event Bitmap             *
                       ESI TCP/UDP Port             *

    PORTAL             IP Address                   *           *
                       TCP/UDP Port                 *           *
                       Portal Symbolic Name         *

5.3.2    Attribute Descriptions for FCIP Gateways

    The iSNS attributes used to represent FCIP gateways are shown and
    described in the following figure:

    - FCIP NETWORK ENTITY
        |
        - 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.
        - Entity Type
        |    Indicates this is an FCIP registration
        - Mgt IP-Address
        |    If it is not registered then in-band management
        |    is assumed.
        - Entity Status Inquiry Interval
        |    0 if no status inquiry is used
        - Timestamp
        |    Last registration update / status inquiry received
        - Entity Certificate
        |    X.509 certificate bound to the Entity (FQDN)
        - SCN Event Bitmap
        |    Indicates current SCN state
        - ESI TCP/UDP Port

Gibbons, Tseng, Monia      Standards Track                          28
iSNS                          March 2001

        |    Destination port number for ESI messages
        - PORTAL (1 - n per ENTITY)
            |
            - Index
            - IP-Address
            - TCP/UDP Port
            |    The IP-Addr and Port combined uniquely
            |    define a portal.
            - Portal Symbolic Name

5.3.3     Example FCIP Object Model Diagram

    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 (FQDN):     |    |     -Entity ID (FQDN):          |
    |   "Tunnelgtwy1.foo.com" |    |      "Tunnelgtwy2.bar.com"      |
    |  -Type: FCIP            |    |     -Type: FCIP                 |
    +-------------------------+    +---------------------------------+

5.3.4    Required Commands and Response Messages for Support of FCIP

    The following tables display iSNS messages and responses that are
    used to support FCIP.  Messages indicated in the REQUIRED TO
    IMPLEMENT column MUST be supported by the iSNS server used to
    support FCIP.  Messages indicated in the REQUIRED TO USE column
    MUST be supported by the FCIP gateway that elects to use the iSNS.












Gibbons, Tseng, Monia      Standards Track                          29
iSNS                          March 2001

                                                      REQUIRED TO:
       Message Description    Abbreviation  Func ID  Implement  Use
       -------------------    ------------  -------  ---------  ---
    Register Dev Attr Req     RegDevAttr    0x0001       *       *
    Dev Attr Query Request    DevAttrQry    0x0002       *       *
    Dev Get Next Request      DevGetNext    0x0003       *
    Deregister Dev Request    DeregDev      0x0004       *       *
    SCN Register Request      SCNReg        0x0005       *
    SCN Deregister Request    SCNDereg      0x0006       *
    SCN Event                 SCNEvent      0x0007       *
    State Change Notification SCN           0x0008       *
    Register DD               RegDD         0x0009       *       *
    Deregister DD             DeregDD       0x000A       *       *
    Register Dev in DD        RegDevDD      0x000B       *       *
    Deregister Dev in DD      DeregDevDD    0x000C       *       *
    Entity Status Inquiry     ESI           0x000D       *
    Name Service Heartbeat    Heartbeat     0x000E       *
    Reserved                  Reserved      0x000F
    Request Network Time      RqstTime      0x0010
    Request Domain ID         RqstDmnId     0x0011
    Release Domain ID         RlseDmnId     0x0012
    Get Domain IDs            GetDmnIds     0x0013
    RESERVED                                0x0014-0x8000

    The following are iSNSP response messages in support of FCIP:

                                                      REQUIRED TO:
    Response Message Desc     Abbreviation  Func_ID  Implement  Use
    ---------------------     ------------  -------  ---------  ---
    Register Dev Attr Rsp     RegDevRsp     0x8001       *       *
    Dev Attr Query Resp       DevAttrQryRsp 0x8002       *       *
    Dev Get Next Resp         DevGetNextRsp 0x8003       *
    Deregister Dev Resp       DeregDevRsp   0x8004       *       *
    SCN Register Resp         SCNRegRsp     0x8005       *
    SCN Deregister Resp       SCNDeregRsp   0x8006       *
    SCN Event Resp            SCNEventRsp   0x8007       *
    SCN Response              SCNRsp        0x8008       *
    Register DD Resp          RegDDRsp      0x8009       *       *
    Deregister DD Resp        DeregDDRsp    0x800A       *       *
    Register Dev in DD Resp   RegDevDDRsp   0x800B       *       *
    Deregister Dev in DD Resp DeregDevDDRsp 0x800C       *       *
    Entity Stat Inquiry Resp  ESIRsp        0x800D       *
    NOT USED                                0x800E-0x800F
    Request Net Time Resp     RqstTimeRsp   0x8010
    Request Domain ID Resp    RqstDmnIdRsp  0x8011
    Release Domain ID Resp    RlseDmnIdRsp  0x8012
    Get Domain IDs Resp       GetDmnIdsRsp  0x8013
    RESERVED                                0x8014-0xFFFF

5.4      Attribute Descriptions for Discovery Domain Registration




Gibbons, Tseng, Monia      Standards Track                          30
iSNS                          March 2001

    Discovery Domains are a required iSNS attribute for all protocols.
    The iSNS attributes for Discovery Domain registration are shown in
    the following figure:

    DISCOVERY DOMAIN
       |
       - DD_ID
       - DD_Symbolic Name

    DD_MEMBER
       |
       - DD_ID
       - Entity Identifier, WWUI, WWNN, WWPN, IP-Address or FWWN

    Members of a Discovery Domain can be defined by registering one of
    the following storage entity attributes in a Discovery Domain:

         - Entity Identifier: this places all contained iSCSI or
                              iFCP storage nodes, or FCIP gateways,
                              in the Discovery Domain
         - WWUI             : this places the individual iSCSI
                              storage node in the Discovery Domain
         - WWNN             : this places all associated iFCP
                              ports in the Discovery Domain
         - WWPN             : this places the associated iFCP
                              port in the Discovery Domain
         - FWWN             : this places all iFCP ports
                              attached to the Fabric Port in
                              the Discovery Domain
         - IP-Address       : this places all associated iSCSI storage
                              nodes or FCIP storage entities in the
                              Discovery Domain

    Discovery Domains are logical groupings of initiators and targets
    that are used to limit the login process to the appropriate subset
    of devices registered in the iSNS.  Discovery Domains are described
    in Section 3.1.2.

6.       iSNS Message Protocol

    The iSNSP message format is similar to the format of other common
    protocols such as DHCP, DNS and BOOTP.  An iSNSP message may be
    sent in one or more iSNS Protocol Data Units (PDU). The following
    describes the format of the iSNSP PDU:










Gibbons, Tseng, Monia      Standards Track                          31
iSNS                          March 2001

    Byte   MSb                                        LSb
    Offset 31                                           0
           +---------------------+----------------------+
         0 |   iSNSP VERSION     |    FUNCTION ID       | 4 Bytes
           +---------------------+----------------------+
         4 |     PDU LENGTH      |       FLAGS          | 4 Bytes
           +---------------------+----------------------+
         8 |   TRANSACTION ID    |    SEQUENCE ID       | 4 Bytes
           +---------------------+----------------------+
        12 |                                            |
           |                PDU PAYLOAD                 | N Bytes
           |                    ...                     |
           +--------------------------------------------+
    12 + N |    AUTHENTICATION BLOCK (if present)       | L Bytes
           +--------------------------------------------+
                      Total Length = 12 + N

6.1      iSNS PDU Header

    The iSNSP header contains the iSNSP VERSION, FUNCTION ID, PDU
    LENGTH, FLAGS, TRANSACTIONID, and SEQUENCE ID fields as defined
    below:

    iSNSP VERSION - Currently 0x0001

    FUNCTION ID defines the type of iSNS message.  It indicates the
    function the message is supporting.  See section 5 under the
    appropriate protocol (i.e., iSCSI, iFCP, and/or FCIP) for a mapping
    of the FUNCTION_ID value to the iSNSP Command or Response message.
    All PDU's comprising an iSNSP message must have the same
    FUNCTION_IDand TRANSACTION ID value.

    iSNS PDU LENGTH - Specifies the length of the PDU PAYLOAD field in
    bytes.The payload contains the data/attribute values for the
    operation.

    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            Enabled Means:
    ---------            -------------
      0-9                RESERVED
       10                First PDU of the iSNS message
       11                Last PDU of the iSNS message
       12                Update Flag (used only for RegDevAttr)
       13                Authentication Block Present
       14                Sender is the iSNS server
       15                Sender is the iSNS client

    TRANSACTION ID - Is set to a unique random value for each request
    message.  Replies MUST use the same TRANSACTION ID value as the


Gibbons, Tseng, Monia      Standards Track                          32
iSNS                          March 2001

    associated iSNS request message.  If a message is retransmitted,
    the same TRANSACTION ID value MUST be used.

    SEQUENCE ID - Is set to a unique value for each PDU within a single
    transaction.  Each SEQUENCE_ID value in each PDU SHALL be numbered
    sequentially in the order that the PDU's are transmitted.  If a
    message is retransmitted, then the same SEQUENCE_ID value MUST be
    used for all PDU's in the message.

6.2      iSNS Message Segmentation and Reassembly

    iSNS messages may be carried in one or more iSNS PDU's.  If only
    one iSNS PDU is used to carry the iSNS message, then bit 10 (First
    PDU) and bit 11 in the FLAGS field (Last PDU) SHALL both be
    enabled.  If multiple PDUs are used to carry the iSNS message, then
    bit 10 SHALL be enabled in the first PDU of the message, and bit 11
    SHALL be enabled in the last PDU.

    All PDU's comprising the same iSNSP message SHALL have the same
    FUNCTION_ID and TRANSACTION_ID values.  Each PDU comprising an
    iSNSP message SHALL have a unique SEQUENCE_ID value.  The recipient
    of the iSNSP message SHALL NOT process the message until it
    receives

    The authentication operation described in section 6.4 SHALL be
    performed on a per-PDU basis.

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

    Byte   MSb                                        LSb
    Offset 31                                           0
           +--------------------------------------------+
         0 |               Attribute Tag                | 4 Bytes
           +--------------------------------------------+
         4 |            Attribute Length (N)            | 4 Bytes
           +--------------------------------------------+
         8 |                                            |
           |              Attribute Value               | N Bytes
           |                                            |
           +--------------------------------------------+
                       Total Length = 8 + N

    Attribute Tag - a 4-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      Standards Track                          33
iSNS                          March 2001

    Attribute Length - a 4-byte field that indicates the length, in
    bytes, of the attribute value to follow.

    Attribute 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 included as the first field in the iSNSP
    PAYLOAD.  This field contains 0x00000000 (NO ERROR) if the original
    iSNSP request message was processed normally by the iSNS server.

        Error Code       Error Description
        ----------       -----------------
           0             No Error
           1             Unknown Error
           2             Message Format Error
           3             Invalid Registration
           4             Invalid Registration Update
           4             Invalid Query
           5             Authentication Unknown
           6             Authentication Absent
           7             Authentication Failed
           8             No Such Entry
           9             Version Not Supported
          10             Internal Bus Error
          11             Busy Now
          12             Option Not Understood
          13             Invalid Update
          14             Message Not Supported
          15             SCN Event Rejected
          16             SCN Registration Rejected
          17             Entity Status Inquiry (ESI) Not Available
          18             DOMAIN_ID not available

    For iSNS State Change Notification message and Request Network Time
    Response messages, a 4-byte TIMESTAMP field is included. The
    TIMESTAMP is a 4-byte unsigned, fixed-point integer giving the
    number of seconds since 00:00:00 GMT on January 1, 1970.

6.4      Message Authentication

    iSNSP provides an optional PDU 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.



Gibbons, Tseng, Monia      Standards Track                          34
iSNS                          March 2001

    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
    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 iSNSP PDU.  The digital signature is calculated on a per-PDU
    basis.  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   |   AUTHENTICATION BLOCK LENGTH    |     2 Bytes
              +----------------------------------+
          2   |    BLOCK STRUCTURE DESCRIPTOR    |     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

    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.

    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

Gibbons, Tseng, Monia      Standards Track                          35
iSNS                          March 2001

    PKI specification, allowing easy integration of the STRUCTURED
    AUTHENTICATOR format with an existing PKI infrastructure.

    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.

6.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      Standards Track                          36
iSNS                          March 2001

    Attribute Name    Length(bytes) Tag  Reg Key   Query Keys
    --------------    ------------- ---  -------   ----------
    Delimiter                 0      0     N/A     N/A
    Entity Identifier      0-255     1     N/A     1,3,17,32,34,64
    Entity Type               4      2      1      1,3,17,32,34,64
    Management IP Address    16      3      1      1,3,17,32,34,64
    ESI Interval              4      4      1      1,3,17,32,34,64
    ESI TCP/UDP Port          4      5      1      32,1&33,34,64
    Timestamp                 8      6      1      1,3,17,32,34,64
    Entity Event Bitmap       4      7      1      32,1&33,34,64
    Entity Certificate   variable    8      1      32,1&33,34,64
    Portal IP Address        16     16      1      1,32,64
    Portal TCP/UDP Port       4     17      1      1,32,64
    Portal Symbolic Name   0-255    18    16&17      1,32,64
    WWUI                   4-255    32      1      1,32,1&33
    Node Name (WWNN)          8     33      1      1,34,64
    Node Type                 4     34   32 or 33  32,1&33,34,64
    Alias/Symbolic Node Name 0-255  35   32 or 33  32,1&33,34,64
    FC Node IP Address       16     36     33      34,64
    FC Node IPA               8     37     33      34,64
    Node Certificate   variable     38   32 or 33  32,1&33,34,64
    Port Name (WWPN)          8     64     33      1,34,66,68,71,72
    Port ID                   4     65     64      64,17,65
    Port Type                 4     66     64      64,17&65
    Port Symbolic Name     0-255    67     64      64,17&65
    Fabric Port Name (FWWN)   8     68     64      64,17&65
    FC Hard Address           4     69     64      64,17&65
    FC Port IP Address       16     70     64      64,17&65
    FC Class of Service       4     71     64      64,17&65
    FC FC-4 Types            32     72     64      64,17&65
    FC FC-4 Descriptor     0-255    73     64      64,17&65
    FC FC-4 Features         128    74     64      64,17&65
    User-Specific-Entity  0-65536 128-255   1      --user defined--
    User-Specific-Portal  0-65536 256-383 16&17    --user defined--
    User-Spec-iSCSI-Node  0-65536 384-511  32      --user defined--
    User-Spec-iFCP-Node   0-65536 512-639  33      --user defined--
    User-Spec-iFCP-Port   0-65536 640-767  64      --user defined--
    RESERVED                      768-895
    Vendor-Specific-DD    0-65536 896-1023 101    --vendor defined--
    Vendor-Specific-DD    0-65536 896-1023 101    --vendor defined--
    Vendor-Specific       0-65536 1024-2047       --vendor defined--
    RESERVED                      2048-65535

    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.



Gibbons, Tseng, Monia      Standards Track                          37
iSNS                          March 2001

    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.

6.5.1    Entity Identifier-Keyed Attributes

    The following attributes are registered in the iSNS using the
    Entity Identifier attribute as the key.

6.5.1.1  Entity Identifier (DNS Name)

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

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


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

6.5.1.4  Entity Status Inquiry Interval


Gibbons, Tseng, Monia      Standards Track                          38
iSNS                          March 2001

    This optional field is provided by the iSNS client.  It indicates
    the minimum time, in seconds, between Entity Status Inquiry (ESI)
    messages sent from the iSNS to a client.  ESI messages can be used
    to verify that a client registration continues to be valid.  To
    request monitoring by the iSNS, 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 ESI messages, it SHALL reject the
    ESI request by returning a "ESI Not Available" error code.  The
    rejection might occur in situations where the resulting frequency
    of ESI 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 _ESI Not Available_, then the multi-attribute
    registration SHALL be resent with a ESI value of 0.

6.5.1.5  ESI TCP/UDP Port

    This is the TCP or UDP Port Number of the iSNS client entity uses
    to receive ESI messages from the iSNS server and transmit ESI
    responses.

6.5.1.6  Entity Registration Timestamp

    Indicates the time the client registration occurred, or the most
    recent response from the iSNS client to the Client Status Inquiry
    message, whichever is later.  It is the time, in milliseconds,
    after the standard base time of 00:00:00 GMT on January 1, 1970,
    that the update occurred.  The timestamp can be used to ensure the
    SNS directory does not contain entries for non-existent devices.
    An implementation may decide to remove stale registrations of iSNS
    clients that exceed an implementation-specific threshhold age
    limit.

6.5.1.7  Entity Event Bitmap

    This optional field is provided by the iSNS client.  It indicates
    the events that the client is interested in.  These events can
    cause SCN to be generated.

    Bit Field          Flag Description
    ---------          ----------------
        0              CHANGE IN DD MEMBERSHIP
        1              CHANGE IN NETWORK
        2              CHANGE IN DEVICE REGISTRATION PARAMETERS
        3              DEVICE ADDED
        4              DEVICE REMOVED
        5              CLIENT STATUS UPDATE REQUESTED (for CSI message)

6.5.1.8  Entity Certificate



Gibbons, Tseng, Monia      Standards Track                          39
iSNS                          March 2001

    This optional attribute contains an X.509 certificate that is bound
    to the NETWORK ENTITY of the iSNS client.  For example, in FCIP
    this X.509 certificate may have the Fully Qualified Domain Name of
    the FCIP gateway device.  This certificate is uploaded and
    registered to the iSNS by clients wishing to allow other clients to
    authenticate themselves and access the services offered by that
    NETWORK ENTITY.  This certificate MAY also be used to set up the
    TLS association between the iSNS client and server, as well as to
    key the authentication block in the iSNSP.

6.5.2    Portal-Keyed Attributes

    The following attributes are registered in the iSNS using the
    combined Portal IP-Address and Portal TCP/UDP Port as the key.
    Each set of Portal-Keyed attributes is also associated with one
    Entity Identifier object key.

    Although the combined Portal IP-Address and Portal TCP/UDP Port key
    is associated with one Entity Identifier, it is unique across the
    entire iSNS.

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

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

6.5.2.3 Portal Symbolic Name

    This is an optional, 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 Portal Symbolic
    Name is a user-readable description of the Portal entry in the
    iSNS.
6.5.3    Node-Keyed Attributes

    The following attributes are registered in the iSNS using the WWUI
    (for iSCSI) or WWNN (for iFCP) attribute as the key.  Each set of
    Node-Keyed attributes is also associated with one Entity Identifier
    object key.


Gibbons, Tseng, Monia      Standards Track                          40
iSNS                          March 2001

    Although the WWUI (for iSCSI) or WWNN (for iFCP) key is associated
    with one Entity Identifier, it is unique across the entire iSNS.

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

6.5.3.2  Alias/Symbolic Node Name

    This is an optional, 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 Alias is a user-
    readable description of the node entry in the iSNS.  The Node
    Symbolic Name is available for use by both Fibre Channel and iSCSI
    clients.

6.4.3.3  Node Name (WWNN)

    Node Name is a 64-bit identifier that uniquely identifies the iFCP
    device node in the network, and is provided by a Fibre Channel-
    based iSNS client entity. This globally unique identifier is used
    during the device registration process, and uses a value 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].

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

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

6.5.3.5  FC Node IPA


Gibbons, Tseng, Monia      Standards Track                          41
iSNS                          March 2001

    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.

6.5.3.6  Node Certificate

    This optional attribute contains an X.509 certificate that is bound
    to the STORAGE NODE of the iSNS client.  For example, in iSCSI this
    X.509 certificate may have the WWUI of the target device.  This
    certificate is uploaded and registered to the iSNS by clients
    wishing to allow other clients to authenticate themselves and
    access the STORAGE NODE.  This certificate SHOULD NOT be used to
    set up the authenticating SA supporting the iSNSP authentication
    block.

6.5.4    Storage Port-Keyed Attributes

    The following attributes are registered in the iSNS using the Port
    Name (WWPN) attribute as the key.  Each set of Port-Keyed
    attributes is also associated with one Node-Keyed object.

    Although the Port Name (WWPN) key is associated with one Node-Keyed
    object, it is unique across the entire iSNS.

6.5.4.1  Port Name (WWPN)

    This 64-bit identifier uniquely defines the iFCP device port, and
    is provided by a Fibre Channel-based iSNS client entity. This
    globally unique identifier is used during the device registration
    process, and uses a value 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].

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

6.5.4.3  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      Standards Track                          42
iSNS                          March 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

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

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

    The Fabric Port may itself be registered as a port in the iSNS.  In
    that case, the Fabric Port Name (FWWN) attribute of fabric attached
    ports will match the Port Name (WWPN) of the Fabric Port
    registration.

6.5.4.6  FC Hard Address

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

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

6.5.4.8  FC Class of Service (COS)

Gibbons, Tseng, Monia      Standards Track                          43
iSNS                          March 2001


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

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

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

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

6.5.5    Domain ID

    This is a 4-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
    Client Status Inquiry message to determine if an iFCP gateway is
    still present on the network.

6.6      Discovery Domain Registration Attributes

    iSNS clients can be placed into areas of control belonging to one
    or more Discovery Domains.  When an iSNS client or Network
    Management System registers a DD, it provides attribute values to
    describe the DD characteristics and capabilities.  The following
    table lists the iSNSP DD attributes:


Gibbons, Tseng, Monia      Standards Track                          44
iSNS                          March 2001

    Attribute Name     Size(bytes)    ID      Reg Key     Query Key
    --------------     -----------    --      -------     ---------
    DD_ID                   4        101                     101
    DD_Symbolic Name       1-64      102        101          101
    DD Member (Ent Ident)  0-255     103        101          101
    DD_Member (WWUI)       4-255     104        101          101
    DD_Member (WWPN)        8        105        101          101
    DD_Member (WWNN)        8        106        101          101
    DD_Member (FWWN)        8        107        101          101
    DD_Member (IP Addr)    16        108        101          101
    Vendor-Specific      0-65535   640-767      101          101

    DD_ID - a unique identifier used in the iSNS directory database to
    indicate the DD.  This value is used as the key for any DD
    attribute query. If the iSNS client does not provide a DD_ID in a
    DD registration request message, the iSNS shall generate a DD_ID
    value that is unique within the iSNS database for that new DD
    (i.e., the iSNS client will be registered in a new DD).  The DD ID
    value of 0 is reserved.

    DD_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 DD function.  When
    registered by a client, the DD symbolic name SHALL be verified
    unique by the iSNS.  If the DD symbolic name is not unique, then
    the DD registration SHALL be rejected with an _Invalid
    Registration_ error code.  The invalid attribute(s), in this case
    the DD symbolic name, SHALL be included in the response.

    DD_Member (WWUI) - the Entity Identifier of an iSNS client that is
    a member of the DD.  The DD may have a list of 0 to n members.
    Membership is represented by the Entity Identifier of the iSNS
    client being listed.

    DD_Member (WWUI) - the World Wide Unique Identifier of an iSNS
    client that is a member of the DD.  The DD may have a list of 0 to
    n members.  Membership is represented by the WWUI of the iSNS
    client being listed.

    DD_Member (WWPN) - the Port Name of an iSNS client that is a member
    of the DD.  The DD may have a list of 0 to n members.  Membership
    is represented by the Port Name (WWPN) of the iSNS client being
    listed.

    DD_Member (WWNN) - the Node Name of an iSNS client that is a member
    of the DD.  The DD may have a list of 0 to n members.  Membership
    is represented by the Node Name (WWNN) of the iSNS client being
    listed.

    DD_Member (FWWN) - the Fabric World Wide Name of an iSNS client
    that is a member of the DD.  The DD may have a list of 0 to n
    members.  Membership is represented by the FWWN of the iSNS client
    being listed.

Gibbons, Tseng, Monia      Standards Track                          45
iSNS                          March 2001


    DD_Member (IP Addr) - the IP address of an iSNS client that is a
    member of the DD.  The DD 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 DD.

6.7      Vendor-Specific and User-Specific Attributes

    Specific iSNS implementations MAY define vendor-specific attributes
    for private use.  The tag values reserved for vendor-specific and
    user-specific use are defined in section 6.5 and 6.6.  To avoid
    misinterpreting proprietary attributes, it is RECOMMENDED that the
    vendor's own OUI (Organizationally Unique Identifier) be placed in
    the upper three bytes of the attribute field itself.  If the OUI is
    not used, then some other unique marker recognizable by the vendor
    SHOULD be used.  The OUI is defined in IEEE Std 802-1990, and is
    the same constant used to generate 48 bit Universal LAN MAC
    addresses.  A vendor's own iSNS implementation will then be able to
    recognize the OUI in the vendor-specific or user-specific attribute
    field, and be able to execute vendor-specific handling of the
    attribute.

6.8      State Change Notification and Client Status Inquiry Flags

    A State Change Notification (SCN) allows an iSNS client to be
    notified of changes within a DD, 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.

    Client Status Inquiry (CSI) allows an iSNS server to verify that an
    iSNS client entity is still connected to the network.  The CSI
    message is sent to the iSNS client by the server to verify client
    status.  If enabled, the iSNS server will send a CSI to request a
    Client Status Inquiry Update message from the SCE.

    The following table displays the flags in the EVENT TYPE FLAGS
    field used in SCNReg, SCN and CSI messages:

    Bit Field          Flag Description
    ---------          ----------------
        0              CHANGE IN DD MEMBERSHIP
        1              CHANGE IN NETWORK
        2              CHANGE IN DEVICE REGISTRATION PARAMETERS
        3              DEVICE ADDED
        4              DEVICE REMOVED
        5              CLIENT STATUS UPDATE REQUESTED (for CSI message)



Gibbons, Tseng, Monia      Standards Track                          46
iSNS                          March 2001

    CHANGE IN DD MEMBERSHIP - indicates a change has occurred in a DD
    that the iSNS client is a member of.  A client can be a member of
    multiple DDs.  This flag indicates that a change in registration
    parameters or membership has occured, either an addition or
    deletion, to a DD 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 DDs that the client is a
    member of.  This flag is used in conjunction with CHANGE IN DD
    MEMBERSHIP and CHANGE IN NETWORK flags indicate whether the change
    in device registration occurred in a DD or the network.  This flag
    may be administratively enabled/disabled.

    DEVICE ADDED - indicates a device addition has occurred in the
    network or DD. This flag is used in conjunction with CHANGE IN DD
    MEMBERSHIP and CHANGE IN NETWORK flags indicate whether the
    addition occurred in a DD or the network.

    DEVICE REMOVED - indicates a device removal has occurred in the
    network or DD. This flag is used in conjunction with CHANGE IN DD
    MEMBERSHIP and CHANGE IN NETWORK flags indicate whether the removal
    occurred in a DD or the network.

7.       iSNSP Message Descriptions

    The iSNSP PDU payload follows the iSNSP PDU header described in
    section 6.1.  The message payload contains a list of attributes,
    each in TLV format described in section 6.3.

7.1      Registration and Query Messages

    The iSNSP registration and query message payloads contain a list of
    attributes, and have the following format:















Gibbons, Tseng, Monia      Standards Track                          47
iSNS                          March 2001

              MSb                                    LSb
              31                                       0
              +----------------------------------------+
              |         Source Attribute               |
              +----------------------------------------+
              |         Key Attribute[1]               |
              +----------------------------------------+
              |         Key Attribute[2] (if present)  |
              +----------------------------------------+
              |         Key Attribute[3] (if present)  |
              +----------------------------------------+
              |                 . . .                  |
              +----------------------------------------+
              |       - Delimiter Attribute -          |
              +----------------------------------------+
              |   Operating Attribute[1]               |
              +----------------------------------------+
              |   Operating Attribute[2] (if present)  |
              +----------------------------------------+
              |   Operating Attribute[3] (if present)  |
              +----------------------------------------+
              |                 . . .                  |
              +----------------------------------------+

    iSNS Registration and Query messages, sent by iSNS Clients, are
    sent to the iSNS IP-Address and TCP/UDP Port.  The iSNS Responses
    will be sent to the iSNS Client IP-Address and the originating
    TCP/UDP Port used for the associated registration and query
    message.

7.1.1     Source Attribute

    The source attribute is used to identify the iSNS client to the
    iSNS server.  The source attribute is an attribute that uniquely
    identifies the source of the message.  Valid source attribute types
    are shown below.

            Valid Source Attributes
            -----------------------
            Entity Identifier
            WWUI (iSCSI only)
            Node WWN (iFCP only)
            Port WWN (iFCP only)

    The source attribute is used to bind the scope of a query into the
    Discovery Domains of which the source is a member.

    The iSNS may validate that the Source Attribute matches client
    certificate information.  If the iSNS is validating Source
    Attribute information, and the Source Attribute does not match the
    client certificate, then the request will be rejected with an
    authentication error code.


Gibbons, Tseng, Monia      Standards Track                          48
iSNS                          March 2001

7.1.1.1   Source Attribute for Initial Registration

    A length value of 0 in the source attribute TLV is valid for
    initial client registration when the iSNS is being used to assign a
    unique Entity Identifier to the client.  In this case, since the
    Entity Identifier will not yet have been assigned, the source
    attribute field will contain a 0 length Entity Identifier.  The
    response message to the registration will contain the assigned
    identifier.

7.1.2     Key Attribute

    Key attributes are used to identify the object (or objects) in the
    iSNS server that the registration or query operation will be
    performed on.  The number of Key Attributes depends on the specific
    iSNSP request or query operation being performed.  Following the
    set of Key Attributes is a Delimiter Attribute, whose tag value is
    0.

7.1.2.1   Key Attribute for Initial Registration

    A length value of 0 in the key attribute TLV is valid for initial
    client registration when the iSNS is being used to assign a unique
    Entity Identifier to the client.  In this case, the Entity
    Identifier will not yet have been assigned.  The key attribute
    field will contain a 0 length Entity Identifier.  The response
    message to the registration will contain the assigned identifier.

7.1.3     Delimiter Attribute

    The Delimiter Attribute separates the key and operating attributes
    in a message.  The Delimiter Attribute has a tag value of 0 and a
    length value of 0.  The Delimiter Attribute is effectively 8 Bytes
    long, a 4 Byte tag containing 0x00000000, and a 4 Byte length field
    containing 0x00000000.

7.1.4     Operating Attributes

    The Operating Attributes are a list of one or more attributes
    related to the actual iSNS registration or query operation being
    performed.

    The number of Operating Attributes depends on the specific iSNSP
    request or query.  For example, the Operating Attributes in a
    Device Attribute Query message are the set of attributes to be
    returned in the associated Device Attribute Query Response message
    that match the Key Attributes of the query.

    Some iSNSP messages do not require any Operating Attributes.

7.1.4.1   Operating Attributes for Query and Get Next Requests



Gibbons, Tseng, Monia      Standards Track                          49
iSNS                          March 2001

    A length value of 0 in an Operating Attribute TLV is valid for
    query request and get next messages, where the iSNS will be
    returning matching attribute values in the response message.  In
    this case the Operating Attributes indicate the desired attributes
    to be returned in the response and therefore do not require values.
    The response message will contain valid values for the Operating
    Attributes if the Key Attributes in the query or get next are
    matched.

7.1.5     Registration and Query Message Types

    The following describes each query and message type.

7.1.5.1   Register Device Attribute Request (RegDevAttr)

    The RegDevAttr message type is 0x0001. The RegDevAttr message
    provides an iSNS client with the means to register network
    entities.  The iSNS client formulates a RegDevAttr by specifying a
    Source, Key Attribute(s), and list of Operating Attributes to
    register.  All values are in Tag Length Value (TLV) format.  The
    Source attribute of the RegDevAttr message is as defined in Section
    7.1.1.

    For the initial network entity registration the Key Attribute SHALL
    be the Entity Identifier.  A length value of 0 in the key attribute
    TLV is valid for initial client registration when the iSNS is being
    used to assign a unique Entity Identifier to the client.

    The operating attributes are the elements that will be registered
    and associated with the key attributes.  Multiple attributes
    associated with the one key attribute can be registered in one
    RegDevAttr.

    One RegDevAttr message can contain attributes for Entity, Portal,
    Node, and Port objects if they are contained in the same Entity.
    When the registration contains attributes for the Entity, Portal,
    Node or Port objects together, then the appropriate Portal, Node
    and Port key attributes must be registered as part of the operating
    attributes.

    Ordering of the attributes is important in multi object
    registrations.  For example, Node Attributes follow a valid Node
    key.

    When a registration of a Portal, Node or Port is performed, the
    appropriate associations between objects will be created in the
    iSNS.

    Attributes following the Delimiter Attribute are Operating
    Attributes.  Depending on the setting of the Update bit in the
    FLAGS field, the Operating attribute values in the RegDevAttr
    message will either replace existing value(s), or be added to
    existing value(s) of the specified operating attribute.

Gibbons, Tseng, Monia      Standards Track                          50
iSNS                          March 2001


7.1.5.1.1 Update Flag

    The Update Flag, contained in the message header FLAGS field,
    indicates the RegDevAttr message is an update to an existing entry.

    If the key attributes match an existing object in the iSNS
    directory database, and the Update bit in the flags field is not
    set, then the registration will replace the existing registration.
    The existing object shall be de-registered.  A new registration
    will be created with the new attribute value(s) in the registration
    request.  Existing associations between objects will be updated to
    reflect the new information.  For example, an existing Node object
    may be de-registered and reregistered with a different Entity
    object as part of a registration.

    If the key attributes match an existing entry in the iSNS database
    and the Update bit in the FLAGS field is enabled, then the new
    attribute value(s) in the registration request SHALL update
    existing values or add additional attributes in the key entry.
    Existing associations between objects will be maintained.  If the
    Update bit is set and the registration would cause a change in
    associations, then the error _Invalid Registration Update_ SHALL be
    returned.  For example, if a RegDevAttr message with an Entity
    Identifier key for one entity contains a Node WWUI attribute
    associated with another entity, then an error shall be returned.

7.1.5.2   Device Attribute Query Request (DevAttrQry)

    The DevAttrQry message type is 0x0002.  The DevAttrQry message
    provides an iSNS client with the means to query the iSNS server for
    network entity attributes.

    The Source attribute of the DevAttrQry message is as defined in
    Section 7.1.1.  The source is used to scope the query to the
    Discovery Domains that the source attribute is a member of.

    The Key Attribute(s) follow the source attribute in the message
    payload.  The attributes returned by the query will be from objects
    WHERE the Key Attribute(s) match the object.  The Key Attributes
    map to a type of object.

    The DevAttrQry message shall support the following Key Attributes:











Gibbons, Tseng, Monia      Standards Track                          51
iSNS                          March 2001

           Valid Key Attributes for Queries
           --------------------------------
            Entity Identifier
            Entity Type
            Node Type
            Portal IP-Address
            Portal IP-Address, Portal TCP/UDP Port
            WWUI (iSCSI only)
            Node WWN (iFCP only)
            Port WWN (iFCP only)

    If the network entities matching key attributes are not in the same
    Discovery Domain as the Source Attribute, then the results for the
    network entity will not be included in the response message.

    The Operating Attributes are the attributes whose values are being
    queried.


7.1.5.3   Device Get Next Request (DevGetNext)

    The DevGetNext message type is 0x0003. This message provides the
    iSNS client with the means to sequentially retrieve Entity
    Identifiers, IP Addresses, WWUI's, Node Names and Port Names from
    devices in DDs to which the client has access.

    The Source attribute of the DevGetNext message is as defined in
    Section 7.1.1.  The source is used to scope the Get Next process to
    the Discovery Domains that the source attribute is a member of.  It
    is the Entity Identifier, WWUI, Node Name, Port Name, or the IP-
    Address of the client performing the query.

    The Key Attribute follows the source attribute in the message
    payload.  The Key Attribute is a Entity Identifier, WWUI, IP
    Address, Node Name, or Port Name.  If the key length value entered
    is zero, signifying an empty key value field, the first accessible
    a Entity Identifier, WWUI, IP Address, Node Name, or Port Name
    instance shall be returned to the client.

    There are no Delimiter or Operating Attributes in the DevGetNext
    request message.

7.1.5.4   Deregister Device Request (DeregDev)

    The DeregDev message type is 0x0004.  An iSNS client port or device
    is removed from the iSNS directory database by using DeregDev.
    Upon receiving the DeregDev, the iSNS server removes all object
    registrations associated with the Key Attribute in the payload.

    The DeregDev request message payload contains a Source Attribute
    and Key Attribute(s).  The Source attribute of the DeregDev message
    is as defined in Section 7.1.1.  Valid Key Attributes are shown
    below:

Gibbons, Tseng, Monia      Standards Track                          52
iSNS                          March 2001


           Valid Key Attributes for DeregDev
           ---------------------------------
            Entity Identifier
            Portal IP-Address
            Portal IP-Address, Portal TCP/UDP Port
            WWUI (iSCSI only)
            Node WWN (iFCP only)
            Port WWN (iFCP only)

    The removal of the object will initiate an SCN message to
    registered iSNS clients that are in the same DD as the removed
    device or port.  After removing the port or device, the iSNS server
    sends back an acknowledgement to the iSNS client.

7.1.5.5   SCN Register Request (SCNReg)

    The SCNReg message type is 0x0005.  The State Change Notification
    Registration Request (SCNReg) message allows an iSNS client to
    register a network entity to receive State Change Notification
    (SCN) messages.  SCN messages allow an iSNS client to be notified
    of changes within the DD or network (if administratively allowed)
    that the device port is a member of.

    The SCNReg request message payload contains a Source Attribute, Key
    Attribute(s), and Operating Attributes.  The Source attribute of
    the SCNReg message is as defined in Section 7.1.1.  Valid Key
    Attributes for an SCNReg are shown below:

           Valid Key Attributes for SCNReg
           --------------------------------
            Entity Identifier
            Portal IP-Address
            Portal IP-Address, Portal TCP/UDP Port
            WWUI (iSCSI only)
            Node WWN (iFCP only)
            Port WWN (iFCP only)


    The network entities matching the Key Attributes are registered to
    receive SCNs.

    The Operating Attributes section contains the Entity Event Bitmap
    attribute.  The bitmap indicates the INTERESTED EVENT TYPE FLAGS
    that the network entity is registering for.

    Section 6.8 describes each flag used in the EVENT TYPE FLAGS field.


7.1.5.6   SCN Deregister Request (SCNDereg)




Gibbons, Tseng, Monia      Standards Track                          53
iSNS                          March 2001

    The SCNDereg message type is 0x0006. The SCNDereg message allows an
    iSNS client to deregister a network entity to receive State Change
    Notification (SCN) messages.

    The SCNDereg request message payload contains a Source Attribute
    and Key Attribute(s).  The Source attribute of the SCNDereg message
    is as defined in Section 7.1.1.  Valid Key Attributes for an
    SCNDereg are shown below:

           Valid Key Attributes for SCNDereg
           --------------------------------
            Entity Identifier
            Portal IP-Address
            Portal IP-Address, Portal TCP/UDP Port
            WWUI (iSCSI only)
            Node WWN (iFCP only)
            Port WWN (iFCP only)

    The network entities matching the Key Attributes are deregistered
    for SCNs.

    There are no Delimiter or Operating Attributes in the SCNDereg
    message.

7.1.5.7   SCN Event (SCNEvent)

    The SCNEvent message type is 0x0007. The SCNEvent is a special
    message generated by a network entity for the iSNS.  The SCNEvent
    allows a network entity to request generation of a State Change
    Notification (SCN) message by the iSNS.  The SCN, sent by the iSNS,
    then notifies other registered network entities within a DD or
    network (if administratively allowed) of the change indicated in
    the SCNEvent.

    Most SCNs are automatically generated by the iSNS when network
    entities are registered or deregistered from the directory
    database.  SCNs are also be generated when a network management
    application makes changes to the DD membership in the iSNS.
    However, a network entity can trigger a SCN by using the SCNEvent.

    The format of the SCNEvent message is shown below:

              MSb                                    LSb
              31                                       0
              +----------------------------------------+
              |            Source Attribute            |
              +----------------------------------------+
              |          Source Event Bitmap           |
              +----------------------------------------+

    The Source Attribute is the object that caused the SCN to be
    generated.  The Source Attribute can be an Entity Identifier, WWUI,
    Node Name or Port Name.

Gibbons, Tseng, Monia      Standards Track                          54
iSNS                          March 2001


    The Source Event Bitmap indicates the event that caused the SCN to
    be generated.  The Event Bitmap is a 32 bit field, with the
    following definitions:

    Bit Field          Flag Description
    ---------          ----------------
        0              CHANGE IN DD MEMBERSHIP
        1              CHANGE IN NETWORK
        2              CHANGE IN DEVICE REGISTRATION PARAMETERS
        3              DEVICE ADDED
        4              DEVICE REMOVED
        5              CLIENT STATUS UPDATE REQUESTED (for CSI message)
     All Others        Reserved

7.1.5.8   State Change Notification (SCN)

    The SCN message type is 0x0008. The SCN is a special message
    generated by the iSNS which allows a registered network entity to
    be notified of changes within a DD, network (if administratively
    allowed), or about device registration parameter updates in the
    iSNS directory database.

    The types of events that a network entity will be notified about
    are based on the value of the Entity Event Bitmap, as described in
    Section 6.8.

    The format of the SCN message is shown below:

              MSb                                    LSb
              31                                       0
              +----------------------------------------+
              |         Destination Attribute          |
              +----------------------------------------+
              |               Timestamp                |
              +----------------------------------------+
              |           Source Attribute[1]          |
              +----------------------------------------+
              |          Source Event Bitmap[1]        |
              +----------------------------------------+
              |    Source Attribute [2](if present)    |
              +----------------------------------------+
              |   Source Event Bitmap [2](if present)  |
              +----------------------------------------+
              |    Source Attribute [3](if present)    |
              +----------------------------------------+
              |   Source Event Bitmap [3](if present)  |
              +----------------------------------------+
              |                 . . .                  |
              +----------------------------------------+




Gibbons, Tseng, Monia      Standards Track                          55
iSNS                          March 2001

    The Destination Attribute is the object that is receiving the SCN.
    The Destination Attribute can be an Entity Identifier, WWUI, Node
    Name or Port Name.

    The Timestamp field indicates the time the SCN Event was generated.
    The timestamp is a 4-byte unsigned, fixed-point integer giving the
    number of seconds since 00:00:00 GMT on January 1, 1970.

    The Source Attribute is the object that caused the SCN to be
    generated.  The Source Attribute can be an Entity Identifier, WWUI,
    Node Name or Port Name.

    The Source Event Bitmap indicates the event that caused the SCN to
    be generated.  The Event Bitmap is a 32 bit field, with the
    following definitions:

    Bit Field          Flag Description
    ---------          ----------------
        0              CHANGE IN DD MEMBERSHIP
        1              CHANGE IN NETWORK
        2              CHANGE IN DEVICE REGISTRATION PARAMETERS
        3              DEVICE ADDED
        4              DEVICE REMOVED
        5              CLIENT STATUS UPDATE REQUESTED (for CSI message)
     All Others        Reserved

7.1.5.9   Register DD (RegDD)

    The RegDD message type is 0x0009.  This message allows an iSNS
    client to create a new Discovery Domain (DD) or update an existing
    DD Symbolic Name.  Once created, network identities can be added
    and deleted from the DD.

    DDs are uniquely defined using DD_IDs.  DD registration attributes
    are described in section 5.5.

    The RegDD message payload contains the Source Attribute, Key
    Attributes and Operating Attributes. The Source attribute of the
    RegDD message is as defined in Section 7.1.1.

    The Key Attribute for a RegDD message is the DD ID for the domain
    being added or updated.  If the DD ID matches an existing DD, then
    the DD Symbolic Name will be updated with the value contained in
    the Operating Attribute payload.  If the DD ID does not match an
    existing DD, then a new DD is registered with the DD ID.  The new
    DD Symbolic Name will be the value contained in the Operating
    Attribute payload.

    The Operating Attribute for a RegDD message is the DD_Symbolic Name
    for the DD.

7.1.5.10  Deregister DD (DeregDD)


Gibbons, Tseng, Monia      Standards Track                          56
iSNS                          March 2001

    The DeregDD message type is 0x000A.  This message allows an iSNS
    client to deregister an existing Discovery Domain (DD).

    DDs are uniquely defined using DD_IDs.  DD registration attributes
    are described in section 5.5.

    The DeregDD message payload contains Source Attribute and Key
    Attributes.  The Source attribute of the DeregDD message is as
    defined in Section 7.1.1.

    The Key Attribute for a DeregDD message is the DD ID for the domain
    being removed.  If the DD ID matches an existing DD, then the DD
    will be removed and a success error code returned.  If the DD ID
    does not match an existing DD then the error code _No Such Entry_
    will be returned.

7.1.5.11  Register Device in DD (RegDevDD)

    The RegDevDD message type is 0x000B.  This message allows an iSNS
    client to add network identities to the DD.  DD registration
    attributes are described in section 5.5.

    The RegDevDD message payload contains the Source Attribute, Key
    Attribute and Operating Attributes. The Source attribute of the
    RegDevDD message is as defined in Section 7.1.1.  The Key Attribute
    for a RegDevDD message is the DD ID for the Discovery Domain (DD)
    to which the network entity will be added.  If the DD ID matches an
    existing DD, then the network entity will be added to the DD. If
    the DD ID does not match an existing DD then the error code _No
    Such Entry_ will be returned.

    The Operating Attribute for a RegDevDD message is the member to be
    added to the DD.  Valid members for a DD are shown in section 4.4.
    The network identities matching the Key Attributes will be added to
    the DD.

7.1.5.12  Deregister Device in DD (DeregDevDD)

    The DeregDevDD message type is 0x000C. This message allows an iSNS
    client to remove network identities from a DD.  DD attributes are
    described in section 5.5.

    The DeregDevDD message payload contains the Source Attribute, Key
    Attribute and Operating Attributes. The Source attribute of the
    DeregDevDD message is as defined in Section 7.1.1.  The Key
    Attribute for a DeregDevDD message is the DD ID for the Discovery
    Domain (DD) from which the network entity will be deregistered.  If
    the DD ID matches an existing DD, then the network entity will be
    removed to the DD. If the DD ID does not match an existing DD then
    the error code _No Such Entry_ will be returned.

    The Operating Attributes for a DeregDevDD message are the members
    to be deregistered from the DD.  Valid members for a DD are shown

Gibbons, Tseng, Monia      Standards Track                          57
iSNS                          March 2001

    in section 4.4.  The network identities matching the Operating
    Attributes will be deregistered from the DD indicated in the Key
    Attribute.

    If any of the Operating Attributes do not match a network entity in
    the DD then the error code _No Such Entry_ will be returned.  All
    other matching network entities will be removed.

7.1.5.13  Entity Status Inquiry (ESI)

    The ESI message type is 0x000D. This message is used to verify that
    an individual iSNS client is reachable and available.

    The ESI response message payload contains the destination attribute
    specifying the Entity Identifier of the iSNS client.

    If the iSNS client fails to respond to three consecutive ESI
    messages, then the iSNS shall remove that client from the iSNS
    database and trigger the appropriate State Change Notifications, if
    any.

7.1.5.14  Request Network Time (RqstTime)

    The RqstTime message type is 0x0010.  This is a special message
    that returns the network time as stored in the iSNS.  The iSNS uses
    NTP to obtain and maintain the network time provided in the
    RqstTime message.

    There are no Key or Operating attributes in this message.

7.1.5.15  Request Domain ID (RqstDmnId)

    The RqstDmnId message type is 0x0011. This optional message is used
    for FCIP and iFCP Transparent Mode to allocate DOMAIN_ID values
    used to assign 3-byte Fibre Channel PORT_ID values. In the case of
    FCIP, the iSNS client may be an address assignment authority for an
    Autonomous Region of a Fibre Channel fabric.  In the case of iFCP,
    the iSNS server becomes the address assignment authority for the
    entire iFCP fabric.

    The iSNS server responds to RqstDmnID with the DOMAIN_ID values
    from the range 1 to 239 that have not been previously allocated to
    other iSNS clients.  If no further unallocated DOMAIN_ID values are
    available from this range, the iSNS server SHALL respond with the
    error code 18 "DOMAIN_ID not available".

    Once a DOMAIN_ID value is allocated by the iSNS server, it shall
    not be reused until it has been deallocated by the iSNS client to
    which the value was assigned, or the CSI message detects that the
    iSNS client no longer exists on the network.

    The iSNS server and client SHALL use TCP to transmit and receive
    RqstDmnID, RqstDmnIDRsp, RlseDmnID, and RlseDmnIDRsp messages.

Gibbons, Tseng, Monia      Standards Track                          58
iSNS                          March 2001


7.1.5.16  Release Domain ID (RlseDmnId)

    The RlseDmnId message type is 0x0012. This optional message is used
    for FCIP and iFCP Transparent Mode to release DOMAIN_ID values used
    to assign 3-byte Fibre Channel PORT_ID values. In the case of FCIP,
    the iSNS client may be an address assignment authority for an
    Autonomous Region of a Fibre Channel fabric.  In the case of iFCP,
    the iSNS server becomes the address assignment authority for the
    entire iFCP fabric.

    Once a DOMAIN_ID value is allocated by the iSNS server, it shall
    not be reused until it has been deallocated by the iSNS client to
    which the value was assigned, or the CSI message detects that the
    iSNS client no longer exists on the network.

    The iSNS server and client SHALL use TCP to transmit and receive
    RqstDmnID, RqstDmnIDRsp, RlseDmnID, and RlseDmnIDRsp messages.

7.1.5.17  Get Domain IDs (GetDmnIds)

    The GetDmnIds message type is 0x0013. This optional message is used
    for FCIP and iFCP Transparent Mode to query for the currently used
    DOMAIN_ID values used to assign 3-byte Fibre Channel PORT_ID
    values. In the case of FCIP, the iSNS client may be an address
    assignment authority for an Autonomous Region of a Fibre Channel
    fabric.  In the case of iFCP, the iSNS server becomes the address
    assignment authority for the entire iFCP fabric.

    The GetDmnIds message payload contains Source Attribute and Key
    Attributes.  The Source attribute of the GetDmnIds message is as
    defined in Section 7.1.1.

    The Key Attribute for a GetDmnIds message is the Domain, used as a
    Scope, for the query.  The Operating Attribute is the Domain
    attribute.  If the Domain Scope matches a domain, then the utilized
    Area Codes will be returned in the Operating Attribute.  If the
    Domain used as a key is 0, then all currently used Domain IDs will
    be returned.  If the Domain Scope is non-zero and does not match an
    existing Domain then the error code _No Such Entry_ will be
    returned.

7.2      Response Messages

    The iSNSP response message payloads contain an Error Code, followed
    by a list of attributes, and have the following format:








Gibbons, Tseng, Monia      Standards Track                          59
iSNS                          March 2001

              MSb                                    LSb
              31                                       0
              +----------------------------------------+
              |          4-byte ERROR CODE             |
              +----------------------------------------+
              |      Key Attribute[1] (if present)     |
              +----------------------------------------+
              |      Key Attribute[2] (if present)     |
              +----------------------------------------+
              |      Key Attribute[3] (if present)     |
              +----------------------------------------+
              |                 . . .                  |
              +----------------------------------------+
              |  - Delimiter Attribute - (if present)  |
              +----------------------------------------+
              |   Operating Attribute[1] (if present)  |
              +----------------------------------------+
              |   Operating Attribute[2] (if present)  |
              +----------------------------------------+
              |   Operating Attribute[3] (if present)  |
              +----------------------------------------+
              |                 . . .                  |
              +----------------------------------------+

    The iSNS Response messages will be sent to the iSNS Client IP-
    Address and the originating TCP/UDP Port that was used for the
    associated registration and query message.

7.2.1   Error Code

    The iSNSP response message payloads contain a 4-byte ERROR CODE
    field.  If the operation completed successfully the Error Code
    field will contain No Error, represented by 0x00000000.  The list
    of valid Error Codes are shown below:




















Gibbons, Tseng, Monia      Standards Track                          60
iSNS                          March 2001

    Error Code       Error Description
    ----------       -----------------
       0             No Error
       1             Unknown Error
       2             Message Format Error
       3             Invalid Registration
       4             Invalid Registration Update
       4             Invalid Query
       5             Authentication Unknown
       6             Authentication Absent
       7             Authentication Failed
       8             No Such Entry
       9             Version Not Supported
      10             Internal Bus Error
      11             Busy Now
      12             Option Not Understood
      13             Invalid Update
      14             Message Not Supported
      15             SCN Event Rejected
      16             SCN Registration Rejected
      17             Client Status Inquiry Not Available
      18             DOMAIN_ID not available

7.2.2   Key Attributes in Response

    Depending on the specific iSNSP request, the response message will
    contain Key Attributes.  For example, a Register Device Attribute
    Response message will contain the Key Attributes used in the Device
    Attribute Registration with the assigned values, if they were
    assigned by the iSNS.

7.2.3   Delimiter Attribute in Response

    The Delimiter Attribute separates the key and operating attributes
    in a response message, if they exist.  The Delimiter Attribute has
    a tag value of 0 and a length value of 0.  The Delimiter Attribute
    is effectively 8 Bytes long, a 4 Byte tag containing 0x00000000,
    and a 4 Byte length field containing 0x00000000.

7.2.4   Operating Attributes in Response

    The Operating Attributes in a response are the results related to
    the iSNS registration or query operation being performed.

    The number of Operating Attributes in the response depends on the
    specific iSNSP request or query response.  For example, the
    Operating Attributes in a Device Attribute Query Response message
    are the set of Operating Attributes from network entity entries
    that matched the Key Attributes in the associated Device Attribute
    Query message.

7.2.5     Registration and Query Message Types


Gibbons, Tseng, Monia      Standards Track                          61
iSNS                          March 2001

    The following describes each query and message type.

7.2.5.1 Register Device Attribute Rsp (RegDevRsp)

    The RegDevRsp message type is 0x8001.  The RegDevRsp message
    contains the results for the RegDevAttr message with the same
    TRANSACTION ID.

    The Error Code contains the operation results.  If the registration
    completed successfully the code of _No Error_ is returned.  If an
    error occurred then the appropriate code will be returned.

    The Key Attribute contains the key used for the Register Device
    Attribute message.  If the RegDevAttr registration message was used
    to assign a unique Entity Identifier to the network entity, then
    the key attribute field contains the assigned Entity Identifier.

    There are no Operating Attributes in the RegDevRsp message.

7.2.5.2    Device Attribute Query Response (DevAttrQryRsp)

    The DevAttrQryRsp message type is 0x8002.  The DevAttrQryRsp
    message contains the results for the DevAttrQry message with the
    same TRANSACTION ID.

    The Error Code contains the operation results.  If the query
    completed successfully the code of _No Error_ is returned.  If an
    error occurred then the appropriate code will be returned.

    For a successful query result, the DevAttrQryRsp Operating
    Attribute field will contain the set of results that match the
    original DevAttrQry Key Attributes.

7.2.5.3    Device Get Next Response (DevGetNextRsp)

    The DevGetNextRsp message type is 0x8003. The DevGetNextRsp message
    contains the results for the DevGetNext message with the same
    TRANSACTION ID.

    The Error Code contains the operation results.  If the operation
    completed successfully the code of _No Error_ is returned.  If an
    error occurred then the appropriate code will be returned.

    The Key Attribute field contains the next key, in lexicographical
    order, after the Key Attribute used in the DevGetNext message.

    The Operating Attribute field contains the same attributes as were
    in the DevGetNext message.  The values of the Operating Attributes
    are the attribute values associated with the key returned.

7.2.5.4    Deregister Device Response (DeregDevRsp)



Gibbons, Tseng, Monia      Standards Track                          62
iSNS                          March 2001

    The DeregDevRsp message type is 0x8004. If the DeregDev operation
    completed successfully then the code of _No Error_ is returned.  If
    an error occurred then the appropriate code will be returned.

    The DeregDevRsp message does not contain any key or operating
    attributes.

7.2.5.5    SCN Register Response (SCNRegRsp)

    The SCNRegRsp message type is 0x8005. If the SCNReg operation
    completed successfully then the code of _No Error_ is returned.  If
    an error occurred then the appropriate code will be returned.

    The SCNRegRsp message does not contain any key or operating
    attributes.

7.2.5.6    SCN Deregister Response (SCNDeregRsp)

    The SCNDeregRsp message type is 0x8006. If the SCNDereg operation
    completed successfully then the code of _No Error_ is returned.  If
    an error occurred then the appropriate code will be returned.

    The SCNDeregRsp message does not contain any key or operating
    attributes.

7.2.5.7    SCN Event Response (SCNEventRsp)

    The SCNEventRsp message type is 0x8007. If the SCNEvent operation
    completed successfully then the code of _No Error_ is returned.  If
    an error occurred then the appropriate code will be returned.

    The SCNEventRsp message does not contain any key or operating
    attributes.

7.2.5.5    SCN Response (SCNRsp)

    The SCNRsp message type is 0x8008.  If the SCN operation completed
    successfully then the code of _No Error_ is returned.  If an error
    occurred then the appropriate code will be returned.

    The SCNRsp message does not contain any key or operating
    attributes.

7.2.5.9    Register DD Response (RegDDRsp)

    The RegDDRsp message type is 0x8009. If the RegDD operation
    completed successfully then the code of _No Error_ is returned.  If
    an error occurred then the appropriate code will be returned.

    The RegDDRsp message does not contain any key or operating
    attributes.

7.2.5.10   Deregister DD Response (DeregDDRsp)

Gibbons, Tseng, Monia      Standards Track                          63
iSNS                          March 2001


    The DeregDDRsp message type is 0x800A.  If the DeregDD operation
    completed successfully then the code of _No Error_ is returned.  If
    an error occurred then the appropriate code will be returned.

    The DeregDDRsp message does not contain any key or operating
    attributes.

7.2.5.11   Register Device in DD Response (RegDevDDRsp)

    The RegDevDDRsp message type is 0x800B. If the RegDevDD operation
    completed successfully then the code of _No Error_ is returned.  If
    an error occurred then the appropriate code will be returned.

    The DeregDDRsp message does not contain any key or operating
    attributes.

7.2.5.12   Deregister Device in DD Response (DeregDevDDRsp)

    The DeregDevDDRsp message type is 0x800C. If the DeregDevDD
    operation completed successfully then the code of _No Error_ is
    returned.  If an error occurred then the appropriate code will be
    returned.

    The DeregDevDDRsp message does not contain any key or operating
    attributes.

7.2.5.13   Entity Status Inquiry Response (ESIRsp)

    The ESIRsp message type is 0x800D. This message provides
    confirmation that the ESI message was received and processed by the
    iSNS client.

    The ESIRsp response message payload contains the source attribute
    of the iSNS client network entity.

    Upon receiving the ESIRsp from the iSNS client, the iSNS server
    SHALL update the timestamp attribute for that client.

    If the ESI operation completed successfully on the iSNS client then
    the code of _No Error_ is returned.  If an error occurred then the
    appropriate code will be returned.

    The ESIRsp message does not contain any key or operating
    attributes.

7.2.5.14   Request Network Time Response (RqstTimeRsp)

    The RqstTimeRsp message type is 0x8010.  The format of the
    RqstTimeRsp payload is different then other response message
    payloads, and is shown below:



Gibbons, Tseng, Monia      Standards Track                          64
iSNS                          March 2001

              MSb                                    LSb
              31                                       0
              +----------------------------------------+
              |          4-byte ERROR CODE             |
              +----------------------------------------+
              |          4-byte TIMESTAMP              |
              +----------------------------------------+

    The TIMESTAMP is a 4-byte unsigned, fixed-point integer giving the
    number of seconds since 00:00:00 GMT on January 1, 1970.  The
    Network Time Protocol can be used by the iSNS to generate the
    timestamp provided.  The iSNS TIMESTAMP shall only be considered to
    be locally significant.

7.2.5.15   Request Domain ID Response (RqstDmnIdRsp)

    The RqstDmnIdRsp message type is 0x8011.  This optional message
    provides the response for RqstDmnID, and is used for FCIP and iFCP
    Transparent Mode to allocate DOMAIN_ID values used to assign 3-byte
    Fibre Channel PORT_ID values. In the case of FCIP, the iSNS client
    may be an address assignment authority for an Autonomous Region of
    a Fibre Channel fabric.  In the case of iFCP, the iSNS server
    becomes the address assignment authority for the entire iFCP
    fabric.

    The iSNS server responds to RqstDmnID with the DOMAIN_ID values
    from the range 1 to 239 that have not been previously allocated to
    other iSNS clients.  If no further unallocated DOMAIN_ID values are
    available from this range, the iSNS server SHALL respond with the
    error code 18 "DOMAIN_ID not available".

    Once a DOMAIN_ID value is allocated by the iSNS server, it shall
    not be reused until it has been deallocated by the iSNS client to
    which the value was assigned, or the CSI message detects that the
    iSNS client no longer exists on the network.

    The iSNS server and client SHALL use TCP to transmit and receive
    RqstDmnID, RqstDmnIDRsp, RlseDmnID, and RlseDmnIDRsp messages.

7.2.5.16   Release Domain ID Response (RlseDmnIdRsp)

    The RlseDmnIdRsp message type is 0x8012. This optional message
    provides the response for RlseDmnId, and is used for FCIP and iFCP
    Transparent Mode to release DOMAIN_ID values used to assign 3-byte
    Fibre Channel PORT_ID values. In the case of FCIP, the iSNS client
    may be an address assignment authority for an Autonomous Region of
    a Fibre Channel fabric.  In the case of iFCP, the iSNS server
    becomes the address assignment authority for the entire iFCP
    fabric.

    Once a DOMAIN_ID value is allocated by the iSNS server, it shall
    not be reused until it has been deallocated by the iSNS client to


Gibbons, Tseng, Monia      Standards Track                          65
iSNS                          March 2001

    which the value was assigned, or the ESI message detects that the
    iSNS client no longer exists on the network.

    The iSNS server and client SHALL use TCP to transmit and receive
    RqstDmnID, RqstDmnIDRsp, RlseDmnID, and RlseDmnIDRsp messages.

7.2.5.17  Get Domain IDs Response (GetDmnIdsResp)

    The GetDmnIdsResp message type is 0x8013. This optional message is
    used for FCIP and iFCP Transparent Mode to return the results of a
    query for the currently-allocated DOMAIN_ID values used to assign
    3-byte Fibre Channel PORT_ID values. In the case of FCIP, the iSNS
    client may be an address assignment authority for an Autonomous
    Region of a Fibre Channel fabric.  In the case of iFCP, the iSNS
    server becomes the address assignment authority for the entire iFCP
    fabric.

    If the Domain Scope matches a domain, then the utilized Area Codes
    will be returned in the Operating Attribute.  If the Domain used as
    a key is 0, then all currently used Domain IDs will be returned.
    If the Domain Scope is non-zero and does not match an existing
    Domain then the error code _No Such Entry_ will be returned.

8.       Security Considerations

8.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 described in section 6.4.

8.2      Confidentiality

    If the operational evironment requires confidentiality in iSNSP
    queries and responses, then the iSNSP shall be used with Transport
    Layer Security (TLS).  However, there will be many instances where
    confidentiality will not be a requirement.  None of the information
    stored in the iSNS database is inherently confidential.  This
    includes X.509 certificates, which should contain only public keys.
    In these cases where confidentiality is not required, the iSNS can
    be used only with the message authentication block described in
    section 6.4.

8.3      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 technology can protect
    against active attacks from the Public Internet.

9.       References


Gibbons, Tseng, Monia      Standards Track                          66
iSNS                          March 2001

    [RFC1035]      Domain Implementation and Specification
    [STD0035]      Domain Name System
    [RFC2065]      Domain Name System Security Extensions
    [RFC2608]      Service Location Protocol, Version 2
    [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
    [iSCSI-SLP]    Finding iSCSI Targets and Name Servers Using SLP,
                   draft-bakke-iscsi-slp-00.txt
    [iSCSI-NDR]    iSCSI Naming and Discovery Requirements,
                   draft-ietf-ips-iscsi-name-disc-00.txt

   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      Standards Track                          67
iSNS                          March 2001

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

    Kenneth Hirata
    Vixel Corporation
    Irvine, CA 92618
    Phone: (949) 450-6100
    Email: khirata@vixel.com

    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      Standards Track                          68
iSNS                          March 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."



























Gibbons, Tseng, Monia      Standards Track                          69
iSNS                          March 2001

                         Appendix A - iSNS Examples

A.1       iSCSI Initialization Example

    This example assumes an SLP Service Agent (SA) has been implemented
    on the iSNS host, and an SLP User Agent (UA) has been implemented
    on the iSNS initiator.  See [RFC2608] for further details on SA's
    and UA's.  This example also assumes the target is configured to
    use the iSNS, and have its access control policy "slaved" to the
    iSNS.












































Gibbons, Tseng, Monia      Standards Track                          70
iSNS                          March 2001


A.1.1     Simple iSCSI Target Registration

    In this example, a simple target with a single WWUI registers with
    the iSNS.  The target has not been assigned a Fully Qualified
    Domain Name (FQDN) by the administrator.

    +--------------------------+------------------+-------------------+
    |    iSCSI Target Device   |    iSNS          |Management Station |
    +--------------------------+------------------+-------------------+
    |Discover iSNS--SLP------->|                  |/*mgmt station is  |
    |                          |<--SLP--iSNS Here:| administratively  |
    |                          |      192.36.53.1 | authorized to view|
    |                          |                  | all DD's.  Device |
    |                          |                  | WWUIabcd has been |
    |      RegDevAttr--------->|                  | previously placed |
    |Src:(tag=1) NULL          |                  | into DDabcd******/|
    |Key:(tag=1) NULL          |                  |                   |
    |tag=2: "iSCSI"            |                  |                   |
    |tag=4: 0                  |                  |                   |
    |tag=16: "192.36.4.5"      |                  |                   |
    |tag=17: "5001"            |                  |                   |
    |tag=32: "WWUIabcd"        |                  |                   |
    |tag=34: "target"          |                  |                   |
    |tag=35: "disk 1"          |                  |                   |
    |                          |<---RegDevAttrRsp |                   |
    |                          |tag=1: "iSNS:0001"|                   |
    |                          |                  |                   |
    |      DevAttrQry--------->|      SCN-------->|                   |
    |Src:(tag=32) "WWUIabcd"   |(or SNMP trap)    |                   |
    |Key:(tag=2) "iSCSI"       |src: "iSNS:0001"  |                   |
    |Key:(tag=34) "initiator"  |dest: "mgmt.foo.com"                  |
    |tag=16:  NULL             |CHANGE IN NETWORK |                   |
    |tag=32:  NULL             |                  |<-------SCNRsp     |
    |/*Query asks for all iSCSI|                  |                   |
    |devices' IP address, port |<---DevAttrQryRsp |                   |
    |number, and WWUI*/        |tag=16:"192.36.4.1"                   |
    |                          |tag=32:"WWUIpdq"  |<-----DevAttrQry   |
    |                          |tag=16:"192.1.3.2"|src: mgmt.foo.com  |
    |                          |tag=32:"WWUIrst"  |key:(tag=1)iSNS:0001
    |/*************************|                  |Op Attr: (tag=16)  |
    |Our target "iSNS:0001"    |                  |Op Attr: (tag=17)  |
    |discovers two initiators  |                  |Op Attr: (tag=32)  |
    |in the same DD.  It will  |                  |                   |
    |accept iSCSI logins from  |                  |                   |
    |these two identified      |                  |                   |
    |initiators presented by   |                  |                   |
    |iSNS*********************/| DevAttrQryRsp--->|                   |
    |                          |tag=16: 192.36.4.5|                   |
    |                          |tag=17: 5001      |                   |
    |                          |tag=32: WWUIabcd  |                   |
    +--------------------------+------------------+-------------------+


Gibbons, Tseng, Monia      Standards Track                          71
iSNS                          March 2001


A.1.2     Target Registration and DD Configuration

    In this example, a more complex target registers with the iSNS.
    This target has been configured with a Fully Qualified Domain Name
    (FQDN) in the DNS servers, and the user wishes to use this
    identifier for the device.  Also, the user wishes to use public key
    certificates in the iSCSI login authentication.

    +--------------------------+------------------+-------------------+
    |    iSCSI Target Device   |    iSNS          |Management Station |
    +--------------------------+------------------+-------------------+
    |Discover iSNS--SLP-->     |                  |/*mgmt station is  |
    |                          |<--SLP--iSNS Here:| administratively  |
    |                          |      192.36.53.1 | authorized to view|
    |      RegDevAttr-->       |                  | all DD's ********/|
    |Src:(tag=1)"jbod1.foo.com"|                  |                   |
    |Key:(tag=1)"jbod1.foo.com"|                  |                   |
    |tag=1: "jbod1.foo.com"    |                  |                   |
    |tag=2: "iSCSI"            |                  |                   |
    |tag=4: 5 seconds          |                  |                   |
    |tag=16: "192.36.34.4"     |                  |                   |
    |tag=17: "5001"            |                  |                   |
    |tag=16: "192.36.53.5"     |                  |                   |
    |tag=17: "5001"            |                  |                   |
    |tag=32: "WWUIabcd"        |                  |                   |
    |tag=35: "Target"          |/*****************|                   |
    |tag=36: "Volume 1"        |jbod1.foo.com is  |                   |
    |tag=39: X.509 cert blob 1 |now registered in |                   |
    |tag=32: "WWUIefgh"        |iSNS, but is not  |                   |
    |tag=35: "Target"          |in any DD. Therefore,                 |
    |tag=36: "Volume 2"        |no other devices  |                   |
    |tag=39: X.509 cert blob 2 |can "see" it.     |                   |
    |                          |*****************/|                   |
    |                          |<--DevAttrRsp     |                   |
    |                          |                  |                   |
    |                          |       SCN------> |                   |
    |                          |  (or SNMP trap)  |                   |
    |                          |src: jbod1.foo.com|                   |
    |                          |dest: mgmt.foo.com|                   |
    |                          |CHANGE IN NETWORK |                   |
    |                          |                  |                   |
    |                          |                  |<--SCNRsp          |
    |                          |                  |<--DevAttrQry      |
    |                          |                  |src: mgmt.foo.com  |
    |                          |                  |key:  (tag=1)      |
    |                          |                  |  jbod1.foo.com    |
    |                          |                  |Op Attr: (tag=2)   |
    |                          |                  |Op Attr: (tag=16)  |
    |                          |                  |Op Attr: (tag=17)  |
    |                          |                  |Op Attr: (tag=32)  |
    |                          |                  |                   |
    |                          | DevAttrQryRsp--> |                   |

Gibbons, Tseng, Monia      Standards Track                          72
iSNS                          March 2001

    |                          |tag=2:  "iSCSI"   |                   |
    |                          |tag=16: 192.36.34.4                   |
    |                          |tag=17: 5001      |                   |
    |                          |tag=16: 192.36.53.5                   |
    |                          |tag=17: 5001      |/**Mgmt Station ***|
    |                          |tag=32:"WWUIabcd" |displays device,   |
    |                          |tag=32:"WWUIefgh" |the operator decides
    |                          |                  |to place "WWUIabcd"|
    |                          |                  |into Domain "DDxyz"|
    |/*************************|                  |******************/|
    |Target is now registered  |                  |                   |
    |in iSNS.  It has been placed                 |<--RegDevDD        |
    |in DDxyz by management    |                  |src:(tag=1)
    |station.                  |                  |  "mgmt.foo.com"   |
    |*************************/|                  |key: "DDxyz"       |
    |                          |                  |tag=32: "WWUIabcd" |
    |                          |                  |                   |
    |                          |    RegDevRsp---->|                   |
    +--------------------------+------------------+-------------------+



































Gibbons, Tseng, Monia      Standards Track                          73
iSNS                          March 2001


A.1.3     Initiator Registration and Target Discovery

    The following example illustrates a new initiator registering with
    the iSNS, and discovering the target WWUIabcd from the example in
    A.1.1.

    +--------------------------+------------------+-------------------+
    |    iSCSI Initiator       |    iSNS          |Management Station |
    +--------------------------+------------------+-------------------+
    |Discover iSNS--SLP-->     |                  |/*mgmt station is  |
    |                          |<--SLP--iSNS Here:| administratively  |
    |                          |      192.36.53.1 | authorized to view|
    |RegDevAttr-->             |                  | all DD's ********/|
    |Src:(tag=1)"svr1.foo.com" |                  |                   |
    |Key:(tag=1)"svr1.foo.com" |                  |                   |
    |tag=1: "svr1.foo.com"     |                  |                   |
    |tag=2: "iSCSI"            |                  |                   |
    |tag=4: 5 seconds          |/*****************|                   |
    |tag=16: "192.20.3.1"      |Device not in any |                   |
    |tag=17: "5001"            |DD, so it is      |                   |
    |tag=32: "WWUIijkl"        |inaccessible by   |                   |
    |tag=35: "Initiator"       |other devices     |                   |
    |tag=36: "Server1"         |*****************/|                   |
    |tag=39: X.509 cert blob 3 |                  |                   |
    |                          |<--DevAttrRsp     |                   |
    |                          |                  |                   |
    |                          |       SCN------> |                   |
    |                          |  (or SNMP trap)  |                   |
    |                          |src: svr1.foo.com |                   |
    |                          |dest: mgmt.foo.com|                   |
    |                          |CHANGE IN NETWORK |                   |
    |                          |                  |                   |
    |                          |                  |<------SCNRsp      |
    |                          |                  |<----DevAttrQry    |
    |                          |                  |src: mgmt.foo.com  |
    |                          |                  |key:  (tag=1)      |
    |                          |                  |  svr1.foo.com     |
    |                          |                  |Op Attr: (tag=2)   |
    |                          |                  |Op Attr: (tag=16)  |
    |                          |                  |Op Attr: (tag=17)  |
    |                          |                  |Op Attr: (tag=32)  |
    |                          | DevAttrQryRsp--> |                   |
    |                          |tag=2:  "iSCSI"   |                   |
    |                          |tag=17:192.20.3.1 |                   |
    |                          |tag=32:"WWUIijkl" |                   |
    |                          |                  |/**Mgmt Station ***|
    |                          |                  |displays device,   |
    |                          |                  |the operator decides
    |                          |                  |to place "WWUIijkl"|
    |                          |                  |into Domain "DDxyz"|
    |                          |                  |with device WWUIabcd
    |                          |                  |******************/|

Gibbons, Tseng, Monia      Standards Track                          74
iSNS                          March 2001

    |                          |                  |<--RegDevDD        |
    |                          |                  |src: (tag=1)       |
    |                          |                  |  "mgmt.foo.com"   |
    |                          |                  |key: "DDxyz"       |
    |                          |                  |tag=32: "WWUIijkl  |
    |                          |                  |                   |
    |                          |     RegDevRsp--->|/******************|
    |                          |                  |"WWUIijkl" has been|
    |                          |                  |moved to "DDxyz"   |
    |                          |                  |******************/|
    |                          |<-----SCN         |                   |
    |                          |src: "WWUIijkl"   |                   |
    |                          |dest: "WWUIijkl"  |                   |
    |                          |CHANGE IN DD MEMBERSHIP               |
    |    DevAttrQry----------->|                  |                   |
    |src: "WWUIabcd"           |/*****************|                   |
    |key:(tag=2) "iSCSI"       |Note that WWUIabcd|                   |
    |key:(tag=35) "Target"     |also receives an  |                   |
    |Op Attr: (tag=16)         |SCN that WWUIijkl |                   |
    |Op Attr: (tag=17)         |is in the same DD |                   |
    |Op Attr: (tag=32)         |*****************/|                   |
    |Op Attr: (tag=36)         |                  |                   |
    |Op Attr: (tag=39)         |<-----AttrQryRsp  |                   |
    |                          |tag=16: 192.36.34.4                   |
    |                          |tag=17: 5001      |                   |
    |                          |tag=16: 192.36.53.5                   |
    |                          |tag=17: 5001      |                   |
    |                          |tag=32: WWUIabcd  |                   |
    |                          |tag=36: Volume 1  |                   |
    |                          |tag=39: X.509 cert blob 2             |
    |                          |                  |                   |
    |/***The initiator has discovered             |                   |
    |the target, and has everything               |                   |
    |needed to complete iSCSI login               |                   |
    |The same process occurs on the               |                   |
    |target side; the SCN prompts the             |                   |
    |target to download the list of               |                   |
    |authorized initiators from the               |                   |
    |iSNS (i.e., those initiators in the          |                   |
    |same DD as the target.************/          |                   |
    +--------------------------+------------------+-------------------+













Gibbons, Tseng, Monia      Standards Track                          75
iSNS                          March 2001


                      Appendix B _ SNMP Management MIB

    The following SNMP MIB is for iSNS network management.  The
    definition is based on SNMPv2c.  This is the first general release
    of the MIB.

    iSNS DEFINITIONS ::= BEGIN
    --
    --  iSNS.mib: IETF IPS Internet Storage Name Service (iSNS)
    management
    --  v1.0
    --
    IMPORTS
        enterprises,
        MODULE-IDENTITY,
        OBJECT-TYPE,
        NOTIFICATION-TYPE,
        IpAddress,
        Counter32
             FROM SNMPv2-SMI

        Gauge
             FROM RFC1155-SMI

        OBJECT-GROUP
             FROM SNMPv2-CONF

        TEXTUAL-CONVENTION,
        DisplayString,
        DateAndTime,
        RowStatus,
        PhysAddress,
        TimeStamp
             FROM SNMPv2-TC;

    FCIDtype  ::= OCTET STRING (SIZE (3))
    WWNtype   ::= OCTET STRING (SIZE (8))
    EntIdx    ::= INTEGER
    PortalIdx ::= INTEGER
    NodeIdx   ::= INTEGER
    EIDtype   ::= OCTET STRING
    NodeType  ::= OCTET STRING (SIZE (2))
    EntType   ::= INTEGER {iSCSI(1), FCIP(2), iFCP(3)}
    WWUItype  ::= OCTET STRING
    DDIDtype  ::= INTEGER

    TFtype   ::= INTEGER {true(1), false(2)}

    iSNS  MODULE-IDENTITY
          LAST-UPDATED "200103010000Z"
          ORGANIZATION "IETF IPS iSNS Working Group"
          CONTACT-INFO "

Gibbons, Tseng, Monia      Standards Track                          76
iSNS                          March 2001

            Attn: Kevin Gibbons / Josh Tseng
                  Nishan Systems
                  3850 North First Street
                  San Jose, CA 95134
                  USA
                  Tel : +1 408 519-3700
                  email : snmp@nishansystems.com "
          DESCRIPTION "The MIB for internet Storage Name Service (iSNS)
    Management."
              ::=  {experimental 1}

    --
    -- Internet Storage Name Service Management
    --

    iSnsVersion OBJECT-TYPE
        SYNTAX          INTEGER (0..65535)
        MAX-ACCESS      read-only
        STATUS          current
        DESCRIPTION
    "The version of this iSNS instance.  The header of each iSNSP
     message contains iSNS version information."
        ::= {iSNS 1}

    --
    -- Discovery Domain Membership Information --------------------
    --

    iSnsDdMmbrs      OBJECT IDENTIFIER ::= {iSNS 2}

    --
    -- Naming Service's Discovery Domain Information --------------
    --

    iSnsNumDomains        OBJECT-TYPE
        SYNTAX            INTEGER
        MAX-ACCESS        read-only
        STATUS            current
        DESCRIPTION
    "The current total number of Discovery Domain entries
     in the iSNS."
        ::= {iSnsDdMmbrs 1}

    iSnsNewDomainMemberStatus OBJECT-TYPE
        SYNTAX      INTEGER {inNoDomain(0), inDefaultDomain(1)}
        MAX-ACCESS  read-write
        STATUS      current
        DESCRIPTION
    "The Domain Status for a new device when added to the network.
    Either the
     new device will not be in a domain, or go into a default domain.
    The
     default domain is by convention DD ID 1."

Gibbons, Tseng, Monia      Standards Track                          77
iSNS                          March 2001

        ::= {iSnsDdMmbrs 2}

    iSnsDDTable OBJECT-TYPE
        SYNTAX        SEQUENCE OF iSnsDDtInfoEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
    "A table containing configuration information for each
     Discovery Domain (DD) configured in the network
     managed by the iSNS."
        ::= {iSnsDdMmbrs 3}

    iSnsDDtInfoEntry OBJECT-TYPE
        SYNTAX      iSnsDDtInfoEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
    "Configuration information for each Discovery Domain
     (DD) configured in the network."
        INDEX   {iSnsDDtId}
        ::= {iSnsDDTable 1}

    iSnsDDtInfoEntry ::=
        SEQUENCE {
           iSnsDDtId             DDIDtype,
           iSnsDDtSymbolicName   OCTET STRING,
           iSnsDDtRowStatus      RowStatus
          }

    iSnsDDtId         OBJECT-TYPE
        SYNTAX          INTEGER
        MAX-ACCESS      read-write
        STATUS          current
        DESCRIPTION
    "The ID that refers to this Discovery Domain."
        ::= {iSnsDDtInfoEntry 1}

    iSnsDDtSymbolicName    OBJECT-TYPE
        SYNTAX        OCTET STRING (SIZE (0 .. 64))
        MAX-ACCESS    read-write
        STATUS        current
        DESCRIPTION
    "The Discovery Domain Symbolic Name field contains
     a variable length description (from 0 to 64) that is
     associated with the DD.  If the DD Sym Name is not
     registered, then the length of this field is set to zero
     bytes."
        ::= {iSnsDDtInfoEntry 2}

    iSnsDDtRowStatus  OBJECT-TYPE
        SYNTAX        RowStatus
        MAX-ACCESS    read-write
        STATUS        current

Gibbons, Tseng, Monia      Standards Track                          78
iSNS                          March 2001

        DESCRIPTION
    "This object indicates the status of this entry.
             active (1),         read-write
             notInService (2),   read-write
             notReady (3),       read-only
             createAndGo (4),    write-only
             createAndWait (5),  write-only
             destroy (6),        write-only"
        ::= {iSnsDDtInfoEntry 3}

    --
    -- DD Entity Membership Assignment
    --

    iSnsDDMemberEntityTable OBJECT-TYPE
        SYNTAX        SEQUENCE OF iSnsDDEIDtInfoEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
    "A table containing Entity Identifiers that
     have been assigned to specific DDs."
        ::= {iSnsDdMmbrs 4}

    iSnsDDEIDtInfoEntry  OBJECT-TYPE
        SYNTAX            iSnsDDEIDtInfoEntry
        MAX-ACCESS        not-accessible
        STATUS            current
        DESCRIPTION
    "DD membership information for Entity Identifiers."
        INDEX   {iSnsDDEIDtId}
        ::= {iSnsDDMemberEntityTable 1}

    iSnsDDEIDtInfoEntry ::=
        SEQUENCE {
           iSnsDDEIDtId        INTEGER,
           iSnsDDEIDtEID          EIDtype,
           iSnsDDEIDtRowStatus    RowStatus
          }

    iSnsDDEIDtId        OBJECT-TYPE
        SYNTAX          INTEGER
        MAX-ACCESS      read-write
        STATUS          current
        DESCRIPTION
    "The ID that refers to the Discovery Domain that
     the entity is a member of."
        ::= {iSnsDDEIDtInfoEntry 1}

    iSnsDDEIDtEID    OBJECT-TYPE
        SYNTAX        EIDtype
        MAX-ACCESS    read-write
        STATUS        current
        DESCRIPTION

Gibbons, Tseng, Monia      Standards Track                          79
iSNS                          March 2001

    "The Enity ID of the entity that is a member of the DD."
        ::= {iSnsDDEIDtInfoEntry 2}

    iSnsDDEIDtRowStatus  OBJECT-TYPE
        SYNTAX            RowStatus
        MAX-ACCESS        read-write
        STATUS            current
        DESCRIPTION
    "This object indicates the status of this entry.
             active (1),         read-write
             notInService (2),   read-write
             notReady (3),       read-only
             createAndGo (4),    write-only
             createAndWait (5),  write-only
             destroy (6),        write-only"
        ::= {iSnsDDEIDtInfoEntry 3}

    --
    -- DD Portal Membership Assignment
    --

    iSnsDDMemberPortalIPAddrTable OBJECT-TYPE
        SYNTAX        SEQUENCE OF iSnsDDPIPtInfoEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
    "A table containing Portal IP Addreses that
     have been assigned to specific DDs."
        ::= {iSnsDdMmbrs 5}

    iSnsDDPIPtInfoEntry OBJECT-TYPE
        SYNTAX      iSnsDDPIPtInfoEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
    "DD membership information for Portal IP Addresses."
        INDEX   {iSnsDDPIPtId}
        ::= {iSnsDDMemberPortalIPAddrTable 1}

    iSnsDDPIPtInfoEntry ::=
        SEQUENCE {
           iSnsDDPIPtId       INTEGER,
           iSnsDDPIPtPIPA         IpAddress,
           iSnsDDPIPtRowStatus    RowStatus
          }

    iSnsDDPIPtId        OBJECT-TYPE
        SYNTAX          INTEGER
        MAX-ACCESS      read-write
        STATUS          current
        DESCRIPTION
    "The ID that refers to the Discovery Domain that
     the portal is a member of."

Gibbons, Tseng, Monia      Standards Track                          80
iSNS                          March 2001

        ::= {iSnsDDPIPtInfoEntry 1}

    iSnsDDPIPtPIPA    OBJECT-TYPE
        SYNTAX        IpAddress
        MAX-ACCESS    read-write
        STATUS        current
        DESCRIPTION
    "The Portal IP Address of the entity that is a member of the DD."
        ::= {iSnsDDPIPtInfoEntry 2}

    iSnsDDPIPtRowStatus  OBJECT-TYPE
        SYNTAX        RowStatus
        MAX-ACCESS    read-write
        STATUS        current
        DESCRIPTION
    "This object indicates the status of this entry.
             active (1),         read-write
             notInService (2),   read-write
             notReady (3),       read-only
             createAndGo (4),    write-only
             createAndWait (5),  write-only
             destroy (6),        write-only"
        ::= {iSnsDDPIPtInfoEntry 3}

    --
    -- DD Node Membership Assignment
    --
    -- By WWUI

    iSnsDDMemberNodeWWUITable OBJECT-TYPE
        SYNTAX        SEQUENCE OF iSnsDDNWWUItInfoEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
    "A table containing Node WWUIs that
     have been assigned to specific DDs."
        ::= {iSnsDdMmbrs 6}

    iSnsDDNWWUItInfoEntry OBJECT-TYPE
        SYNTAX      iSnsDDNWWUItInfoEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
    "DD membership information for Node WWUIs."
        INDEX   {iSnsDDNWWUItId}
        ::= {iSnsDDMemberNodeWWUITable 1}

    iSnsDDNWWUItInfoEntry ::=
        SEQUENCE {
           iSnsDDNWWUItId               INTEGER,
           iSnsDDNWWUItWWUI         WWUItype,
           iSnsDDNWWUItRowStatus    RowStatus
          }

Gibbons, Tseng, Monia      Standards Track                          81
iSNS                          March 2001


    iSnsDDNWWUItId      OBJECT-TYPE
        SYNTAX          INTEGER
        MAX-ACCESS      read-write
        STATUS          current
        DESCRIPTION
    "The ID that refers to the Discovery Domain that
     the node is a member of."
        ::= {iSnsDDNWWUItInfoEntry 1}

    iSnsDDNWWUItWWUI    OBJECT-TYPE
        SYNTAX        WWUItype
        MAX-ACCESS    read-write
        STATUS        current
        DESCRIPTION
    "The WWUI the node that is a member of the DD."
        ::= {iSnsDDNWWUItInfoEntry 2}

    iSnsDDNWWUItRowStatus  OBJECT-TYPE
        SYNTAX        RowStatus
        MAX-ACCESS    read-write
        STATUS        current
        DESCRIPTION
    "This object indicates the status of this entry.
             active (1),         read-write
             notInService (2),   read-write
             notReady (3),       read-only
             createAndGo (4),    write-only
             createAndWait (5),  write-only
             destroy (6),        write-only"
        ::= {iSnsDDNWWUItInfoEntry 3}

    -- DD Node Membership By Node Name WWN

    iSnsDDMemberNodeWWNTable OBJECT-TYPE
        SYNTAX        SEQUENCE OF iSnsDDNWWNtInfoEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
    "A table containing Node WWNs that
     have been assigned to specific DDs."
        ::= {iSnsDdMmbrs 7}

    iSnsDDNWWNtInfoEntry OBJECT-TYPE
        SYNTAX      iSnsDDNWWNtInfoEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION
    "DD membership information for Node WWNs."
        INDEX   {iSNSDDNWWNtId}
        ::= {iSnsDDMemberNodeWWNTable 1}

    iSnsDDNWWNtInfoEntry ::=

Gibbons, Tseng, Monia      Standards Track                          82
iSNS                          March 2001

        SEQUENCE {
           iSnsDDNWWNtId               INTEGER,
           iSnsDDNWWNtNodeWWN      WWNtype,
           iSnsDDNWWNtRowStatus    RowStatus
          }

    iSnsDDNWWNtId       OBJECT-TYPE
        SYNTAX          INTEGER
        MAX-ACCESS      read-write
        STATUS          current
        DESCRIPTION
    "The ID that refers to the Discovery Domain that
     the node is a member of."
        ::= {iSnsDDNWWNtInfoEntry 1}

    iSnsDDNWWNtNodeWWN    OBJECT-TYPE
        SYNTAX        WWNtype
        MAX-ACCESS    read-write
        STATUS        current
        DESCRIPTION
    "The WWN the node that is a member of the DD."
        ::= {iSnsDDNWWNtInfoEntry 2}

    iSnsDDNWWNtRowStatus  OBJECT-TYPE
        SYNTAX        RowStatus
        MAX-ACCESS    read-write
        STATUS        current
        DESCRIPTION
    "This object indicates the status of this entry.
             active (1),         read-write
             notInService (2),   read-write
             notReady (3),       read-only
             createAndGo (4),    write-only
             createAndWait (5),  write-only
             destroy (6),        write-only"
        ::= {iSnsDDNWWNtInfoEntry 3}

    --
    -- DD Port Membership Assignment
    --

    iSnsDDMemberPortWWNTable OBJECT-TYPE
        SYNTAX        SEQUENCE OF iSnsDDPWWNtInfoEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
    "A table containing Port WWNs that
     have been assigned to specific DDs."
        ::= {iSnsDdMmbrs 8}

    iSnsDDPWWNtInfoEntry OBJECT-TYPE
        SYNTAX      iSnsDDPWWNtInfoEntry
        MAX-ACCESS  not-accessible

Gibbons, Tseng, Monia      Standards Track                          83
iSNS                          March 2001

        STATUS      current
        DESCRIPTION
    "DD membership information for Port WWNs."
        INDEX   {iSnsDDPWWNtId}
        ::= {iSnsDDMemberPortWWNTable 1}

    iSnsDDPWWNtInfoEntry ::=
        SEQUENCE {
           iSnsDDPWWNtId               INTEGER,
           iSnsDDPWWNtPortWWN      WWNtype,
           iSnsDDPWWNtRowStatus    RowStatus
          }

    iSnsDDPWWNtId       OBJECT-TYPE
        SYNTAX          INTEGER
        MAX-ACCESS      read-write
        STATUS          current
        DESCRIPTION
    "The ID that refers to the Discovery Domain that
     the port is a member of."
        ::= {iSnsDDPWWNtInfoEntry 1}

    iSnsDDPWWNtPortWWN    OBJECT-TYPE
        SYNTAX        WWNtype
        MAX-ACCESS    read-write
        STATUS        current
        DESCRIPTION
    "The WWN the port that is a member of the DD."
        ::= {iSnsDDPWWNtInfoEntry 2}

    iSnsDDPWWNtRowStatus  OBJECT-TYPE
        SYNTAX        RowStatus
        MAX-ACCESS    read-write
        STATUS        current
        DESCRIPTION
    "This object indicates the status of this entry.
             active (1),         read-write
             notInService (2),   read-write
             notReady (3),       read-only
             createAndGo (4),    write-only
             createAndWait (5),  write-only
             destroy (6),        write-only"
        ::= {iSnsDDPWWNtInfoEntry 3}

    --
    -- iSNS Registered Objects ----------------------------------------
    ----------
    --

    iSnsRegObj      OBJECT IDENTIFIER ::= {iSNS 3}

    --


Gibbons, Tseng, Monia      Standards Track                          84
iSNS                          March 2001

    -- iSNS Content Information ---------------------------------------
    -----------
    --

    --
    -- iSNS Registered Entity Information
    --

    iSnsNumEntities       OBJECT-TYPE
        SYNTAX            INTEGER
        MAX-ACCESS        read-only
        STATUS            current
        DESCRIPTION
    "The current total number of Entity entries in the iSNS."
        ::= {iSnsRegObj 1}

    --
    -- iSNS Registered Entities Table
    --

    iSnsRegEntityTable OBJECT-TYPE
        SYNTAX        SEQUENCE OF iSnsREtInfoEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
    "A table containing the registered entities in the iSNS."
        ::= {iSnsRegObj 2}

    iSnsREtInfoEntry  OBJECT-TYPE
        SYNTAX            iSnsREtInfoEntry
        MAX-ACCESS        not-accessible
        STATUS            current
        DESCRIPTION
    "Information on registered entities in the iSNS."
        INDEX   {iSnsREtEIdx}
        ::= {iSnsRegEntityTable 1}

    iSnsREtInfoEntry ::=
        SEQUENCE {
           iSnsREtEIdx         EntIdx,
           iSnsREtEID            EIDtype,
           iSnsREtType         EntType,
           iSnsREtMgtIpAddr    IpAddress,
           iSnsREtESIintvl     INTEGER,
           iSnsREtESIport      INTEGER,
           iSnsREtTimestamp    DateAndTime,
           iSnsREtESCNmap      OCTET STRING
                  }

    iSnsREtEIdx                OBJECT-TYPE
        SYNTAX                 EntIdx
        MAX-ACCESS             read-only
        STATUS                 current

Gibbons, Tseng, Monia      Standards Track                          85
iSNS                          March 2001

        DESCRIPTION
    "The Entity Index for this entity.  The index is
     derived for mapping between objects."
        ::= {iSnsREtInfoEntry 1}

    iSnsREtEID                 OBJECT-TYPE
        SYNTAX                 EIDtype
        MAX-ACCESS             read-only
        STATUS                 current
        DESCRIPTION
    "The Entity Identifier for this entity as defined in
     the iSNS Specification."
        ::= {iSnsREtInfoEntry 2}

    iSnsREtType                OBJECT-TYPE
        SYNTAX                 EntType
        MAX-ACCESS             read-only
        STATUS                 current
        DESCRIPTION
    "The Entity Type as defined in the iSNS Specification.
               Type Value       Entity Type
               ----------       -----------
                  1             iSCSI
                  2             iFCP
                  3             FCIP
                All Others      Reserved
    "
        ::= {iSnsREtInfoEntry 3}

    iSnsREtMgtIpAddr           OBJECT-TYPE
        SYNTAX                 IpAddress
        MAX-ACCESS             read-only
        STATUS                 current
        DESCRIPTION
    "The Entity Management IP address for this entity as
     defined in the iSNS Specification."
        ::= {iSnsREtInfoEntry 4}

    iSnsREtESIintvl            OBJECT-TYPE
        SYNTAX                 INTEGER
        MAX-ACCESS             read-only
        STATUS                 current
        DESCRIPTION
    "ESI interval as defined in the iSNS Specification."
        ::= {iSnsREtInfoEntry 5}

    iSnsREtESIport            OBJECT-TYPE
        SYNTAX                 INTEGER
        MAX-ACCESS             read-only
        STATUS                 current
        DESCRIPTION
    "The TCP/UDP port used for ESI updates as defined
     in the iSNS Specification."

Gibbons, Tseng, Monia      Standards Track                          86
iSNS                          March 2001

        ::= {iSnsREtInfoEntry 6}

    iSnsREtTimestamp            OBJECT-TYPE
        SYNTAX                 DateAndTime
        MAX-ACCESS             read-only
        STATUS                 current
        DESCRIPTION
    "The entity registration timestamp as defined in the
     iSNS Specification."
        ::= {iSnsREtInfoEntry 7}

    iSnsREtESCNmap            OBJECT-TYPE
        SYNTAX                 OCTET STRING (SIZE (4))
        MAX-ACCESS             read-only
        STATUS                 current
        DESCRIPTION
    "The entity SCN notification map as defined in the
     iSNS Specification."
        ::= {iSnsREtInfoEntry 8}

    --
    -- iSNS Registered Portal Information
    --

    iSnsNumPortals        OBJECT-TYPE
        SYNTAX            INTEGER
        MAX-ACCESS        read-only
        STATUS            current
        DESCRIPTION
    "The current total number of registered Portals in iSNS."
        ::= {iSnsRegObj 3}

    --
    -- iSNS Registered Portals Table
    --

    iSnsRegPortalTable OBJECT-TYPE
        SYNTAX        SEQUENCE OF iSnsRPRTLtInfoEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
    "A table containing the registered portals in the iSNS."
        ::= {iSnsRegObj 4}

    iSnsRPRTLtInfoEntry  OBJECT-TYPE
        SYNTAX            iSnsRPRTLtInfoEntry
        MAX-ACCESS        not-accessible
        STATUS            current
        DESCRIPTION
    "Information on registered entity portals in the iSNS."
        INDEX   {iSnsRPRTLtEIdx, iSnsRPRTLtPrtlIdx}
        ::= {iSnsRegPortalTable 1}


Gibbons, Tseng, Monia      Standards Track                          87
iSNS                          March 2001

    iSnsRPRTLtInfoEntry ::=
        SEQUENCE {
           iSnsRPRTLtEIdx      EntIdx,
           iSnsRPRTLtPrtlIdx   PrtlIdx,
           iSnsRPRTLtEID       EIDtype,
           iSnsRPRTLtIpAddr    IpAddress,
           iSnsRPRTLtPort      INTEGER
                  }

    iSnsRPRTLtEIdx             OBJECT-TYPE
        SYNTAX                 EntIdx
        MAX-ACCESS             read-only
        STATUS                 current
        DESCRIPTION
    "The Entity Index of the entity associated with this portal.
     The index is derived for mapping between objects."
        ::= {iSnsRPRTLtInfoEntry 1}

    iSnsRPRTLtPrtlIdx          OBJECT-TYPE
        SYNTAX                 PortalIdx
        MAX-ACCESS             read-only
        STATUS                 current
        DESCRIPTION
    "The Portal Index for this node.  The index is derived for
     mapping between objects."
        ::= {iSnsRPRTLtInfoEntry 2}

    iSnsRPRTLtEID              OBJECT-TYPE
        SYNTAX                 EIDtype
        MAX-ACCESS             read-only
        STATUS                 current
        DESCRIPTION
    "The Entity Identifier of the entity associated with this portal."
        ::= {iSnsRPRTLtInfoEntry 3}

    iSnsRPRTLtIpAddr           OBJECT-TYPE
        SYNTAX                 IpAddress
        MAX-ACCESS             read-only
        STATUS                 current
        DESCRIPTION
    "The IP Address for this portal as defined in the iSNS
     Specification."
        ::= {iSnsRPRTLtInfoEntry 4}

    iSnsRPRTLtPort             OBJECT-TYPE
        SYNTAX                 INTEGER
        MAX-ACCESS             read-only
        STATUS                 current
        DESCRIPTION
    "The TCP/UDP port for this portal as defined in the iSNS
     Specification."
        ::= {iSnsRPRTLtInfoEntry 5}


Gibbons, Tseng, Monia      Standards Track                          88
iSNS                          March 2001

    --
    -- iSNS Registered Node Information by WWUI,
    --

    iSnsNumWWUINodes      OBJECT-TYPE
        SYNTAX            INTEGER
        MAX-ACCESS        read-only
        STATUS            current
        DESCRIPTION
    "The current total number of Node entries, by WWUI, in the iSNS."
        ::= {iSnsRegObj 5}

    --
    -- iSNS Registered Node Table by WWUI
    --

    iSnsRegWWUINodeTable OBJECT-TYPE
        SYNTAX        SEQUENCE OF iSnsRegWWUINtEntry
        MAX-ACCESS    not-accessible
        STATUS        current
        DESCRIPTION
    "A table containing the registered Nodes, by WWUI, in the iSNS."
        ::= {iSnsRegObj 6}

    iSnsRegWWUINtEntry    OBJECT-TYPE
        SYNTAX            iSnsRegWWUINtEntry
        MAX-ACCESS        not-accessible
        STATUS            current
        DESCRIPTION
    "Information on registered entity nodes, by WWUI, in the iSNS."
        INDEX          {iSnsRegWWUINtEIdx, iSnsRegWWUINtNodeIdx}
        ::= {iSnsRegWWUINodeTable 1}

    iSnsRegWWUINtEntry ::= SEQUENCE {
        iSnsRegWWUINtEIdx              EntIdx,
        iSnsRegWWUINtNodeIdx           NodeIdx,
        iSnsRegWWUINtEID               EIDtype,
        iSnsRegWWUINtNodeWWUI          WWUItype,
        iSnsRegWWUINtNodeType          NodeType,
        iSnsRegWWUINtNodeAliasSymb     OCTET STRING
                                    }

    iSnsRegWWUINtEIdx            OBJECT-TYPE
        SYNTAX                   EntIdx
        MAX-ACCESS               read-only
        STATUS                   current
        DESCRIPTION
    "The Entity Index of the Entity associated with this node.  The
     index is derived for mapping between objects."
        ::= {iSnsRegWWUINtEntry 1}

    iSnsRegWWUINtNodeIdx          OBJECT-TYPE
        SYNTAX                    NodeIdx

Gibbons, Tseng, Monia      Standards Track                          89
iSNS                          March 2001

        MAX-ACCESS                read-only
        STATUS                    current
        DESCRIPTION
    "The Node Index for this node.  The index is derived for
     mapping between objects."
        ::= {iSnsRegWWUINtEntry 2}

    iSnsRegWWUINtEID             OBJECT-TYPE
        SYNTAX                   EIDtype
        MAX-ACCESS               read-only
        STATUS                   current
        DESCRIPTION
    "The Entity Identifier of the Entity associated with this node."
        ::= {iSnsRegWWUINtEntry 3}

    iSnsRegWWUINtNodeWWUI        OBJECT-TYPE
        SYNTAX                   WWUItype
        MAX-ACCESS               read-only
        STATUS                   current
        DESCRIPTION
    "The WWUI for this node as defined in the iSNS Specification."
        ::= {iSnsRegWWUINtEntry 4}

    iSnsRegWWUINtNodeType         OBJECT-TYPE
        SYNTAX                    NodeType
        MAX-ACCESS                read-only
        STATUS                    current
        DESCRIPTION
    "The Node Type bit-map as defined in the iSNS Specification.
               Bit Field       Node Type
               ---------       ---------
                  0 (Lsb)      Target
                  1            Initiator
               All Others      RESERVED
    "
        ::= {iSnsRegWWUINtEntry 5}

    iSnsRegWWUINtNodeAliasSymb    OBJECT-TYPE
        SYNTAX                    OCTET STRING (SIZE(0..255))
        MAX-ACCESS                read-only
        STATUS                    current
        DESCRIPTION
    "The Alias/Symbolic Name of the node as defined in the
     iSNS Specification.  This is a variable-length text-based
     description of up to 255 bytes."
        ::= {iSnsRegWWUINtEntry 6}

    --
    -- iSNS Registered Node, by WWN, Information
    --

    iSnsNumWWNNodes      OBJECT-TYPE
        SYNTAX            INTEGER

Gibbons, Tseng, Monia      Standards Track                          90
iSNS                          March 2001

        MAX-ACCESS        read-only
        STATUS            current
        DESCRIPTION
    "The current total number of Node entries, by WWN, in the iSNS."
        ::= {iSnsRegObj 7}

    --
    -- iSNS Registered Node Table by WWN
    --

    iSnsRegWWNNodeTable    OBJECT-TYPE
        SYNTAX         SEQUENCE OF iSnsRegWWNNtEntry
        MAX-ACCESS     not-accessible
        STATUS         current
        DESCRIPTION
    "A table containing the registered Nodes, by WWN, in the iSNS."
        ::= {iSnsRegObj 8}

    iSnsRegWWNNtEntry    OBJECT-TYPE
        SYNTAX           iSnsRegWWNNtEntry
        MAX-ACCESS       not-accessible
        STATUS           current
        DESCRIPTION
    "Information on registered entity nodes, by WWN, in the iSNS."
        INDEX          {iSnsRegWWNNtNodeWwn}
        ::= {iSnsRegWWNNodeTable 1}

    iSnsRegWWNNtEntry ::= SEQUENCE {
        iSnsRegWWNNtNodeWwn           WWNtype,
        iSnsRegWWNNtEIdx              EntIdx,
        iSnsRegWWNNtEID               EIDtype,
        iSnsRegWWNNtNodeType          NodeType,
        iSnsRegWWNNtNodeAliasSymb     OCTET STRING,
        iSnsRegWWNNtFcNodeIpAddress   IpAddress,
        iSnsRegWWNNtFcNodeIPA         OCTET STRING
                                    }

    iSnsRegWWNNtNodeWwn          OBJECT-TYPE
        SYNTAX                   WWNtype
        MAX-ACCESS               read-only
        STATUS                   current
        DESCRIPTION
    "The Node WorldWideName as defined in the iSNS Specification."
        ::= {iSnsRegWWNNtEntry 1}

    iSnsRegWWNNtEIdx          OBJECT-TYPE
        SYNTAX                   EntIdx
        MAX-ACCESS               read-only
        STATUS                   current
        DESCRIPTION
    "The Entity Index of the Entity associated with this node.  The
     index is derived for mapping between objects."
        ::= {iSnsRegWWNNtEntry 2}

Gibbons, Tseng, Monia      Standards Track                          91
iSNS                          March 2001


    iSnsRegWWNNtEID          OBJECT-TYPE
        SYNTAX                   EIDtype
        MAX-ACCESS               read-only
        STATUS                   current
        DESCRIPTION
    "The Entity Identifier of the Entity associated with this node."
        ::= {iSnsRegWWNNtEntry 3}

    iSnsRegWWNNtNodeType         OBJECT-TYPE
        SYNTAX                   NodeType
        MAX-ACCESS               read-only
        STATUS                   current
        DESCRIPTION
    "The Node Type bit-map as defined in the iSNS Specification.
               Bit Field       Node Type
               ---------       ---------
                  0 (Lsb)      Target
                  1            Initiator
               All Others      RESERVED
    "
        ::= {iSnsRegWWNNtEntry 4}

    iSnsRegWWNNtNodeAliasSymb    OBJECT-TYPE
        SYNTAX                   OCTET STRING (SIZE(0..255))
        MAX-ACCESS               read-only
        STATUS                   current
        DESCRIPTION
    "The Alias/Symbolic Name of the node as defined in the
     iSNS Specification.  This is a variable-length text-based
     description of up to 255 bytes."
        ::= {iSnsRegWWNNtEntry 5}

    iSnsRegWWNNtFcNodeIpAddress  OBJECT-TYPE
        SYNTAX                   IpAddress
        MAX-ACCESS               read-only
        STATUS                   current
        DESCRIPTION
    "The FC Node IP address of the node as defined in the
     iSNS Specification."
        ::= {iSnsRegWWNNtEntry 6}

    iSnsRegWWNNtFcNodeIPA        OBJECT-TYPE
        SYNTAX                   OCTET STRING (SIZE(8))
        MAX-ACCESS               read-only
        STATUS                   current
        DESCRIPTION
    "The object identifies the FC Initial Process Associator
     of the node for the entry as defined in the iSNS
     Specification."
        ::= {iSnsRegWWNNtEntry 7}

    --

Gibbons, Tseng, Monia      Standards Track                          92
iSNS                          March 2001

    -- iSNS Registered Port Information
    --

    iSnsNumPorts          OBJECT-TYPE
        SYNTAX            INTEGER
        MAX-ACCESS        read-only
        STATUS            current
        DESCRIPTION
    "The current total number of Port entries in the iSNS.
     This is only applicable to iFCP entries."
        ::= {iSnsRegObj 9}

    --
    -- iSNS Port Table
    --

    iSnsRegWWNPortTable    OBJECT-TYPE
        SYNTAX             SEQUENCE OF iSnsRegWWNPtEntry
        MAX-ACCESS         not-accessible
        STATUS             current
        DESCRIPTION
    "Information on registered entity ports, by WWN, in the iSNS."
        ::= {iSnsRegObj 10}

    iSnsRegWWNPtEntry        OBJECT-TYPE
        SYNTAX             iSnsRegWWNPtEntry
        MAX-ACCESS         not-accessible
        STATUS             current
        DESCRIPTION
    "Information on registered entity ports, by WWN, in the iSNS."
        INDEX          {iSnsRegWWNPtPortWwn}
        ::= {iSnsRegWWNPortTable 1}

    iSnsRegWWNPtEntry ::= SEQUENCE {
        iSnsRegWWNPtPortWwn             WWNtype,
        iSnsRegWWNPtPortID              FCIDtype,
        iSnsRegWWNPtPortType            INTEGER,
        iSnsRegWWNPtPortSymb            OCTET STRING,
        iSnsRegWWNPtNodeWwn             WWNtype,
        iSnsRegWWNPtFabricPortWwn       WWNtype,
        iSnsRegWWNPtFcHA                FCIDtype,
        iSnsRegWWNPtFcPortIpAddress     IpAddress,
        iSnsRegWWNPtFcCos               INTEGER,
        iSnsRegWWNPtFcFc4Types          OCTET STRING,
        iSnsRegWWNPtFcFc4Descr          OCTET STRING,
        iSnsRegWWNPtFcFc4Features       OCTET STRING
                                  }

    iSnsRegWWNPtPortWwn           OBJECT-TYPE
        SYNTAX                    WWNtype
        MAX-ACCESS                read-only
        STATUS                    current
        DESCRIPTION

Gibbons, Tseng, Monia      Standards Track                          93
iSNS                          March 2001

    "The Port WWN as defined in the iSNS Specification."
        ::= {iSnsRegWWNPtEntry 1}

    iSnsRegWWNPtPortID            OBJECT-TYPE
        SYNTAX                    FCIDtype
        MAX-ACCESS                read-only
        STATUS                    current
        DESCRIPTION
    "The Port ID as defined in the iSNS Specification."
        ::= {iSnsRegWWNPtEntry 2}

    iSnsRegWWNPtPortType          OBJECT-TYPE
        SYNTAX          INTEGER {
            unknown       (0),
            n-port        (1),
            nl-port       (2),
            f-nl-port     (3),
            f-port        (129),     -- x'81'
            fl-port       (130),     -- x'82'
            e-port        (132),     -- x'84'
            b-port        (133),     -- x'85'
            mFCP-port     (65297),   -- x'FF11'
            iFCP-port     (65298),   -- x'FF12'
            unknown-end   (65535)
                }
        MAX-ACCESS      read-only
        STATUS          current
        DESCRIPTION
    "The Port Type as defined in the iSNS Specification."
        ::= {iSnsRegWWNPtEntry 3}

    iSnsRegWWNPtPortSymb      OBJECT-TYPE
        SYNTAX                OCTET STRING(SIZE(0..255))
        MAX-ACCESS            read-only
        STATUS                current
        DESCRIPTION
    "The Port Symbolic Name as defined in the iSNS Specification."
        ::= {iSnsRegWWNPtEntry 4}

    iSnsRegWWNPtNodeWwn       OBJECT-TYPE
        SYNTAX                WWNtype
        MAX-ACCESS            read-only
        STATUS                current
        DESCRIPTION
    "The Node WWN associated with this Port as defined in the iSNS
    Specification."
        ::= {iSnsRegWWNPtEntry 5}

    iSnsRegWWNPtFabricPortWwn   OBJECT-TYPE
        SYNTAX                  WWNtype
        MAX-ACCESS              read-only
        STATUS                  current
        DESCRIPTION

Gibbons, Tseng, Monia      Standards Track                          94
iSNS                          March 2001

    "The Fabric Port WWN associated with this Port as defined in the
    iSNS Specification."
        ::= {iSnsRegWWNPtEntry 6}

    iSnsRegWWNPtFcHA             OBJECT-TYPE
        SYNTAX                   FCIDtype
        MAX-ACCESS               read-only
        STATUS                   current
        DESCRIPTION
    "The FC Hard Address as defined in the iSNS Specification."
        ::= {iSnsRegWWNPtEntry 7}

    iSnsRegWWNPtFcPortIpAddress  OBJECT-TYPE
        SYNTAX                   IpAddress
        MAX-ACCESS               read-only
        STATUS                   current
        DESCRIPTION
    "The FC Port IP Address as defined in the iSNS Specification."
        ::= {iSnsRegWWNPtEntry 8}

    iSnsRegWWNPtFcCos         OBJECT-TYPE
        SYNTAX          INTEGER {
                --        class-unknown (0),
                          class-F (1),
                          class-1 (2),
                          class-F-1 (3),
                          class-2 (4),
                          class-F-2 (5),
                          class-1-2 (6),
                          class-F-1-2 (7),
                          class-3 (8),
                          class-F-3 (9),
                          class-1-3 (10),
                          class-F-1-3 (11),
                          class-2-3 (12),
                          class-F-2-3 (13),
                          class-1-2-3 (14),
                          class-F-1-2-3 (15)
                        }
        MAX-ACCESS     read-only
        STATUS         current
        DESCRIPTION
    "The FC Class of Service as defined in the iSNS Specification."
        ::= {iSnsRegWWNPtEntry 9}

    iSnsRegWWNPtFcFc4Types    OBJECT-TYPE
        SYNTAX                OCTET STRING (SIZE (32))
        MAX-ACCESS            read-only
        STATUS                current
        DESCRIPTION
    "The FC FC-4 Types as defined in the iSNS Specification."
        ::= {iSnsRegWWNPtEntry 10}


Gibbons, Tseng, Monia      Standards Track                          95
iSNS                          March 2001

    iSnsRegWWNPtFcFc4Descr    OBJECT-TYPE
        SYNTAX                OCTET STRING (SIZE (32))
        MAX-ACCESS            read-only
        STATUS                current
        DESCRIPTION
    "The FC FC-4 Descriptors as defined in the iSNS Specification."
        ::= {iSnsRegWWNPtEntry 11}

    iSnsRegWWNPtFcFc4Features    OBJECT-TYPE
        SYNTAX                OCTET STRING (SIZE (32))
        MAX-ACCESS            read-only
        STATUS                current
        DESCRIPTION
    "The FC FC-4 Features as defined in the iSNS Specification."
        ::= {iSnsRegWWNPtEntry 12}

    END





































Gibbons, Tseng, Monia      Standards Track                          96


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