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