idnits 2.17.1 draft-ietf-ips-isns-22.txt: 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: ---------------------------------------------------------------------------- == There is 1 instance 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 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: Upon receiving the DevDereg, the iSNS server removes all objects identified by the Operating Attribute(s), as well as all associated subordinate objects that are solely dependent on those identified objects. For example, removal of a Network Entity also results in removal of all associated Portal, Portal Group, Storage Node, and FC Device objects associated with that Network Entity. FC Device objects SHALL not be deregistered in this manner unless all Storage Nodes associated with them have been deregistered. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: Attempted deregistration of non-existing entries SHALL not be considered an error. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: The attempted deregistration of non-existent DD entries SHALL not be considered an error. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: The attempted deregistration of non-existent DDS entries SHALL not be considered an error. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: In the event of an error, this response message contains the appropriate status code as well as a list of objects from the original DevDereg message that were not successfully deregistered from the iSNS database. This list of objects is contained in the Operating Attributes of the DevDeregRsp message. Note that an attempted deregistration of a non-existent object does not constitute an error, and non-existent entries SHALL not be returned in the DevDeregRsp message. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: The Message Key in the DDRegRsp message SHALL return the Message Key in the original query message. If the original DDReg message did not have a Message Key, then the DDRegRsp message SHALL not have a Message Key. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: The Message Key in the DDSRegRsp message SHALL contain the Message Key of the original DDSReg message. If the original DDSReg message did not have a Message Key, then the DDSRegRsp message SHALL not have a Message Key. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: Once a FC_DOMAIN_ID value is allocated by the iSNS server, it SHALL not be reused until it has been deallocated by the iSNS client to which the value was assigned, or the ESI message detects that the iSNS client no longer exists on the network. -- 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 (February 2004) is 7368 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: 'RFC2119' is mentioned on line 5239, but not defined == Missing Reference: 'RFC2608' is mentioned on line 5455, but not defined == Missing Reference: 'RFC 2608' is mentioned on line 1239, but not defined == Missing Reference: 'RFC3279' is mentioned on line 5286, but not defined -- Looks like a reference, but probably isn't: '1' on line 3150 -- Looks like a reference, but probably isn't: '2' on line 3152 -- Looks like a reference, but probably isn't: '3' on line 3154 == Missing Reference: 'STRINGPREP' is mentioned on line 5246, but not defined == Missing Reference: 'NAMEPREP' is mentioned on line 5250, but not defined == Missing Reference: 'RFC2373' is mentioned on line 4571, but not defined ** Obsolete undefined reference: RFC 2373 (Obsoleted by RFC 3513) == Missing Reference: 'RFC2408' is mentioned on line 5262, but not defined ** Obsolete undefined reference: RFC 2408 (Obsoleted by RFC 4306) == Missing Reference: 'RFC3280' is mentioned on line 5291, but not defined ** Obsolete undefined reference: RFC 3280 (Obsoleted by RFC 5280) == Missing Reference: 'FC-FS' is mentioned on line 5300, but not defined == Missing Reference: 'EUI-64' is mentioned on line 5283, but not defined == Missing Reference: '802-1990' is mentioned on line 5295, but not defined == Missing Reference: 'RFC2407' is mentioned on line 5259, but not defined ** Obsolete undefined reference: RFC 2407 (Obsoleted by RFC 4306) == Missing Reference: 'RFC2409' is mentioned on line 5267, but not defined ** Obsolete undefined reference: RFC 2409 (Obsoleted by RFC 4306) == Missing Reference: 'SEC-IPS' is mentioned on line 5242, but not defined == Missing Reference: 'RFC2401' is mentioned on line 5253, but not defined ** Obsolete undefined reference: RFC 2401 (Obsoleted by RFC 4301) == Missing Reference: 'RFC2406' is mentioned on line 5256, but not defined ** Obsolete undefined reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) == Missing Reference: 'RFC2412' is mentioned on line 5270, but not defined == Missing Reference: 'RFC793' is mentioned on line 5273, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) == Missing Reference: 'RFC3513' is mentioned on line 5276, but not defined ** Obsolete undefined reference: RFC 3513 (Obsoleted by RFC 4291) == Missing Reference: 'DSS' is mentioned on line 5279, but not defined == Unused Reference: 'RFC1035' is defined on line 5317, but no explicit reference was found in the text == Unused Reference: 'RFC1305' is defined on line 5321, but no explicit reference was found in the text == Unused Reference: 'FC-GS-3' is defined on line 5324, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 5329, but no explicit reference was found in the text == Unused Reference: 'RFC1510' is defined on line 5332, but no explicit reference was found in the text == Unused Reference: 'RFC2025' is defined on line 5335, but no explicit reference was found in the text == Unused Reference: 'RFC2945' is defined on line 5342, but no explicit reference was found in the text == Unused Reference: 'RFC1994' is defined on line 5345, but no explicit reference was found in the text == Unused Reference: 'RFC2131' is defined on line 5348, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 1510 (Obsoleted by RFC 4120, RFC 6649) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 12 errors (**), 0 flaws (~~), 42 warnings (==), 10 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 McDATA Corporation 5 Standards Track 6 Expires August 2004 Franco Travostino 7 Nortel Networks 9 Curt Du Laney 10 IBM 12 Joe Souza 13 Microsoft 15 February 2004 17 Internet Storage Name Service (iSNS) 19 Status of this Memo 21 This document is an Internet-Draft and is subject to all provisions 22 of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Copyright Notice 42 Copyright (C) The Internet Society (2003). All Rights Reserved. 44 Abstract 46 This document specifies the Internet Storage Name Service (iSNS) 47 protocol, used for interaction between iSNS servers and iSNS 48 clients, which facilitates automated discovery, management, and 49 configuration of iSCSI and Fibre Channel devices (using iFCP 50 gateways) on a TCP/IP network. iSNS provides intelligent storage 51 discovery and management services comparable to those found in Fibre 52 Channel networks, allowing a commodity IP network to function in a 53 Internet Storage Name Service (iSNS) February 2004 55 similar capacity as a storage area network. iSNS facilitates a 56 seamless integration of IP and Fibre Channel networks due to its 57 ability to emulate Fibre Channel fabric services and manage both 58 iSCSI and Fibre Channel devices. iSNS thereby provides value in any 59 storage network comprised of iSCSI devices, Fibre Channel devices 60 (using iFCP gateways), or any combination thereof. 62 Acknowledgements 64 Numerous individuals contributed to the creation of this draft 65 through their careful review and submissions of comments and 66 recommendations. We acknowledge the following persons for their 67 technical contributions to this document: Mark Bakke (Cisco), John 68 Hufferd (IBM), Julian Satran (IBM), Kaladhar Voruganti(IBM), Joe 69 Czap (IBM), John Dowdy (IBM), Tom McSweeney (IBM), Jim Hafner (IBM), 70 Chad Gregory (Intel), Yaron Klein (Sanrad), Larry Lamers (Adaptec), 71 Jack Harwood (EMC), David Black (EMC), David Robinson (Sun), Alan 72 Warwick (Microsoft), Bob Snead (Microsoft), Fa Yoeu (Intransa), Joe 73 White (McDATA), Charles Monia (McDATA), Larry Hofer (McDATA), Ken 74 Hirata (Vixel), Howard Hall (Pirus), Malikarjun Chadalapaka (HP), 75 Marjorie Krueger (HP), Siva Vaddepuri (McDATA), and Vinai Singh 76 (American Megatrends). 78 Internet Storage Name Service (iSNS) February 2004 80 Table of Contents 82 Status of this Memo............................................ 1 83 Copyright Notice............................................... 1 84 Abstract....................................................... 1 85 Acknowledgements............................................... 2 86 1. About this Document...................................... 7 87 1.1 Conventions Used in this Document........................ 7 88 1.2 Purpose of this Document................................. 7 89 2. Introduction - iSNS Overview............................. 7 90 2.1 iSNS Architectural Components ........................... 8 91 2.1.1 iSNS Protocol (iSNSP) ................................... 8 92 2.1.2 iSNS Client.............................................. 8 93 2.1.3 iSNS Server.............................................. 8 94 2.1.4 iSNS Database ........................................... 8 95 2.1.5 iSCSI.................................................... 8 96 2.1.6 iFCP..................................................... 8 97 2.2 iSNS Functional Overview................................. 8 98 2.2.1 Name Registration Service................................ 9 99 2.2.2 Discovery Domain and Login Control Service............... 9 100 2.2.3 State Change Notification Service....................... 10 101 2.2.4 Open Mapping Between Fibre Channel and iSCSI Devices ... 11 102 2.3 iSNS Usage Model........................................ 12 103 2.3.1 iSCSI Initiator......................................... 12 104 2.3.2 iSCSI Target............................................ 12 105 2.3.3 iSCSI-FC Gateway........................................ 12 106 2.3.4 iFCP Gateway............................................ 12 107 2.3.5 Management Station...................................... 13 108 2.4 Administratively Controlled iSNS Settings............... 13 109 2.5 iSNS Server Discovery .................................. 14 110 2.5.1 Service Location Protocol (SLP)......................... 14 111 2.5.2 Dynamic Host Configuration Protocol (DHCP).............. 14 112 2.5.3 iSNS Heartbeat Message.................................. 14 113 2.6 iSNS and Network Address Translation (NAT).............. 14 114 2.7 Transfer of iSNS Database Records between iSNS Servers.. 15 115 2.8 Backup iSNS Servers..................................... 17 116 2.9 Transport Protocols..................................... 19 117 2.9.1 Use of TCP For iSNS Communication....................... 19 118 2.9.2 Use of UDP For iSNS Communication....................... 19 119 2.9.3 iSNS Multicast and Broadcast Messages................... 19 120 2.10 Simple Network Management Protocol (SNMP) Requirements.. 20 121 3. iSNS Object Model....................................... 20 122 3.1 Network Entity Object .................................. 21 123 3.2 Portal Object .......................................... 21 124 3.3 Storage Node Object..................................... 21 125 3.4 Portal Group Object..................................... 21 126 3.5 FC Device Object........................................ 22 127 3.6 Discovery Domain Object................................. 22 128 3.7 Discovery Domain Set Object............................. 23 129 3.8 iSNS Database Model..................................... 23 130 4. iSNS Implementation Requirements........................ 24 131 4.1 iSCSI Requirements...................................... 24 132 4.1.1 Required Attributes for Support of iSCSI................ 24 133 4.1.2 Example iSCSI Object Model Diagrams..................... 26 134 Internet Storage Name Service (iSNS) February 2004 136 4.1.3 Required Commands and Response Messages for Support of iSCSI. 28 137 4.2 iFCP Requirements....................................... 29 138 4.2.1 Required Attributes for Support of iFCP................. 29 139 4.2.2 Example iFCP Object Model Diagram....................... 30 140 4.2.3 Required Commands and Response Messages for Support of iFCP. 31 141 5. iSNSP Message Format.................................... 33 142 5.1 iSNSP PDU Header........................................ 33 143 5.1.1 iSNSP Version .......................................... 33 144 5.1.2 iSNSP Function ID....................................... 33 145 5.1.3 iSNSP PDU Length........................................ 33 146 5.1.4 iSNSP Flags............................................. 34 147 5.1.5 iSNSP Transaction ID.................................... 34 148 5.1.6 iSNSP Sequence ID....................................... 34 149 5.2 iSNSP Message Segmentation and Reassembly............... 34 150 5.3 iSNSP PDU Payload....................................... 34 151 5.3.1 Attribute Value 4-Byte Alignment........................ 35 152 5.4 iSNSP Response Status Codes............................. 35 153 5.5 Authentication for iSNS Multicast and Broadcast Messages 36 154 5.6 Registration and Query Messages......................... 37 155 5.6.1 Source Attribute........................................ 38 156 5.6.2 Message Key Attributes.................................. 39 157 5.6.3 Delimiter Attribute..................................... 39 158 5.6.4 Operating Attributes.................................... 39 159 5.6.5 Registration and Query Request Message Types ........... 40 160 5.7 Response Messages....................................... 59 161 5.7.1 Status Code............................................. 60 162 5.7.2 Message Key Attributes in Response...................... 60 163 5.7.3 Delimiter Attribute in Response......................... 60 164 5.7.4 Operating Attributes in Response........................ 60 165 5.7.5 Registration and Query Response Message Types........... 61 166 5.8 Vendor Specific Messages................................ 65 167 6. iSNS Attributes......................................... 66 168 6.1 iSNS Attribute Summary.................................. 66 169 6.2 Entity Identifier-Keyed Attributes...................... 68 170 6.2.1 Entity Identifier (EID)................................. 68 171 6.2.2 Entity Protocol......................................... 69 172 6.2.3 Management IP Address .................................. 69 173 6.2.4 Entity Registration Timestamp .......................... 70 174 6.2.5 Protocol Version Range.................................. 70 175 6.2.6 Registration Period..................................... 70 176 6.2.7 Entity Index............................................ 71 177 6.2.8 Entity Next Index....................................... 71 178 6.2.9 Entity ISAKMP Phase-1 Proposals......................... 71 179 6.2.10 Entity Certificate..................................... 72 180 6.3 Portal-Keyed Attributes................................. 72 181 6.3.1 Portal IP Address....................................... 72 182 6.3.2 Portal TCP/UDP Port..................................... 72 183 6.3.3 Portal Symbolic Name.................................... 72 184 6.3.4 Entity Status Inquiry Interval.......................... 73 185 6.3.5 ESI Port................................................ 73 186 6.3.6 Portal Index............................................ 74 187 6.3.7 SCN Port................................................ 74 188 6.3.8 Portal Next Index....................................... 74 189 6.3.9 Portal Security Bitmap.................................. 75 190 Internet Storage Name Service (iSNS) February 2004 192 6.3.10 Portal ISAKMP Phase-1 Proposals........................ 75 193 6.3.11 Portal ISAKMP Phase-2 Proposals........................ 75 194 6.3.12 Portal Certificate..................................... 76 195 6.4 iSCSI Node-Keyed Attributes............................. 76 196 6.4.1 iSCSI Name.............................................. 76 197 6.4.2 iSCSI Node Type......................................... 76 198 6.4.3 iSCSI Node Alias........................................ 77 199 6.4.4 iSCSI Node SCN Bitmap .................................. 77 200 6.4.5 iSCSI Node Index........................................ 78 201 6.4.6 WWNN Token.............................................. 79 202 6.4.7 iSCSI Node Next Index .................................. 80 203 6.4.8 iSCSI AuthMethod........................................ 80 204 6.5 Portal Group (PG) Object-Keyed Attributes............... 80 205 6.5.1 Portal Group iSCSI Name................................. 81 206 6.5.2 PG Portal IP Addr....................................... 81 207 6.5.3 PG Portal TCP/UDP Port.................................. 81 208 6.5.4 Portal Group Tag (PGT).................................. 81 209 6.5.5 Portal Group Index...................................... 81 210 6.5.6 Portal Group Next Index................................. 81 211 6.6 FC Port Name-Keyed Attributes .......................... 82 212 6.6.1 FC Port Name (WWPN)..................................... 82 213 6.6.2 Port ID (FC_ID)......................................... 82 214 6.6.3 FC Port Type............................................ 82 215 6.6.4 Symbolic Port Name...................................... 83 216 6.6.5 Fabric Port Name (FWWN)................................. 83 217 6.6.6 Hard Address............................................ 83 218 6.6.7 Port IP Address......................................... 83 219 6.6.8 Class of Service (COS).................................. 83 220 6.6.9 FC-4 Types.............................................. 83 221 6.6.10 FC-4 Descriptor........................................ 83 222 6.6.11 FC-4 Features ......................................... 84 223 6.6.12 iFCP SCN Bitmap........................................ 84 224 6.6.13 Port Role.............................................. 84 225 6.6.14 Permanent Port Name (PPN).............................. 85 226 6.7 Node-Keyed Attributes .................................. 85 227 6.7.1 FC Node Name (WWNN)..................................... 85 228 6.7.2 Symbolic Node Name...................................... 85 229 6.7.3 Node IP Address......................................... 85 230 6.7.4 Node IPA................................................ 86 231 6.7.5 Proxy iSCSI Name........................................ 86 232 6.8 Other Attributes........................................ 86 233 6.8.1 FC-4 Type Code.......................................... 86 234 6.8.2 iFCP Switch Name........................................ 86 235 6.8.3 iFCP Transparent Mode Commands.......................... 86 236 6.9 iSNS Server-Specific Attributes......................... 87 237 6.9.1 iSNS Server Vendor OUI.................................. 87 238 6.10 Vendor-Specific Attributes.............................. 87 239 6.10.1 Vendor-Specific Server Attributes...................... 88 240 6.10.2 Vendor-Specific Entity Attributes...................... 88 241 6.10.3 Vendor-Specific Portal Attributes...................... 88 242 6.10.4 Vendor-Specific iSCSI Node Attributes.................. 88 243 6.10.5 Vendor-Specific FC Port Name Attributes................ 88 244 6.10.6 Vendor-Specific FC Node Name Attributes................ 88 245 6.10.7 Vendor-Specific Discovery Domain Attributes............ 89 246 Internet Storage Name Service (iSNS) February 2004 248 6.10.8 Vendor-Specific Discovery Domain Set Attributes........ 89 249 6.10.9 Other Vendor-Specific Attributes....................... 89 250 6.11 Discovery Domain Registration Attributes................ 89 251 6.11.1 DD Set ID Keyed Attributes............................. 89 252 6.11.2 DD ID Keyed Attributes................................. 90 253 7. Security Considerations................................. 92 254 7.1 iSNS Security Threat Analysis .......................... 92 255 7.2 iSNS Security Implementation and Usage Requirements..... 93 256 7.3 Discovering Security Requirements of Peer Devices....... 94 257 7.4 Configuring Security Policies of iFCP/iSCSI Devices..... 95 258 7.5 Resource Issues......................................... 95 259 7.6 iSNS Interaction with IKE and IPSec..................... 96 260 8. IANA Considerations..................................... 96 261 8.1 Registry of Block Storage Protocols..................... 96 262 8.2 Registry of Standard iSNS Attributes ................... 96 263 8.3 Block Structure Descriptor (BSD) Registry............... 97 264 9. Normative References.................................... 98 265 10. Informative References.................................. 99 266 11. Author's Addresses..................................... 101 267 Full Copyright Statement..................................... 102 268 Notice of Intellectual Property Rights ...................... 102 269 Appendix A -- iSNS Examples.................................. 103 270 A.1 iSCSI Initialization Example........................... 103 271 A.1.1 Simple iSCSI Target Registration....................... 103 272 A.1.2 Target Registration and DD Configuration............... 104 273 A.1.3 Initiator Registration and Target Discovery............ 107 274 Internet Storage Name Service (iSNS) February 2004 276 1. About this Document 278 1.1 Conventions Used in this Document 280 "iSNS� refers to the storage network model and associated services 281 covered in the text of this document. 283 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 284 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 285 document are to be interpreted as described in [RFC2119]. 287 All frame formats are in big endian network byte order. 289 All unused fields and bitmaps, including those that are RESERVED, 290 SHOULD be set to zero when sending and ignored when receiving. 292 1.2 Purpose of this Document 294 This is a standards track document containing normative text 295 specifying the iSNS Protocol, used by iSCSI and iFCP devices to 296 communicate with the iSNS server. This document focuses on the 297 interaction between iSNS servers and iSNS clients; interactions 298 among multiple authoritative primary iSNS servers are a potential 299 topic for future work. 301 2. Introduction - iSNS Overview 303 iSNS facilitates scalable configuration and management of iSCSI and 304 Fibre Channel (FCP) storage devices in an IP network, by providing a 305 set of services comparable to that available in Fibre Channel 306 networks. iSNS thus allows a commodity IP network to function at a 307 comparable level of intelligence to a Fibre Channel fabric. iSNS 308 allows the administrator to go beyond a simple device-by-device 309 management model, where each storage device is manually and 310 individually configured with its own list of known initiators and 311 targets. Using the iSNS, each storage device subordinates its 312 discovery and management responsibilities to the iSNS server. The 313 iSNS server thereby serves as the consolidated configuration point 314 through which management stations can configure and manage the 315 entire storage network, including both iSCSI and Fibre Channel 316 devices. 318 iSNS can be implemented to support iSCSI and/or iFCP protocols as 319 needed; an iSNS implementation MAY provide support for one or both 320 of these protocols as desired by the implementor. Implementation 321 requirements within each of these protocols are further discussed in 322 section 5. Use of iSNS is OPTIONAL for iSCSI, and REQUIRED for 323 iFCP. 325 Internet Storage Name Service (iSNS) February 2004 327 2.1 iSNS Architectural Components 329 2.1.1 iSNS Protocol (iSNSP) 331 The iSNS Protocol (iSNSP) is a flexible and lightweight protocol 332 that specifies how iSNS clients and servers communicate. It is 333 suitable for various platforms, including switches and targets as 334 well as server hosts. 336 2.1.2 iSNS Client 338 iSNS clients initiate transactions with iSNS servers using the 339 iSNSP. iSNS clients are processes that are co-resident in the 340 storage device, and can register device attribute information, 341 download information about other registered clients in a common 342 Discovery Domain (DD), and receive asynchronous notification of 343 events that occur in their DD(s). Management stations are a special 344 type of iSNS client that have access to all DDs stored in the iSNS. 346 2.1.3 iSNS Server 348 iSNS servers respond to iSNS protocol queries and requests, and 349 initiate iSNS protocol State Change Notifications. Properly 350 authenticated information submitted by a registration request is 351 stored in an iSNS database. 353 2.1.4 iSNS Database 355 The iSNS database is the information repository for the iSNS 356 server(s). It maintains information about iSNS client attributes. 357 A directory-enabled implementation of iSNS may store client 358 attributes in an LDAP directory infrastructure. 360 2.1.5 iSCSI 362 iSCSI (Internet SCSI) is an encapsulation of SCSI for a new 363 generation of storage devices interconnected with TCP/IP [iSCSI]. 365 2.1.6 iFCP 367 iFCP (Internet FCP) is a gateway-to-gateway protocol designed to 368 interconnect existing Fibre Channel and SCSI devices using TCP/IP. 369 iFCP maps the existing FCP standard and associated Fibre Channel 370 services to TCP/IP [iFCP]. 372 2.2 iSNS Functional Overview 374 There are four main functions of the iSNS: 376 1) A Name Service Providing Storage Resource Discovery 378 2) Discovery Domain (DD) and Login Control Service 380 3) State Change Notification Service 381 Internet Storage Name Service (iSNS) February 2004 383 4) Open Mapping of Fibre Channel and iSCSI Devices 385 2.2.1 Name Registration Service 387 The iSNS provides a registration function to allow all entities in a 388 storage network to register and query the iSNS database. Both 389 targets and initiators can register in the iSNS database, as well as 390 query for information about other initiators and targets. This 391 allows, for example, a client initiator to obtain information about 392 target devices from the iSNS server. This service is modeled on the 393 Fibre Channel Generic Services Name Server described in FC-GS-4, 394 with extensions, operating within the context of an IP network. 396 The naming registration service also provides the ability to obtain 397 a network unique Domain ID for iFCP gateways when required. 399 2.2.2 Discovery Domain and Login Control Service 401 The Discovery Domain (DD) Service facilitates the partitioning of 402 Storage Nodes into more manageable groupings for administrative and 403 login control purposes. It allows the administrator to limit the 404 login process of each host to the more appropriate subset of targets 405 registered in the iSNS. This is particularly important to reduce 406 the number of unnecessary logins (iSCSI logins or Fibre Channel Port 407 Logins), and to limit the amount of time that the host spends 408 initializing login relationships as the size of the storage network 409 scales up. Storage Nodes must be in at least one common enabled DD 410 in order to obtain information about each other. Devices can be a 411 member of multiple DDs simultaneously. 413 Login Control allows targets to delegate their access 414 control/authorization policy to the iSNS server. This is consistent 415 with the goal of centralizing management of those storage devices 416 using the iSNS server. The target node or device downloads the list 417 of authorized initiators from the iSNS. Each node or device is 418 uniquely identified by an iSCSI Name or FC Port Name. Only 419 initiators that match the required identification and authorization 420 provided by the iSNS will be allowed access by that target Node 421 during session establishment. 423 Placing Portals of a Network Entity into Discovery Domains allows 424 administrators to indicate the preferred IP Portal interface through 425 which storage traffic should access specific Storage Nodes of that 426 Network Entity. If no Portals of a Network Entity have been placed 427 into a DD, then queries scoped to that DD SHALL report all Portals 428 of that Network Entity. If one or more Portals of a Network Entity 429 have been placed into a DD, then queries scoped to that DD SHALL 430 report only those Portals that have been explicitly placed in the 431 DD. 433 DDs can be managed offline through a separate management workstation 434 using the iSNSP or SNMP. If the target opts to use the Login 435 Control feature of the iSNS, the target delegates management of 436 access control policy (i.e., the list of initiators allowed to login 437 Internet Storage Name Service (iSNS) February 2004 439 to that target) to the management workstations that are managing the 440 configuration in the iSNS database. 442 If administratively authorized, a target can upload its own Login 443 Control list. This is accomplished using the DDReg message and 444 listing the iSCSI Name of each initiator to be registered in the 445 Target's DD. 447 An implementation MAY decide that newly registered devices that have 448 not explicitly been placed into a DD by the management station are 449 to be placed into a "default DD" contained in a "default DDS" whose 450 initial DD Set Status value is "enabled". This makes them visible 451 to other devices in the default DD. Other implementations MAY 452 decide that they are registered with no DD, making them inaccessible 453 to source-scoped iSNSP messages. 455 The iSNS server uses the Source Attribute of each iSNSP message to 456 determine the originator of the request and scope the operation to a 457 set of Discovery Domains. In addition, the Node Type (specified in 458 the iFCP or iSCSI Node Type bitmap field) may also be used to 459 determine authorization for the specified iSNS operation. For 460 example, only Control Nodes are authorized to create or delete 461 discovery domains. 463 Valid and active Discovery Domains (DDs) belong to at least one 464 active Discovery Domain Set (DDS). Discovery Domains that do not 465 belong to an activated DDS are not enabled. The iSNS server MUST 466 maintain the state of DD membership for all Storage Nodes, even for 467 those Storage Nodes that have been deregistered. DD membership is 468 persistent regardless of whether a Storage Node is actively 469 registered in the iSNS database. 471 2.2.3 State Change Notification Service 473 The State Change Notification (SCN) service allows the iSNS Server 474 to issue notifications about network events that affect the 475 operational state of Storage Nodes. The iSNS client may register for 476 notifications on behalf of its Storage Nodes for notification of 477 events detected by the iSNS Server. SCNs notify iSNS clients of 478 explicit or implicit changes to the iSNS database; they do not 479 necessarily indicate the state of connectivity to peer storage 480 devices in the network. The response of a storage device to receipt 481 of an SCN is implementation-specific; the policy for responding to 482 SCNs is outside of the scope of this document. 484 There are two types of SCN registrations: Regular registrations and 485 management registrations; management registrations result in 486 management SCNs, while regular registrations result in regular SCNs. 487 The type of registration and SCN message is indicated in the SCN 488 bitmap (see sections 6.4.4 and 6.6.12). 490 A regular SCN registration indicates that the Discovery Domain 491 Service SHALL be used to control the distribution of SCN messages. 492 Receipt of regular SCNs is limited to the discovery domains in which 493 Internet Storage Name Service (iSNS) February 2004 495 the SCN-triggering event takes place. Regular SCNs do not contain 496 information about discovery domains. 498 A management SCN registration can only by requested by Control 499 Nodes. Management SCNs resulting from management registrations are 500 not bound by the Discovery Domain service. Authorization to request 501 management SCN registrations may be administratively controlled. 503 The iSNS server SHOULD be implemented with sufficient hardware and 504 software resources needed to support the expected number of iSNS 505 clients. However, if resources are unexpectedly exhausted, then the 506 iSNS server MAY refuse SCN service by returning a SCN Registration 507 Rejected (Status Code 17). The rejection might occur in situations 508 where the network size or current number of SCN registrations, has 509 passed an implementation-specific threshold. A client not allowed 510 to register for SCNs may decide to monitor its sessions with other 511 storage devices directly. 513 The specific notification mechanism by which the iSNS server learns 514 of the events that trigger SCNs is implementation-specific, but can 515 include examples such as explicit notification messages from an iSNS 516 client to the iSNS server, or a hardware interrupt to a switch- 517 hosted iSNS server as a result of link failure. 519 2.2.4 Open Mapping Between Fibre Channel and iSCSI Devices 521 The iSNS database stores naming and discovery information about both 522 Fibre Channel and iSCSI devices. This allows the iSNS server to 523 store mappings of a Fibre Channel device to a proxy iSCSI device 524 "image" in the IP network. Similarly, mappings of an iSCSI device 525 to a "proxy WWN" can be stored under the WWNN Token field for that 526 iSCSI device. 528 Furthermore, through use of iSCSI-FC gateways, Fibre Channel-aware 529 management stations can interact with the iSNS server to retrieve 530 information about Fibre Channel devices, and use this information to 531 manage Fibre Channel devices as well as iSCSI devices. This allows 532 management functions such as Discovery Domains and State Change 533 Notifications to be seamlessly applied for both iSCSI and Fibre 534 Channel devices, facilitating integration of IP networks with Fibre 535 Channel devices and fabrics. 537 Note that Fibre Channel attributes are stored as iFCP attributes, 538 and the ability to store this information in the iSNS server is 539 useful even if the iFCP protocol is not implemented. In particular, 540 tag 101 can be used to store a "Proxy iSCSI Name" for Fibre Channel 541 devices registered in the iSNS server. This field is used to 542 associate the FC device with an iSCSI registration entry that is 543 used for the Fibre Channel device to communicate with iSCSI devices 544 in the IP network. Conversely, tag 37 (see section 6.1) contains a 545 WWNN Token field, which can be used to store an FC Node Name (WWNN) 546 value used by iSCSI-FC gateways to represent an iSCSI device in the 547 Fibre Channel domain. 549 Internet Storage Name Service (iSNS) February 2004 551 By storing the mapping between Fibre Channel and iSCSI devices in 552 the iSNS server, this information becomes open to any authorized 553 iSNS client wishing to retrieve and use this information. In many 554 cases, this provides advantages over storing this information 555 internally within an iSCSI-FC gateway, where the mapping is 556 inaccessible to other devices except by proprietary mechanisms. 558 2.3 iSNS Usage Model 560 The following is a high-level description of how each type of device 561 in a storage network can utilize iSNS. Each type of device 562 interacts with the iSNS server as an iSNS client, and must register 563 itself in the iSNS database in order to access services provided by 564 the iSNS. 566 2.3.1 iSCSI Initiator 568 An iSCSI initiator will query the iSNS server to discover the 569 presence and location of iSCSI target devices. It may also request 570 state change notifications (SCNs) so that it can be notified of new 571 targets that appear on the network after the initial bootup and 572 discovery. SCNs can also inform the iSCSI initiator of targets that 573 are removed or no longer available in the storage network, so that 574 incomplete storage sessions can be gracefully terminated and 575 resources for non-existent targets can be reallocated. 577 2.3.2 iSCSI Target 579 An iSCSI target allows itself to be discovered by iSCSI initiators 580 by registering its presence in the iSNS server. It may also 581 register for SCNs in order to detect the addition or removal of 582 initiators for resource allocation purposes. The iSCSI target 583 device may also register for Entity Status Inquiry (ESI) messages, 584 which allow the iSNS to monitor the target device's availability in 585 the storage network. 587 2.3.3 iSCSI-FC Gateway 589 An iSCSI-FC Gateway bridges devices in a Fibre Channel network to an 590 iSCSI/IP network. It may use the iSNS server to store FC device 591 attributes discovered in the FC name server, as well as mappings of 592 FC device identifiers to iSCSI device identifiers. iSNS has the 593 capability to store all attributes of both iSCSI and Fibre Channel 594 devices; iSCSI devices are managed through direct interaction using 595 iSNS, while FC devices can be indirectly managed through iSNS 596 interactions with the iSCSI-FC gateway. This allows both iSCSI and 597 Fibre Channel devices to be managed in a seamless management 598 framework. 600 2.3.4 iFCP Gateway 602 An iFCP Gateway uses iSNS to emulate the services provided by a 603 Fibre Channel name server for FC devices in its gateway region. 604 iSNS provides basic discovery and zoning configuration information 605 Internet Storage Name Service (iSNS) February 2004 607 to be enforced by the iFCP gateway. When queried, iSNS returns 608 information on the N_Port network address used to establish iFCP 609 sessions between FC devices supported by iFCP gateways. 611 2.3.5 Management Station 613 A management station uses iSNS to monitor storage devices and enable 614 or disable storage sessions by configuring discovery domains. A 615 management station usually interacts with the iSNS server as a 616 Control Node endowed with access to all iSNS database records and 617 special privileges to configure discovery domains. Through 618 manipulation of discovery domains, the management station controls 619 the scope of device discovery for iSNS clients querying the iSNS 620 server. 622 2.4 Administratively Controlled iSNS Settings 624 Some important operational settings for the iSNS server are 625 configured using administrative means, such as through a 626 configuration file, console port, SNMP, or other implementation- 627 specific method. These administratively controlled settings cannot 628 be configured using the iSNS Protocol, and therefore the iSNS server 629 implementation MUST provide for such an administrative control 630 interface. 632 The following is a list of parameters that are administratively 633 controlled for the iSNS server. In the absence of alternative 634 settings provided by the administrator, the following specified 635 default settings MUST be used. 637 Setting Default Setting 638 ------- --------------- 639 ESI Non-Response Threshold 3 (see 5.6.5.13) 640 Management SCNs (Control Nodes only) enabled (see 5.6.5.8) 641 Default DD/DDS disabled 642 DD/DDS Modification 643 - Control Node enabled 644 - iSCSI Target Node Type disabled 645 - iSCSI Initiator Node Type disabled 646 - iFCP Target Port Role disabled 647 - iFCP Initiator Port Role disabled 648 Authorized Control Nodes N/A 650 ESI Non-Response Threshold - determines the number of ESI messages 651 sent without receiving a response before the network entity is 652 deregistered from the iSNS database. 654 Management SCN for Control Node - determines whether a registered 655 Control Node is permitted to register to receive Management SCNs. 657 Default DD/DDS - determines whether a newly registered device not 658 explicitly placed into a discovery domain (DD) and discovery domain 659 set (DDS) is placed into a default DD/DDS. 661 Internet Storage Name Service (iSNS) February 2004 663 DD/DDS Modification - determines whether the specified type of Node 664 is allowed to add, delete or update DDs and DDSs. 666 Authorized Control Nodes - a list of Nodes identified by iSCSI Name 667 or FC Port Name WWPN that are authorized to register as Control 668 Nodes. 670 2.5 iSNS Server Discovery 672 2.5.1 Service Location Protocol (SLP) 674 The Service Location Protocol (SLP) provides a flexible and scalable 675 framework for providing hosts with access to information about the 676 existence, location, and configuration of networked services, 677 including the iSNS server. SLP can be used by iSNS clients to 678 discover the IP address or FQDN of the iSNS server. To implement 679 discovery through SLP, a Service Agent (SA) should be cohosted in 680 the iSNS server, and a User Agent (UA) should be in each iSNS 681 client. Each client multicasts a discovery message requesting the IP 682 address of the iSNS server(s). The SA responds to this request. 683 Optionally, the location of the iSNS server can be stored in the SLP 684 Directory Agent (DA). 686 Note that a complete description and specification of SLP can be 687 found in [RFC2608], and is beyond the scope of this document. A 688 service template for using SLP to locate iSNS servers can be found 689 in [iSCSI-SLP]. 691 2.5.2 Dynamic Host Configuration Protocol (DHCP) 693 The IP address of the iSNS server can be stored in a DHCP server to 694 be downloaded by iSNS clients using a DHCP option. The DHCP option 695 number to be used for distributing the iSNS server location is found 696 in [isnsoption]. 698 2.5.3 iSNS Heartbeat Message 700 The iSNS heartbeat message is described in section 5.6.5.14. It 701 allows iSNS clients within the broadcast or multicast domain of the 702 iSNS server to discover the location of the active iSNS server and 703 any backup servers. 705 2.6 iSNS and Network Address Translation (NAT) 707 The existence of NAT will have an impact upon information retrieved 708 from the iSNS server. If the iSNS client exists in a different 709 addressing domain than the iSNS server, then IP address information 710 stored in the iSNS server may not be correct when interpreted in the 711 domain of the iSNS client. 713 There are several possible approaches to allow operation of iSNS 714 within a NAT network. The first approach is to require use of the 715 canonical TCP port number by both targets and initiators when 716 addressing targets across a NAT boundary, and for the iSNS client to 717 Internet Storage Name Service (iSNS) February 2004 719 not query for nominal IP addresses. Rather, the iSNS client queries 720 for the DNS Fully Qualified Domain Name stored in the Entity 721 Identifier field when seeking addressing information. Once 722 retrieved, the DNS name can be interpreted in each address domain 723 and mapped to the appropriate IP address by local DNS servers. 725 A second approach is to deploy a distributed network of iSNS 726 servers. Local iSNS servers are deployed inside and outside NAT 727 boundaries, with each local server storing relevant IP addresses for 728 their respective NAT domains. Updates among the network of 729 decentralized, local iSNS servers are handled using LDAP and 730 appropriate NAT translation rules implemented within the update 731 mechanism in each server. 733 Finally, note that it is possible for an iSNS server in the private 734 addressing domain behind a NAT boundary to exclusively support iSNS 735 clients that are operating in the global IP addressing domain. If 736 this is the case, the administrator only needs to ensure that the 737 appropriate mappings are configured on the NAT gateways to allow the 738 iSNS clients to initiate iSNSP sessions to the iSNS server. All 739 registered addresses contained in the iSNS server are thus public IP 740 addresses for use outside the NAT boundary. Care should be taken to 741 ensure that there are no iSNS clients querying the server from 742 inside the NAT boundary. 744 2.7 Transfer of iSNS Database Records between iSNS Servers 746 Transfer of iSNS database records between iSNS servers has important 747 applications, including the following: 749 1) An independent organization needs to transfer storage 750 information to a different organization. Each organization 751 independently maintains its own iSNS infrastructure. To facilitate 752 discovery of storage assets of the peer organization using IP, iSNS 753 database records can be transferred between authoritative iSNS 754 servers from each organization. This allows storage sessions to be 755 established directly between devices residing in each organization's 756 storage network infrastructure over a common IP network. 758 2) Multiple iSNS servers are desired for redundancy. Backup 759 servers need to maintain copies of the primary server's dynamically 760 changing database. 762 To support the above applications, information in an iSNS server can 763 be distributed to other iSNS servers either using the iSNS protocol, 764 or through out-of-band mechanisms using non-iSNS protocols. The 765 following examples illustrate possible methods to transfer data 766 records between iSNS servers. In the first example, a back-end LDAP 767 information base is used to support the iSNS server, and the data is 768 transferred using the LDAP protocol. Once the record transfer of 769 the remote device is completed, it becomes visible and accessible to 770 local devices using the local iSNS server. This allows local 771 devices to establish sessions with remote devices (provided firewall 772 boundaries can be negotiated). 774 Internet Storage Name Service (iSNS) February 2004 776 +-------------------------+ +-------------------------+ 777 |+------+ iSNSP | | iSNSP +-----+ | 778 ||dev A |<----->+------+ | | +------+<----->|dev C| | 779 |+------+ | | | | | | +-----+ | 780 |+------+ iSNSP |local | | | |remote| iSNSP +-----+ | 781 ||dev B |<----->| iSNS | | | | iSNS |<----->|dev D| | 782 |+------+ |server| | | |server| +-----+ | 783 |........ +--+---+ | WAN | +---+--+ | 784 |.dev C'. | | Link | | | 785 |........ | ============= | | 786 | | | | | | 787 | +--+---+ | | +---+--+ | 788 | | local|<--- <--- <--- <-|remote| | 789 | | LDAP | | LDAP: | | LDAP | | 790 | +------+ Xfer "dev C"| +------+ | 791 +-------------------------+ +-------------------------+ 792 Enterprise Enterprise 793 Network A Network B 795 In the above diagram, two business partners wish to share storage 796 "dev C". Using LDAP, the record for "dev C" can be transferred from 797 Network B to Network A. Once accessible to the local iSNS server in 798 Network A, local devices A and B can now discover and connect to 799 "dev C". 801 +-------------------------+ +-------------------------+ 802 |+------+ iSNSP | | iSNSP +-----+ | 803 ||dev A |<----->+------+ | | +------+<----->|dev C| | 804 |+------+ | | | | | | +-----+ | 805 |+------+ iSNSP |local | | | |remote| iSNSP +-----+ | 806 ||dev B |<----->| iSNS | | | | iSNS |<----->|dev D| | 807 |+------+ |server| | | |server| +-----+ | 808 |........ +------+ | WAN | +---+--+ | 809 |.dev C'. ^ | Link | | | 810 |........ | ============= v | 811 | | | | |SNMP | 812 | | | | | | 813 | +--+----+ | | v | 814 | | SNMP |<--- <--- <--- <---- | 815 | | Mgmt | | SNMP: Xfer "dev C" | 816 | |Station| | | | 817 | +-------+ | | | 818 +-------------------------+ +-------------------------+ 819 Enterprise Enterprise 820 Network A Network B 822 The above diagram illustrates a second example of how iSNS records 823 can be shared. This method uses an SNMP-based management station to 824 (manually) retrieve (GET) the desired record for "dev C", and then 825 directly store (SET) it on the local iSNS server. Once the record is 826 transferred to the local iSNS server in Network A, "dev C" becomes 827 visible and accessible (provided firewall boundaries can be 828 negotiated) to other devices in Network A. 830 Internet Storage Name Service (iSNS) February 2004 832 Other methods, including proprietary protocols, can be used to 833 transfer device records between iSNS servers. Further discussion 834 and explanation of these methodologies is beyond the scope of this 835 document. 837 2.8 Backup iSNS Servers 839 This section offers a broad framework for implementation and 840 deployment of iSNS backup servers. Server failover and recovery are 841 topics of continuing research and adequate resolution of issues such 842 as split brain and primary server selection is dependent on the 843 specific implementation requirements and deployment needs. The 844 failover mechanisms discussed in this document focus on the 845 interaction between iSNS clients and iSNS servers. Specifically, 846 what is covered in this document includes the following: 848 - iSNS client behavior and the iSNS protocol interaction between 849 the client and multiple iSNS servers, some of which are backup 850 servers. 852 - Required failover behaviors of the collection of iSNS servers 853 that includes active and backup servers. 855 However, note that this document does not specify the complete 856 functional failover requirements of each iSNS server. In 857 particular, it does not specify the complete set of protocol 858 interactions among the iSNS servers that are required to achieve 859 stable failover operation in an interoperable manner. 861 For the purposes of this discussion, the specified backup mechanisms 862 pertain to interaction among different logical iSNS servers. Note 863 that it is possible to create multiple physical iSNS servers to form 864 a single logical iSNS server cluster, and thus distribute iSNS 865 transaction processing among multiple physical servers. However, a 866 more detailed discussion of the interactions between physical 867 servers within a logical iSNS server cluster is beyond the scope of 868 this document. 870 Multiple logical iSNS servers can be used to provide redundancy in 871 the event that the active iSNS server fails or is removed from the 872 network. The methods described in section 2.7 above can be used to 873 transfer name server records to backup iSNS servers. Each backup 874 server maintains a redundant copy of the name server database found 875 in the primary iSNS server, and can respond to iSNS protocol 876 messages in the same way as the active server. Each backup server 877 SHOULD monitor the health and status of the active iSNS server, 878 including checking to make sure its own database is synchronized 879 with the active server's database. How each backup server 880 accomplishes this is implementation-dependent, and may (or may not) 881 include using the iSNS protocol. If the iSNS protocol is used, then 882 the backup server MAY register itself in the active server's iSNS 883 database as a Control Node, allowing it to receive state change 884 notifications. 886 Internet Storage Name Service (iSNS) February 2004 888 Generally, the administrator or some automated election process is 889 responsible for initial and subsequent designation of the primary 890 server and each backup server. 892 A maximum of one logical backup iSNS server SHALL exist at any 893 individual IP address, in order to avoid conflicts from multiple 894 servers listening on the same canonical iSNS TCP or UDP port number. 896 The iSNS heartbeat can also be used to coordinate designation and 897 selection of primary and backup iSNS servers. 899 Each backup server MUST note its relative precedence in the active 900 server's list of backup servers. If not already known, each backup 901 server MAY learn its precedence from the iSNS heartbeat message, by 902 noting the position of its IP address in the ordered list of backup 903 server IP addresses. For example, if it is the first backup listed 904 in the heartbeat message, then its backup precedence is 1. If it is 905 the third backup server listed, then its backup precedence is 3. 907 If a backup server establishes that it has lost connectivity to the 908 active server and other backup servers of higher precedence, then it 909 SHOULD assume that it is the active server. The method of 910 determining whether connectivity has been lost is implementation- 911 specific. One possible approach is to assume that if the backup 912 server does not receive iSNS heartbeat messages for a period of 913 time, then connectivity to the active server has been lost. 914 Alternatively, the backup server may establish TCP connections to 915 the active server and other backup servers, and loss of connectivity 916 determined through non-response to periodic echo or polling messages 917 (using iSNSP, SNMP, or other protocols). 919 When a backup server becomes the active server, it SHALL assume all 920 active server responsibilities, including (if used) transmission of 921 the iSNS heartbeat message. If transmitting the iSNS heartbeat, the 922 backup server replaces the active Server IP Address and TCP/UDP Port 923 entries with its own IP address and TCP/UDP Port, and begins 924 incrementing the counter field from the last known value from the 925 previously-active iSNS server. However, it MUST NOT change the 926 original ordered list of backup server IP Address and TCP/UDP Port 927 entries. If the primary backup server or other higher-precedence 928 backup server returns, then the existing active server is 929 responsible for ensuring that the new active server's database is 930 up-to-date before demoting itself to its original status as backup. 932 Since the primary and backup iSNS servers maintain a coordinated 933 database, no re-registration by an iSNS Client is required when a 934 backup server takes the active server role. Likewise, no re- 935 registration by an iSNS Client is required when the previous primary 936 server returns to the active server role. 938 Internet Storage Name Service (iSNS) February 2004 940 2.9 Transport Protocols 942 The iSNS Protocol is transport-neutral. Query and registration 943 messages are transported over TCP or UDP. iSNS heartbeat messages 944 are transported using IP multicast or broadcast. 946 2.9.1 Use of TCP For iSNS Communication 948 It MUST be possible to use TCP for iSNS communication. The iSNS 949 server MUST accept TCP connections for client registrations. 951 To receive Entity Status Inquiry (ESI) (see section 5.6.5.13) 952 monitoring using TCP, the client registers the Portal ESI Interval 953 and the port number of the TCP port that will be used to receive ESI 954 messages. The iSNS server initiates the TCP connection used to 955 deliver the ESI message. This TCP connection does not need to be 956 continuously open. 958 To receive SCN notifications using TCP, the client registers the 959 iSCSI or iFCP SCN Bitmap and the port number of the TCP port in the 960 Portal used to receive SCNs. The iSNS server initiates the TCP 961 connection used to deliver the SCN message. This TCP connection 962 does not need to be continuously open. 964 It is possible for an iSNS client to use the same TCP connection for 965 SCN, ESI, and iSNS queries. Alternatively, separate connections may 966 be used. 968 2.9.2 Use of UDP For iSNS Communication 970 The iSNS server MAY accept UDP messages for client registrations. 971 The iSNS server MUST accept registrations from clients requesting 972 UDP-based ESI and SCN messages. 974 To receive UDP-based ESI monitoring messages, the client registers 975 the port number of the UDP port in at least one Portal to be used to 976 receive and respond to ESI messages from the iSNS server. If a 977 Network Entity has multiple Portals with registered ESI UDP Ports, 978 then ESI messages SHALL be delivered to every Portal registered to 979 receive such messages. 981 To receive UDP-based SCN notification messages, the client registers 982 the port number of the UDP port in at least one Portal to be used to 983 receive SCN messages from the iSNS server. If a Network Entity has 984 multiple Portals with registered SCN UDP Ports, then SCN messages 985 SHALL be delivered to each Portal registered to receive such 986 messages. 988 When using UDP to transport iSNS messages, each UDP datagram MUST 989 contain exactly one iSNS PDU (see section 5). 991 2.9.3 iSNS Multicast and Broadcast Messages 992 Internet Storage Name Service (iSNS) February 2004 994 iSNS multicast messages are transported using IP multicast or 995 broadcast. The iSNS heartbeat is the only iSNS multicast or 996 broadcast message. This message is originated by the iSNS server 997 and sent to all iSNS clients that are listening on the IP multicast 998 address allocated for the iSNS heartbeat. 1000 2.10 Simple Network Management Protocol (SNMP) Requirements 1002 The iSNS Server may be managed via the iSNS MIB [iSNSMIB] using an 1003 SNMP management framework [RFC3411]. For a detailed overview of the 1004 documents that describe the current Internet-Standard Management 1005 Framework, please refer to section 7 of RFC 3410 [RFC3410]. The 1006 iSNS MIB provides the ability to configure and monitor an iSNS 1007 server without using the iSNS protocol directly. SNMP management 1008 frameworks have several requirements for object indexing in order 1009 for objects to be accessed or added. 1011 SNMP uses an Object Identifier (OID) for object identification. The 1012 size of each OID is restricted to a maximum of 128 sub-identifiers. 1013 Both the iSCSI and iFCP protocol contain identifiers, such as the 1014 iSCSI Name, that are greater the 128 characters in length. Using 1015 such identifiers as an index would result in more than 128 sub- 1016 identifiers per OID. In order to support objects that have key 1017 identifiers whose maximum length is longer than the maximum SNMP 1018 supported length, the iSNS server provides secondary non-zero 1019 integer index identifiers. These indexes SHALL be persistent for as 1020 long as the server is active. Furthermore, index values for recently 1021 deregistered objects SHOULD NOT be reused in the short term. Object 1022 attributes, including indexes, are described in detail in Section 6. 1024 In order for SNMP based management applications to create a new 1025 entry in a table of objects, a valid OID must be available to 1026 specify the table row. The iSNS server supports this by providing, 1027 for each type of object that can be added via SNMP, an object 1028 attribute that returns the next available non-zero integer index. 1029 This allows an SNMP client to request an OID to be used for 1030 registering a new object in the server. Object attributes, 1031 including next available index attributes, are described in detail 1032 in Section 6. 1034 3. iSNS Object Model 1036 iSNS provides the framework for the registration, discovery, and 1037 management of iSCSI devices and Fibre Channel-based devices (using 1038 iFCP). This architecture framework provides elements needed to 1039 describe various storage device objects and attributes that may 1040 exist on an IP storage network. Objects defined in this 1041 architecture framework include Network Entity, Portal, Storage Node, 1042 FC Device, Discovery Domain, and Discovery Domain Set. Each of 1043 these objects is described in greater detail in the following 1044 sections. 1046 Internet Storage Name Service (iSNS) February 2004 1048 3.1 Network Entity Object 1050 The Network Entity object is a container of Storage Node objects and 1051 Portal objects. It represents the infrastructure supporting access 1052 to a unique set of one or more Storage Nodes. The Entity Identifier 1053 attribute uniquely distinguishes a Network Entity, and is the key 1054 used to register a Network Entity object in an iSNS server. All 1055 Storage Nodes and Portals contained within a single Network Entity 1056 object operate as a cohesive unit. 1058 Note that it is possible for a single physical device or gateway to 1059 be represented by more than one logical Network Entity in the iSNS 1060 database. For example, one of the Storage Nodes on a physical 1061 device may be accessible from only a subset of the network 1062 interfaces (i.e., Portals) available on that device. In this case, 1063 a logical network entity (i.e., a "shadow entity") is created and 1064 used to contain the Portals and Storage Nodes that can operate 1065 cooperatively. No object (Portals, Storage Nodes, etc...) can be 1066 contained in more than one logical Network Entity. 1068 Similarly, it is possible for a logical Network Entity to be 1069 supported by more than one physical device or gateway. For example, 1070 multiple FC-iSCSI gateways may be used to bridge FC devices in a 1071 single Fibre Channel network. The multiple gateways collectively 1072 can be used to support a single logical Network Entity that is used 1073 to contain all of the devices in that Fibre Channel network. 1075 3.2 Portal Object 1077 The Portal object is an interface through which access to Storage 1078 Nodes within the Network Entity can be obtained. The IP address and 1079 TCP/UDP Port number attributes uniquely distinguish a Portal object, 1080 and combined are the key used to register a Portal object in an iSNS 1081 server. A Portal is contained in one and only one Network Entity, 1082 and may be contained in one or more DDs (see section 3.6 below). 1084 3.3 Storage Node Object 1086 The Storage Node object is the logical endpoint of an iSCSI or iFCP 1087 session. In iFCP, the session endpoint is represented by the World 1088 Wide Port Name (WWPN). In iSCSI, the session endpoint is 1089 represented by the iSCSI Name of the device. For iSCSI, the iSCSI 1090 Name attribute uniquely distinguishes a Storage Node, and is the key 1091 used to register a Storage Node object in an iSNS Server. For iFCP, 1092 the FC Port Name (WWPN) attribute uniquely distinguishes a Storage 1093 Node, and is the key used to register a Storage Node object in the 1094 iSNS Server. A Storage Node is contained in one and only one 1095 Network Entity object, and may be contained in one or more DDs (see 1096 section 3.6 below). 1098 3.4 Portal Group Object 1100 The Portal Group (PG) object represents an association between a 1101 Portal and an iSCSI Node. Each Portal and iSCSI Storage Node 1102 Internet Storage Name Service (iSNS) February 2004 1104 registered in an Entity can be associated using a Portal Group (PG) 1105 object. The PG Tag (PGT), if non-NULL, indicates that the 1106 associated Portal provides access to the associated iSCSI Storage 1107 Node in the Entity. All Portals that have the same PGT value for a 1108 specific iSCSI Storage Node allow coordinated access to that node. 1110 A PG object MAY be registered when a Portal or iSCSI Storage Node is 1111 registered. Each Portal to iSCSI Node association is represented by 1112 one and only one PG object. In order for a Portal to provide access 1113 to an iSCSI Node, the PGT of the PG object MUST be non-NULL. If the 1114 PGT value registered for a specified Portal and iSCSI Node is NULL, 1115 or no PGT value is registered, then the Portal does not provide 1116 access to that iSCSI Node in the Entity. 1118 The PGT value indicates whether access to an iSCSI Node can be 1119 coordinated across multiple Portals. All Portals that have the same 1120 PGT value for a specific iSCSI Node can provide coordinated access 1121 to that iSCSI Node. According to the iSCSI Specification, 1122 coordinated access to an iSCSI node indicates the capability of 1123 coordinating an iSCSI session with connections that span these 1124 Portals [iSCSI]. 1126 The PG object is uniquely distinguished by the iSCSI Name, Portal IP 1127 Address, and the Portal TCP Port values of the associated Storage 1128 Node and Portal objects. These are represented in the iSNS Server 1129 by the PG iSCSI Name, PG Portal IP Address, and PG Portal TCP/UDP 1130 Port attributes, respectively. The PG object is also uniquely 1131 distinguished in the iSNS Server by the PG Index value. 1133 A new PG object can only be registered by referencing its associated 1134 iSCSI Storage Node or Portal object. A pre-existing PG object can 1135 be modified or queried by using its Portal Group Index as message 1136 key, or by referencing its associated iSCSI Storage Node or Portal 1137 object. A 0-length Tag, Length, Value TLV is used to register a PGT 1138 NULL value. 1140 The PG object is deregistered if and only if its associated iSCSI 1141 Node and Portal objects are both removed. 1143 3.5 FC Device Object 1145 The FC Device represents the Fibre Channel Node. This object 1146 contains information that may be useful in the management of the 1147 Fibre Channel device. The FC Node Name (WWNN) attribute uniquely 1148 distinguishes an FC Device, and is the key used to register an FC 1149 Device object in the iSNS Server. 1151 The FC Device is contained in one or more Storage Node objects. 1153 3.6 Discovery Domain Object 1155 Discovery Domains (DD) are a security and management mechanism used 1156 to administer access and connectivity to storage devices. For query 1157 and registration purposes, they are considered to be containers for 1158 Internet Storage Name Service (iSNS) February 2004 1160 Storage Node and Portal objects. A query by an iSNS client that is 1161 not from a Control Node only returns information about objects with 1162 which it shares at least one active DD. The only exception to this 1163 rule is with Portals; if Storage Nodes of a Network Entity are 1164 registered in the DD without Portals, then all Portals of that 1165 Network Entity are implicit members of that DD. The Discovery 1166 Domain ID (DD_ID) attribute uniquely distinguishes a Discovery 1167 Domain object, and is the key used to register a Discovery Domain 1168 object in the iSNS Server. 1170 A DD is considered active if it is a member of at least one active 1171 DD Set. DDs that are not members of at least one enabled DDS are 1172 considered disabled. A Storage Node can be a member of one or more 1173 DDs. An enabled DD establishes connectivity among the Storage Nodes 1174 in that DD. 1176 3.7 Discovery Domain Set Object 1178 The Discovery Domain Set (DDS) is a container object for Discovery 1179 Domains (DDs). DDSs may contain one or more DDs. Similarly, each 1180 DD can be a member of one or more DDSs. DDSs are a mechanism to 1181 store coordinated sets of DD mappings in the iSNS server. Active 1182 DDs are members of at least one active DD Set. Multiple DDSs may be 1183 considered active at the same time. The Discovery Domain Set ID 1184 (DDS_ID) attribute uniquely distinguishes a Discovery Domain Set 1185 object, and is the key used to register a Discovery Domain Set 1186 object in the iSNS Server. 1188 3.8 iSNS Database Model 1190 As presented to the iSNS client, each object of a specific type in 1191 the iSNS database MUST have an implicit internal linear ordering 1192 based on the key(s) for that object type. This ordering provides 1193 the ability to respond to DevGetNext queries (see section 5.6.5.3). 1194 The ordering of objects in the iSNS database SHOULD NOT be changed 1195 with respect to that implied ordering, as a consequence of object 1196 insertions and deletions. That is, the relative order of surviving 1197 object entries in the iSNS database SHOULD be preserved so that the 1198 DevGetNext message encounters generally reasonable behavior. 1200 The following shows the various objects described above and their 1201 relationship to each other. 1203 Internet Storage Name Service (iSNS) February 2004 1205 +--------------+ +-----------+ 1206 | NETWORK |1 *| | 1207 | ENTITY |----| PORTAL | 1208 | | | | 1209 +--------------+ +-----------+ 1210 |1 |1 |* 1211 | | | 1212 | |* | 1213 | +----------+ | 1214 | | PORTAL | | 1215 | | GROUP | | 1216 | +----------+ | 1217 | |* | 1218 | | | 1219 |* |1 |* 1220 +-----------+ +--------------+ +-----------+ +-----------+ 1221 | FC |1 *| STORAGE |* *| DISCOVERY |* *| DISCOVERY | 1222 | DEVICE |----| NODE |----| DOMAIN |----| DOMAIN | 1223 | | | | | | | SET | 1224 +-----------+ +--------------+ +-----------+ +-----------+ 1226 * represents 0 to many possible relationships 1228 4. iSNS Implementation Requirements 1230 This section details specific requirements for support of each of 1231 these IP storage protocols. Implementation requirements for security 1232 are described in section 7. 1234 4.1 iSCSI Requirements 1236 Use of iSNS in support of iSCSI is OPTIONAL. iSCSI devices MAY be 1237 manually configured with the iSCSI Name and IP address of peer 1238 devices, without the aid or intervention of iSNS. iSCSI devices 1239 also may use SLP [RFC 2608] to discover peer iSCSI devices. 1240 However, iSNS is useful for scaling a storage network to a larger 1241 number of iSCSI devices. 1243 4.1.1 Required Attributes for Support of iSCSI 1245 The following attributes are available to support iSCSI. Attributes 1246 indicated in the REQUIRED for Server column MUST be implemented by 1247 an iSNS server used to support iSCSI. Attributes indicated in the 1248 REQUIRED for Client column MUST be implemented by an iSCSI device 1249 that elects to use the iSNS. Attributes indicated in the K (Key) 1250 column uniquely identify the object type in the iSNS Server. A more 1251 detailed description of each attribute is found in section 6. 1253 REQUIRED for: 1254 Object Attribute K Server Client 1255 ------ --------- - ------ ------ 1256 NETWORK ENTITY Entity Identifier * * * 1257 Entity Protocol * * 1259 Internet Storage Name Service (iSNS) February 2004 1261 Management IP Address * 1262 Timestamp * 1263 Protocol Version Range * 1264 Registration Period * 1265 Entity Index * 1266 Entity IKE Phase-1 Proposal 1267 Entity Certificate 1269 PORTAL IP Address * * * 1270 TCP/UDP Port * * * 1271 Portal Symbolic Name * 1272 ESI Interval * 1273 ESI Port * 1274 Portal Index * 1275 SCN Port * 1276 Portal Security Bitmap * 1277 Portal IKE Phase-1 Proposal 1278 Portal IKE Phase-2 Proposal 1279 Portal Certificate 1281 PORTAL GROUP PG iSCSI Name * * * 1282 PG IP Address * * * 1283 PG TCP/UDP Port * * * 1284 PG Tag * * 1285 PG Index * 1287 STORAGE NODE iSCSI Name * * * 1288 iSCSI Node Type * * 1289 Alias * 1290 iSCSI SCN Bitmap * 1291 iSCSI Node Index * 1292 WWNN Token 1293 iSCSI AuthMethod 1294 iSCSI Node Certificate 1296 DISCOVERY DOMAIN DD ID * * * 1297 DD Symbolic Name * 1298 DD Member iSCSI Node Index * 1299 DD Member iSCSI Name * 1300 DD Member Portal Index * 1301 DD Member Portal IP Addr * 1302 DD Member Portal TCP/UDP * 1303 DD Features * 1305 DISCOVERY DOMAIN DDS Identifier * * 1306 SET DDS Symbolic Name * 1307 DDS Status * 1309 All iSCSI user-specified and vendor-specified attributes are 1310 OPTIONAL to implement and use. 1312 Internet Storage Name Service (iSNS) February 2004 1314 4.1.2 Example iSCSI Object Model Diagrams 1316 The following diagram models how a simple iSCSI-based initiator and 1317 target is represented using database objects stored in the iSNS 1318 server. In this implementation, each target and initiator is 1319 attached to a single Portal. 1321 +----------------------------------------------------------------+ 1322 | IP Network | 1323 +------------+--------------------------------------+------------+ 1324 | | 1325 | | 1326 +-----+------+------+-----+ +-----+------+------+-----+ 1327 | | PORTAL | | | | PORTAL | | 1328 | | -IP Addr 1 | | | | -IP Addr 2 | | 1329 | | -TCP Port 1 | | | | -TCP Port 2 | | 1330 | +-----+ +-----+ | | +-----+ +-----+ | 1331 | | | | | | | | 1332 | +-----+ +-----+ | | +-----+ +-----+ | 1333 | | PORTAL GROUP| | | | PORTAL GROUP| | 1334 | | -Prtl Tag 1 | | | | -Prtl Tag 2 | | 1335 | +-----+ +-----+ | | +-----+ +-----+ | 1336 | | | | | | | | 1337 | +--------+ +--------+ | | +-------+ +--------+ | 1338 | | | | | | | | 1339 | | STORAGE NODE | | | | STORAGE NODE | | 1340 | | -iSCSI Name | | | | -iSCSI Name | | 1341 | | -Alias: "server1"| | | | -Alias: "disk1"| | 1342 | | -Type: initiator | | | | -Type: target | | 1343 | | | | | | | | 1344 | +-------------------+ | | +------------------+ | 1345 | | | | 1346 | NETWORK ENTITY | | NETWORK ENTITY | 1347 | -Entity ID (FQDN): | | -Entity ID (FQDN): | 1348 | "strg1.example.com" | | "strg2.example.net" | 1349 | -Protocol: iSCSI | | -Protocol: iSCSI | 1350 | | | | 1351 +-------------------------+ +-------------------------+ 1353 The object model can be expanded to describe more complex devices, 1354 such as an iSCSI device with more than one storage controller, each 1355 controller accessible through any of multiple Portal interfaces, 1356 possibly using multiple Portal Groups. The storage controllers on 1357 this device can be accessed through alternate Portal interfaces if 1358 any original interface should fail. The following diagram describes 1359 such a device: 1361 Internet Storage Name Service (iSNS) February 2004 1363 +---------------------------------------------------------------+ 1364 | IP Network | 1365 +-------------------+-----------------------+-------------------+ 1366 | | 1367 | | 1368 +------------+------+------+---------+------+------+------------+ 1369 | | PORTAL 1 | | PORTAL 2 | | 1370 | | -IP Addr 1 | | -IP Addr 2 | | 1371 | | -TCP Port 1 | | -TCP Port 2 | | 1372 | +-----+ +-----+ +-----+ +-----+ | 1373 | | | | | | 1374 | +---------------+ +---------------------+ +---------------+ | 1375 | +-------+ +----------------+ +-------------------+ +------+ | 1376 | | | | | | | | 1377 | +-------+ +-------+ +------+ +--------+ +--------+ +------+ | 1378 | | | | | | | | 1379 | | STORAGE NODE 1 | | STORAGE NODE 2 | | STORAGE NODE 3 | | 1380 | | -iSCSI Name 1 | | -iSCSI Name 2 | | -iSCSI Name 3 | | 1381 | | -Alias: "disk1"| | -Alias: "disk2"| | -Alias: "disk3"| | 1382 | | -Type: target | | -Type: target | | -Type: target | | 1383 | | | | | | | | 1384 | +-----------------+ +-----------------+ +-----------------+ | 1385 | | 1386 | NETWORK ENTITY | 1387 | -Entity ID (FQDN): "dev1.example.com" | 1388 | -Protocol: iSCSI | 1389 | | 1390 | Portal Group Object Table | 1391 | Storage-Node Portal Portal-Group-Tag | 1392 | 1 1 10 | 1393 | 1 2 NULL (no access permitted) | 1394 | 2 1 20 | 1395 | 2 2 20 | 1396 | 3 1 30 | 1397 | 3 2 10 | 1398 | | 1399 +---------------------------------------------------------------+ 1401 Storage Node 1 is accessible via Portal 1 with a PGT of 10. It does 1402 not have a Portal Group Tag (PGT) assigned for Portal 2, so Storage 1403 Node 1 cannot be accessed via Portal 2. 1405 Storage Node 2 can be accessed via both Portal 1 and Portal 2. 1406 Since Storage Node 2 has the same PGT value assigned to both Portal 1407 1 and Portal 2, in this case 20, coordinated access via the Portals 1408 is available [iSCSI]. 1410 Storage Node 3 can be accessed via Portal 1 or Portal 2. However, 1411 since Storage Node 3 has different PGT values assigned to each 1412 Portal, in this case 10 and 30, access is not coordinated [iSCSI]. 1413 Because PGTs are assigned within the context of a Storage Node, the 1414 PGT value of 10 used for Storage Node 1 and Storage Node 3 are not 1415 interrelated. 1417 Internet Storage Name Service (iSNS) February 2004 1419 4.1.3 Required Commands and Response Messages for Support of iSCSI 1421 The following iSNSP messages and responses are available in support 1422 of iSCSI. Messages indicated in the REQUIRED for Server column MUST 1423 be implemented in iSNS servers used for iSCSI devices. Messages 1424 indicated in the REQUIRED for Client column MUST be implemented in 1425 iSCSI devices that elect to use the iSNS server. 1427 REQUIRED for: 1428 Message Description Abbreviation Func_ID Server Client 1429 ------------------- ------------ ------- ------ ------ 1430 RESERVED 0x0000 1431 Device Attr Reg Request DevAttrReg 0x0001 * * 1432 Dev Attr Query Request DevAttrQry 0x0002 * * 1433 Dev Get Next Request DevGetNext 0x0003 * 1434 Deregister Dev Request DevDereg 0x0004 * * 1435 SCN Register Request SCNReg 0x0005 * 1436 SCN Deregister Request SCNDereg 0x0006 * 1437 SCN Event SCNEvent 0x0007 * 1438 State Change Notification SCN 0x0008 * 1439 DD Register DDReg 0x0009 * * 1440 DD Deregister DDDereg 0x000A * * 1441 DDS Register DDSReg 0x000B * * 1442 DDS Deregister DDSDereg 0x000C * * 1443 Entity Status Inquiry ESI 0x000D * 1444 Name Service Heartbeat Heartbeat 0x000E 1445 RESERVED 0x000F-0x00FF 1446 Vendor Specific 0x0100-0x01FF 1447 RESERVED 0x0200-0x7FFF 1449 The following are iSNSP response messages used in support of iSCSI: 1451 REQUIRED for: 1452 Response Message Desc Abbreviation Func_ID Server Client 1453 --------------------- ------------ ------- ------ ------ 1454 RESERVED 0x8000 1455 Device Attr Register Rsp DevAttrRegRsp 0x8001 * * 1456 Device Attr Query Rsp DevAttrQryRsp 0x8002 * * 1457 Device Get Next Rsp DevGetNextRsp 0x8003 * 1458 Device Dereg Rsp DevDeregRsp 0x8004 * * 1459 SCN Register Rsp SCNRegRsp 0x8005 * 1460 SCN Deregister Rsp SCNDeregRsp 0x8006 * 1461 SCN Event Rsp SCNEventRsp 0x8007 * 1462 SCN Response SCNRsp 0x8008 * 1463 DD Register Rsp DDRegRsp 0x8009 * * 1464 DD Deregister Rsp DDDeregRsp 0x800A * * 1465 DDS Register Rsp DDSRegRsp 0x800B * * 1466 DDS Deregister Rsp DDSDeregRsp 0x800C * * 1467 Entity Stat Inquiry Rsp ESIRsp 0x800D * 1468 RESERVED 0x800E-0x80FF 1469 Vendor Specific 0x8100-0x81FF 1470 RESERVED 0x8200-0xFFFF 1471 Internet Storage Name Service (iSNS) February 2004 1473 4.2 iFCP Requirements 1475 In iFCP, use of iSNS is REQUIRED. No alternatives exist for support 1476 of iFCP Naming & Discovery functions. 1478 4.2.1 Required Attributes for Support of iFCP 1480 The following table displays attributes that are used by iSNS to 1481 support iFCP. Attributes indicated in the REQUIRED for Server 1482 column MUST be implemented by the iSNS server that supports iFCP. 1483 Attributes indicated in the REQUIRED for Client column MUST be 1484 supported by iFCP gateways. Attributes indicated in the K (Key) 1485 column uniquely identify the object type in the iSNS Server. A more 1486 detailed description of each attribute is found in section 6. 1488 REQUIRED for: 1489 Object Attribute K Server Client 1490 ------ --------- - ------ ------ 1491 NETWORK ENTITY Entity Identifier * * * 1492 Entity Protocol * * 1493 Management IP Address * 1494 Timestamp * 1495 Protocol Version Range * 1496 Registration period 1497 Entity Index 1498 Entity IKE Phase-1 Proposal 1499 Entity Certificate 1501 PORTAL IP Address * * * 1502 TCP/UDP Port * * * 1503 Symbolic Name * 1504 ESI Interval * 1505 ESI Port * 1506 SCN Port * 1507 Portal IKE Phase-1 Proposal 1508 Portal IKE Phase-2 Proposal 1509 Portal Certificate 1510 Security Bitmap * 1512 STORAGE NODE FC Port Name (WWPN) * * * 1513 (FC Port) Port_ID * * 1514 FC Port Type * * 1515 Port Symbolic Name * 1516 Fabric Port Name (FWWN) * 1517 Hard Address * 1518 Port IP Address * 1519 Class of Service * 1520 FC FC-4 Types * 1521 FC FC-4 Descriptors * 1522 FC FC-4 Features * 1523 SCN Bitmap * 1524 iFCP Port Role * 1525 Permanent Port Name * 1527 Internet Storage Name Service (iSNS) February 2004 1529 FC DEVICE FC Node Name (WWNN) * * * 1530 (FC Node) Node Symbolic Name * 1531 Node IP Address * 1532 Node IPA * 1533 Proxy iSCSI Name 1535 DISCOVERY DOMAIN DD ID * * * 1536 DD Symbolic Name * 1537 DD Member FC Port Name * 1538 DD Member Portal Index * 1539 DD Member Portal IP Addr * 1540 DD Member Portal TCP/UDP * 1542 DISCOVERY DOMAIN DDS ID * * 1543 SET DDS Symbolic Name * 1544 DDS Status * 1546 OTHER Switch Name 1547 Preferred_ID 1548 Assigned_ID 1549 Virtual_Fabric_ID 1551 All iFCP user-specified and vendor-specified attributes are OPTIONAL 1552 to implement and use. 1554 4.2.2 Example iFCP Object Model Diagram 1556 The iFCP protocol allows native Fibre Channel devices or Fibre 1557 Channel fabrics connected to an iFCP gateway to be directly 1558 internetworked using IP. 1560 When supporting iFCP, the iSNS server stores Fibre Channel device 1561 attributes, iFCP gateway attributes, and Fibre Channel fabric switch 1562 attributes that might also be stored in an FC name server. 1564 The following diagram shows a representation of a gateway supporting 1565 multiple Fibre Channel devices behind it. The two Portal objects 1566 represent IP interfaces on the iFCP gateway that can be used to 1567 access any of the three Storage Node objects behind it. Note that 1568 the FC Device object is not contained in the Network Entity object. 1569 However, each FC Device has a relationship to one or more Storage 1570 Node objects. 1572 Internet Storage Name Service (iSNS) February 2004 1574 +--------------------------------------------------------+ 1575 | IP Network | 1576 +--------+-----------------+-----------------------------+ 1577 | | 1578 +-+------+------+---+------+------+----------------------+ 1579 | | PORTAL | | PORTAL | NETWORK ENTITY | 1580 | | -IP Addr 1 | | -IP Addr 2 | -Entity ID (FQDN): | 1581 | | -TCP Port 1 | | -TCP Port 2 | "gtwy1.example.com" | 1582 | +-----+ +-----+ +-----+ +-----+ -Protocol: iFCP | 1583 | | | | | | 1584 | +-----+ +---------------+ +----------------------+ | 1585 | +-----+ +---------------+ +-------------+ +------+ | 1586 | | | | | | | | 1587 | +-----+ +-----+ +----+ +------+ +----+ +------+ | 1588 | |STORAGE NODE | |STORAGE NODE | |STORAGE NODE | | 1589 | | -WWPN 1 | | -WWPN 2 | | -WWPN 3 | | 1590 | | -Port ID 1 | | -Port ID 2 | | -Port ID 3 | | 1591 | | -FWWN 1 | | -FWWN 2 | | -FWWN 3 | | 1592 | | -FC COS | | -FC COS | | -FC COS | | 1593 | +------+------+ +-------+-----+ +----+--------+ | 1594 +--------|-------------------|------------|--------------+ 1595 | | | 1596 +------+------+ +---+------------+---+ 1597 | FC DEVICE | | FC DEVICE | 1598 | -WWNN 1 | | -WWNN 2 | 1599 | | | | 1600 +-------------+ +--------------------+ 1602 4.2.3 Required Commands and Response Messages for Support of iFCP 1604 The iSNSP messages and responses displayed in the following tables 1605 are available to support iFCP gateways. Messages indicated in the 1606 REQUIRED TO IMPLEMENT column MUST be supported by the iSNS server 1607 used by iFCP gateways. Messages indicated in the REQUIRED TO USE 1608 column MUST be supported by the iFCP gateways themselves. 1610 Internet Storage Name Service (iSNS) February 2004 1612 REQUIRED for: 1613 Message Description Abbreviation Func ID Server Client 1614 ------------------- ------------ ------- ------ ------ 1615 RESERVED 0x0000 1616 Device Attr Reg Request DevAttrReg 0x0001 * * 1617 Device Attr Query Request DevAttrQry 0x0002 * * 1618 Device Get Next Request DevGetNext 0x0003 * 1619 Device Dereg Request DevDereg 0x0004 * * 1620 SCN Register Request SCNReg 0x0005 * 1621 SCN Deregister Request SCNDereg 0x0006 * 1622 SCN Event SCNEvent 0x0007 * 1623 State Change Notification SCN 0x0008 * 1624 DD Register DDReg 0x0009 * * 1625 DD Deregister DDDereg 0x000A * * 1626 DDS Register DDSReg 0x000B * * 1627 DDS Deregister DDSDereg 0x000C * * 1628 Entity Status Inquiry ESI 0x000D * 1629 Name Service Heartbeat Heartbeat 0x000E * 1630 Reserved Reserved 0x000F-0x0010 1631 Request FC_DOMAIN_ID RqstDomId 0x0011 1632 Release FC_DOMAIN_ID RlseDomId 0x0012 1633 Get FC_DOMAIN_IDs GetDomId 0x0013 1634 RESERVED 0x0014-0x00FF 1635 Vendor Specific 0x0100-0x01FF 1636 RESERVED 0x0200-0x7FFF 1638 The following are iSNSP response messages in support of iFCP: 1640 REQUIRED for: 1641 Response Message Desc Abbreviation Func_ID Server Client 1642 --------------------- ------------ ------- ------ ------ 1643 RESERVED 0x8000 1644 Device Attr Reg Rsp DevAttrRegRsp 0x8001 * * 1645 Device Attr Query Rsp DevAttrQryRsp 0x8002 * * 1646 Device Get Next Rsp DevGetNextRsp 0x8003 * 1647 Device Deregister Rsp DevDeregRsp 0x8004 * * 1648 SCN Register Rsp SCNRegRsp 0x8005 * 1649 SCN Deregister Rsp SCNDeregRsp 0x8006 * 1650 SCN Event Rsp SCNEventRsp 0x8007 * 1651 SCN Rsp SCNRsp 0x8008 * 1652 DD Register Rsp DDRegRsp 0x8009 * * 1653 DD Deregister Rsp DDDeregRsp 0x800A * * 1654 DDS Register Rsp DDSRegRsp 0x800B * * 1655 DDS Deregister Rsp DDSDeregRsp 0x800C * * 1656 Entity Status Inquiry Rsp ESIRsp 0x800D * 1657 NOT USED 0x800E 1658 RESERVED 0x800F-0x8010 1659 Request FC_DOMAIN_ID Rsp RqstDomIdRsp 0x8011 1660 Release FC_DOMAIN_ID Rsp RlseDomIdRsp 0x8012 1661 Get FC_DOMAIN_IDs GetDomIdRsp 0x0013 1662 RESERVED 0x8014-0x80FF 1663 Vendor Specific 0x8100-0x81FF 1664 RESERVED 0x8200-0xFFFF 1665 Internet Storage Name Service (iSNS) February 2004 1667 5. iSNSP Message Format 1669 The iSNSP message format is similar to the format of other common 1670 protocols such as DHCP, DNS and BOOTP. An iSNSP message may be sent 1671 in one or more iSNS Protocol Data Units (PDU). Each PDU is 4 byte 1672 aligned. The following describes the format of the iSNSP PDU: 1674 Byte MSb LSb 1675 Offset 0 15 16 31 1676 +---------------------+----------------------+ 1677 0 | iSNSP VERSION | FUNCTION ID | 4 Bytes 1678 +---------------------+----------------------+ 1679 4 | PDU LENGTH | FLAGS | 4 Bytes 1680 +---------------------+----------------------+ 1681 8 | TRANSACTION ID | SEQUENCE ID | 4 Bytes 1682 +---------------------+----------------------+ 1683 12 | | 1684 | PDU PAYLOAD | N Bytes 1685 | ... | 1686 +--------------------------------------------+ 1687 12+N | AUTHENTICATION BLOCK (Multicast/Broadcast) | L Bytes 1688 +--------------------------------------------+ 1689 Total Length = 12 + N + L 1691 5.1 iSNSP PDU Header 1693 The iSNSP PDU header contains the iSNSP VERSION, FUNCTION ID, PDU 1694 LENGTH, FLAGS, TRANSACTION ID, and SEQUENCE ID fields as defined 1695 below. 1697 5.1.1 iSNSP Version 1699 The iSNSP version described in this document is 0x0001. All other 1700 values are RESERVED. The iSNS server MAY reject messages for iSNSP 1701 version numbers that it does not support. 1703 5.1.2 iSNSP Function ID 1705 The FUNCTION ID defines the type of iSNS message and the operation 1706 to be executed. FUNCTION_ID values with the leading bit cleared 1707 indicate query, registration, and notification messages, while 1708 FUNCTION_ID values with the leading bit set indicate response 1709 messages. 1711 See section 4 under the appropriate protocol (i.e., iSCSI or iFCP) 1712 for a mapping of the FUNCTION_ID value to the iSNSP Command or 1713 Response message. All PDUs comprising an iSNSP message must have 1714 the same FUNCTION_ID value. 1716 5.1.3 iSNSP PDU Length 1718 The iSNS PDU Length specifies the length of the PDU PAYLOAD field in 1719 bytes. The PDU Payload contains TLV attributes for the operation. 1721 Internet Storage Name Service (iSNS) February 2004 1723 Additionally, response messages contain a success/failure code. The 1724 PDU Length MUST be 4-byte aligned. 1726 5.1.4 iSNSP Flags 1728 The FLAGS field indicates additional information about the message 1729 and the type of Network Entity that generated the message. The 1730 following table displays the valid flags: 1732 Bit Position Enabled (1) Means: 1733 ------------ ----------------- 1734 16 Sender is the iSNS client 1735 17 Sender is the iSNS server 1736 18 Authentication block present 1737 19 Replace flag (for DevAttrReg) 1738 20 Last PDU of the iSNS message 1739 21 First PDU of the iSNS message 1740 22-31 RESERVED 1742 5.1.5 iSNSP Transaction ID 1744 The TRANSACTION ID MUST be set to a unique value for each 1745 concurrently outstanding request message. Replies MUST use the same 1746 TRANSACTION ID value as the associated iSNS request message. If a 1747 message is retransmitted, the original TRANSACTION ID value MUST be 1748 used. All PDUs comprising an iSNSP message must have the same 1749 TRANSACTION ID value. 1751 5.1.6 iSNSP Sequence ID 1753 The SEQUENCE ID has a unique value for each PDU within a single 1754 transaction. The SEQUENCE_ID value of the first PDU transmitted in 1755 a given iSNS message MUST be zero (0), and each SEQUENCE_ID value in 1756 each PDU MUST be numbered sequentially in the order that the PDUs 1757 are transmitted. Note that the two-byte SEQUENCE ID allows for up 1758 to 65536 PDUs per iSNS message. 1760 5.2 iSNSP Message Segmentation and Reassembly 1762 iSNS messages may be carried in one or more iSNS PDUs. If only one 1763 iSNS PDU is used to carry the iSNS message, then bit 21 (First PDU) 1764 and bit 20 in the FLAGS field (Last PDU) SHALL both be set. If 1765 multiple PDUs are used to carry the iSNS message, then bit 21 SHALL 1766 be set in the first PDU of the message, and bit 20 SHALL be set in 1767 the last PDU. 1769 All PDUs comprising the same iSNSP message SHALL have the same 1770 FUNCTION_ID and TRANSACTION_ID values. Each PDU comprising an iSNSP 1771 message SHALL have a unique SEQUENCE_ID value. 1773 5.3 iSNSP PDU Payload 1775 The iSNSP PDU PAYLOAD is variable length and contains attributes 1776 used for registration and query operations. The attribute data 1777 Internet Storage Name Service (iSNS) February 2004 1779 items use a format similar to other protocols, such as DHCP [RFC 1780 2131] options. Each iSNS attribute is specified in the PDU Payload 1781 using Tag-Length-Value (TLV) data format, as shown below: 1783 Byte MSb LSb 1784 Offset 0 31 1785 +--------------------------------------------+ 1786 0 | Attribute Tag | 4 Bytes 1787 +--------------------------------------------+ 1788 4 | Attribute Length (N) | 4 Bytes 1789 +--------------------------------------------+ 1790 8 | | 1791 | Attribute Value | N Bytes 1792 | | 1793 +--------------------------------------------+ 1794 Total Length = 8 + N 1796 Attribute Tag - a 4-byte field that identifies the attribute as 1797 defined in section 6.1. This field contains the tag value from the 1798 indicated table. 1800 Attribute Length - a 4-byte field that indicates the length, in 1801 bytes, of the value field to follow in the TLV. For variable-length 1802 attributes, the value field MUST contain padding bytes, if 1803 necessary, in order to achieve 4-byte alignment. A "zero-length 1804 TLV" contains only the attribute tag and length fields. 1806 Attribute Value - a variable-length field containing the attribute 1807 value and padding bytes (if necessary). 1809 The above format is used to identify each attribute in the PDU 1810 Payload. Note that TLV boundaries need not be aligned with PDU 1811 boundaries; PDUs may carry one or more TLVs, or any fraction 1812 thereof. The Response Status Code, contained in response message 1813 PDU Payloads and described below, is not in TLV format. PDU 1814 Payloads for messages that do not contain iSNS attributes, such as 1815 the Name Service Heartbeat, do not use the TLV format. 1817 5.3.1 Attribute Value 4-Byte Alignment 1819 All attribute values are aligned to 4 byte boundaries. For variable 1820 length attributes, if necessary, the TLV length MUST be increased to 1821 the next 4-byte boundary through padding with bytes containing zero 1822 (0). If an attribute value is padded, a combination of the tag and 1823 attribute value itself, is used to determine the actual value length 1824 and number of pad bytes. There is no explicit count of the number 1825 of pad bytes provided in the TLV. 1827 5.4 iSNSP Response Status Codes 1829 All iSNSP response messages contain a 4-byte Status Code field as 1830 the first field in the iSNSP PDU PAYLOAD. If the original iSNSP 1831 request message was processed normally by the iSNS server, or by the 1832 iSNS client for ESI and SCN messages, then this field SHALL contain 1833 Internet Storage Name Service (iSNS) February 2004 1835 a status code of 0 (Successful). A non-zero status code indicates 1836 rejection of the entire iSNS client request message. 1838 Status Code Status Description 1839 ----------- ----------------- 1840 0 Successful 1841 1 Unknown Error 1842 2 Message Format Error 1843 3 Invalid Registration 1844 4 RESERVED 1845 5 Invalid Query 1846 6 Source Unknown 1847 7 Source Absent 1848 8 Source Unauthorized 1849 9 No Such Entry 1850 10 Version Not Supported 1851 11 Internal Error 1852 12 Busy 1853 13 Option Not Understood 1854 14 Invalid Update 1855 15 Message (FUNCTION_ID) Not Supported 1856 16 SCN Event Rejected 1857 17 SCN Registration Rejected 1858 18 Attribute Not Implemented 1859 19 FC_DOMAIN_ID Not Available 1860 20 FC_DOMAIN_ID Not Allocated 1861 21 ESI Not Available 1862 22 Invalid Deregistration 1863 23 Registration Feature Not Supported 1864 24 And Above RESERVED 1866 5.5 Authentication for iSNS Multicast and Broadcast Messages 1868 For iSNS multicast and broadcast messages (see section 2.9.3), the 1869 iSNSP provides authentication capability. The following section 1870 details the iSNS Authentication Block, which is identical in format 1871 to the SLP authentication block [RFC2608]. iSNS unicast messages 1872 SHOULD NOT include the authentication block, but rather should rely 1873 upon IPSec security mechanisms. 1875 If a message contains an authentication block, then the 1876 "Authentication block present" bit in the iSNSP PDU header FLAGS 1877 field SHALL be enabled. 1879 If a PKI is available with an X.509 Certificate Authority (CA), then 1880 public key authentication of the iSNS server is possible. The 1881 authentication block leverages the DSA with SHA-1 algorithm, which 1882 can easily integrate into a public key infrastructure. 1884 The authentication block contains a digital signature for the 1885 multicast message. The digital signature is calculated on a per-PDU 1886 basis. The authentication block contains the following information: 1888 1. A time stamp, to prevent replay attacks 1889 Internet Storage Name Service (iSNS) February 2004 1891 2. A structured authenticator containing a signature calculated 1892 over the time stamp and the message being secured 1893 3. An indicator of the cryptographic algorithm that was used to 1894 calculate the signature. 1895 4. An indicator of the keying material and algorithm parameters, 1896 used to calculate the signature. 1898 The authentication block is described in the following figure: 1900 Byte MSb LSb 1901 Offset 0 31 1902 +----------------------------------+ 1903 0 | BLOCK STRUCTURE DESCRIPTOR | 4 Bytes 1904 +----------------------------------+ 1905 4 | AUTHENTICATION BLOCK LENGTH | 4 Bytes 1906 +----------------------------------+ 1907 8 | TIMESTAMP | 8 Bytes 1908 +----------------------------------+ 1909 16 | SPI STRING LENGTH | 4 Bytes 1910 +----------------------------------+ 1911 20 | SPI STRING | N Bytes 1912 +----------------------------------+ 1913 20 + N | STRUCTURED AUTHENTICATOR | M Bytes 1914 +----------------------------------+ 1915 Total Length = 20 + N + M 1917 BLOCK STRUCTURE DESCRIPTOR (BSD) - Defines the structure and 1918 algorithm to use for the STRUCTURED AUTHENTICATOR. BSD values from 1919 0x00000000 to 0x00007FFF are assigned by IANA, while values 1920 0x00008000 to 0x00008FFF are for private use. 1922 AUTHENTICATION BLOCK LENGTH - Defines the length of the 1923 authentication block, beginning with the BSD field and running 1924 through the last byte of the STRUCTURED AUTHENTICATOR. 1926 TIMESTAMP - This is an 8-byte unsigned, fixed-point integer giving 1927 the number of seconds since 00:00:00 GMT on January 1, 1970. 1929 SPI STRING LENGTH - The length of the SPI STRING field. 1931 SPI STRING (Security Parameters Index) - Index to the key and 1932 algorithm used by the message recipient to decode the STRUCTURED 1933 AUTHENTICATOR field. 1935 STRUCTURED AUTHENTICATOR - Contains the digital signature. For the 1936 default BSD value of 0x0002, this field SHALL contain the binary 1937 ASN.1 encoding of output values from the DSA with SHA-1 signature 1938 calculation as specified in section 2.2.2 of [RFC3279]. 1940 5.6 Registration and Query Messages 1942 The iSNSP registration and query message PDU Payloads contain a list 1943 of attributes, and have the following format: 1945 Internet Storage Name Service (iSNS) February 2004 1947 +----------------------------------------+ 1948 | Source Attribute (Requests Only) | 1949 +----------------------------------------+ 1950 | Message Key Attribute[1] (if present) | 1951 +----------------------------------------+ 1952 | Message Key Attribute[2] (if present) | 1953 +----------------------------------------+ 1954 | . . . | 1955 +----------------------------------------+ 1956 | - Delimiter Attribute - | 1957 +----------------------------------------+ 1958 | Operating Attribute[1] (if present) | 1959 +----------------------------------------+ 1960 | Operating Attribute[2] (if present) | 1961 +----------------------------------------+ 1962 | Operating Attribute[3] (if present) | 1963 +----------------------------------------+ 1964 | . . . | 1965 +----------------------------------------+ 1967 Each Source, Message Key, Delimiter, and Operating attribute is 1968 specified in the PDU Payload using Tag-Length-Value (TLV) data 1969 format. iSNS Registration and Query messages are sent by iSNS 1970 Clients to iSNS server IP Address and well-known TCP/UDP Port. The 1971 iSNS Responses will be sent to the iSNS Client IP address and 1972 TCP/UDP port number from the original request message. 1974 5.6.1 Source Attribute 1976 The Source Attribute is used to identify the Storage Node to the 1977 iSNS server for queries and other messages that require source 1978 identification. The Source Attribute uniquely identifies the source 1979 of the message. Valid Source Attribute types are shown below. 1981 Valid Source Attributes 1982 ----------------------- 1983 iSCSI Name 1984 FC Port Name WWPN 1986 For a query operation, the Source Attribute is used to limit the 1987 scope of the specified operation to the Discovery Domains of which 1988 the source is a member. Special Control Nodes, identified by the 1989 Source Attribute, may be administratively configured to perform the 1990 specified operation on all objects in the iSNS database without 1991 scoping to Discovery Domains. 1993 For messages that change the contents of the iSNS database, the iSNS 1994 server MUST verify that the Source Attribute identifies either a 1995 Control Node, or a Storage Node that is a part of the Network Entity 1996 containing the added, deleted, or modified objects. 1998 Internet Storage Name Service (iSNS) February 2004 2000 5.6.2 Message Key Attributes 2002 Message Key attributes are used to identify matching objects in the 2003 iSNS database for iSNS query and registration messages. If present, 2004 the Message Key MUST be a Registration or Query Key for an object as 2005 described in sections 5.6.5 and 6.1. A Message Key is not required 2006 when a query spans the entire set of objects available to the Source 2007 or a registration is for a new Entity. 2009 iSCSI Names used in the Message Key MUST be normalized according to 2010 the stringprep template [STRINGPREP]. Entity Identifiers (EIDs) 2011 used in the Message Key MUST be normalized according to the nameprep 2012 template [NAMEPREP]. 2014 5.6.3 Delimiter Attribute 2016 The Delimiter Attribute separates the Message Key attributes from 2017 the Operating Attributes in a PDU Payload. The Delimiter Attribute 2018 has a tag value of 0 and a length value of 0. The Delimiter 2019 Attribute is always 8 Bytes long (a 4 byte tag field and a 4 byte 2020 length field, all containing zeros). If a Message Key is not 2021 required for a message, then the Delimiter Attribute immediately 2022 follows the Source Attribute. 2024 5.6.4 Operating Attributes 2026 The Operating Attributes are a list of one or more key and non-key 2027 attributes related to the actual iSNS registration or query 2028 operation being performed. 2030 Operating Attributes include object key attributes and non-key 2031 attributes. Object key attributes uniquely identify iSNS objects. 2032 Key attributes MUST precede the non-key attributes of each object in 2033 the Operating Attributes. The tag value distinguishes the attribute 2034 as an object key attribute (i.e., tag=1, 16&17, 32, 64, and 96) or 2035 non-key attribute. iSCSI Names used in the Operating Attributes MUST 2036 be normalized according to the stringprep template [STRINGPREP]. 2037 Entity Identifiers (EIDs) used in the Operating Attributes MUST be 2038 normalized according to the nameprep template [NAMEPREP]. 2040 The ordering of Operating Attributes in the message is important in 2041 determining the relationships among objects and their ownership of 2042 non-key attributes. iSNS protocol messages that violate these 2043 ordering rules SHALL be rejected with the Status Code of 2 (Message 2044 Format Error). See the message descriptions for proper operating 2045 attribute ordering requirements. 2047 Some objects are keyed by more than one object key attribute value. 2048 For example, the Portal object is keyed by attribute tags 16 and 17. 2049 When describing an object keyed by more than one key attribute, each 2050 and every object key attribute of that object MUST be listed 2051 sequentially by tag value in the message before non-key attributes 2052 of that object, and key attributes of the next object. A group of 2053 Internet Storage Name Service (iSNS) February 2004 2055 key attributes of this kind is treated as a single logical key 2056 attribute when identifying an object. 2058 Non-key attributes that immediately follow key attributes MUST be 2059 attributes of the object referenced by the key attributes. All non- 2060 key attributes of an object MUST be listed before the object key 2061 attributes introducing the next object. 2063 Objects MUST be listed in inheritance order, according to their 2064 containment order. Storage Node and Portal objects and their 2065 respective attributes MUST follow the Network Entity object to which 2066 they have a relationship. Similarly, FC Device objects MUST follow 2067 the Storage Node object to which they have a relationship. 2069 Vendor-specific objects defined by tag values in the range 1537-2048 2070 have the same requirements described above. 2072 5.6.4.1 Operating Attributes for Query and Get Next Requests 2074 In Query and Get Next request messages, TLV attributes with length 2075 value of 0 are used to indicate which Operating Attributes are to be 2076 returned in the corresponding response. Operating Attribute values 2077 that match the TLV attributes in the original message are returned 2078 in the response message. 2080 5.6.5 Registration and Query Request Message Types 2082 The following describes each query and message type. 2084 5.6.5.1 Device Attribute Registration Request (DevAttrReg) 2086 The DevAttrReg message type is 0x0001. The DevAttrReg message 2087 provides the means for iSNS clients to update existing objects or 2088 register new objects. The value of the replace bit in the FLAGs 2089 field determines whether the DevAttrReg message updates or replaces 2090 an existing registration. 2092 The Source Attribute identifies the Node initiating the registration 2093 request. 2095 The Message Key identifies the object that the DevAttrReg message 2096 acts upon. It MUST contain the key attribute(s) identifying an 2097 object. This object MUST contain all attributes and related 2098 subordinate object attributes that will be included in the Operating 2099 Attributes of the DevAttrReg PDU Payload. The key attribute(s) 2100 identifying this object MUST also be included among the Operating 2101 Attributes. 2103 If the Message Key contains an EID, and no pre-existing objects 2104 match the Message Key, then the DevAttrReg message SHALL create a 2105 new Entity with the specified EID and any new object(s) specified by 2106 the Operating Attributes. The replace bit SHALL be ignored 2107 Internet Storage Name Service (iSNS) February 2004 2109 If the Message Key does not contain an EID, and no pre-existing 2110 objects match the Message Key, then the DevAttrReg message SHALL be 2111 rejected with a status code of 3 (Invalid Registration). 2113 If the Message Key is not present, then the DevAttrReg message 2114 implicitly registers a new Network Entity. In this case, the 2115 replace bit SHALL be ignored; a new Network Entity SHALL be created. 2116 Existing entities, their objects, and their relationships remain 2117 unchanged. 2119 The replace bit determines the kind of operation conducted on the 2120 object identified in the DevAttrReg Message Key. The replace bit 2121 only applies to the DevAttrReg message; it is ignored for all other 2122 message types. 2124 If the replace bit is set, then the objects, attributes, and 2125 relationships specified in the Operating Attributes SHALL replace 2126 the object identified by the Message Key. The object and all of its 2127 subordinate objects SHALL be deregistered and the appropriate SCNs 2128 SHALL be sent by the iSNS server for the deregistered objects. The 2129 objects listed in the Operating Attributes are then used to replace 2130 the just-deregistered objects. Note that additional SCNs SHALL be 2131 sent for the newly-registered objects, if appropriate. Existing 2132 objects and relationships that are not identified or are subordinate 2133 to the object identified by the Message Key MUST NOT be affected or 2134 changed. 2136 If the replace bit is not set, then the message updates the 2137 attributes of the object identified by the Message Key and its 2138 subordinate objects. Existing object containment relationships MUST 2139 NOT be changed. For existing objects, key attributes MUST NOT be 2140 modified, but new subordinate objects MAY be added. 2142 The Operating Attributes represent objects, attributes, and 2143 relationships that are to be registered. Multiple related objects 2144 and attributes MAY be registered in a single DevAttrReg message. 2145 The ordering of the objects in this message indicates the structure 2146 of, and associations among, the objects to be registered. At least 2147 one object MUST be listed in the Operating Attributes. Additional 2148 objects (if any) MUST be subordinate to the first object listed. 2149 Key attributes MUST precede non-key attributes of each object. A 2150 given object may only appear a maximum of once in the Operating 2151 Attributes of a message. If the Node identified by the Source 2152 Attribute is not a Control Node, then the objects in the operating 2153 attributes MUST be members of the same Network Entity as the Source 2154 Node. 2156 For example, to establish relationships between a Network Entity 2157 object and its Portal and Storage Node objects, the Operating 2158 Attributes lists the key and non-key attributes of the Network 2159 Entity object, followed by the key and non-key attributes of each 2160 Portal and Storage Node object to be linked to that Network Entity. 2161 Similarly, an FC Device object that follows a Storage Node object is 2162 Internet Storage Name Service (iSNS) February 2004 2164 considered to have a subordinate relationship with that Storage 2165 Node. 2167 New PG objects are registered when an associated Portal or iSCSI 2168 Node object is registered. An explicit PG object registration MAY 2169 follow a Portal or iSCSI Node object registration in a DevAttrReg 2170 message. 2172 When a Portal is registered, then the Portal attributes MAY 2173 immediately be followed by a PGT attribute. The PGT attribute SHALL 2174 be followed by the set of PG iSCSI Names representing nodes that 2175 will be associated to the Portal using the indicated PGT value. 2176 Additional sets of PGTs and PG iSCSI Names to be associated to the 2177 registered Portal MAY follow. Indicated PGT values are assigned to 2178 the PG object associated with the newly registered Portal and the 2179 iSCSI Storage Node(s) referenced immediately following the PGT 2180 attribute in the operating attributes. 2182 When an iSCSI Storage Node is registered, then the Storage Node 2183 attributes MAY immediately be followed by a PGT attribute. The PGT 2184 attribute SHALL be followed by the set of PG Portal IP-Address, PG 2185 TCP/UDP Port pairs representing Portal objects that will be 2186 associated with the Storage Node using the indicated PGT value. 2187 Additional sets of PGTs and PG Portal IP-Address PG TCP/UDP Port 2188 pairs to be associated with the registered Storage Node MAY follow. 2189 Indicated PGT values are assigned to the PG object associated with 2190 the newly registered iSCSI Storage Node and Portal object(s) 2191 referenced immediately following the PGT attribute in the operating 2192 attributes. 2194 If the PGT value is not included in the Storage Node or Portal 2195 object registration, and a PGT value was not previously registered 2196 for the relationship, then the PGT for the corresponding PG object 2197 SHALL be registered with a value of 0x00000001. If the PGT 2198 attribute is included in the registration message as a 0-length TLV, 2199 then the PGT value for the corresponding PG object SHALL be 2200 registered as NULL. A 0-length TLV for the PGT in an update 2201 registration message overwrites the previous PGT value with NULL, 2202 indicating that there is no relationship between the Storage Node 2203 and Portal. 2205 A maximum of one Network Entity object can be created or updated 2206 with a single DevAttrReg message. Consequently, the Operating 2207 Attributes MUST NOT contain more than one Network Entity object. 2208 There is no limit to the number of Portal, Storage Node, and FC 2209 Device objects that can listed in the Operating Attributes, provided 2210 they are all subordinate to the listed Network Entity object. 2212 If the Message Key and Operating Attributes do not contain an EID 2213 attribute, or if the EID attribute has a length of 0, then a new 2214 Network Entity object SHALL be created and the iSNS server SHALL 2215 supply a unique EID value for it. The assigned EID value SHALL be 2216 included in the DevAttrReg Response message. If the Message Key and 2217 Operating Attributes contain an EID that does not match the EID of 2218 Internet Storage Name Service (iSNS) February 2004 2220 an existing Network Entity in the iSNS database, then a new Network 2221 Entity SHALL be created and assigned the value contained in that EID 2222 attribute. Finally, if the Message Key and Operating Attributes 2223 contain an EID that matches the EID of an existing object in the 2224 iSNS database, then the objects, attributes, and relationships 2225 specified in the Operating Attributes SHALL be appended to the 2226 existing Network Entity identified by the EID. 2228 A registration message that creates a new Network Entity object MUST 2229 contain at least one Portal or one Storage Node. If the message 2230 does not, then it SHALL be considered invalid and result in a 2231 response with Status Code of 3 (Invalid Registration). 2233 If an iSNS Server does not support a registration feature, such as 2234 explicit PG object registration, then the server SHALL return a 2235 Status Code of 23 (Registration Feature Not Supported). 2237 Note that the iSNS server may modify or reject the registration of 2238 certain attributes, such as ESI Interval. In addition, the iSNS 2239 server may assign values for additional Operating Attributes that 2240 are not explicitly registered in the original DevAttrReg message, 2241 such as the EID and WWNN Token. 2243 5.6.5.2 Device Attribute Query Request (DevAttrQry) 2245 The DevAttrQry message type is 0x0002. The DevAttrQry message 2246 provides an iSNS client with the means to query the iSNS server for 2247 object attributes. 2249 The Source Attribute identifies the Node initiating the request. 2250 For non-Control Nodes initiating the DevAttrQry message, the query 2251 is scoped to the Discovery Domains that initiating Node is a member 2252 of. The DevAttrQry message SHALL only return information on Storage 2253 Nodes and their related parent and subordinate objects, where the 2254 Storage Node has a common Discovery Domain with the Node identified 2255 in the Source Attribute. 2257 The Message Key may contain key or non-key attributes or no 2258 attributes at all. If multiple attributes are used as the Message 2259 Key, then they MUST all be from the same object type (e.g., IP 2260 address and TCP/UDP Port are attributes of the Portal object type). 2261 A Message Key with non-key attributes may match multiple instances 2262 of the specific object type. A Message Key with zero-length TLV(s) 2263 is scoped to every object of the type indicated by the zero-length 2264 TLV(s). An empty Message Key field indicates the query is scoped to 2265 the entire database accessible by the source Node. 2267 The DevAttrQry response message returns attributes of objects listed 2268 in the Operating Attributes that are related to the Message Key of 2269 the original DevAttrQry message. The Operating Attributes of the 2270 DevAttrQry message contain zero-length TLVs that specify the 2271 attributes that are to be returned in the DevAttrQryRsp message. A 2272 Message Key containing zero-length TLVs indicates that the set of 2273 Internet Storage Name Service (iSNS) February 2004 2275 attributes specified in the Operating Attributes are to be returned 2276 for each object matching the type indicated by the Message Key. 2278 If the Message Key contains non-zero length TLVs, then Operating 2279 Attributes for the object matching the Message Key SHALL be returned 2280 in the DevAttrQryRsp message. Each attribute type (i.e., zero- 2281 length TLV) in the Operating Attributes indicates an attribute from 2282 the object matching the Message Key, or other objects in the same 2283 Entity having a relationship to the object matching the Message Key, 2284 is to be returned in the response. The ordering of the object keys 2285 and associated attributes returned in the DevAttrQry response 2286 message SHALL be the same as in the original query message. If no 2287 objects match the Message Key, then the DevAttrQryRsp message SHALL 2288 NOT return any operating attributes. Such a message and its 2289 corresponding response SHALL NOT be considered to be an error. 2291 The Portal Group object determines whether a relationship exists 2292 between a given Storage Node and Portal object. If the PGT of the 2293 Portal Group is not NULL, then a relationship exists between the 2294 indicated Storage Node and Portal; if the PGT is NULL, then no 2295 relationship exists. Therefore, the value (NULL or not NULL) of the 2296 PGT attribute of each Portal Group object determines the structure 2297 and ordering of the DevAttrQry response to a query for Storage Nodes 2298 and Portals. 2300 For example, an iSNS database contains a Network Entity having two 2301 Portals and two Nodes. Each Storage Node has two Portal Groups, one 2302 with a NULL PGT value for one Portal and another with a non-NULL PGT 2303 value for the other Portal. The DevAttrQry message contains a 2304 Message Key entry matching one of the Nodes, and Operating 2305 Attributes with zero-length TLVs listing first the Node attributes, 2306 Portal attributes, and then the PG attributes. The response message 2307 SHALL therefore return first the matching Node object, followed by 2308 the requested attributes of the one Portal object that can be used 2309 to access the Storage Node (as indicated by the PGT), and finally 2310 the requested attributes of the PG object used to access that 2311 Storage Node. The order in which each object's attributes are 2312 listed is the same as the ordering of the object's attributes in the 2313 Operating Attributes of the original request message. 2315 If the Message Key Attribute contains zero-length TLV(s), then the 2316 query returns requested attributes for all objects matching the 2317 Message Key type (DD restrictions SHALL apply for non-Control 2318 Nodes). If multiple objects match the Message Key type, then the 2319 attributes for each object matching the Message Key MUST be listed 2320 before the attributes for the next matching object are listed in the 2321 query response. In other words, the process described above must be 2322 iterated in the message response for each object that matches the 2323 Message Key type specified by the zero-length TLV(s). 2325 For example, an iSNS database contains only one Network Entity 2326 having two Portals and three Nodes. All PG objects in the Entity 2327 have a PGT value of 0x00000001. In the DevAttrQry message, the 2328 Message Key contains a zero-length TLV specifying a Node type, and 2329 Internet Storage Name Service (iSNS) February 2004 2331 Operating Attributes listing first the Node attributes, and then the 2332 Portal attributes. The response message will return the first Node 2333 attributes, followed by both Portals attributes, and then attributes 2334 for the next Node object followed by those for the same two Portals, 2335 and then finally attributes for the last Node object followed by 2336 those for the same two Portals. If that same DevAttrQry message had 2337 instead contained a zero-length TLV specifying the Network Entity 2338 type, then the response message would have returned attributes for 2339 all three Node objects, followed by attributes for the two Portals. 2341 If there is no Message Key Attribute, then the query returns all 2342 attributes in the iSNS database (once again, DD restrictions SHALL 2343 apply for non-Control Nodes). All attributes matching the type 2344 specified by each zero-length TLV in the Operating Attributes SHALL 2345 be listed. All attributes of each type SHALL be listed before the 2346 attributes matching the next zero-length TLV are listed. 2348 For example, an iSNS database contains two Entities, each having two 2349 Nodes and two Portals. The DevAttrQry message contains no Message 2350 Key attribute, and Operating Attributes list first the Portal 2351 attributes, and then the Node attributes. The Operating Attributes 2352 of the response message will return attributes from each of the four 2353 Portals, followed by attributes from each of the four nodes. 2355 If a DevAttrQry message requests an attribute for which the iSNS 2356 server has no value, then the server SHALL NOT return the requested 2357 attribute in the query response. Such query and response messages 2358 SHALL NOT be considered to be in error. 2360 Registration and query messages for iSNS server-specific attributes 2361 (i.e., tags in the range 132 to 384) SHALL be formatted using the 2362 identifying key attribute of the Storage Node originating the query 2363 (i.e., iSCSI Name or FC Port Name WWPN) for both the Source 2364 Attribute and Message Key attribute. Operating Attributes SHALL 2365 include the TLV of the server-specific attribute being requested. 2367 DD membership can be discovered through the DevAttrQry message by 2368 including either DD member attributes (i.e., DD Member iSCSI Index, 2369 DD Member iSCSI Node, DD Member iFCP Node, DD Member Portal Index, 2370 DD Member Portal IP Addr, and DD Member Portal TCP/UDP) or the 2371 object key of the Storage Node or Portal (i.e., iSCSI Name, iSCSI 2372 Index, Portal IP Addr, Portal TCP/UDP Port, and Portal Index) in the 2373 Operating Attributes. Using DD member attributes SHALL return both 2374 registered and unregistered member Storage Nodes and/or Portals of a 2375 DD. DevAttrQry messages using the Storage Node and/or Portal object 2376 key SHALL return only member Storage Nodes or Portals that are 2377 currently registered in the iSNS database. 2379 The DevAttrQry message SHALL support the following minimum set of 2380 Message Key Attributes: 2382 Internet Storage Name Service (iSNS) February 2004 2384 Valid Message Key Attributes for Queries 2385 ---------------------------------------- 2386 Entity Identifier 2387 Entity Protocol 2388 Portal IP-Address & Portal TCP/UDP Port 2389 Portal Index 2390 iSCSI Node Type 2391 iSCSI Name 2392 iSCSI Index 2393 PG Index 2394 FC Port Name WWPN 2395 FC Port Type 2396 FC-4 Type 2397 Discovery Domain ID 2398 Discovery Domain Set ID 2399 Source Attribute (for server-specific attributes) 2400 Switch Name (FC Device WWNN--for Virtual_Fabric_ID queries) 2402 5.6.5.3 Device Get Next Request (DevGetNext) 2404 The DevGetNext message type is 0x0003. This message provides the 2405 iSNS client with the means to retrieve each and every instance of an 2406 object type exactly once. 2408 The Source Attribute identifies the Node initiating the DevGetNext 2409 request, and is used to scope the retrieval process to the Discovery 2410 Domains that the initiating Node is a member of. 2412 The Message Key Attribute may be an Entity Identifier (EID), iSCSI 2413 Name, iSCSI Index, Portal IP Address and TCP/UDP Port, Portal Index, 2414 PG Index, FC Node Name WWNN, or FC Port Name WWPN. If the TLV 2415 length of the Message Key Attribute(s) is zero, then the first 2416 object entry in the iSNS database matching the Message Key type 2417 SHALL be returned in the Message Key of the corresponding 2418 DevGetNextRsp message. If non-zero-length TLV attributes are 2419 contained in the Message Key, then the DevGetNext response message 2420 SHALL return the next object stored after the object identified by 2421 the Message Key in the original DevGetNext request message. 2423 If the Message Key provided matches the last object instance in the 2424 iSNS database, then the Status Code of 9 (No Such Entry) SHALL be 2425 returned in the response. 2427 The Operating Attributes can be used specify the scope of the 2428 DevGetNext request, and specify the attributes of the next object 2429 that are to be returned in the DevGetNext response message. All 2430 Operating Attributes MUST be attributes of the object type 2431 identified by the Message Key. For example, if the Message Key is 2432 an Entity_ID attribute, then the Operating Attributes MUST NOT 2433 contain attributes of Portals. 2435 Non-zero-length TLV attributes in the Operating Attributes are used 2436 to scope the DevGetNext message. Only the next object with 2437 Internet Storage Name Service (iSNS) February 2004 2439 attribute values that match the non-zero-length TLV attributes SHALL 2440 be returned in the DevGetNext response message. 2442 Zero-length TLV attributes MUST be listed after non-zero-length 2443 attributes in the Operating Attributes of the DevGetNext request 2444 message. Zero-length TLV attributes specify the attributes of the 2445 next object that are to be returned in the DevGetNext response 2446 message. 2448 Note that there are no specific requirements concerning the order in 2449 which object entries are retrieved from the iSNS database; the 2450 retrieval order of object entries using the DevGetNext message is 2451 implementation specific. 2453 The iSNS client is responsible for ensuring that information 2454 acquired through use of the DevGetNext message is accurate and up- 2455 to-date. There is no assurance that the iSNS database will not 2456 change between successive DevGetNext request messages. If the 2457 Message Key provided does not match an existing database entry, then 2458 attributes for the next object key following the Message Key 2459 provided SHALL be returned. For example, an object entry may have 2460 been deleted between successive DevGetNext messages. This may 2461 result in a DevGetNext request where the Message Key does not match 2462 an existing object entry. In this case, attributes for the next 2463 object stored in the iSNS database are returned. 2465 5.6.5.4 Device Deregister Request (DevDereg) 2467 The DevDereg message type is 0x0004. This message is used to remove 2468 object entries from the iSNS database. One or more objects may be 2469 removed through a single DevDereg message. Note that deregistered 2470 Storage Node objects will retain membership in their Discovery 2471 Domain(s) until explicit deregistration of the membership(s) or 2472 Discovery Domain(s). 2474 Upon receiving the DevDereg, the iSNS server removes all objects 2475 identified by the Operating Attribute(s), as well as all associated 2476 subordinate objects that are solely dependent on those identified 2477 objects. For example, removal of a Network Entity also results in 2478 removal of all associated Portal, Portal Group, Storage Node, and FC 2479 Device objects associated with that Network Entity. FC Device 2480 objects SHALL not be deregistered in this manner unless all Storage 2481 Nodes associated with them have been deregistered. 2483 The DevDereg request PDU Payload contains a Source Attribute and 2484 Operating Attribute(s); there are no Message Key Attributes. If the 2485 Node identified by the Source Attribute is not a Control Node, then 2486 it MUST be from the same Network Entity as the object(s) identified 2487 for removal by the Operating Attribute(s). Valid Operating 2488 Attributes are shown below: 2490 Internet Storage Name Service (iSNS) February 2004 2492 Valid Operating Attributes for DevDereg 2493 --------------------------------------- 2494 Entity Identifier 2495 Portal IP-Address & Portal TCP/UDP Port 2496 Portal Index 2497 iSCSI Name 2498 iSCSI Index 2499 FC Port Name WWPN 2500 FC Node Name WWNN 2502 The removal of the object may result in SCN messages to the 2503 appropriate iSNS clients. 2505 Attempted deregistration of non-existing entries SHALL not be 2506 considered an error. 2508 If all Nodes and Portals associated with a Network Entity are 2509 deregistered, then the Network Entity SHALL also be removed. 2511 If both the Portal and iSCSI Storage Node objects associated with a 2512 Portal Group object are removed, then that Portal Group object SHALL 2513 also be removed. The Portal Group object SHALL remain registered as 2514 long as either of its associated Portal or iSCSI Storage Node 2515 objects remain registered. If a deleted Storage Node or Portal 2516 object is subsequently re-registered, then a relationship between 2517 the re-registered object and an existing Portal or Storage Node 2518 object registration, indicated by the PG object, SHALL be restored. 2520 5.6.5.5 SCN Register Request (SCNReg) 2522 The SCNReg message type is 0x0005. The State Change Notification 2523 Registration Request (SCNReg) message allows an iSNS client to 2524 register a Storage Node to receive State Change Notification (SCN) 2525 messages. 2527 The SCN notifies the Storage Node of changes to any Storage Nodes 2528 within any DD that it is a member of. If the Storage Node is a 2529 Control Node, it SHALL receive SCN notifications for changes in the 2530 entire network. Note that while SCNReg sets the SCN Bitmap field, 2531 the DevAttrReg message registers the UDP or TCP Port used by each 2532 Portal to receive SCN messages. If no SCN Port fields of any 2533 Portals of the Storage Node are registered to receive SCN messages, 2534 then the SCNReg message SHALL be rejected with Status Code 17 (SCN 2535 Registration Rejected). 2537 The SCNReg request PDU Payload contains a Source Attribute, Message 2538 Key Attribute, and an Operating Attribute. Valid Message Key 2539 Attributes for a SCNReg are shown below: 2541 Internet Storage Name Service (iSNS) February 2004 2543 Valid Message Key Attributes for SCNReg 2544 --------------------------------------- 2545 iSCSI Name 2546 FC Port Name WWPN 2548 The node with the iSCSI Name or FC Port Name WWPN attribute that 2549 matches the Message Key in the SCNReg message is registered to 2550 receive SCNs using the specified SCN bitmap. A maximum of one Node 2551 SHALL be registered for each SCNReg message. 2553 The SCN Bitmap is the only operating attribute of this message, and 2554 it always overwrites the previous contents of this field in the iSNS 2555 database. The bitmap indicates the SCN event types for which the 2556 Node is registering. 2558 Note that the settings of this bitmap determine whether the SCN 2559 registration is for regular SCNs or management SCNs. Control Nodes 2560 MAY conduct registrations for management SCNs; iSNS clients that are 2561 not supporting Control Nodes MUST NOT conduct registrations for 2562 management SCNs. Control Nodes that register for management SCNs 2563 receive a copy of every SCN message generated by the iSNS server. 2564 It is recommended that management registrations be used only where 2565 needed in order to conserve iSNS server resources. In addition, a 2566 Control Node that conducts such registrations should be prepared to 2567 receive the anticipated volume of SCN message traffic. 2569 5.6.5.6 SCN Deregister Request (SCNDereg) 2571 The SCNDereg message type is 0x0006. The SCNDereg message allows an 2572 iSNS client to no longer receive State Change Notification (SCN) 2573 messages. 2575 The SCNDereg request message PDU Payload contains a Source Attribute 2576 and Message Key Attribute(s). Valid Message Key Attributes for a 2577 SCNDereg are shown below: 2579 Valid Message Key Attributes for SCNDereg 2580 ----------------------------------------- 2581 iSCSI Name 2582 FC Port Name WWPN 2584 The node with an iSCSI Name or FC Port Name WWPN attribute that 2585 matches the Message Key Attributes in the SCNDereg message is 2586 deregistered for SCNs. The SCN bitmap field of such Nodes are 2587 cleared. A maximum of one Node SHALL be deregistered for each 2588 SCNDereg message. 2590 There are no Operating Attributes in the SCNDereg message. 2592 5.6.5.7 SCN Event (SCNEvent) 2594 The SCNEvent message type is 0x0007. The SCNEvent is a message sent 2595 by an iSNS client to request generation of a State Change 2596 Notification (SCN) message by the iSNS server. The SCN, sent by the 2597 Internet Storage Name Service (iSNS) February 2004 2599 iSNS server, then notifies iFCP, iSCSI, and Control Nodes within the 2600 affected DD of the change indicated in the SCNEvent. 2602 Most SCNs are automatically generated by the iSNS server when Nodes 2603 are registered or deregistered from the directory database. SCNs 2604 are also generated when a network management application or Control 2605 Node makes changes to the DD membership in the iSNS server. 2606 However, an iSNS client can trigger an SCN by using SCNEvent. 2608 The SCNEvent message PDU Payload contains a Source Attribute, 2609 Message Key Attribute, and Operating Attribute. Valid Key Attributes 2610 for a SCNEvent are shown below: 2612 Valid Message Key Attributes for SCNEvent 2613 ----------------------------------------- 2614 iSCSI Name 2615 FC Port Name WWPN 2617 The Operating Attributes section SHALL contain the SCN Event Bitmap 2618 attribute. The bitmap indicates the event that caused the SCNEvent 2619 to be generated. 2621 5.6.5.8 State Change Notification (SCN) 2623 The SCN message type is 0x0008. The SCN is a message generated by 2624 the iSNS server, notifying a registered Storage Node of changes. 2625 There are two types of SCN registrations: regular registrations and 2626 management registrations. Regular SCNs notify iSNS clients of 2627 events within the discovery domain. Management SCNs notify Control 2628 Nodes that register for management SCNs of events occurring anywhere 2629 in the network. 2631 If no active TCP connection exists to the SCN recipient, then the 2632 SCN message SHALL be sent to one Portal of the registered Storage 2633 Node that has a registered TCP or UDP Port value in the SCN Port 2634 field. If more than one Portal of the Storage Node has a registered 2635 SCN Port value, then the SCN SHALL be delivered to any one of the 2636 indicated Portals, provided that the selected Portal is not the 2637 subject of the SCN. 2639 The types of events that can trigger an SCN message, and the amount 2640 of information contained in the SCN message, depend on the 2641 registered SCN Event Bitmap for the Storage Node. The iSCSI Node 2642 SCN Bitmap is described in Section 6.4.4. The iFCP SCN Bitmap is 2643 described in Section 6.6.12. 2645 The format of the SCN PDU Payload is shown below: 2647 Internet Storage Name Service (iSNS) February 2004 2649 +----------------------------------------+ 2650 | Destination Attribute | 2651 +----------------------------------------+ 2652 | Timestamp | 2653 +----------------------------------------+ 2654 | Source SCN Bitmap 1 | 2655 +----------------------------------------+ 2656 | Source Attribute [1] | 2657 +----------------------------------------+ 2658 | Source Attribute [2](if present) | 2659 +----------------------------------------+ 2660 | Source Attribute [3](if present)_ | 2661 +----------------------------------------+ 2662 | Source Attribute [n](if present) | 2663 +----------------------------------------+ 2664 | Source SCN Bitmap 2 (if present) | 2665 +----------------------------------------+ 2666 | . . . | 2667 +----------------------------------------+ 2669 All PDU Payload attributes are in TLV format. 2671 The Destination Attribute is the Node identifier that is receiving 2672 the SCN. The Destination Attribute can be an iSCSI Name, or FC Port 2673 Name. 2675 The Timestamp field, using the Timestamp TLV format, described in 2676 Section 6.2.4, indicates the time the SCN was generated. 2678 The Source SCN Bitmap field indicates the type of SCN notification 2679 (i.e., regular or management SCN), and the type of event that caused 2680 the SCN to be generated; it does not necessarily correlate with the 2681 original SCN bitmap registered in the iSNS server. 2683 Following the timestamp, the SCN message SHALL list the SCN bitmap, 2684 followed by the key attribute (i.e., iSCSI Name or FC Port Name) of 2685 the Storage Node affected by the SCN event. If the SCN is a 2686 Management SCN, then the SCN message SHALL also list the DD_ID 2687 and/or DDS_ID of the Discovery Domains and Discovery Domain Sets (if 2688 any) that caused the change in state for that Storage Node. These 2689 additional attributes (i.e., DD_ID and/or DDS_ID) shall immediately 2690 follow the iSCSI Name or FC Port Name and precede the next SCN 2691 bitmap for the next notification message (if any). The SCN bitmap 2692 is used as a delineator for SCN messages providing multiple state 2693 change notifications. 2695 For example, a regular SCN to notify an iSNS client of a new Portal 2696 available for a particular iSCSI target would contain the SCN bitmap 2697 followed by the iSCSI Name of the target device as the source 2698 attribute. If the SCN were a management SCN, then the iSCSI Name 2699 would be followed by the DD_ID(s) of the shared Discovery Domains 2700 that allow the destination Storage Node to have visibility to the 2701 affected Storage Node. If a Discovery Domain Set (DDS) was enabled 2702 Internet Storage Name Service (iSNS) February 2004 2704 in order to provide this visibility, then the appropriate DDS_ID 2705 would be included as well. 2707 A management SCN is also generated to notify a Control Node of the 2708 creation, deletion, or modification of a Discovery Domain or 2709 Discovery Domain Set. In this case, the DD_ID and/or DDS_ID of the 2710 affected Discovery Domain and/or Discovery Domain Set would follow 2711 the SCN bitmap. 2713 For example, a management SCN to notify a Control Node of a new DD 2714 within a Discovery Domain Set would contain both the DD_ID and the 2715 DDS_ID of the affected Discovery Domain and Discovery Domain Set 2716 among the Source Attributes. 2718 See sections 6.4.4 and 6.6.12 for additional information on the SCN 2719 Bitmap. 2721 5.6.5.9 DD Register (DDReg) 2723 The DDReg message type is 0x0009. This message is used to create a 2724 new Discovery Domain (DD), update an existing DD Symbolic Name 2725 and/or DD Features attribute, and add DD members. 2727 DDs are uniquely defined using DD_IDs. DD registration attributes 2728 are described in section 6.11. 2730 The DDReg message PDU Payload contains the Source Attribute and 2731 optional Message Key and Operating Attributes. 2733 The Message Key, if used, contains the DD_ID of the Discovery Domain 2734 to be registered. If the Message Key contains a DD_ID of an 2735 existing DD entry in the iSNS database, then the DDReg message SHALL 2736 attempt to update the existing entry. If the DD_ID in the Message 2737 Key (if used) does not match an existing DD entry, then the iSNS 2738 server SHALL reject the DDReg message with a status code of 3 2739 (Invalid Registration). If the DD_ID is included in both the 2740 Message Key and Operating Attributes, then the DD_ID value in the 2741 Message Key MUST be the same as the DD_ID value in the Operating 2742 Attributes. 2744 A DDReg message with no Message Key SHALL result in the attempted 2745 creation of a new Discovery Domain (DD). If the DD_ID attribute 2746 (with non-zero length) is included among the Operating Attributes in 2747 the DDReg message, then the new Discovery Domain SHALL be assigned 2748 the value contained in that DD_ID attribute. Otherwise, if the 2749 DD_ID attribute is not contained among the Operating Attributes of 2750 the DDReg message, or if the DD_ID is an operating attribute with 2751 TLV length of 0, then the iSNS server SHALL assign a DD_ID value. 2752 The assigned DD_ID value is then returned in the DDReg Response 2753 message. The Operating Attributes can also contain the DD Member 2754 iSCSI Node Index, DD Member iSCSI Name, DD Member FC Port Name, DD 2755 Member Portal IP Address, DD Member Portal TCP/UDP Port Number, or 2756 DD Member Portal Index of members to be added to the DD. It may 2757 also contain the DD_Symbolic_Name and/or DD_Features of the DD. 2759 Internet Storage Name Service (iSNS) February 2004 2761 This message SHALL add any DD members listed as Operating Attributes 2762 to the Discovery Domain specified by the DD_ID. If the DD_Features 2763 attribute is an Operating Attribute, then it SHALL be stored in the 2764 iSNS server as the feature list for the specified DD. If the 2765 DD_Symbolic_Name is an operating attribute and its value is unique 2766 (i.e., does not match the registered DD_Symbolic_Name for another 2767 DD, then the value SHALL be stored in the iSNS database as the 2768 DD_Symbolic_Name for the specified Discovery Domain. If the value 2769 for the DD_Symbolic_Name is not unique, then the iSNS server SHALL 2770 reject the attempted DD registration with a status code of 3 2771 (Invalid Registration). 2773 When creating a new DD, if the DD_Symbolic_Name is not included in 2774 the Operating Attributes, or if it is included with a zero-length 2775 TLV, then the iSNS server SHALL provide a unique DD_Symbolic_Name 2776 value for the created DD. The assigned DD_Symbolic_Name value SHALL 2777 be returned in the DDRegRsp message. 2779 When creating a new DD, if the DD_Features attribute is not included 2780 in the Operating Attributes, then the iSNS server SHALL assign the 2781 default value. The default value for DD_Features is 0. 2783 DD Member iSCSI Name, DD Member iFCP Node, DD Member Portal IP 2784 Address, and DD Member TCP/UDP Port Number attributes included in 2785 the Operating Attributes need not to match currently existing iSNS 2786 database entries. This allows, for example, a Storage Node to be 2787 added to a DD even if the Storage Node is not currently registered 2788 in the iSNS database. A Storage Node or Portal can thereby be added 2789 to a DD at the time of the DDs creation, even if the Storage Node or 2790 Portal is not currently active in the storage network. 2792 If the Operating Attributes contain a DD Member iSCSI Name value for 2793 a Storage Node that is currently not registered in the iSNS 2794 database, then the iSNS server MUST allocate an unused iSCSI Node 2795 Index for that Storage Node. The assigned iSCSI Node Index SHALL be 2796 returned in the DDRegRsp message as the DD Member iSCSI Node Index. 2797 The allocated iSCSI Node Index value SHALL be assigned to the 2798 Storage Node if and when it registers in the iSNS database. 2800 If the Operating Attributes contain a DD Member Portal IP Addr and 2801 DD Member Portal TCP/UDP value for a Portal that is not currently 2802 registered in the iSNS database, then the iSNS server MUST allocate 2803 an unused Portal Index value for that Portal. The assigned Portal 2804 Index value SHALL be returned in the DDRegRsp message as the DD 2805 Member Portal Index. The allocated Portal Index value SHALL be 2806 assigned to the Portal if and when it registers in the iSNS 2807 database. 2809 DD Member iSCSI Node Index and DD Member Portal Index attributes 2810 that are provided in the Operating Attributes MUST match a 2811 corresponding iSCSI Node Index or Portal Index of an existing 2812 Storage Node or Portal entry in the iSNS database. Furthermore, the 2813 DD Member iSCSI Node Index and DD Member Portal Index SHALL NOT be 2814 Internet Storage Name Service (iSNS) February 2004 2816 used to add Storage Nodes or Portals to a DD unless those Storage 2817 Nodes or Portals are actively registered in the iSNS database. 2819 5.6.5.10 DD Deregister (DDDereg) 2821 The DDDereg message type is 0x000A. This message allows an iSNS 2822 client to deregister an existing Discovery Domain (DD) and remove 2823 members from an existing DD. 2825 DDs are uniquely identified using DD_IDs. DD registration 2826 attributes are described in section 6.11. 2828 The DDDereg message PDU Payload contains a Source Attribute, Message 2829 Key Attribute, and optional Operating Attributes. 2831 The Message Key Attribute for a DDDereg message is the DD ID for the 2832 Discovery Domain being removed, or having members removed. If the 2833 DD ID matches an existing DD, and there are no Operating Attributes, 2834 then the DD SHALL be removed and a success Status Code returned. 2835 Any existing members of that DD SHALL remain in the iSNS database 2836 without membership in the just-removed DD. 2838 If the DD ID matches an existing DD, and there are Operating 2839 Attributes matching DD members, then the DD members identified by 2840 the Operating Attributes SHALL be removed from the DD and a 2841 successful Status Code returned. 2843 If a DD Member iSCSI Name identified in the Operating Attributes 2844 contains an iSCSI Name for a Storage Node that is not currently 2845 registered in the iSNS database or contained in another DD, then the 2846 association between that Storage Node and its pre-assigned iSCSI 2847 Node Index SHALL be removed. The pre-assigned iSCSI Node Index 2848 value no longer has an association to a specific iSCSI Name and can 2849 now be re-assigned. 2851 If a DD Member Portal IP Address and DD Member TCP/UDP Port 2852 identified in the Operating Attributes references a Portal that is 2853 not currently registered in the iSNS database or contained in 2854 another DD, then the association between that Portal and its pre- 2855 assigned Portal Index SHALL be removed. The pre-assigned Portal 2856 Index value can now be reassigned. 2858 The attempted deregistration of non-existent DD entries SHALL not be 2859 considered an error. 2861 5.6.5.11 DDS Register (DDSReg) 2863 The DDSReg message type is 0x000B. This message allows an iSNS 2864 client to create a new Discovery Domain Set (DDS), update an 2865 existing DDS Symbolic Name and/or DDS Status, or add DDS members. 2867 DDSs are uniquely defined using DDS_IDs. DDS registration 2868 attributes are described in section 6.11.1. 2870 Internet Storage Name Service (iSNS) February 2004 2872 The DDSReg message PDU Payload contains the Source Attribute, and 2873 optionally, Message Key and Operating Attributes. 2875 The Message Key, if used, contains the DDS_ID of the Discover Domain 2876 Set to be registered or modified. If the Message Key contains a 2877 DDS_ID of an existing DDS entry in the iSNS database, then the 2878 DDSReg message SHALL attempt to update the existing entry. If the 2879 DDS_ID in the Message Key (if used) does not match an existing DDS 2880 entry, then the iSNS server SHALL reject the DDSReg message with a 2881 status code of 3 (Invalid Registration). If the DDS_ID is included 2882 in both the Message Key and Operating Attributes, then the DDS_ID 2883 value in the Message Key MUST be the same as the DDS_ID value in the 2884 Operating Attributes. 2886 A DDSReg message with no Message Key SHALL result in the attempted 2887 creation of a new Discovery Domain Set (DDS). If the DDS_ID 2888 attribute (with non-zero length) is included among the Operating 2889 Attributes in the DDSReg message, then the new Discovery Domain Set 2890 SHALL be assigned the value contained in that DDS_ID attribute. 2891 Otherwise, if the DDS_ID attribute is not contained among the 2892 Operating Attributes of the DDSReg message, or if the DDS_ID is an 2893 operating attribute with TLV length of 0, then the iSNS server SHALL 2894 assign a DDS_ID value. The assigned DDS_ID value is then returned 2895 in the DDSReg Response message. The Operating Attributes can also 2896 contain the DDS_Symbolic_Name, DDS Status, and the DD_IDs of 2897 Discovery Domains to be added to the DDS. 2899 When creating a new DDS, if the DDS Symbolic Name is included in the 2900 Operating Attributes and its value is unique (i.e., does not match 2901 the registered DDS Symbolic Name for another DDS), then the value 2902 SHALL be stored in the iSNS database as the DDS Symbolic Name for 2903 that DDS. If the value for the DDS Symbolic Name is not unique, 2904 then the iSNS server SHALL reject the attempted DDS registration 2905 with a status code of 3 (Invalid Registration). 2907 When creating a new DDS, if the DDS Symbolic Name is not included in 2908 the Operating Attributes, or if it is included with a zero-length 2909 TLV, then the iSNS server SHALL provide a unique DDS Symbolic Name 2910 value for the created DDS. The assigned DDS Symbolic Name value 2911 SHALL be returned in the DDSRegRsp message. 2913 This message SHALL add any DD_IDs listed as Operating Attributes to 2914 the Discovery Domain Set specified by the DDS_ID Message Key 2915 Attribute. In addition, if the DDS_Symbolic_Name is an operating 2916 attribute and the value is unique, then it SHALL be stored in the 2917 iSNS database as the DDS_Symbolic_Name for the specified Discovery 2918 Domain Set. 2920 If a DD_ID listed in the Operating Attributes does not match an 2921 existing DD, then a new DD using the DD_ID SHALL be created. In 2922 this case for the new DD, the iSNS server SHALL assign a unique 2923 value for the DD Symbolic Name and SHALL set the DD Features 2924 attribute to the default value of 0. These assigned values SHALL be 2925 returned in the DDSRegRsp message. 2927 Internet Storage Name Service (iSNS) February 2004 2929 5.6.5.12 DDS Deregister (DDSDereg) 2931 The DDSDereg message type is 0x000C. This message allows an iSNS 2932 client to deregister an existing Discovery Domain Set (DDS) or 2933 remove some DDs from an existing DDS. 2935 The DDSDereg message PDU Payload contains a Source Attribute, 2936 Message Key Attribute, and optional Operating Attributes. 2938 The Message Key Attribute for a DDSDereg message is the DDS ID for 2939 the DDS being removed, or having members removed. If the DDS ID 2940 matches an existing DDS, and there are no Operating Attributes, then 2941 the DDS SHALL be removed and a success Status Code returned. Any 2942 existing members of that DDS SHALL remain in the iSNS database 2943 without membership in the just-removed DDS. 2945 If the DDS ID matches an existing DDS, and there are Operating 2946 Attributes matching DDS members, then the DDS members SHALL be 2947 removed from the DDS and a success Status Code returned. 2949 The attempted deregistration of non-existent DDS entries SHALL not 2950 be considered an error. 2952 5.6.5.13 Entity Status Inquiry (ESI) 2954 The ESI message type is 0x000D. This message is sent by the iSNS 2955 server, and is used to verify that an iSNS client Portal is 2956 reachable and available. The ESI message is sent to the ESI UDP port 2957 provided during registration, or the TCP connection used for ESI 2958 registration, depending on which communication type that is being 2959 used. 2961 The ESI message PDU Payload contains the following attributes in TLV 2962 format and in the order listed: the current iSNS timestamp, the EID, 2963 the Portal IP Address, and the Portal TCP/UDP Port. The format of 2964 this message is shown below: 2966 +----------------------------------------+ 2967 | Timestamp | 2968 +----------------------------------------+ 2969 | Entity_ID | 2970 +----------------------------------------+ 2971 | Portal IP Address | 2972 +----------------------------------------+ 2973 | Portal TCP/UDP Port | 2974 +----------------------------------------+ 2976 The ESI response message PDU Payload contains a status code, 2977 followed by the Attributes from the original ESI message. 2979 If the Portal fails to respond to an administratively-determined 2980 number of consecutive ESI messages, then the iSNS server SHALL 2981 remove that Portal from the iSNS database. If there are no other 2982 Internet Storage Name Service (iSNS) February 2004 2984 remaining ESI monitored Portals for the associated Network Entity, 2985 then the Network Entity SHALL also be removed. The appropriate 2986 State Change Notifications, if any, SHALL be triggered. 2988 5.6.5.14 Name Service Heartbeat (Heartbeat) 2990 This message, if used, is only sent by the active iSNS server. It 2991 allows iSNS clients and backup servers listening to a broadcast or 2992 multicast address to discover the IP address of the primary and 2993 backup iSNS servers. It also allows concerned parties to monitor 2994 the health and status of the primary iSNS server. 2996 This message is NOT in TLV format. There is no response message to 2997 the Name Service Heartbeat. 2999 MSb LSb 3000 0 31 3001 +------------------------------------------------+ 3002 | Active Server IP-Address | 16 Bytes 3003 +------------------------------------------------+ 3004 | iSNS TCP Port | iSNS UDP Port | 4 Bytes 3005 +------------------------------------------------+ 3006 | Interval | 4 Bytes 3007 +------------------------------------------------+ 3008 | Counter | 4 Bytes 3009 +------------------------------------------------+ 3010 | RESERVED | Backup Servers | 4 Bytes 3011 +------------------------------------------------+ 3012 | Primary Backup Server IP Address(if any) | 16 Bytes 3013 +------------------------------------------------+ 3014 |Backup TCP Port(if any)|Backup UDP Port(if any) | 4 Bytes 3015 +------------------------------------------------+ 3016 | 2nd Backup Server IP Address(if any) | 16 Bytes 3017 +------------------------------------------------+ 3018 |Backup TCP Port(if any)|Backup UDP Port(if any) | 4 Bytes 3019 +------------------------------------------------+ 3020 | . . . | 3021 +------------------------------------------------+ 3022 | VENDOR SPECIFIC | 3023 +------------------------------------------------+ 3025 The heartbeat PDU Payload contains: 3027 Internet Storage Name Service (iSNS) February 2004 3029 Active Server IP-Address: the IP_Address of the active iSNS server 3030 in IPv6 format. When this field contains an IPv4 value, it is 3031 stored as an IPv4-mapped IPv6 address. That is, the most 3032 significant 10 bytes are set to 0x00, with the next two bytes set to 3033 0xFFFF [RFC2373]. When this field contains an IPv6 value, the 3034 entire 16-byte field is used. 3036 Active TCP Port: the TCP Port of the server currently in use. 3038 Active UDP Port: the UDP Port of the server currently in use, 3039 otherwise 0. 3041 Interval: the interval, in seconds, of the heartbeat. 3043 Counter: a count that begins at 0 when this server becomes active. 3044 The count increments by one for each heartbeat sent since this 3045 server became active. 3047 Backup Servers: the number of iSNS backup servers. The IP address, 3048 TCP Port, and UDP Port of each iSNS backup server follow this field. 3049 Note that if backup servers are used, then the active iSNS server 3050 SHOULD be among the list of backup servers. 3052 The content of the remainder of this message after the list of 3053 backup servers is vendor-specific. Vendors may use additional 3054 fields to coordinate between multiple iSNS servers, and/or to 3055 identify vendor specific features. 3057 5.6.5.15 Request FC_DOMAIN_ID (RqstDomId) 3059 The RqstDomId message type is 0x0011. This message is used for iFCP 3060 Transparent Mode to allocate non-overlapping FC_DOMAIN_ID values 3061 between 1 and 239. The iSNS server becomes the address assignment 3062 authority for the entire iFCP fabric. To obtain multiple 3063 FC_DOMAIN_ID values, this request must be repeated multiple times to 3064 the iSNS server. iSNS clients that acquire FC_DOMAIN_ID values from 3065 an iSNS server MUST register for ESI monitoring from that iSNS 3066 server. 3068 The RqstDomId PDU Payload contains three TLV attributes in the 3069 following order: the requesting Switch Name (WWN) as the Source 3070 Attribute, the Virtual_Fabric_ID as the Message Key Attribute, and 3071 Preferred ID as the operating attribute. The Virtual_Fabric_ID is a 3072 string identifying the domain space for which the iSNS server SHALL 3073 allocate non-overlapping integer FC_DOMAIN_ID values between 1 and 3074 239. The Preferred_ID is the nominal FC_DOMAIN_ID value requested 3075 by the iSNS client. If the Preferred_ID value is available and has 3076 not been already allocated for the Virtual_Fabric_ID specified in 3077 the message, the iSNS server SHALL return the requested Preferred_ID 3078 value as the Assigned_ID to the requesting client. 3080 The RqstDomId response contains a Status Code, and the TLV attribute 3081 Assigned ID, which contains the integer value in the space 3082 requested. If no further unallocated values are available from this 3083 Internet Storage Name Service (iSNS) February 2004 3085 space, the iSNS server SHALL respond with the Status Code 18 3086 "FC_DOMAIN_ID Not Available". 3088 Once a FC_DOMAIN_ID value has been allocated to an iSNS client by 3089 the iSNS server for a given Virtual_Fabric_ID, that FC_DOMAIN_ID 3090 value SHALL NOT be reused until it has been deallocated, or until 3091 ESI monitoring detects that the iSNS client no longer exists on the 3092 network and objects for that client are removed from the iSNS 3093 database. 3095 The iSNS server and client SHALL use TCP to transmit and receive 3096 RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages. 3098 5.6.5.16 Release FC_DOMAIN_ID (RlseDomId) 3100 The RlseDomId message type is 0x0012. This message may be used by 3101 iFCP Transparent Mode to release integer identifier values used to 3102 assign 3-byte Fibre Channel PORT_ID values. 3104 The RlseDomId message contains three TLV attributes in the following 3105 order: the requesting EID as the Source Attribute, the 3106 Virtual_Fabric_ID as the Message Key Attribute, and Assigned_ID as 3107 the operating attribute. Upon receiving the RlseDomId message, the 3108 iSNS server SHALL deallocate the FC_DOMAIN_ID value contained in the 3109 Assigned_ID attribute for the Virtual_Fabric_ID attribute specified. 3110 Upon deallocation, that FC_DOMAIN_ID value can now be requested by, 3111 and assigned to, a different iSNS client. 3113 The iSNS server and client SHALL use TCP to transmit and receive 3114 RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages. 3116 5.6.5.17 Get FC_DOMAIN_IDs (GetDomId) 3118 The GetDomId message type is 0x0013. This message is used to learn 3119 the currently-allocated FC_DOMAIN_ID values for a given 3120 Virtual_Fabric_ID. 3122 The GetDomId message PDU Payload contains a Source Attribute and 3123 Message Key Attribute. 3125 The Message Key Attribute for the GetDomId message is the 3126 Virtual_Fabric_ID. The response to this message returns all of the 3127 FC_DOMAIN_ID values that have been allocated for the 3128 Virtual_Fabric_ID specified. 3130 5.7 Response Messages 3132 The iSNSP response message PDU Payloads contain a Status Code, 3133 followed by a list of attributes, and have the following format: 3135 Internet Storage Name Service (iSNS) February 2004 3137 MSb LSb 3138 0 31 3139 +----------------------------------------+ 3140 | 4-byte STATUS CODE | 3141 +----------------------------------------+ 3142 | Message Key Attribute[1] (if present) | 3143 +----------------------------------------+ 3144 | Message Key Attribute[2] (if present) | 3145 +----------------------------------------+ 3146 | . . . | 3147 +----------------------------------------+ 3148 | - Delimiter Attribute - (if present) | 3149 +----------------------------------------+ 3150 | Operating Attribute[1] (if present) | 3151 +----------------------------------------+ 3152 | Operating Attribute[2] (if present) | 3153 +----------------------------------------+ 3154 | Operating Attribute[3] (if present) | 3155 +----------------------------------------+ 3156 | . . . | 3157 +----------------------------------------+ 3159 The iSNSP Response messages SHALL be sent to the iSNS Client IP 3160 Address and the originating TCP/UDP Port that was used for the 3161 associated registration and query message. 3163 5.7.1 Status Code 3165 The first field in an iSNSP response message PDU Payload is the 3166 Status Code for the operation that was performed. The Status Code 3167 encoding is defined in section 5.4. 3169 5.7.2 Message Key Attributes in Response 3171 Depending on the specific iSNSP request, the response message MAY 3172 contain Message Key Attributes. Message Key Attributes generally 3173 contain the interesting key attributes that are affected by the 3174 operation specified in the original iSNS registration or query 3175 message. 3177 5.7.3 Delimiter Attribute in Response 3179 The Delimiter Attribute separates the key and Operating Attributes 3180 in a response message, if they exist. The Delimiter Attribute has a 3181 tag value of 0 and a length value of 0. The Delimiter Attribute is 3182 effectively 8 Bytes long, a 4 Byte tag containing 0x00000000, and a 3183 4 Byte length field containing 0x00000000. 3185 5.7.4 Operating Attributes in Response 3187 The Operating Attributes in a response are the results related to 3188 the iSNS registration or query operation being performed. Some 3189 response messages will not have Operating Attributes. 3191 Internet Storage Name Service (iSNS) February 2004 3193 5.7.5 Registration and Query Response Message Types 3195 The following describes each query and message type. 3197 5.7.5.1 Device Attribute Registration Response (DevAttrRegRsp) 3199 The DevAttrRegRsp message type is 0x8001. The DevAttrRegRsp message 3200 contains the results for the DevAttrReg message with the same 3201 TRANSACTION ID. 3203 The Message Key in the DevAttrRegRsp message SHALL return the 3204 Message Key in the original registration message. If the iSNS 3205 server assigned the Entity Identifier for a Network Entity, then the 3206 Message Key Attribute field SHALL contain the assigned Entity 3207 Identifier. 3209 The Operating Attributes of the DevAttrRegRsp message SHALL contain 3210 the affected object's key and non-key attributes that have been 3211 explicitly modified or created by the original DevAttrReg message. 3212 Among the Operating Attributes, each modified or added non-key 3213 attribute SHALL be listed following its key attribute(s) in the 3214 DevAttrRegRsp message. Implicitly registered attributes MUST NOT be 3215 returned in the DevAttrRegRsp message. Implicitly registered 3216 attributes are those that are assigned a fixed default value or 3217 secondary index value by the iSNS server. 3219 Implicitly registered PG objects (i.e., PG objects that are not 3220 explicitly included in the registration or replace message) MUST NOT 3221 have their key or non-key attributes returned in the DevAttrRegRsp 3222 message. However, explicitly registered PG objects (i.e., those 3223 with PGT values that are explicitly included in the registration or 3224 replace message) SHALL have their PGT values returned in the 3225 DevAttrRegRsp message. 3227 For example, three Portals are registered in the original DevAttrReg 3228 request message. Due to lack of resources, the iSNS server needs to 3229 modify the registered ESI Interval value of one of those Portals. To 3230 accomplish this, the iSNS server returns the key attributes 3231 identifying the Portal, followed by the non-key modified ESI Interval 3232 attribute value, as Operating Attributes of the corresponding 3233 DevAttrRegRsp message. 3235 If the iSNS server rejects a registration due to invalid attribute 3236 values or types, then the indicated status code SHALL be 3 (Invalid 3237 Registration). If this occurs, then the iSNS server MAY include the 3238 list of invalid attributes in the Operating Attributes of the 3239 DevAttrRsp message. 3241 Some attributes values (e.g., ESI Interval, Registration Period) in 3242 the original registration message MAY be modified by the iSNS 3243 server. This can occur only for a limited set of attribute types, 3244 as indicated in the table in section 6.1. When this occurs, the 3245 registration SHALL be considered a success (with status code 0), and 3246 Internet Storage Name Service (iSNS) February 2004 3248 the changed value(s) indicated in the Operating Attributes of the 3249 DevAttrRsp message. 3251 5.7.5.2 Device Attribute Query Response (DevAttrQryRsp) 3253 The DevAttrQryRsp message type is 0x8002. The DevAttrQryRsp message 3254 contains the results for the DevAttrQry message with the same 3255 TRANSACTION ID. 3257 The Message Key in the DevAttrQryRsp message SHALL return the 3258 Message Key in the original query message. 3260 If no Operating Attributes are included in the original query, then 3261 all Operating Attributes SHALL be returned in the response. 3263 For a successful query result, the DevAttrQryRsp Operating 3264 Attributes SHALL contain the results of the original DevAttrQry 3265 message. 3267 5.7.5.3 Device Get Next Response (DevGetNextRsp) 3269 The DevGetNextRsp message type is 0x8003. The DevGetNextRsp message 3270 contains the results for the DevGetNext message with the same 3271 TRANSACTION ID. 3273 The Message Key Attribute field returns the object keys for the next 3274 object after the Message Key Attribute in the original DevGetNext 3275 message. 3277 The Operating Attribute field returns the Operating Attributes of 3278 the next object as requested in the original DevGetNext message. 3279 The values of the Operating Attributes are those associated with the 3280 object identified by the Message Key Attribute field of the 3281 DevGetNextRsp message. 3283 5.7.5.4 Deregister Device Response (DevDeregRsp) 3285 The DevDeregRsp message type is 0x8004. This message is the 3286 response to the DevDereg request message. 3288 This message response does not contain a Message Key, but MAY 3289 contain Operating Attributes. 3291 In the event of an error, this response message contains the 3292 appropriate status code as well as a list of objects from the 3293 original DevDereg message that were not successfully deregistered 3294 from the iSNS database. This list of objects is contained in the 3295 Operating Attributes of the DevDeregRsp message. Note that an 3296 attempted deregistration of a non-existent object does not 3297 constitute an error, and non-existent entries SHALL not be returned 3298 in the DevDeregRsp message. 3300 Internet Storage Name Service (iSNS) February 2004 3302 5.7.5.5 SCN Register Response (SCNRegRsp) 3304 The SCNRegRsp message type is 0x8005. This message is the response 3305 to the SCNReg request message. 3307 The SCNRegRsp message does not contain any Message Key or Operating 3308 Attributes. 3310 5.7.5.6 SCN Deregister Response (SCNDeregRsp) 3312 The SCNDeregRsp message type is 0x8006. This message is the 3313 response to the SCNDereg request message. 3315 The SCNDeregRsp message does not contain any Message Key or 3316 Operating Attributes. 3318 5.7.5.7 SCN Event Response (SCNEventRsp) 3320 The SCNEventRsp message type is 0x8007. This message is the response 3321 to the SCNEvent request message. 3323 The SCNEventRsp message does not contain any Message Key or 3324 Operating Attributes. 3326 5.7.5.8 SCN Response (SCNRsp) 3328 The SCNRsp message type is 0x8008. This message is sent by an iSNS 3329 client, and provides confirmation that the SCN message was received 3330 and processed. 3332 The SCNRsp response contains the SCN Destination Attribute 3333 representing the Node identifier that received the SCN. 3335 5.7.5.9 DD Register Response (DDRegRsp) 3337 The DDRegRsp message type is 0x8009. This message is the response to 3338 the DDReg request message. 3340 The Message Key in the DDRegRsp message SHALL return the Message Key 3341 in the original query message. If the original DDReg message did 3342 not have a Message Key, then the DDRegRsp message SHALL not have a 3343 Message Key. 3345 If successful, the DD ID of the DD created or updated during the 3346 DDReg operation SHALL be returned as an operating attribute of the 3347 message. 3349 If the DD Symbolic Name attribute or DD Features attribute was 3350 assigned or updated during the DDReg operation, then any new values 3351 SHALL be returned as an operating attribute of the DDRegRsp message. 3353 If the iSNS server rejects a DDReg due to invalid attribute values 3354 or types, then the indicated status code SHALL be 3 (Invalid 3355 Registration). If this occurs, then the iSNS server MAY include the 3356 Internet Storage Name Service (iSNS) February 2004 3358 list of invalid attributes in the Operating Attributes of the 3359 DDRegRsp message. 3361 5.7.5.10 DD Deregister Response (DDDeregRsp) 3363 The DDDeregRsp message type is 0x800A. This message is the response 3364 to the DDDereg request message. 3366 The DDDeregRsp message does not contain any Message Key or Operating 3367 Attributes. 3369 5.7.5.11 DDS Register Response (DDSRegRsp) 3371 The DDSRegRsp message type is 0x800B. This message is the response 3372 to the DDSReg request message. 3374 The Message Key in the DDSRegRsp message SHALL contain the Message 3375 Key of the original DDSReg message. If the original DDSReg message 3376 did not have a Message Key, then the DDSRegRsp message SHALL not 3377 have a Message Key. 3379 If successful, the DDS ID of the DDS created or updated during the 3380 DDSReg operation SHALL be returned as an operating attribute of the 3381 message. 3383 If the DDS Symbolic Name attribute or DDS Status attribute was 3384 assigned or updated during the DDSRegRsp operation, then any new 3385 values SHALL be returned as an operating attribute of the DDSRegRsp 3386 message. 3388 If the iSNS server rejects a DDSReg due to invalid attribute values 3389 or types, then the indicated status code SHALL be 3 (Invalid 3390 Registration). If this occurs, then the iSNS server MAY include the 3391 list of invalid attributes in the Operating Attributes of the 3392 DDSRegRsp message. 3394 5.7.5.12 DDS Deregister Response (DDSDeregRsp) 3396 The DDSDeregRsp message type is 0x800C. This message is the 3397 response to the DDSDereg request message. 3399 The DDSDeregRsp message does not contain any Message Key or 3400 Operating Attributes. 3402 5.7.5.13 Entity Status Inquiry Response (ESIRsp) 3404 The ESIRsp message type is 0x800D. This message is sent by an iSNS 3405 client, and provides confirmation that the ESI message was received 3406 and processed. 3408 The ESIRsp response message PDU Payload contains the attributes from 3409 the original ESI message. These attributes represent the Portal 3410 that is responding to the ESI. The ESIRsp Attributes are in the 3411 order they were provided in the original ESI message. 3413 Internet Storage Name Service (iSNS) February 2004 3415 Upon receiving the ESIRsp from the iSNS client, the iSNS server 3416 SHALL update the timestamp attribute for that Network Entity and 3417 Portal. 3419 5.7.5.14 Request FC_DOMAIN_ID Response (RqstDomIdRsp) 3421 The RqstDomIdRsp message type is 0x8011. This message provides the 3422 response for RqstDomId. 3424 The RqstDomId response contains a Status Code and the TLV attribute 3425 Assigned ID, which contains the integer value in the space 3426 requested. If no further unallocated values are available from this 3427 space, the iSNS server SHALL respond with the Status Code 19 3428 "FC_DOMAIN_ID Not Available". 3430 Once a FC_DOMAIN_ID value is allocated by the iSNS server, it SHALL 3431 not be reused until it has been deallocated by the iSNS client to 3432 which the value was assigned, or the ESI message detects that the 3433 iSNS client no longer exists on the network. 3435 The iSNS server and client SHALL use TCP to transmit and receive 3436 RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages. 3438 5.7.5.15 Release FC_DOMAIN_ID Response (RlseDomIdRsp) 3440 The RlseDomIdRsp message type is 0x8012. This message provides the 3441 response for RlseDomId. The response contains an Error indicating 3442 if the request was successful or not. If the Assigned_ID value in 3443 the original RlseDomId message is not allocated, then the iSNS 3444 server SHALL respond with this message using the Status Code 20 3445 "FC_DOMAIN_ID Not Allocated". 3447 The iSNS server and client SHALL use TCP to transmit and receive 3448 RqstDomId, RqstDomIdRsp, RlseDomId, and RlseDomIdRsp messages. 3450 5.7.5.16 Get FC_DOMAIN_IDs Response (GetDomIdRsp) 3452 The GetDomIdRsp message type is 0x8013. This message is used 3453 determine which FC_DOMAIN_ID values have been allocated for the 3454 Virtual_Fabric_ID specified in the original GetDomId request 3455 message. 3457 The GetDomId response message PDU Payload contains a Status Code 3458 indicating if the request was successful, and a list of the Assigned 3459 IDs from the space requested. The Assigned_ID attributes are listed 3460 in TLV format. 3462 5.8 Vendor Specific Messages 3464 Vendor-specific iSNSP messages have a functional ID of between 3465 0x0100 and 0x01FF, while vendor-specific responses have a functional 3466 ID of between 0x8100 and 0x81FF. The first Message Key Attribute in 3467 a vendor-specific message SHALL be the company OUI (tag=256) 3468 Internet Storage Name Service (iSNS) February 2004 3470 identifying original creator of the proprietary iSNSP message. The 3471 contents of the remainder of the message are vendor-specific. 3473 6. iSNS Attributes 3475 Attributes can be stored in the iSNS server using iSNSP registration 3476 messages, and they can be retrieved using iSNSP query messages. 3477 Unless otherwise indicated, these attributes are supplied by iSNS 3478 clients using iSNSP registration messages. 3480 6.1 iSNS Attribute Summary 3482 The complete registry of iSNS attributes is maintained by IANA, and 3483 the following table summarizes the initial set of iSNS attributes 3484 available at time of publication of this document. 3486 Attributes Length Tag Reg Key Query Key 3487 ---------- ------ --- ------- --------- 3488 Delimiter 0 0 N/A N/A 3489 Entity Identifier (EID) 4-256 1 1 1|2|16&17|32|64 3490 Entity Protocol 4 2 1 1|2|16&17|32|64 3491 Management IP Address 16 3 1 1|2|16&17|32|64 3492 Timestamp 8 4 -- 1|2|16&17|32|64 3493 Protocol Version Range 4 5 1 1|2|16&17|32|64 3494 Registration Period 4 6 1 1|2|16&17|32|64 3495 Entity Index 4 7 1 1|2|16&17|32|64 3496 Entity Next Index 4 8 -- 1|2|16&17|32|64 3497 Entity ISAKMP Phase-1 var 11 1 1|2|16&17|32|64 3498 Entity Certificate var 12 1 1|2|16&17|32|64 3499 Portal IP Address 16 16 1 1|16&17|32|64 3500 Portal TCP/UDP Port 4 17 1 1|16&17|32|64 3501 Portal Symbolic Name 4-256 18 16&17 1|16&17|32|64 3502 ESI Interval 4 19 16&17 1|16&17|32|64 3503 ESI Port 4 20 16&17 1|16&17|32|64 3504 Portal Index 4 22 16&17 1|16&17|32|64 3505 SCN Port 4 23 16&17 1|16&17|32|64 3506 Portal Next Index 4 24 -- 1|16&17|32|64 3507 Portal Security Bitmap 4 27 16&17 1|16&17|32|64 3508 Portal ISAKMP Phase-1 var 28 16&17 1|16&17|32|64 3509 Portal ISAKMP Phase-2 var 29 16&17 1|16&17|32|64 3510 Portal Certificate var 31 16&17 1|16&17|32|64 3511 iSCSI Name 4-224 32 1 1|16&17|32|33 3512 iSCSI Node Type 4 33 32 1|16&17|32 3513 iSCSI Alias 4-256 34 32 1|16&17|32 3514 iSCSI SCN Bitmap 4 35 32 1|16&17|32 3515 iSCSI Node Index 4 36 32 1|16&17|32 3516 WWNN Token 8 37 32 1|16&17|32 3517 iSCSI Node Next Index 4 38 -- 1|16&17|32 3518 iSCSI AuthMethod var 42 32 1|16&17|32 3519 PG iSCSI Name 4-224 48 32|16&17 1|16&17|32|52 3520 PG Portal IP Addr 16 49 32|16&17 1|16&17|32|52 3521 PG Portal TCP/UDP Port 4 50 32|16&17 1|16&17|32|52 3522 Internet Storage Name Service (iSNS) February 2004 3524 PG Tag (PGT) 4 51 32|16&17 1|16&17|32|52 3525 PG Index 4 52 32|16&17 1|16&17|32|52 3526 PG Next Index 4 53 -- 1|16&17|32|52 3527 FC Port Name WWPN 8 64 1 1|16&17|64|66|96|128 3528 Port ID 4 65 64 1|16&17|64 3529 FC Port Type 4 66 64 1|16&17|64 3530 Symbolic Port Name 4-256 67 64 1|16&17|64 3531 Fabric Port Name 8 68 64 1|16&17|64 3532 Hard Address 4 69 64 1|16&17|64 3533 Port IP-Address 16 70 64 1|16&17|64 3534 Class of Service 4 71 64 1|16&17|64 3535 FC-4 Types 32 72 64 1|16&17|64 3536 FC-4 Descriptor 4-256 73 64 1|16&17|64 3537 FC-4 Features 128 74 64 1|16&17|64 3538 iFCP SCN bitmap 4 75 64 1|16&17|64 3539 Port Role 4 76 64 1|16&17|64 3540 Permanent Port Name 8 77 -- 1|16&17|64 3541 FC-4 Type Code 4 95 -- 1|16&17|64 3542 FC Node Name WWNN 8 96 64 1|16&17|64|96 3543 Symbolic Node Name 4-256 97 96 64|96 3544 Node IP-Address 16 98 96 64|96 3545 Node IPA 8 99 96 64|96 3546 Proxy iSCSI Name 4-256 101 96 64|96 3547 Switch Name 8 128 128 128 3548 Preferred ID 4 129 128 128 3549 Assigned ID 4 130 128 128 3550 Virtual_Fabric_ID 4-256 131 128 128 3551 iSNS Server Vendor OUI 4 256 -- SOURCE Attribute 3552 Vendor-Spec iSNS Srvr 257-384 -- SOURCE Attribute 3553 Vendor-Spec Entity 385-512 1 1|2|16&17|32|64 3554 Vendor-Spec Portal 513-640 16&17 1|16&17|32|64 3555 Vendor-Spec iSCSI Node 641-768 32 16&17|32 3556 Vendor-Spec FC Port Name 769-896 64 1|16&17|64 3557 Vendor-Spec FC Node Name 897-1024 96 64|96 3558 Vendor-Specific DDS 1025-1280 2049 2049 3559 Vendor-Specific DD 1281-1536 2065 2065 3560 Other Vendor-Specific 1537-2048 3561 DD_Set ID 4 2049 2049 1|32|64|2049|2065 3562 DD_Set Sym Name 4-256 2050 2049 2049 3563 DD_Set Status 4 2051 2049 2049 3564 DD_Set_Next_ID 4 2052 -- 2049 3565 DD_ID 4 2065 2049 1|32|64|2049|2065 3566 DD_Symbolic Name 4-256 2066 2065 2065 3567 DD_Member iSCSI Index 4 2067 2065 2065 3568 DD_Member iSCSI Name 4-224 2068 2065 2065 3569 DD_Member FC Port Name 8 2069 2065 2065 3570 DD_Member Portal Index 4 2070 2065 2065 3571 DD_Member Portal IP Addr 16 2071 2065 2065 3572 DD_Member Portal TCP/UDP 4 2072 2065 2065 3573 DD_Features 4 2078 2065 2065 3574 DD_ID Next ID 4 2079 -- 2065 3575 Internet Storage Name Service (iSNS) February 2004 3577 The following is a description of the columns used in the above 3578 table: 3580 Length - indicates the attribute length in bytes used for the TLV 3581 format. Variable-length identifiers are NULL-terminated and 4-byte 3582 aligned (NULLs are included in the length). 3584 Tag - the IANA-assigned integer tag value used to identify the 3585 attribute. All undefined tag values are reserved. 3587 Reg Key - indicates the tag values for the object key in DevAttrReg 3588 messages for registering a new attribute value in the database. 3589 These tags represent attributes defined as object keys in Section 4. 3591 Query Key - indicates the possible tag values for the Message Key 3592 and object key that are used in the DevAttrQry messages for 3593 retrieving a stored value from the iSNS database. 3595 The following is a summary of iSNS attribute tag values available 3596 at the time of publication for future allocation by IANA: 3598 Tag Values Reg Key Query Key 3599 ---------- ------- --------- 3600 9-10, 13-15 1 1|2|16&17|32|64 3601 21, 25-26, 30 16&17 1|16&17|32|64 3602 39-41, 44-47 32 1|16&17|32 3603 54-63 32|16&17 1|16&17|32|52 3604 78-82, 85-94 64 1|16&17|64 3605 102-127 96 64|96 3606 132-255 -- SOURCE Attribute 3607 2053-2064 2049 2049 3608 2073-2077 2065 2065 3609 2080-65535 To be assigned To be assigned 3611 Registration and query keys for attributes with tags in the range 3612 2080 to 65535 are to be documented in the RFC introducing the new 3613 iSNS attributes. IANA will maintain registration of these values 3614 as required by the new RFC. 3616 New iSNS attributes with any of the above tag values MAY also be 3617 designated as "read-only" attributes. The new RFC introducing 3618 these attributes as "read-only" SHALL document them as such, and 3619 IANA will record their corresponding Registration Key (Reg Key) as 3620 "--". 3622 6.2 Entity Identifier-Keyed Attributes 3624 The following attributes are stored in the iSNS server using the 3625 Entity Identifier attribute as the key. 3627 6.2.1 Entity Identifier (EID) 3629 The Entity Identifier (EID) is variable-length UTF-8 encoded NULL- 3630 terminated text-based description for a Network Entity. This key 3631 Internet Storage Name Service (iSNS) February 2004 3633 attribute uniquely identifies each Network Entity registered in the 3634 iSNS server. The attribute length varies from 4 to 256 bytes 3635 (including the NULL termination), and is a unique value within the 3636 iSNS server. 3638 If the iSNS client does not provide an EID during registration the 3639 iSNS server SHALL generate one that is unique within the iSNS 3640 database. If an EID is to be generated, then the EID attribute 3641 value in the registration message SHALL be empty (0 length). The 3642 generated EID SHALL be returned in the registration response. 3644 In environments where the iSNS server is integrated with a DNS 3645 infrastructure, the Entity Identifier may be used to store the Fully 3646 Qualified Domain Name (FQDN) of the iSCSI or iFCP device. FQDNs of 3647 greater than 255 bytes MUST NOT be used. 3649 If FQDNs are not used, the iSNS server can be used to generate EIDs. 3650 EIDs generated by the iSNS server MUST begin with the string 3651 "isns:". iSNS clients MUST NOT generate and register EIDs beginning 3652 with the string "isns:". 3654 This field MUST be normalized according to the nameprep template 3655 [NAMEPREP] before it is stored in the iSNS database. 3657 6.2.2 Entity Protocol 3659 The Entity Protocol is a required 4-byte integer attribute that 3660 indicates the block storage protocol used by the registered NETWORK 3661 ENTITY. Values used for this attribute are assigned and maintained 3662 by IANA. The initial set of protocols supported by iSNS is as 3663 follows: 3665 Value Entity Protocol Type 3666 ----- -------------------- 3667 1 No Protocol 3668 2 iSCSI 3669 3 iFCP 3670 All Others To be assigned by IANA 3672 'No Protocol' is used to indicate that the Network Entity does not 3673 support an IP block storage protocol. A Control Node or monitoring 3674 Node would likely (but not necessarily) use this value. 3676 This attribute is required during initial registration of the 3677 Network Entity. 3679 6.2.3 Management IP Address 3681 This field contains the IP Address that may be used to manage the 3682 Network Entity and all Storage Nodes contained therein via the iSNS 3683 MIB [iSNSMIB]. Some implementations may also use this IP address to 3684 support vendor-specific proprietary management protocols. The 3685 Management IP Address is a 16-byte field that may contain an IPv4 or 3686 IPv6 address. When this field contains an IPv4 value, it is stored 3687 Internet Storage Name Service (iSNS) February 2004 3689 as an IPv4-mapped IPv6 address. That is, the most significant 10 3690 bytes are set to 0x00, with the next two bytes set to 0xFFFF 3691 [RFC2373]. When this field contains an IPv6 value, the entire 16- 3692 byte field is used. If this field is not set, then in-band 3693 management through the IP address of one of the Portals of the 3694 Network Entity is assumed. 3696 6.2.4 Entity Registration Timestamp 3698 This field indicates the most recent time that the Network Entity 3699 registration occurred or an associated object attribute was updated 3700 or queried by the iSNS client registering the Network Entity. The 3701 time format is, in seconds, the update period since the standard 3702 base time of 00:00:00 GMT on January 1, 1970. This field cannot be 3703 explicitly registered. This timestamp TLV format is also used in 3704 the SCN and ESI messages. 3706 6.2.5 Protocol Version Range 3708 This field contains the minimum and maximum version of the block 3709 storage protocol supported by the Network Entity. The most 3710 significant two bytes contain the maximum version supported, and the 3711 least significant two bytes contain the minimum version supported. 3712 If a range is not registered then the Network Entity is assumed to 3713 support all versions of the protocol. The value 0xffff is a 3714 wildcard that indicates no minimum or maximum. If the Network 3715 Entity does not support a protocol, then this field SHALL be set to 3716 0. 3718 6.2.6 Registration Period 3720 This 4-byte unsigned integer field indicates the maximum period, in 3721 seconds, that the registration SHALL be maintained by the server 3722 without receipt of an iSNS message from the iSNS client that 3723 registered the Network Entity. Entities that are not registered for 3724 ESI monitoring MUST have a non-zero Registration Period. If a 3725 Registration Period is not requested by the iSNS client and Entity 3726 Status Inquiry (ESI) messages are not enabled for that client, then 3727 the Registration Period SHALL be set to a non-zero value by the iSNS 3728 server. This implementation-specific value for the Registration 3729 Period SHALL be returned in the registration response to the iSNS 3730 client. The Registration Period may be set to zero, indicating its 3731 non-use, only if ESI messages are enabled for that Network Entity. 3733 The registration SHALL be removed from the iSNS database if an iSNS 3734 Protocol message is not received from the iSNS client before the 3735 registration period has expired. Receipt of any iSNS Protocol 3736 message from the iSNS client automatically refreshes the Entity 3737 Registration Period and Entity Registration Timestamp. To prevent a 3738 registration from expiring, the iSNS client should send an iSNS 3739 Protocol message to the iSNS server at intervals shorter than the 3740 registration period. Such a message can be as simple as a query for 3741 one of its own attributes, using its associated iSCSI Name or FC 3742 Port Name WWPN as the Source attribute. 3744 Internet Storage Name Service (iSNS) February 2004 3746 For an iSNS client that is supporting a Network Entity with multiple 3747 Storage Node objects, receipt of an iSNS message from any Storage 3748 Node of that Network Entity is sufficient to refresh the 3749 registration for all Storage Node objects of the Network Entity. 3751 If ESI support is requested as part of a Portal registration, the 3752 ESI Response message received from the iSNS client by the iSNS 3753 server SHALL refresh the registration. 3755 6.2.7 Entity Index 3757 The Entity Index is an unsigned non-zero integer value that uniquely 3758 identifies each Network Entity registered in the iSNS server. Upon 3759 initial registration of a Network Entity, the iSNS server assigns an 3760 unused value for the Entity Index. Each Network Entity in the iSNS 3761 database MUST be assigned a value for the Entity Index that is not 3762 assigned to any other Network Entity. Furthermore, Entity Index 3763 values for recently deregistered Network Entities SHOULD NOT be 3764 reused in the short term. 3766 The Entity Index MAY be used to represent the Network Entity in 3767 situations when the Entity Identifier is too long or otherwise 3768 inappropriate. An example of this is when SNMP is used for 3769 management, as described in Section 2.10. 3771 6.2.8 Entity Next Index 3773 This is a virtual attribute containing a 4-byte integer value that 3774 indicates the next available (i.e., unused) Entity Index value. 3775 This attribute may only be queried; the iSNS server SHALL return an 3776 error code of 3 (Invalid Registration) to any client that attempts 3777 to register a value for this attribute. A Message Key is not 3778 required when exclusively querying for this attribute. 3780 The Entity Next Index MAY be used by an SNMP client to create an 3781 entry in the iSNS server. SNMP requirements are described in 3782 Section 2.10. 3784 6.2.9 Entity ISAKMP Phase-1 Proposals 3786 This field contains the IKE Phase-1 proposal listing in decreasing 3787 order of preference the protection suites acceptable to protect all 3788 IKE Phase-2 messages sent and received by the Network Entity. This 3789 includes Phase-2 SAs from the iSNS client to the iSNS server as well 3790 as to peer iFCP and/or iSCSI devices. This attribute contains the 3791 SA payload, proposal payload(s), and transform payload(s) in the 3792 ISAKMP format defined in [RFC2408]. 3794 This field should be used if the implementer wishes to define a 3795 single phase-1 SA security configuration used to protect all phase-2 3796 IKE traffic. If the implementer desires to have a different phase-1 3797 SA security configuration to protect each Portal interface, then the 3798 Portal Phase-1 Proposal (section 6.3.10) should be used. 3800 Internet Storage Name Service (iSNS) February 2004 3802 6.2.10 Entity Certificate 3804 This attribute contains one or more X.509 certificates that are 3805 bound to the Network Entity. This certificate is uploaded and 3806 registered to the iSNS server by clients wishing to allow other 3807 clients to authenticate themselves and access the services offered 3808 by that Network Entity. The format of the X.509 certificate is 3809 found in [RFC3280]. This certificate MUST contain a Subject Name 3810 with an empty sequence and MUST contain a SubjectAltName extension 3811 encoded with the dNSName type. The Entity Identifier (section 3812 6.2.1) of the identified Entity MUST be stored in the SubjectAltName 3813 field of the certificate. 3815 6.3 Portal-Keyed Attributes 3817 The following Portal attributes are registered in the iSNS database 3818 using the combined Portal IP-Address and Portal TCP/UDP Port as the 3819 key. Each Portal is associated with one Entity Identifier object 3820 key. 3822 6.3.1 Portal IP Address 3824 This attribute is the IP address of the Portal through which a 3825 Storage Node can transmit and receive storage data. The Portal IP 3826 Address is a 16-byte field that may contain an IPv4 or IPv6 address. 3827 When this field contains an IPv4 address, it is stored as an IPv4- 3828 mapped IPv6 address. That is, the most significant 10 bytes are set 3829 to 0x00, with the next 2 bytes set to 0xFFFF [RFC2373]. When this 3830 field contains an IPv6 address, the entire 16-byte field is used. 3831 The Portal IP Address along with the Portal TCP/UDP Port number (see 3832 6.3.2 below), is used as a key to uniquely identify a Portal. It is 3833 a required attribute for registration of a Portal. 3835 6.3.2 Portal TCP/UDP Port 3837 The TCP/UDP port of the Portal through which a Storage Node can 3838 transmit and receive storage data. Bits 16 to 31 represents the 3839 TCP/UDP port number. Bit 15 represents the port type. If bit 15 is 3840 set, then the port type is UDP. Otherwise it is TCP. Bits 0 to 14 3841 are reserved. 3843 If the field value is 0, then the port number is the implied 3844 canonical port number and type of the protocol indicated by the 3845 associated Entity Type. 3847 The Portal IP-Address along with the Portal TCP/UDP Port number is 3848 used as a key to uniquely identify a Portal. It is a required 3849 attribute for registration of a Portal. 3851 6.3.3 Portal Symbolic Name 3853 A variable-length UTF-8 encoded NULL-terminated text-based 3854 description of up to 256 bytes. The Portal Symbolic Name is a user- 3855 readable description of the Portal entry in the iSNS server. 3857 Internet Storage Name Service (iSNS) February 2004 3859 6.3.4 Entity Status Inquiry Interval 3861 This field indicates the requested time, in seconds, between Entity 3862 Status Inquiry (ESI) messages sent from the iSNS server to this 3863 Network Entity. ESI messages can be used to verify that a Portal 3864 registration continues to be valid. To request monitoring by the 3865 iSNS server, an iSNS client registers a non-zero value for this 3866 Portal attribute using a DevAttrReg message. The client MUST 3867 register an ESI Port on at least one of its Portals to receive the 3868 ESI monitoring. 3870 If the iSNS server does not receive an expected response to an ESI 3871 message, it SHALL attempt an administratively configured number of 3872 re-transmissions of the ESI message. The ESI Interval period begins 3873 with the iSNS server's receipt of the last ESI Response. All re- 3874 transmissions MUST be sent before twice the ESI Interval period has 3875 passed. If no response is received from any of the ESI messages, 3876 then the Portal SHALL be deregistered. Note that only Portals that 3877 have registered a value in their ESI Port field can be deregistered 3878 in this way. 3880 If all Portals associated with a Network Entity that have registered 3881 for ESI messages are deregistered due to non-response, and no 3882 registrations have been received from the client for at least two 3883 ESI Interval periods, then the Network Entity and all associated 3884 objects (including Storage Nodes) SHALL be deregistered. 3886 If the iSNS server is unable to support ESI messages or the ESI 3887 Interval requested, it SHALL either reject the ESI request by 3888 returning an "ESI Not Available" Status Code or modify the ESI 3889 Interval attribute by selecting its own suitable value and returning 3890 that value in the Operating Attributes of the registration response 3891 message. 3893 If at any time an iSNS client that is registered for ESI messages 3894 has not received an ESI message to any of its Portals as expected, 3895 then the client MAY attempt to query the iSNS server using a 3896 DevAttrQry message using its Entity_ID as the key. If the query 3897 result is the error "no such entry", then the client SHALL close all 3898 remaining TCP connections to the iSNS server and assume that it is 3899 no longer registered in the iSNS database. Such a client MAY 3900 attempt re-registration. 3902 6.3.5 ESI Port 3904 This field contains the TCP or UDP port used for ESI monitoring by 3905 the iSNS server at the Portal IP Address. Bit 16 to 31 represents 3906 the port number. If bit 15 is set, then the port type is UDP. 3907 Otherwise, the port is TCP. Bits 0 to 14 are reserved. 3909 If the iSNS client registers a valid TCP or UDP port number in this 3910 field, then the client SHALL allow ESI messages to be received at 3911 the indicated TCP or UDP port. If a TCP port is registered and a 3912 pre-existing TCP connection from that TCP port to the iSNS server 3913 Internet Storage Name Service (iSNS) February 2004 3915 does not already exist, then the iSNS client SHALL accept new TCP 3916 connections from the iSNS server at the indicated TCP port. 3918 The iSNS server SHALL return an error if a Network Entity is 3919 registered for ESI monitoring and none of the Portals of that 3920 Network Entity has an entry for the ESI Port field. If multiple 3921 Portals have a registered ESI port, then the ESI message may be 3922 delivered to any one of the indicated Portals. 3924 6.3.6 Portal Index 3926 The Portal Index is a 4-byte non-zero integer value that uniquely 3927 identifies each Portal registered in the iSNS database. Upon 3928 initial registration of a Portal, the iSNS server assigns an unused 3929 value for the Portal Index of that Portal. Each Portal in the iSNS 3930 database MUST be assigned a value for the Portal Index that is not 3931 assigned to any other Portal. Furthermore, Portal Index values for 3932 recently deregistered Portals SHOULD NOT be reused in the short 3933 term. 3935 The Portal Index MAY be used to represent a registered Portal in 3936 situations where the Portal IP-Address and Portal TCP/UDP Port is 3937 unwieldy to use. An example of this is when SNMP is used for 3938 management, as described in Section 2.10. 3940 6.3.7 SCN Port 3942 This field contains the TCP or UDP port used by the iSNS client to 3943 receive SCN messages from the iSNS server. When a value is 3944 registered for this attribute, an SCN message may be received on the 3945 indicated port for any of the Storage Nodes supported by the Portal. 3946 Bits 16 to 31 contain the port number. If bit 15 is set, then the 3947 port type is UDP. Otherwise, the port type is TCP. Bits 0 to 14 3948 are reserved. 3950 If the iSNS client registers a valid TCP or UDP port number in this 3951 field, then the client SHALL allow SCN messages to be received at 3952 the indicated TCP or UDP port. If a TCP port is registered and a 3953 pre-existing TCP connection from that TCP port to the iSNS server 3954 does not already exist, then the iSNS client SHALL accept new TCP 3955 connections from the iSNS server at the indicated TCP port. 3957 The iSNS server SHALL return an error if an SCN registration message 3958 is received and none of the Portals of the Network Entity has an 3959 entry for the SCN Port. If multiple Portals have a registered SCN 3960 Port, then the SCN SHALL be delivered to any one of the indicated 3961 Portals of that Network Entity. 3963 6.3.8 Portal Next Index 3965 This is a virtual attribute containing a 4-byte integer value that 3966 indicates the next available (i.e., unused) Portal Index value. 3967 This attribute may only be queried; the iSNS server SHALL return an 3968 error code of 3 (Invalid Registration) to any client that attempts 3969 Internet Storage Name Service (iSNS) February 2004 3971 to register a value for this attribute. A Message Key is not 3972 required when exclusively querying for this attribute. 3974 The Portal Next Index MAY be used by an SNMP client to create an 3975 entry in the iSNS server. SNMP requirements are described in 3976 Section 2.10. 3978 6.3.9 Portal Security Bitmap 3980 This 4-byte field contains flags that indicate security attribute 3981 settings for the Portal. Bit 31 (Lsb) of this field must be 1 3982 (enabled) in order for this field to contain significant 3983 information. If Bit 31 is enabled, this signifies the iSNS server 3984 can be used to store and distribute security policies and settings 3985 for iSNS clients (i.e., iSCSI devices). Bit 30 must be 1 in order 3986 for bits 25-29 to contain significant information. All other bits 3987 are reserved for non-IKE/IPSec security mechanisms to be specified 3988 in the future. 3990 Bit Position Flag Description 3991 ------------ ---------------- 3992 25 1 = Tunnel Mode Preferred; 0 = No Preference 3993 26 1 = Transport Mode Preferred; 0 = No Preference 3994 27 1 = Perfect Forward Secrecy (PFS) Enabled; 3995 0 = PFS Disabled 3996 28 1 = Aggressive Mode Enabled; 0 = Disabled 3997 29 1 = Main Mode Enabled; 0 = MM Disabled 3998 30 1 = IKE/IPSec Enabled; 0 = IKE/IPSec Disabled 3999 31 (Lsb) 1 = Bitmap VALID; 0 = INVALID 4000 All others reserved 4002 6.3.10 Portal ISAKMP Phase-1 Proposals 4004 This field contains the IKE Phase-1 proposal listing in decreasing 4005 order of preference of the protection suites acceptable to protect 4006 all IKE Phase-2 messages sent and received by the Portal. This 4007 includes Phase-2 SAs from the iSNS client to the iSNS server as well 4008 as to peer iFCP and/or iSCSI devices. This attribute contains the 4009 SA payload, proposal payload(s), and transform payload(s) in the 4010 ISAKMP format defined in [RFC2408]. 4012 This field should be used if the implementer wishes to define phase- 4013 1 SA security configuration on a per-Portal basis, as opposed to on 4014 a per-Network Entity basis. If the implementer desires to have a 4015 single phase-1 SA security configuration to protect all phase-2 4016 traffic regardless of the interface used, then the Entity Phase-1 4017 Proposal (section 6.2.9) should be used. 4019 6.3.11 Portal ISAKMP Phase-2 Proposals 4021 This field contains the IKE Phase-2 proposal, in ISAKMP format 4022 [RFC2408], listing in decreasing order of preference the security 4023 proposals acceptable to protect traffic sent and received by the 4024 Portal. This field is used only if bits 31, 30 and 29 of the 4025 Internet Storage Name Service (iSNS) February 2004 4027 Security Bitmap (see 6.3.9) are enabled. This attribute contains 4028 the SA payload, proposal payload(s), and associated transform 4029 payload(s) in the ISAKMP format defined in [RFC2408]. 4031 6.3.12 Portal Certificate 4033 This attribute contains one or more X.509 certificates that is a 4034 credential of the Portal. This certificate is used to identify and 4035 authenticate communications to the IP address and TCP/UDP Port 4036 supported by the Portal. The format of the X.509 certificate is 4037 specified in [RFC3280]. This certificate MUST contain a Subject 4038 Name with an empty sequence and MUST contain a SubjectAltName 4039 extension encoded with the iPAddress type. The Portal IP Address 4040 (section 6.3.1) of the identified Portal SHALL be stored in the 4041 SubjectAltName field of the certificate. 4043 6.4 iSCSI Node-Keyed Attributes 4045 The following attributes are stored in the iSNS database using the 4046 iSCSI Name attribute as the key. Each set of Node-Keyed attributes 4047 is associated with one Entity Identifier object key. 4049 Although the iSCSI Name key is associated with one Entity 4050 Identifier, it is unique across the entire iSNS database. 4052 6.4.1 iSCSI Name 4054 This is a variable-length UTF-8 encoded NULL-terminated text-based 4055 description of up to 224 bytes. This key attribute is required for 4056 iSCSI Storage Nodes, and is provided by the iSNS client. The 4057 registered iSCSI Name MUST be conformant to the format described in 4058 [iSCSI] for iSCSI Names. The maximum size for an iSCSI Name is 223 4059 bytes. Including the NULL character and 4-byte alignment (see 4060 section 5.3.1), the maximum iSCSI Name field size is 224 bytes. 4062 If an iSCSI Name is registered without an EID key, then a Network 4063 Entity SHALL be created and an EID assigned. The assigned EID SHALL 4064 be returned in the registration response as an operating attribute. 4066 This field MUST be normalized according to the stringprep template 4067 [STRINGPREP] before it is stored in the iSNS database. 4069 6.4.2 iSCSI Node Type 4071 This required 32-bit field is a bitmap indicating the type of iSCSI 4072 Storage Node. The bit positions are defined below. A set bit (1) 4073 indicates that the Node has the corresponding characteristics. 4075 Internet Storage Name Service (iSNS) February 2004 4077 Bit Position Node Type 4078 ------------ --------- 4079 29 Control 4080 30 Initiator 4081 31 (Lsb) Target 4082 All Others RESERVED 4084 If the Target bit is set to 1, then the Node represents an iSCSI 4085 target. Setting of the Target bit MAY be performed by iSNS clients 4086 using the iSNSP. 4088 If the Initiator bit is set to 1, then the Node represents an iSCSI 4089 initiator. Setting of the Initiator bit MAY be performed by iSNS 4090 clients using the iSNSP. 4092 If the control bit is set to 1, then the Node represents a gateway, 4093 management station, backup iSNS server, or other device which is not 4094 an initiator or target, but requires the ability to send and receive 4095 iSNSP messages, including state change notifications. Setting of 4096 the control bit is an administrative task that MUST be performed on 4097 the iSNS server; iSNS clients SHALL NOT be allowed to change this 4098 bit using the iSNSP. 4100 This field MAY be used by the iSNS server to distinguish among 4101 permissions by different iSCSI Node types for accessing various iSNS 4102 functions. More than one Node Type bit may be simultaneously 4103 enabled. 4105 6.4.3 iSCSI Node Alias 4107 This is a variable-length UTF-8 encoded NULL-terminated text-based 4108 description of up to 256 bytes. The Alias is a user-readable 4109 description of the Node entry in the iSNS database. 4111 6.4.4 iSCSI Node SCN Bitmap 4113 The iSCSI Node SCN Bitmap indicates those events for which the 4114 registering iSNS client wishes to receive a notification message. 4115 The following table displays events that result in notifications, 4116 and the bit field in the SCN Bitmap that when enabled, results in 4117 the corresponding notification. 4119 Note that this field is of dual use--it is used in the SCN 4120 registration process to define interested events that will trigger 4121 an SCN message, and it is also contained in each SCN message itself, 4122 to indicate the type of event that triggered the SCN message. A set 4123 bit (1) indicates the corresponding type of SCN. 4125 Bit Position Flag Description 4126 ------------ ---------------- 4127 24 INITIATOR AND SELF INFORMATION ONLY 4128 25 TARGET AND SELF INFORMATION ONLY 4129 26 MANAGEMENT REGISTRATION/SCN 4130 Internet Storage Name Service (iSNS) February 2004 4132 27 OBJECT REMOVED 4133 28 OBJECT ADDED 4134 29 OBJECT UPDATED 4135 30 DD/DDS MEMBER REMOVED (Mgmt Reg/SCN only) 4136 31 (Lsb) DD/DDS MEMBER ADDED (Mgmt Reg/SCN only) 4137 All others RESERVED 4139 DD/DDS MEMBER REMOVED indicates that an existing member of a 4140 Discovery Domain and/or Discovery Domain Set has been removed. 4142 DD/DDS MEMBER ADDED indicates that a new member was added to an 4143 existing DD and/or DDS. 4145 OBJECT REMOVED, OBJECT ADDED, and OBJECT UPDATED indicate a Network 4146 Entity, Portal, Storage Node, FC Device, DD, and/or DDS object was 4147 removed from, added to, or updated in the Discovery Domain or in the 4148 iSNS database (Control Nodes only). 4150 Regular SCNs provide information about objects that are updated, 4151 added or removed from Discovery Domains that the Storage Node is a 4152 member of. An SCN or SCN registration is considered a regular SCN 4153 or regular SCN registration if the MANAGEMENT REGISTRATION/SCN flag 4154 is cleared. All iSNS clients may register for regular SCNs. 4156 Management SCNs provide information about all changes to the 4157 network, regardless of discovery domain membership. Registration 4158 for management SCNs is indicated by setting bit 26 to 1. Only 4159 Control Nodes may register for management SCNs. Bits 30 and 31 may 4160 only be enabled if bit 26 is set to 1. 4162 TARGET AND SELF INFORMATION ONLY SCNs (bit 25) provides information 4163 only about changes to target devices, or if the iSCSI Storage Node 4164 itself has undergone a change. Similarly, INITIATOR AND SELF 4165 INFORMATION ONLY SCNs (bit 24) provides information only about 4166 changes to initiator Nodes, or the target itself. 4168 6.4.5 iSCSI Node Index 4170 The iSCSI Node Index is a 4-byte non-zero integer value used as a 4171 key that uniquely identifies each iSCSI Storage Node registered in 4172 the iSNS database. Upon initial registration of the iSCSI Storage 4173 Node, the iSNS server assigns an unused value for the iSCSI Node 4174 Index. Each iSCSI Node MUST be assigned a value for the iSCSI Node 4175 Index that is not assigned to any other iSCSI Storage Node. 4176 Furthermore, iSCSI Node Index values for recently deregistered iSCSI 4177 Storage Nodes SHOULD NOT be reused in the short term. 4179 The iSCSI Node Index may be used as a key to represent a registered 4180 Node in situations where the iSCSI Name is too long to be used as a 4181 key. An example of this is when SNMP is used for management, as 4182 described in Section 2.10. 4184 The value assigned for the iSCSI Node Index SHALL be persistent for 4185 as long as the iSCSI Storage Node is registered in the iSNS database 4186 Internet Storage Name Service (iSNS) February 2004 4188 or a member of a Discovery Domain. An iSCSI Node Index value that 4189 is assigned for a Storage Node SHALL NOT be used for any other 4190 Storage Node for as long as the original node is registered in the 4191 iSNS database or a member of a Discovery Domain. 4193 6.4.6 WWNN Token 4195 This field contains a globally unique 64-bit integer value that can 4196 be used to represent the World Wide Node Name of the iSCSI device in 4197 a Fibre Channel fabric. This identifier is used during the device 4198 registration process, and MUST conform to the requirements in [FC- 4199 FS]. 4201 The FC-iSCSI gateway uses the value found in this field to register 4202 the iSCSI device in the Fibre Channel name server. It is stored in 4203 the iSNS server to prevent conflict when assigning "proxy" WWNN 4204 values to iSCSI initiators establishing storage sessions to devices 4205 in the FC fabric. 4207 If the iSNS client does not assign a value for WWNN Token, then the 4208 iSNS server SHALL provide a value for this field upon initial 4209 registration of the iSCSI Storage Node. The process by which the 4210 WWNN Token is assigned by the iSNS server MUST conform to the 4211 following requirements: 4213 1. The assigned WWNN Token value MUST be unique among all WWN 4214 entries in the existing iSNS database, as well as among all devices 4215 that can potentially be registered in the iSNS database. 4217 2. Once assigned, the iSNS server MUST persistently save the 4218 mapping between the WWNN Token value and registered iSCSI Name. 4219 That is, successive re-registrations of the iSCSI Storage Node keyed 4220 by the same iSCSI Name maintain the original mapping to the 4221 associated WWNN Token value in the iSNS server. Similarly, the 4222 mapping SHALL be persistent across iSNS server reboots. Once 4223 assigned, the mapping can only be changed if a DevAttrReg message 4224 from an authorized iSNS client explicitly provides a different WWNN 4225 Token value. 4227 3. Once a WWNN Token value has been assigned and mapped to an iSCSI 4228 name, that WWNN Token value SHALL NOT be reused or mapped to any 4229 other iSCSI name. 4231 4. The assigned WWNN Token value MUST conform to the formatting 4232 requirements of [FC-FS] for World Wide Names (WWNs). 4234 An iSNS client, such as an FC-iSCSI gateway or the iSCSI initiator, 4235 MAY register its own WWNN Token value or overwrite the iSNS Server- 4236 supplied WWNN Token value, if it wishes to supply its own iSCSI-FC 4237 name mapping. This is accomplished using the DevAttrReg message 4238 with the WWNN Token (tag=37) as an operating attribute. Once 4239 overwritten, the new WWNN Token value MUST be stored and saved by 4240 the iSNS server, and all requirements specified above continue to 4241 apply. If an iSNS client attempts to register a value for this 4242 Internet Storage Name Service (iSNS) February 2004 4244 field that is not unique in the iSNS database or is otherwise 4245 invalid, then the registration SHALL be rejected with an Status Code 4246 of 3 (Invalid Registration). 4248 There MAY be a matching records in the iSNS database for the Fibre 4249 Channel device specified by the WWNN Token. These records for the 4250 FC device may contain device attributes for that FC device 4251 registered in the Fibre Channel fabric name server. 4253 6.4.7 iSCSI Node Next Index 4255 This is a virtual attribute containing a 4-byte integer value that 4256 indicates the next available (i.e., unused) iSCSI Node Index value. 4257 This attribute may only be queried; the iSNS server SHALL return an 4258 error code of 3 (Invalid Registration) to any client that attempts 4259 to register a value for this attribute. A Message Key is not 4260 required when exclusively querying for this attribute. 4262 The iSCSI Node Next Index MAY be used by an SNMP client to create an 4263 entry in the iSNS server. SNMP requirements are described in 4264 Section 2.10. 4266 6.4.8 iSCSI AuthMethod 4268 This attribute contains a NULL-terminated string containing UTF-8 4269 text listing the iSCSI authentication methods enabled for this iSCSI 4270 Storage Node, in order of preference. The text values used to 4271 identify iSCSI authentication methods are embedded in this string 4272 attribute and delineated by a comma. The text values are identical 4273 to those found in the main iSCSI draft [iSCSI]; additional vendor- 4274 specific text values are also possible. 4276 Text Value Description Reference 4277 ---------- ----------- --------- 4278 KB5 Kerberos V5 RFC 1510 4279 SPKM1 Simple Public Key GSS-API RFC 2025 4280 SPKM2 Simple Public Key GSS-API RFC 2025 4281 SRP Secure Remote Password RFC 2945 4282 CHAP Challenge Handshake Protocol RFC 1994 4283 none No iSCSI Authentication 4285 6.5 Portal Group (PG) Object-Keyed Attributes 4287 The following attributes are used to associate Portal and iSCSI 4288 Storage Node objects. PG objects are stored in the iSNS database 4289 using the PG iSCSI Name, PG Portal IP Address, and the PG Portal 4290 TCP/UDP Port as keys. New PG objects are implicitly or explicitly 4291 created at the time that the corresponding Portal and/or iSCSI 4292 Storage Node objects are registered. Section 3.4 has a general 4293 discussion of PG usage. For further details on use of Portal 4294 Groups, see [iSCSI]. 4296 Internet Storage Name Service (iSNS) February 2004 4298 6.5.1 Portal Group iSCSI Name 4300 This is the iSCSI Name for the iSCSI Storage Node that is 4301 associated with the PG object. This name MAY represent an iSCSI 4302 Storage Node not currently registered in the server. 4304 6.5.2 PG Portal IP Addr 4306 This is the Portal IP Address attribute for the Portal that is 4307 associated with the PG object. This Portal IP Address MAY be that 4308 of a Portal that is not currently registered in the server. 4310 6.5.3 PG Portal TCP/UDP Port 4312 This is the Portal TCP/UDP Port attribute for the Portal that is 4313 associated with the PG object. This Portal TCP/UDP Port MAY be that 4314 of a Portal that is not currently registered in the server. 4316 6.5.4 Portal Group Tag (PGT) 4318 This field is used to group Portals to coordinate connections in a 4319 session across Portals to a specified iSCSI Node. The PGT is a 4320 value in the range of 0-65535, or NULL. A NULL PGT value is 4321 registered by using 0 for the length in the TLV during registration. 4322 The two least significant bytes of the value contain the PGT for the 4323 object. The two most significant bytes are reserved. If a PGT 4324 value is not explicitly registered for an iSCSI Storage Node and 4325 Portal pair, then the PGT value SHALL be implicitly registered as 4326 0x00000001. 4328 6.5.5 Portal Group Index 4330 The PG Index is a 4-byte non-zero integer value used as a key that 4331 uniquely identifies each PG object registered in the iSNS database. 4332 On initial registration of a PG object, the iSNS server MUST assign 4333 an unused value for the PG Index. Furthermore, PG Index values for 4334 recently deregistered PG objects SHOULD NOT be reused in the short 4335 term. 4337 The PG Index MAY be used as the key to reference a registered PG in 4338 situations where a unique index for each PG object is required. It 4339 MAY also be used as the message key in an iSNS message to query or 4340 update a pre-existing PG object. An example of this is when SNMP 4341 is used for management, as described in Section 2.10. The value 4342 assigned for the PG Index SHALL be persistent for as long as the 4343 server is active. 4345 6.5.6 Portal Group Next Index 4347 The PG Next Index is a virtual attribute containing a 4-byte 4348 integer value that indicates the next available (i.e., unused) PG 4349 Index value. This attribute may only be queried; the iSNS server 4350 SHALL return an error code of 3 (Invalid Registration) to any 4351 client that attempts to register a value for this attribute. A 4352 Internet Storage Name Service (iSNS) February 2004 4354 Message Key is not required when exclusively querying for this 4355 attribute. 4357 The Portal Group Next Index MAY be used by an SNMP client to create 4358 an entry in the iSNS server. SNMP requirements are described in 4359 Section 2.10. 4361 6.6 FC Port Name-Keyed Attributes 4363 The following attributes are registered in the iSNS database using 4364 the FC Port World Wide Name (WWPN) attribute as the key. Each set 4365 of FC Port-Keyed attributes is associated with one Entity Identifier 4366 object key. 4368 Although the FC Port World Wide Name is associated with one Entity 4369 Identifier, it is also globally unique. 4371 6.6.1 FC Port Name (WWPN) 4373 This 64-bit identifier uniquely defines the FC Port, and is the 4374 World Wide Port Name (WWPN) of the corresponding Fibre Channel 4375 device. This attribute is the key for the iFCP Storage Node. This 4376 globally unique identifier is used during the device registration 4377 process, and uses a value conforming to IEEE EUI-64 [EUI-64]. 4379 6.6.2 Port ID (FC_ID) 4381 The Port Identifier is a Fibre Channel address identifier assigned 4382 to an N_Port or NL_Port during fabric login. The format of the Port 4383 Identifier is defined in [FC-FS]. The least significant 3 bytes 4384 contain this address identifier. The most significant byte is 4385 RESERVED. 4387 6.6.3 FC Port Type 4389 Indicates the type of FC port. Encoded values for this field are 4390 listed in the following table: 4392 Type Description 4393 ---- ----------- 4394 0x0000 Unidentified/Null Entry 4395 0x0001 Fibre Channel N_Port 4396 0x0002 Fibre Channel NL_Port 4397 0x0003 Fibre Channel F/NL_Port 4398 0x0004-0080 RESERVED 4399 0x0081 Fibre Channel F_Port 4400 0x0082 Fibre Channel FL_Port 4401 0x0083 RESERVED 4402 0x0084 Fibre Channel E_Port 4403 0x0085-00FF RESERVED 4404 0xFF11 RESERVED 4405 0xFF12 iFCP Port 4406 0xFF13-FFFF RESERVED 4407 Internet Storage Name Service (iSNS) February 2004 4409 6.6.4 Symbolic Port Name 4411 This is a variable-length UTF-8 encoded NULL-terminated text-based 4412 description of up to 256 bytes that is associated with the iSNS- 4413 registered FC Port Name in the network. 4415 6.6.5 Fabric Port Name (FWWN) 4417 This 64-bit identifier uniquely defines the fabric port. If the 4418 port of the FC Device is attached to a Fibre Channel fabric port 4419 with a registered Port Name, then that fabric Port Name SHALL be 4420 indicated in this field. 4422 6.6.6 Hard Address 4424 This field is the requested hard address 24-bit NL Port Identifier, 4425 included in the iSNSP for compatibility with Fibre Channel 4426 Arbitrated Loop devices and topologies. The least significant 3 4427 bytes of this field contain the address. The most significant byte 4428 is RESERVED. 4430 6.6.7 Port IP Address 4432 The Fibre Channel IP address associated with the FC Port. When this 4433 field contains an IPv4 value, it is stored as an IPv4-mapped IPv6 4434 address. That is, the most significant 10 bytes are set to 0x00, 4435 with the next two bytes set to 0xFFFF [RFC2373]. When an IPv6 value 4436 is contained in this field, then the entire 16-byte field is used. 4438 6.6.8 Class of Service (COS) 4440 This 32-bit bit-map field indicates the Fibre Channel Class of 4441 Service types that are supported by the registered port. In the 4442 following table, a set bit (1) indicates a Class of Service 4443 supported. 4445 Bit Position Description 4446 ------------ ----------- 4447 29 Fibre Channel Class 2 Supported 4448 28 Fibre Channel Class 3 Supported 4450 6.6.9 FC-4 Types 4452 This 32-byte field indicates the FC-4 protocol types supported by 4453 the associated port. This field can be used to support Fibre 4454 Channel devices and is consistent with FC-GS-4. 4456 6.6.10 FC-4 Descriptor 4458 This is a variable-length UTF-8 encoded NULL-terminated text-based 4459 description of up to 256 bytes, that is associated with the iSNS- 4460 registered device port in the network. This field can be used to 4461 support Fibre Channel devices and is consistent with FC-GS-4. 4463 Internet Storage Name Service (iSNS) February 2004 4465 6.6.11 FC-4 Features 4467 This is a 128-byte array, 4 bits per type, for the FC-4 protocol 4468 types supported by the associated port. This field can be used to 4469 support Fibre Channel devices and is consistent with FC-GS-4. 4471 6.6.12 iFCP SCN Bitmap 4473 This field indicates the events that the iSNS client is interested 4474 in. These events can cause SCN to be generated. SCNs provide 4475 information about objects that are updated, added or removed from 4476 Discovery Domains that the source and destination are a member of. 4477 Management SCNs provide information about all changes to the 4478 network. A set bit (1) indicates the type of SCN for the bitmap as 4479 follows: 4481 Bit Position Flag Description 4482 ------------ ---------------- 4483 24 INITIATOR AND SELF INFORMATION ONLY 4484 25 TARGET AND SELF INFORMATION ONLY 4485 26 MANAGEMENT REGISTRATION/SCN 4486 27 OBJECT REMOVED 4487 28 OBJECT ADDED 4488 29 OBJECT UPDATED 4489 30 DD/DDS MEMBER REMOVED (Mgmt Reg/SCN only) 4490 31 (Lsb) DD/DDS MEMBER ADDED (Mgmt Reg/SCN only) 4491 All others RESERVED 4493 Further information on use of the above specified bit positions can 4494 be found in section 6.4.4. 4496 6.6.13 Port Role 4498 This required 32-bit field is a bitmap indicating the type of iFCP 4499 Storage Node. The bit fields are defined below. A set bit 4500 indicates the Node has the corresponding characteristics. 4502 Bit Position Node Type 4503 ------------ --------- 4504 29 Control 4505 30 FCP Initiator 4506 31 (Lsb) FCP Target 4507 All Others RESERVED 4509 If the 'Target' bit is set to 1, then the port represents an FC 4510 target. Setting of the 'Target' bit MAY be performed by iSNS clients 4511 using the iSNSP. 4513 If the 'Initiator' bit is set to 1, then the port represents an FC 4514 initiator. Setting of the 'Initiator' bit MAY be performed by iSNS 4515 clients using the iSNSP. 4517 If the 'Control' bit is set to 1, then the port represents a 4518 gateway, management station, iSNS backup server, or other device. 4520 Internet Storage Name Service (iSNS) February 2004 4522 This is usually a special device that is neither an initiator nor 4523 target, which requires the ability to send and receive iSNSP 4524 messages including state change notifications. Setting of the 4525 control bit is an administrative task that MUST be administratively 4526 configured on the iSNS server; iSNS clients SHALL NOT be allowed to 4527 change this bit using the iSNSP. 4529 This field MAY be used by the iSNS server to distinguish among 4530 permissions by different iSNS clients. For example, an iSNS server 4531 implementation may be administratively configured to allow only 4532 targets to receive ESIs, or for only Control Nodes to have 4533 permission to add, modify, or delete discovery domains. 4535 6.6.14 Permanent Port Name (PPN) 4537 The Permanent Port Name can be used to support Fibre Channel devices 4538 and is consistent with the PPN description in FC-GS-4 [FC-GS-4]. 4539 The format of the PPN is identical to the FC Port Name WWPN 4540 attribute format. 4542 6.7 Node-Keyed Attributes 4544 The following attributes are registered in the iSNS database using 4545 the FC Node Name (WWNN) attribute as the key. Each set of FC Node- 4546 Keyed attributes represents a single device, and can be associated 4547 with many FC Ports. 4549 The FC Node Name is unique across the entire iSNS database. 4551 6.7.1 FC Node Name (WWNN) 4553 The FC Node Name is a 64-bit identifier that is the World Wide Node 4554 Name (WWNN) of the corresponding Fibre Channel device. This 4555 attribute is the key for the FC Device. This globally unique 4556 identifier is used during the device registration process, and uses 4557 a value conforming to IEEE EUI-64 [EUI-64]. 4559 6.7.2 Symbolic Node Name 4561 This is a variable-length UTF-8 encoded NULL-terminated text-based 4562 description of up to 256 bytes that is associated with the iSNS- 4563 registered FC Device in the network. 4565 6.7.3 Node IP Address 4567 This IP address is associated with the device Node in the network. 4568 This field is included for compatibility with Fibre Channel. When 4569 this field contains an IPv4 value, it is stored as an IPv4-mapped 4570 IPv6 address. That is, the most significant 10 bytes are set to 4571 0x00, with the next two bytes set to 0xFFFF [RFC2373]. When an IPv6 4572 value is contained in this field, then the entire 16-byte field is 4573 used. 4575 Internet Storage Name Service (iSNS) February 2004 4577 6.7.4 Node IPA 4579 This field is the 8 byte Fibre Channel Initial Process Associator 4580 (IPA) associated with the device Node in the network. The initial 4581 process associator is used for communication between Fibre Channel 4582 devices. 4584 6.7.5 Proxy iSCSI Name 4586 This is a variable-length UTF-8 encoded NULL-terminated text-based 4587 field that contains the iSCSI Name used to represent the FC Node in 4588 the IP network. It is used as a pointer to the matching iSCSI Name 4589 entry in the iSNS server. Its value is usually registered by an FC- 4590 iSCSI gateway connecting the IP network to the fabric containing the 4591 FC device. 4593 Note that if this field is used, there SHOULD be a matching entry in 4594 the iSNS database for the iSCSI device specified by the iSCSI name. 4595 The database entry should include the full range of iSCSI attributes 4596 needed for discovery and management of the "iSCSI proxy image" of 4597 the FC device. 4599 6.8 Other Attributes 4601 The following are not attributes of the previously-defined objects. 4603 6.8.1 FC-4 Type Code 4605 This is a 4-byte field, and is used to provide a FC-4 type during a 4606 FC-4 Type query. The FC-4 types are consistent with the FC-4 Types 4607 as defined in FC-FS. Byte 0 contains the FC-4 type. All other 4608 bytes are reserved. 4610 6.8.2 iFCP Switch Name 4612 The iFCP Switch Name is a 64-bit World Wide Name (WWN) identifier 4613 that uniquely identifies a distinct iFCP gateway in the network. 4614 This globally unique identifier is used during the switch 4615 registration/FC_DOMAIN_ID assignment process. The iFCP Switch Name 4616 value used MUST conform to the requirements stated in [FC-FS] for 4617 World Wide Names. The iSNS server SHALL track the state of all 4618 FC_DOMAIN_ID values that have been allocated to each iFCP Switch 4619 Name. If a given iFCP Switch Name is deregistered from the iSNS 4620 database, then all FC_DOMAIN_ID values allocated to that iFCP Switch 4621 Name SHALL be returned to the unused pool of values. 4623 6.8.3 iFCP Transparent Mode Commands 4625 6.8.3.1 Preferred ID 4627 This is a 4-byte unsigned integer field, and is the requested value 4628 that the iSNS client wishes to use for the FC_DOMAIN_ID. The iSNS 4629 server SHALL grant the iSNS client the use of the requested value as 4630 the FC_DOMAIN_ID, if the requested value has not been already 4631 Internet Storage Name Service (iSNS) February 2004 4633 allocated. If the requested value is not available, the iSNS server 4634 SHALL return a different value that has not been allocated. 4636 6.8.3.2 Assigned ID 4638 This is a 4-byte unsigned integer field that is used by an iFCP 4639 gateway to reserve its own unique FC_DOMAIN_ID value from the range 4640 1 to 239. When a FC_DOMAIN_ID is no longer required, it SHALL be 4641 released by the iFCP gateway using the RlseDomId message. The iSNS 4642 server MUST use the Entity Status Inquiry message to determine if an 4643 iFCP gateway is still present on the network. 4645 6.8.3.3 Virtual_Fabric_ID 4647 This is a variable-length UTF-8 encoded NULL-terminated text-based 4648 field of up to 256 bytes. The Virtual_Fabric_ID string is used as a 4649 key attribute to identify a range of non-overlapping FC_DOMAIN_ID 4650 values to be allocated using RqstDomId. Each Virtual_Fabric_ID 4651 string submitted by an iSNS client SHALL have its own range of non- 4652 overlapping FC_DOMAIN_ID values to be allocated to iSNS clients. 4654 6.9 iSNS Server-Specific Attributes 4656 Access to the following attributes may be administratively 4657 controlled. These attributes are specific to the iSNS server 4658 instance; the same value is returned for all iSNS clients accessing 4659 the iSNS server. Only query messages may be performed on these 4660 attributes. Attempted registrations of values for these attributes 4661 SHALL return a status code of 3 (Invalid Registration). 4663 A query for iSNS Server-Specific attribute MUST contain the 4664 identifying key attribute (i.e., iSCSI Name or FC Port Name WWPN) of 4665 the Node originating the registration or query message as the Source 4666 and Message Key attributes. The Operating Attributes are the 4667 server-specific attributes being registered or queried. 4669 6.9.1 iSNS Server Vendor OUI 4671 This attribute is the OUI (Organizationally Unique Identifier) [802- 4672 1990] identifying the specific vendor implementing the iSNS server. 4673 This attribute can only be queried; iSNS clients SHALL NOT be 4674 allowed to register a value for the iSNS Server Vendor OUI. 4676 6.10 Vendor-Specific Attributes 4678 iSNS server implementations MAY define vendor-specific attributes 4679 for private use. These attributes MAY be used to store optional 4680 data that is registered and/or queried by iSNS clients in order to 4681 gain optional capabilities. Note that any implementation of vendor- 4682 specific attributes in the iSNS server SHALL NOT impose any form of 4683 mandatory behavior on the part of the iSNS client. 4685 The tag values used for vendor-specific and user-specific use are 4686 defined in section 6.1. To avoid misinterpreting proprietary 4687 Internet Storage Name Service (iSNS) February 2004 4689 attributes, vendor's own OUI (Organizationally Unique Identifier) 4690 MUST be placed in the upper three bytes of the attribute value field 4691 itself. 4693 The OUI is defined in IEEE Std 802-1990, and is the same constant 4694 used to generate 48 bit Universal LAN MAC addresses. A vendor's own 4695 iSNS implementation will then be able to recognize the OUI in the 4696 attribute field, and be able to execute vendor-specific handling of 4697 the attribute. 4699 6.10.1 Vendor-Specific Server Attributes 4701 Attributes with tags in the range 257 to 384 are vendor-specific or 4702 site-specific attributes of the iSNS server. Values for these 4703 attributes are administratively set by the specific vendor providing 4704 the iSNS server implementation. Query access to these attribute may 4705 be administratively controlled. These attributes are unique for 4706 each logical iSNS server instance. Query messages for these 4707 attributes SHALL use the key identifier (i.e., iSCSI Name or FC Port 4708 Name WWPN) for both the Source attribute and Message Key attribute. 4709 These attributes can only be queried; iSNS clients SHALL NOT be 4710 allowed to register a value for server attributes. 4712 6.10.2 Vendor-Specific Entity Attributes 4714 Attributes in the range 385 to 512 are vendor-specific or site- 4715 specific attributes used to describe the Network Entity object. 4716 These attributes are keyed by the Entity Identifier attribute 4717 (tag=1). 4719 6.10.3 Vendor-Specific Portal Attributes 4721 Attributes in the range 513 to 640 are vendor-specific or site- 4722 specific attributes used to describe the Portal object. These 4723 attributes are keyed by the Portal IP-Address (tag=16) and Portal 4724 TCP/UDP Port (tag=17). 4726 6.10.4 Vendor-Specific iSCSI Node Attributes 4728 Attributes in the range 641 to 768 are vendor-specific or site- 4729 specific attributes used to describe the iSCSI Node object. These 4730 attributes are keyed by the iSCSI Name (tag=32). 4732 6.10.5 Vendor-Specific FC Port Name Attributes 4734 Attributes in the range 769 to 896 are vendor-specific or site- 4735 specific attributes used to describe the N_Port Port Name object. 4736 These attributes are keyed by the FC Port Name WWPN (tag=64). 4738 6.10.6 Vendor-Specific FC Node Name Attributes 4740 Attributes in the range 897 to 1024 are vendor-specific or site- 4741 specific attributes used to describe the FC Node Name object. These 4742 attributes are keyed by the FC Node Name WWNN (tag=96). 4744 Internet Storage Name Service (iSNS) February 2004 4746 6.10.7 Vendor-Specific Discovery Domain Attributes 4748 Attributes in the range 1025 to 1280 are vendor-specific or site- 4749 specific attributes used to describe the Discovery Domain object. 4750 These attributes are keyed by the DD_ID (tag=104). 4752 6.10.8 Vendor-Specific Discovery Domain Set Attributes 4754 Attributes in the range 1281 to 1536 are vendor-specific or site- 4755 specific attributes used to describe the Discovery Domain Set 4756 object. These attributes are keyed by the DD Set ID (tag=101) 4758 6.10.9 Other Vendor-Specific Attributes 4760 Attributes in the range 1537 to 2048 can be used for key and non-key 4761 attributes that describe new vendor-specific objects specific to the 4762 vendor's iSNS server implementation. 4764 6.11 Discovery Domain Registration Attributes 4766 6.11.1 DD Set ID Keyed Attributes 4768 6.11.1.1 Discovery Domain Set ID (DDS ID) 4770 The DDS ID is an unsigned non-zero integer identifier used in the 4771 iSNS directory database as a key to uniquely indicate a Discovery 4772 Domain Set. A DDS is a collection of Discovery Domains that can be 4773 enabled or disabled by a management station. This value is used as 4774 a key for DDS attribute queries. When a Discovery Domain is 4775 registered it is initially not in any DDS. 4777 If the iSNS client does not provide a DDS_ID in a DDS registration 4778 request message, the iSNS server SHALL generate a DDS_ID value that 4779 is unique within the iSNS database for that new DDS. The created 4780 DDS ID SHALL be returned in the response message. The DDS ID value 4781 of 0 is reserved, and the DDS ID value of 1 is used for the default 4782 DDS (see section 2.2.2). 4784 6.11.1.2 Discovery Domain Set Symbolic Name 4786 A variable-length UTF-8 encoded NULL-terminated text-based field of 4787 up to 256 bytes. This is a user-readable field used to assist a 4788 network administrator in tracking the DDS function. When registered 4789 by a client, the DDS symbolic name SHALL be verified to be unique by 4790 the iSNS server. If the DDS symbolic name is not unique, then the 4791 DDS registration SHALL be rejected with an "Invalid Registration" 4792 Status Code. The invalid attribute(s), in this case the DDS 4793 symbolic name, SHALL be included in the response. 4795 6.11.1.3 Discovery Domain Set Status 4797 The DDS_Status field is a 32-bit bitmap indicating the status of the 4798 DDS. Bit 0 of the bitmap indicates whether the DDS is Enabled (1) 4799 Internet Storage Name Service (iSNS) February 2004 4801 or Disabled (0). The default value for the DDS Enabled flag is 4802 Disabled (0). 4804 Bit Position DDS Status 4805 ------------ --------- 4806 31 (Lsb) DDS Enabled (1) / DDS Disabled (0) 4807 All Others RESERVED 4809 6.11.1.4 Discovery Domain Set Next ID 4811 This is a virtual attribute containing a 4-byte integer value that 4812 indicates the next available (i.e., unused) Discovery Domain Set 4813 Index value. This attribute may only be queried; the iSNS server 4814 SHALL return an error code of 3 (Invalid Registration) to any client 4815 that attempts to register a value for this attribute. A Message Key 4816 is not required when exclusively querying for this attribute. 4818 The Discovery Domain Set Next Index MAY be used by an SNMP client to 4819 create an entry in the iSNS server. SNMP requirements are described 4820 in Section 2.10. 4822 6.11.2 DD ID Keyed Attributes 4824 6.11.2.1 Discovery Domain ID (DD ID) 4826 The DD ID is an unsigned non-zero integer identifier used in the 4827 iSNS directory database as a key to uniquely identify a Discovery 4828 Domain. This value is used as the key for any DD attribute query. 4829 If the iSNS client does not provide a DD_ID in a DD registration 4830 request message, the iSNS server SHALL generate a DD_ID value that 4831 is unique within the iSNS database for that new DD (i.e., the iSNS 4832 client will be registered in a new DD). The created DD ID SHALL be 4833 returned in the response message. The DD ID value of 0 is reserved, 4834 and the DD ID value of 1 is used for the default DD (see section 4835 2.2.2). 4837 6.11.2.2 Discovery Domain Symbolic Name 4839 A variable-length UTF-8 encoded NULL-terminated text-based field of 4840 up to 256 bytes. When registered by a client, the DD symbolic name 4841 SHALL be verified to be unique by the iSNS server. If the DD 4842 symbolic name is not unique, then the DD registration SHALL be 4843 rejected with an "Invalid Registration" Status Code. The invalid 4844 attribute(s), in this case the DD symbolic name, SHALL be included 4845 in the response. 4847 6.11.2.3 Discovery Domain Member--iSCSI Node Index 4849 This is the iSCSI Node Index of a Storage Node that is a member of 4850 the DD. The DD may have a list of 0 to n members. The iSCSI Node 4851 Index is one alternative representation of membership in a Discovery 4852 Domain, the other alternative being the iSCSI Name. The Discovery 4853 Domain iSCSI Node Index is a 4-byte non-zero integer value. 4855 Internet Storage Name Service (iSNS) February 2004 4857 The iSCSI Node Index can be used to represent a DD member in 4858 situations where the iSCSI Name is too long to be used. An example 4859 of this is when SNMP is used for management, as described in Section 4860 2.10. 4862 The iSCSI Node Index and iSCSI Name stored as a member in a DD SHALL 4863 be consistent with the iSCSI Node Index and iSCSI Name attributes 4864 registered for the Storage Node object in the iSNS server. 4866 6.11.2.4 Discovery Domain Member--iSCSI Name 4868 A variable-length UTF-8 encoded NULL-terminated text-based field of 4869 up to 224 bytes. It indicates membership for the specified iSCSI 4870 Storage Node in the Discovery Domain. Note that the referenced 4871 Storage Node does not need to be actively registered in the iSNS 4872 database before the iSNS client uses this attribute. There is no 4873 limit to the number of members that may be in a DD. Membership is 4874 represented by the iSCSI Name of the iSCSI Storage Node. 4876 6.11.2.5 Discovery Domain Member--FC Port Name 4878 This 64-bit identifier attribute indicates membership for an iFCP 4879 Storage Node (FC Port) in the Discovery Domain . Note that the 4880 referenced Storage Node does not need to be actively registered in 4881 the iSNS database before the iSNS client uses this attribute. There 4882 is no limit to the number of members that may be in a DD. 4883 Membership is represented by the FC Port Name (WWPN) of the iFCP 4884 Storage Node. 4886 6.11.2.6 Discovery Domain Member--Portal Index 4888 This attribute indicates membership in the Discovery Domain for a 4889 Portal. It is an alternative representation for Portal membership 4890 to the Portal IP Address and Portal TCP/UDP Port. The referenced 4891 Portal MUST be actively registered in the iSNS database before the 4892 iSNS client uses this attribute. 4894 6.11.2.7 Discovery Domain Member--Portal IP Address 4896 This attribute, along with the Portal TCP/UDP Port attribute, 4897 indicates membership in the Discovery Domain for the specified 4898 Portal. Note that the referenced Portal does not need to be 4899 actively registered in the iSNS database before the iSNS client uses 4900 this attribute. 4902 6.11.2.8 Discovery Domain Member--Portal TCP/UDP Port 4904 This attribute, along with the Portal IP Address attribute, 4905 indicates membership in the Discovery Domain for the specified 4906 Portal. Note that the referenced Portal does not need to be 4907 actively registered in the iSNS database before the iSNS client uses 4908 this attribute. 4910 Internet Storage Name Service (iSNS) February 2004 4912 6.11.2.9 Discovery Domain Features 4914 The Discovery Domain Features is a bitmap indicating the features of 4915 this DD. The bit positions are defined below. A bit set to 1 4916 indicates the DD has the corresponding characteristics. 4918 Bit Position DD Feature 4919 ------------ ---------- 4920 31 (Lsb) Boot List Enabled (1)/Boot List Disabled (0) 4921 All Others RESERVED 4923 Boot List: this feature indicates that the target(s) in this DD 4924 provides boot capabilities for the member initiators, as described 4925 in [iSCSI-boot]. 4927 6.11.2.10 Discovery Domain Next ID 4929 This is a virtual attribute containing a 4-byte integer value that 4930 indicates the next available (i.e., unused) Discovery Domain Index 4931 value. This attribute may only be queried; the iSNS server SHALL 4932 return an error code of 3 (Invalid Registration) to any client that 4933 attempts to register a value for this attribute. A Message Key is 4934 not required when exclusively querying for this attribute. 4936 7. Security Considerations 4938 7.1 iSNS Security Threat Analysis 4940 When the iSNS protocol is deployed, the interaction between iSNS 4941 server and iSNS clients are subject to the following security 4942 threats: 4944 a) An attacker could alter iSNS protocol messages, such as to 4945 direct iSCSI and iFCP devices to establish connections with rogue 4946 peer devices, or to weaken/eliminate IPSec protection for iSCSI or 4947 iFCP traffic. 4949 b) An attacker could masquerade as the real iSNS server using false 4950 iSNS heartbeat messages. This could cause iSCSI and iFCP devices to 4951 use rogue iSNS servers. 4953 c) An attacker could gain knowledge about iSCSI and iFCP devices by 4954 snooping iSNS protocol messages. Such information could aid an 4955 attacker in mounting a direct attack on iSCSI and iFCP devices, such 4956 as a denial-of-service attack or outright physical theft. 4958 To address these threats, the following capabilities are needed: 4960 a) Unicast iSNS protocol messages may need to be authenticated. In 4961 addition, to protect against threat [c] above, confidentiality 4962 support is desirable, and REQUIRED when certain functions of iSNS 4963 server are utilized. 4965 Internet Storage Name Service (iSNS) February 2004 4967 b) Multicast iSNS protocol messages such as the iSNS heartbeat 4968 message may need to be authenticated. These messages need not be 4969 confidential since they do not leak critical information. 4971 7.2 iSNS Security Implementation and Usage Requirements 4973 If the iSNS server is used to distribute authorizations for 4974 communications between iFCP and iSCSI peer devices, IPsec ESP with 4975 null transform MUST be implemented, and non-null transform MAY be 4976 implemented. If a non-null transform is implemented, then the DES 4977 encryption algorithm SHOULD NOT be used. 4979 If the iSNS server is used to distribute security policy for iFCP 4980 and iSCSI devices, then authentication, data integrity, and 4981 confidentiality MUST be supported and used. Where confidentiality 4982 is desired or required, IPSec ESP with non-null transform SHOULD be 4983 used, and the DES encryption algorithm SHOULD NOT be used. 4985 If the iSNS server is used to provide the boot list for clients, as 4986 described in Section 6.11.2.9, then the iSCSI boot client SHOULD 4987 implement a secure iSNS connection. 4989 In order to protect against an attacker masquerading as an iSNS 4990 server, client devices MUST support the ability to authenticate 4991 broadcast or multicast messages such as the iSNS heartbeat. The 4992 iSNS authentication block (which is identical in format to the SLP 4993 authentication block) SHALL be used for this purpose. iSNS clients 4994 MUST implement the iSNS authentication block and MUST support BSD 4995 value 0x002. If the iSNS server supports broadcast or multicast 4996 iSNS messages (i.e., the heartbeat), then the server MUST implement 4997 the iSNS authentication block and MUST support BSD value 0x002. 4998 Note that the authentication block is used only for iSNS broadcast 4999 or multicast messages, and MUST NOT be used in unicast iSNS 5000 messages. 5002 There is no requirement that the communicating identities in iSNS 5003 protocol messages be kept confidential. Specifically, the identity 5004 and location of the iSNS server is not considered confidential. 5006 For protecting unicast iSNS protocol messages, iSNS servers 5007 supporting security MUST implement ESP in tunnel mode and MAY 5008 implement transport mode. 5010 All iSNS implementations supporting security MUST support the replay 5011 protection mechanisms of IPsec. 5013 iSNS security implementations MUST support both IKE Main Mode and 5014 Aggressive Mode for authentication, negotiation of security 5015 associations, and key management, using the IPSec DOI [RFC2407]. 5016 Manual keying SHOULD NOT be used since it does not provide the 5017 necessary rekeying support. Conformant iSNS security 5018 implementations MUST support authentication using a pre-shared key, 5019 and MAY support certificate-based peer authentication using digital 5020 signatures. Peer authentication using the public key encryption 5021 Internet Storage Name Service (iSNS) February 2004 5023 methods outlined in IKEs sections 5.2 and 5.3 [RFC2409] SHOULD NOT 5024 be supported. 5026 Conformant iSNS implementations MUST support both IKE Main Mode and 5027 Aggressive Mode. IKE Main Mode with pre-shared key authentication 5028 SHOULD NOT be used when either of the peers use dynamically assigned 5029 IP addresses. While Main Mode with pre-shared key authentication 5030 offers good security in many cases, situations where dynamically 5031 assigned addresses are used force the use a group pre-shared key, 5032 which is vulnerable to man-in-the-middle attack. IKE Identity 5033 Payload ID_KEY_ID MUST NOT be used. 5035 When digital signatures are used for authentication, either IKE Main 5036 Mode or IKE Aggressive Mode MAY be used. In all cases, access to 5037 locally stored secret information (pre-shared key or private key for 5038 digital signing) MUST be suitably restricted, since compromise of 5039 the secret information nullifies the security properties of the 5040 IKE/IPsec protocols. 5042 When digital signatures are used to achieve authentication, an IKE 5043 negotiator SHOULD use IKE Certificate Request Payload(s) to specify 5044 the certificate authority (or authorities) that are trusted in 5045 accordance with its local policy. IKE negotiators SHOULD check the 5046 pertinent Certificate Revocation List (CRL) before accepting a PKI 5047 certificate for use in IKE's authentication procedures. 5049 When the iSNS server is used without security, IP block storage 5050 protocol implementations MUST support a negative cache for 5051 authentication failures. This allows implementations to avoid 5052 continually contacting discovered endpoints that fail authentication 5053 within IPsec or at the application layer (in the case of iSCSI 5054 Login). The negative cache need not be maintained within the IPsec 5055 implementation, but rather within the IP block storage protocol 5056 implementation. 5058 7.3 Discovering Security Requirements of Peer Devices 5060 Once communication between iSNS clients and the iSNS server have 5061 been secured through use of IPSec, the iSNS client devices have the 5062 capability to discover the security settings that they need to use 5063 for their peer-to-peer communications using the iSCSI and/or iFCP 5064 protocols. This provides a potential scaling advantage over device- 5065 by-device configuration of individual security policies for each 5066 iSCSI and iFCP device. 5068 The iSNS server stores security settings for each iSCSI and iFCP 5069 device interface. These security settings, which can be retrieved 5070 by authorized hosts, include use or non-use of IPSec, IKE, Main 5071 Mode, and Aggressive Mode. For example, IKE may not be enabled for 5072 a particular interface of a peer device. If a peer device can learn 5073 of this in advance by consulting the iSNS server, it will not need 5074 to waste time and resources attempting to initiate an IKE phase 1 5075 session with that peer device interface. 5077 Internet Storage Name Service (iSNS) February 2004 5079 If iSNS is used for this purpose, then the minimum information that 5080 should be learned from the iSNS server is the use or non-use of IKE 5081 and IPSec by each iFCP or iSCSI peer device interface. This 5082 information is encoded in the Security Bitmap field of each Portal 5083 of the peer device, and is applicable on a per-interface basis for 5084 the peer device. iSNS queries to acquire security configuration 5085 data about peer devices MUST be protected by IPSec/ESP 5086 authentication. 5088 7.4 Configuring Security Policies of iFCP/iSCSI Devices 5090 Use of iSNS for distribution of security policies offers the 5091 potential to reduce the burden of manual device configuration, and 5092 decrease the probability of communications failures due to 5093 incompatible security policies. If iSNS is used to distribute 5094 security policies, then IPSec authentication, data integrity, and 5095 confidentiality MUST be used to protect all iSNS protocol messages. 5097 The complete IKE/IPSec configuration of each iFCP and/or iSCSI 5098 device can be stored in the iSNS server, including policies that are 5099 used for IKE Phase 1 and Phase 2 negotiations between client 5100 devices. The IKE payload format includes a series of one or more 5101 proposals that the iSCSI or iFCP device will use when negotiating 5102 the appropriate IPsec policy to use to protect iSCSI or iFCP 5103 traffic. 5105 In addition, the iSCSI Authentication Methods used by each iSCSI 5106 device can also be stored in the iSNS server. The iSCSI AuthMethod 5107 field (tag=42) contains a null-terminated string embedded with the 5108 text values indicating iSCSI authentication methods to be used by 5109 that iSCSI device. 5111 Note that iSNS distribution of security policy is not necessary if 5112 the security settings can be determined by other means, such as 5113 manual configuration or IPsec security policy distribution. If a 5114 network entity has already obtained its security configuration via 5115 other mechanisms, then it MUST NOT request security policy via iSNS. 5117 7.5 Resource Issues 5119 The iSNS protocol is lightweight, and will not generate a 5120 significant amount of traffic. iSNS traffic is characterized by 5121 occasional registration, notification, and update messages that do 5122 not consume significant amounts of bandwidth. Even software-based 5123 IPSec implementations should not have a problem handling the traffic 5124 loads generated by the iSNS protocol. 5126 To fulfill iSNS security requirements, the only additional resources 5127 needed beyond what is already required for iSCSI and iFCP involves 5128 the iSNS server. Since iSCSI and iFCP end nodes are already 5129 required to implement IKE and IPSec, these existing requirements can 5130 also be used to fulfill IKE and IPSec requirements for iSNS clients. 5132 Internet Storage Name Service (iSNS) February 2004 5134 7.6 iSNS Interaction with IKE and IPSec 5136 When IPSec security is enabled, each iSNS client with at least one 5137 Storage Node that is registered in the iSNS database SHALL maintain 5138 at least one phase-1 security association with the iSNS server. All 5139 iSNS protocol messages between iSNS clients and the iSNS server 5140 SHALL be protected by a phase-2 security association. 5142 When a Network Entity is removed from the iSNS database, the iSNS 5143 server SHALL send a phase-1 delete message to the associated iSNS 5144 client IKE peer, and tear down all phase-1 and phase-2 SAs 5145 associated with that iSNS client. 5147 8. IANA Considerations 5149 The well-known TCP and UDP port number for iSNS is 3205. 5151 The standards action of this RFC creates two registries to be 5152 maintained by IANA in support of iSNSP and assigns initial values 5153 for both registries. The first registry is of Block Storage 5154 Protocols supported by iSNS. The second registry is a detailed 5155 registry of standard iSNS attributes that can be registered to and 5156 queried from the iSNS server. Also note that this RFC utilizes the 5157 registry created for Block Structure Descriptor (BSD) in section 15 5158 of Service Location Protocol, Version 2 [RFC2608]. 5160 8.1 Registry of Block Storage Protocols 5162 In order to maintain a registry of block storage protocols supported 5163 by iSNSP, IANA will assign a 32-bit unsigned integer number for each 5164 block storage protocol supported by iSNS. This number is stored in 5165 the iSNS database as the Entity Protocol. The initial set of values 5166 to be maintained by IANA for Entity Protocol is indicated in the 5167 table in section 6.2.2. Additional values for new block storage 5168 protocols to be supported by iSNS SHALL be assigned by the IPS WG 5169 Chairperson, or a Designated Expert [RFC2434] appointed by the IETF 5170 Transport Area Director. 5172 8.2 Registry of Standard iSNS Attributes 5174 IANA is responsible for creating and maintaining the Registry of 5175 Standard iSNS Attributes. The initial list of iSNS attributes 5176 described in section 6. This information MUST include for each iSNS 5177 attribute, its tag value, the attribute length, and the tag values 5178 for the set of permissible registration and query keys that can be 5179 used for that attribute. The initial list of iSNS attributes to be 5180 maintained by IANA is indicated in section 6.1. 5182 Additions of new standard attributes to the Registry of Standard 5183 iSNS Attributes SHALL require IETF Consensus [RFC2434]. The RFC 5184 required for this process SHALL specify use of tag values reserved 5185 for IANA allocation in section 6.1. The RFC SHALL specify as a 5186 minimum, the new attribute tag value, attribute length, and the set 5187 of permissible registration and query keys that can be used for the 5188 Internet Storage Name Service (iSNS) February 2004 5190 new attribute. The RFC SHALL also include a discussion of the 5191 reasons for the new attribute(s) and how the new attribute(s) are to 5192 be used. 5194 As part of the process of obtaining IETF Consensus, the proposed RFC 5195 and its supporting documentation SHALL be made available to the IPS 5196 WG mailing list, or if the IPS WG is disbanded at the time to a 5197 mailing list designated by the IETF Transport Area Director. The 5198 review and comment period SHALL last at least three months before 5199 the IPS WG Chair or a person designated by the IETF Transport Area 5200 Director decides to either reject the proposal or forward the draft 5201 to the IESG for publication as an RFC. When the specification is 5202 published as an RFC, then IANA will register the new iSNS 5203 attribute(s) and make the registration available to the community. 5205 8.3 Block Structure Descriptor (BSD) Registry 5207 Note that IANA is already responsible for assigning and maintaining 5208 values used for the Block Structure Descriptor for the iSNS 5209 Authentication Block (see section 5.5). Section 15 of [RFC2608] 5210 describes the process for allocation of new BSD values. 5212 Internet Storage Name Service (iSNS) February 2004 5214 9. Normative References 5216 [iSCSI] Satran, J., et al., iSCSI, Internet draft (work in 5217 progress), draft-ietf-ips-iSCSI-20.txt, January 2003 5219 [iFCP] Monia, C., et al., iFCP - A Protocol for Internet Fibre 5220 Channel Storage Networking, Internet draft (work in 5221 progress), draft-ietf-ips-ifcp-14.txt, December 2002 5223 [iSNSOption] Monia, Tseng, Gibbons, The IPv4 DHCP Option for the 5224 Internet Storage Name Service, Internet draft (work in 5225 progress), draft-ietf-dhc-isnsoption-10.txt, September 5226 2003 5228 [RFC2608] Guttman, E., Perkins, C., Veizades, J., Day, M., Service 5229 Location Protocol, Version 2, RFC 2608, June 1999 5231 [iSCSI-SLP] Bakke, M., Finding iSCSI Targets and Name Servers Using 5232 SLP, Internet draft (work in progress), draft-ietf-ips- 5233 iscsi-slp-06.txt, March 2003 5235 [iSCSI-boot] Sarkar, P., et al, Bootstrapping Clients using the 5236 iSCSI Protocol (work in progress), draft-ietf-ips-iscsi- 5237 boot-11.txt, July 2003 5239 [RFC2119] Bradner, S., Key Words for Use in RFCs to Indicate 5240 Requirement Levels, BCP 14, RFC 2119, March 1997 5242 [SEC-IPS] Aboba, B., et al., Securing Block Storage Protocols over 5243 IP (work in progress), draft-ietf-ips-security-19.txt, 5244 January 2003 5246 [STRINGPREP] Bakke, M. String Profile for iSCSI Names (work in 5247 progress), draft-ietf-ips-string-prep-06.txt, August 5248 2003 5250 [NAMEPREP] Hoffman, P. Nameprep: A Stringprep Profile for 5251 Internationalized Domain Names, July 2002 5253 [RFC2401] Atkinson, R., Kent, S., Security Architecture for the 5254 Internet Protocol, RFC 2401, November 1998 5256 [RFC2406] Kent, S., Atkinson, R., IP Encapsulating Security 5257 Payload (ESP), RFC 2406, November 1998 5259 [RFC2407] Piper, D., The Internet IP Security Domain of 5260 Interpretation of ISAKMP, RFC 2407, November 1998 5262 [RFC2408] Maughan, D., Schertler, M., Schneider, M., Turner, J., 5263 Internet Security Association and Key Management 5264 Protocol (ISAKMP), RFC 2408, November 1998 5265 Internet Storage Name Service (iSNS) February 2004 5267 [RFC2409] Harkins, D., Carrel, D., The Internet Key Exchange 5268 (IKE), RFC 2409, November 1998 5270 [RFC2412] Orman, H., The OAKLEY Key Determination Protocol, RFC 5271 2412, November 1998 5273 [RFC793] Postel, J., Transmission Control Protocol, STD 7, RFC 5274 793, September 1981 5276 [RFC3513] Hinden, R., IP Version 6 Addressing Architecture, 5277 RFC3513, April, 2003 5279 [DSS] FIPS PUB 186-2, National Institute of Standards and 5280 Technology, Digital Signature Standard (DSS), Technical 5281 Report 5283 [EUI-64] Guidelines for 64-bit Global Identifier (EUI-64) 5284 Registration Authority, May 2001, IEEE 5286 [RFC3279] Polk, W., Algorithms and Identifiers for the Internet 5287 X.509 Public Key Infrastructure Certificate and 5288 Certificate Revocation List (CRL) Profile, RFC3279, 5289 April 2002 5291 [RFC3280] Housley, R., Internet X.509 Public Key Infrastructure 5292 Certificate and Certificate Revocation List (CRL) 5293 Profile, RFC3280, April 2002 5295 [802-1990] IEEE Standards for Local and Metropolitan Area Networks: 5296 Overview and Architecture, Technical Committee on 5297 Computer Communications of the IEEE Computer Society, 5298 May 31, 1990 5300 [FC-FS] Fibre Channel Framing and Signaling Interface, NCITS 5301 Working Draft Project 1331-D 5303 10. Informative References 5305 [iSCSIName] Bakke, M., et al., iSCSI Naming and Discovery, draft- 5306 ietf-ips-iscsi-name-disc-10.txt (work in progress), June 5307 2003 5309 [iSNSMIB] Gibbons, K., et al., Definitions of Managed Objects for 5310 iSNS (Internet Storage name Service) (work in progress), 5311 draft-ietf-ips-isns-mib-05.txt, July 2003 5313 [X.509] ITU-T Recommendation X.509 (1997 E): Information 5314 Technology - Open Systems Interconnection - The 5315 Directory: Authentication Framework, June 1997 5317 [RFC1035] Mockapetris, P., Domain Names - Implementation and 5318 Specification, RFC 1035, November 1987 5319 Internet Storage Name Service (iSNS) February 2004 5321 [RFC1305] Mills, D., Network Time Protocol (Version 3), RFC 1305, 5322 March 1992 5324 [FC-GS-3] Fibre Channel Generic Services-3, NCITS 348-2000 5326 [FC-GS-4] Fibre Channel Generic Services-4 (work in progress), 5327 NCITS Working Draft Project 1505-D 5329 [RFC2026] Bradner, S. The Internet Standards Process -- Revision 5330 3, BCP 9, RFC 2026, October 1996 5332 [RFC1510] Kohl, J., The Kerberos Network Authentication Service 5333 (V5), RFC 1510, September 1993 5335 [RFC2025] Adams, C., The Simple Public-Key GSS-API Mechanism 5336 (SPKM), RFC 2025, October 1996 5338 [RFC2434] Narten, T., Guidelines for Writing an IANA 5339 Considerations Section in RFCs, BCP 26, RFC2434, October 5340 1998 5342 [RFC2945] Wu, T., The SRP Authentication and Key Exchange System, 5343 RFC 2945, September 2000 5345 [RFC1994] Simpson, W., PPP Challenge Handshake Authentication 5346 Protocol (CHAP), August 1996 5348 [RFC2131] Droms, R., Dynamic Host Configuration Protocol, March 5349 1997 5351 [RFC3410] Case, J., et al., Introduction and Applicability 5352 Statements for Internet Standard Management Framework, 5353 RFC 3410, December 2002 5355 [RFC3411] Harrington, D., et al., An Architecture for Describing 5356 Simple Network Management Protocol (SNMP) Management 5357 Frameworks, RFC 3411, December 2002 5358 Internet Storage Name Service (iSNS) February 2004 5360 11. Author's Addresses 5362 Josh Tseng 5363 McDATA Corporation 5364 3850 North First Street 5365 San Jose, CA 95134-1702 5366 Phone: (408) 519-3749 5367 Email: joshua.tseng@mcdata.com 5369 Kevin Gibbons 5370 McDATA Corporation 5371 3850 North First Street 5372 San Jose, CA 95134-1702 5373 Phone: (408) 519-3756 5374 Email: kevin.gibbons@mcdata.com 5376 Franco Travostino 5377 Nortel Networks 5378 3 Federal Street 5379 Billerica, MA 01821 5380 Phone: (978) 288-7708 5381 Email: travos@nortelnetworks.com 5383 Curt Du Laney 5384 IBM 5385 4205 South Miami Blvd 5386 Research Triangle Park, NC 27709 5387 Phone: (919) 254-5632 5388 Email: dulaney@us.ibm.com 5390 Joe Souza 5391 Microsoft Corporation 5392 One Microsoft Way 5393 Redmond, WA 98052-6399 5394 Phone: (425) 706-3135 5395 Email: joes@microsoft.com 5396 Internet Storage Name Service (iSNS) February 2004 5398 Full Copyright Statement 5400 "Copyright (C) The Internet Society 2003. All Rights Reserved. This 5401 document and translations of it may be copied and furnished to 5402 others, and derivative works that comment on or otherwise explain it 5403 or assist in its implementation may be prepared, copied, published 5404 and distributed, in whole or in part, without restriction of any 5405 kind, provided that the above copyright notice and this paragraph 5406 are included on all such copies and derivative works. However, this 5407 document itself may not be modified in any way, such as by removing 5408 the copyright notice or references to the Internet Society or other 5409 Internet organizations, except as needed for the purpose of 5410 developing Internet standards in which case the procedures for 5411 copyrights defined in the Internet Standards process must be 5412 followed, or as required to translate it into languages other than 5413 English. 5415 The limited permissions granted above are perpetual and will not be 5416 revoked by the Internet Society or its successors or assigns. 5418 This document and the information contained herein is provided on an 5419 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 5420 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 5421 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 5422 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 5423 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 5425 Notice of Intellectual Property Rights 5427 The IETF takes no position regarding the validity or scope of any 5428 intellectual property or other rights that might be claimed to 5429 pertain to the implementation or use of the technology described in 5430 this document or the extent to which any license under such rights 5431 might or might not be available; neither does it represent that it 5432 has made any effort to identify any such rights. Information on the 5433 IETF's procedures with respect to rights in standards-track and 5434 standards-related documentation can be found in BCP-11. Copies of 5435 claims of rights made available for publication and any assurances 5436 of licenses to be made available, or the result of an attempt made 5437 to obtain a general license or permission for the use of such 5438 proprietary rights by implementors or users of this specification 5439 can be obtained from the IETF Secretariat. 5441 The IETF invites any interested party to bring to its attention any 5442 copyrights, patents or patent applications, or other proprietary 5443 rights which may cover technology that may be required to practice 5444 this standard. Please address the information to the IETF Executive 5445 Director. 5447 Internet Storage Name Service (iSNS) February 2004 5449 Appendix A -- iSNS Examples 5451 A.1 iSCSI Initialization Example 5453 This example assumes an SLP Service Agent (SA) has been implemented 5454 on the iSNS host, and an SLP User Agent (UA) has been implemented on 5455 the iSNS initiator. See [RFC2608] for further details on SAs and 5456 UAs. This example also assumes the target is configured to use the 5457 iSNS server, and have its access control policy subordinated to the 5458 iSNS server. 5460 A.1.1 Simple iSCSI Target Registration 5462 In this example, a simple target with a single iSCSI name registers 5463 with the iSNS server. The target is represented in the iSNS by an 5464 Entity containing one Storage Node, one Portal, and an implicitly 5465 registered Portal Group that provides a relationship between the 5466 Storage Node and Portal. The target has not been assigned a Fully 5467 Qualified Domain Name (FQDN) by the administrator. In this example, 5468 since a PG object is not explicitly registered, a Portal Group with 5469 a PGT of 1 is implicitly registered. In this example SLP is used to 5470 discover the location of the iSNS Server. An alternative is to use 5471 the iSNS DHCP option [iSNSOption] to discover the iSNS server. 5473 +--------------------------+------------------+-------------------+ 5474 | iSCSI Target Device | iSNS Server |Management Station | 5475 +--------------------------+------------------+-------------------+ 5476 |Discover iSNS--SLP------->| |/*mgmt station is | 5477 | |<--SLP--iSNS Here:| administratively | 5478 | | 192.0.2.100 | authorized to view| 5479 | | | all DDs. Device | 5480 | DevAttrReg--------->| | NAMEabcd was | 5481 |Src:(tag=32) "NAMEabcd" | | previously placed | 5482 |Key: | | into DDabcd along | 5483 |Oper Attrs: | | with devpdq and | 5484 |tag=1: NULL | | devrst. | 5485 |tag=2: "iSCSI" | | | 5486 |tag=16: 192.0.2.5 | | | 5487 |tag=17: 5001 | | | 5488 |tag=32: "NAMEabcd" | | | 5489 |tag=33: target | | | 5490 |tag=34: "disk 1" | | | 5491 | |<---DevAttrRegRsp | | 5492 | |SUCCESS | | 5493 | |Key:(tag=1) "isns:0001" | 5494 | |Oper Attrs: | | 5495 | |tag=1: "isns:0001"| | 5496 | |tag=2: "iSCSI" | | 5497 | |tag=16: 192.0.2.5 | | 5498 | |tag=17: 5001 | | 5499 | |tag=32: "NAMEabcd"|/* previously | 5500 | |tag=33: target | placed in a DD */ | 5501 | |tag=34: "disk 1" | | 5502 | | | | 5503 Internet Storage Name Service (iSNS) February 2004 5505 | | SCN-------->| | 5506 | |(or SNMP notification) | 5507 | |dest:(tag=32):"MGMTname1" | 5508 | |time:(tag=4): | 5509 | |tag=35: "MGT-SCN, OBJ-ADD" | 5510 | |tag=32: "NAMEabcd"| | 5511 | | |<-------SCNRsp | 5512 | DevAttrQry--------->| | | 5513 |Src:(tag=32) "NAMEabcd" | | | 5514 |Key:(tag=33) "initiator" | | | 5515 |Oper Attrs: | | | 5516 |tag=16: NULL | | | 5517 |tag=17: NULL | | | 5518 |tag=32: NULL | | | 5519 |/*Query asks for all initr| | | 5520 |devices' IP address, port |<---DevAttrQryRsp | | 5521 |number, and Name*/ |SUCCESS | | 5522 | |tag=16:192.0.2.1 | | 5523 | |tag=17:50000 | | 5524 | |tag=32:"devpdq" | | 5525 | |tag=16:192.0.2.2 | | 5526 | |tag=17:50000 | | 5527 | |tag=32:"devrst" | | 5528 |/*************************| |<-----DevAttrQry | 5529 |Our target "NAMEabcd" | |src: "MGMTname1" | 5530 |discovers two initiators | key:(tag=32)"NAMEabcd" 5531 |in shared DDs. It will | |Op Attrs: | 5532 |accept iSCSI logins from | |tag=16: NULL | 5533 |these two identified | |tag=17: NULL | 5534 |initiators presented by | |tag=32: NULL | 5535 |iSNS | | | 5536 |*************************/| DevAttrQryRsp--->| | 5537 | |SUCCESS | | 5538 | |tag=16: 192.0.2.5 | | 5539 | |tag=17: 5001 | | 5540 | |tag=32: "NAMEabcd"| | 5541 +--------------------------+------------------+-------------------+ 5543 A.1.2 Target Registration and DD Configuration 5545 In this example, a more complex target, with two Storage Nodes and 5546 two Portals using ESI monitoring, registers with the iSNS. This 5547 target has been configured with a Fully Qualified Domain Name (FQDN) 5548 in the DNS servers, and the user wishes to use this identifier for 5549 the device. The target explicitly registers Portal Groups to 5550 describe how each Portal provides access to each Storage Node. One 5551 target Storage Node allows coordinated access through both Portals. 5552 The other Storage Node allows access, but not coordinated access, 5553 through both Portals. 5555 Internet Storage Name Service (iSNS) February 2004 5557 +--------------------------+------------------+-------------------+ 5558 | iSCSI Target Device | iSNS Server |Management Station | 5559 +--------------------------+------------------+-------------------+ 5560 |Discover iSNS--SLP--> | |/*mgmt station is | 5561 | |<--SLP--iSNS Here:| administratively | 5562 | | 192.0.2.100 | authorized to view| 5563 | DevAttrReg--> | | all DDs */ | 5564 |Src: | | | 5565 |tag=32: "NAMEabcd" | | | 5566 |Msg Key: | | | 5567 |tag=1: "jbod1.example.com"| | | 5568 |Oper Attrs: | | | 5569 |tag=1: "jbod1.example.com"| | | 5570 |tag=2: "iSCSI" | | | 5571 |tag=16: 192.0.2.4 | | | 5572 |tag=17: 5001 | | | 5573 |tag=19: 5 | | | 5574 |tag=20: 5002 | | | 5575 |tag=16: 192.0.2.5 | | | 5576 |tag=17: 5001 | | | 5577 |tag=19: 5 | | | 5578 |tag=20: 5002 | | | 5579 |tag=32: "NAMEabcd" | | | 5580 |tag=33: "Target" | | | 5581 |tag=34: "Storage Array 1" | | | 5582 |tag=51: 10 | | | 5583 |tag=49: 192.0.2.4 | | | 5584 |tag=50: 5001 | | | 5585 |tag=49: 192.0.2.5 | | | 5586 |tag=50: 5001 | | | 5587 |tag=32: "NAMEefgh" | | | 5588 |tag=33: "Target" | | | 5589 |tag=34: "Storage Array 2" |/*****************| | 5590 |tag=51: 20 |jbod1.example.com is | 5591 |tag=49: 192.0.2.4 |now registered in | | 5592 |tag=50: 5001 |iSNS, but is not | | 5593 |tag=51: 30 |in any DD. Therefore, | 5594 |tag=49: 192.0.2.5 |no other devices | | 5595 |tag=50: 5001 |can "see" it. | | 5596 | |*****************/| | 5597 | |<--DevAttrRegRsp | | 5598 | |SUCCESS | | 5599 | |Msg Key: | | 5600 | |tag=1: "jbod1.example.com" | 5601 | |Oper Attrs: | | 5602 | |tag=1: "jbod1.example.com" | 5603 | |tag=2: "iSCSI" | | 5604 | |tag=16: 192.0.2.4 | | 5605 | |tag=17: 5001 | | 5606 | |tag=19: 5 | | 5607 | |tag=20: 5002 | | 5608 | |tag=16: 192.0.2.5 | | 5609 | |tag=17: 5001 | | 5610 | |tag=19: 5 | | 5611 Internet Storage Name Service (iSNS) February 2004 5613 | |tag=20: 5002 | | 5614 | |tag=32: "NAMEabcd"| | 5615 | |tag=33: "Target" | | 5616 | |tag=34: "Storage Array 1" | 5617 | |tag=48: "NAMEabcd"| | 5618 | |tag=49: 192.0.2.4 | | 5619 | |tag=50: 5001 | | 5620 | |tag=51: 10 | | 5621 | |tag=48: "NAMEabcd"| | 5622 | |tag=49: 192.0.2.5 | | 5623 | |tag=50: 5001 | | 5624 | |tag=51: 10 | | 5625 | |tag=32: "NAMEefgh"| | 5626 | |tag=33: "Target" | | 5627 | |tag=34: "Storage Array 2" | 5628 | |tag=43: X.509 cert| | 5629 | |tag=48: "NAMEefgh"| | 5630 | |tag=49: 192.0.2.4 | | 5631 | |tag=50: 5001 | | 5632 | |tag=51: 20 | | 5633 | |tag=48: "NAMEefgh"| | 5634 | |tag=49: 192.0.2.5 | | 5635 | |tag=50: 5001 | | 5636 | |tag=51: 30 | | 5637 | | | | 5638 | | SCN------> | | 5639 | | (or SNMP notification) | 5640 | |dest:(tag=32)"mgmt.example.com" | 5641 | |time:(tag=4): | 5642 | |tag=35: "MGT-SCN, OBJ-ADD" | 5643 | |tag=32: "NAMEabcd"| | 5644 | |tag=35: "MGT-SCN, OBJ-ADD" | 5645 | |tag=32: "NAMEefgh"| | 5646 | | |<--SCNRsp | 5647 | | |SUCCESS | 5648 | | tag=32:"mgmt.example.com"| 5649 | | | | 5650 | | |<--DevAttrQry | 5651 | | |Src: | 5652 | | tag=32:"mgmt.example.com" 5653 | | |Msg Key: | 5654 | | |tag=32: "NAMEabcd" | 5655 | | |Oper Attrs: | 5656 | | |tag=16: <0-length> | 5657 | | |tag=17: <0-length> | 5658 | | |tag=32: <0-length> | 5659 | | | | 5660 | | DevAttrQryRsp--> | | 5661 | |SUCCESS | | 5662 | |Msg Key: | | 5663 | |tag=32: "NAMEabcd"| | 5664 | |Oper Attrs: | | 5665 | |tag=16: 192.0.2.4 | | 5666 | |tag=17: 5001 | | 5667 Internet Storage Name Service (iSNS) February 2004 5669 | |tag=32:"NAMEabcd" | | 5670 | |tag=16: 192.0.2.5 | | 5671 | |tag=17: 5001 | | 5672 | |tag=32:"NAMEabcd" | | 5673 | | |Src: | 5674 | | tag=32:"mgmt.example.com" 5675 | | |Msg Key: | 5676 | | |tag=32: "NAMEefgh" | 5677 | | |Oper Attrs: | 5678 | | |tag=16: <0-length> | 5679 | | |tag=17: <0-length> | 5680 | | |tag=32: <0-length> | 5681 | | | | 5682 | | DevAttrQryRsp--> | | 5683 | |SUCCESS | | 5684 | |Msg Key: | | 5685 | |tag=32: "NAMEefgh"| | 5686 | |Oper Attrs: | | 5687 | |tag=16: 192.0.2.4 | | 5688 | |tag=17: 5001 | | 5689 | |tag=32:"NAMEefgh" | | 5690 | |tag=16: 192.0.2.5 |/**Mgmt Station ***| 5691 | |tag=17: 5001 |displays device, | 5692 | |tag=32:"NAMEefgh" |the operator decides 5693 | | |to place "NAMEabcd"| 5694 | | |into Domain "DDxyz"| 5695 |/*************************| |******************/| 5696 |Target is now registered | | | 5697 |in iSNS. It is then placed| |<--DDReg | 5698 |in a pre-existing DD with | |Src: | 5699 |DD_ID 123 by a management | tag=32:"mgmt.example.com" 5700 |station. | |Msg Key: | 5701 |*************************/| |tag=2065: 123 | 5702 | | |Oper Attrs: | 5703 | | |tag=2068: "NAMEabcd" 5704 | | DDRegRsp-----> | | 5705 | |SUCCESS | | 5706 | |Msg Key: | | 5707 | |tag=2065: 123 | | 5708 | |Oper Attrs: | | 5709 | |tag=2065: 123 | | 5710 +--------------------------+------------------+-------------------+ 5712 A.1.3 Initiator Registration and Target Discovery 5714 The following example illustrates a new initiator registering with 5715 the iSNS, and discovering the target NAMEabcd from the example in 5716 A.1.2. 5718 Internet Storage Name Service (iSNS) February 2004 5720 +--------------------------+------------------+-------------------+ 5721 | iSCSI Initiator | iSNS |Management Station | 5722 +--------------------------+------------------+-------------------+ 5723 |Discover iSNS--SLP--> | |/*mgmt station is | 5724 | |<--SLP--iSNS Here:| administratively | 5725 | | 192.36.53.1 | authorized to view| 5726 |DevAttrReg--> | | all DDs ********/ | 5727 |Src: | | | 5728 |tag=32: "NAMEijkl" | | | 5729 |Msg Key: | | | 5730 |tag=1: "svr1.example.com" | | | 5731 |Oper Attrs: | | | 5732 |tag=1: "svr1.example.com" | | | 5733 |tag=2: "iSCSI" | | | 5734 |tag=16: 192.20.3.1 |/*****************| | 5735 |tag=17: 5001 |Device not in any | | 5736 |tag=19: 5 |DD, so it is | | 5737 |tag=20: 5002 |inaccessible by | | 5738 |tag=32: "NAMEijkl" |other devices | | 5739 |tag=33: "Initiator" |*****************/| | 5740 |tag=34: "Server1" | | | 5741 |tag=51: 11 | | | 5742 |tag=49: 192.20.3.1 | | | 5743 |tag=50: 5001 | | | 5744 | |<--DevAttrRegRsp | | 5745 | |SUCCESS | | 5746 | |Msg Key: | | 5747 | |tag=1: "svr1.example.com" | 5748 | |Oper Attrs: | | 5749 | |tag=1: "svr1.example.com" | 5750 | |tag=2: "iSCSI" | | 5751 | |tag=16: 192.20.3.1| | 5752 | |tag=17: 5001 | | 5753 | |tag=19: 5 | | 5754 | |tag=20: 5002 | | 5755 | |tag=32: "NAMEijkl"| | 5756 | |tag=33: "Initiator" | 5757 | |tag=34: "Server1" | | 5758 | |tag=48: "NAMEijkl"| | 5759 | |tag=49: 192.20.3.1| | 5760 | |tag=50: 5001 | | 5761 | |tag=51: 11 | | 5762 | | | | 5763 | | SCN------> | | 5764 | | (or SNMP notification) | 5765 | |dest:(tag=32)"mgmt.example.com" | 5766 | |time:(tag=4): | 5767 | |tag=35: "MGT-SCN, OBJ-ADD" | 5768 | |tag=32: "NAMEijkl"| | 5769 | | | | 5770 | | |<------SCNRsp | 5771 | | |SUCCESS | 5772 | | tag=32:"mgmt.example.com" 5773 | | | | 5774 Internet Storage Name Service (iSNS) February 2004 5776 |SCNReg--> | | | 5777 |Src: | | | 5778 |tag=32: "NAMEijkl" | | | 5779 |Msg Key: | | | 5780 |tag=32: "NAMEijkl" | | | 5781 |Oper Attrs: | | | 5782 |tag=35: | | 5783 | |<--SCNRegRsp | | 5784 | |SUCCESS | | 5785 | | | | 5786 | | |<----DevAttrQry | 5787 | | |Src: | 5788 | | tag=32:"mgmt.example.com" 5789 | | |Msg Key: | 5790 | | |tag=32: "NAMEijkl" | 5791 | | |Oper Attrs: | 5792 | | |tag=16: <0-length> | 5793 | | |tag=17: <0-length> | 5794 | | |tag=32: <0-length> | 5795 | | DevAttrQryRsp--->| | 5796 | |SUCCESS | | 5797 | |Msg Key: | | 5798 | |tag=32: "NAMEijkl"| | 5799 | |Oper Attrs: | | 5800 | |tag=16:192.20.3.1 | | 5801 | |tag=17: 5001 | | 5802 | |tag=32:"NAMEijkl" | | 5803 | | |/**Mgmt Station ***| 5804 | | |displays device, the 5805 | | |operator decides to| 5806 | | |place "NAMEijkl" into 5807 | | |pre-existing Disc | 5808 | | |Domain "DDxyz" with| 5809 | | |device NAMEabcd | 5810 | | |******************/| 5811 | | |<--DDReg | 5812 | | |Src: | 5813 | | tag=32:"mgmt.example.com" 5814 | | |Msg Key: | 5815 | | |tag=2065: 123 | 5816 | | |Oper Attrs: | 5817 | | |tag=2068: "NAMEijkl" 5818 | | | | 5819 | | DDRegRsp---->| | 5820 | |SUCCESS | | 5821 | |Msg Key: | | 5822 | |tag=2065: 123 | | 5823 | |Oper Attrs: | | 5824 | |tag=2065: 123 |/******************| 5825 | | |"NAMEijkl" has been| 5826 | | |moved to "DDxyz" | 5827 | | |******************/| 5828 | | SCN------>| | 5829 | |dest:(tag=32)"mgmt.example.com" | 5830 Internet Storage Name Service (iSNS) February 2004 5832 | |time:(tag=4): | 5833 | |tag=35: | 5834 | |tag=2065: 123 | | 5835 | |tag=2068: "NAMEijkl" | 5836 | | | | 5837 | | |<------SCNRsp | 5838 | | |SUCCESS | 5839 | | tag=32:"mgmt.example.com" 5840 | |<-----SCN | | 5841 | |dest:(tag=32)"NAMEijkl" | 5842 | |time:(tag=4): | 5843 | |tag=35: | 5844 | |tag=32: "NAMEijkl"| | 5845 | SCNRsp------> | | | 5846 |SUCCESS | | | 5847 |tag=32:"NAMEijkl" | | | 5848 | | | | 5849 | |/*****************| | 5850 | |Note that NAMEabcd| | 5851 | |also receives an | | 5852 | |SCN that NAMEijkl | | 5853 | |is in the same DD | | 5854 | |*****************/| | 5855 | (to "NAMEabcd")|<-----SCN | | 5856 | |dest:(tag=32)"NAMEabcd" | 5857 | |time:(tag=4): | 5858 | |tag=35: | 5859 | |tag=32: "NAMEijkl"| | 5860 | SCNRsp------> | | | 5861 |SUCCESS | | | 5862 |tag=32:"NAMEabcd" | | | 5863 | | | | 5864 | DevAttrQry----------->| | | 5865 |Src: | | | 5866 |tag=32: "NAMEijkl" | | | 5867 |Msg Key: | | | 5868 |tag=33: "Target" | | | 5869 |Oper Attrs: | | | 5870 |tag=16: <0-length> | | | 5871 |tag=17: <0-length> | | | 5872 |tag=32: <0-length> | | | 5873 |tag=34: <0-length> | | | 5874 |tag=43: <0-length> | | | 5875 |tag=48: <0-length> | | | 5876 |tag=49: <0-length> | | | 5877 |tag=50: <0-length> | | | 5878 |tag=51: <0-length> | | | 5879 | |<--DevAttrQryRsp | | 5880 | |SUCCESS | | 5881 | |Msg Key: | | 5882 | |tag=33:"Target" | | 5883 | |Oper Attrs: | | 5884 | |tag=16: 192.0.2.4 | | 5885 | |tag=17: 5001 | | 5886 Internet Storage Name Service (iSNS) February 2004 5888 | |tag=32: "NAMEabcd"| | 5889 | |tag=34: "Storage Array 1" | 5890 | |tag=16: 192.0.2.5 | | 5891 | |tag=17: 5001 | | 5892 | |tag=32: "NAMEabcd"| | 5893 | |tag=34: "Storage Array 1" | 5894 | |tag=43: X.509 cert| | 5895 | |tag=48: "NAMEabcd"| | 5896 | |tag=49: 192.0.2.4 | | 5897 | |tag=50: 5001 | | 5898 | |tag=51: 10 | | 5899 | |tag=48: "NAMEabcd"| | 5900 | |tag=49: 192.0.2.5 | | 5901 | |tag=50: 5001 | | 5902 | |tag=51: 10 | | 5903 | | | | 5904 |/***The initiator has discovered | | 5905 |the target, and has everything | | 5906 |needed to complete iSCSI login | | 5907 |The same process occurs on the | | 5908 |target side; the SCN prompts the | | 5909 |target to download the list of | | 5910 |authorized initiators from the | | 5911 |iSNS (i.e., those initiators in the | | 5912 |same DD as the target.************/ | | 5913 +--------------------------+------------------+-------------------+