Internet Draft K. Gibbons J. Tseng Expires April 2001 C. Monia Nishan Systems October 2000 iSNS Internet Storage Name Service Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Comments Comments should be sent to the ips mailing list (ips@ece.cmu.edu) or to the authors. 1. Abstract The Internet Storage Name Service (iSNS) provides a generic framework for configuring and managing various storage entities and their usage attributes in an IP-based storage network. iSNS integrates Fibre Channel name server and DNS mechanisms into a common naming and resource-discovery framework. The iSNS Protocol (iSNSP) defines how entities communicate with the iSNS server to discover and utilize available networked storage resources. The iSNS server MAY be supported by a consolidated iSNS directory database, which serves as a repository to store information about various storage resources, providing easy access to topology information for storage entities. 2. Conventions used in this document iSNS refers to the framework consisting of the storage network model and associated services. Gibbons, Tseng, Monia 2 iSNS October 2000 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 3. iSNS Overview IP network entities use the Domain Name System (DNS) to resolve mappings of DNS names to IP addresses. Fibre Channel-based storage entities use a Storage Name Server (SNS) to discover other storage entities and their addressing information. The iSNSP provides a common framework to supply both DNS and SNS services for all storage entities. Although the DNS and SNS infrastructures MAY be managed separately, nevertheless they must provide consistent naming and addressing information to both IP-based and Fibre Channel-based storage entities. The iSNS Protocol (iSNSP) provides a common framework for integration of these naming services for both IP and Fibre Channel-based storage entities. This framework builds upon the association of IP and Fibre Channel objects, and the resulting consistency guarantees among these objects. Regardless of the underlying implementation, the framework presents the illusion of common IP and Fibre Channel objects. . Some attributes of these database objects may be applicable to Fibre Channel-based entities, while other attributes may be applicable only to IP-based iSCSI entities. Still other attributes such as World Wide Port Name may be used by both Fibre Channel and iSCSI entities. Values stored as attributes for both iSCSI and Fibre Channel devices SHALL be consistent regardless of whether they are accessed for use by iSCSI or Fibre Channel devices. The consistency guarantee MAY be implemented through a consolidated information base. Gibbons, Tseng, Monia 3 iSNS October 2000 The following diagram shows an example of Fibre Channel clients and IP clients accessing SNS and DNS data via iSNS server and DNS server: +------------+ +-----------+ +-----------+ | | LDAP | Directory | LDAP | iSNS | | DNS Server |<-------->| Database |<-------->| Server | | | | | | | +------+-----+ +-----+-----+ +-----+-----+ | | | | DNS | LDAP iSNSP | |Queries | | +------+----------------------+----------------------+-----+ | | | IP Network | | | +------+----------------------+----------------------+-----+ | | | | +-------+------+ | | | FC-IP / | | | |Gateway /iSNS | | | | Proxy /Server| | | +-------+------+ | | | | +----+----+ +----+----+ +----+----+ | iSCSI | | Fibre | | iSCSI | |Initiator| | Channel | | Target | | | | Network | | | +---------+ +---------+ +---------+ iSNS Client Entities In the above example, each iSNS Client Entity has its attributes committed to the directory database, regardless of whether the client is a Fibre Channel entity, or an IP-based entity. A DNS server receiving a DNS resolve request can use the directory database to resolve DNS names to IP addresses. Changes to DNS name mappings due to DNS Zone transfers and other DNS protocol events will be reflected directory update messages to the database, and consistently reflected in subsequent iSNSP queries and SCN's. The iSNS server may be a standalone entity, or it may be integrated into another network entity such as a Fibre Channel-iSCSI gateway proxy device. The iSNS directory database may be cohosted with the iSNS server, or it may be a separate infrastructure based on distributed directory database services such as LDAP. 3.1 iSNS Functional Components Gibbons, Tseng, Monia 4 iSNS October 2000 There are four functional components required by devices operating in a IP-based storage network: 1) A Name Service Providing Storage Resource Discovery 2) State Change Notification Service 3) Network Zoning Service 4) Domain Name System (DNS) Service (see RFC 1035) 3.1.1 Name Registration Service The iSNS provides a registration function to allow all entities in a storage network to register and query the directory. This allows an iSNS client initiator to obtain information about iSNS client target devices from the iSNS server. This service is modeled on the Fiber Channel Name Services described in FC-GS-2, with extensions, operating within the context of an IP network. 3.1.2 State Change Notification Service The State Change Notification service provides functionality for issuing notifications about network events that may affect the operational state of iSNS entities. The State Change Notification service gives an iSNS client the ability to register for notification of events detected or received by the iSNS server from an iSNS client entity. This service provides the Fiber Channel State Change Notification service, with extensions, operating within the context of an IP network. 3.1.3 Network Zoning Service The Network Zoning Service implements the functionality to support grouping of iSNS client devices into domains for administrative and access control purposes. Devices must be in common zones in order to "see" each other and communicate through the network. Devices can be a member of multiple zones simultaneously. 3.1.4 DNS Name Service The iSNS framework unifies the above storage services used in Fibre Channel with the Domain Name System (DNS) service in IP-based networks. A detailed description of the Domain Name System (DNS) protocol is found in [RFC 1035], and is beyond the scope of this document. In the iSNS framework, the DNS host names can be given to storage controllers, HBA's, gateways, and iSCSI NICs. To create a unified iSNS framework, DNS naming features now coexist with storage concepts such as World Wide Names (WWN's). For example, WWN's can now be used as a key in an iSNS query to discover the DNS Name and Path of a particular storage device. Similarly, the iSNS directory database can be used to support queries by DNS resolvers. Gibbons, Tseng, Monia 5 iSNS October 2000 3.2 iSNS Architectural Components 3.2.1 iSNS Client Entities which initiate transactions using the iSNS protocol will hereafter be referred to as iSNS clients. iSNS clients register their attribute information in the iSNS server through use of the iSNS protocol. 3.2.2 iSNS Server The iSNS server resides at an IP address in the network, and responds to TCP and UDP-based iSNSP messages at a TBD port. It may be implemented on a stand-alone host computer or network management station, or integrated into one or more switches in the network. Administration of the iSNS server is similar to established processes for administering DNS servers. The primary functional difference between the iSNS and classical DNS is the ability for client entities to write information to the server database using the iSNSP. The iSNS server responds to iSNS and DNS protocol queries and requests, and initiates iSNS protocol State Change Notifications. Properly authenticated registration request information is stored in an internal or external database. 3.2.3 iSNS Directory Database The iSNS database is a repository for the iSNS server(s) and DNS server(s) to store information about DNS Names, IP Addresses, Fibre Channel storage attributes (WWNN, Port ID, etc...), and iSCSI storage attributes. The database SHALL guarantee consistency between data stored and retrieved by iSNS server(s) and DNS server(s). This database MAY be implemented using a distributed directory database such as LDAP, and MAY be implemented using a single common database for both iSNS servers and DNS servers. 3.2.4 World Wide Name (WWN) Identifiers iSNS client entities use a set of identifiers to uniquely identify the device (Node) and each network interface (Port) associated with the device. A unique 64-bit World Wide Name (WWN) is assigned to each node and each port on the device. The three WWN types are Node Name (WWNN), Port Name (WWPN), and Fabric Port Name (FWWN). These globally unique identifiers are used during the device registration process, and are assigned values conforming to IEEE Naming Assignment Authority (NAA) type 1, 2, 5, or 6. This format is found in ANSI/IEEE Std 802-1990 [802-1990]. Editor's note: iSCSI naming conventions are TBD by IPS working group. Gibbons, Tseng, Monia 6 iSNS October 2000 3.2.5 IP Address The IP address is used to identify a network interface of an IP storage gateway or native device in an IP network. 3.2.6 DNS Name A DNS Name is assigned to a network node having one or more storage devices. Each IP storage device is distinguished by the Path field. The DNS Name uses a hierarchical name space consisting of one or more labels, each of at most 63 characters. A period is used to separate the labels. The iSNS uses a fully qualified domain name consisting of up to 255 characters. Each Domain Name maps to an IP Address. More information about the DNS Domain Name can be found in RFC 1035. 3.3 Compatible Naming Convention Example The above components of the iSNS architectural framework support the use of Fibre Channel naming conventions as well as the URL convention common in IP networking. The framework allows iSCSI naming conventions to be mapped to naming conventions used in Fibre Channel. For example, the following URL format can be implemented and translated to the Fibre Channel naming convention through use of the iSNS server: iscsi://server1.nishansystems.com/device3?WWPN=c2ae3253f3 The iSCSI client parsing this URL would submit an iSNSP query to the iSNS server, using the keys DNS Name = "server1.nishansystems.com", Path = "device3" and WWPN = "c2ae3253f3". The iSNS directory database would retrieve the attribute IP Address = ww.xx.yy.zz as the proxy IP gateway address to the Fibre Channel fabric. DevGetNext queries to the iSNS server will allow the iSCSI client to further discover additional targets in the Fibre Channel fabric by returning their WWPN's. 3.4 iSNS Applicability iSNSP functions in networks under cooperative administrative control. Such networks permit a policy to be implemented regarding security, multicast routing, and organization of services and clients into groups. Through leveraging of an Internet-based distributed database framework such as LDAP, iSNS functionality can be broadly extended to the Public Internet. Additionally, the iSNS framework leverages existing DNS mechanisms, where zone transfer of domain information may take place from upstream authorities in the DNS hierarchy. Gibbons, Tseng, Monia 7 iSNS October 2000 The iSNSP provides a common framework for providing the above services for IP-based storage devices such as native iSCSI storage products, as well as FCP-based devices such as existing Fibre Channel storage devices. 4. iSCSI/Fibre Channel Database Objects iSNS provides the framework for archiving and retrieval of topology information of iSCSI and Fibre Channel-based storage devices. This architecture defines objects which represent storage entity components in both Fibre Channel and IP-based storage devices. The following architecture framework includes all elements needed to describe both iSCSI-based and FCP-based (Fibre Channel) storage device attributes in the iSNS directory database. Existing Fibre Channel storage resources can now be described to iSCSI-based iSNS clients for access through a proxy iSCSI/Fibre Channel gateway. Four object entities are defined in this architecture framework. They are IP STORAGE NODE, STORAGE ENTITY, ZONE and STORAGE PORT. Each of these objects are defined in sections 4.1, 4.2, 4.3, and 4.4. The following diagram shows how database objects are used to represent storage components (with the exception of Zones). Each object has a set of attributes described in section 5., which may be applicable in either a iSCSI or Fibre Channel network, or both. Objects are denoted in all CAPITAL letters. Gibbons, Tseng, Monia 8 iSNS October 2000 +----------------------------------------------------------------+ | IP Network | +--------------------+---------------------+---------------------+ | | IP Address 1 o o IP Address 2 | | +--------------------|---------------------|---------------------+ | | | | | +----------------+---------------------+-----------------+ | | | Service Delivery Subsystem (FC or internal dev bus) | | | +--------+ +---------------------+ +-----------+ +-------+ | | | | | | | | | | | | | | | | | | +--------+ +-------+ +-----+ +-----------+ +-------+ | | | |STORAGE| | | |STORAGE| |STORAGE| | | | | | PORT | | | | PORT | | PORT | | | | | +-------+ | | +-------+ +-------+ | | | | | | | | | | | | 000000000000000000000 | | | | | | Logical Units | | | | | | | | | | initiator | | target | | | | STORAGE ENTITY | | STORAGE ENTITY | | | +------------------+ +-----------------------------+ | | | | IP STORAGE NODE | +----------------------------------------------------------------+ 4.1 IP Storage Node Object The IP Storage Node object defines an IP endpoint node that originates or terminates a TCP/IP connection. An IP End Node may contain one or more Storage Entity objects. This object may be used to define a native iSCSI storage device, iSCSI NIC, a Fibre Channel-iSCSI gateway, or any other storage device with an IP address. In the case of a Fibre Channel to IP gateway, the IP storage node object may support one or more native Fibre Channel storage devices. One or more IP address attribute values may be assigned to an IP Storage Node object entity. The following are attributes of the IP Storage Node object. Each attribute is described in more detail in section 5.4. Applicability indicates whether the attribute is used by an iSCSI device or a Fibre Channel device, or both. A gateway device will need to support both iSCSI and Fibre Channel attributes. The following attributes are described in more detail in sections 5.4. The Key Attribute column indicates the attribute is a search key used to query the database. Gibbons, Tseng, Monia 9 iSNS October 2000 Applicability Attribute iSCSI Fibre Channel Key Attribute --------- ----- ------------- ------------- IP Address * * Management IP Address * * DNS Name * * Client Certificate Port Number 4.2 Storage Entity Object The Storage Entity object defines an individual storage initiator or target. This entity may be a RAID device, a Fibre Channel HBA, or other individual storage device. The Storage Entity may have one or more Storage Port objects. The following are attributes of the Storage Entity object. Each attribute is described in more detail in section 5.4. Applicability indicates whether the attribute is used by an iSCSI device or a Fibre Channel device, or both. A gateway device will need to support both iSCSI and Fibre Channel attributes. The following attributes are described in more detail in sections 5.4. Applicability Attribute iSCSI Fibre Channel Key Attribute --------- ----- ------------- ------------- Node Name * * Node Symbolic Name * FC Node IPA * Node Type * * 4.3 Zone Object Zoning is a security and management mechanism used to partition storage resources. Zoning prevents initiators from potentially logging in to every possible target during device discovery. When queried, the iSNS server will only provide information on storage entities in a common zone. Initiators will thus not be able to "see" devices that are not in a common zone. A Zone entity contains one or more Storage Ports. Storage Ports that are in the same Zone entity can "see" each other, and can thus communicate without restrictions. The following are attributes of the Zone object. Each attribute is described in more detail in section 5.4. Applicability indicates whether the attribute is used by an iSCSI device or a Fibre Channel device, or both. A gateway device will need to support both iSCSI and Fibre Channel attributes. Gibbons, Tseng, Monia 10 iSNS October 2000 The following attributes are described in more detail in sections 5.4. Applicability Attribute iSCSI Fibre Channel Key Attribute --------- ----- ------------- ------------- Zone ID * * * Zone Tag * * * Zone Symbolic Name * * Zone Member (WWPN) * * Zone Member (IP Address) * Zone Member Priority * * 4.4 Storage Port Object The Storage Port object defines an individual service delivery port that services a Storage Entity. The Storage Port provides the interconnect between the Storage Entity and its Logical Units with the Service Delivery Subsystem. The Service Delivery Subsytem may be a Fibre Channel interconnect, or an internal device bus, depending on the specific type of Storage Entity being supported by the Storage Port. A Storage Port may be a member of one or more Zone entities. The following attributes are described in more detail in sections 5.4. Applicability Attribute iSCSI Fibre Channel Key Attribute --------- ----- ------------- ------------- Port Name (WWPN) * * * FC Hard Address * Fabric Port Name (FWWN) * * Port_ID * Port_Symbolic Name * Port_Type * * FC Class of Service * FC Port IP Address * Path * 5. iSNS Message Protocol The following describes the format of the iSNS Protocol: Gibbons, Tseng, Monia 11 iSNS October 2000 Byte MSb LSb Offset 7 6 5 4 3 2 1 0 +----------------------------------+ 0 | iSNSP VERSION | 2 Bytes +----------------------------------+ 2 | FUNCTION ID | 2 Bytes +----------------------------------+ 4 | MESSAGE LENGTH | 2 Bytes +----------------------------------+ 6 | FLAGS | 2 Bytes +----------------------------------+ 8 | TRANSACTION ID | 2 Bytes +----------------------------------+ 10 | MESSAGE PAYLOAD | N Bytes +----------------------------------+ 10 + N | AUTHENTICATION BLOCK (if present)| L Bytes +----------------------------------+ Total Length = 10 + N + L 5.1 iSNS Message Header The iSNSP header contains the iSNSP VERSION, FUNCTION ID, MESSAGE LENGTH, FLAGS, and TRANSACTION ID fields as defined below: iSNSP VERSION - Currently 0x0001 FUNCTION ID defines the type of iSNS message. It contains a value as defined in the "ID" column in the tables below. The following messages are iSNSP request messages: Message Description Abbreviation Func ID Support ------------------- ------------ ------- ------- Register Device Attribute Req RegDevAttr 0x0001 Required Device Attribute Query Request DevAttrQry 0x0002 Required Device Get Next Request DevGetNext 0x0003 Optional Deregister Device Request DeregDev 0x0004 Required SCN Register Request SCNReg 0x0005 Required State Change Notification SCN 0x0006 Required Register Zone RegZone 0x0007 Required Deregister Zone DeregZone 0x0008 Required Register Device in Zone RegDevZone 0x0009 Required Deregister Device in Zone DeregDevZone 0x000A Required Port Status Inquiry PSI 0x000B Optional PSI Update PSIUpdate 0x000C Optional Name Service Heartbeat Heartbeat 0x000D Required RESERVED 0x0000-8000 The following are iSNSP response messages: Gibbons, Tseng, Monia 12 iSNS October 2000 Response Message Description Abbreviation Func_ID Support ---------------------------- ------------ ------- ------- Register Device Attribute RegDevRsp 0x8001 Required Device Attribute Query Response DevAttrQryRsp 0x8002 Required Device Get Next Response DevGetNextRsp 0x8003 Optional Deregister Device Response DeregDevRsp 0x8004 Required SCN Register Response SCNRegRsp 0x8005 Required Register Zone Response RegZoneRsp 0x8006 Required Deregister Zone Response DeregZoneRsp 0x8007 Required Register Device in Zone Response RegDevZoneRsp 0x8008 Required Deregister Device in Zone Resp DeregDevZoneRsp 0x8009 Required RESERVED 0x800A-FFFF iSNS MESSAGE LENGTH - Specifies the length of the MESSAGE PAYLOAD field in bytes. FLAGS - Indicates additional information about the message and the type of iSNS entity that generated the message. The following table displays the valid flags: Bit Field Flag --------- ---- 0-12 RESERVED 13 Authentication Block Present 14 Sender is the iSNS server 15 Sender is the iSNS client TRANSACTION ID - Is set to a unique value for each request message. Replies must use the same TRANSACTION ID value as the associated iSNS request message. If a message is retransmitted, the same TRANSACTION ID value must be used. 5.2 iSNS Message Payload The MESSAGE PAYLOAD is of variable length and contains attributes used for registration and query operations. Each iSNS attribute is specified in the iSNSP message payload using Tag-Length-Value (TLV) format, as shown below: +----------+----------+-------------------+ | attr_id | attr_len | attr_val | +----------+----------+-------------------+ attr_id (ID) - a 2-byte field that identifies the attribute as defined in section 5.4. This field contains the ID of the indicated attribute. attr_len (Length) - a 2-byte field that indicates the length, in bytes, of the attribute value to follow. Gibbons, Tseng, Monia 13 iSNS October 2000 attr_val (Value) - a variable-length field containing the attribute value. The above format is used to identify each attribute in the iSNS message payload. Each iSNSP request message contains several attributes in the above format to identify the requesting iSNS client and register or query for attribute values in the iSNS server. For iSNS response messages sent by the iSNS server to the client, a 4-byte ERROR CODE field is prepended to the MESSAGE PAYLOAD. This field contains 0x0000 (NO ERROR) if the original iSNSP request message was processed normally by the iSNS server. Error codes are described in the following table: Error Code Error Description ---------- ----------------- 0 No Error 1 Unknown Error 2 Format Error 3 Invalid Registration 4 Scope Not Supported 5 Authentication Unknown 6 Authentication Absent 7 Authentication Failed 8 Entry Requested Not Found 9 Version Not Supported 10 Internal Bus Error 11 Busy Now 12 Option Not Understood 13 Invalid Update 14 Message Not Supported 15 Refresh Rejected 5.3 Message Authentication iSNSP provides an optional message authentication capability. Network interactions using iSNSP occur in short transactions, and are generally not sesion based. The iSNS client connects to the iSNS server only when information needs to be registered or queried. Public Key Encryption MAY be used for message authentication. If a public key infrastructure is not available, a shared secret algorithm MAY alternatively be used. A shared secret mechanism may leverage a Kerberos server, or may involve manual distribution of a private key to the iSNS server and each iSNS client. If a PKI is available with an X.509 certificate authority, then public key authentication of clients is possible. The Gibbons, Tseng, Monia 14 iSNS October 2000 authentication block leverages the DSA with SHA-1 algorithm, which can easily integrate into a public key infrastructure. The SNSP optional authentication block is a digital signature for the message. The authentication block contains the following information: 1. A time stamp, to prevent replay attacks 2. A structured authenticator containing a signature calculated over the time stamp and the message being secured 3. An indicator of the cryptographic algorithm that was used to calculate the signature. 4. An indicator of the keying material and algorithm parameters, used to calculate the signature. The authentication block is described in the following figure: Byte MSb LSb Offset 7 6 5 4 3 2 1 0 +----------------------------------+ 0 | BLOCK STRUCTURE DESCRIPTOR | 2 Bytes +----------------------------------+ 2 | AUTHENTICATION BLOCK LENGTH | 2 Bytes +----------------------------------+ 4 | TIMESTAMP | 4 Bytes +----------------------------------+ 8 | SPI STRING LENGTH | 1 Byte +----------------------------------+ 9 | SPI STRING | N Bytes +----------------------------------+ 9 + N | STRUCTURED AUTHENTICATOR | M Bytes +----------------------------------+ Total Length = 9 + N + M BLOCK STRUCTURE DESCRIPTOR (BSD) - Defines the structure and algorithm to use for the STRUCTURED AUTHENTICATOR. Currently, the only defined value for BSD is 0x0002, which represents DSA with SHA-1. Details on DSA can be found in [DSS]. BSD values from 0x0000 to 0x7FFF are assigned by IANA, while 0x8000 to 0x8FFF are for private use. The BSD value 0x0002 is compatible with the X.509 PKI specification, allowing easy integration of the STRUCTURED AUTHENTICATOR format with an existing PKI infrastructure. AUTHENTICATION BLOCK LENGTH - Defines the length of the authentication block, beginning with the BSD field and running through the last byte of the STRUCTURED AUTHENTICATOR. TIMESTAMP - This is a 4-byte unsigned, fixed-point integer giving the number of seconds since midnight, January 1, 1970. SPI STRING LENGTH - The length of the SPI STRING field. Gibbons, Tseng, Monia 15 iSNS October 2000 SPI STRING (Security Parameters Index) - Index to the key and algorithm used by the message recipient to decode the STRUCTURED AUTHENTICATOR field. STRUCTURED AUTHENTICATOR - Contains the digital signature. For the default BSD value of 0x0002, this field contains the binary ASN.1 encoding of output values from the DSA with SHA-1 signature calculation. 5.4 iSNS Client Registration Attributes When an iSNS client registers with the iSNS server, it provides attribute values to describe the entity characteristics and capabilities. The attributes are also returned by the iSNS server in response to queries. The following table lists all iSNSP message attributes for device registration and queries: Attribute Name Size(bytes) ID Reg Key Query Key -------------- ----------- -- ------- --------- Node Name (WWNN) 8 1 1 1,4, 9&10 or 18&19 Node Symbolic Name 0-255 2 1 1,4, 9&10 or 18&19 Management IP Address 16 3 1 1,4, 9&10 or 18&19 Port Name (WWPN) 8 4 1 1 or 9&10 FC Node IPA 8 5 1 1,4 or 9&10 FC Hard Address 3 6 1 1,4 or 9&10 Fabric Port Name (FWWN) 8 7 1 1,4 or 9&10 Node Type 2 8 1 1,4 or 9&10 IP Address 16 9 4 1,4 or 19 Port ID 3 10 4 4 Port Symbolic Name 0-255 11 4 4 or 9&10 Port Type 2 12 4 4 or 9&10 FC Class of Service 4 13 4 4 or 9&10 FC Port IP Address 16 14 4 4 or 9&10 FC-4 Types 32 15 4 4 or 9&10 Port Reg Timestamp 8 16 4 4 or 9&10 Transport Protocol 2 17 4 4 or 9&10 DNS Name 0-255 18 1 or 9 1,4 or 9&10 Path 0-255 19 1 or 9 1,4 or 9&10 Client Certificate variable 20 1 1,4, 9&10 or 18&19 Port Number 2 21 4 4 or 9&10 The following is a description of the columns used in the above table: Size - indicates the attribute length. Variable-length identifiers are NULL character terminated, which is included in the length. ID - the value used to identify the attribute. Gibbons, Tseng, Monia 16 iSNS October 2000 Registration Key - indicates the attribute ID that is the unique key used for attribute registration. This attribute is also known as the primary key for the iSNS directory database entry. Query Key - indicates the attribute ID(s) that is (are) the unique key used to query the iSNS directory database. iSNS client attributes are defined below: 5.4.1 Node Name (WWNN) Node Name is a 64-bit identifier that uniquely identifies the device node in the network. This required field is provided by the iSNS client entity. The format of the Node Name (WWNN) is as defined in section 3.2.4. 5.4.2 Node Symbolic Name This is a variable-length text-based description of up to 255 bytes, that is associated with the device node in the network. The text field contains user-readable ASCII text and is terminated with at least one NULL character. This optional field is normally provided by the iSNS client during registration. However, a network management application can update this field as required. The Node Symbolic Name provides a user-readable description of the device entry in the iSNS. The use of the Node Symbolic Name is consistent with Fibre Channel. 5.4.3 Management IP Address This optional field is provided by the iSNS client. It contains the IP Address used to manage the node. The Management IP Address is a 16-byte field that may contain either a 32-bit IPv4 or 128-bit IPv6 address. When this field contains an IPv4 value, the most significant 12 bytes are set to 0x00. 5.4.4 Port Name (WWPN) This 64-bit identifier uniquely defines the device port. This required field is provided by the iSNS client entity. The format of the Port Name (WWPN) is defined in section 3.2.4. 5.4.5 FC Node Initial Process Associator This optional field is included for compatibility with Fibre Channel, and is provided by the iSNS client entity. The initial process associator can be used for communication between Fibre Channel devices. 5.4.6 FC Hard Address Gibbons, Tseng, Monia 17 iSNS October 2000 This optional is the 24-bit NL Port Identifier, included in the iSNSP for compatibility with Fibre Channel Arbitrated Loop devices and topologies. 5.4.7 Fabric Port Name (FWWN) This 64-bit identifier uniquely defines the fabric port. If the iSNS client is attached to a fabric port with a registered Port Name, then that fabric Port Name shall be indicated in this field. This field is included in the iSNSP for compatibility with Fibre Channel fabric devices and topologies. 5.4.8 Node Type This 16-bit field is a bitmap indicating the type of node. The fields are defined as below. An enabled bit indicates the node has the corresponding characteristics. Bit Field Node Type --------- --------- 0 (Lsb) Target 1 Initiator 2 Proxy 3 Switch All Others RESERVED This field will be consistent with the FC-4 Feature bits described in [FC-GS-3] if the node represents a Fibre Channel device. The default value for this field is 0x0000, which is "unknown". 5.4.9 IP Address This is the IP address associated with a device port in the network. This required field is provided by the iSNS client. When an IPv4 value is contained in this field, the most significant 12 bytes are set to 0x00. 5.4.10 Port ID Along with the IP Address, this field uniquely identifies a native Fibre Channel device port in the network, and maps one-to-one to a specific Port Name (WWPN) entry. The Port ID is only used for native Fibre Channel storage devices, and is unused for native IP- based storage devices. 5.4.11 Port Symbolic Name A variable-length text-based description of up to 256 bytes, that is associated with the iSNS-registered device port in the network. The text field contains user-readable ASCII text and is terminated with at least one NULL character. This optional field is normally Gibbons, Tseng, Monia 18 iSNS October 2000 provided by the iSNS client during registration. However, network management application can update this field as required. The use of the Symbolic Name provides the user with a readable description of the port entry in the iSNS directory database. 5.4.12 Port Type Indicates the type of device port. This is provided by the iSNS client entity. Encoded values for this field are listed in the following table: Type Description ---- ----------- 0x0000 Unidentified/Null Entry 0x0001 Fibre Channel N_Port 0x0002 Fibre Channel NL_Port 0x0003 Fibre Channel F/NL_Port 0x0004-0080 RESERVED 0x0081 Fibre Channel F_Port 0x0082 Fibre Channel FL_Port 0x0083 RESERVED 0x0084 Fibre Channel E_Port 0x0085-00FF RESERVED 0xFF10 iSCSI Port 0xFF11 RESERVED (for mFCP Port*) 0xFF12 RESERVED (for iFCP Port*) 0xFF13-FFFF RESERVED * To be defined later. 5.4.13 Class of Service (COS) This is a 32-bit bit-map field that indicates the COS types that are supported by the registered port. This required field is provided by the iSNS client. The COS values are equivalent to Fibre Channel COS values. The valid COS types, and associated bit- map, are listed in the following table: Class of Service Description Bit-Map ---------------- ----------- --------- 2 Delivery Confirmation Provided bit 2 set 3 Delivery Confirmation Not Provided bit 3 set RESERVED other 5.4.14 FC Port IP Address The IP address associated with the device port in the network. This optional field is included for compatibility with Fibre Channel. When an IPv4 value is contained in this field, the most significant 12 bytes are set to 0x00. This value is provided by the iSNS client. Gibbons, Tseng, Monia 19 iSNS October 2000 5.4.15 FC-4 Types An 8-word bit-map of the FC-4 protocol types supported by the associated port. This required field is provided by the iSNS client. This field can be used to support Fibre Channel devices. 5.4.16 Port Registration Timestamp Indicates the time that the most recent device port registration updates occurred. It is the time, in milliseconds, after the standard base time of 00:00:00 GMT on january 1, 1970, that the last update occurred. The timestamp is used to ensure the SNS directory does not contain entries for non-existent port devices. 5.4.17 Transport Protocol Contains a bit map that indicates the type of transport protocol that the iSNS client supports for transport of storage traffic. This bit map is indicated below: Bit Field Transport Protocol Supported --------- ---------------------------- 0 UDP 1 TCP 2 SCTP Others RESERVED 5.4.18 DNS Name Identifies a node in the IP storage network. The DNS Name, along with the Path, uniquely identify a Node Name (WWNN). It uses existing naming conventions defined in RFC1035. Each DNS Name maps to one IP-addressable node. A node having an IP Address may have more than one storage device. For example, a host at a single IP address may have several device controllers that can be independently addressed by initiators. The Path attribute distinguishes among multiple devices which may reside in an IP- addressable node. 5.4.19 Path Along with the DNS Name, the Path uniquely identifies a native IP- based storage device. The Path distinguishes among multiple IP- based storage entities which may reside at the same IP address. Note that the Path is used only with native IP-based storage devices, and native Fibre Channel devices do not need a Path. The Path field is similar to that of the UNIX file format. 5.4.20 Client Certificate Gibbons, Tseng, Monia 20 iSNS October 2000 This optional attribute MAY contain a X.509 certificate with the public key of the iSNS client. This certificate is used by the iSNS client to authenticate itself for storage transfers with other storage entities. Initiators wishing to communicate with a target storage device MAY retrieve the target's X.509 certificate from the name server in order to encrypt a secret session key using the target's public key contained in the certificate. 5.4.21 Port Number Contains the TCP or UDP port number being used for communication with the iSNS server by the iSNS client. 5.4 Zone Registration Attributes iSNS clients can be placed into zoned areas of control. When an iSNS client or Network Management System registers a zone, it provides attribute values to describe the zone characteristics and capabilities. The following table lists the iSNSP zone attributes: Attribute Name Size(bytes) ID Reg Key Query Key -------------- ----------- -- ------- --------- Zone ID 2 101 101 Zone Tag 2 102 101 101 Zone Symbolic Name 1-64 103 101 101 Zone Member (WWN) 8 104 101 101 Zone Member (IP Addr) 16 105 101 101 Zone Member Priority 1 106 101,105,106 101,104,105 Zone ID - a unique identifier used in the iSNS directory database to indicate the zone. This value is used as the key for any zone attribute query. Zone Tag - the tag used to identify the the zone in the network. Zone Symbolic Name - an ASCII, variable-length string that is NULL-terminated. This is an optional user-readable field that can be used to assist a network administrator in tracking the zone function. Zone Member (WWPN) - the Port Name of an iSNS client that is a member of the zone. The zone may have a list of 0 to n members. Membership is represented by the Port Name of the iSNS client being listed. Zone Member (IP Addr) - the IP address of an iSNS client that is a member of the zone. The zone may have a list of 0 to n members. This IP address indicates that all storage entities using this IP address are members of the zone. Gibbons, Tseng, Monia 21 iSNS October 2000 Zone Member Priority - the 802.1P/Q priority being used for this zone member in the network. This value can range from 0 to 7, and is based on valid 802.1P/Q priority tag values. 5.5 State Change Notification and Port Status Inquiry Flags A State Change Notification (SCN) allows an iSNS client to be notified of changes within a zone, network, or existing device attribute values in the iSNS directory database. An iSNS client registers for SCN's using the SCN Registration Request command. The SCN message is sent to the iSNS client by the iSNS server. The types of changes for which an SCN is sent is based on the flags set in the EVENT TYPE FLAGS field. The EVENT TYPE FLAGS field is a 16-bit mask containing flags for different event types. Port Status Inquiry (PSI) allows an iSNS server to verify that an iSNS client port is still connected to the network. The PSI message is sent to the iSNS client by the server to verify port status. If enabled, the iSNS server will send a PSI to request a Port Status Inquiry Update message from the SCE. The following table displays the flags in the EVENT TYPE FLAGS field used in SCNReg, SCN and PSI messages: Bit Field Flag Description --------- ---------------- 0 CHANGE IN ZONE MEMBERSHIP 1 CHANGE IN NETWORK 2 CHANGE IN DEVICE REGISTRATION PARAMETERS 3 DEVICE ADDED 4 DEVICE REMOVED 5 PORT STATUS UPDATE REQUESTED (for PSI message) CHANGE IN ZONE MEMBERSHIP - indicates a change has occurred in a zone that the iSNS client is a member of. A client can be a member of multiple zones. This flag indicates that a change in registration parameters or membership has occured, either an addition or deletion, to a zone that the client is a member of. CHANGE IN NETWORK - indicates a change in the network has occurred. The change may be anywhere in the network of devices. This flag is administratively controlled, and may not be allowed by the iSNS server except for use by an IP address associated with a Network Management Station. CHANGE TO DEVICE REGISTRATION PARAMETERS - indicates a change in a device registration in the network or zones that the client is a member of. This flag is used in conjunction with CHANGE IN ZONE MEMBERSHIP and CHANGE IN NETWORK flags indicate whether the change Gibbons, Tseng, Monia 22 iSNS October 2000 in device registration occurred in a zone or the network. This flag may be administratively enabled/disabled. DEVICE ADDED - indicates a device addition has occurred in the network or zone. This flag is used in conjunction with CHANGE IN ZONE MEMBERSHIP and CHANGE IN NETWORK flags indicate whether the addition occurred in a zone or the network. DEVICE REMOVED - indicates a device removal has occurred in the network or zone. This flag is used in conjunction with CHANGE IN ZONE MEMBERSHIP and CHANGE IN NETWORK flags indicate whether the removal occurred in a zone or the network. 6. iSNSP Message Descriptions The message payload follows the iSNSP header described in section 5.1. The request message payload contains a list of attributes, each in TLV format described in section 5.2. The iSNSP request message payload contains a list of attributes, and has the following format: +----------------------------------------+ | Source Attribute | +----------------------------------------+ | Key Attribute[1] | +----------------------------------------+ | Key Attribute[2] (if present) | +----------------------------------------+ | . . . | +----------------------------------------+ | Op Attribute[1] | +----------------------------------------+ | Op Attribute[2] (if present) | +----------------------------------------+ | Op Attribute[3] (if present) | +----------------------------------------+ | . . . | +----------------------------------------+ The source attribute is used to identify the iSNS client to the iSNS server. The key attribute is used to identify the entry (or entries) in the iSNS server for the request operation. Following the key attribute is a list of one or more operating attributes directly related to the actual iSNS request message. The number of each attribute (key & operating) depends on the specific iSNSP request or operation being performed. Some iSNSP messages may not specify any attributes. Gibbons, Tseng, Monia 23 iSNS October 2000 The response message contains a 4-byte ERROR CODE field, and depending on the specific iSNSP request, may be followed by a list of attributes. The following table lists each iSNSP message, allowable source attribute ID's, key attribute ID's, and operating attribute ID's. Message Source/Dest Attr Key Attribute Operating Attr ------- ---------------- ------------- -------------- RegDevAttr 1,4,9 1,4,9,18&19 multiple[1-21] RegDevRsp -- -- -- DevAttrQry 4,9 1,4,9,18&19 multiple[1-21] DevAttrQryRsp -- -- multiple[1-21] DevGetNext 4,9 1,4,9,18&19 -- DevGetNextRsp -- -- 1,4,9,18&19 DeregDev 4,9 1,4,9,18&19 -- DeregDevRsp -- -- -- SCNReg 4,9 1,4,9,18&19 -- SCNRegRsp -- -- -- SCN 4,9 (dest) -- -- RegZone 4,9 (dest) 101 multiple[101-106] RegZoneRsp -- -- -- DeregZone 4,9 101 -- DeregZoneRsp -- -- -- RegDevZone 4,9 101 4,9 RegDevZoneRsp -- -- -- DeregDevZone 4,9 101 4,9 DeregDevZoneRsp -- -- -- PSI 4,9 (dest) -- -- PSIUpdate 4,9 -- -- Heartbeat -- -- -- The above table lists attribute ID's from section 5.4 that can be used for each role (source, key, and operating attribute) in the iSNSP message. The source attribute is that of the iSNS client, used in the registration or query message. The key attribute is the attribute used to look up the operating attribute in the iSNS directory database. The operating attribute(s) is the attribute(s) in the iSNS directory database which is to be added, modified, deleted, or queried. If more than one operating attribute can be used, "multiple" is noted in the entry. A "--" entry indicates that the iSNSP message does not use the attribute role (source/dest, key, or operating attribute). Note that the SCN and PSI messages specify the destination attribute in place of the source attribute. 6.1 Register Device Attribute Request (RegDevAttr) The Register Device Attribute Request (RegDevAttr) message provides an iSNS client with the means to register device attributes. The Gibbons, Tseng, Monia 24 iSNS October 2000 iSNS client formulates a register attribute request by specifying a source, query key(s), and list of attributes to register. All values are in Tag Length Value format. The source attribute of the request is the IP address or the 8-byte Port Name (WWPN) of the iSNS client performing the query. The key attribute(s) is based on the type of attributes being registered, and is the IP Address, DNS Name & Path, Node Name (WWNN), or Port Name (WWPN) of the client being registered. If the key attribute matches an existing entry in the iSNS directory database, then the attribute values corresponding to the key entry will be replaced with new values sent in the message. Multiple attributes associated with the one database key attribute can be registered. The source attribute does not need to have been previously registered for the registration to succeed. The use of a Port Name (WWPN) as source does not automatically register it in the database--it is registered by including the attribute as part of a registration using a Node Name (WWNN) as a key. However, a Node Name (WWNN) is registered the first time it is used as a key, so it does not necessarily have to be listed among the attributes to be registered. The RegDevAttr request message payload includes the source attribute (IP Address, Node Name, or Port Name), the key attribute (IP Address, DNS Name & Path, Node Name or Port Name), and one or more operating attributes. 6.2 Register Device Attribute Response (DevAttrRsp) If device attributes are successfully addded to the iSNS directory database as a result of DevAttrReg, then an acknowledgement with an error code of NO ERROR (0) is returned to the iSNS client. If the registration request is unsuccessful, the appropriate error code will be returned. 6.3 Device Attribute Query Request (DevAttrQry) Once iSNS client attributes have been registered in the name service, queries can be made to obtain attributes related to a specific key. The Device Attribute Query Request (DevAttrQry) messages provide an iSNS client with the means to query the iSNS server for device attributes. The key attribute for the DevAttrQry is Node Name (WWNN), Port Name (WWPN), or a key set consisting of DNS Name and Path. The attribute list contains desired attributes. The length field for each requested attribute shall be of length 0. Gibbons, Tseng, Monia 25 iSNS October 2000 The iSNS server uses the key in the request message to query its database, and then returns the corresponding entry or entries for each requested attribute back to the client. The DevAttrQry request message payload includes the source attribute (IP Address or Port Name), the key attribute(s), and one or more operating attributes. 6.4 Device Attribute Query Response (DevAttrQryRsp) The iSNS server uses the DevAttrQryRsp message to send back the attribute query results back to the iSNS client. A successful query will result in attribute values and length fields in the original TLV-formatted DevAttrQry request to be appropriately filled in. A failed query as a result of an inappropriate source and/or key attribute(s) will result in the message payload being replaced with the 4-byte ERROR CODE field. If there is no entry for queried attributes, the TLV-formatted attribute block will be returned with the length field set to 0 or a negative value error code. In addition to the ERROR CODE field, the DevAttrQryRsp message contains a list of operating attributes corresponding to the original request message. The attribute values resulting from the query are represented in the TLV format described in section 5.2. 6.5 Device Get Next Request (DevGetNext) This message provides the iSNS client with the means to sequentially retrieve IP Addresses, DNS Name & Paths, Node Names and Port Names from devices in zones to which the client has access. The source of the query is represented by the IP Address or 8-byte Port Name (WWPN) of the client performing the query. The key tag is the IP Address, DNS Name & Path, Node Name (WWNN), or Port Name (WWPN). If the key length value entered is zero, signifying an empty key value field, the first accessible IP Address, DNS Name, Node Name, or Port Name instance shall be returned to the client. The DevGetNext request message payload contains a source attribute (IP Address or Port Name) and a key attribute (IP Address, DNS Name & Path, Node Name or Port Name). 6.6 Device Get Next Response (DevGetNextRsp) The iSNS server uses the DevGetNextRsp to return the results of the DevGetNext request message. If the DevGetNext query does not identify an IP Address, DNS Name & Path, Node Name, or Port Name following the key provided in the query, and the query completed properly, the attribute value length field is set to zero. Gibbons, Tseng, Monia 26 iSNS October 2000 The DevGetNextRsp response message payload returns the queried attribute resulting from the original DevGetNext request (IP Address, DNS Name & Path, Node Name, or Port Name). 6.7 Deregister Device Request (DeregDev) An iSNS client port or device is removed from the iSNS directory database by using the Deregister Device Request (DeregDev). Upon receiving the DeregDev, the iSNS server removes all attributes associated with the IP Address, DNS Name & Path, Node Name (WWNN) or Port Name (WWPN) key, and sends state change notifications (SCNs) to registered iSNS clients that are in the same Zone as the removed device or port. After removing the port or device, the iSNS server sends back an acknowledgement to the iSNS client. The DeregDev request message payload contains a single source attribute (IP Address or Port Name) and key attributes (IP Address, DNS Name & Path, Node Name or Port Name). 6.8 Deregister Device Response (DeregDevRsp) If device attributes are successfully removed from the iSNS directory database as a result of a Deregister Device Request (DeregDev), the DeregDevRsp message with error code of NO ERROR(0) is returned to the original iSNS client. The DeregDevRsp response message payload does not contain any attributes. 6.9 SCN Registration Request (SCNReg) The State Change Notification Registration Request (SCNReg) message allows an iSNS client to register an IP Address or Port Name (WWPN) for State Change Notification (SCN) messages. SCN messages allow an iSNS client to be notified of changes within the zone or network (if adminstratively allowed) that the device port is a member of. In place of the attribute list for other iSNSP message types, the SCNReg has the 16-bit INTERESTED EVENT TYPE FLAGS field described in section 5.5, which comes immediately after the key attribute. The following displays the format of the SCNReg message payload: Byte MSb LSb Offset 7 6 5 4 3 2 1 0 +----------------------------------+ 0 | source attribute | 12 Bytes +----------------------------------+ 12 | key attribute | 12 Bytes +----------------------------------+ 24 | EVENT TYPE FLAGS | 2 Bytes +----------------------------------+ Total Length = 26 Gibbons, Tseng, Monia 27 iSNS October 2000 Section 5.5 describes each flag used in the EVENT TYPE FLAGS field. 6.10 SCN Registration Response (SCNRegRsp) If the iSNS client successfully registered for state change notifications, an acknowledgement with the ERROR CODE field set to NO ERROR(0) is returned to the client. This message does not contain any attributes. 6.11 State Change Notification (SCN) The State Change Notification is a special message which allows a registered iSNS client to be notified of changes within a zone, network (if administratively allowed), or other device registration parameters in the iSNS directory database. The notification is indicated in the EVENT TYPE FLAGS field described in section 5.5. A time stamp is included in this message following the EVENT TYPE FLAGS field. This time stamp is a 4-byte unsigned, fixed-point integer giving the number of seconds since midnight, January 1, 1970. The format of the message payload of the SCN message is as follows: Byte MSb LSb Offset 7 6 5 4 3 2 1 0 +----------------------------------+ 0 | destination attribute | 12 Bytes +----------------------------------+ 12 | EVENT TYPE FLAGS | 2 Bytes +----------------------------------+ 14 | TIME STAMP | 4 Bytes +----------------------------------+ Total Length = 18 Destination attribute contains the IP Address or Port_Name in TLV format of the iSNS client to receive the SCN message. There is no response message to the SCN message by the iSNS client. 6.12 Register Zone (RegZone) This message allows an iSNS client to create a new Zone to be stored in the iSNS directory database. Once created, Port Names can be added and deleted from the Zone. Zones are defined using Zone IDs, Zone tags, and Symbolic Names. Zone registration attributes are described in section 5.4. The RegZone message payload contains the source attribute (IP Address or Port Name), key attribute (Zone ID), and one or more Zone attributes (Zone Tag, Zone Symbolic Name, Zone Member [IP Address or WWPN], and Zone Member Priority). Gibbons, Tseng, Monia 28 iSNS October 2000 6.13 Register Zone Response (RegZoneRsp) The Register Zone Response (RegZoneRsp) message is used by the iSNS server to acknowledge a RegZone message. If a Zone is successfully created with the requested attributes, the RegZoneRsp is returned to the client with an ERROR CODE of NO ERROR(0). The message payload contains no attributes. 6.14 Deregister Zone (DeregZone) This message allows an iSNS client to delete an existing Zone from the iSNS directory database. A zone with non-zero membership cannot be deleted. The DeregZone message payload contains the source attribute (IP Address or Port Name) and key attribute (Zone ID). 6.15 Deregister Zone Response (DeregZoneRsp) This message is used by the iSNS server to acknowledge a DeregZone request. If the zone was successfully deregistered, an acknowledgement is sent with an ERROR CODE of NO ERROR(0). The DeregZoneRsp message payload does not contain any attributes. 6.16 Register Device in Zone (RegDevZone) Devices can be added to a zone by registering the port names of the devices. Adding an IP Address or Port Name (WWPN) to the zone provides access to all other device ports in the zone. The RegDevZone message payload contains the source attribute (IP Address or Port Name), key attribute (Zone ID), and one or more Zone attributes (Zone Tag, Zone Symbolic Name, Zone Member [IP Address or Port_Name], and Zone Member Priority). 6.17 Register Device in Zone Response (RegDevZoneRsp) This message provides confirmation that the RegDevZone message was received and processed by the iSNS server. If the device was successfully registered in the zone, an acknowledgement is sent with an ERROR CODE of NO ERROR(0). The RegDevZoneRsp message payload does not contain any attributes. 6.18 Deregister Device in Zone (DeregDevZone) Devices can be removed from a Zone by deleting their IP Address or Port Names (WWPN) from the Zone. Deleting devices from a zone removes access to that device from all other devices in that Zone. The DeregDevZone request message payload contains the source attribute (IP Address or Port Name), key attribute (Zone ID), and Gibbons, Tseng, Monia 29 iSNS October 2000 the operating attribute (IP Address or Port Name) of the device being deregistered. 6.19 Deregister Device in Zone Response (DeregDevZoneRsp) This message provides confirmation that the DeregDevZone message was received and processed by the iSNS server. If the device was successfully deregistered from the zone, an acknowledgement is sent with an ERROR CODE of NO ERROR(0). The DeregDevZoneRsp message payload does not contain any attributes. 6.20 Port Status Inquiry (PSI) The Port Status Inquiry (PSI) message provides the iSNS server with the ability to verify that a registered iSNS client is still accessible. The format of the PSI is similar to the SCN message, and uses the same EVENT TYPE FLAGS field. The types of events and flags are listed in section 5.5. The PSI request message payload contains the attribute (IP Address or Port Name) of the device being inquired for status. 6.21 Port Status Inquiry Update (PSIUpdate) This message provides confirmation that the PSI message was received and processed by the iSNS client. If the client is still accessible by the iSNS server, then it will respond and confirm accessibility through the PSIUpdate message. The PSIUpdate response message payload contains the source attribute (IP Address or Port Name) of the responding device. 6.22 Name Service Heartbeat (Heartbeat) The iSNS server sends out a multicast heartbeat message. The heartbeat can be used by iSNS clients to verify connectivity, as well as to discover the iSNS server. The period of the heartbeat is included in the message, with default period of 15 seconds. There is no response to the Heartbeat message. 7. Security Considerations 7.1 Data Integrity and Authentication Data integrity and authentication requirements for communication between iSNS clients and server can be achieved through use of the authentication block. 7.2 Security Model Gibbons, Tseng, Monia 30 iSNS October 2000 The iSNS server will leverage existing security mechanisms currently used to secure resources such as DNS servers, e-mail relays servers, and other sensitive and otherwise vulnerable network resources. Existing firewalls with stateful inspection technology can examine incoming traffic from the Public Internet, and protect against active attacks. 8. References [RFC1035] Domain Implentation and Specification [STD0035] Domain Name System [RFC2065] Domain Name System Security Extensions [FC-GS-2] Fibre Channel Generic Services-2, ANSI NCITS 288 [FC-GS-3] Fibre Channel Generic Services-3, NCITS Working Draft Rev 6.42, June 7, 2000 [RFC2609] Service Templates and Service [IEEE802.1Q] Standard for Virtual Bridged Local Area Networks [RFC1510] The Kerberos Network Authentication Service [DSS] FIPS PUB 186-2, National Institute of Standards and Technology, Digital Signature Standard(DSS), Technical Report [802-1990] ANSI/IEEE Std 802-1990, Name: IEEE Standards for Local and Metropolitan Area Networks: Overview and Architecture [SPC] SCSI-3 Primary Commands, ANSI NCITS 995D, Revision 11a 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 9. Author's Addresses Josh Tseng Kevin Gibbons Charles Monia Nishan Systems 3850 North First Street San Jose, CA 95134-1702 Phone: (408) 519-3749 Email: jtseng@nishansystems.com Gibbons, Tseng, Monia 31 iSNS October 2000 Full Copyright Statement "Copyright (C) The Internet Society, September 18, 2000. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Gibbons, Tseng, Monia 32 iSNS October 2000