idnits 2.17.1 draft-ietf-ips-isns-09.txt: ** The Abstract section seems to be numbered -(913): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1611): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3327): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3383): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3668): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3677): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3686): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3721): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3731): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3740): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(3750): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(4246): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 35 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 8 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 980 has weird spacing: '...plement to U...' == Line 1171 has weird spacing: '...plement to ...' == Line 1479 has weird spacing: '...ificate var ...' == Line 1509 has weird spacing: '...NS Srvr var ...' == Line 1512 has weird spacing: '...SI Node var ...' == (5 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2002) is 7891 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 1035' is mentioned on line 536, but not defined == Missing Reference: 'RFC2608' is mentioned on line 4194, but not defined == Missing Reference: 'RFC 2608' is mentioned on line 965, but not defined == Missing Reference: 'RFC2408' is mentioned on line 4071, but not defined ** Obsolete undefined reference: RFC 2408 (Obsoleted by RFC 4306) == Missing Reference: 'FC-FS' is mentioned on line 4099, but not defined == Missing Reference: 'EUI-64' is mentioned on line 4089, but not defined == Missing Reference: 'DSS' is mentioned on line 4084, but not defined -- Looks like a reference, but probably isn't: '1' on line 3835 -- Looks like a reference, but probably isn't: '2' on line 3840 -- Looks like a reference, but probably isn't: '3' on line 3852 == Missing Reference: 'RFC2407' is mentioned on line 4068, but not defined ** Obsolete undefined reference: RFC 2407 (Obsoleted by RFC 4306) == Missing Reference: 'RFC2409' is mentioned on line 4075, but not defined ** Obsolete undefined reference: RFC 2409 (Obsoleted by RFC 4306) -- Looks like a reference, but probably isn't: '58' on line 4003 == Missing Reference: 'SEC-IPS' is mentioned on line 4058, but not defined == Missing Reference: 'RFC2401' is mentioned on line 4062, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) == Missing Reference: 'RFC2406' is mentioned on line 4065, but not defined ** Obsolete undefined reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) == Missing Reference: 'RFC2412' is mentioned on line 4078, but not defined == Missing Reference: 'RFC793' is mentioned on line 4081, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) == Missing Reference: '802-1990' is mentioned on line 4094, but not defined == Unused Reference: 'RFC1035' is defined on line 4104, but no explicit reference was found in the text == Unused Reference: 'RFC1305' is defined on line 4107, but no explicit reference was found in the text == Unused Reference: 'FC-GS' is defined on line 4110, but no explicit reference was found in the text == Unused Reference: 'FC-GS-2' is defined on line 4112, but no explicit reference was found in the text == Unused Reference: 'FC-GS-3' is defined on line 4114, but no explicit reference was found in the text == Unused Reference: 'FC-GS-4' is defined on line 4116, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) Summary: 11 errors (**), 0 flaws (~~), 30 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPS Josh Tseng 3 Internet Draft Kevin Gibbons 4 Charles Monia 5 Standards Track Nishan Systems 6 Expires September 2002 7 Franco Travostino 8 Nortel Networks 10 Tom McSweeney 11 Curt Du Laney 12 John Dowdy 13 IBM 15 Chad Gregory 16 Intel 18 March 2002 20 Internet Storage Name Service (iSNS) 22 Status of this Memo 24 This document is an Internet-Draft and is in full conformance with 25 all provisions of Section 10 of [RFC2026]. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. Internet-Drafts are draft documents valid for a maximum of 31 six months and may be updated, replaced, or obsoleted by other 32 documents at any time. It is inappropriate to use Internet- Drafts 33 as reference material or to cite them other than as "work in 34 progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Acknowledgements 44 Numerous individuals contributed to the creation of this draft 45 through their careful review and submissions of comments and 46 recommendations. We acknowledge the following persons for their 47 technical contributions to this document: Mark Bakke (Cisco), John 48 Hufferd (IBM), Julian Satran (IBM), Kaladhar Voruganti(IBM), Joe 49 Czap (IBM), Jim Hafner (IBM), Yaron Klein (Sanrad), Larry Lamers 50 (SAN Valley), Jack Harwood (EMC), David Black (EMC), David Robinson 51 (Sun), Joe Souza (Microsoft), Alan Warwick (Microsoft), Bob Snead 52 Internet Storage Name Service (iSNS) February 2002 54 (Microsoft), Fa Yeou (Nishan), Ken Hirata (Vixel), Howard Hall 55 (Pirus), and Marjorie Krueger (HP). 57 Comments 59 Comments should be sent to the IPS mailing list (ips@ece.cmu.edu) or 60 to the authors. 62 Internet Storage Name Service (iSNS) February 2002 64 Table of Contents 66 Status of this Memo...................................................1 67 Acknowledgements......................................................1 68 Comments..............................................................2 69 1. Abstract.......................................................7 70 2. About this Document............................................7 71 2.1 Conventions Used in this Document..............................7 72 2.2 Purpose of this Document.......................................7 73 3. iSNS Overview..................................................7 74 3.1 iSNS Architectural Components..................................8 75 3.1.1 iSNS Protocol (iSNSP)..........................................8 76 3.1.2 iSNS Client....................................................8 77 3.1.3 iSNS Server....................................................8 78 3.1.4 iSNS Database..................................................8 79 3.1.5 iSCSI..........................................................8 80 3.1.6 iFCP...........................................................9 81 3.2 iSNS Functional Overview.......................................9 82 3.2.1 Name Registration Service......................................9 83 3.2.2 Discovery Domain and Login Control Service (Zoning)............9 84 3.2.3 State Change Notification Service.............................11 85 3.2.4 Open Mapping Between Fibre Channel and iSCSI Devices..........11 86 3.3 iSNS and Domain Name System (DNS).............................12 87 3.4 iSNS and LDAP.................................................12 88 3.5 iSNS Server Discovery.........................................13 89 3.5.1 Service Location Protocol (SLP)...............................13 90 3.5.2 Dynamic Host Configuration Protocol (DHCP)....................13 91 3.5.3 iSNS Heartbeat Message........................................13 92 3.6 iSNS and NAT..................................................13 93 3.7 Transfer of iSNS Database Records between iSNS Servers........14 94 3.8 Backup iSNS Servers...........................................16 95 3.9 Deployment Architecture Diagram...............................17 96 4. iSNS Object Model.............................................18 97 4.1 NETWORK ENTITY Object.........................................18 98 4.2 PORTAL Object.................................................19 99 4.3 STORAGE NODE Object...........................................19 100 4.4 FC DEVICE Object..............................................19 101 4.5 DISCOVERY DOMAIN Object.......................................19 102 4.6 DISCOVERY DOMAIN SET Object...................................19 103 4.7 iSNS Database Model...........................................19 104 5. iSNS Implementation Requirements..............................20 105 5.1 iSCSI Requirements............................................20 106 5.1.1 Required Attributes for Support of iSCSI......................20 107 5.1.2 Example iSCSI Object Model Diagrams...........................21 108 5.1.3 Required Commands and Response Messages for Support of iSCSI..23 109 5.2 iFCP Requirements.............................................24 110 5.2.1 Required Attributes for Support of iFCP.......................24 111 5.2.2 Example iFCP Object Model Diagram.............................25 112 5.2.3 Required Commands and Response Messages for Support of iFCP...26 113 5.3 Attribute Descriptions for Discovery Domain Registration......28 114 5.4 Use of TCP For iSNS Communication.............................29 115 5.5 Use of UDP For iSNS Communication.............................30 116 6. iSNS Message Attributes.......................................30 117 6.1 iSNS Attribute Summary........................................30 118 Internet Storage Name Service (iSNS) February 2002 120 6.2 Entity Identifier-Keyed Attributes............................33 121 6.2.1 Entity Identifier (EID).......................................33 122 6.2.2 Entity Protocol...............................................34 123 6.2.3 Management IP Address.........................................34 124 6.2.4 Entity Registration Timestamp.................................34 125 6.2.5 Protocol Version Range........................................34 126 6.2.6 Registration Period...........................................34 127 6.2.7 Entity Index..................................................35 128 6.2.8 Entity ISAKMP Phase-1 Proposals...............................35 129 6.2.9 Entity Certificate............................................36 130 6.3 Portal-Keyed Attributes.......................................36 131 6.3.1 Portal IP-Address.............................................36 132 6.3.2 Portal TCP/UDP Port...........................................36 133 6.3.3 Portal Symbolic Name..........................................36 134 6.3.4 Entity Status Inquiry Interval................................36 135 6.3.5 ESI Port......................................................37 136 6.3.6 Portal Group..................................................37 137 6.3.7 Portal Index..................................................38 138 6.3.8 SCN Port......................................................38 139 6.3.9 Portal Security Bitmap........................................38 140 6.3.10Portal ISAKMP Phase-1 Proposals...............................38 141 6.3.11Portal ISAKMP Phase-2 Proposals...............................39 142 6.3.12Portal Certificate............................................39 143 6.4 iSCSI Node-Keyed Attributes...................................39 144 6.4.1 iSCSI Name....................................................39 145 6.4.2 iSCSI Node Type...............................................39 146 6.4.3 iSCSI Node Alias..............................................40 147 6.4.4 iSCSI Node SCN Bitmap.........................................40 148 6.4.5 iSCSI Node Index..............................................41 149 6.4.6 WWN Token.....................................................41 150 6.4.7 iSCSI AuthMethod..............................................42 151 6.4.8 iSCSI Node Certificate........................................42 152 6.5 FC Port-Keyed Attributes......................................42 153 6.5.1 Port Name (WWPN)..............................................43 154 6.5.2 Port ID.......................................................43 155 6.5.3 Port Type.....................................................43 156 6.5.4 Symbolic Port Name............................................43 157 6.5.5 Fabric Port Name (FWWN).......................................43 158 6.5.6 Hard Address..................................................44 159 6.5.7 Port IP Address...............................................44 160 6.5.8 Class of Service (COS)........................................44 161 6.5.9 FC-4 Types....................................................44 162 6.5.10FC-4 Descriptor...............................................44 163 6.5.11FC-4 Features.................................................44 164 6.5.12iFCP SCN Bitmap...............................................44 165 6.5.13iFCP Port Type................................................45 166 6.5.14Port Certificate..............................................45 167 6.6 Node-Keyed Attributes.........................................46 168 6.6.1 Node Name (WWNN)..............................................46 169 6.6.2 Symbolic Node Name............................................46 170 6.6.3 Node IP Address...............................................46 171 6.6.4 Node IPA......................................................46 172 6.6.5 Node Certificate..............................................46 173 6.6.6 Proxy iSCSI Name..............................................46 174 Internet Storage Name Service (iSNS) February 2002 176 6.7 Other Attributes..............................................47 177 6.7.1 FC-4 Type Code................................................47 178 6.7.2 iFCP Switch Name..............................................47 179 6.7.3 Preferred ID..................................................47 180 6.7.4 Assigned ID...................................................47 181 6.7.5 Space_Identifier..............................................47 182 6.8 Company OUI...................................................48 183 6.9 Discovery Domain Registration Attributes......................48 184 6.9.1 DD Set ID Keyed Attributes....................................48 185 6.9.2 DD ID Keyed Attributes........................................49 186 6.10 Vendor-Specific Attributes....................................50 187 6.10.1Vendor-Specific Server Attributes.............................50 188 6.10.2Vendor-Specific Entity Attributes.............................51 189 6.10.3Vendor-Specific Portal Attributes.............................51 190 6.10.4Vendor-Specific iSCSI Node Attributes.........................51 191 6.10.5Vendor-Specific Port Name Attributes..........................51 192 6.10.6Vendor-Specific Node Name Attributes..........................51 193 6.10.7Vendor-Specific Discovery Domain Attributes...................51 194 6.10.8Vendor-Specific Discovery Domain Set Attributes...............51 195 6.11 Standards-Based Extensions....................................51 196 7. iSNSP Message Format..........................................51 197 7.1 iSNSP PDU Header..............................................52 198 7.1.1 iSNSP Version.................................................52 199 7.1.2 iSNSP Function ID.............................................52 200 7.1.3 iSNSP PDU Length..............................................52 201 7.1.4 iSNSP Flags...................................................52 202 7.1.5 iSNSP Transaction ID..........................................53 203 7.1.6 iSNSP Sequence ID.............................................53 204 7.2 iSNSP Message Segmentation and Reassembly.....................53 205 7.3 iSNSP Message Payload.........................................53 206 7.3.1 Attribute Value 4-Byte Alignment..............................54 207 7.4 iSNSP Response Error Codes....................................54 208 7.5 iSNS Multicast Message Authentication.........................55 209 7.6 Registration and Query Messages...............................56 210 7.6.1 Source Attribute..............................................57 211 7.6.2 Key Attributes................................................57 212 7.6.3 Delimiter Attribute...........................................58 213 7.6.4 Operating Attributes..........................................58 214 7.6.5 Registration and Query Message Types..........................58 215 7.7 Response Messages.............................................69 216 7.7.1 Error Code....................................................69 217 7.7.2 Key Attributes in Response....................................69 218 7.7.3 Delimiter Attribute in Response...............................70 219 7.7.4 Operating Attributes in Response..............................70 220 7.7.5 Registration and Query Message Types..........................70 221 7.8 Vendor Specific Messages......................................74 222 8. Security Considerations.......................................74 223 8.1 iSNS Security Threat Analysis.................................74 224 8.2 iSNS Security Implementation and Usage Requirements...........74 225 8.3 Using iSNS to Discover Security Requirements of Peer Devices..76 226 8.4 Using iSNS to Configure Security Policies of Client Devices...76 227 8.5 Resource Issues...............................................77 228 8.6 iSNS Interaction with IKE and IPSec...........................77 229 9. Normative References..........................................78 230 Internet Storage Name Service (iSNS) February 2002 232 10. Informative References........................................79 233 11. Author's Addresses............................................80 234 Full Copyright Statement.............................................81 235 Appendix A -- iSNS Examples..........................................82 236 A.1 iSCSI Initialization Example..................................82 237 A.1.1 Simple iSCSI Target Registration..............................82 238 A.1.2 Target Registration and DD Configuration......................83 239 A.1.3 Initiator Registration and Target Discovery...................84 240 Internet Storage Name Service (iSNS) February 2002 242 1. Abstract 244 This document specifies the iSNS protocol, which is used for 245 interaction between iSNS servers and iSNS clients in order to 246 facilitate automated discovery, management, and configuration of 247 iSCSI and Fibre Channel (FCP) devices on a TCP/IP network. iSNS 248 provides intelligent storage discovery and management services 249 comparable to those found in Fibre Channel networks, allowing a 250 commodity IP network to function in a similar capacity as a storage 251 area network. iSNS also facilitates a seamless integration of IP 252 and Fibre Channel networks, due to its ability to emulate Fibre 253 Channel fabric services, and manage both iSCSI and Fibre Channel 254 devices. iSNS thereby provides value in any storage network 255 comprised of iSCSI devices, Fibre Channel devices, or any 256 combination thereof. 258 2. About this Document 260 2.1 Conventions Used in this Document 262 iSNS refers to the framework consisting of the storage network model 263 and associated services. 265 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 266 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 267 this document are to be interpreted as described in [RFC2119]. 269 All frame formats are in big endian network byte order. 271 All unused fields and bitmaps, including those that are RESERVED, 272 SHOULD be set to zero. 274 2.2 Purpose of this Document 276 This is a standards track document containing normative text 277 specifying the iSNS Protocol, used by iSCSI and iFCP devices to 278 communicate with the iSNS server. This document focuses on the 279 interaction between iSNS servers and iSNS clients; interactions 280 among multiple authoritative primary iSNS servers are a potential 281 topic for future work. 283 3. iSNS Overview 285 iSNS facilitates scalable configuration and management of iSCSI and 286 Fibre Channel (FCP) storage devices in an IP network, by providing a 287 set of services comparable to that available in Fibre Channel 288 networks. iSNS thus allows a commodity IP network to function at 289 comparable level of intelligence to a Fibre Channel fabric. iSNS 290 allows the administrator to go beyond a simple device-by-device 291 management model, where each storage device is manually and 292 individually configured with its own list of known initiators and 293 targets. Using the iSNS, each storage device subordinates its 294 discovery and management responsibilities to the iSNS server. The 295 Internet Storage Name Service (iSNS) February 2002 297 iSNS server thereby serves as the consolidated management contact 298 through which administrator workstations can configure and manage 299 the entire storage network, including both iSCSI and Fibre Channel 300 devices. 302 iSNS can be implemented to support iSCSI and/or iFCP protocols as 303 needed; an iSNS implementation MAY provide support for one or both 304 of these protocols as desired by the implementer. Implementation 305 requirements within each of these protocols is further discussed in 306 section 5. Use of iSNS is OPTIONAL for iSCSI, and REQUIRED for 307 iFCP. 309 3.1 iSNS Architectural Components 311 3.1.1 iSNS Protocol (iSNSP) 313 The iSNS Protocol (iSNSP) is a flexible and lightweight protocol 314 that specifies how iSNS clients and servers communicate. It is 315 suitable for various platforms, including switches and targets as 316 well as server hosts. 318 3.1.2 iSNS Client 320 iSNS clients initiate transactions with iSNS servers using the 321 iSNSP. iSNS clients are applications that are co-resident in the 322 storage device, and can register device�s attribute information, 323 download information about other registered clients in a common 324 Discovery Domain (DD), and receive asynchronous notification of 325 topology events that occur in their DD(s). Management stations are a 326 special type of iSNS client that have access to all DDs stored in 327 the iSNS. 329 3.1.3 iSNS Server 331 iSNS servers respond to iSNS protocol queries and requests, and 332 initiate iSNS protocol State Change Notifications. Properly 333 authenticated information submitted by a registration request is 334 stored in an iSNS database. 336 3.1.4 iSNS Database 338 The iSNS database is the information repository for the iSNS 339 server(s). It maintains information about iSNS client attributes. 340 A directory-enabled implementation of iSNS may store client 341 attributes in an LDAP directory infrastructure. 343 3.1.5 iSCSI 345 iSCSI (Internet SCSI) is an encapsulation of SCSI for a new 346 generation of storage devices interconnected with TCP/IP. 348 Internet Storage Name Service (iSNS) February 2002 350 3.1.6 iFCP 352 iFCP (Internet FCP) is a gateway-to-gateway protocol designed to 353 interconnect existing Fibre Channel and SCSI devices using TCP/IP. 354 iFCP maps the existing FCP standard and associated Fibre Channel 355 services to TCP/IP. 357 3.2 iSNS Functional Overview 359 iSNS Protocol registration and query messages are sent by iSNS 360 clients to servers, while notification messages are sent by iSNS 361 servers to iSNS clients. Messages originating at the client are 362 sent to the iSNS server at the well-known iSNS TCP or UDP port 363 number. 365 There are four main functions of the iSNS: 367 1) A Name Service Providing Storage Resource Discovery 369 2) Discovery Domain (DD) and Login Control Service 371 3) State Change Notification Service 373 4) Open Mapping of Fibre Channel and iSCSI Devices 375 3.2.1 Name Registration Service 377 The iSNS provides a registration function to allow all entities in a 378 storage network to register and query the iSNS database. Both 379 targets and initiators can register in the iSNS database, as well as 380 query for information about other initiators and targets. This 381 allows, for example, a client initiator to obtain information about 382 target devices from the iSNS server. This service is modeled on the 383 Fibre Channel Generic Services Name Server described in FC-GS-3, 384 with extensions, operating within the context of an IP network. 386 The naming registration service also provides the ability to obtain 387 a network unique Domain ID for iFCP gateways when required. 389 3.2.2 Discovery Domain and Login Control Service (Zoning) 391 Zoning is an important function in existing Storage Area Networks 392 that allows storage administrators to partition storage assets into 393 more manageable groups for administrative and management purposes. 394 It also provides important storage network isolation capabilities to 395 prevent interaction among incompatible storage and file systems. 396 iSNS provides zoning capability through the Discovery Domain (DD) 397 Service. 399 The Discovery Domain (DD) Service facilitates the partitioning of 400 iSNS client devices into more manageable groupings for 401 administrative and login control purposes. This allows the 402 administrator to limit the login process to the more appropriate 403 subset of targets registered in the iSNS. iSNS clients must be in 404 Internet Storage Name Service (iSNS) February 2002 406 at least one common DD in order to obtain information about each 407 other. iSNS clients can be a member of multiple DD's 408 simultaneously. 410 The DD information stored in the iSNS can be used by various 411 enforcement points in the network to configure security and access 412 control policy. For example, a DD-aware switch can block storage 413 initiators from accessing targets that are not in the same DD, even 414 if the initiator somehow obtained address information for a target 415 outside of its DD. 417 Login Control allows targets to subordinate their access 418 control/authorization policy to the iSNS server. The target node or 419 device downloads the list of authorized initiators from the iSNS. 420 Each node or device is uniquely identified by an iSCSI Name or FC 421 Port Name. Only initiators that match the required identification 422 and authentication information provided by the iSNS will be allowed 423 access by that target node or device during session establishment. 424 If spoofing of initiator identities is a concern, the target may use 425 the public key certificate of the authorized initiator, obtained 426 from the iSNS server, to authenticate the initiator. 428 DD's can be managed offline through a separate management 429 workstation using the iSNSP or SNMP. If the target opts to use the 430 Login Control feature of the iSNS, the target subordinates 431 management of access control policy (i.e., the list of initiators 432 allowed to login to that target) to the management workstations that 433 are manipulating information in the iSNS database. 435 If administratively authorized, a target can upload its own Login 436 Control list. This is accomplished using the DDReg message and 437 listing the iSCSI Name of each initiator to be registered in the 438 Target's DD. 440 Depending on the implementation, newly registered devices that have 441 not explicitly been placed into a DD by the management station MAY 442 be placed into a "default DD" where they are visible to other 443 devices in that DD. Other implementations MAY decide that they are 444 registered with no DD, making them inaccessible to source-scoped 445 iSNSP messages. 447 The iSNS server uses the SOURCE field of each iSNSP message to 448 determine the source of the request and scope the operation to the 449 set of Discovery Domains that the iSNS client is a member of. In 450 addition, the Node Type (specified in the iFCP or iSCSI Node Type 451 bitmap field) may also be used to determine authorization for the 452 specified iSNS operation. For example, only CONTROL nodes are 453 authorized to create or delete discovery domains. 455 Valid and active Discovery Domains (DD's) belong to at least one 456 active Discovery Domain Sets (DDS's). Discovery Domains that do not 457 belong to an activated DDS are not enabled. 459 Internet Storage Name Service (iSNS) February 2002 461 3.2.3 State Change Notification Service 463 The State Change Notification (SCN) service allows the iSNS to issue 464 notifications about network events that affect the operational state 465 of iSNS clients. The iSNS client has the ability to register for 466 these notifications of events detected by the iSNS. The types of 467 events for which SCNs can be sent include change in Discovery Domain 468 (DD) membership and device registration updates. 470 The State Change Notification service utilizes the Discovery Domain 471 Service to control the distribution of notification messages. 472 Notifications about changes within a DD are limited to members of 473 that DD. 475 If the iSNS is unable to service an SCN registration it SHALL reject 476 the SCN registration request, returning a SCN Registration Rejected 477 error code. The rejection might occur in situations where the 478 network size, or current level of SCN registrations, has passed an 479 implementation-specific threshold. A client not allowed to register 480 for SCNs may monitor its sessions with other storage devices 481 directly. 483 The specific notification mechanism by which the iSNS learns of the 484 events is implementation-specific, but can include examples such as 485 explicit notification messages from an iSNS client to the iSNS 486 server, or a hardware interrupt to a switch-hosted iSNS as a result 487 of link failure. 489 3.2.4 Open Mapping Between Fibre Channel and iSCSI Devices 491 The iSNS database stores naming and discovery information about both 492 Fibre Channel and iSCSI devices. This allows the iSNS to store 493 mappings of a Fibre Channel device to a proxy iSCSI device "image" 494 in the IP network. Similarly, mappings of an iSCSI device to a 495 "proxy WWN" can be stored under the WWN Token field for that that 496 iSCSI device. 498 Furthermore, through use of iSCSI-FC gateways, Fibre Channel-aware 499 management stations can interact with the iSNS server to retrieve 500 information about Fibre Channel devices, and use this information to 501 manage Fibre Channel devices as well as iSCSI devices. This allows 502 management functions such as Discovery Domains and State Change 503 Notifications to be seamlessly applied for both iSCSI and Fibre 504 Channel devices, facilitating integration of IP networks with Fibre 505 Channel devices and fabrics. 507 Note that Fibre Channel attributes are stored as iFCP attributes, 508 and the ability to store this information in the iSNS server is 509 useful even if the iFCP protocol is not implemented. In particular, 510 tag 101 can be used to store a "Proxy iSCSI Name" for Fibre Channel 511 devices registered in the iSNS. This field is used to associate the 512 FC device with an iSCSI registration entry that is used for the 513 Fibre Channel device to communicate with iSCSI devices in the IP 514 network. Conversely, tag 37 contains an WWN Token field, which can 515 Internet Storage Name Service (iSNS) February 2002 517 be used to store an FC Node Name (WWNN) value used by iSCSI-FC 518 gateways to represent an iSCSI device in the Fibre Channel domain. 520 By storing the mapping between Fibre Channel and iSCSI devices in 521 the iSNS, this information becomes open to any iSNS client wishing 522 to retrieve and use this information. In many cases, this provides 523 advantages over storing this information internally within an iSCSI- 524 FC gateway, where the mapping is inaccessible to other devices 525 except by proprietary mechanisms. 527 3.3 iSNS and Domain Name System (DNS) 529 A directory-enabled iSNS implementation may use LDAP to store iSNS 530 database records. If this is the case, then LDAP can be used to 531 support both the iSNS and DNS server infrastructures, in order to 532 maintaining consistency in Domain Name-to-IP address mappings used 533 by DNS and iSNS. 535 A detailed description of the Domain Name System (DNS) protocol is 536 found in [RFC 1035], and is beyond the scope of this document. If a 537 common LDAP information base is used to support both DNS and iSNS 538 servers, then Domain-Name-to-IP address mappings for storage devices 539 can be obtained from either DNS servers or the iSNS. 541 3.4 iSNS and LDAP 543 LDAP is a generic protocol to access directory services through the 544 network. It is a passive service designed to deliver scalable 545 directory services using a get/set model. Applications designed and 546 tailored to specific user requirements interact with LDAP for their 547 generic directory service needs. On the other hand, iSNS is an 548 application that goes beyond the simple get/set model, and provides 549 specific capabilities needed to monitor and manage an enterprise- 550 scale storage network. iSNS is one example of an application that 551 can leverage the services of LDAP. By layering iSNS on top of LDAP, 552 the capabilities of both iSNS and LDAP can be leveraged to manage 553 and scale the enterprise IP storage network. 555 The iSNS application provides capabilities that LDAP alone is not 556 designed to achieve. This includes the following: 558 1) Client Attribute Awareness - The iSNS server application 559 interprets attribute values submitted by clients in registration 560 messages, and can take appropriate action based upon specific 561 registered attribute values. The iSNS server is conscious of 562 the state of each client. 564 2) State Change Notification - An iSNS server may initiate 565 notification messages to clients in the event of a change in the 566 network, such as the non-availability or non-reachability of a 567 storage device, or a specific change of a client attribute. 569 Internet Storage Name Service (iSNS) February 2002 571 3) Monitoring of Clients - iSNS provides an Entity Status Inquiry 572 message to verify the availability and reachability of storage 573 devices. 575 4) Lightweight - iSNSP is a simple and lightweight protocol 576 suitable for implementation on embedded devices such as switches 577 and targets. There are no unused or "wasted" features that may 578 bog down the performance of the host device. 580 LDAP provides important capabilities that can be used to increase 581 the scalability of iSNS services. For example, LDAP provides 582 database replication capabilities (LDUP), which can be used to 583 support iSNS deployments with multiple iSNS servers. 585 3.5 iSNS Server Discovery 587 3.5.1 Service Location Protocol (SLP) 589 The Service Location Protocol (SLP) provides a flexible and scalable 590 framework for providing hosts with access to information about the 591 existence, location, and configuration of networked services, 592 including the iSNS server. SLP can be used by iSNS clients to 593 discover the IP address or FQDN of the iSNS server. To implement 594 discovery through SLP, a Service Agent (SA) should be cohosted in 595 the iSNS server, and a User Agent (UA) should be in each iSNS 596 client. Each client multicasts a discovery message requesting the IP 597 address of the iSNS server(s). The SA responds to this request. 598 Optionally, the location of the iSNS can be stored in the SLP 599 Directory Agent (DA). 601 Note that a complete description and specification of SLP can be 602 found in [RFC2608], and is beyond the scope of this document. 603 Additional details on use of SLP to discover iSNS can be found in 604 [iSCSI-SLP]. 606 3.5.2 Dynamic Host Configuration Protocol (DHCP) 608 The IP address of the iSNS server can be stored in a DHCP server to 609 be downloaded by iSNS clients using a DHCP option. The DHCP option 610 number to be used for distributing the iSNS server location is 611 <>. 613 3.5.3 iSNS Heartbeat Message 615 The iSNS heartbeat message is described in section 7.6.5.14. It 616 allows iSNS clients within the broadcast or multicast domain of the 617 iSNS server to discover the location of the active iSNS server and 618 any backup servers. 620 3.6 iSNS and NAT 622 The existence of NAT will have an impact upon information retrieved 623 from the iSNS. If the iSNS client exists in a different addressing 624 domain than the iSNS server, then IP address information stored in 625 Internet Storage Name Service (iSNS) February 2002 627 the iSNS server may not be correct when interpreted in the domain of 628 the iSNS client. 630 There are several possible approaches to allow operation of iSNS 631 within a NAT network. The first approach is to require use of the 632 canonical TCP port number by both targets and initiators when 633 addressing targets across a NAT boundary, and for the iSNS client to 634 not query for nominal IP addresses. Rather, the iSNS client 635 initiator queries for the DNS Fully Qualified Domain Name stored in 636 the Entity Identifier field, when seeking addressing information. 637 Once retrieved, the DNS name can be interpreted in each address 638 domain and mapped to the appropriate IP address by local DNS 639 servers. 641 A second approach is to deploy a distributed network of iSNS 642 servers. Local iSNS servers are deployed inside and outside NAT 643 boundaries, with each local server storing relevant IP addresses for 644 their respective NAT domains. Updates among the network of 645 decentralized, local iSNS servers are handled using LDAP and using 646 appropriate NAT translation rules implemented within the update 647 mechanism in each server. 649 The final alternative is to simply disallow use of NAT in 650 communication between the iSNS server and any iSNS client. 652 3.7 Transfer of iSNS Database Records between iSNS Servers 654 Transfer of iSNS database records between iSNS servers has important 655 applications, including the following: 657 1) An independent organization needs to transfer storage 658 information to a different organization. Each organization 659 independently maintains its own iSNS infrastructure. To facilitate 660 discovery of storage assets of the peer organization using IP, iSNS 661 database records can be transferred between authoritative iSNS 662 servers from each organization. This allows storage sessions to be 663 established directly between devices residing in each organization's 664 storage network infrastructure over a common IP network. 666 2) Multiple iSNS servers are desired for redundancy. Backup 667 servers need to maintain copies of the primary server's dynamically 668 changing database. 670 To support the above applications, information in an iSNS server can 671 be distributed to other iSNS servers either using the iSNS protocol, 672 or through out-of-band mechanisms using non-iSNS protocols. The 673 following examples illustrate possible methods to transfer data 674 records between iSNS servers. In the first example, a back-end LDAP 675 information base is used to support the iSNS server, and the data is 676 transferred using the LDAP protocol. Once the record transfer of 677 the remote device is completed, it becomes visible and accessible to 678 local devices using the local iSNS server. This allows local 679 devices to establish sessions with remote devices (provided firewall 680 boundaries can be negotiated). 682 Internet Storage Name Service (iSNS) February 2002 684 +-------------------------+ +-------------------------+ 685 |+------+ iSNSP | | iSNSP +-----+ | 686 ||dev A |<----->+------+ | | +------+<----->|dev C| | 687 |+------+ | | | | | | +-----+ | 688 |+------+ iSNSP |local | | | |remote| iSNSP +-----+ | 689 ||dev B |<----->| iSNS | | | | iSNS |<----->|dev D| | 690 |+------+ | | | | | | +-----+ | 691 |........ +--+---+ | WAN | +---+--+ | 692 |.dev C'. | | Link | | | 693 |........ | ============= | | 694 | | | | | | 695 | +--+---+ | | +---+--+ | 696 | | local|<--- <--- <--- <-|remote| | 697 | | LDAP | | LDAP: | | LDAP | | 698 | +------+ Xfer "dev C"| +------+ | 699 +-------------------------+ +-------------------------+ 700 Enterprise Enterprise 701 Network A Network B 703 In the above diagram, two business partners wish to share storage 704 "dev C". Using LDAP, the record for "dev C" can be transfered from 705 Network B to Network A. Once accessible to the local iSNS in 706 Network A, local devices A and B can now discover and connect to 707 "dev C". 709 +-------------------------+ +-------------------------+ 710 |+------+ iSNSP | | iSNSP +-----+ | 711 ||dev A |<----->+------+ | | +------+<----->|dev C| | 712 |+------+ | | | | | | +-----+ | 713 |+------+ iSNSP |local | | | |remote| iSNSP +-----+ | 714 ||dev B |<----->| iSNS | | | | iSNS |<----->|dev D| | 715 |+------+ | | | | | | +-----+ | 716 |........ +------+ | WAN | +---+--+ | 717 |.dev C'. ^ | Link | | | 718 |........ | ============= v | 719 | | | | |SNMP | 720 | | | | | | 721 | +--+----+ | | v | 722 | | SNMP |<--- <--- <--- <---- | 723 | | Mgmt | | SNMP: Xfer "dev C" | 724 | |Station| | | | 725 | +-------+ | | | 726 +-------------------------+ +-------------------------+ 727 Enterprise Enterprise 728 Network A Network B 730 The above diagram illustrates a second example of how iSNS records 731 can be shared. This method uses an SNMP-based management station to 732 manually download the desired record for "dev C", and then directly 733 upload it to the local iSNS. Once the record is transferred to the 734 local iSNS in Network A, "dev C" becomes visible and accessible 735 (provided firewall boundaries can be negotiated) to other devices in 736 Network A. 738 Internet Storage Name Service (iSNS) February 2002 740 Other methods, including proprietary protocols, can be used to 741 transfer device records between iSNS servers. Further discussion 742 and explanation of these methodologies is beyond the scope of this 743 document. 745 3.8 Backup iSNS Servers 747 This section offers a broad framework for implementation and 748 deployment of iSNS backup servers. Server failover and recovery are 749 topics of continuing research and adequate resolution of issues such 750 as split brain and primary server selection is dependent on the 751 specific implementation requirements and deployment needs. 752 Therefore, it is beyond the scope of this specification to 753 facilitate more than a basic interoperability among failover 754 mechanisms. Further development of redundant iSNS server mechanisms 755 are left to the individual implementation. 757 Multiple iSNS servers can be used to provide redundancy in the event 758 that the active iSNS server fails or is removed from the network. 759 The methods described in section 3.7 above can be used to transfer 760 name server records to backup iSNS servers. Each backup server 761 maintains a redundant copy of the name server database found in the 762 primary iSNS server, and can respond to iSNS protocol messages in 763 the same way as the active server. Each backup server SHOULD 764 monitor the health and status of the active iSNS server, including 765 checking to make sure its own database is synchronized with the 766 active server's database. How each backup server accomplishes this 767 is implementation-dependent, and may (or may not) include using the 768 iSNS protocol. If the iSNS protocol is used, then the backup server 769 MAY register itself in the active server's iSNS database as a 770 control node, allowing it to receive state change notifications. 772 Generally, the administrator or some automated election process is 773 responsible for initial and subsequent designation of the primary 774 server and each backup server. 776 A maximum of one backup iSNS server SHALL exist at any individual IP 777 address. 779 In addition to proprietary vendor-specific ways of deploying 780 multiple redundant iSNS servers, the iSNS heartbeat can also be used 781 to coordinate designation and selection of primary and backup iSNS 782 servers. 784 Each backup server should note its relative precedence in the active 785 server's list of backup servers. If not already known, each backup 786 server MAY learn its precedence from the iSNS heartbeat message, by 787 noting the position of its IP address in the ordered list of backup 788 server IP addresses. For example, if it is the first backup listed 789 in the heartbeat message, then its backup precedence is 1. If it is 790 the third backup server listed, then its backup precedence is 3. 792 If a backup server establishes that it has lost connectivity to the 793 active server and other backup servers of higher precedence, then it 794 Internet Storage Name Service (iSNS) February 2002 796 shall assume that it is the active server. The method of 797 determining whether connectivity has been lost is implementation- 798 specific. One possible approach is to assume that if the backup 799 server does not receive iSNS hearbeat messages for a period of time, 800 then connectivity to the active server has been lost. Alternately, 801 the backup server may establish TCP connections to the active server 802 and other backup servers, and loss of connectivity determined 803 through non-response to periodic echo messages (using iSNSP, SNMP, 804 or other protocols). 806 When a backup server becomes the active server, it shall assume all 807 active server responsibilities, including (if used) transmission of 808 the iSNS heartbeat message. If transmitting the iSNS heartbeat, the 809 backup server replaces the active Server IP Address and TCP/UDP Port 810 entries with its own IP address and TCP/UDP Port, and begins 811 incrementing the counter field from the last known value from the 812 previously-active iSNS server. However, it MUST NOT change the 813 original ordered list of backup server IP Address and TCP/UDP Port 814 entries. If the primary backup server or other higher-precedence 815 backup server returns, then the existing active server is 816 responsible for ensuring that the new active server's database is 817 up-to-date before demoting itself to its original status as backup. 819 3.9 Deployment Architecture Diagram 821 The following diagram displays examples of where and how iSNS can be 822 deployed, and of the various IP-based storage entities that it can 823 support. 825 Internet Storage Name Service (iSNS) February 2002 827 +------------+ +-----------+ +-----------+ 828 | | LDAP | Directory | LDAP | iSNS | 829 | DNS Server |<-------->| Database |<-------->| Server | 830 | | | | | | 831 +------+-----+ +-----+-----+ +-----+-----+ 832 | | | 833 | DNS | LDAP iSNSP | 834 |Queries | | 835 +------+----------------------+----------------------+---------+ 836 | | 837 | IP Network | 838 | | 839 +----+-----------+----------+---------------+------------------+ 840 | | | | 841 | | +-----+-----+ +------+-----+ 842 | | |iSCSI-/ | |iFCP / | 843 | | | FC /iSNS | |Switch/iSNS | 844 | | |Gtwy/Server| | /Server| 845 | | +----+------+ +-+-------+--+ 846 | | | | | 847 +----+----+ +----+---+ +---+----+ +----+-+ +---+----+ 848 | iSCSI | | iSCSI | | Fibre | | FC | | Fibre | 849 |Initiator| | Target | |Channel | |Device| |Channel | 850 +---------+ +--------+ |Network | +------+ |Network | 851 +--------+ +--------+ 853 4. iSNS Object Model 855 iSNS provides the framework for the registration, discovery, and 856 management of iSCSI devices and Fibre Channel-based devices (using 857 iFCP). This architecture framework provides elements needed to 858 describe various storage device objects and attributes that may 859 exist on an IP storage network. Objects defined in this 860 architecture framework include SAN, NETWORK ENTITY, PORTAL, STORAGE 861 NODE, STORAGE DEVICE DISCOVERY DOMAIN, and DISCOVERY DOMAIN SET. 862 Each of these objects are described in greater detail in the 863 following sections. 865 4.1 NETWORK ENTITY Object 867 The NETWORK ENTITY object is a container of STORAGE NODE objects and 868 PORTAL objects. It represents a logical device or gateway that is 869 accessible from the IP network. All STORAGE NODEs and PORTALs 870 contained within a single NETWORK ENTITY object operate in a 871 coordinated manner. 873 Note that it is possible for a single physical device or gateway to 874 be represented by more than one logical Network Entity in the iSNS 875 database. For example, one of the storage nodes on a physical 876 device may be accessible from only a subset of the network 877 interfaces (i.e., portals) available on that device. In this case, 878 a logical network entity (i.e., a "shadow entity") is created and 879 used to contain the portals and storage nodes that can operate 880 Internet Storage Name Service (iSNS) February 2002 882 cooperatively. No object (portals, storage nodes, etc...) can be 883 contained by more than one logical Network Entity. 885 4.2 PORTAL Object 887 The PORTAL object is an interface through which access to any 888 STORAGE NODE within the NETWORK ENTITY can be obtained. An IP 889 address and TCP/UDP Port number uniquely distinguish a PORTAL 890 object. A NETWORK ENTITY should have one or more PORTALs, each of 891 which is usable by STORAGE NODEs contained in that NETWORK ENTITY to 892 gain access to, or be accessible from, the IP network. 894 4.3 STORAGE NODE Object 896 The STORAGE NODE object is the logical endpoint of an iSCSI or iFCP 897 session. In iFCP, the session endpoint is represented by the World 898 Wide Port Name (WWPN). In iSCSI, the session endpoint is 899 represented by the iSCSI Name of the device. 901 4.4 FC DEVICE Object 903 The FC DEVICE represents the Fibre Channel end node. This object 904 contains information that may be useful in the management of the 905 Fibre Channel device. 907 4.5 DISCOVERY DOMAIN Object 909 DISCOVERY DOMAINS (DD) are a security and management mechanism used 910 to administer access and connectivity to storage devices. Discovery 911 Domains limit the discovery process to the administrator-configured 912 subset of relevant storage devices, preventing initiators from 913 inappropriately attempting login to devices that they shouldn�t have 914 access to. When queried, the iSNS server will provide information 915 only for storage entities that share at least one common DD. 916 Initiators will not be able to "see" devices with which they do not 917 have at least one common DD. 919 4.6 DISCOVERY DOMAIN SET Object 921 The DISCOVERY DOMAIN SET (DDS) is a container object for DD�s. 922 DDS�s may contain one or more DD�s. Similarly, each DD can be a 923 member of one or more DDS�s. DDS�s are a mechanism to store 924 coordinated sets of DD mappings in the iSNS. 926 4.7 iSNS Database Model 928 The following shows the various objects described above and their 929 relationship to each other. 931 Internet Storage Name Service (iSNS) February 2002 933 +--------------+ +-----------+ 934 | NETWORK |1 *| | 935 | ENTITY |----| PORTAL | 936 | | | | 937 +--------------+ +-----------+ 938 | 1 939 | 940 | 941 | * 942 +-----------+ +--------------+ +-----------+ +-----------+ 943 | FC |1 *| STORAGE |* *| DISCOVERY |* *| DISCOVERY | 944 | DEVICE |----| NODE |----| DOMAIN |----| DOMAIN | 945 | | | | | | | SET | 946 +-----------+ +--------------+ +-----------+ +-----------+ 948 * represents 0 to many possible relationships 950 5. iSNS Implementation Requirements 952 iSNS can be implemented with features to support iSCSI and/or iFCP. 953 Implementation of support for either or both of these protocols is 954 OPTIONAL. If iSNS is implemented to support a particular protocol, 955 then a minimum set of attributes and iSNSP commands is REQUIRED for 956 support of that protocol. This section details specific requirements 957 for support of each of these IP storage protocols. Implementation 958 requirements for security are described in section 1.1. 960 5.1 iSCSI Requirements 962 Use of iSNS in support of iSCSI is OPTIONAL. iSCSI devices MAY be 963 manually configured with the iSCSI Name and IP address of peer 964 devices, without the aid or intervention of iSNS. iSCSI devices 965 also may use SLP [RFC 2608] to discover peer iSCSI devices. 966 However, iSNS is useful for scaling a storage network to a larger 967 number of iSCSI devices. 969 5.1.1 Required Attributes for Support of iSCSI 971 The following attributes are available to support iSCSI. Attributes 972 indicated in the REQUIRED TO IMPLEMENT column MUST be supported by 973 an iSNS server used to support iSCSI. Attributes indicated in the 974 REQUIRED TO USE column MUST be supported by an iSCSI device that 975 elects to use the iSNS. 977 Internet Storage Name Service (iSNS) February 2002 979 REQUIRED REQUIRED 980 Object Attribute to Implement to Use 981 ------ --------- ------------ -------- 982 NETWORK ENTITY Entity Identifier * * 983 Entity Protocol * * 984 Management IP Address 985 Timestamp * 986 Protocol Version Range * 987 Registration Period * 988 Entity Index * 989 Entity IKE Phase-1 Proposal 990 Entity Certificate 992 PORTAL IP Address * * 993 TCP/UDP Port * * 994 Portal Symbolic Name * 995 ESI Interval * 996 ESI Port * 997 Portal Group * 998 Portal Index * 999 SCN Port * 1000 Portal Security Bitmap * 1001 Portal IKE Phase-1 Proposal 1002 Portal IKE Phase-2 Proposal 1003 Portal Certificate 1005 STORAGE NODE iSCSI Name * * 1006 iSCSI Node Type * * 1007 Alias * 1008 iSCSI SCN Bitmap * 1009 iSCSI Node Index * 1010 WWN Token 1011 iSCSI AuthMethod 1012 iSCSI Node Certificate 1014 DISCOVERY DOMAIN DD_ID * * 1015 DD_Symbolic Name * 1016 DD iSCSI Node Index * 1017 DD iSCSI Node Member * 1018 DD Features * 1020 DISCOVERY DOMAIN DDS Identifier * 1021 SET DDS Symbolic Name * 1022 Status * 1024 All iSCSI user-specified and vendor-specified attributes are 1025 optional to implement and use. 1027 5.1.2 Example iSCSI Object Model Diagrams 1029 The following diagram models how a simple iSCSI-based initiator and 1030 target is represented using database objects stored in the iSNS. In 1031 Internet Storage Name Service (iSNS) February 2002 1033 this implementation, each target and initiator is attached to a 1034 single PORTAL. 1036 +----------------------------------------------------------------+ 1037 | IP Network | 1038 +------------+--------------------------------------+------------+ 1039 | | 1040 | | 1041 +-----+------+------+-----+ +-----+------+------+-----+ 1042 | | PORTAL | | | | PORTAL | | 1043 | | -IP Addr 1 | | | | -IP Addr 2 | | 1044 | | -TCP Port 1 | | | | -TCP Port 2 | | 1045 | +-----+ +-----+ | | +-----+ +-----+ | 1046 | | | | | | | | 1047 | | | | | | | | 1048 | +--------+ +--------+ | | +-------+ +--------+ | 1049 | | | | | | | | 1050 | | STORAGE NODE | | | | STORAGE NODE | | 1051 | | -iSCSI Name | | | | -iSCSI Name | | 1052 | | -Alias: "server1"| | | | -Alias: "disk1"| | 1053 | | -Type: initiator | | | | -Type: target | | 1054 | | | | | | | | 1055 | +-------------------+ | | +------------------+ | 1056 | | | | 1057 | NETWORK ENTITY | | NETWORK ENTITY | 1058 | -Entity ID (FQDN): | | -Entity ID (FQDN): | 1059 | "strg1.foo.com" | | "strg2.bar.com" | 1060 | -Protocol: iSCSI | | -Protocol: iSCSI | 1061 | | | | 1062 +-------------------------+ +-------------------------+ 1064 The object model can be expanded to describe more complex devices, 1065 such as an iSCSI device with more than one storage controller, each 1066 controller accessible through any of multiple PORTAL interfaces. 1067 The storage controllers on this device can be accessed through 1068 alternate PORTAL interfaces, if any original interface should fail. 1069 The following diagram describes such a device: 1071 Internet Storage Name Service (iSNS) February 2002 1073 +---------------------------------------------------------------+ 1074 | IP Network | 1075 +-------------------+-----------------------+-------------------+ 1076 | | 1077 | | 1078 +------------+------+------+---------+------+------+------------+ 1079 | | PORTAL | | PORTAL | | 1080 | | -IP Addr 1 | | -IP Addr 2 | | 1081 | | -TCP Port 1 | | -TCP Port 2 | | 1082 | +-----+ +-----+ +-----+ +-----+ | 1083 | | | | | | 1084 | +---------------+ +---------------------+ +---------------+ | 1085 | +-------+ +----------------+ +-------------------+ +------+ | 1086 | | | | | | | | 1087 | +-------+ +-------+ +------+ +--------+ +--------+ +------+ | 1088 | | | | | | | | 1089 | | STORAGE NODE | | STORAGE NODE | | STORAGE NODE | | 1090 | | -iSCSI Name 1 | | -iSCSI Name 2 | | -iSCSI Name 3 | | 1091 | | -Alias: "disk1"| | -Alias: "disk2"| | -Alias: "disk3"| | 1092 | | -Type: target | | -Type: target | | -Type: target | | 1093 | | | | | | | | 1094 | +-----------------+ +-----------------+ +-----------------+ | 1095 | | 1096 | NETWORK ENTITY | 1097 | -Entity ID (FQDN): "dev1.foo.com" | 1098 | -Protocol: iSCSI | 1099 | | 1100 +---------------------------------------------------------------+ 1102 5.1.3 Required Commands and Response Messages for Support of iSCSI 1104 The following are iSNSP messages and responses are available in 1105 support of iSCSI. Messages indicated in the REQUIRED TO IMPLEMENT 1106 column MUST be implemented in iSNS servers used for iSCSI devices. 1107 Messages indicated in the REQUIRED TO USE column must be implemented 1108 in iSCSI devices that elect to use the iSNS. 1110 REQUIRED TO: 1111 Message Description Abbreviation Func ID Implement Use 1112 ------------------- ------------ ------- --------- --- 1113 Register Dev Attr Req RegDevAttr 0x0001 * * 1114 Dev Attr Query Request DevAttrQry 0x0002 * * 1115 Dev Get Next Request DevGetNext 0x0003 * 1116 Deregister Dev Request DeregDev 0x0004 * * 1117 SCN Register Request SCNReg 0x0005 * 1118 SCN Deregister Request SCNDereg 0x0006 * 1119 SCN Event SCNEvent 0x0007 * 1120 State Change Notification SCN 0x0008 * 1121 DD Register DDReg 0x0009 * * 1122 DD Deregister DDDereg 0x000A * * 1123 DDS Register DDSReg 0x000B * * 1124 DDS Deregister DDSDereg 0x000C * * 1125 Entity Status Inquiry ESI 0x000D * 1126 Internet Storage Name Service (iSNS) February 2002 1128 Name Service Heartbeat Heartbeat 0x000E 1129 NOT USED 0x000F-0x0013 1130 RESERVED 0x0014-0x00FF 1131 Vendor Specific 0x0100-0x01FF 1132 RESERVED 0x0200-0x8000 1134 The following are iSNSP response messages used in support of iSCSI: 1136 REQUIRED TO: 1137 Response Message Desc Abbreviation Func_ID Implement Use 1138 --------------------- ------------ ------- --------- --- 1139 Register Dev Attr Rsp RegDevRsp 0x8001 * * 1140 Dev Attr Query Rsp DevAttrQryRsp 0x8002 * * 1141 Dev Get Next Rsp DevGetNextRsp 0x8003 * 1142 Deregister Dev Rsp DeregDevRsp 0x8004 * * 1143 SCN Register Rsp SCNRegRsp 0x8005 * 1144 SCN Deregister Rsp SCNDeregRsp 0x8006 * 1145 SCN Event Rsp SCNEventRsp 0x8007 * 1146 SCN Response SCNRsp 0x8008 * 1147 DD Register Rsp DDRegRsp 0x8009 * * 1148 DD Deregister Rsp DDDeregRsp 0x800A * * 1149 DDS Register Rsp DDSRegRsp 0x800B * * 1150 DDS Deregister Rsp DDSDeregRsp 0x800C * * 1151 Entity Stat Inquiry Rsp ESIRsp 0x800D * 1152 NOT USED 0x800E-0x8013 1153 RESERVED 0x8014-0x80FF 1154 Vendor Specific 0x8100-0x81FF 1155 RESERVED 0x8200-0xFFFF 1157 5.2 iFCP Requirements 1159 In iFCP, use of iSNS is REQUIRED. No alternatives exist for support 1160 of iFCP Naming & Discovery functions. 1162 5.2.1 Required Attributes for Support of iFCP 1164 The following table displays attributes that are used by iSNS to 1165 support iFCP. Attributes indicated in the REQUIRED TO IMPLEMENT 1166 column MUST be supported by the iSNS server that supports iFCP. 1167 Attributes indicated in the REQUIRED TO USE column MUST be supported 1168 by iFCP gateways. 1170 REQUIRED REQUIRED 1171 Object Attribute to Implement to Use 1172 ------ --------- ------------ -------- 1173 NETWORK ENTITY Entity Identifier * * 1174 Entity Protocol * * 1175 Management IP Address 1176 Timestamp * 1177 Protocol Version Range * 1178 Registration period 1179 Entity Index 1181 Internet Storage Name Service (iSNS) February 2002 1183 Entity IKE Phase-1 Proposal 1184 Entity Certificate 1186 PORTAL IP Address * * 1187 TCP/UDP Port * * 1188 Symbolic Name * 1189 ESI Interval * 1190 ESI Port * 1191 Portal IKE Phase-1 Proposal 1192 Portal IKE Phase-2 Proposal 1193 Portal Certificate 1194 Security Bitmap * 1196 STORAGE NODE Port Name (WWPN) * * 1197 Port_ID * * 1198 Port Type * * 1199 Port Symbolic Name * 1200 Fabric Port Name (FWWN) * 1201 Hard Address * 1202 Port IP Address * 1203 Class of Service * 1204 FC FC-4 Types * 1205 FC FC-4 Descriptors * 1206 FC FC-4 Features * 1207 SCN Bitmap * 1208 Port Certificate 1210 FC DEVICE Node Name (WWNN) * * 1211 Node Symbolic Name * 1212 Node IP Address * 1213 Node IPA * 1214 Node Certificate 1215 Proxy iSCSI Name 1217 DISCOVERY DOMAIN DD_ID * * 1218 DD_Symbolic Name * 1219 DD iFCP Member (WWPN) * 1221 DISCOVERY DOMAIN DDS Identifier * 1222 SET DDS Symbolic Name * 1223 DDS Status * 1225 OTHER Switch Name 1226 Preferred_ID 1227 Assigned_ID 1228 Space Identifier 1230 5.2.2 Example iFCP Object Model Diagram 1232 The iFCP protocol allows native Fibre Channel devices or Fibre 1233 Channel fabrics connected to an iFCP gateway to be directly 1234 internetworked using IP. 1236 Internet Storage Name Service (iSNS) February 2002 1238 When supporting iFCP, the iSNS stores Fibre Channel device 1239 attributes, iFCP gateway attributes, and Fibre Channel fabric switch 1240 attributes that might also be stored in an FC name server. 1242 The following diagram shows a representation of a gateway supporting 1243 multiple Fibre Channel devices behind it. The two PORTAL objects 1244 represent IP interfaces on the iFCP gateway that can be used to 1245 access any of the three STORAGE NODE objects behind it. Note that 1246 the FC DEVICE object is not contained in the NETWORK ENTITY object. 1247 However, each FC DEVICE has a relationship to one or more STORAGE 1248 NODE objects. 1250 +--------------------------------------------------------+ 1251 | IP Network | 1252 +--------+-----------------+-----------------------------+ 1253 | | 1254 +-+------+------+---+------+------+----------------------+ 1255 | | PORTAL | | PORTAL | NETWORK ENTITY | 1256 | | -IP Addr 1 | | -IP Addr 2 | -Entity ID (FQDN): | 1257 | | -TCP Port 1 | | -TCP Port 2 | �gtwy1.foo.com� | 1258 | +-----+ +-----+ +-----+ +-----+ -Protocol: iFCP | 1259 | | | | | | 1260 | +-----+ +---------------+ +----------------------+ | 1261 | +-----+ +---------------+ +-------------+ +------+ | 1262 | | | | | | | | 1263 | +-----+ +-----+ +----+ +------+ +----+ +------+ | 1264 | |STORAGE NODE | |STORAGE NODE | |STORAGE NODE | | 1265 | | -WWPN 1 | | -WWPN 2 | | -WWPN 3 | | 1266 | | -Port ID 1 | | -Port ID 2 | | -Port ID 3 | | 1267 | | -FWWN 1 | | -FWWN 2 | | -FWWN 3 | | 1268 | | -FC COS | | -FC COS | | -FC COS | | 1269 | +------+------+ +-------+-----+ +----+--------+ | 1270 +--------|-------------------|------------|--------------+ 1271 | | | 1272 +------+------+ +---+------------+---+ 1273 | FC DEVICE | | FC DEVICE | 1274 | -WWNN 1 | | -WWNN 2 | 1275 | | | | 1276 +-------------+ +--------------------+ 1278 5.2.3 Required Commands and Response Messages for Support of iFCP 1280 The iSNSP messages and responses displayed in the following tables 1281 are available to support iFCP gateways. Messages indicated in the 1282 REQUIRED TO IMPLEMENT column MUST be supported by the iSNS server 1283 used by iFCP gateways. Messages indicated in the REQUIRED TO USE 1284 column MUST be supported by the iFCP gateways themselves. 1286 Internet Storage Name Service (iSNS) February 2002 1288 REQUIRED TO: 1289 Message Description Abbreviation Func ID Implement Use 1290 ------------------- ------------ ------- --------- --- 1291 Register Dev Attr Req RegDevAttr 0x0001 * * 1292 Dev Attr Query Request DevAttrQry 0x0002 * * 1293 Dev Get Next Request DevGetNext 0x0003 * 1294 Deregister Dev Request DeregDev 0x0004 * * 1295 SCN Register Request SCNReg 0x0005 * 1296 SCN Deregister Request SCNDereg 0x0006 * 1297 SCN Event SCNEvent 0x0007 * 1298 State Change Notification SCN 0x0008 * 1299 DD Register DDReg 0x0009 * * 1300 DD Deregister DDDereg 0x000A * * 1301 DDS Register DDSReg 0x000B * * 1302 DDS Deregister DDSDereg 0x000C * * 1303 Entity Status Inquiry ESI 0x000D * 1304 Name Service Heartbeat Heartbeat 0x000E * 1305 Reserved Reserved 0x000F-0x0010 1306 Request Switch ID RqstSwId 0x0011 1307 Release Switch ID RlseSwId 0x0012 1308 Get Switch IDs GetSwIds 0x0013 1309 RESERVED 0x0014-0x00FF 1310 Vendor Specific 0x0100-0x01FF 1311 RESERVED 0x0200-0x8000 1313 The following are iSNSP response messages in support of iFCP: 1315 Internet Storage Name Service (iSNS) February 2002 1317 REQUIRED TO: 1318 Response Message Desc Abbreviation Func_ID Implement Use 1319 --------------------- ------------ ------- --------- --- 1320 Register Dev Attr Rsp RegDevRsp 0x8001 * * 1321 Dev Attr Query Resp DevAttrQryRsp 0x8002 * * 1322 Dev Get Next Resp DevGetNextRsp 0x8003 * 1323 Deregister Dev Resp DeregDevRsp 0x8004 * * 1324 SCN Register Resp SCNRegRsp 0x8005 * 1325 SCN Deregister Resp SCNDeregRsp 0x8006 * 1326 SCN Event Resp SCNEventRsp 0x8007 * 1327 SCN Response SCNRsp 0x8008 * 1328 DD Register Rsp DDRegRsp 0x8009 * * 1329 DD Deregister Rsp DDDeregRsp 0x800A * * 1330 DDS Register Rsp DDSRegRsp 0x800B * * 1331 DDS Deregister Rsp DDSDeregRsp 0x800C * * 1332 Entity Stat Inquiry Resp ESIRsp 0x800D * 1333 NOT USED 0x800E 1334 RESERVED 0x800F-0x8010 1335 Request Switch ID Resp RqstSwIdRsp 0x8011 1336 Release Switch ID Resp RlseSwIdRsp 0x8012 1337 Get Switch IDs GetSwIdRsp 0x0013 1338 RESERVED 0x8014-0x80FF 1339 Vendor Specific 0x8100-0x81FF 1340 RESERVED 0x8200-0xFFFF 1342 5.3 Attribute Descriptions for Discovery Domain Registration 1344 Discovery Domains are logical groupings of initiators and targets 1345 that are used to limit the login process to the appropriate subset 1346 of devices registered in the iSNS. 1348 Support for Discovery Domains is required for all protocols. The 1349 iSNS attributes for Discovery Domain and Discovery Domain Set 1350 registration are shown in the following: 1352 Internet Storage Name Service (iSNS) February 2002 1354 DISCOVERY DOMAIN SET 1355 | 1356 - DD Set_ID 1357 - DD Set_Symbolic Name 1358 - DD Set Enabled/Disabled 1360 DD SET_MEMBER 1361 | 1362 - DD Set_ID 1363 - DD_ID 1365 DISCOVERY DOMAIN 1366 | 1367 - DD_ID 1368 - DD_Symbolic Name 1369 - DD Features 1371 DD_MEMBER 1372 | 1373 - DD_ID 1374 - iSCSI Node Index, iSCSI Name, or WWPN 1376 Membership in a Discovery Domain is established by registering one 1377 of the following attributes in that DD: 1379 - iSCSI Name or : this places the iSCSI node in the 1380 iSCSI Node Index Discovery Domain 1382 - WWPN : this places the FC Port in the 1383 Discovery Domain 1385 5.4 Use of TCP For iSNS Communication 1387 TCP can be used for any or all iSNS communication. The iSNS server 1388 MUST accept TCP connections for client registrations. The well- 1389 known TCP port used by the iSNS server to receive TCP messages used 1390 is 3205. The iSNS client MAY use one or more TCP connections to 1391 register attributes and communicate with the server. 1393 To receive ESI monitoring using TCP, the client registers the Portal 1394 ESI Interval and the port number of the TCP port that will be used 1395 to receive ESI inquiry messages. TCP-based ESI monitoring requires 1396 that an open TCP connection be maintained by the iSNS server to 1397 every iSNS client registered to receive monitoring. This TCP 1398 connection is terminated at the iSNS client at the registered ESI 1399 Port number. If the TCP connection supporting ESI monitoring is 1400 terminated, then the client must reregister for ESI messages on a 1401 new TCP connection in order to continue to receive ESI monitoring. 1403 To receive SCN notifications using TCP, the client registers the 1404 iSCSI or iFCP SCN Bitmap and the port number of the TCP port in the 1405 Portal used to receive SCN's. The TCP connection for SCN's does not 1406 necessarily need to be continuously open. 1408 Internet Storage Name Service (iSNS) February 2002 1410 It is possible for an iSNS client to use the same TCP connection for 1411 SCN, ESI, and iSNS queries. Alternately, separate connections may 1412 be used. 1414 5.5 Use of UDP For iSNS Communication 1416 The iSNS server MAY accept UDP messages for client registrations. 1417 The iSNS server MUST accept registrations from clients requesting 1418 UDP-based ESI and SCN messages. The well-known UDP port used to 1419 receive UDP messages is 3205. 1421 To receive UDP-based ESI monitoring messages, the client registers 1422 the port number of the UDP port in at least one Portal to be used to 1423 receive and respond to ESI messages from the iSNS server. If an 1424 entity has multiple Portals with registered ESI UDP Ports, then ESI 1425 messages SHALL be delivered to every Portal registered to receive 1426 such messages. 1428 To receive UDP-based SCN notification messages, the client registers 1429 the port number of the UDP port in at least one Portal to be used to 1430 receive SCN messages from the iSNS server. If an entity has 1431 multiple Portals with registered SCN UDP Ports, then SCN messages 1432 SHALL be delivered to each Portal registered to receive such 1433 messages. 1435 6. iSNS Message Attributes 1437 The following are attributes stored in the iSNS server, which can be 1438 retrieved using iSNS queries. Unless otherwise indicated, these 1439 attributes are supplied by iSNS clients using iSNS registration 1440 messages. 1442 6.1 iSNS Attribute Summary 1444 The following table lists all iSNSP message attributes: 1446 Internet Storage Name Service (iSNS) February 2002 1448 T Entity Attributes Length Tag Reg Key Query Key 1449 - ----------------------- ------ --- ------- ----------- 1450 Delimiter 0-256 0 N/A N/A 1451 ^ Entity Identifier (EID) 0-256 1 1|@ @|1|2|16,17|32|64 1452 & Entity Protocol 4 2 1 @|1|2|16,17|32|64 1453 Mgt IP Address 16 3 1 @|1|2|16,17|32|64 1454 = Timestamp 8 4 1 @|1|2|16,17|32|64 1455 Protocol Version Range 4 5 1 @|1|2|16,17|32|64 1456 Registration Period 4 6 1 @|1|2|16,17|32|64 1457 Entity Index 4 7 1 @|1|2|16,17|32|64 1458 Entity ISAKMP Phase-1 var 11 1 @|1|2|16,17|32|64 1459 * Entity Certificate var 12 1 @|1|2|16,17|32|64 1460 # Portal IP-Address 16 16 1 @|1|16,17|32|64 1461 $ Portal TCP/UDP Port 4 17 1 @|1|16,17|32|64 1462 Portal Symbolic Name 0-256 18 16,17 @|1|16,17|32|64 1463 ESI Interval 4 19 16,17 @|1|16,17|32|64 1464 ESI Port 4 20 16,17 @|1|16,17|32|64 1465 Portal Group 4 21 16,17 @|1|16,17|32|64 1466 Portal Index 4 22 16,17 @|1|16,17|32|64 1467 SCN Port 4 23 16,17 @|1|16,17|32|64 1468 Portal Security Bitmap 4 27 16,17 @|1|16,17|32|64 1469 * Portal ISAKMP Phase-1 var 28 16,17 @|1|16,17|32|64 1470 * Portal ISAKMP Phase-2 var 29 16,17 @|1|16,17|32|64 1471 * Portal Certificate var 31 16,17 @|1|16,17|32|64 1472 # iSCSI Name 4-256 32 1% @|1|16,17|32|33 1473 & iSCSI Node Type 4 33 32 @|1|16,17|32 1474 Alias 0-256 34 32 @|1|16,17|32 1475 iSCSI SCN Bitmap 4 35 32 @|1|16,17|32 1476 iSCSI Node Index 4 36 32 @|1|16,17|32 1477 WWN Token 8 37 32 @|1|16,17|32 1478 iSCSI AuthMethod var 42 32 @|1|16,17|32 1479 * iSCSI Node Certificate var 43 32 @|1|16,17|32 1480 # Port Name WWPN 8 64 1% @|1|16,17|64|66|96|128 1481 Port ID 4 65 64 @|1|16,17|64 1482 Port Type 4 66 64 @|1|16,17|64 1483 Symbolic Port Name 0-256 67 64 @|1|16,17|64 1484 Fabric Port Name 8 68 64 @|1|16,17|64 1485 Hard Address 4 69 64 @|1|16,17|64 1486 Port IP-Address 16 70 64 @|1|16,17|64 1487 Class of Service 4 71 64 @|1|16,17|64 1488 FC-4 Types 32 72 64 @|1|16,17|64 1489 FC-4 Descriptor 0-256 73 64 @|1|16,17|64 1490 FC-4 Features 128 74 64 @|1|16,17|64 1491 iFCP SCN bitmap 4 75 64 @|1|16,17|64 1492 iFCP Port Type 4 76 64 @|1|16,17|64 1493 * Port Certificate var 83 64 @|1|16,17|64 1494 FC-4 Type Code 4 95 Query Key only 1495 # Node Name WWNN 8 96 @ @|64|96 1496 Symbolic Node Name 0-256 97 96 @|64|96 1497 Node IP-Address 16 98 96 @|64|96 1498 Node IPA 8 99 96 @|64|96 1499 * Node Certificate var 100 96 @|64|96 1500 Proxy iSCSI Name 0-256 101 96 @|64|96 1501 Switch Name 8 128 128|@ 1502 Internet Storage Name Service (iSNS) February 2002 1504 Preferred ID 4 129 128 @|128 1505 Assigned ID 4 130 128 @|128 1506 Space_Identifier 0-256 131 128 @|128 1507 RESERVED for iSNS server-specific tags in range 132-255 1508 Company OUI 4 256 1509 * Vendor-Spec iSNS Srvr var - tags in range 257-384 1510 * Vendor-Spec Entity var - tags in range 385-512 1511 * Vendor-Spec Portal var - tags in range 513-640 1512 * Vendor-Spec iSCSI Node var - tags in range 641-768 1513 * Vendor-Spec Port Name var - tags in range 769-896 1514 * Vendor-Spec Node Name var - tags in range 897-1024 1515 * Vendor-Specific DD var - tags in range 1025-1280 1516 * Vendor-Specific DDS var - tags in range 1281-1536 1517 * Other Vendor-Specific var - tags in range 1537-2048 1518 DD_Set ID 4 2049 @ 1,32,64,2049,2065 1519 DD_Set Sym Name 4-256 2050 2049 2049 1520 DD_Set Status 4 2051 2049 2049 1521 RESERVED 2052-2064 1522 + DD_ID 4 2065 @|2049 1,32,64,2049,2065 1523 DD_Symbolic Name 4-256 2066 2065 2065 1524 DD_iSCSI Node Index 4 2067 2065 2065 1525 DD_iSCSI Node Member 0-256 2068 2065 2065 1526 DD_iFCP Member (WWPN) 8 2069 2065 2065 1527 RESERVED 2070-2077 1528 DD_Features 4 2078 2065 2065 1529 RESERVED 2304-65535 1530 RESERVED All Others 1532 The following is a description of the columns used in the above 1533 table: 1535 Attribute Type (T) 1536 -------------------------------------------------------------- 1537 # : Required key for object registration. 1538 ^ : Required key for object registration, unique value is 1539 assigned by the iSNS if value not provided during initial 1540 registration. 1541 $ : Required as part of the key, and the canonical value is 1542 used if one is not registered. 1543 & : Attribute required during initial registration that is 1544 not a key. 1545 * : Optional to implement. 1546 = : Cannot be used as a query key or be explicitly registered. This 1547 value is provided by the iSNS server. 1548 @ : if no key is present then a new entry is created, or all 1549 entries of the operating attributes are returned. 1550 | : used to separate the different sets of possible keys in the 1551 table. 1552 % : If an iSCSI Name or Port Name WWPN is registered 1553 without an EID key, then an Entity will be created and an EID 1554 assigned. The assigned EID will be returned in the response 1555 as an Operating attribute. 1556 + : A DD ID is placed into a DD_Set by using the DD_Set ID 1557 as a key 1558 Internet Storage Name Service (iSNS) February 2002 1560 Length - indicates the attribute length. Variable-length 1561 identifiers are NULL character terminated (NULL is included in the 1562 length). 1564 Tag - the integer tag value used to identify the attribute. All 1565 undefined tag values are reserved. 1567 Value � a description of the data. 1569 Implementation Notes: 1570 -------------------------------------------------------------- 1572 A well-formed registration contains the key of the object to 1573 register, or no key if it is to be generated by the iSNS server. If 1574 an attribute is present as a key, then it cannot also be an 1575 operating attribute. 1577 The registration response will contain the key for each object 1578 registered, including any key values that were assigned by the iSNS 1579 as part of the registration. For example, if an entity, two portals 1580 and one Port Name was registered, then the response message key 1581 attributes section would contain the keys for each. The key 1582 attributes, returned in the response, may be in a different order 1583 than they appeared in the registration. 1585 iSNS attributes are defined below. 1587 6.2 Entity Identifier-Keyed Attributes 1589 The following attributes are stored in the iSNS using the Entity 1590 Identifier attribute as the key. 1592 6.2.1 Entity Identifier (EID) 1594 The Entity Identifier is a variable length identifier that uniquely 1595 identifies each network entity registered in the iSNS. The 1596 attribute length varies from 4 to 256 bytes, and is a unique value 1597 within the iSNS. 1599 If the iSNS client does not provide an EID during registration the 1600 iSNS shall generate one that is unique within the iSNS. If an EID 1601 is to be generated, then the EID attribute value in the registration 1602 message shall be empty (0 length). The generated EID shall be 1603 returned in the registration response. 1605 In environments where iSNS is integrated with a DNS infrastructure, 1606 the Entity Identifier may be used to store the Fully Qualified 1607 Domain Name (FQDN) of the iSCSI or iFCP device. 1609 If FQDN's are not used, the iSNS server can be used to generate 1610 EIDs. By convention, EIDs generated by the iSNS server begin with 1611 the string �iSNS:�. iSNS clients SHOULD NOT generate and register 1612 EIDs beginning with the string "iSNS:". 1614 Internet Storage Name Service (iSNS) February 2002 1616 6.2.2 Entity Protocol 1618 Entity Protocol is a required 4-byte integer attribute that 1619 indicates the protocol of registered network entity. The valid 1620 protocol types are defined as below: 1622 Type Value Entity Protocol Type 1623 ----------_ -------------------- 1624 0 Protocol Neutral 1625 1 iSCSI 1626 2 iFCP 1627 All Others RESERVED 1629 'Protocol neutral' is the standard registration for 'control nodes'. 1631 6.2.3 Management IP Address 1633 This field contains the IP Address used to manage the entity. The 1634 Management IP Address is a 16-byte field that may contain either a 1635 32-bit IPv4 or 128-bit IPv6 address. When this field contains an 1636 IPv4 value, the most significant 12 bytes are set to 0x00. If the 1637 network entity is capable of being managed and this field is not 1638 set, then in-band management is assumed. 1640 6.2.4 Entity Registration Timestamp 1642 This field indicates the time the entity registration occurred, an 1643 associated object was updated, or the time of the most recent 1644 response from a message to the entity was received, whichever is 1645 later. The time format is, in seconds, the update period since the 1646 standard base time of 00:00:00 GMT on January 1, 1970. It cannot be 1647 used as a query key or be explicitly registered. 1649 6.2.5 Protocol Version Range 1651 This field contains the minimum and maximum version of the protocol 1652 supported by the entity. The most significant two bytes contain the 1653 maximum version supported, and the least significant two bytes 1654 contain the minimum version supported. If a range is not registered 1655 then the entity is assumed to support all versions of the protocol. 1656 If the entity is protocol neutral, then this field SHALL be set to 1657 0. 1659 6.2.6 Registration Period 1661 This field indicates the maximum period, in seconds, that the entity 1662 registration will be maintained by the server without receipt of an 1663 iSNS message from the client. If the Registration Period is set to 1664 0, then the Entity SHALL NOT be deregistered due to no contact with 1665 the iSNS client. 1667 If ESI messages are not requested by an entity and the Registration 1668 Period is not set to 0, then the entity registration SHALL be 1669 removed if an iSNS Protocol message is not received from the iSNS 1670 Internet Storage Name Service (iSNS) February 2002 1672 client before the registration period has expired. Receipt of any 1673 iSNS Protocol message from the iSNS client automatically refreshes 1674 the Entity Registration Period and Entity Registration Timestamp. To 1675 prevent a registration from expiring, the iSNS client should send an 1676 iSNS Protocol message to the iSNS server at intervals shorter than 1677 the registration period. Such a message can be as simple as a query 1678 for one of its own attributes, using its associated iSCSI Name or 1679 Port Name as the SOURCE attribute. 1681 For an iSNS client that is a multi-node entity, receipt of an iSNS 1682 message from any node of that entity is sufficient to refresh the 1683 registration for all nodes of the entity. 1685 Byte 0 and 1 represents the entity registration period, in seconds. 1686 Byte 2 and 3 are reserved. 1688 If ESI support is requested as part of a portal registration, the 1689 ESI Response message received from the iSNS client by the iSNS 1690 server SHALL act as an alternative to a refresh of the entity 1691 registration. 1693 6.2.7 Entity Index 1695 The Entity Index is a 4-byte integer value that uniquely identifies 1696 each network entity registered in the iSNS. The Entity Index is 1697 assigned by the iSNS server during the initial registration of an 1698 Entity. The value MAY BE assigned using a monotonically increasing 1699 process. 1701 The Entity Index can be used to represent a registered entity in 1702 situations where the Entity Identifier is too long to be used. An 1703 example of this is when SNMP tables are used to access the contents 1704 of the iSNS server. In this case, the Entity Index may be used as 1705 the table index. 1707 6.2.8 Entity ISAKMP Phase-1 Proposals 1709 This field contains the IKE Phase-1 proposal listing in decreasing 1710 order of preference of the protection suites acceptable to protect 1711 all IKE Phase-2 messages sent and received by the Entity. This 1712 includes Phase-2 SA's from the iSNS client to the iSNS server as 1713 well as to peer iFCP and/or iSCSI devices. This attribute contains 1714 the SA payload, proposal payload(s), and transform payload(s) in the 1715 ISAKMP format defined in [RFC2408]. 1717 This field should be used if the implementer wishes to define a 1718 single phase-1 SA security configuration used to protect all phase-2 1719 IKE traffic. If the implementer desires to have a different phase-1 1720 SA security configuration to protect each Portal interface, then the 1721 Portal Phase-1 Proposal (section 6.3.10) should be used. 1723 Internet Storage Name Service (iSNS) February 2002 1725 6.2.9 Entity Certificate 1727 This attribute contains one or more X.509 certificate that are bound 1728 to the NETWORK ENTITY of the iSNS client. This certificate is 1729 uploaded and registered to the iSNS by clients wishing to allow 1730 other clients to authenticate themselves and access the services 1731 offered by that NETWORK ENTITY. 1733 6.3 Portal-Keyed Attributes 1735 The following portal attributes are registered in the iSNS using the 1736 combined Portal IP-Address and Portal TCP/UDP Port as the key. Each 1737 portal is associated with one Entity Identifier object key. 1739 6.3.1 Portal IP-Address 1741 This attribute is the IP address of the PORTAL through which a 1742 STORAGE NODE can transmit and receive storage data. When an IPv4 1743 value is contained in this field, the most significant 12 bytes are 1744 set to 0x00. The Portal IP Address along with the Portal TCP/UDP 1745 Port number uniquely identifies a Portal. 1747 6.3.2 Portal TCP/UDP Port 1749 The TCP/UDP port of the PORTAL through which a STORAGE NODE can 1750 transmit and receive storage data. Bit 0 to 15 represents the 1751 TCP/UDP port number. Bit 16 represents the port type. If bit 16 is 1752 set, then the port type is UDP. Otherwise it is TCP. Bits 17 to 31 1753 are reserved. 1755 If the field value is 0, then the port number is the implied 1756 canonical port number and type of the protocol indicated by the 1757 associated Entity Type. 1759 The Portal IP-Address along with the Portal TCP/UDP Port number 1760 uniquely identifies a Portal. 1762 6.3.3 Portal Symbolic Name 1764 This is a variable-length text-based value from 0 to 256 bytes. The 1765 text field contains user-readable UTF-8 text, and is terminated with 1766 at least one NULL character. The Portal Symbolic Name is a user- 1767 readable description of the Portal entry in the iSNS. 1769 6.3.4 Entity Status Inquiry Interval 1771 This field indicates the requested time, in seconds, between Entity 1772 Status Inquiry (ESI) messages sent from the iSNS to this entity 1773 portal. ESI messages can be used to verify that a Portal 1774 registration continues to be valid. To request monitoring by the 1775 iSNS server, an iSNS client registers a non-zero value for this 1776 portal attribute using a RegDevAttr message. The client must also 1777 register an ESI Port on at least one of its Portals to receive the 1778 ESI monitoring. 1780 Internet Storage Name Service (iSNS) February 2002 1782 If the iSNS server does not receive an expected response to an ESI 1783 message, it shall attempt at least three re-transmissions of the ESI 1784 message. All re-transmissions MUST be sent before twice the ESI 1785 Interval period has passed since the last ESI response was received 1786 from the client. If no response is received from any of the ESI 1787 messages, then the Portal SHALL be deregistered. If TCP was used to 1788 transport the ESI messages, then that TCP connection SHALL be 1789 closed. Note that only Portals that have registered a value in 1790 their ESI Port field can be deregistered in this way. 1792 If all Portals associated with an entity that have registered for 1793 ESI messages are deregistered due to non-response, and no 1794 registrations have been received from the client for at least two 1795 ESI Interval periods, then the entity and all associated objects 1796 (including storage nodes) SHALL be deregistered. 1798 If the iSNS server is unable to support ESI messages or the ESI 1799 Interval requested, it SHALL reject the ESI request by returning an 1800 "ESI Not Available" error code. The rejection might occur in 1801 situations where the resulting frequency of ESI messages being 1802 issued to clients would pass an implementation-specific threshold. 1804 If at any time an iSNS client that is registered for ESI messages 1805 has not received an ESI message to any of its portals as expected, 1806 then the client MAY attempt to query the iSNS server using a 1807 DevAttrQry message using its Entity_ID as the key. If the query 1808 result is the error "no such entry", then the client SHALL close all 1809 remaining TCP connections to the iSNS server and assume that it is 1810 no longer registered in the iSNS database. Such a client MAY 1811 attempt re-registration. 1813 6.3.5 ESI Port 1815 This field contains the TCP or UDP port of the iSNS client used for 1816 ESI monitoring by the iSNS server. Bit 0 to 15 represents the port 1817 number. If bit 16 is set, then the port type is UDP. Otherwise, the 1818 port is TCP. Bits 17 to 31 are reserved. 1820 The iSNS server SHALL return an error if an Entity is registered for 1821 ESI monitoring and none of the portals of that Entity has an entry 1822 for the ESI Port field. If multiple Portals have a registered ESI 1823 port, then the ESI message may be delivered to any of the indicated 1824 portals. 1826 6.3.6 Portal Group 1828 This field is used to group portals into aggregation groups. All 1829 entity portals that belong to the same Portal Group in a Network 1830 Entity can provide connections to the same STORAGE NODE. The value 1831 chosen for the Portal Group need only be unique within a given 1832 Network Entity. The same Portal Group value can represent 1833 unassociated Portal Groups in other Network Entities. This allows 1834 multiple sessions to be established to a node through multiple 1835 portals. The least significant two bytes contain the integer Portal 1836 Internet Storage Name Service (iSNS) February 2002 1838 Group value for the Portal. The most significant two bytes are 1839 reserved. 1841 6.3.7 Portal Index 1843 The Portal Index is a 4-byte integer value that uniquely identifies 1844 each portal registered in the iSNS. The Portal Index is assigned by 1845 iSNS server during the initial registration of a portal. The value 1846 MAY be assigned using a monotonically increasing process. 1848 The Portal Index can be used to represent a registered portal in 1849 situations where the Portal IP-Address and Portal TCP/UDP Port is 1850 unwieldy to use. An example of this is when SNMP tables are used to 1851 access the contents of the iSNS server. In this case, the Portal 1852 Index may be used as the Registered Portal table index. 1854 6.3.8 SCN Port 1856 This field contains the TCP or UDP port used by the iSNS client to 1857 receive SCN messages from the iSNS server. Bit 0 to 15 represents 1858 the port number. If bit 16 is set, then the port type is UDP. 1859 Otherwise, the port is TCP. Bits 17 to 31 are reserved. 1861 The iSNS server SHALL return an error if an SCN registration message 1862 is received and none of the portals of the iSNS client has an entry 1863 for the SCN Port. If multiple Portals have a registered SCN Port, 1864 then the SCN may be delivered to any of the indicated portals. 1866 6.3.9 Portal Security Bitmap 1868 This 4-byte field contains flags that indicate security attribute 1869 settings for the Portal. Bit 31 (Lsb) of this field must be 1 1870 (enabled) in order for this field to contain significant 1871 information. If Bit 31 is enabled, this signifies the iSNS server 1872 can be used to store and distribute security policies and settings 1873 for iSNS clients (i.e., iSCSI devices). 1875 Bit Field Flag Description 1876 --------- ---------------- 1877 31 1 = Bitmap VALID; 0 = INVALID 1878 30 1 = IPSec Enabled; 0 = IPSec Disabled 1879 29 1 = IKE Enabled; 0 = IKE Disabled 1880 28 1 = Main Mode Enabled; 0 = MM Disabled 1881 27 1 = Aggressive Mode Enabled; 0 = Disabled 1882 26-22 RESERVED 1883 21 1 = PFS Enabled; 0 = PFS Disabled 1884 All others reserved 1886 6.3.10 Portal ISAKMP Phase-1 Proposals 1888 This field contains the IKE Phase-1 proposal listing in decreasing 1889 order of preference of the protection suites acceptable to protect 1890 all IKE Phase-2 messages sent and received by the Portal. This 1891 includes Phase-2 SA's from the iSNS client to the iSNS server as 1892 Internet Storage Name Service (iSNS) February 2002 1894 well as to peer iFCP and/or iSCSI devices. This attribute contains 1895 the SA payload, proposal payload(s), and transform payload(s) in the 1896 ISAKMP format defined in [RFC2408]. 1898 This field should be used if the implementer wishes to define phase- 1899 1 SA security configuration on a per-interface basis, as opposed to 1900 on a per-device basis. If the implementer desires to have a single 1901 phase-1 SA security configuration to protect all phase-2 traffic 1902 regardless of the interface used, then the Entity Phase-1 Proposal 1903 (section 6.2.8) should be used. 1905 6.3.11 Portal ISAKMP Phase-2 Proposals 1907 This field contains the IKE Phase-2 proposal, in ISAKMP format 1908 [RFC2408], listing in decreasing order of preference the security 1909 proposals acceptable to protect traffic sent and received by the 1910 Portal. This field is used only if bits 0, 1 and 2 of the Security 1911 Bitmap (see 6.3.9) are enabled. This attribute contains the SA 1912 payload, proposal payload(s), and associated transform payload(s) in 1913 the ISAKMP format defined in [RFC2408]. 1915 6.3.12 Portal Certificate 1917 This attribute contains one or more X.509 certificates that is a 1918 credential of the PORTAL. This certificate is used to identify and 1919 authenticate communications to the IP address supported by the 1920 Portal. 1922 6.4 iSCSI Node-Keyed Attributes 1924 The following attributes are stored in the iSNS using the iSCSI Name 1925 attribute as the key. Each set of Node-Keyed attributes is 1926 associated with one Entity Identifier object key. 1928 Although the iSCSI Name key is associated with one Entity 1929 Identifier, it is unique across the entire iSNS. 1931 6.4.1 iSCSI Name 1933 This identifier uniquely defines an iSCSI STORAGE NODE, and is a 1934 variable-length text-based value from 0 to 256 bytes. This field is 1935 required for iSCSI STORAGE NODEs, and is provided by the iSNS 1936 client. 1938 If an iSCSI Name is registered without an EID key, then an Entity 1939 will be created and an EID assigned. The assigned EID will be 1940 returned in the registration response as an operating attribute. 1942 6.4.2 iSCSI Node Type 1944 This required 32-bit field is a bitmap indicating the type of iSCSI 1945 STORAGE NODE. The bit fields are defined below. An enabled bit 1946 indicates the node has the corresponding characteristics. 1948 Internet Storage Name Service (iSNS) February 2002 1950 Bit Field Node Type 1951 --------- --------- 1952 31 (Lsb) Target 1953 30 Initiator 1954 29 Control 1955 All Others RESERVED 1957 If the Target bit is set, then the node represents an iSCSI target. 1958 Setting of the Target bit MAY be performed by iSNS clients using the 1959 iSNSP. 1961 If the Initiator bit is set, then the node represents an iSCSI 1962 initiator. Setting of the Initiator bit MAY be performed by iSNS 1963 clients using the iSNSP. 1965 If the control bit is set, then the node represents a gateway, 1966 management station, backup iSNS server, or other device which is not 1967 an initiator or target that requires the ability to send and receive 1968 iSNSP messages, including state change notifications. Setting of 1969 the control bit is an administrative task that MUST be performed on 1970 the iSNS server; iSNS clients SHALL NOT be allowed to change this 1971 bit using the iSNSP. 1973 This field MAY be used by the iSNS server to distinguish among 1974 permissions by different iSCSI node types for accessing various iSNS 1975 functions. For example, an iSNS server implementation may be 1976 administratively configured to allow only targets to receive ESI's, 1977 or for only control nodes to have permission to add, modify, or 1978 delete discovery domains. 1980 6.4.3 iSCSI Node Alias 1982 This field is a variable-length text-based value from 0 to 256 1983 bytes. The text field contains user-readable UTF-8 text, and is 1984 terminated with at least one NULL character. The Alias is a user- 1985 readable description of the node entry in the iSNS. 1987 6.4.4 iSCSI Node SCN Bitmap 1989 This field indicates the events that the iSCSI Node is interested 1990 in. These events can cause a State Change Notification (SCN) to be 1991 generated. SCNs provide information about objects that are updated, 1992 added or removed from Discovery Domains that the source and 1993 destination are a member of. Detailed SCNs provide information 1994 about all changes to the network, and may be sent if requested and 1995 administratively allowed. Target and Self SCN's (bit 6) may be 1996 useful for iSCSI initiators. This SCN provides information only 1997 about changes to target devices, or if the iSCSI Node itself has 1998 undergone a change. Similarly, Initiator and Self SCN's (bit 7) 1999 may be useful for iSCSI targets, by providing information only about 2000 changes to initiator nodes, or the target itself. 2002 Internet Storage Name Service (iSNS) February 2002 2004 Bit Field Flag Description 2005 --------- ---------------- 2006 31 (Lsb) MEMBER ADDED (DETAILED SCN ONLY) 2007 30 MEMBER REMOVED (DETAILED SCN ONLY) 2008 29 OBJECT UPDATED 2009 28 OBJECT ADDED 2010 27 OBJECT REMOVED 2011 26 DETAILED SCN REQUESTED/SENT 2012 25 TARGET AND SELF INFORMATION ONLY 2013 24 INITIATOR AND SELF INFORMATION ONLY 2014 All others RESERVED 2016 6.4.5 iSCSI Node Index 2018 The iSCSI Node Index is a 4-byte integer value that uniquely 2019 identifies each iSCSI node registered in the iSNS. The iSCSI Node 2020 Index is assigned by the iSNS server during the initial registration 2021 of the iSCSI node. The value MAY be assigned using a monotonically 2022 increasing process. 2024 The iSCSI Node Index may be used to represent a registered node in 2025 situations where the iSCSI Name is too long to be used. An example 2026 of this is when SNMP tables are used to access the contents of the 2027 iSNS server. In this case, the iSCSI Node Index may be used as the 2028 registered iSCSI Node table index. 2030 6.4.6 WWN Token 2032 This field contains a globally unique 64-bit integer value that can 2033 be used to represent the World Wide Node Name of the iSCSI device in 2034 a Fibre Channel fabric. It is a globally unique identifier is used 2035 during the device registration process, and uses a format defined in 2036 [FC-FS]. 2038 The FC-iSCSI gateway uses the value found in this field to register 2039 the iSCSI device in the Fibre Channel name server. It is stored in 2040 the iSNS to prevent conflict when assigning "proxy" WWNN values to 2041 iSCSI initiators establishing storage sessions to devices in the FC 2042 fabric. 2044 The iSNS server SHALL provide a value for this field upon initial 2045 registration of the iSCSI node. The process by which the WWN Token 2046 is assigned by the iSNS server MUST conform to the following 2047 requirements: 2049 1. The assigned WWN Token value MUST be unique across the entire 2050 iSNS database. 2052 2. Once assigned, the iSNS server MUST persistently save the 2053 mapping between the WWN Token value and registered iSCSI Name. That 2054 is, successive re-registrations of the iSCSI node keyed by the same 2055 iSCSI Name maintains the original mapping to the associated WWN 2056 Token value in the iSNS server. Similarly, the mapping shall be 2057 persistent across iSNS server reboots. Once assigned, the mapping 2058 Internet Storage Name Service (iSNS) February 2002 2060 can only be changed if a RegDevAttr message from an authorized iSNS 2061 client explicitly provides a different WWN Token value. 2063 3. Once a WWN Token value has been assigned and mapped to an iSCSI 2064 name, that WWN Token value SHALL NOT be reused or mapped to any 2065 other iSCSI name. 2067 4. The assigned WWN Token value MUST conform to the formatting 2068 requirements of [FC-FS] for World Wide Names (WWN's). 2070 An iSNS client, such as an FC-iSCSI gateway or the iSCSI initiator, 2071 MAY overwrite the iSNS Server-supplied WWN Token value if it wishes 2072 to supply its own iSCSI-FC name mapping. This is accomplished using 2073 the RegDevAttr message with the WWN Token (tag=37) as an operating 2074 attribute. Once overwritten, the new WWN Token value MUST be stored 2075 and saved by the iSNS server, and all requirements specified above 2076 continue to apply. If an iSNS client attempts to register a value 2077 for this field that is not unique in the iSNS database or is 2078 otherwise invalid, then the registration SHALL be rejected with an 2079 error code of 3 (Invalid Registration). 2081 6.4.7 iSCSI AuthMethod 2083 This attribute contains a null-terminated string containing UTF-8 2084 text listing the iSCSI authentication methods enabled for this iSCSI 2085 Node, in order of preference. The text values used to identify 2086 iSCSI authentication methods are embedded in this string attribute 2087 and delineated by a comma. The text values are identical to those 2088 found in the main iSCSI draft [iSCSI]; additional vendor-specific 2089 text values are also possible. 2091 Text Value Description Reference 2092 ---------- ----------- --------- 2093 KB5 Kerberos V5 RFC 1510 2094 SPKM1 Simple Public Key GSS-API RFC 2025 2095 SPKM2 Simple Public Key GSS-API RFC 2025 2096 SRP Secure Remote Password RFC 2945 2097 CHAP Challenge Handshake Protocol RFC 1994 2098 none No iSCSI Authentication 2100 6.4.8 iSCSI Node Certificate 2102 This attribute contains one or more X.509 certificates that may be a 2103 credential used to authenticate the iSCSI node during iSCSI 2104 authentication. This certificate MAY be used for the SPKM Public 2105 Key authentication method. 2107 6.5 FC Port-Keyed Attributes 2109 The following attributes are registered in the iSNS using the FC 2110 Port World Wide Name (WWPN) attribute as the key. Each set of FC 2111 Port-Keyed attributes is associated with one Entity Identifier 2112 object key. 2114 Internet Storage Name Service (iSNS) February 2002 2116 Although the FC Port World Wide Name is associated with one Entity 2117 Identifier, it is also globally unique. 2119 6.5.1 Port Name (WWPN) 2121 This 64-bit identifier uniquely defines the FC Port, and is the 2122 World Wide Port Name (WWPN) of the corresponding Fibre Channel 2123 device. This globally unique identifier is used during the device 2124 registration process, and uses a value conforming to IEEE EUI-64 2125 [EUI-64]. 2127 6.5.2 Port ID 2129 Along with the IP Address, this field uniquely identifies a native 2130 Fibre Channel device port in the network, and maps one-to-one to a 2131 specific Port Name (WWPN) entry. 2133 6.5.3 Port Type 2135 Indicates the type of FC port. Encoded values for this field are 2136 listed in the following table: 2138 Type Description 2139 ---- ----------- 2140 0x0000 Unidentified/Null Entry 2141 0x0001 Fibre Channel N_Port 2142 0x0002 Fibre Channel NL_Port 2143 0x0003 Fibre Channel F/NL_Port 2144 0x0004-0080 RESERVED 2145 0x0081 Fibre Channel F_Port 2146 0x0082 Fibre Channel FL_Port 2147 0x0083 RESERVED 2148 0x0084 Fibre Channel E_Port 2149 0x0085-00FF RESERVED 2150 0xFF11 mFCP Port 2151 0xFF12 iFCP Port 2152 0xFF13-FFFF RESERVED 2154 6.5.4 Symbolic Port Name 2156 A variable-length text-based description of up to 255 bytes, that is 2157 associated with the iSNS-registered Port Name in the network. The 2158 text field contains user-readable UTF-8 text and is terminated with 2159 at least one NULL character. 2161 6.5.5 Fabric Port Name (FWWN) 2163 This 64-bit identifier uniquely defines the fabric port. If the 2164 iSNS client is attached to a Fibre Channel fabric port with a 2165 registered Port Name, then that fabric Port Name shall be indicated 2166 in this field. 2168 Internet Storage Name Service (iSNS) February 2002 2170 6.5.6 Hard Address 2172 This field is the requested hard address 24-bit NL Port Identifier, 2173 included in the iSNSP for compatibility with Fibre Channel 2174 Arbitrated Loop devices and topologies. 2176 6.5.7 Port IP Address 2178 The Fibre Channel IP address associated with the FC Port. When an 2179 IPv4 value is contained in this field, the most significant 12 bytes 2180 are set to 0x00. 2182 6.5.8 Class of Service (COS) 2184 This 32-bit bit-map field indicates the Fibre Channel COS types that 2185 are supported by the registered port. The COS values are equivalent 2186 to Fibre Channel COS values. The valid COS types, and associated 2187 bit-map, are listed in the following table: 2189 Class of Service Description Bit-Map 2190 ---------------- ----------- --------- 2191 2 Delivery Confirmation Provided bit 2 set 2192 3 Delivery Confirmation Not Provided bit 3 set 2193 RESERVED other 2195 6.5.9 FC-4 Types 2197 This 32-byte field indicates the FC-4 protocol types supported by 2198 the associated port. This field can be used to support Fibre 2199 Channel devices and is consistent with FC-GS-4. 2201 6.5.10 FC-4 Descriptor 2203 A variable-length text-based description of up to 256 bytes, that is 2204 associated with the iSNS-registered device port in the network. This 2205 field can be used to support Fibre Channel devices and is consistent 2206 with FC-GS-4. 2208 6.5.11 FC-4 Features 2210 This is a 128-byte array, 4 bits per type, for the FC-4 protocol 2211 types supported by the associated port. This field can be used to 2212 support Fibre Channel devices and is consistent with FC-GS-4. 2214 6.5.12 iFCP SCN Bitmap 2216 This field indicates the events that the iSNS client is interested 2217 in. These events can cause SCN to be generated. SCNs provide 2218 information about objects that are updated, added or removed from 2219 Discovery Domains that the source and destination are a member of. 2220 Detailed SCNs provide information about all changes to the network, 2221 and may be sent if requested and administratively allowed 2222 Internet Storage Name Service (iSNS) February 2002 2224 Bit Field Flag Description 2225 --------- ---------------- 2226 31 (Lsb) MEMBER ADDED (DETAILED SCN ONLY) 2227 30 MEMBER REMOVED (DETAILED SCN ONLY) 2228 29 OBJECT UPDATED 2229 28 OBJECT ADDED 2230 27 OBJECT REMOVED 2231 26 DETAILED SCN REQUESTED/SENT 2232 25 TARGET AND SELF INFORMATION ONLY 2233 24 INITIATOR AND SELF INFORMATION ONLY 2234 All others RESERVED 2236 6.5.13 iFCP Port Type 2238 This required 32-bit field is a bitmap indicating the type of iFCP 2239 STORAGE NODE. The bit fields are defined below. An enabled bit 2240 indicates the node has the corresponding characteristics. 2242 Bit Field Node Type 2243 --------- --------- 2244 31 (Lsb) Target 2245 30 Initiator 2246 29 Control 2247 All Others RESERVED 2249 If the 'Target' bit is set, then the port represents an FC target. 2250 Setting of the 'Target' bit MAY be performed by iSNS clients using 2251 the iSNSP. 2253 If the 'Initiator' bit is set, then the port represents an FC 2254 initiator. Setting of the 'Initiator' bit MAY be performed by iSNS 2255 clients using the iSNSP. 2257 If the 'control' bit is set, then the port represents a gateway, 2258 management station, iSNS backup server, or other device. This is 2259 usually a special device that is neither an initiator nor target, 2260 which requires the ability to send and receive iSNSP messages 2261 including state change notifications. Setting of the control bit is 2262 an administrative task that MUST be administratively configured on 2263 the iSNS server; iSNS clients SHALL NOT be allowed to change this 2264 bit using the iSNSP. 2266 This field MAY be used by the iSNS server to distinguish among 2267 permissions by different iSNS clients. For example, an iSNS server 2268 implementation may be administratively configured to allow only 2269 targets to receive ESI's, or for only control nodes to have 2270 permission to add, modify, or delete discovery domains. 2272 6.5.14 Port Certificate 2274 This attribute contains one or more X.509 certificates that is a 2275 credential of the iFCP STORAGE NODE. 2277 Internet Storage Name Service (iSNS) February 2002 2279 6.6 Node-Keyed Attributes 2281 The following attributes are registered in the iSNS using the FC 2282 Node Name (WWNN) attribute as the key. Each set of FC Node-Keyed 2283 attributes represents a single device, and can be associated with 2284 many FC Ports. 2286 The FC Node Name is unique across the entire iSNS. 2288 6.6.1 Node Name (WWNN) 2290 The FC Node Name is a 64-bit identifier that is the World Wide Node 2291 Name (WWNN) of the corresponding Fibre Channel device. This globally 2292 unique identifier is used during the device registration process, 2293 and uses a value conforming to IEEE EUI-64 [EUI-64]. 2295 6.6.2 Symbolic Node Name 2297 A variable-length text-based description of up to 256 bytes, that is 2298 associated with the iSNS-registered FC Device in the network. The 2299 text field contains user-readable UTF-8 text and is terminated with 2300 at least one NULL character. 2302 6.6.3 Node IP Address 2304 This IP address is associated with the device node in the network. 2305 This field is included for compatibility with Fibre Channel. When 2306 an IPv4 value is contained in this field, the most significant 12 2307 bytes are set to 0x00. 2309 6.6.4 Node IPA 2311 This field is the 8 byte Fibre Channel Initial Process Associator 2312 (IPA) associated with the device node in the network. The initial 2313 process associator can be used for communication between Fibre 2314 Channel devices. 2316 6.6.5 Node Certificate 2318 This attribute contains an X.509 certificate that is bound to the FC 2319 Node of the iSNS client. 2321 6.6.6 Proxy iSCSI Name 2323 This field contains the iSCSI Name used to represent the FC Node in 2324 the IP network. It is used as a pointer to the matching iSCSI Name 2325 entry in the iSNS server. Its value is usually registered by an FC- 2326 iSCSI gateway connecting the IP network to the fabric containing the 2327 FC device. 2329 Note that if this field is used, there SHOULD be a matching entry in 2330 the iSNS database for the iSCSI device specified by the iSCSI name. 2331 The database entry should include the full range of iSCSI attributes 2332 Internet Storage Name Service (iSNS) February 2002 2334 needed for discovery and management of the "iSCSI proxy image" of 2335 the FC device. 2337 6.7 Other Attributes 2339 The following are not attributes of the previously-defined objects. 2341 6.7.1 FC-4 Type Code 2343 This is a 4-byte field, and is used to provide a FC-4 type during a 2344 FC-4 Type query. The FC-4 types are consistent with the FC-4 Types 2345 as defined in FC-PH. Byte 0 contains the FC-4 type. All other 2346 bytes are reserved. 2348 6.7.2 iFCP Switch Name 2350 The iFCP Switch Name is a 64-bit World Wide Name (WWN) identifier 2351 that uniquely identifies the iFCP switch in the network. This 2352 globally unique identifier is used during the switch registration 2353 switch ID assignment process, and uses a value conforming to IEEE 2354 EUI-64 [EUI-64]. The iSNS server SHALL track the state of all 2355 Switch_ID values that have been allocated to each iFCP Switch Name. 2356 If a given iFCP Switch Name is deregistered from the iSNS database, 2357 then all Switch_ID values allocated to that iFCP Switch Name shall 2358 be returned to the unused pool of values. 2360 6.7.3 Preferred ID 2362 This is a 4-byte unsigned integer field, and is the requested value 2363 that the iSNS client wishes to use for the SWITCH_ID. The iSNS 2364 server SHALL grant the iSNS client the use of the requested value as 2365 the SWITCH_ID, if the requested value has not been already 2366 allocated. If the requested value is not available, the iSNS server 2367 SHALL return a different value that has not been allocated. 2369 6.7.4 Assigned ID 2371 This is a 4-byte unsigned integer field that is used to support iFCP 2372 Transparent Mode. When operating in iFCP Transparent Mode, the 2373 RqstSwId message SHALL be used by each iFCP gateway to reserve its 2374 own unique SWITCH_ID value from the range 1 to 239. When a Switch 2375 ID is no longer required, it SHALL be released by the iFCP gateway 2376 using the RlseSwId message. The iSNS MAY use the Entity Status 2377 Inquiry message to determine if an iFCP gateway is still present on 2378 the network. 2380 6.7.5 Space_Identifier 2382 This is a UTF-8 encoded string. The Space_Identifier string is used 2383 as a key attribute to identify a range of non-overlapping SWITCH_ID 2384 values to be allocated using RqstSwId. Each Space_Identifier string 2385 submitted by iSNS clients shall have its own range of non- 2386 overlapping SWITCH_ID values to be allocated to iSNS clients. 2388 Internet Storage Name Service (iSNS) February 2002 2390 6.8 Company OUI 2392 This attribute is the OUI (Organizationally Unique Identifier) 2393 identifying the specific vendor implementing the iSNS. It is used 2394 to identify the original creator of a vendor-specific iSNSP message. 2396 6.9 Discovery Domain Registration Attributes 2398 iSNS STORAGE NODE objects can be placed into Discovery Domains. 2399 Only objects that share the same enabled Discovery Domain can query 2400 for information about each other. Discovery Domains can overlap, so 2401 an iSCSI node can be a member of many DD�s. 2403 Enabled Discovery Domains are members of one or more enabled 2404 Discovery Domain Sets (DDS). Discovery Domains that are not members 2405 of at least one enabled DDS are disabled. Therefore, Discovery 2406 Domains are not directly enabled, but rather are enabled through 2407 their association with one or more enabled Discovery Domain Sets 2408 (DDS). Discovery Domain Sets are enabled by setting bit 0 in the DDS 2409 Status field. 2411 6.9.1 DD Set ID Keyed Attributes 2413 6.9.1.1 Discovery Domain Set ID (DDS ID) 2415 The DDS ID is a unique unsigned integer identifier used in the iSNS 2416 directory database to indicate a Discovery Domain Set. A DDS is a 2417 collection of Discovery Domains that can be enabled or disabled by a 2418 management station. This value is used as a key for DDS attribute 2419 queries. When a Discovery Domain is registered it is initially not 2420 in any DDS. 2422 If the iSNS client does not provide a DDS_ID in a DDS registration 2423 request message, the iSNS shall generate a DDS_ID value that is 2424 unique within the iSNS database for that new DDS. The created DDS 2425 ID shall be returned in the response message. The DDS ID value of 0 2426 is reserved. 2428 6.9.1.2 Discovery Domain Set Symbolic Name 2430 The DDS_Symbolic Name is a UTF-8, variable-length, NULL-terminated 2431 string. This is an user-readable field used to assist a network 2432 administrator in tracking the DDS function. When registered by a 2433 client, the DDS symbolic name SHALL be verified unique by the iSNS. 2434 If the DDS symbolic name is not unique, then the DDS registration 2435 SHALL be rejected with an �Invalid Registration� error code. The 2436 invalid attribute(s), in this case the DDS symbolic name, SHALL be 2437 included in the response. 2439 6.9.1.3 Discovery Domain Set Status 2441 The DDS_Status field is a 32-bit bitmap indicating the status of the 2442 DDS. Bit 0 of the bitmap indicates whether the DDS is Enabled (1) 2443 Internet Storage Name Service (iSNS) February 2002 2445 or Disabled (0). The default value for the DDS Enabled flag is 2446 Disabled (0). 2448 Bit Field DDS Status 2449 --------- --------- 2450 31 (Lsb) DDS Enabled (1) / DDS Disabled (0) 2451 All Others RESERVED 2453 6.9.1.4 Discovery Domain Set Member 2455 The Discovery Domain Set Member is a DD ID for a previously 2456 registered Discovery Domain. The DD ID tag value is used to 2457 represents membership. 2459 6.9.2 DD ID Keyed Attributes 2461 6.9.2.1 Discovery Domain ID (DD ID) 2463 The DD ID is a unique unsigned integer identifier used in the iSNS 2464 directory database to indicate the DD. This value is used as the 2465 key for any DD attribute query. If the iSNS client does not provide 2466 a DD_ID in a DD registration request message, the iSNS shall 2467 generate a DD_ID value that is unique within the iSNS database for 2468 that new DD (i.e., the iSNS client will be registered in a new DD). 2469 The created DD ID shall be returned in the response message. The DD 2470 ID value of 0 is reserved. 2472 6.9.2.2 Discovery Domain Symbolic Name 2474 The DD_Symbolic Name is a UTF-8 encoded, variable-length, NULL- 2475 terminated string. When registered by a client, the DD symbolic 2476 name SHALL be verified unique by the iSNS. If the DD symbolic name 2477 is not unique, then the DD registration SHALL be rejected with an 2478 �Invalid Registration� error code. The invalid attribute(s), in 2479 this case the DD symbolic name, SHALL be included in the response. 2481 6.9.2.3 Discovery Domain iSCSI Node Index 2483 This is the iSCSI Node Index of an iSNS client that is a member of 2484 the DD. The DD may have a list of 0 to n members. The iSCSI Node 2485 Index is one alternate representation of membership in a Discovery 2486 Domain, the other alternative being the iSCSI Node Name. The 2487 Discovery Domain iSCSI Node Index is a 4-byte integer value. 2489 The iSCSI Node Index can be used to represent a DD member in 2490 situations where the iSCSI Name is too long to be used. An example 2491 of this is when SNMP tables are used to access the contents of the 2492 iSNS server. 2494 The iSCSI Node Index and iSCSI Node Name registered as a member in a 2495 DD SHALL be consistent with the iSCSI Node Index and iSCSI Node Name 2496 used for the registered node in the iSNS. 2498 Internet Storage Name Service (iSNS) February 2002 2500 Both the iSCSI Name and iSCSI Node Index of a member are registered 2501 in the DD in order to maintain the unique 1:1 mapping between the 2502 two attributes for the member over multiple registration/ 2503 deregistrations of the same member in the iSNS. 2505 6.9.2.4 Discovery Domain Member--iSCSI Name 2507 The iSCSI Name of an iSNS client that is a member of the DD. The DD 2508 may have a list of 0 to n members. The iSCSI Name of the iSNS 2509 client represents membership. 2511 6.9.2.5 Discovery Domain Member--Port Name 2513 The Port Name of an iSNS client that is a member of the DD. The DD 2514 may have a list of 0 to n members. Membership is represented by the 2515 Port Name (WWPN) of the iSNS client being listed. 2517 6.9.2.6 Discovery Domain Features 2519 The Discovery Domain Features is a bitmap indicating the features of 2520 this DD. The bit fields are defined below. An enabled bit 2521 indicates the DD has the corresponding characteristics. 2523 Bit Field DD Feature 2524 --------- ---------- 2525 31 (Lsb) Boot List 2526 All Others RESERVED 2528 Boot List: this feature indicates that the targets in this DD 2529 provide boot capabilities for the member initiators. 2531 6.10 Vendor-Specific Attributes 2533 Specific iSNS implementations MAY define vendor-specific attributes 2534 for private use. The tag values reserved for vendor-specific and 2535 user-specific use are defined in section 6.10. To avoid 2536 misinterpreting proprietary attributes, it is RECOMMENDED that the 2537 vendor's own OUI (Organizationally Unique Identifier) be placed in 2538 the upper three bytes of the attribute field itself. If the OUI is 2539 not used, then some other unique marker recognizable by the vendor 2540 SHOULD be used. The OUI is defined in IEEE Std 802-1990, and is the 2541 same constant used to generate 48 bit Universal LAN MAC addresses. 2542 A vendor's own iSNS implementation will then be able to recognize 2543 the OUI in the vendor-specific or user-specific attribute field, and 2544 be able to execute vendor-specific handling of the attribute. 2546 6.10.1 Vendor-Specific Server Attributes 2548 Attributes with tags in the range 257 to 384 are vendor-specific or 2549 site-specific attributes of the iSNS server. These attributes are 2550 unique for each logical iSNS server instance. Query and 2551 registration messages for these attributes SHALL NOT contain a key 2552 attribute. 2554 Internet Storage Name Service (iSNS) February 2002 2556 6.10.2 Vendor-Specific Entity Attributes 2558 Attributes in the range 385 to 512 are vendor-specific or site- 2559 specific attributes used to describe the Entity object. These 2560 attributes are keyed by the Entity Identifier attribute (tag=1). 2562 6.10.3 Vendor-Specific Portal Attributes 2564 Attributes in the range 513 to 640 are vendor-specific or site- 2565 specific attributes used to describe the Portal object. These 2566 attributes are keyed by the Portal IP-Address (tag=16) and Portal 2567 TCP/UDP Port (tag=17). 2569 6.10.4 Vendor-Specific iSCSI Node Attributes 2571 Attributes in the range 641 to 768 are vendor-specific or site- 2572 specific attributes used to describe the iSCSI Node object. These 2573 attributes are keyed by the iSCSI Node Name (tag=32). 2575 6.10.5 Vendor-Specific Port Name Attributes 2577 Attributes in the range 769 to 896 are vendor-specific or site- 2578 specific attributes used to describe the N_Port Port Name object. 2579 These attributes are keyed by the Port Name WWPN (tag=64). 2581 6.10.6 Vendor-Specific Node Name Attributes 2583 Attributes in the range 897 to 1024 are vendor-specific or site- 2584 specific attributes used to describe the FC Node Name object. These 2585 attributes are keyed by the Node Name WWNN (tag=96). 2587 6.10.7 Vendor-Specific Discovery Domain Attributes 2589 Attributes in the range 1025 to 1280 are vendor-specific or site- 2590 specific attributes used to describe the Discovery Domain object. 2591 These attributes are keyed by the DD_ID (tag=104). 2593 6.10.8 Vendor-Specific Discovery Domain Set Attributes 2595 Attributes in the range 1281 to 1536 are vendor-specific or site- 2596 specific attributes used to describe the Discovery Domain Set 2597 object. These attributes are keyed by the DD Set ID (tag=101) 2599 6.11 Standards-Based Extensions 2601 These attributes are reserved for future work by other standards 2602 bodies. 2604 7. iSNSP Message Format 2606 The iSNSP message format is similar to the format of other common 2607 protocols such as DHCP, DNS and BOOTP. An iSNSP message may be sent 2608 in one or more iSNS Protocol Data Units (PDU). Each PDU is 4 byte 2609 aligned. The following describes the format of the iSNSP PDU: 2611 Internet Storage Name Service (iSNS) February 2002 2613 Byte MSb LSb 2614 Offset 0 31 2615 +---------------------+----------------------+ 2616 0 | iSNSP VERSION | FUNCTION ID | 4 Bytes 2617 +---------------------+----------------------+ 2618 4 | PDU LENGTH | FLAGS | 4 Bytes 2619 +---------------------+----------------------+ 2620 8 | TRANSACTION ID | SEQUENCE ID | 4 Bytes 2621 +---------------------+----------------------+ 2622 12 | | 2623 | PDU PAYLOAD | N Bytes 2624 | ... | 2625 +--------------------------------------------+ 2626 12+N | AUTHENTICATION BLOCK (Multicast Only) | L Bytes 2627 +--------------------------------------------+ 2628 Total Length = 12 + N +_L 2630 7.1 iSNSP PDU Header 2632 The iSNSP header contains the iSNSP VERSION, FUNCTION ID, PDU 2633 LENGTH, FLAGS, TRANSACTIONID, and SEQUENCE ID fields as defined 2634 below. 2636 7.1.1 iSNSP Version 2638 The iSNSP version is currently 0x0001. 2640 7.1.2 iSNSP Function ID 2642 The FUNCTION ID defines the type of iSNS message and the function 2643 the message is supporting. See section 5 under the appropriate 2644 protocol (i.e., iSCSI or iFCP) for a mapping of the FUNCTION_ID 2645 value to the iSNSP Command or Response message. All PDU's 2646 comprising an iSNSP message must have the same FUNCTION_ID and 2647 TRANSACTION ID value. 2649 7.1.3 iSNSP PDU Length 2651 The iSNS PDU LENGTH specifies the length of the PDU PAYLOAD field in 2652 bytes. The payload contains the data/attribute values for the 2653 operation. 2655 7.1.4 iSNSP Flags 2657 The FLAGS field indicates additional information about the message 2658 and the type of iSNS entity that generated the message. The 2659 following table displays the valid flags: 2661 Internet Storage Name Service (iSNS) February 2002 2663 Bit Field Enabled Means: 2664 --------- ------------- 2665 22-31 RESERVED 2666 21 First PDU of the iSNS message 2667 20 Last PDU of the iSNS message 2668 19 Replace Flag (valid only for RegDevAttr) 2669 18 RESERVED 2670 17 Sender is the iSNS server 2671 16 Sender is the iSNS client 2673 7.1.5 iSNSP Transaction ID 2675 The TRANSACTION ID is set to a unique random value for each request 2676 message. Replies MUST use the same TRANSACTION ID value as the 2677 associated iSNS request message. If a message is retransmitted, the 2678 same TRANSACTION ID value MUST be used. 2680 7.1.6 iSNSP Sequence ID 2682 The SEQUENCE ID is set to a unique value for each PDU within a 2683 single transaction. Each SEQUENCE_ID value in each PDU SHALL be 2684 numbered sequentially in the order that the PDU's are transmitted. 2685 If a message is retransmitted, then the same SEQUENCE_ID value MUST 2686 be used for all PDU's in the message. 2688 7.2 iSNSP Message Segmentation and Reassembly 2690 iSNS messages may be carried in one or more iSNS PDU's. If only one 2691 iSNS PDU is used to carry the iSNS message, then bit 10 (First PDU) 2692 and bit 11 in the FLAGS field (Last PDU) SHALL both be enabled. If 2693 multiple PDUs are used to carry the iSNS message, then bit 10 SHALL 2694 be enabled in the first PDU of the message, and bit 11 SHALL be 2695 enabled in the last PDU. 2697 All PDU's comprising the same iSNSP message SHALL have the same 2698 FUNCTION_ID and TRANSACTION_ID values. Each PDU comprising an iSNSP 2699 message SHALL have a unique SEQUENCE_ID value. 2701 The authentication operation described in section 7.5 SHALL be 2702 performed on a per-PDU basis. 2704 7.3 iSNSP Message Payload 2706 The MESSAGE PAYLOAD is variable length and contains attributes used 2707 for registration and query operations. The attribute data items use 2708 a format similar to other protocols, such as DHCP (RFC 2131) 2709 options. Each iSNS attribute is specified in the iSNSP message 2710 payload using Tag-Length-Value (TLV) data format, as shown below: 2712 Internet Storage Name Service (iSNS) February 2002 2714 Byte MSb LSb 2715 Offset 0 31 2716 +--------------------------------------------+ 2717 0 | Attribute Tag | 4 Bytes 2718 +--------------------------------------------+ 2719 4 | Attribute Length (N) | 4 Bytes 2720 +--------------------------------------------+ 2721 8 | | 2722 | Attribute Value | N Bytes 2723 | | 2724 +--------------------------------------------+ 2725 Total Length = 8 + N 2727 Attribute Tag - a 4-byte tag field that identifies the attribute as 2728 defined in section 6.1. This field contains the ID of the indicated 2729 attribute. 2731 Attribute Length - a 4-byte field that indicates the length, in 2732 bytes, of the attribute value to follow. 2734 Attribute Value - a variable-length field containing the attribute 2735 value. 2737 The above format is used to identify each attribute in the iSNS 2738 message payload. Each iSNSP request message contains several 2739 attributes in the above format to identify the requesting iSNS 2740 client and register or query for attribute values in the iSNS 2741 server. 2743 7.3.1 Attribute Value 4-Byte Alignment 2745 All attribute values are aligned at 4 byte boundaries. For variable 2746 length attributes, the value length is increased to the next 4-byte 2747 boundary and the value is NULL padded. 2749 7.4 iSNSP Response Error Codes 2751 All iSNSP response messages contain a 4-byte ERROR CODE field as the 2752 first field in the iSNSP PAYLOAD. If the original iSNSP request 2753 message was processed normally by the iSNS server, or the iSNS 2754 client for ESI and SCN messages, the field SHALL contain 0x00000000 2755 (NO ERROR). 2757 Internet Storage Name Service (iSNS) February 2002 2759 Error Code Error Description 2760 ---------- ----------------- 2761 0 No Error 2762 1 Unknown Error 2763 2 Message Format Error 2764 3 Invalid Registration 2765 4 Requested ESI Period Too Short 2766 5 Invalid Query 2767 6 Authentication Unknown 2768 7 Authentication Absent 2769 8 Authentication Failed 2770 9 No Such Entry 2771 10 Version Not Supported 2772 11 Internal Bus Error 2773 12 Busy Now 2774 13 Option Not Understood 2775 14 Invalid Update 2776 15 Message Not Supported 2777 16 SCN Event Rejected 2778 17 SCN Registration Rejected 2779 18 Attribute not Implemented 2780 19 SWITCH_ID not available 2781 20 SWITCH_ID not allocated 2782 21 ESI Not Available 2783 22 And Above RESERVED 2784 All undefined Error Code values are RESERVED. 2786 7.5 iSNS Multicast Message Authentication 2788 For iSNS multicast messages, the iSNSP provides authentication 2789 capability. The following section details the iSNS Authentication 2790 Block, which is identical in format to the SLP authentication block 2791 [RFC2608]. iSNS unicast messages SHOULD NOT include the 2792 authentication block, but rather should rely upon IPSec security 2793 mechanisms. 2795 If a PKI is available with an X.509 certificate authority, then 2796 public key authentication of the iSNS server is possible. The 2797 authentication block leverages the DSA with SHA-1 algorithm, which 2798 can easily integrate into a public key infrastructure. 2800 The authentication block contains a digital signature for the 2801 multicast message. The digital signature is calculated on a per-PDU 2802 basis. The authentication block contains the following information: 2804 1. A time stamp, to prevent replay attacks 2805 2. A structured authenticator containing a signature calculated 2806 over the time stamp and the message being secured 2807 3. An indicator of the cryptographic algorithm that was used to 2808 calculate the signature. 2809 4. An indicator of the keying material and algorithm parameters, 2810 used to calculate the signature. 2812 The authentication block is described in the following figure: 2814 Internet Storage Name Service (iSNS) February 2002 2816 Byte MSb LSb 2817 Offset 0 1 2 3 4 5 6 7 2818 +----------------------------------+ 2819 0 | BLOCK STRUCTURE DESCRIPTOR | 2 Bytes 2820 +----------------------------------+ 2821 2 | AUTHENTICATION BLOCK LENGTH | 2 Bytes 2822 +----------------------------------+ 2823 4 | TIMESTAMP | 4 Bytes 2824 +----------------------------------+ 2825 8 | SPI STRING LENGTH | 1 Byte 2826 +----------------------------------+ 2827 9 | SPI STRING | N Bytes 2828 +----------------------------------+ 2829 9 + N | STRUCTURED AUTHENTICATOR | M Bytes 2830 +----------------------------------+ 2831 Total Length = 9 + N + M 2833 BLOCK STRUCTURE DESCRIPTOR (BSD) - Defines the structure and 2834 algorithm to use for the STRUCTURED AUTHENTICATOR. Currently, the 2835 only defined value for BSD is 0x0002, which represents DSA with SHA- 2836 1. Details on DSA can be found in [DSS]. BSD values from 0x0000 to 2837 0x7FFF are assigned by IANA, while 0x8000 to 0x8FFF are for private 2838 use. The BSD value 0x0002 is compatible with the X.509 PKI 2839 specification, allowing easy integration of the STRUCTURED 2840 AUTHENTICATOR format with an existing PKI infrastructure. 2842 AUTHENTICATION BLOCK LENGTH - Defines the length of the 2843 authentication block, beginning with the BSD field and running 2844 through the last byte of the STRUCTURED AUTHENTICATOR. 2846 TIMESTAMP - This is a 4-byte unsigned, fixed-point integer giving 2847 the number of seconds since 00:00:00 GMT on January 1, 1970. 2849 SPI STRING LENGTH - The length of the SPI STRING field. 2851 SPI STRING (Security Parameters Index) - Index to the key and 2852 algorithm used by the message recipient to decode the STRUCTURED 2853 AUTHENTICATOR field. 2855 STRUCTURED AUTHENTICATOR - Contains the digital signature. For the 2856 default BSD value of 0x0002, this field contains the binary ASN.1 2857 encoding of output values from the DSA with SHA-1 signature 2858 calculation. 2860 7.6 Registration and Query Messages 2862 The iSNSP registration and query message payloads contain a list of 2863 attributes, and have the following format: 2865 Internet Storage Name Service (iSNS) February 2002 2867 MSb LSb 2868 0 31 2869 +----------------------------------------+ 2870 | Source Attribute (Query Only) | 2871 +----------------------------------------+ 2872 | Key Attribute[1] (if present) | 2873 +----------------------------------------+ 2874 | Key Attribute[2] (if present) | 2875 +----------------------------------------+ 2876 | Key Attribute[3] (if present) | 2877 +----------------------------------------+ 2878 | . . . | 2879 +----------------------------------------+ 2880 | - Delimiter Attribute - | 2881 +----------------------------------------+ 2882 | Operating Attribute[1] | 2883 +----------------------------------------+ 2884 | Operating Attribute[2] (if present) | 2885 +----------------------------------------+ 2886 | Operating Attribute[3] (if present) | 2887 +----------------------------------------+ 2888 | . . . | 2889 +----------------------------------------+ 2891 iSNS Registration and Query messages, sent by iSNS Clients, are sent 2892 to the iSNS IP-Address and TCP/UDP Port. The iSNS Responses will be 2893 sent to the iSNS Client IP-Address and the originating TCP/UDP Port 2894 used for the associated registration and query message. 2896 7.6.1 Source Attribute 2898 The source attribute is used to identify the iSNS client to the iSNS 2899 server for queries and other messages that require source 2900 identification. The source attribute uniquely identifies the source 2901 of the message. Valid source attribute types are shown below. 2903 Valid Source Attributes 2904 ----------------------- 2905 iSCSI Name 2906 FC Port Name WWPN 2908 For a query operation, the source attribute is used to limit the 2909 scope of the specified operation to the Discovery Domains of which 2910 the source is a member. Special control nodes, identified by the 2911 SOURCE attribute, may be administratively configured to perform the 2912 specified operation on all objects in the iSNS database without 2913 scoping to Discovery Domains. 2915 7.6.2 Key Attributes 2917 Key attributes are used to identify the object (or objects) in the 2918 iSNS server that the registration or query operation will be 2919 performed on. The number of Key Attributes depends on the specific 2920 iSNSP request or query operation being performed. 2922 Internet Storage Name Service (iSNS) February 2002 2924 7.6.3 Delimiter Attribute 2926 The Delimiter Attribute separates the key attributes from the 2927 operating attributes in a message payload. The Delimiter Attribute 2928 has a tag value of 0 and a length value of 0. The Delimiter 2929 Attribute is effectively 8 Bytes long, a 4 Byte tag containing 2930 0x00000000, and a 4 Byte length field containing 0x00000000. 2932 7.6.4 Operating Attributes 2934 The Operating Attributes are a list of one or more attributes 2935 related to the actual iSNS registration or query operation being 2936 performed. In a registration, operating attributes represent values 2937 to be registered by the iSNS client performing the registration. In 2938 a query, operating attributes represent values being requested by 2939 the iSNS client. 2941 The number of possible Operating Attributes depends on the specific 2942 iSNSP request or query. For example, the Operating Attributes in a 2943 Device Attribute Query message are the set of attributes to be 2944 returned in the associated Device Attribute Query Response message 2945 that match the Key Attributes of the query. 2947 Some iSNSP messages do not require any Operating Attributes. 2949 7.6.4.1 Operating Attributes for Query and Get Next Requests 2951 In Query and Get Next request messages, TLV attributes with length 2952 value of 0 are used to indicate what operating attributes are to be 2953 returned in the corresponding response. Operating Attribute values 2954 that match the TLV attributes in the original message are returned 2955 in the response message. 2957 7.6.5 Registration and Query Message Types 2959 The following describes each query and message type. 2961 7.6.5.1 Register Device Attribute Request (RegDevAttr) 2963 The RegDevAttr message type is 0x0001. The RegDevAttr message 2964 provides an iSNS client with the means to register network entities. 2965 The iSNS client formulates a RegDevAttr by specifying Key 2966 Attribute(s) and list of Operating Attributes to register. All 2967 values are in Tag Length Value (TLV) format. 2969 Attributes following the Delimiter Attribute are Operating 2970 Attributes. Depending on the setting of the Replace bit in the 2971 FLAGS field, the Operating attribute values in the RegDevAttr 2972 message will either replace existing attributes(s), or be added to 2973 existing attributes(s). See section 7.6.5.1.1 below for a complete 2974 description of the Replace Flag. 2976 The operating attributes are the elements that will be registered. 2977 Multiple attributes can be registered in one RegDevAttr. The 2978 Internet Storage Name Service (iSNS) February 2002 2980 ordering of the operating attributes indicates the associations to 2981 be created in the iSNS. For example, Portal attributes following 2982 Entity attributes SHALL create a link between the registered entity 2983 and portal. Similarly, node attributes following entity attributes 2984 will create an association. 2986 A RegDevAttr message with no key attribute results in creation of a 2987 new entity (EID). If the EID attribute (with non-zero length) is 2988 included among the operating attributes in the RegDevAttr message, 2989 then the new entity SHALL be assigned the value contained in that 2990 EID attribute. Otherwise, if the EID attribute is not contained 2991 among the operating attributes of the RegDevAttr message, or if the 2992 EID is an operating attribute with TLV length of 0, then the iSNS 2993 SHALL assign the EID value that is returned in the RegDevAttr 2994 Response message. 2996 One RegDevAttr message can contain attributes for Entity, Portal, 2997 and Node objects if each of these attributes are contained in the 2998 same Entity. When the registration contains attributes for the 2999 Entity, Portal, and Node objects together in the same message, then 3000 the appropriate Portal, and Node key attributes must be registered 3001 as part of the operating attributes. 3003 Ordering of the attributes is important in multi-object 3004 registrations. For example, Node Attributes follow a valid Node 3005 key. 3007 7.6.5.1.1 Replace Flag 3009 The Replace Flag, contained in the message header FLAGS field, 3010 indicates whether the registration is a replacement of, or update 3011 to, an existing entry. If the Replace bit in the FLAGS field is 3012 enabled then a new object entry SHALL be created, replacing the 3013 existing object if one exists. 3015 If the key attributes of the registration do not match an existing 3016 object then the Replace flag has no effect. 3018 If the key attributes match an existing object in the iSNS, and the 3019 Replace flag is enabled, then the registration will replace the 3020 existing entry in the iSNS. The existing object(s) specified in the 3021 RegDevAttr message shall be de-registered. A new registration shall 3022 be created with the new attribute value(s) in the registration 3023 request. Existing associations between objects will be updated to 3024 reflect the new information. For example, an existing Node object 3025 may be de-registered and reregistered with a different Entity object 3026 as part of a registration. 3028 If the key attributes match an existing object in the iSNS, and the 3029 Replace flag is not enabled, then the new attribute value(s) in the 3030 registration request SHALL update existing values and may add new, 3031 additional attributes for the key entry. Only non-key attributes 3032 can be updated. Existing associations between objects will be 3033 maintained. If a registration update of the existing object would 3034 Internet Storage Name Service (iSNS) February 2002 3036 cause a change in associations, then the error �Invalid Update� 3037 SHALL be returned. For example, if a RegDevAttr message with an 3038 Entity Identifier key for one entity contains a Node attribute 3039 associated with another entity, then an error shall be returned. 3041 7.6.5.2 Device Attribute Query Request (DevAttrQry) 3043 The DevAttrQry message type is 0x0002. The DevAttrQry message 3044 provides an iSNS client with the means to query the iSNS server for 3045 network entity attributes. The source is used to scope the query to 3046 the Discovery Domains that the source attribute is a member of. 3048 The Key Attribute(s) follow the source attribute in the message 3049 payload. The attributes returned by the query will be from objects 3050 WHERE the Key Attribute(s) match the object. The Key Attributes map 3051 to a type of object. 3053 The DevAttrQry message shall support the following minimum set of 3054 Key Attributes: 3056 Valid Key Attributes for Queries 3057 -------------------------------- 3058 Entity Identifier 3059 Entity Protocol 3060 Portal IP-Address 3061 Portal IP-Address, Portal TCP/UDP Port 3062 iSCSI Node Type 3063 iSCSI Identifier 3064 FC Port Name WWPN 3065 FC Port Type 3066 FC-4 Type 3067 Switch Name (FC Device WWNN--for space identifier queries) 3069 If the network entities matching key attributes are not in the same 3070 Discovery Domain as the Source Attribute, then the results for the 3071 network entity will not be included in the response message. 3073 The Operating Attributes are the attributes whose values are being 3074 queried. 3076 7.6.5.3 Device Get Next Request (DevGetNext) 3078 The DevGetNext message type is 0x0003. This message provides the 3079 iSNS client with the means to sequentially retrieve Entity, Portal, 3080 iSCSI Node, Port Name, or Node Name attributes from DD's to which 3081 the client has access. The source is used to scope the Get Next 3082 process to the Discovery Domains that the source attribute is a 3083 member of. 3085 The Key Attribute follows the source attribute in the message 3086 payload. The Key Attribute may be an Entity Identifier, iSCSI Name, 3087 Portal IP Address and TCP/UDP Port, FC Node Name WWNN, or FC Port 3088 Name WWPN. If the key TLV length value entered is zero, signifying 3089 an empty key value field, then the first accessible Entity 3090 Internet Storage Name Service (iSNS) February 2002 3092 Identifier, iSCSI Name, Portal IP Address and TCP/UDP Port, FC Node 3093 name, or FC Port Name instance shall be returned to the client. 3094 DevGetNext SHALL return the object that is stored sequentially after 3095 the object matching the key provided. If the key provided matches 3096 the last object instance, then the Error Code of "No Such Entry" 3097 SHALL be returned in the response. 3099 The values of the matching Operating Attributes listed in the 3100 original DevGetNext message SHALL be returned in the DevGetNext 3101 response. 3103 7.6.5.4 Deregister Device Request (DeregDev) 3105 The DeregDev message type is 0x0004. An iSNS client port or device 3106 is removed from the iSNS directory database by using DeregDev. Upon 3107 receiving the DeregDev, the iSNS server removes all object 3108 registrations associated with the Key Attribute in the payload. 3110 The DeregDev request message payload contains a Source Attribute and 3111 Key Attribute(s). Valid Key Attributes are shown below: 3113 Valid Key Attributes for DeregDev 3114 --------------------------------- 3115 Entity Identifier 3116 Portal IP-Address 3117 Portal IP-Address, Portal TCP/UDP Port 3118 iSCSI Name 3119 FC Port Name WWPN 3120 FC Node Name WWNN 3122 The removal of the object will initiate an SCN message to registered 3123 iSNS clients that are in the same DD as the removed device or port. 3124 After removing the port or device, the iSNS server sends back an 3125 acknowledgement to the iSNS client. 3127 If all nodes associated with an entity are deregistered from that 3128 entity, then the entity SHALL also be removed UNLESS the entity 3129 (through one or more Portals) is responding to ESI's. 3131 If all Portals associated with an entity are deregistered from that 3132 entity, then that entity and all associated nodes SHALL be removed 3133 from the iSNS database. 3135 7.6.5.5 SCN Register Request (SCNReg) 3137 The SCNReg message type is 0x0005. The State Change Notification 3138 Registration Request (SCNReg) message allows an iSNS client to 3139 register a STORAGE NODE to receive State Change Notification (SCN) 3140 messages. SCN messages are sent to the indicated UDP or TCP Port 3141 specified in the SCN Port field (tag 23), notifying the iSNS client 3142 of changes within the DD or network (if administratively allowed). 3144 Internet Storage Name Service (iSNS) February 2002 3146 The SCNReg request message payload contains a Source Attribute, a 3147 Key Attribute(s), and an Operating Attribute. Valid Key Attributes 3148 for an SCNReg are shown below: 3150 Valid Key Attributes for SCNReg 3151 ------------------------------- 3152 iSCSI Name 3153 FC Port Name WWPN 3155 The iSCSI nodes or Node Names matching the Key Attributes are 3156 registered to receive SCNs. 3158 The SCN Bitmap is the only operating attribute of this message, and 3159 it always overwrites the previous contents of this field in the iSNS 3160 database. The bitmap indicates those INTERESTED EVENT TYPES the 3161 node is registering for. 3163 7.6.5.6 SCN Deregister Request (SCNDereg) 3165 The SCNDereg message type is 0x0006. The SCNDereg message allows an 3166 iSNS client to disable State Change Notification (SCN) messages. 3168 The SCNDereg request message payload contains a Source Attribute and 3169 Key Attribute(s). Valid Key Attributes for an SCNDereg are shown 3170 below: 3172 Valid Key Attributes for SCNDereg 3173 --------------------------------- 3174 iSCSI Name 3175 FC Port Name WWPN 3177 The iSCSI or iFCP nodes matching the Key Attributes are deregistered 3178 for SCNs. 3180 There are no Delimiter or Operating Attributes in the SCNDereg 3181 message. 3183 7.6.5.7 SCN Event (SCNEvent) 3185 The SCNEvent message type is 0x0007. The SCNEvent is a message 3186 generated by an iSNS client. The SCNEvent allows the client to 3187 request generation of a State Change Notification (SCN) message by 3188 the iSNS server. The SCN, sent by the iSNS server, then notifies 3189 iFCP, iSCSI, and control nodes within the affected DD of the change 3190 indicated in the SCNEvent. 3192 Most SCNs are automatically generated by the iSNS when nodes are 3193 registered or deregistered from the directory database. SCNs are 3194 also be generated when a network management application makes 3195 changes to the DD membership in the iSNS. However, an iSNS client 3196 can trigger an SCN by using SCNEvent. 3198 Internet Storage Name Service (iSNS) February 2002 3200 The SCNEvent message payload contains a Source Attribute, Key 3201 Attribute, and Operating Attribute. Valid Key Attributes for an 3202 SCNEvent are shown below: 3204 Valid Key Attributes for SCNEvent 3205 --------------------------------- 3206 iSCSI Name 3207 FC Port Name WWPN 3209 The Operating Attributes section SHALL contain the SCN Event Bitmap 3210 attribute. The bitmap indicates the event that caused the SCNEvent 3211 to be generated. 3213 7.6.5.8 State Change Notification (SCN) 3215 The SCN message type is 0x0008. The SCN is a message generated by 3216 the iSNS server which notifies a registered iFCP, iSCSI, or control 3217 node of changes within its DD. The SCN message is sent to each 3218 Portal of the affected node that has a registered TCP or UDP Port in 3219 the SCN Port field. 3221 The types of events that a node can be notified about are based on 3222 the value of the SCN Event Bitmap for the node. 3224 The format of the SCN payload is shown below: 3226 +----------------------------------------+ 3227 | Destination Attribute | 3228 +----------------------------------------+ 3229 | Timestamp | 3230 +----------------------------------------+ 3231 | Source SCN Bitmap 1 | 3232 +----------------------------------------+ 3233 | Source Attribute [1] | 3234 +----------------------------------------+ 3235 | Source Attribute [2](if present) | 3236 +----------------------------------------+ 3237 | Source Attribute [3](if present) | 3238 +----------------------------------------+ 3239 | Source Attribute [n](if present) | 3240 +----------------------------------------+ 3241 | Source SCN Bitmap 2 (if present) | 3242 +----------------------------------------+ 3243 | . . . | 3244 +----------------------------------------+ 3246 All payload attributes are in TLV format. 3248 The Destination Attribute is the node identifier that is receiving 3249 the SCN. The Destination Attribute can be an iSCSI Name, or FC Port 3250 Name. 3252 The Timestamp field, using the Timestamp TLV format, indicates the 3253 time the SCN was generated. 3255 Internet Storage Name Service (iSNS) February 2002 3257 The Source Attributes describe the object that caused the SCN to be 3258 generated. The Source Attributes can be an iSCSI Name, DD ID, DDS 3259 ID, or FC Port Name, and possibly include other attributes to 3260 describe the change that occurred. The additional attributes are 3261 included to provide additional information about the source to 3262 minimize the possibility that the destination object needs to query 3263 the server for additional information. 3265 The Source SCN Bitmap field indicates the type of event that caused 3266 the SCN to be generated. This field is also used as a delimiter 3267 between information about multiple objects, if the SCN message is 3268 providing multiple notifications. 3270 7.6.5.9 DD Register (DDReg) 3272 The DDReg message type is 0x0009. This message is used to create a 3273 new Discovery Domain (DD), update an existing DD Symbolic Name, 3274 and/or add DD members. 3276 DDs are uniquely defined using DD_IDs. DD registration attributes 3277 are described in section 6.9.2. 3279 The DDReg message payload contains the Source Attribute, and 3280 optionally Key and Operating Attributes. 3282 A DDReg message with no key attribute results in creation of a new 3283 Discovery Domain (DD). If the DD_ID attribute (with non-zero 3284 length) is included among the operating attributes in the DDReg 3285 message, then the new Discovery Domain SHALL be assigned the value 3286 contained in that DD_ID attribute. Otherwise, if the DD_ID 3287 attribute is not contained among the operating attributes of the 3288 DDReg message, or if the DD_ID is an operating attribute with TLV 3289 length of 0, then the iSNS SHALL assign the DD_ID value that is 3290 returned in the DDReg Response message. 3292 The Operating Attributes can contain the iSCSI Node Identifier or 3293 iFCP WWPN of iSNS clients to be added to the DD. It may also 3294 contain the DD_Symbolic_Name of the DD. 3296 This message shall add any DD members listed as operating attributes 3297 to the Discovery Domain specified by the DD_ID. In addition, if the 3298 DD_Symbolic_Name is an operating attribute, then it will be stored 3299 in the iSNS as the DD_Symbolic_Name for the specified Discovery 3300 Domain. 3302 7.6.5.10 DD Deregister (DDDereg) 3304 The DDDereg message type is 0x000A. This message allows an iSNS 3305 client to deregister an existing Discovery Domain (DD) or remove 3306 members from an existing DD. 3308 DDs are uniquely defined using DD_IDs. DD registration attributes 3309 are described in section 6.9. 3311 Internet Storage Name Service (iSNS) February 2002 3313 The DDDereg message payload contains a Source Attribute, Key 3314 Attribute, and Operating Attributes. 3316 The Key Attribute for a DDDereg message is the DD ID for the domain 3317 being removed, or having members removed. If the DD ID matches an 3318 existing DD, and there are no operating attributes, then the DD will 3319 be removed and a success error code returned. If the key attribute 3320 does not match an existing DD then the error code �No Such Entry� 3321 will be returned. 3323 If the DD ID matches an existing DD, and there are operating 3324 attributes matching DD members, then the DD members identified by 3325 the operating attributes SHALL be removed from the DD and a success 3326 error code returned. If any of the operating attributes do not 3327 match existing DD members, then the error code �No Such Entry� will 3328 be returned, and no DD members shall be removed. 3330 7.6.5.11 DDS Register (DDSReg) 3332 The DDSReg message type is 0x000B. This message allows an iSNS 3333 client to create a new Discovery Domain Set (DDS), update an 3334 existing DDS Symbolic Name, or add DDS members. 3336 DDS�s are uniquely defined using DDS_ID�s. DDS registration 3337 attributes are described in section 6.9.1. 3339 The DDSReg message payload contains the Source Attribute, and 3340 optionally Key and Operating Attributes. 3342 A DDSReg message with no key attribute results in creation of a new 3343 Discovery Domain Set (DDS). If the DDS_ID attribute (with non-zero 3344 length) is included among the operating attributes in the DDSReg 3345 message, then the new Discovery Domain Set SHALL be assigned the 3346 value contained in that DDS_ID attribute. Otherwise, if the DDS_ID 3347 attribute is not contained among the operating attributes of the 3348 DDSReg message, or if the DDS_ID is an operating attribute with TLV 3349 length of 0, then the iSNS SHALL assign the DDS_ID value that is 3350 returned in the DDSReg Response message. 3352 The Operating Attributes can contain the DDS_Symbolic_Name and the 3353 DD_ID�s of Discovery Domains to be added to the DDS. 3355 This message shall add any DDS members listed as operating 3356 attributes to the Discovery Domain Set specified by the DDS_ID key 3357 attribute. In addition, if the DDS_Symbolic_Name is an operating 3358 attribute, then it will be stored in the iSNS as the 3359 DDS_Symbolic_Name for the specified Discovery Domain Set. 3361 7.6.5.12 DDS Deregister (DDSDereg) 3363 The DDSDereg message type is 0x000C. This message allows an iSNS 3364 client to deregister an existing Discovery Domain Set (DDS) or 3365 remove some DD�s from an existing DDS. 3367 Internet Storage Name Service (iSNS) February 2002 3369 The DDSDereg message payload contains a Source Attribute, Key 3370 Attribute, and Operating Attributes. 3372 The Key Attribute for a DDSDereg message is the DDS ID for the set 3373 being removed, or having members removed. If the DDS ID matches an 3374 existing DDS, and there are no operating attributes, then the DDS 3375 will be removed and a success error code returned. If the key 3376 attribute does not match an existing DDS then the error code �No 3377 Such Entry� will be returned. 3379 If the DDS ID matches an existing DDS, and there are operating 3380 attributes matching DDS members, then the DDS members will be 3381 removed from the DDS and a success error code returned. If any of 3382 the operating attributes do not match existing DDS members, then the 3383 error code �No Such Entry� will be returned and no DDS members shall 3384 be removed. 3386 7.6.5.13 Entity Status Inquiry (ESI) 3388 The ESI message type is 0x000D. This message is sent by the iSNS 3389 server, and is used to verify that an iSNS client portal is 3390 reachable and available. The ESI message is sent to the ESI UDP port 3391 provided during registration, or the TCP connection used for ESI 3392 registration, depending on which communication type that is being 3393 used. 3395 The ESI message payload contains several attributes in TLV format, 3396 including the current iSNS timestamp, the EID, the Portal IP 3397 Address, and Portal TCP/UDP Port. 3399 The ESI response message payload contains the Attributes from the 3400 original ESI message. 3402 If the iSNS client portal fails to respond to three consecutive ESI 3403 messages, then the iSNS SHALL remove that client portal from the 3404 iSNS database. If there are no other remaining ESI monitored portals 3405 for the associated entity, then the entity SHALL also be removed. 3406 The appropriate State Change Notifications, if any, SHALL be 3407 triggered. 3409 7.6.5.14 Name Service Heartbeat (Heartbeat) 3411 This message SHOULD only be sent by the active iSNS server. It 3412 allows iSNS clients and backup servers listening to the broadcast or 3413 multicast address to discover the IP address of the primary and 3414 backup iSNS servers. It also all concerned parties to monitor the 3415 health and status of the primary iSNS server. 3417 This message is NOT in TLV format. There is no response message to 3418 the Name Service Heartbeat. 3420 Internet Storage Name Service (iSNS) February 2002 3422 MSb LSb 3423 0 31 3424 +------------------------------------------------+ 3425 | Active Server IP-Address | 3426 +------------------------------------------------+ 3427 | iSNS TCP Port | iSNS UDP Port | 3428 +------------------------------------------------+ 3429 | Interval | 3430 +------------------------------------------------+ 3431 | Counter | 3432 +------------------------------------------------+ 3433 | RESERVED | Backup Servers | 3434 +------------------------------------------------+ 3435 | Primary Backup Server IP Address(if any) | 3436 +------------------------------------------------+ 3437 |Backup TCP Port(if any)|Backup UDP Port(if any) | 3438 +------------------------------------------------+ 3439 | 2nd Backup Server IP Address(if any) | 3440 +------------------------------------------------+ 3441 |Backup TCP Port(if any)|Backup UDP Port(if any) | 3442 +------------------------------------------------+ 3443 | . . . | 3444 +------------------------------------------------+ 3445 | VENDOR SPECIFIC | 3446 +------------------------------------------------+ 3448 The heartbeat payload contains: 3450 Active Server IP-Address: the IP_Address of the active iSNS server 3451 in IPv6 format. 3453 Active TCP Port: the TCP Port of the server currently in use 3455 Active UDP Port: the UDP Port of the server currently in use, 3456 otherwise 0 3458 Interval: the interval, in seconds, of the heartbeat 3460 Counter: a monotonically incrementing count of heartbeats sent 3462 Backup Servers: the number of iSNS backup servers. The IP address, 3463 TCP Port, and UDP Port of each iSNS backup server follow this field. 3464 Note that if backup servers are used, then the active iSNS server 3465 SHOULD list be among the list of backup servers. 3467 The content of the remainder of this message after the list of 3468 backup servers is vendor-specific. Vendors may use additional 3469 fields to coordinate between multiple iSNS servers, and/or to 3470 identify vendor specific features. 3472 7.6.5.15 Request Switch ID (RqstSwId) 3474 The RqstSwId message type is 0x0011. This message is used for iFCP 3475 Transparent Mode to allocate non-overlapping SWITCH_ID values 3476 Internet Storage Name Service (iSNS) February 2002 3478 between 1 and 239. The iSNS server becomes the address assignment 3479 authority for the entire iFCP fabric. To obtain multiple SWITCH_ID 3480 values, this request must be repeated multiple times to the iSNS 3481 server. 3483 The RqstSwId payload contains three TLV attributes in the following 3484 order: the requesting Switch Name (WWN) as the source attribute, the 3485 Space Identifier as the key attribute, and Preferred ID as the 3486 operating attribute. The Space Identifier is a string identifying 3487 the domain space for which the iSNS server shall allocate non- 3488 overlapping integer SWITCH_ID values between 1 and 239. The 3489 Preferred_ID is the nominal SWITCH_ID value requested by the iSNS 3490 client. If the Preferred_ID value is available and has not been 3491 already allocated for the Space_Identifier specified in the message, 3492 the iSNS server shall return the requested Preferred_ID value as the 3493 Assigned_ID to the requesting client. 3495 The RqstSwId response contains an Error Code, and the TLV attribute 3496 Assigned ID, which contains the integer value in the space 3497 requested. If no further unallocated values are available from this 3498 space, the iSNS server SHALL respond with the error code 18 3499 "SWITCH_ID not available". 3501 Once a SWITCH_ID value has been allocated to an iSNS client by the 3502 iSNS server for a given Space_Identifier, that SWITCH_ID value shall 3503 not be reused until it has been deallocated, or the ESI message 3504 detects that the iSNS client no longer exists on the network. 3506 The iSNS server and client SHALL use TCP to transmit and receive 3507 RqstSwId, RqstSwIdRsp, RlseSwId, and RlseSwIdRsp messages. 3509 7.6.5.16 Release Switch ID (RlseSwId) 3511 The RlseSwId message type is 0x0012. This message may be used by 3512 iFCP Transparent Mode to release integer identifier values used to 3513 assign 3-byte Fibre Channel PORT_ID values. 3515 The RlseSwId message contains three TLV attributes in the following 3516 order: the requesting entity EID as the source attribute, the 3517 Space_Identifier as the key attribute, and Assigned_ID as the 3518 operating attribute. Upon receiving the RlseSwId message, the iSNS 3519 server shall deallocate the SWITCH_ID value contained in the 3520 Assigned_ID attribute for the Space_Identifier attribute specified. 3521 Upon deallocation, that SWITCH_ID value can now be requested by, and 3522 assigned to, a different iSNS client. 3524 The iSNS server and client SHALL use TCP to transmit and receive 3525 RqstSwId, RqstSwIdRsp, RlseSwId, and RlseSwIdRsp messages. 3527 7.6.5.17 Get Switch IDs (GetSwIds) 3529 The GetSwIds message type is 0x0013. This message is used to learn 3530 the currently-allocated SWITCH_ID values for a given 3531 Space_Identifier. 3533 Internet Storage Name Service (iSNS) February 2002 3535 The GetSwIds message payload contains a Source Attribute and Key 3536 Attribute. 3538 The Key Attribute for the GetSwIds message is the Space_Identifier. 3539 The response to this message returns all of the SWITCH_ID values 3540 that have been allocated for the Space_Identifier specified. 3542 7.7 Response Messages 3544 The iSNSP response message payloads contain an Error Code, followed 3545 by a list of attributes, and have the following format: 3547 MSb LSb 3548 0 31 3549 +----------------------------------------+ 3550 | 4-byte ERROR CODE | 3551 +----------------------------------------+ 3552 | Key Attribute[1] (if present) | 3553 +----------------------------------------+ 3554 | Key Attribute[2] (if present) | 3555 +----------------------------------------+ 3556 | Key Attribute[3] (if present) | 3557 +----------------------------------------+ 3558 | . . . | 3559 +----------------------------------------+ 3560 | - Delimiter Attribute - (if present) | 3561 +----------------------------------------+ 3562 | Operating Attribute[1] (if present) | 3563 +----------------------------------------+ 3564 | Operating Attribute[2] (if present) | 3565 +----------------------------------------+ 3566 | Operating Attribute[3] (if present) | 3567 +----------------------------------------+ 3568 | . . . | 3569 +----------------------------------------+ 3571 The iSNS Response messages will be sent to the iSNS Client IP 3572 Address and the originating TCP/UDP Port that was used for the 3573 associated registration and query message. 3575 7.7.1 Error Code 3577 The first field in an iSNSP response message payload is the Error 3578 Code for the operation that was performed. The Error Code format is 3579 defined in section 7.4. 3581 7.7.2 Key Attributes in Response 3583 Depending on the specific iSNSP request, the response message will 3584 contain Key Attributes. For example, a Register Device Attribute 3585 Response message will contain the Key Attributes used in the Device 3586 Attribute Registration with the assigned values, if they were 3587 assigned by the iSNS. 3589 Internet Storage Name Service (iSNS) February 2002 3591 7.7.3 Delimiter Attribute in Response 3593 The Delimiter Attribute separates the key and operating attributes 3594 in a response message, if they exist. The Delimiter Attribute has a 3595 tag value of 0 and a length value of 0. The Delimiter Attribute is 3596 effectively 8 Bytes long, a 4 Byte tag containing 0x00000000, and a 3597 4 Byte length field containing 0x00000000. 3599 7.7.4 Operating Attributes in Response 3601 The Operating Attributes in a response are the results related to 3602 the iSNS registration or query operation being performed. 3604 The number of Operating Attributes in the response depends on the 3605 specific iSNSP request or query response. For example, the 3606 Operating Attributes in a Device Attribute Query Response message 3607 are the set of Operating Attributes from network entity entries that 3608 matched the Key Attributes in the associated Device Attribute Query 3609 message. 3611 7.7.5 Registration and Query Message Types 3613 The following describes each query and message type. 3615 7.7.5.1 Register Device Attribute Response (RegDevRsp) 3617 The RegDevRsp message type is 0x8001. The RegDevRsp message 3618 contains the results for the RegDevAttr message with the same 3619 TRANSACTION ID. 3621 The Error Code contains the operation results. If the registration 3622 completed successfully the code of �No Error� is returned. If an 3623 error occurred then the appropriate code will be returned. 3625 The Key Attributes contain the set of keys for the objects 3626 registered by the Register Device Attribute message. If the iSNS 3627 assigned a unique Entity Identifier for a network entity, then the 3628 key attribute field shall contain the assigned Entity Identifier. 3630 There are no Operating Attributes in the RegDevRsp message. 3632 7.7.5.2 Device Attribute Query Response (DevAttrQryRsp) 3634 The DevAttrQryRsp message type is 0x8002. The DevAttrQryRsp message 3635 contains the results for the DevAttrQry message with the same 3636 TRANSACTION ID. 3638 The Error Code contains the operation results. If the query 3639 completed successfully the code of �No Error� is returned. If an 3640 error occurred then the appropriate code will be returned. 3642 For a successful query result, the DevAttrQryRsp Operating 3643 Attributes will contain the results of the original DevAttrQry 3644 message. 3646 Internet Storage Name Service (iSNS) February 2002 3648 7.7.5.3 Device Get Next Response (DevGetNextRsp) 3650 The DevGetNextRsp message type is 0x8003. The DevGetNextRsp message 3651 contains the results for the DevGetNext message with the same 3652 TRANSACTION ID. 3654 The Error Code contains the operation results. If the operation 3655 completed successfully the code of �No Error� is returned. If an 3656 error occurred then the appropriate code will be returned. 3658 The Key Attribute field contains the next key, in sequential order, 3659 after the Key Attribute used in the DevGetNext message. 3661 The Operating Attribute field contains the same attributes as in the 3662 DevGetNext message. The values of the Operating Attributes are the 3663 attribute values associated with the key returned. 3665 7.7.5.4 Deregister Device Response (DeregDevRsp) 3667 The DeregDevRsp message type is 0x8004. If the DeregDe operation 3668 completed successfully then the code of �No Error� is returned. If 3669 an error occurred then the appropriate code will be returned. 3671 The DeregDevRsp message does not contain any key or operating 3672 attributes. 3674 7.7.5.5 SCN Register Response (SCNRegRsp) 3676 The SCNRegRsp message type is 0x8005. If the SCReg operation 3677 completed successfully then the code of �No Error� is returned. If 3678 an error occurred then the appropriate code will be returned. 3680 The SCNRegRsp message does not contain any key or operating 3681 attributes. 3683 7.7.5.6 SCN Deregister Response (SCNDeregRsp) 3685 The SCNDeregRsp message type is 0x8006. If the SCNDereg operation 3686 completed successfully then the code of �No Error� is returned. If 3687 an error occurred then the appropriate code will be returned. 3689 The SCNDeregRsp message does not contain any key or operating 3690 attributes. 3692 7.7.5.7 SCN Event Response (SCNEventRsp) 3694 The SCNEventRsp message type is 0x8007. If the SCNEvent operation 3695 completed successfully then the Error Code of �No Error� is 3696 returned. If an error occurred then the appropriate code will be 3697 returned. 3699 The SCNEventRsp message does not contain any key or operating 3700 attributes. 3702 Internet Storage Name Service (iSNS) February 2002 3704 7.7.5.8 SCN Response (SCNRsp) 3706 The SCNRsp message type is 0x8008. This message is sent by an iSNS 3707 client, and provides confirmation that the SCN message was received 3708 and processed. 3710 If the SCN operation completed successfully, then the Error Code of 3711 �No Error� is returned by the iSNS client. If an error occurred 3712 then the appropriate code will be returned. 3714 The SCNRsp response message payload also contains the SCN 3715 Destination Attribute representing the node or entity identifier 3716 that received the SCN. 3718 7.7.5.9 DD Register Response (DDRegRsp) 3720 The DDRegRsp message type is 0x8009. If the DDReg operation 3721 completed successfully then the code of �No Error� is returned. If 3722 an error occurred then the appropriate code will be returned. 3724 If successful, the DD ID of the DD created or updated during the 3725 DDReg operation will be returned as an operating attribute of the 3726 message. 3728 7.7.5.10 DD Deregister Response (DDDeregRsp) 3730 The DDDeregRsp message type is 0x800A. If the DDDereg operation 3731 completed successfully then the code of �No Error� is returned. If 3732 an error occurred then the appropriate code will be returned. 3734 The DDDeregRsp message does not contain any key or operating 3735 attributes. 3737 7.7.5.11 DDS Register Response (DDSRegRsp) 3739 The DDSRegRsp message type is 0x800B. If the DDSRegRsp operation 3740 completed successfully then the code of �No Error� is returned. If 3741 an error occurred then the appropriate code will be returned. 3743 If successful, the DDS ID of the DDS created or updated during the 3744 DDSReg operation will be returned as an operating attribute of the 3745 message. 3747 7.7.5.12 DDS Deregister Response (DDSDeregRsp) 3749 The DDSDeregRsp message type is 0x800C. If the DDSDeregRsp operation 3750 completed successfully then the code of �No Error� is returned. If 3751 an error occurred then the appropriate code will be returned. 3753 The DDSDeregRsp message does not contain any key or operating 3754 attributes. 3756 Internet Storage Name Service (iSNS) February 2002 3758 7.7.5.13 Entity Status Inquiry Response (ESIRsp) 3760 The ESIRsp message type is 0x800D. This message is sent by an iSNS 3761 client, and provides confirmation that the ESI message was received 3762 and processed. 3764 The ESIRsp response message payload contains the attributes from the 3765 original ESI message. These attributes represent the iSNS client 3766 portal that is responding to the ESI. The ESIRsp Attributes are in 3767 the order they were provided in the original ESI message. An error 3768 code of "No Error" is returned. 3770 Upon receiving the ESIRsp from the iSNS client, the iSNS server 3771 SHALL update the timestamp attribute for that client entity and 3772 portal. 3774 7.7.5.14 Request Switch ID Response (RqstSwIdRsp) 3776 The RqstSwIdRsp message type is 0x8011. This message provides the 3777 response for RqstSwId. 3779 The RqstSwId response contains an Error Code and the TLV attribute 3780 Assigned ID, which contains the integer value in the space 3781 requested. If no further unallocated values are available from this 3782 space, the iSNS server SHALL respond with the error code 19 3783 "SWITCH_ID not available". 3785 Once a SWITCH_ID value is allocated by the iSNS server, it shall not 3786 be reused until it has been deallocated by the iSNS client to which 3787 the value was assigned, or the ESI message detects that the iSNS 3788 client no longer exists on the network. 3790 The iSNS server and client SHALL use TCP to transmit and receive 3791 RqstSwId, RqstSwIdRsp, RlseSwId, and RlseSwIdRsp messages. 3793 7.7.5.15 Release Switch ID Response (RlseSwIdRsp) 3795 The RlseSwIdRsp message type is 0x8012. This message provides the 3796 response for RlseSwId. The response contains an Error indicating if 3797 the request was successful or not. If the Assigned_ID value in the 3798 original RlseSwId message is not allocated, then the iSNS server 3799 SHALL respond with this message using the error code 20 �SWITCH_ID 3800 not allocated�. 3802 The iSNS server and client SHALL use TCP to transmit and receive 3803 RqstSwId, RqstSwIdRsp, RlseSwId, and RlseSwIdRsp messages. 3805 7.7.5.16 Get Switch IDs Response (GetSwIdRsp) 3807 The GetSwIdsResp message type is 0x8013. This message is used 3808 determine which SWITCH_ID values have been allocated for the 3809 Space_Identifier specified in the original GetSwId request message. 3811 Internet Storage Name Service (iSNS) February 2002 3813 The GetSwIds response message payload contains an error code 3814 indicating if the request was successful, and a list of the Assigned 3815 IDs from the space requested. The Assigned_ID attributes are listed 3816 in TLV format. 3818 7.8 Vendor Specific Messages 3820 Vendor-specific iSNSP messages have a functional ID of between 3821 0x0100 and 0x01FF, while vendor-specific responses have a functional 3822 ID of between 0x8100 and 0x81FF. The first key attribute in a 3823 vendor-specific message SHALL be the company OUI (tag=256) 3824 identifying original creator of the proprietary iSNSP message. The 3825 contents of the remainder of the message are vendor-specific. 3827 8. Security Considerations 3829 8.1 iSNS Security Threat Analysis 3831 When the iSNS protocol is deployed, the interaction between iSNS 3832 server and iSNS clients are subject to the following security 3833 threats: 3835 [1] An attacker could alter iSNS protocol messages, such as to 3836 direct iSCSI and iFCP devices to establish connections with rogue 3837 peer devices, or to weaken/eliminate IPSec protection for iSCSI or 3838 iFCP traffic. 3840 [2] An attacker could masquerade as the real iSNS server using 3841 false iSNS heartbeat messages. This could cause iSCSI and iFCP 3842 devices to use rogue iSNS servers. 3844 [3] An attacker could gain knowledge about iSCSI and iFCP devices 3845 by snooping iSNS protocol messages. Such information could aid an 3846 attacker in mounting a direct attack on iSCSI and iFCP devices, such 3847 as a denial-of-service attack or outright physical theft. 3849 To address these threats, the following capabilities are needed: 3851 [a] Unicast iSNS protocol messages may need to be authenticated. 3852 In addition, to protect against threat [3] above, confidentiality 3853 support is desireable, and REQUIRED when certain functions of iSNS 3854 are used. 3856 [b] Multicast iSNS protocol messages such as the iSNS heartbeat 3857 message may need to be authenticated. These messages need not be 3858 confidential since they do not leak critical information. 3860 8.2 iSNS Security Implementation and Usage Requirements 3862 If iSNS is used to distribute authorizations for communications 3863 between iFCP and iSCSI peer devices, IPsec ESP with null transform 3864 MUST be implemented. 3866 Internet Storage Name Service (iSNS) February 2002 3868 If iSNS is used to distribute security policy for iFCP and iSCSI 3869 devices, then authentication, data integrity, and confidentiality 3870 MUST be supported and used. Where confidentiality is desired or 3871 required, IPsec ESP with non-null transform SHOULD be used. 3873 In order to protect against an attacker masquerading as an iSNS 3874 server, client devices MUST support the ability to authenticate 3875 broadcast or multicast messages such as the iSNS heartbeat. The 3876 iSNS authentication block (which is identical in format to the SLP 3877 authentication block) MAY be used for this purpose. Note that the 3878 authentication block is used only for iSNS broadcast or multicast 3879 messages, and SHOULD NOT be used in unicast iSNS messages. 3881 There is no requirement that the communicating identities in iSNS 3882 protocol messages be kept confidential. Specifically, the identity 3883 and location of the iSNS server shall not be considered 3884 confidential. 3886 For protecting unicast iSNS protocol messages, iSNS servers 3887 supporting security MUST implement ESP in tunnel mode and MAY 3888 implement transport mode. 3890 All iSNS implementations supporting security MUST support the replay 3891 protection mechanisms of IPsec. 3893 Conformant iSNS security implementations MUST support IKE for 3894 authentication, negotiation of security associations, and key 3895 management, using the IPSec DOI [RFC2407]. Manual keying SHOULD NOT 3896 be used since it does not provide the necessary rekeying support. 3897 Conformant iSNS security implementations MUST support authentication 3898 using a pre-shared key, and MAY support certificate-based peer 3899 authentication using digital signatures. Peer authentication using 3900 the public key encryption methods outlined in IKE's sections 5.2 and 3901 5.3 [RFC2409] SHOULD NOT be supported. 3903 Conformant iSNS implementations MUST support both IKE Main Mode and 3904 Aggressive Mode. IKE Main Mode with pre-shared key authentication 3905 SHOULD NOT be used when either of the peers use dynamically assigned 3906 IP addresses. While Main Mode with pre-shared key authentication 3907 offers good security in many cases, situations where dynamically 3908 assigned addreses are used force the use a group pre-shared key, 3909 which is vulnerable to man-in-the-middle attack. 3911 When digital signatures are used for authentication, either IKE Main 3912 Mode or IKE Aggressive Mode MAY be used. In all cases, access to 3913 locally stored secret information (pre-shared key or private key for 3914 digital signing) MUST be suitably restricted, since compromise of 3915 the secret information nullifies the security properties of the 3916 IKE/IPsec protocols. 3918 When digital signatures are used to achieve authentiation, an IKE 3919 negotiator SHOULD use IKE Certificate Request Payload(s) to specify 3920 the certificate authority (or authorities) that are trusted in 3921 accordance with its local policy. IKE negotiators SHOULD check the 3922 Internet Storage Name Service (iSNS) February 2002 3924 pertinent Certificate Revocation List (CRL) before accepting a PKI 3925 certificate for use in IKE's authentication procedures. 3927 When iSNS is used without security, IP block storage protocol 3928 implementations MUST support a negative cache for authentication 3929 failures. This allows implementations to avoid continually 3930 contacting discovered endpoints which fail authentication within 3931 IPsec or at the application layer (in the case of iSCSI Login). The 3932 negative cache need not be maintained within the IPsec 3933 implementation, but rather within the IP block storage protocol 3934 implementation. 3936 8.3 Using iSNS to Discover Security Requirements of Peer Devices 3938 The iSNS protocol is used to transfer naming, discovery, and 3939 management information between iSCSI devices, iFCP gateways, 3940 management stations, and the iSNS server. Once communication 3941 between iSNS clients and the iSNS server have been secured through 3942 use of IPSec, the iSNS client devices have the capability to 3943 discover the security settings that they need to use for their peer- 3944 to-peer communications using the iSCSI and/or iFCP protocols. This 3945 provides a potential scaling advantage over device-by-device 3946 configuration of individual security policies for each iSCSI and 3947 iFCP device. 3949 The iSNS server stores security settings for each iSCSI and iFCP 3950 device interface. These security settings, which can be retrieved 3951 by authorized hosts, include use or non-use of IPSec, IKE, Main 3952 Mode, and Aggressive Mode. For example, IKE may not be enabled for 3953 a particular interface of a peer device. If a peer device can learn 3954 of this in advance by consulting the iSNS server, it will not need 3955 to waste time and resources attempting to initiate an IKE phase 1 3956 session with that peer device interface. 3958 If iSNS is used for this purpose, then the minimum information that 3959 should be learned from the iSNS server is the use or non-use of IKE 3960 and IPSec by each iFCP or iSCSI peer device interface. This 3961 information is encoded in the Security Bitmap field of each Portal 3962 of the peer device, and is applicable on a per-interface basis for 3963 the peer device. iSNS queries to acquire security configuration 3964 data about peer devices MUST be protected by IPSec/ESP 3965 authentication. 3967 8.4 Using iSNS to Configure Security Policies of Client Devices 3969 Once communication between iSNS clients and the iSNS server are 3970 secured through use of IPsec, iSNS clients have the capability to 3971 discover the security settings required for communication via the 3972 iSCSI and/or iFCP protocols. Use of iSNS for distribution of 3973 security policies offers the potential to reduce the burden of 3974 manual device configuration, and decrease the probability of 3975 communications failures due to incompatible security policies. If 3976 iSNS is used to distribute security policies, then IPSec 3977 Internet Storage Name Service (iSNS) February 2002 3979 authentication, data integrity, and confidentiality MUST be used to 3980 protect all iSNS protocol messages. 3982 The complete IKE/IPSec configuration of each iFCP and/or iSCSI 3983 device can be stored in the iSNS server, including policies that are 3984 used for IKE Phase 1 and Phase 2 negotiations between client 3985 devices. The IKE payload format includes a series of one or more 3986 proposals that the iSCSI or iFCP device will use when negotiating 3987 the appropriate IPsec policy to use to protect iSCSI or iFCP 3988 traffic. 3990 In addition, the iSCSI Authentication Methods used by each iSCSI 3991 device can also be stored in the iSNS server. The iSCSI AuthMethod 3992 field (tag=42) contains a null-terminated string embedded with the 3993 text values indicating iSCSI authentication methods to be used by 3994 that iSCSI device. 3996 Note that iSNS distribution of security policy is not necessary if 3997 the security settings can be determined by other means, such as 3998 manual configuration or IPsec security policy distribution. If an 3999 entity has already obtained its security configuration via other 4000 mechanisms, then it MUST NOT request security policy via iSNS. 4002 For further details on how to store and retrieve IKE policy 4003 proposals in the iSNS server, see [58]. 4005 8.5 Resource Issues 4007 The iSNS protocol is lightweight, and will not generate a 4008 significant amount of traffic. iSNS traffic is characterized by 4009 occassional registration, notification, and update messages that do 4010 not consume measurable amounts of bandwidth. Even software-based 4011 IPSec implementations should not have a problem handling the traffic 4012 loads generated by iSNS. 4014 To fulfill iSNS security requirements, the only additional resources 4015 needed beyond what is already required for iSCSI and iFCP involves 4016 the iSNS server. Since iSCSI and iFCP end nodes are already 4017 required to implement IKE and IPSec, these existing requirements can 4018 also be used to fulfill IKE and IPSec requirements for iSNS clients. 4020 8.6 iSNS Interaction with IKE and IPSec 4022 When IPSec security is enabled, each iSNS client that is registered 4023 in the iSNS database SHALL maintain at least one phase-1 and one 4024 phase-2 security association with the iSNS server. All iSNS 4025 protocol messages between iSNS clients and the iSNS server SHALL be 4026 protected by a phase-2 security association. 4028 When an iSNS client is removed from the iSNS database, the iSNS 4029 server shall send a phase-1 delete message to the associated IKE 4030 peer, and tear down all phase-1 and phase-2 SA's associated with 4031 that iSNS client. 4033 Internet Storage Name Service (iSNS) February 2002 4035 9. Normative References 4037 [iSCSI] Satran, J., et al., "iSCSI", Internet draft (work in 4038 progress), draft-ietf-ips-iSCSI-09.txt, November 2001 4040 [iFCP] Monia, C., et al., "iFCP - A Protocol for Internet Fibre 4041 Channel Storage Networking", Internet draft (work in 4042 progress), draft-ietf-ips-ifcp-07.txt, November 2001 4044 [RFC2608] Guttman, E., Perkins, C., Veizades, J., Day, M., 4045 "Service Location Protocol, Version 2", RFC 2608, June 4046 1999 4048 [iSCSIName] Bakke, M., et al., "iSCSI naming and Discovery", draft- 4049 ietf-ips-iscsi-name-disc-03.txt, November 2001 4051 [iSCSI-SLP] Bakke, M., "Finding iSCSI Targets and Name Servers Using 4052 SLP", Internet draft (work in progress), draft-ietf-ips- 4053 iscsi-slp-01.txt, July 2001 4055 [RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate 4056 Requirement Levels, BCP 14, RFC 2119, March 1997 4058 [SEC-IPS] Aboba, B., et al., "Securing IP Block Storage 4059 Protocols", draft-ietf-ips-security-07.txt, December 4060 2001 4062 [RFC2401] Atkinson, R., Kent, S., "Security Architecture for the 4063 Internet Protocol", RFC 2401, November 1998 4065 [RFC2406] Kent, S., Atkinson, R., "IP Encapsulating Security 4066 Payload (ESP)", RFC 2406, November 1998 4068 [RFC2407] Piper, D., "The Internet IP Security Domain of 4069 Interpretation of ISAKMP", RFC 2407, November 1998 4071 [RFC2408] Maughan, D., Schertler, M., Schneider, M., Turner, J., 4072 "Internet Security Association and Key Management 4073 Protocol (ISAKMP), RFC 2408, November 1998 4075 [RFC2409] Harkins, D., Carrel, D., "The Internet Key Exchange 4076 (IKE)", RFC 2409, November 1998 4078 [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 4079 2412, November 1998 4081 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 4082 793, September 1981 4084 [DSS] FIPS PUB 186-2, National Institute of Standards and 4085 Technology, Digital Signature Standard (DSS), Technical 4086 Report 4087 Internet Storage Name Service (iSNS) February 2002 4089 [EUI-64] Guidelines for 64-bit Global Identifier (EUI-64) 4090 Registration Authority, May 2001, IEEE, 4091 http://standards.ieee.org/regauth/oui/tutorials/EUI64.ht 4092 ml 4094 [802-1990] IEEE Standards for Local and Metropolitan Area Networks: 4095 Overview and Architecture, Technical Committee on 4096 Computer Communications of the IEEE Computer Society, 4097 May 31, 1990 4099 [FC-FS] Fibre Channel Framing and Signaling Interface, NCITS 4100 Working Draft Project 1331-D 4102 10. Informative References 4104 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 4105 Specification, RFC 1035, November 1987 4107 [RFC1305] Mills, D., Network Time Protocol (Version 3), RFC 1305, 4108 March 1992 4110 [FC-GS] Fibre Channel Generic Services, ANSI X3.288:1996 4112 [FC-GS-2] Fibre Channel Generic Services-2, ANSI NCITS 288 4114 [FC-GS-3] Fibre Channel Generic Services-3, NCITS 348-2000 4116 [FC-GS-4] Fibre Channel Generic Services-4, NCITS Working Draft 4117 Project 1505-D 4119 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 4120 3", BCP 9, RFC 2026, October 1996. 4122 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 4123 Requirement Levels", BCP 14, RFC 2119, March 1997 4124 Internet Storage Name Service (iSNS) November 2001 4126 11. Author's Addresses 4128 Josh Tseng 4129 Kevin Gibbons 4130 Charles Monia 4131 Nishan Systems 4132 3850 North First Street 4133 San Jose, CA 95134-1702 4134 Phone: (408) 519-3749 4135 Email: jtseng@nishansystems.com 4137 Franco Travostino 4138 Nortel Networks 4139 3 Federal Street 4140 Billerica, MA 01821 4141 Phone: 978-288-7708 4142 Email: travos@nortelnetworks.com 4144 Tom McSweeney 4145 Curt Du Laney 4146 John Dowdy 4147 IBM 4148 4205 South Miami Blvd 4149 Research Triangle Park, NC 27709 4150 Email: jdowdy@us.ibm.com 4151 Phone: (919) 254-5632 4153 Chad Gregory 4154 505 E. Huntland Drive, Suite 550 4155 Austin, TX 78752 4156 Email: chad.gregory@intel.com 4157 Phone: (512) 407-2137 4158 Internet Storage Name Service (iSNS) November 2001 4160 Full Copyright Statement 4162 "Copyright (C) The Internet Society (date). All Rights Reserved. 4163 This document and translations of it may be copied and furnished to 4164 others, and derivative works that comment on or otherwise explain it 4165 or assist in its implementation may be prepared, copied, published 4166 and distributed, in whole or in part, without restriction of any 4167 kind, provided that the above copyright notice and this paragraph 4168 are included on all such copies and derivative works. However, this 4169 document itself may not be modified in any way, such as by removing 4170 the copyright notice or references to the Internet Society or other 4171 Internet organizations, except as needed for the purpose of 4172 developing Internet standards in which case the procedures for 4173 copyrights defined in the Internet Standards process must be 4174 followed, or as required to translate it into languages other than 4175 English. 4177 The limited permissions granted above are perpetual and will not be 4178 revoked by the Internet Society or its successors or assigns. 4180 This document and the information contained herein is provided on an 4181 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4182 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4183 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 4184 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 4185 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 4186 Internet Storage Name Service (iSNS) November 2001 4188 Appendix A -- iSNS Examples 4190 A.1 iSCSI Initialization Example 4192 This example assumes an SLP Service Agent (SA) has been implemented 4193 on the iSNS host, and an SLP User Agent (UA) has been implemented on 4194 the iSNS initiator. See [RFC2608] for further details on SA's and 4195 UA's. This example also assumes the target is configured to use the 4196 iSNS, and have its access control policy subordinated to the iSNS. 4198 A.1.1 Simple iSCSI Target Registration 4200 In this example, a simple target with a single iSCSI name registers 4201 with the iSNS. The target has not been assigned a Fully Qualified 4202 Domain Name (FQDN) by the administrator. 4204 +--------------------------+------------------+-------------------+ 4205 | iSCSI Target Device | iSNS |Management Station | 4206 +--------------------------+------------------+-------------------+ 4207 |Discover iSNS--SLP------->| |/*mgmt station is | 4208 | |<--SLP--iSNS Here:| administratively | 4209 | | 192.36.53.1 | authorized to view| 4210 | | | all DD's. Device | 4211 | | | NAMEabcd has been | 4212 | RegDevAttr--------->| | previously placed | 4213 |Oper Attrs: | | into DDabcd******/| 4214 |tag=1: NULL | | | 4215 |tag=2: "iSCSI" | | | 4216 |tag=16: "192.36.4.5" | | | 4217 |tag=17: "5001" | | | 4218 |tag=19: 0 | | | 4219 |tag=32: "NAMEabcd" | | | 4220 |tag=33: "target" | | | 4221 |tag=34: "disk 1" | | | 4222 | |<---RegDevAttrRsp | | 4223 | |SUCCESS | | 4224 | |tag=1: "iSNS:0001"| | 4225 | |tag=16: "192.36.4.5" | 4226 | |tag=17: "5001" | | 4227 | |tag=32: "NAMEabcd"| | 4228 | | | | 4229 | DevAttrQry--------->| SCN-------->| | 4230 |Src:(tag=32) "NAMEabcd" |(or SNMP trap) | | 4231 |Key:(tag=2) "iSCSI" |tag=1: "iSNS:0001" | 4232 |Key:(tag=33) "initiator" |dest: "mgmt.foo.com" | 4233 |Oper Attrs: |CHANGE IN NETWORK | | 4234 |tag=16: NULL | | | 4235 |tag=17: NULL | |<-------SCNRsp | 4236 |tag=32: NULL | | | 4237 |/*Query asks for all iSCSI| | | 4238 |devices' IP address, port |<---DevAttrQryRsp | | 4239 |number, and Name*/ |SUCCESS | | 4240 | |tag=16:"192.36.4.1" | 4241 | |tag=17:"50000" | | 4242 Internet Storage Name Service (iSNS) November 2001 4244 | |tag=32:"devpdq" | | 4245 | |tag=16:"192.1.3.2"|<-----DevAttrQry | 4246 | |tag=17:"50000" |src: �MGMTname1� | 4247 | |tag=32:"devrst" |key:(tag=1)iSNS:0001 4248 | | |Op Attrs: | 4249 |/*************************| |tag=16: NULL | 4250 |Our target "iSNS:0001" | |tag=17: NULL | 4251 |discovers two initiators | |tag=32: NULL | 4252 |in the same DD. It will | | | 4253 |accept iSCSI logins from | | | 4254 |these two identified | | | 4255 |initiators presented by | | | 4256 |iSNS*********************/| DevAttrQryRsp--->| | 4257 | |SUCCESS | | 4258 | |tag=16: 192.36.4.5| | 4259 | |tag=17: 5001 | | 4260 | |tag=32: NAMEabcd | | 4261 +--------------------------+------------------+-------------------+ 4263 A.1.2 Target Registration and DD Configuration 4265 In this example, a more complex target registers with the iSNS. 4266 This target has been configured with a Fully Qualified Domain Name 4267 (FQDN) in the DNS servers, and the user wishes to use this 4268 identifier for the device. Also, the user wishes to use public key 4269 certificates in the iSCSI login authentication. 4271 +--------------------------+------------------+-------------------+ 4272 | iSCSI Target Device | iSNS |Management Station | 4273 +--------------------------+------------------+-------------------+ 4274 |Discover iSNS--SLP--> | |/*mgmt station is | 4275 | |<--SLP--iSNS Here:| administratively | 4276 | | 192.36.53.1 | authorized to view| 4277 | RegDevAttr--> | | all DD's ********/| 4278 |Oper Attrs: | | | 4279 |tag=1: "jbod1.foo.com" | | | 4280 |tag=2: "iSCSI" | | | 4281 |tag=16: "192.36.34.4" | | | 4282 |tag=17: "5001" | | | 4283 |tag=19: "5 seconds" | | | 4284 |tag=16: "192.36.53.5" | | | 4285 |tag=17: "5001" | | | 4286 |tag=32: "NAMEabcd" | | | 4287 |tag=33: "Target" |/*****************| | 4288 |tag=34: "Storage Array 1" |jbod1.foo.com is | | 4289 |tag=43: X.509 cert |now registered in | | 4290 |tag=32: "NAMEefgh" |iSNS, but is not | | 4291 |tag=33: "Target" |in any DD. Therefore, | 4292 |tag=34: "Storage Array 2" |no other devices | | 4293 |tag=43: X.509 cert |can "see" it. | | 4294 | |*****************/| | 4295 | |<--RegDevAttrRsp | | 4296 | |SUCCESS | | 4297 Internet Storage Name Service (iSNS) November 2001 4299 | |tag=1: "jbod1.foo.com" | 4300 | |tag=16: "192.36.34.4" | 4301 | |tag=17: "5001" | | 4302 | |tag=16: "192.36.53.5" | 4303 | |tag=17: "5001" | | 4304 | |tag=32: "NAMEabcd"| | 4305 | |tag=32: "NAMEefgh"| | 4306 | | | | 4307 | | SCN------> | | 4308 | | (or SNMP trap) | | 4309 | |tag=1: jbod1.foo.com | 4310 | |dest: mgmt.foo.com| | 4311 | |CHANGE IN NETWORK | | 4312 | | | | 4313 | | |<--SCNRsp | 4314 | | |<--DevAttrQry | 4315 | | |src: mgmt.foo.com | 4316 | | |key: (tag=1) | 4317 | | | jbod1.foo.com | 4318 | | |Op Attr: (tag=2) | 4319 | | |Op Attr: (tag=16) | 4320 | | |Op Attr: (tag=17) | 4321 | | |Op Attr: (tag=32) | 4322 | | | | 4323 | | DevAttrQryRsp--> | | 4324 | |SUCCESS | | 4325 | |tag=2: "iSCSI" | | 4326 | |tag=16: 192.36.34.4 | 4327 | |tag=17: 5001 | | 4328 | |tag=16: 192.36.53.5 | 4329 | |tag=17: 5001 |/**Mgmt Station ***| 4330 | |tag=32:"NAMEabcd" |displays device, | 4331 | |tag=32:"NAMEefgh" |the operator decides 4332 | | |to place "NAMEabcd"| 4333 | | |into Domain "DDxyz"| 4334 |/*************************| |******************/| 4335 |Target is now registered | | | 4336 |in iSNS. It has been placed |<--DDReg | 4337 |in DDxyz by management | |src: "mgmt.foo.com"| 4338 |station. | |key: "DDxyz ID" | 4339 |*************************/| |Op Attr: | 4340 | | |tag=32: "NAMEabcd" | 4341 | | DDRegRsp----->| | 4342 | | SUCCESS | | 4343 +--------------------------+------------------+-------------------+ 4345 A.1.3 Initiator Registration and Target Discovery 4347 The following example illustrates a new initiator registering with 4348 the iSNS, and discovering the target NAMEabcd from the example in 4349 A.1.2. 4351 Internet Storage Name Service (iSNS) November 2001 4353 +--------------------------+------------------+-------------------+ 4354 | iSCSI Initiator | iSNS |Management Station | 4355 +--------------------------+------------------+-------------------+ 4356 |Discover iSNS--SLP--> | |/*mgmt station is | 4357 | |<--SLP--iSNS Here:| administratively | 4358 | | 192.36.53.1 | authorized to view| 4359 |RegDevAttr--> | | all DD's ********/| 4360 |Oper Attrs: | | | 4361 |tag=1: "svr1.foo.com" | | | 4362 |tag=2: "iSCSI" | | | 4363 |tag=16: "192.20.3.1" |/*****************| | 4364 |tag=17: "5001" |Device not in any | | 4365 |tag=19: 5 seconds |DD, so it is | | 4366 |tag=32: "NAMEijkl" |inaccessible by | | 4367 |tag=33: "Initiator" |other devices | | 4368 |tag=34: "Server1" |*****************/| | 4369 |tag=43: X.509 certificate | | | 4370 | |<--RegDevAttrRsp | | 4371 | |SUCCESS | | 4372 | |tag=1: "svr1.foo.com" | 4373 | |tag=16: "192.20.3.1" | 4374 | |tag=17: "5001" | | 4375 | |tag=32: "NAMEijkl"| | 4376 | | | | 4377 | | SCN------> | | 4378 | | (or SNMP trap) | | 4379 | |tag=1: svr1.foo.com | 4380 | |dest: mgmt.foo.com| | 4381 | |CHANGE IN NETWORK | | 4382 | | | | 4383 | | |<------SCNRsp | 4384 | | |<----DevAttrQry | 4385 | | |src: mgmt.foo.com | 4386 | | |key: (tag=1) | 4387 | | | svr1.foo.com | 4388 | | |Op Attr: (tag=2) | 4389 | | |Op Attr: (tag=16) | 4390 | | |Op Attr: (tag=17) | 4391 | | |Op Attr: (tag=32) | 4392 | | DevAttrQryRsp--> | | 4393 | |SUCCESS | | 4394 | |tag=2: "iSCSI" | | 4395 | |tag=16:192.20.3.1 | | 4396 | |tag=17: "5001" | | 4397 | |tag=32:"NAMEijkl" | | 4398 | | |/**Mgmt Station ***| 4399 | | |displays device, | 4400 | | |the operator decides 4401 | | |to place "NAMEijkl"| 4402 | | |into Domain "DDxyz"| 4403 | | |with device NAMEabcd 4404 | | |******************/| 4405 | | |<--DDReg | 4406 | | |src: (tag=1) | 4407 Internet Storage Name Service (iSNS) November 2001 4409 | | | "mgmt.foo.com" | 4410 | | |key: "DDxyz ID" | 4411 | | |tag=32: "NAMEijkl | 4412 | | | | 4413 | | DDRegRsp---->|/******************| 4414 | | SUCCESS |"NAMEijkl" has been| 4415 | | |moved to "DDxyz" | 4416 | | |******************/| 4417 | |<-----SCN | | 4418 | |tag=32: "NAMEijkl"| | 4419 | |CHANGE IN DD MEMBERSHIP | 4420 | DevAttrQry----------->| | | 4421 |src: "NAMEabcd" |/*****************| | 4422 |key:(tag=2) "iSCSI" |Note that NAMEabcd| | 4423 |key:(tag=33) "Target" |also receives an | | 4424 |Op Attr: (tag=16) |SCN that NAMEijkl | | 4425 |Op Attr: (tag=17) |is in the same DD | | 4426 |Op Attr: (tag=32) |*****************/| | 4427 |Op Attr: (tag=34) | | | 4428 |Op Attr: (tag=43) |<-----AttrQryRsp | | 4429 | |SUCCESS | | 4430 | |tag=16: 192.36.34.4 | 4431 | |tag=17: 5001 | | 4432 | |tag=16: 192.36.53.5 | 4433 | |tag=17: 5001 | | 4434 | |tag=32: NAMEabcd | | 4435 | |tag=34: Volume 1 | | 4436 | |tag=43: X.509 cert| | 4437 | | | | 4438 |/***The initiator has discovered | | 4439 |the target, and has everything | | 4440 |needed to complete iSCSI login | | 4441 |The same process occurs on the | | 4442 |target side; the SCN prompts the | | 4443 |target to download the list of | | 4444 |authorized initiators from the | | 4445 |iSNS (i.e., those initiators in the | | 4446 |same DD as the target.************/ | | 4447 +--------------------------+------------------+-------------------+