idnits 2.17.1 draft-ietf-ips-iscsi-name-disc-01.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** Bad filename characters: the document name given in the document, 'draft-ietf-ips-iscsi-name-disc-01.txt.', contains other characters than digits, lowercase letters and dash. ** Missing revision: the document name given in the document, 'draft-ietf-ips-iscsi-name-disc-01.txt.', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-ips-iscsi-name-disc-01.txt.', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-ips-iscsi-name-disc-01.txt.', but the file name used is 'draft-ietf-ips-iscsi-name-disc-01' ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 2365 lines 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.) ** The document seems to lack an Authors' Addresses Section. ** The abstract seems to contain references ([7]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 38 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 75 has weird spacing: '...h small isola...' == Line 146 has weird spacing: '...itiator needs...' == Line 205 has weird spacing: '...le from the I...' == Line 226 has weird spacing: '... target iSCSI...' == Line 287 has weird spacing: '... object must ...' == (4 more instances...) == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- Couldn't find a document date in the document -- date freshness check skipped. 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 section? '7' on line 2164 looks like a reference -- Missing reference section? '6' on line 2160 looks like a reference -- Missing reference section? 'RFC1737' on line 446 looks like a reference -- Missing reference section? '22' on line 581 looks like a reference -- Missing reference section? 'RFC 2396' on line 763 looks like a reference -- Missing reference section? 'RFC2608' on line 1178 looks like a reference -- Missing reference section? '21' on line 2194 looks like a reference -- Missing reference section? '8' on line 2168 looks like a reference -- Missing reference section? '1' on line 2146 looks like a reference -- Missing reference section? '2' on line 2149 looks like a reference -- Missing reference section? '3' on line 2153 looks like a reference -- Missing reference section? '4' on line 2155 looks like a reference -- Missing reference section? '5' on line 2157 looks like a reference -- Missing reference section? '9' on line 2171 looks like a reference -- Missing reference section? '10' on line 2173 looks like a reference -- Missing reference section? '12' on line 2180 looks like a reference -- Missing reference section? '13' on line 2181 looks like a reference -- Missing reference section? '14' on line 2183 looks like a reference -- Missing reference section? '15' on line 2185 looks like a reference -- Missing reference section? '16' on line 2187 looks like a reference -- Missing reference section? '17' on line 2189 looks like a reference -- Missing reference section? '18' on line 2190 looks like a reference -- Missing reference section? '19' on line 2192 looks like a reference Summary: 13 errors (**), 1 flaw (~~), 12 warnings (==), 24 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPS 3 Internet Draft 4 Draft-ietf-ips-iscsi-name-disc-01.txt 5 Draft Title: iSCSI Naming and Discovery 7 Mark Bakke 8 Cisco 10 Joe Czap 11 IBM 13 Jim Hafner 14 IBM 16 Howard Hall 17 Pirus 19 Jack Harwood 20 EMC 22 John Hufferd 23 IBM 25 Yaron Klein 26 Sanrad 28 Lawrence Lamers 29 San Valley Systems 31 Todd Sperry 32 Adaptec 34 Joshua Tseng 35 Nishan 37 Kaladhar Voruganti 38 IBM 40 draft-ietf-ips-iscsi-name-disc-01.txt. April, 2001 41 Expires October 2001 43 iSCSI Naming and Discovery 45 Status of this Memo 47 This document is an Internet-Draft and is in full conformance with 48 all provisions of Section 10 of RFC2026 except that the right to 49 produce derivative works is not granted. Internet-Drafts are working 50 documents of the Internet Engineering.Task Force (IETF), its areas, 52 and its working groups. Note that other groups may also distribute 53 working documents as Internet-Drafts. Internet-Drafts are draft 54 documents valid for a maximum of six months and may be updated, 55 replaced, or obsoleted by other documents at any time. It is 56 inappropriate to use Internet- Drafts as reference material or to 57 cite them other than as "work in progress." The list of current 58 Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id- 59 abstracts.txt 61 iSCSI Naming and Discovery April 2000 63 The list of Internet-Draft Shadow Directories can be accessed at 64 http://www.ietf.org/shadow.html. 66 Comments 67 Comments should be sent to the ips mailing list (ips@ece.cmu.edu) or 68 to kaladhar@us.ibm.com 70 1. Abstract 72 This document describes iSCSI [7] naming and discovery details. This 73 document complements the iSCSI IETF draft. Flexibility is the key 74 guiding principle behind this requirements document. That is, an 75 effort has been made to satisfy the needs of both small isolated 76 environments, as well as large environments requiring secure/scalable 77 solutions. 79 This document has been organized into the following sections: 80 a) Section 3 presents the naming requirements. It discusses the 81 concept of an iSCSI Name. 82 b) Section 4 discusses the discovery requirements. 83 c) Section 5 presents Storage Name Server (SNS) requirements. 84 d) Section 6 presents the details of iSNS protocol. iSNS 85 meets the requirements of SNS. The protocols identified in section 6, 86 which are used by iSNS, MUST also be supported by any iSCSI compliant 87 SNS protocol. 88 e) Section 7 briefly lists the other existing discovery protocols. 89 f) Section 8 briefly discusses the security implications on the 90 discovery mechanism. 91 g) Appendix A describes the different hardware and software 92 components with whom the initiator and target iSCSI Names can be 93 associated. 94 h) Appendix B contains examples on how the iSCSI Names are to be 95 used in iSCSI Login commands. 96 i) Appendix C contains a taxonomy of iSCSI proxy and firewall 97 concepts. This taxonomy helps to evaluate the behavior of the 98 discovery mechanism when dealing with proxies and firewalls. 100 2. Conventions used in this document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 104 this document are to be interpreted as described in RFC-2119. 106 3. Naming Requirements 107 The iSCSI protocol exists to allow iSCSI initiators to connect to 108 iSCSI targets. It is essentially a client-server model, with the 109 initiators represented by the clients, and the targets represented 110 by servers. 112 +-----------------------------------+ 113 | Network Entity (iSCSI Client) | 114 | | 115 | +-------------+ | 116 | | iSCSI Node | | 117 | | (Initiator) | | 118 | +-------------+ | 119 | | 120 | +--------------+ +--------------+ | 121 | |Network Portal| |Network Portal| | 122 | | 10.1.30.4 | | 10.1.40.6 | | 123 | | TCP Port 1 | | TCP Port 2 | | 124 +-+--------------+-+--------------+-+ 125 | | 126 | IP Networks | 127 | | 128 +-+--------------+-+--------------+-+ 129 | |Network Portal| |Network Portal| | 130 | | 10.1.30.21 | | 10.1.40.3 | | 131 | | TCP Port 4 | | TCP Port 4 | | 132 | +--------------+ +--------------+ | 133 | | 134 | +-------------+ +--------------+ | 135 | | iSCSI Node | | iSCSI Node | | 136 | | (Target) | | (Target) | | 137 | +-------------+ +--------------+ | 138 | | 139 | Network Entity (iSCSI Server) | 140 +-----------------------------------+ 142 A Network Entity object can contain multiple iSCSI Node and Network 143 Portal objects. An iSCSI initiator is represented by an iSCSI node 144 object and an iSCSI target is also represented by an iSCSI node 145 object. In order for an iSCSI initiator to connect to an iSCSI 146 target, the initiator needs to provide information about the target 147 iSCSI node object and the target network portal object. The details 148 of these iSCSI objects and the relationship of these iSCSI objects 149 with the SAM-2 concepts is provided below: 151 --------------------------------------------------------------------- 152 | Network Entity (IP Address) | 153 | -----------------------------------------------------------| | 154 | | iSCSI Node (iSCSI Name) | | 155 | | ------------------------------------------------------- | | 156 | | | SCSI Device | | | 157 | | | (SCSI Device Name = iSCSI Name) | | | 158 | | | | | | 159 | | | --------------------------- --------------------- | | | 160 | | | |Software iSCSI System | |Hardware iSCSI NIC | | | | 161 | | | | | | | | | | 162 | | | | SCSI Port | | SCSI Port | | | | 163 | | | | (iSCSI Name + ISID) | |(iSCSI Name + ISID)| | | | 164 | | | --------------------------| | | | | | 165 | | | | | | | | | | 166 | | -----|--------------|--------- | Network Portal | | | | 167 | |-------|--------------|------- | --------------------| | | | 168 | | | | | | | | | 169 | | | | | | | | | 170 | ------------- ------------ | | | | | | 171 | | | | | | | | | | | 172 | | Network | | Network | | | | | | | 173 | | Portal | | Portal | | | | | | | 174 | ------------- ----------- | ------------|-----------| | | 175 | | | |-------------|-------------| | 176 |-------------|-------------|----------------------|----------------- 177 | | | 178 ----------------------------IP Network--------------------- 179 | 180 -----------------------|--------------------------------------------| 181 | | Network Portal | | 182 | | (IP Address + TCP Port Number) | | 183 | |---------------------------------| | 184 | | | | 185 | | | | 186 | |----------------------------------- |------------------------|| 187 | ||-------------------------------- | ||----------------------||| 188 | || ---------------------- | | || ||| 189 | || | SCSI Port | | | || | SCSI Port |||| 190 | || |(iSCSI Name + TSID) | | | || |(iSCSI Name + TSID)|||| 191 | || |--------------------| | | || -------------------- ||| 192 | || | | || ||| 193 | || SCSI Device | | || SCSI Device ||| 194 | || | | || (iSCSI Name) ||| 195 | || (iSCSI Name) | | ||----------------------||| 196 | ||-------------------------------- | | || 197 | | iSCSI Node | | iSCSI Node || 198 | | (iSCSI Name) | | (iSCSI Name) || 199 | |----------------------------------| |-------------------------| 200 | Network Entity (IP Address) | 201 |-------------------------------------------------------------------| 203 a) Network Entity Object 204 The Network Entity object represents a device or gateway that is 205 accessible from the IP network. This device or gateway may support 206 one or more iSCSI node objects. The iSCSI node object is accessed via 207 a network portal object. 209 b) iSCSI Node Object 210 The iSCSI Node object defines an individual iSCSI initiator or 211 target. In addition to iSCSI functionality, the iSCSI Node provides 212 SCSI device functionality. There may be one or more iSCSI Storage 213 Node objects within the Network Entity object. An iSCSI Node object 214 is identified by its iSCSI name. There is a requirement for iSCSI 215 names to be unique. However, it is not mandatory for the initiators 216 and targets to use the iSCSI names because a unique identifier might 217 not be required in some simple, isolated iSCSI configurations. iSCSI 218 names are useful because in some cases (e.g. when DHCP services [6] 219 are used etc), the combination of IP address and port number [6] 220 cannot uniquely identify an initiator or a target. 222 There is a default iSCSI Node object present at every target network 223 entity that can be accessed without specifying the iSCSI name. 224 However, if there are multiple iSCSI target Nodes that are serviced 225 by a single Network Entity and Network Portal objects, then it is 226 necessary for the initiator to specify the target iSCSI name to 227 uniquely identify the target iSCSI node. An alias string could also 228 be associated with an iSCSI target node. The target alias helps an 229 organization to associate their own semantic meaning with the target 230 alias string. However, the target alias string is not a substitute 231 for the target iSCSI name. 233 c) SCSI Device Object 234 This is the SAM-2 term for an entity that contains other SCSI 235 entities. For example, a SCSI Initiator Device contains one or more 236 SCSI Initiator Ports and zero or more application clients; a SCSI 237 Target Device contains one or more SCSI Target Ports and one or more 238 logical units. For iSCSI, an iSCSI Node provides the functionality 239 of a single SCSI Device. The SCSI Device Name is the same as the 240 iSCSI Node name 242 d) SCSI Port Object 243 This is the SAM-2 term for an entity in a SCSI device that provides 244 the SCSI functionality to interface with a service delivery subsystem 245 or transport. For iSCSI, the SCSI Port Object maps to the endpoint 246 of a session. An iSCSI session is negotiated through the login 247 process between an iSCSI Intiator Node and an iSCSI Target Node. At 248 successful completion of this process, a SCSI Initiator Port is 249 created within the iSCSI Initiator Node and similarly, a SCSI Target 250 Port is created within the iSCSI Target Node. The session is the 251 SCSI I_T nexus. The SCSI Initiator Port Name and SCSI Initiator Port 252 Identifier are the iSCSI Initiator Node name together with the ISID 253 of the session identifier. Similarly, the SCSI Target Port name and 254 SCSI Target Port Identifier are the iSCSI Target Node name together 255 with the TSID of the session identifer. There can be only one iSCSI 256 session with a given ISID between an iSCSI Intiator Node and an iSCSI 257 Target Node. There can be multiple SCSI Port objects present in an 258 iSCSI Storage Node object (one for each session created). In software 259 iSCSI representations, the iSCSI Storage Node object creates a 260 session process which, in turn, represents the SCSI Port. By making 261 the SCSI Port be a separate object from the iSCSI Node object, it 262 allows one to use different combinations of software and hardware 263 iSCSI implementations within the same iSCSI node umbrella. Moreover, 264 this also allows the iSCSI Node name at the initiators to be 266 associated with the operating system footprint and not with any 267 network card hardware (such as the iSCSI offload network card). In 268 hardware iSCSI offload card implementations, the session process is 269 present in the iSCSI network card. The iSCSI Node object passes the 270 unique iSCSI Node name and the ISID or the TSID to the session 271 process. A target uses the initiator iSCSI Node name and the ISID 272 combination to implement part of the persisent feature of SCSI 273 reservations. Therefore, if the initiator wants to maintain the state 274 from its previous session, the iSCSI node at the initiator needs to 275 ensure that the same ISID is assigned (after an iSCSI session logout 276 and during an iSCSI session re-login attempt) when connecting to the 277 same target iSCSI Node object, and the target iSCSI node needs to 278 ensure that during the Login phase, it assigns the same TSID to 279 the login attempt with the particular ISID (if the state from the 280 previous session between the SCSI ports is present at the target). 281 Thus, the target iSCSI Node needs to maintain the state of the 282 pending initiator SCSI reservations. 284 e) Network Portal Object 285 The Network Portal object is a port through which access to any iSCSI 286 Node object within the Network Entity object can be obtained. A 287 Network Entity object must have one or more Network Portal objects, 288 each of which is usable by iSCSI Node objects contained in that 289 Network Entity object to gain access to the IP network. The Network 290 Portal object is identified by its IP address and Port number. A SCSI 291 Port object (an iSCSI session) can use multiple Network Portal 292 objects and a Network Portal object can be used by multiple SCSI port 293 objects. A hardware iSCSI offload card contains at least a SCSI Port 294 object and a Network Portal object. Moreover, the Network Portal 295 contained within a hardware iSCSI NIC can only be used by the SCSI 296 Port(s) contained within the hardware NIC. 298 3. Naming Requirements 300 The concepts of names and addresses have been carefully separated 301 In iSCSI. A name is an identifier that specifies an end-point, such 302 as an initiator or target. The name must be location-independent; 303 the target can be moved to another address, or have multiple 304 addresses, but it is still the same target. An address is an 305 identifier that specifies a path to an end-point at which the target 306 may currently be found. Names are forever; addresses may change at 307 any time. 309 This means that two types of identifiers are needed for iSCSI 310 initiators and targets: 312 - An iSCSI Node Name, or iSCSI Name, is a location-independent, 313 permanent identifier for an iSCSI initiator or target. It stays 314 constant for the life of the target. An iSCSI Name specifies an 315 iSCSI Node. 317 - An iSCSI Address specifies the location of an iSCSI initiator 318 or target. An iSCSI address consists of a host name or IP 319 address, a TCP port number, and the iSCSI Name of the host 320 or target. An iSCSI Address specifies an iSCSI Portal plus 322 an iSCSI Node. 324 - An iSCSI Identifier is either an iSCSI Name or an iSCSI Address. 325 Some specifications of iSCSI targets, such as a configuration 326 File or the iSCSI Boot mechanism [ref], require either a name or 327 an address to be stored in the same field. In this case, the term 328 "iSCSI Identifier" is specified to indicate that either the name 329 or the address can be used. 331 This set of structures has already been defined by the WWW and 332 internet folks. An iSCSI Identifier is functionally equivalent 333 to a Uniform Resource Identifier (URI), an iSCSI Name is 334 functionally equivalent to a Uniform Resource Name (URN), and an 335 iSCSI Address fulfils the same function as a 336 Uniform Resource Locator (URL). 338 In addition to the iSCSI Name, an iSCSI Node may have an iSCSI 339 Alias. This alias is not a unique identifier, but is an 340 administratively-assigned, human-readable text string that assists 341 a user in identifying a target or initiator. 343 A similar analogy exists for people. A person might be: 345 Robert Smith 346 SSN: 333-44-5555 347 Phone: +1 (763) 555.1212 348 Home Address: 555 Big Road, Minneapolis, MN 55444 349 Work Address: 222 Freeway Blvd, St. Paul, MN 55333 351 In this case, Robert's globally unique name is really his Social 352 Security Number (perhaps it should have a "us." in front of it); 353 his common name, "Robert Smith", is not guaranteed to be unique. 354 Robert has three locations at which he may be reached; two 355 Physical addresses, and a phone number. In this example, Robert's 356 SSN is like the iSCSI Name, his phone number, and addresses are 357 analogous to the iSCSI Address, and "Robert Smith" would be the iSCSI 358 Alias. 360 A default target is present on each Network Entity that contains 361 targets. This default target has the iSCSI Name "iscsi", which 362 is not globally unique. An iSCSI initiator, given only the IP 363 address and TCP port of an iSCSI portal, can connect to this 364 default target to request a list of targets within the network 365 entity. 367 The default target need not be present within a network entity 368 that contains only initiators. 370 3.1 iSCSI Names 372 An iSCSI Node Name, or iSCSI name, is used to identify each iSCSI 373 initiator and target. The terms "initiator name" and "target name", 374 when used in this document, refer to iSCSI Node Names. This name is 375 designed to be globally unique, and is independent of the location of 376 the initiator or target. iSCSI names are formatted as UTF-8 text 378 strings. 380 iSCSI names may be assigned by a hardware manufacturer, software 381 manufacturer, or the end user. A naming authority scheme is provided 382 to ensure that each of these can confidently generate unique names. 384 The iSCSI Name uniquely identifies iSCSI initiators and targets. The 385 Initiator Name corresponds to the logical operating system on which 386 the initiator is running, and the Target Name corresponds to the 387 target Storage Node entity. 389 iSCSI names are designed to fulfill the following requirements: 391 1. iSCSI names are globally unique. No two initiators or targets 392 should have the same name. 394 2. iSCSI names are permanent. An iSCSI initiator or target has 395 the same name for its lifetime. 397 3. iSCSI names do not imply a location or address. An iSCSI 398 initiator or target can move, or have multiple addresses. A 399 change of address does not cause a change of name. 401 4. iSCSI names must not rely on a central name broker; the 402 naming authority must be distributed. 404 5. iSCSI names must support integration with existing unique 405 naming schemes. 407 6. iSCSI names must rely on existing naming authorities. iSCSI 408 must not create its own naming authority. 410 The encoding of an iSCSI name also has some requirements: 412 1. iSCSI names have one single encoding method when transmitted 413 over various protocols. 415 2. iSCSI names must be relatively simple to compare. The algorithm 416 for comparing two iSCSI names for equivalence must not rely 417 on any external server. 419 3. iSCSI names must be transcribable by humans. iSCSI names should 420 be kept as simple as possible, and should not use more than a 421 few special characters. They must also be case-insensitive, and 422 cannot include white space. 424 4. iSCSI names must be transport-friendly. They must be transported 425 using both binary and ASCII-based protocols, as well as on paper. 427 An iSCSI Name really names a logical software entity, and is not 428 tied to a port or other hardware that can be changed. For instance, 429 an Initiator Name should name the iSCSI initiator driver, and not 430 a particular NIC or HBA card. When multiple NICs are used, they 431 should generally all present the same iSCSI Initiator Name to the 432 targets, since they are really to the same entity. In most operating 433 systems, the named entity is the operating system image. Most hosts 434 will have a single OS running; some of the really big ones could have 436 multiples. 438 A Target Name should similarly not be tied to hardware interfaces 439 that can be changed. A Target Name should identify the logical 440 target,and must be the same for the target regardless of the physical 441 porton which it is addressed. This gives iSCSI initiators an easy 442 way to determine that two targets it has discovered are really two 443 paths to the same target. 445 The iSCSI Name is designed to fulfill the functional requirements 446 for Uniform Resource Names (URN) [RFC1737]. Among these requirements 447 are that the name must have a global scope, independent of address 448 or location, and that it be persistent and globally unique. It must 449 be extensible, and scale with the use of naming authorities. The 450 encoding of the name should be transcribable by a human, as well as 451 be machine-readable. There are other requirements as well; please 452 read RFC1737 (only 5 pages) for definitions of these requirements. 454 The iSCSI Name may be displayed by user interfaces, but is generally 455 uninterpreted and used as an opaque, case-insensitive string for 456 comparison with other iSCSI Name values. 458 An iSCSI name is text-based. This was done for the following 459 reasons: 461 - A text-based identifier is transcribable, and is easier to 462 differentiate when looking at a user interface, or while 463 debugging problems with iSCSI login and discovery. 465 - iSCSI names are only used during login and discovery phases, so 466 the overhead does not get in the way of the data path. 468 - The iSCSI protocol communicates these via text strings anyway, 469 so it "fits in" easily. 471 An iSCSI name consists of three parts: a type designator, followed by 472 A naming authority, with the remaining format designated by the 473 naming authority itself, subject to the following requirements. 475 An iSCSI name can be any Unicode character string with the following 476 properties: 478 - it is in Normalization Form C (see Unicode Standard Annex #15, 479 "Unicode Normalization Forms" at 480 http://www.unicode.org/unicode/reports/15) 482 - it contains only the ASCII dash character ('-'=U+002d) or the 483 ASCII dot character ('.'=U+002e) or is in one of the following 484 Unicode General Categories: 486 a) Lu (Letter, Uppercase) 487 b) Ll (Letter, Lowercase) 488 c) Lt (Letter, Titlecase) 489 d) Lm (Letter, Modifier) 490 e) Lo (Letter, Other) 491 f) Nd (Number, Decimal Digit) 492 g) Nl (Number, Letter) 494 h) No (Number, Other) 496 - when encoded in UTF-8, it is no more than 255 bytes 498 In particular, white space, punctuation (except as noted), marks and 499 symbols are not allowed. 501 When included in Text or Login messages, an iSCSI Name SHALL be 502 formatted in UTF-8 form. 504 For the purposes of comparison, computing hash values, or anything 505 else that operates on an iSCSI Name, the name must first be converted 506 to lower-case in a locale-independent manner (case-folding) per the 507 rules described in Unicode Technical Report #21, "Case Mappings", 508 section 2.3 "Caseless Matching" (see 509 "http://www.unicode.org/unicode/reports/tr21"). 511 The iSCSI Name does not define any new naming authorities. Instead, 512 it supports two existing authorities: a Fully-Qualified Name, 513 using domain names as an authority, similar to the Java class 514 naming heirarchy, and the EUI format used in Fibre Channel world- 515 wide names. 517 Since there are different types of naming authorities, there are 518 different types of iSCSI Names to make use of them. Each name is 519 prefixed with a short type designator string that indicates the 520 type of naming authority being used. 522 Here are the type designator strings that may currently be used: 524 iscsi - Not unique; indicates a "canonical" target or 525 initiator. 526 fqn. - Fully-Qualified Name 527 eui. - Remainder of the string is an EUI-64 address, 528 in ASCII hexadecimal. 530 As these two naming authorities will suffice in nearly every 531 case imaginable for both software and hardware-based entities, 532 the creation of additional type designators is discouraged. 533 Use of type strings not listed here is not allowed, as they cannot be 534 guaranteed to be unique. 536 The use of the naming authority means that iSCSI names can be 537 assigned by virtually any uniqueness scheme that can be devised by OS 538 vendors, driver or iSCSI NIC vendors, device vendors, gateway 539 vendors, and even the customer. 541 Type "iscsi" 543 This type does not specify a real iSCSI Name; it is used during 544 Login as a default or canonical name. 546 Example Name: 548 iscsi 550 This type does not use a naming authority, and so is not a real 551 iSCSI Name. Every device allowing target connections will support 552 this as a default target, so it is not globally unique. Every device 553 supporting the "iscsi" Name should also support one or more actual 554 iSCSI Names of one of the other two types. 556 Type "fqn." (Fully-Qualified Name) 558 This iSCSI name type can be used by either a manufacturer, end 559 user,or service provider. This naming authority is handy especially 560 when an end user or service provider wishes to provide the iSCSI 561 Name for a target. These customers all own domain names; the same is 562 not true for OUI, SCSI Vendor ID, or any of the other assigned 563 identifiers that could be used as a naming authority. 565 To generate names of this type, the person or organization 566 generating the name must own a DNS domain name. This name does 567 not have to be active, and does not have to resolve to an 568 address; it just needs to be reserved to prevent others from 569 generating iSCSI names using the same domain name. For example, 570 "ACME Storage Arrays, Inc.", might own the domain "acme.com". 572 The fully qualified name string consists of: 574 - The string "fqn.", used to distinguish these names from other 575 types, such as "eui". 577 - A reversed domain name, owned by the person or organization 578 creating the iSCSI name. For example, our storage vendor 579 example would reverse its name to "com.acme". This is similar 580 to the process used to generate unique Java class names 581 [22], but without the restrictions on the domain name, 582 since iSCSI names allow hyphens, and does not have any reserved 583 words. 585 - Another ".". 587 - Any string, within the character set and length boundaries, that 588 the owner of "acme.com" deems appropriate. This may contain 589 product types, serial numbers, host identifiers, software 590 keys, or anything else that makes sense to uniquely identify 591 the initiator or target. 593 After the "fqn.", the string starts with a backwards domain 594 name specifying the Naming Authority, using dots as separators, 595 just as in a regular domain name. It's backwards, since it is 596 not really used as a fully qualified host name; only the necessary 597 top levels need by used. 599 Basically, everything after the backwards domain name, followed 600 by another dot ".", can be assigned as needed by the owner of 601 the domain name. 603 Here is an example of a fully-qualified iSCSI Name string from an 604 equipment vendor: 606 Naming Defined by 607 Type Auth Naming Authority 608 +-+ +------+ +--------------------+ 609 | | | | | | 611 fqn.com.acme.diskarrays-sn-a8675309 613 Where: 615 "fqn" specifies the use of the fully-qualified name as the 616 authority. 618 "com.acme" defines the naming authority. The owner of the DNS 619 name "acme.com" has the sole right of use of this name within 620 an iSCSI name, as well as the responsibility to keep the 621 remainder of the iSCSI name unique. In this case, acme.com happens 622 to manufacture disk arrays. 624 "diskarrays" was picked arbitrarily by acme.com to use to 625 identify the disk arrays they manufacture. Another product 626 that ACME makes might use a different name, and have their 627 own namespace independent of the disk array group. Again, this 628 is not specified here; it's just an example of what ACME could 629 do. 631 "sn" was picked by the disk array group of ACME to show that 632 what follows is a serial number. They could have just assumed 633 that all iSCSI Names are based on serial numbers, but they 634 thought that perhaps later products might be better identified by 635 something else. Adding "sn" was a future-proof measure. 637 "a8675309" is the serial number of the disk array, uniquely 638 identifying it from all other arrays. 640 A research example: 642 Naming Defined by 643 Type Auth Naming Authority 644 +-+ +----------------------+ +-----------+ 645 | | | | | | 646 fqn.edu.pika-u.cs.users.oaks.proto.target4 648 In the above example, Professor Oaks of Pika University is 649 building research prototypes of iSCSI targets. Pika-U's 650 computer science department allows each user to use his 651 or her user name as a naming authority for this type of 652 work. Professor Oaks chose to use "proto.target4" for a 653 particular target. 655 Here is an example of a fully-qualified iSCSI Name string from a 656 service provider: 658 Naming Defined by 659 Type Auth Naming Authority 660 +-+ +--------+ +----------------------+ 662 | | | | | | 664 fqn.com.my-ssp.customers.4567.disks.107 666 In this case, a storage service provider (my-ssp.com) has decided 667 to re-name the targets from the manufacturer, to provide the 668 flexibility to move the customer's data to a different storage 669 subsystem should the need arise. 671 My-ssp has configured the iSCSI Name on this particular target 672 for one of its customers, and has determined that it made the 673 most sense to track these targets by their Customer ID number and 674 a disk number. This target was created for use by customer #4567, 675 and is the 107th target configured for this customer. 677 Note that when reversing these domain names, that the first 678 component(after the "fqn.") will always be a top-level domain name, 679 which includes "com", "edu", "gov", "org", "net", "mil", or one of 680 the two-letter country codes. The use of anything else as the first 681 component of these names is not allowed. In particular, companies 682 generating these names must not eliminate their "com." from the 683 string. 685 Again, these iSCSI names are NOT addresses. Even though they make 686 use of DNS domain names, they are used only to specify the naming 687 authority. An iSCSI name contains no implications of the iSCSI 688 target or initiator's location. The use of the domain name is 689 only a method of re-using an already ubiquitous name space. 691 Note that we could have allowed the SCSI Vendor ID or IEEE OUI as a 692 naming authority. However, some large customers and service 693 providers may wish to use their own identification scheme, rather 694 than that provided by the manufacturer. These customers would not 695 likely have a registered Vendor ID, but the domain name we 696 used is ubiquitous, and was deemed more appropriate. 698 Further examples of fully-qualified iSCSI names are given at the 699 end of this document. 701 Type "eui." (IEEE EUI format) 703 The IEEE iSCSI name might be used when a manufacturer is already 704 basing unique identifiers on World-Wide Names as defined in 705 the SCSI SPC-2 specification. 707 It may also be used by a gateway representing a Fibre Channel 708 or SCSI device that is already adequately identified using a 709 world-wide name. 711 The format is "eui." followed by 16 hex digits. 713 Example iSCSI name: 715 Type EUI-64 WWN 716 +-+ +--------------+ 717 | | | | 719 eui.02004567A425678D 721 Initiator and Target Requirements for iSCSI Name support: 723 Each initiator and target implementation must support the use 724 of iSCSI names. 726 The initiator MUST send an InitiatorName and a TargetName as text 727 fields within the login request. If the initiator does not have or 728 support an iSCSI name, it must send an InitiatorName of "iscsi". If 729 the initiator is logging in to the canonical (default) target, it 730 must specify a TargetName of "iscsi". Note that if an InitiatorName 731 of "iscsi" is used, the initiator stands the risk that it will be 732 excluded from accessing some or all of its targets. 734 An initiator MAY send an InitiatorAlias as a text field within its 735 login request. The target may use this as an informational field 736 only; it must not be used for unique identification or 737 authentication purposes. 739 The target MUST send a TargetName as a text field within its login 740 response. Unless the initiator specified the TargetName "iscsi" 741 in the request, this TargetName MUST match that specified by the 742 initiator. If the initiator had specified a TargetName of "iscsi", 743 this TargetName should be the actual iSCSI Name of the target, or 744 can be returned as "iscsi" if either the target is just a canonical 745 target used for the SendTargets command, or if the target does 746 not have an iSCSI Name. 748 The target MAY send a TargetAlias as a text field within its login 749 response. The initiator may use this as an informational field 750 only; it must not be used for unique identification or 751 authentication purposes. 753 Initiators and targets shall support the receipt of iSCSI names of 754 up to the maximum length. If configuration of the initiator or 755 target name is allowed, the implementation shall support the maximum 756 length. 758 In their user interfaces, both shall support, at a minimum, the 759 display of the ASCII characters within the iSCSI Name's UTF-8 760 string. 762 If the other characters are unsupported, they may be displayed with 763 escape codes as specified in [RFC 2396]. 765 3.4 iSCSI Alias 767 The iSCSI alias is a UTF-8 text string that may be used as an 768 additional descriptive name for an initiator and target. This 769 may not be used to identify a target or initiator during login, 770 and does not have to follow the uniqueness or other requirments 771 of the iSCSI name. The alias strings are communicated between the 773 initiator and target at login, and can be displayed by a user 774 interface on either end, helping the user tell at a glance whether 775 the initiators and/or targets at the other end appear to be 776 correct. The alias must NOT be used to identify, address, or 777 authenticate initiators and targets. 779 The alias is a variable length string, between 0 and 255 characters, 780 and is terminated with at least one NULL (0x00) character. No 781 other structure is imposed upon this string. 783 3.2.1 Purpose of an Alias 785 Initiators and targets are uniquely identified by an iSCSI Name. 786 These identifiers may be assigned by 787 a hardware or software manufacturer, a service provider, or even 788 the customer. Although these identifiers are nominally human- 789 readable, they are likely be be assigned from a point of view 790 different from that of the other side of the connection. For 791 instance, a target name for a disk array may be built from the 792 array's serial number, and some sort of internal target ID. 793 Although this would still be human-readable and transcribable, 794 it offers little assurance to someone at a user interface who 795 would like to see "at-a-glance" whether this target is really 796 the correct one. 798 The use of an alias helps solve that problem. An alias is 799 simply a descriptive name that can be assigned to an initiator 800 or target, that is independent of the name, and does not have 801 to be unique. Since it is not unique, the alias must be used 802 in a purely informational way. It may not be used to specify 803 a target at login, or used during authentication. It is not used 804 in place of the old iscsi "path" concept; the iSCSI Name is used 805 there instead. 807 Both targets and initiators may have aliases. 809 3.2.2 Target Alias 811 To show the utility of an alias, here is an example using an 812 alias for an iSCSI target. 814 Imagine sitting at a desktop station that is using some iSCSI 815 devices over a network. The user requires another iSCSI disk, 816 and calls the storage services person (internal or external), 817 giving any authentication information that the storage device 818 will require for the host. The services person allocates a 819 new target for the host, and sends the Target Name for the new 820 target, and probably an address, back to the user. The user then 821 adds this Target Name to the configuration file on the host, and 822 discovers the new device. 824 Without an alias, a user managing an iSCSI host would click 825 on some sort of "show targets" button to show the targets to 826 which the host is currently connected. 828 +--Connected-To-These-Targets---------------------- 829 | 831 | Target Name 832 | 833 | fqn.com.acme.sn.5551212.target.450 834 | fqn.com.acme.sn.5551212.target.489 835 | fqn.com.acme.sn.8675309 836 | 837 +-------------------------------------------------- 839 In the above example, the user sees a collection of iSCSI Names, but 840 with no real description of what they are for. They will, of 841 course, map to a system-dependent device file or drive letter, 842 but it's not easy looking at numbers quickly to see if everything 843 is there. 845 If a more intelligent target configures an alias for each target, 846 perhaps at the time the target was allocated to the host, a more 847 descriptive name can be given. This alias is sent back to the 848 initiator as part of the login or sendTargets responses, for use 849 in a display such as this. The new display might look like: 851 +--Connected-To-These-Targets---------------------- 852 | 853 | Alias Target Name 854 | 855 | Oracle 1 fqn.com.acme.sn.5551212.target.450 856 | Local Disk fqn.com.acme.sn.5551212.target.489 857 | Exchange 2 fqn.com.acme.sn.8675309 858 | 859 +-------------------------------------------------- 861 This would give the user a better idea of what's really there. 863 In general, flexible, configured aliases will probably be 864 supported by larger storage subsystems and configurable gateways. 865 Simpler devices will likely not keep configuration data 866 around for things such as an alias. The TargetAlias string 867 could be either left unsupported (not given to the initiator 868 during login) or could be returned as whatever the "next best 869 thing" that the target has that might better describe it. 870 Since it does not have to be unique, it could even return 871 SCSI inquiry string data. 873 Note that if a simple initiator does not wish to keep or display 874 alias information, it can be simply ignored in the login or 875 sendTargets responses. 877 3.2.3 Initiator Alias 879 An initiator alias can be used in the same manner as a target 880 alias. An initiator would send the alias in a login request, 881 when it sends its iSCSI Initiator Name. The alias is not used for 882 authentication, but may be kept with the session information for 883 display through a management GUI or command-line interface (for a 884 more complex subsystem or gateway), or through the iSCSI MIB. 886 Note that a simple target can just ignore the Initiator Alias 887 if it has no management interface on which to display it. 889 Usually just the hostname would be sufficient for an initiator 890 alias, but a custom alias could be configured for the sake of the 891 service provider if needed. Even better would be a description of 892 what the machine was used for, such as "Exchange Server 1", or 893 "User Web Server". 895 Here's an example showing a list of sessions on a target device. 896 For this display, the targets are using an internal target number, 897 which is a fictional field that has purely internal significance. 899 +--Connected-To-These-Initiators------------------- 900 | 901 | Target Initiator Name 902 | 903 | 450 fqn.com.sw.cd.12345678-OEM-456 904 | 451 fqn.com.os.hostid.A598B45C 905 | 309 fqn.com.sw.cd.87654321-OEM-259 906 | 907 +-------------------------------------------------- 909 And with the initiator alias displayed: 911 +--Connected-To-These-Initiators------------------- 912 | 913 | Target Alias Initiator Name 914 | 915 | 450 Web Server 4 fqn.com.sw.cd.12345678-OEM-456 916 | 451 scsigate.yours.com fqn.com.os.hostid.A598B45C 917 | 309 Exchange Server fqn.com.sw.cd.87654321-OEM-259 918 | 919 +-------------------------------------------------- 921 This gives the storage administrator a better idea of who is 922 connected to their targets. Of course, one could always do 923 a reverse DNS lookup of the incoming IP address to determine 924 a host name, but simpler devices really don't do well with that 925 particular feature due to blocking problems, and it won't 926 always work if there is a firewall or iSCSI gateway involved. 928 Again, these are purely informational and optional. 930 Aliases are extremely easy to implement. Targets just send 931 a TargetAlias whenever they send a TargetName. Initiators just 932 send an InitiatorAlias whenever they send an InitiatorName. 933 If an alias is received that does not fit, or seems invalid 934 in any way, it is ignored. 936 4. iSCSI Discovery 938 The goal of iSCSI discovery is to allow an initiator to find the 939 targets to which it has access, and at least 940 one address at which each target may be accessed. This should 941 generally be done using as little configuration as possible. This 942 section defines the discovery mechanism only; no attempt is made 943 to specify central management of iSCSI devices within this document. 945 There are several methods that may be used to find targets and their 946 addresses, ranging from configuring a list of targets and addresses 947 on each initiator and doing no discovery at all, to configuring 948 nothing on each initiator, and allowing the initiator to discover 949 targets via multicast mechanisms. 951 An iSCSI initiator can discover iSCSI targets in these ways: 953 a. iSCSI targets are configured on the initiator. 954 b. The initiator queries iSCSI servers using the SendTargets command. 955 c. The initiator queries a storage name server, such as iSNS, for 956 targets. 957 d. The initiator uses the Service Location Protocol (SLP) to find 958 iSCSI targets, iSCSI servers, and storage name servers. 960 4.1 Configuring Target Information 962 The exact manner in which the target information is hard-coded at the 963 initiator is an implementation detail. The information could be 964 present in some persistent location (such as a file) that can be 965 accessed by the initiator. 967 Target discovery can be configured on an initiator in several ways: 969 - Full Target URL. This includes the target's IP address or host 970 name, TCP port, and iSCSI Name. No further discovery is 971 required to contact this target. 973 - Target Name. This includes only the target's name, and contains 974 no address information. The initiator must query SLP or a name 975 server to locate this target. 977 - Canonical Target Name. This is just an iSCSI server's IP address 978 and TCP port, the canonical name "iscsi". The initiator must 979 connect to this address, log in to the canonical target, and 980 issue a SendTargets command to acquire the list of targets it can 981 use. 983 - Storage Name Server Address. This is an address of a storage 984 name server, such as iSNS, that the initiator may query to find 985 more targets. The information required to configure an initiator for 986 a storage name server is outside the scope of this document. 988 4.2 SendTargets Command 990 An initiator may connect to an iSCSI address (IP address + 991 TCP port)and log in to the canonical target name "iscsi". The login 992 process for this target is identical to that of any other target. If 994 there are no targets available that would provide access to the 995 initiator's Name, the target SHOULD reject the initiator's login to 996 the canonical target with the status code set to 0x202 "forbidden 997 target". Upon successful login to the "iscsi" target, the initiator 998 may send the text command "SendTargets", to retrieve a list of target 999 names to which it may attempt login. The canonical target MUST 1000 support this command, and MUST return a list of zero or more target 1001 Names. Each iSCSI Name returned may include zero or more 1002 TargetAddress fields, as well one optional TargetAlias field. If 1003 zero Names are returned, the canonical target is unaware of any 1004 targets that are accessible by the initiator. The command is sent by 1005 formatting an iSCSI Text Command, with the Final (F) bit set to 1. 1006 The first key in the command's text must be 1008 SendTargets= 1010 No value is sent for the send-targets key, and no other keys 1011 are sent. 1013 The response to this command is a text response containing a 1014 list of text keys. The text keys are organized as a set of 1015 records, one for each iSCSI target. Each record includes the 1016 target name, a list of zero or more target addresses, and the 1017 optional target alias. The order of the text keys is very 1018 important. The appearance of the TargetName key signals the 1019 start of a new record. Subsequent TargetAddress and TargetAlias 1020 keys apply only to that record, until the next TargetName 1021 key is found (or the command response is done). 1023 Each target starts with one text key of the form: 1025 TargetName= 1027 It may then include zero or more address keys: 1029 TargetAddress=[:] 1031 It may then include the optional target alias key: 1033 TargetAlias= 1035 This example is the SendTargets response from a single target, 1036 that has no other interface ports, and does not support an alias: 1038 TargetName=fqn.com.acme.diskarray.sn.8675309 1040 Note that all it really had to return in the simple case was the 1041 iSCSI name. It is assumed by the initiator that the IP address and 1042 TCP port for this iSCSI Name are the same as used on the 1043 current connection to the canonical iSCSI target. 1045 The next example has two internal iSCSI targets, each support via 1046 two different ports with different IP addresses: 1048 TargetName=fqn.com.acme.diskarray.sn.8675309 1049 TargetAddress=10.1.0.45:3000 1051 TargetAddress=10.1.1.45:3000 1052 TargetAlias=Oracle disk four 1053 TargetName=fqn.com.acme.diskarray.sn.1234567 1054 TargetAddress=10.1.0.45:3000 1055 TargetAddress=10.1.1.45:3000 1056 TargetAlias:Oracle disk five 1058 Note that both targets share both addresses; the multiple addresses are 1059 likely used to provide multi-path support. The initiator may connect to 1060 either targetName on either address. 1061 Also note that in the above example, a DNS host name could have been 1062 returned instead of an IP address, and that an IPv6 addresses 1063 (5 to 16 dotted-decimal numbers) could have been returned as well. 1065 After obtaining a list of targets in this manner, an iSCSI initiator may 1066 create new sessions to log in to the discovered targets. The 1067 initiator MAY keep the session to the canonical target open, and MAY 1068 send subsequent SendTargets commands to discover new targets. The 1069 target MUST send any iSCSI-level async event notifications on this 1070 session, to allow the initiator to discover new targets as they are 1071 created. [Note: The Asynch Message codes in the iSCSI document need to 1072 be updated to reflect support for this feature]. 1074 Note that since SendTargets is a text response, vendor-specific keys may 1075 be introduced in the response as specified in the iSCSI specification. 1076 A vendor-specific key appearing after a TargetName key should generally 1077 be treated as part of that target's record; however, this is, of course, 1078 defined by the manufacturer introducing the key. Initiators receiving 1079 unknown or unsupported vendor-specific keys in a SendTargets response 1080 MUST silently ignore them. 1082 4.2.1 Redirect Responses 1084 If a target has moved, or if the iSCSI device logged in to has knowledge 1085 of another address at which a target should be accessed, it MAY return a 1086 redirect response by setting the iSCSI login status to one of the 1087 "redirect"-class status codes, and returning at least one text key with 1088 a new target address on which to find the target. This status 1089 terminates the session. 1091 The initiator, upon receiving a redirect response, SHOULD either abandon 1092 attempts to log in to the intended target, or attempt to re-login to the 1093 target using one of the addresses provided. 1095 A target might do this for load balancing or it might do this to provide 1096 multiple virtual targets through a simple initiator discovery protocol. 1098 The target's response includes the Nameof the target, plus one 1099 or more TargetAddress fields, as specified in the SendTargets response. 1101 Here's a simple example: 1103 T->Login Response(status=redirect) 1104 TargetName=fqn.com.acme.diskarray.sn.999999 1105 TargetAddress=10.1.0.49:3000 1107 In the above example, a new address exists for the target name at 1108 10.1.0.49, TCP port 3000. If the TCP port was not specified, it would 1109 use the default port (to be assigned by IANA). 1111 Another example would include multiple addresses for a target, Perhaps 1112 through multiple ports on a storage controller, or through multiple 1113 gateways: 1115 T->Login Response(status=redirect) 1116 TargetName=fqn.com.acme.diskarray.sn.999999 1117 TargetAddress=10.2.30.100 1118 TargetAddress=10.2.40.100:2301 1119 TargetAddress=mystorage.mycompany.com 1121 Note that the address may be either an IP address or DNS host name. 1122 The first and third addresses to not include a TCP port; these would use 1123 the default, IANA-assigned TCP port. 1125 In any case, the TargetName returned is identical to that requested 1126 by the initiator in the initial Login Request. The redirect status 1127 is not used to change names; it is only used to move a iSCSI Name from 1128 one IP address and/or TCP port to another. 1130 4.3 Initiator queries a Storage Name Server (SNS) 1132 Discovery and management of iSCSI devices can be extended by the use 1133 of Storage Name Servers (SNS). The term "SNS" used in this document 1134 should not be confused with the specific implementation used in 1135 Fibre Channel; it is meant to be a generic term. 1137 An SNS can add capabilities beyond discovery of iSCSI targets, but 1138 for the purposes of this section it must at least provide a method of 1139 discovering: 1141 1. The addresses at which a particular iSCSI Name may be found 1142 2. A list of iSCSI Names and/or addresses to which the initiator 1143 has access. 1145 To make use of an SNS, an initiator must support a protocol that 1146 provides SNS query facilities. 1148 4.4 Initiator Uses the Service Location Protocol 1149 A storage name server address may be either configured, or discovered 1150 through SLP. 1152 An initiator may use the Service Location Protocol, Version 2 (SLPv2) 1153 to locate iSCSI targets, canonical targets, and storage name servers, 1154 without having to configure their addresses. SLP Version 1 is not 1155 supported by iSCSI. 1157 The Service Location Protocol (SLP) is a standard protocol for 1158 locating the addresses of resources on a network. iSCSI targets, 1160 canonical targets, and storage name servers may advertise themselves 1161 to iSCSI initiators using SLP. 1163 Three types of nodes participate in SLP discovery. A User Agent (UA) 1164 is the entity that wishes to discover resources. In this case, the 1165 UA is part of the iSCSI initiator. A Service Agent (SA) is the 1166 entity that wishes to be discovered. In our case, the SA is part of 1167 the iSCSI target, canonical target, or storage name server. A third 1168 entity, the Directory Agent (DA) is an optional part of discovery. 1169 If a DA is present, it collects information about the Service Agents, 1170 and is queried by the User Agents, to reduce the network load of all 1171 Uas trying to discovery all SAs. 1173 For true zero-configuration, SLP makes use of multicast to locate DAs 1174 or SAs. However, SLP is designed to use as little multicast traffic 1175 as possible, and by using a DA, and configuring its address on each 1176 initiator, will not require multicast at all. 1178 The SLP Protocol is described in detail in [RFC2608]. 1180 A target can register either its canonical target address, its 1181 targets themselves, or both with SLP. A storage name server can 1182 register its address with SLP, or can also register its targets 1183 with SLP, if desired. 1185 Initiators can send the following service requests using SLP: 1187 1. Locate all canonical targets ("iscsi") 1188 2. Locate specific targets to which the initiator might have access 1189 3. Locate a specific target by its iSCSI Name 1190 4. Locate storage name servers 1192 In addition, a storage name server can act as an initiator and make 1193 use of SLP to discover targets and canonical targets for its own use. 1195 If a specific target is found, the initiator may simply attempt to 1196 log in to that target. An initiator supporting a storage name 1197 service may additionally query the SNS for more information on the 1198 target before logging in. Note that the same target may exist at 1199 more than one address; it is the responsibility of the initiator to 1200 ensure that the targets' names are compared, and that either only 1201 one address is used, or that some form of multi-path software is 1202 in place. 1204 If a canonical target is found, the initiator may log in to the 1205 canonical target, and issue a SendTargets command as described in 1206 the previous section. 1208 If a storage name server is found, and the initiator supports the 1209 use of this type of storage name server, the initiator may query 1210 the SNS as described by its particular protocol specification. 1212 In general, if an initiator supports an SNS, it should normally 1213 not attempt to discover targets and canonical targets via SLP; it 1214 should first attempt to discover the SNS itself, and query the SNS 1215 for this information. 1217 The choice of static configuration, SNS discovery or target storage 1218 discovery protocols is a configuration choice of the initiator. 1220 In summary, this discovery approach is flexible in that the 1221 initiators have the freedom to select static configuration, a 1222 multicast based discovery mechanism for small, isolated iSCSI 1223 environments, or they can choose a scalable storage name server based 1224 discovery mechanism for large iSCSI environments. 1226 Additionally, targets and initiators may be configured to participate 1227 or not participate in an SLP Scope, which allows the SLP discovery 1228 environment to be contained within a smaller group. 1230 The Service Location Protocol uses templates, registered with IANA, 1231 to define the addresses and attributes that are communicated via 1232 SLP. The SLP templates implementation details are provided in [21] 1233 draft-bakke-iscsi-SLP-template.00, but a brief summary is as follows: 1235 Service:iscsi - A top-level abstract template, which is just a 1236 name under which to place our other templates. 1238 service:iscsi:target - A concrete target template, which defines 1239 the addresses and attributes for iSCSI targets and canonical targets. 1241 service:iscsi:name-service - A concrete target template, which 1242 defines the addresses and attributes for storage name services. 1244 5. Storage Name Server (SNS) 1246 The following section describes requirements for any Storage Name 1247 Server used to support iSCSI. An example of a Storage Name Server is 1248 the iSNS described in the draft document draft-ietf-ips-iSNS-00.txt 1249 [8]. There potentially could be other protocols which also satisfy 1250 SNS requirements. 1252 5.1 Overview 1254 A SNS shall be architected using a client-server paradigm, with a SNS 1255 server predominantly serving a passive role. SNS clients actively 1256 register and manipulate entity objects and their attributes in the 1257 SNS server. A SNS server MAY send asynchronous state change 1258 notifications to registered SNS clients in response to an action by a 1259 SNS client. Examples of SNS clients include initiators, targets, 1260 management stations, and switches. A SNS server can be hosted on a 1261 target, switch, or stand-alone server. 1263 5.2 Login Control and Discovery Domains 1264 Discovery Domains (DD's) are logical groupings of iSCSI devices that 1265 are allowed to "see" each other. SNS MUST support Discovery Domains 1266 and Login control. SNS must provide SNS clients with the ability to 1267 Enforce Discovery Domain configurations which may exist on a SNS 1268 server. Targets and management stations shall be able to register 1269 (i.e., upload) Login Control and Discovery Domain configurations to 1271 the SNS if authorized by the end user. Discovery Domains and Login 1272 control supports two separate purposes: 1274 5.2.1 Discovery Domain Partitions 1275 A SNS SHALL support the ability to partition the storage network into 1276 Separate "Discovery Domains". A SNS shall not provide information if 1277 the SNS client performing the query is not in a common Discovery 1278 Domain (DD) as the SNS client that is the subject of the request. 1279 This capability prevents an initiator from attempting an iSCSI login 1280 to every single target in a large enterprise network, and is the 1281 iSCSI equivalent of "Soft" zoning. 1283 5.2.2 Login Control 1284 Login access security which is specified in the iSCSI 1285 Draft (Appendix A) [7] and may be implemented by the iSCSI target. A 1286 SNS shall support login control by storing a mapping of initiators 1287 that are permitted to access each target. Targets shall be able to 1288 query the SNS for a list of initiators that are allowed login access. 1289 This list shall include the key attribute (e.g.,iSCSI Name) used to 1290 identify the initiator. This capability is the iSCSI equivalent of 1291 "Hard" zoning. 1293 5.3 Object Model 1295 A SNS MUST store the following objects and attributes: 1297 Network Entity: 1298 - Entity Identifier 1299 - Management IP Address 1300 - Entity Type (iSCSI) 1302 Network Portal: 1303 - IP Address 1304 - TCP Port Number 1306 iSCSI Node: 1307 - iSCSI Name 1308 - Alias 1309 - Node Type (target or initiator or both) 1311 Discovery Domain: 1312 - DD symbolic name 1313 - DD ID 1314 - DD Member: iSCSI Name 1315 - DD Member: IP Address 1317 A diagram of how the above objects are related is shown 1318 below. 1320 +----------------------------------------------------------------+ 1321 | IP Network | 1322 +------------+--------------------------------------+------------+ 1323 | | 1324 | | 1326 +-----+------+------+-----+ +-----+------+------+-----+ 1327 | |Network Portal | | |Network PORTAL | 1328 | | -IP Addr 1 | | | | -IP Addr 2 | | 1329 | | -TCP Port 1 | | | | -TCP Port 2 | | 1330 | +-----+ +-----+ | | +-----+ +-----+ | 1331 | | | | | | | | 1332 | | | | | | | | 1333 | +--------+ +--------+ | | +-------+ +--------+ | 1334 | | | | | | | | 1335 | | iSCSI Node | | | | iSCSI NODE | | 1336 | | -iSCSI Name | | | | -iSCSI Name | | 1337 | | -Alias: "server1"| | | | Alias: "disk1" | | 1338 | | -Type: initiator | | | | -Type: target | | 1339 | | | | | | | | 1340 | +-------------------+ | | +------------------+ | 1341 | | | | 1342 | NETWORK ENTITY | | NETWORK ENTITY | 1343 | -Entity ID (DNS): | | -Entity ID (DNS): | 1344 | "strg1.foo.com" | | "strg2.bar.com" | 1345 | -Type: iSCSI | | -Type: iSCSI | 1346 | | | | 1347 +-------------------------+ +-------------------------+ 1349 A DISCOVERY DOMAIN contains one or more NETWORK ENTITY, 1350 NETWORK PORTAL, 1351 and/or iSCSI NODE, objects. Each NETWORK ENTITY object contains 1352 one or more NETWORK PORTAL objects, and one or more STORAGE NODE 1353 objects. 1355 5.4 SNS Message Format Requirements 1356 The SNS protocol SHALL be TLV based. 1357 TLV (TLV is already used in many networking protocols such as DHCP). 1358 The SNS protocol shall allow manipulation of multiple objects and 1359 attributes in a SNS server through a single message and response. 1361 5.5 SNS Authentication Requirements 1362 The SNS protocol SHALL include optional authentication of SNS 1363 protocol messages from SNS clients. The authentication mechanism will 1364 allow for authentication of both client and server. 1366 5.6 SNS Query and Registration Services Requirements 1367 The SNS protocol allows initiators and targets to register themselves 1368 at The SNS server. Initiators and targets can also query a SNS server 1369 for information. For example, targets can register themselves at a 1370 SNS server, and the initiators can query a SNS server about which 1371 targets they can access. 1373 During registration, the initiators and the targets must 1374 provide the following information: 1375 a) Network Portal object address (IP address and Port 1376 Number) 1377 b) iSCSI Name information 1378 c) Storage node type 1380 They could optionally also provide other information such 1381 as: 1382 a) iSCSI Node name 1383 b) Alias string information 1384 c) Registration for State Change Notification 1386 If the iSCSI Node name is not provided in the initial 1387 registration, then a SNS shall create a unique Entity name for that 1388 client, and the client shall use that Entity name for all subsequent 1389 queries and updates. 1390 When querying address information in order to establish an 1391 iSCSI connection, the query, as a minimum, should return the 1392 following information: 1394 a) iSCSI Node IP address 1396 The Network Portal Object IP address can be the same as 1397 the iSCSI Node IP 1398 address, and the Network Portal port number can be the (TBD) default 1399 iSCSI port number. Furthermore, the iSCSI Name of the target device 1400 can be queried by issuing the SendTarget command to the default 1401 canonical iSCSI target present at the IP address and port number. 1403 5.7 State Change Notification Requirements 1405 Asynchronous notification (State Change Notifications): A SNS must 1406 be able to inform SNS clients of changes to its database, including 1407 changes or modifications to Discovery Domain or login control 1408 policies and the presence or absence of initiators and targets. 1409 These changes may occur as a result of various events, including an 1410 SNS client (e.g., a management workstation) actively changing the SNS 1411 database, response or non-response to an SNS status inquiry message, 1412 or a hardware interrupt delivered by a SNS host platform (such as a 1413 switch). Asynchronous notification shall be delivered only to SNS 1414 clients that register for the notification, and only for SNS clients 1415 that are in the same Discovery Domain as the event. 1417 5.8 The SNS protocol SHALL be a lightweight protocol that can be 1418 scaled down for implementation on switches and targets, or scaled up 1419 for implementation on servers. 1421 5.9 The SNS protocol SHALL meet the iSCSI boot requirements (see 1422 draft-ietf-ips-iscsi-boot-00.txt). 1424 6. iSNS - Internet Storage Name Service 1426 iSNS is a name service protocol which can be used for discovery and 1427 management of iSCSI devices. The iSNS protocol is described in the 1428 document draft-ietf-ips-iSNS-01.txt, and meets the requirements of 1429 section 5 of this document. The following section describe how iSNS 1430 is used to support iSCSI devices. 1432 6.1 iSCSI Requirements for iSNS 1434 iSNS MAY be used to fulfill iSCSI Naming and Discovery Requirements. 1435 Section 5.1 of the iSNS document lists specific implementation and 1436 usage requirements for iSCSI. Sections 5.2 and 5.3 are applicable to 1437 non-iSCSI protocols, and do NOT have to be implemented to support 1438 iSCSI. The remaining sections of the iSNS document provide important 1439 background and protocol format information which are generally 1440 applicable to an iSNS implementation that supports iSCSI. One 1441 exception is the RqstDmnID and RlsDmnID commands, which are used to 1442 support Fibre Channel and iFCP fabrics. 1444 6.2 Summary of iSNS Features & Capabilities 1446 The following are a summary of iSNS capabilities used to support 1447 iSCSI: 1449 6.2.1 iSNS Registration Service 1450 iSNS allows iSCSI devices to register their identity and attributes 1451 in the iSNS database. Multiple attributes can be registered in a 1452 single message. This allows management stations to directly manage 1453 large numbers of iSCSI devices by accessing the iSNS as a single, 1454 consolidated information repository. 1456 6.2.2 Discovery Domains (DD's) 1457 iSNS organizes iSCSI devices into logical groups. This accomplishes 1458 two primary purposes: 1) it limits the targets visible to each 1459 initiator to the more relevant and appropriate subset of devices in 1460 the entire storage network universe; 2) it eases administration by 1461 partitioning storage devices into smaller, more manageable groups. 1463 6.2.3 iSCSI Device Query Service 1464 iSNS responds to queries from iSCSI devices requesting information 1465 about other iSCSI devices residing in a common Discovery Domain. 1466 Multiple attributes can be queried for in a single message. 1468 6.2.4 State Change Notification (SCN's) 1469 A network event, such as removal of another device from a common 1470 Discovery Domain, will cause the iSNS to send an asynchronous 1471 notification message of the event to iSCSI devices that have 1472 registered for such a notification. 1474 6.2.5 Distribution and Retrieval of Public Key Certificates 1475 iSNS provides a convenient mechanism to distribute X.509 Public Key 1476 certificates. These certificates can be used to set up TLS or IPSec 1477 security associations for authenticating and/or encrypting storage 1478 traffic, as well as for the Public Key authentication method in the 1479 iSCSI login process. iSCSI devices can upload their own Public Key 1480 Certificates, allowing other iSCSI devices in their Discovery Domain 1481 to retrieve them. 1483 6.2.6 Entity Status Inquiry (ESI) 1484 iSNS provides a polling service to detect the removal or loss of 1485 connectivity to iSNS clients. iSCSI devices that register for ESI 1486 will receive an inquiry message from the iSNS server at regular time 1487 intervals. If the iSCSI device does not respond to three consecutive 1488 ESI messages, the iSNS server will determine that the iSCSI device is 1489 no longer available. Appropriate SCN messages will be sent to 1490 affected devices in the Discovery Domain. 1492 6.2.7 Event Logging 1494 iSNS provides an SCN Event Bitmap attribute for each iSCSI device 1495 allowing a management client to learn the last State Change 1496 Notification event to occur to that device. The Timestamp attribute 1497 records the precise time of the latest SCN event. 1499 6.2.8 Name Service Heartbeat 1500 iSNS provides a regular local subnet broadcast that allows iSCSI 1501 devices in the local network to passively listen for and learn the IP 1502 address of the iSNS server. 1504 6.2.9 Network Time Service 1505 iSNS provides an optional network time service allowing iSCSI devices 1506 to synchronize their time to the clock used by the iSNS. 1508 6.3 iSCSI Attributes Supported by iSNS 1510 The following attributes are supported by the iSNS protocol. 1511 Attributes indicated in the "REQUIRED TO IMPLEMENT" column MUST be 1512 supported by a server compliant with the iSNS protocol. Attributes 1513 indicated in the "REQUIRED TO USE" column MUST have values stored for 1514 an iSCSI device registered in the iSNS server. 1516 REQUIRED REQUIRED 1517 Object Attribute to Implement to Use 1518 ------ --------- ------------ -------- 1519 NETWORK ENTITY Entity Identifier * * 1520 Entity Type * * 1521 Management IP Address 1522 ESI Interval * 1523 Timestamp * 1524 Entity Certificate * 1525 SCN Event Bitmap * 1526 ESI TCP/UDP Port * * 1528 Network POR IP Address * * 1529 TCP/UDP Port * * 1530 Portal Symbolic Name * 1532 iSCSI NODE iSCSI Name * * 1533 Node Type * * 1534 Alias/Symbolic Node Name * 1535 Node Certificate * 1537 DISCOVERY DOMAIN DD_ID * * 1538 DD_Symbolic Name * 1539 DD Member (Entity ID) * 1540 DD_Member (iSCSI Name * * 1541 DD_Member (IP Address) * 1543 6.4 iSNS Message Summary 1545 The following messages are used by iSNS to support iSCSI devices. 1546 Messages listed in the "REQUIRED TO IMPLEMENT" column MUST be 1547 supported in the iSNS server. Messages listed in the "REQUIRED TO 1549 USE" column MUST be supported in the iSCSI device using iSNS. 1551 REQUIRED TO: 1552 Message Description Abbreviation Func_ID Implement Use 1553 ------------------- ------------ ------- --------- --- 1554 Register Dev Attr Req RegDevAttr 0x0001 * * 1555 Dev Attr Query Request DevAttrQry 0x0002 * * 1556 Dev Get Next Request DevGetNext 0x0003 * 1557 Deregister Dev Request DeregDev 0x0004 * * 1558 SCN Register Request SCNReg 0x0005 * 1559 SCN Deregister Request SCNDereg 0x0006 * 1560 SCN Event SCNEvent 0x0007 * 1561 State Change Notification SCN 0x0008 * 1562 Register DD RegDD 0x0009 * * 1563 Deregister DD DeregDD 0x000A * * 1564 Register Dev in DD RegDevDD 0x000B * * 1565 Deregister Dev in DD DeregDevDD 0x000C * * 1566 Entity Status Inquiry ESI 0x000D * 1567 Name Service Heartbeat Heartbeat 0x000E 1568 NOT USED 0x000F 1569 Request Network Time RqstTime 0x0010 1570 NOT USED 0x0011-0x0012 1571 RESERVED 0x0013-0x8000 1573 The following are iSNSP response messages used in support of iSCSI: 1575 REQUIRED TO: 1576 Response Message Desc Abbreviation Func_ID Implement Use 1577 --------------------- ------------ ------- --------- --- 1578 Register Dev Attr Rsp RegDevRsp 0x8001 * * 1579 Dev Attr Query Resp DevAttrQryRsp 0x8002 * * 1580 Dev Get Next Resp DevGetNextRsp 0x8003 * 1581 Deregister Dev Resp DeregDevRsp 0x8004 * * 1582 SCN Register Resp SCNRegRsp 0x8005 * 1583 SCN Deregister Resp SCNDeregRsp 0x8006 * 1584 SCN Event Resp SCNEventRsp 0x8007 * 1585 SCN Response SCNRsp 0x8008 * 1586 Register DD Resp RegDDRsp 0x8009 * * 1587 Deregister DD Resp DeregDDRsp 0x800A * * 1588 Register Dev in DD Resp RegDevDDRsp 0x800B * * 1589 Deregister Dev in DD Resp DeregDevDDRsp 0x800C * * 1590 Entity Stat Inquiry Resp ESIRsp 0x800D * 1591 NOT USED 0x800E-0x800F 1592 Request Net Time Resp RqstTimeRsp 0x8010 1593 NOT USED 0x8011-0x8012 1594 RESERVED 0x8013-0xFFFF 1596 7) Related Work 1597 Jini, UPnP, Salutation, and HaVi specifications also provide 1598 discovery protocol services. However, iSCSI uses SLP broadcast 1600 discovery mechanism because SLP is being developed as an IETF 1601 standard and since it provides all of the key broadcast discovery 1602 functionality provided by the other discovery protocols [1]. 1604 8) Security 1605 The iSCSI initiators and targets must have a secure way of 1606 interacting with each other. Hence, once a target or name server is 1607 discovered, authentication and authorization are handled by either 1608 the iSCSI protocol, or by the name server's protocol. It is the 1609 responsibility of the providers of these services to ensure that an 1610 inappropriately advertised or discovered service does not compromise 1611 their security. 1613 8. Appendix A: iSCSI Name Notes 1614 Some iSCSI Name Examples for Targets 1616 - Assign to a target based on controller serial number 1618 fqn.com.acme.diskarray.sn.8675309 1620 See the ASCII iSCSI Name example above for discussion. 1622 - Assign to a target based on serial number and logical target alias 1624 fqn.com.acme.diskarray.sn.8675309.oracle_database_1 1626 Where oracle_database_1 might be a target alias assigned by a user. 1628 This would be useful for a controller that can present 1629 different logical targets to different hosts. 1631 Obviously, any naming authority may come up with its own 1632 scheme and hierarchy for these names, and be just as valid. 1634 A target iSCSI Name should NEVER be assigned based on interface 1635 hardware, or other hardware that can be swapped and moved to other 1636 devices. 1638 Some iSCSI Name Examples for Initiators 1640 - Assign to the OS image by fully qualified host name 1642 fqn.com.osvendor.dns.com.customer1.host_four 1644 Note the use of two FQDNs - that of the naming 1645 authority and also that of the host that is being 1646 named. This can cause problems, due to limitations 1647 imposed on the size of the iSCSI Name. 1649 - Assign to the OS image by OS install serial number 1651 fqn.com.osvendor.newos5.12345-OEM-0067890-23456 1653 Note that this breaks if an install CD is used more 1655 than once. Depending on the O/S vendor's philosophy, 1656 this might be a feature. 1658 - Assign to the OS image by a service provider 1660 fqn.com.mydisk.users.mbakke05657 1662 Note that this could also be assigned to a particular 1663 iSCSI address if more than one service provider is used. 1665 Using Initiator and Target iSCSI Name During Login 1667 Some examples. 1669 1. Login to a known target iSCSI Name; initiator supports 1670 iSCSI Names. 1672 I->Login Request 1673 InitiatorName= fqn.com.os.hostid.34567890 1674 InitiatorAlias= myhost 1675 TargetName= fqn.com.acme.diskarray.sn.8675309 1676 . 1677 . text/login commands flow here during authentication phase 1678 . 1679 T->Login Response 1680 TargetName= fqn.com.acme.diskarray.sn.8675309 1681 TargetAlias= foo 1683 2. Login to an unknown target Name; initiator supports 1684 iSCSI Names. 1686 This only works if there is a single iSCSI Name at the IP address 1687 and TCP port to which the initiator has connected. 1689 I->Login Request 1690 InitiatorName= fqn.com.os.hostid.34567890 1691 InitiatorAlias= myhost 1692 TargetName= iscsi 1693 . 1694 . text/login commands flow here during authentication phase 1695 . 1696 T->Login Response 1697 TargetName= fqn.com.acme.diskarray.sn.8675309 1698 TargetAlias= 8675309 1700 3. Login to a canonical target, for the SendTargets command. 1702 I->Login Request 1703 InitiatorName= fqn.com.os.hostid.34567890 1704 InitiatorAlias= myhost 1705 TargetName= iscsi 1706 . 1707 . text/login commands flow here during authentication phase 1708 . 1709 T->Login Response 1710 TargetName= iscsi 1712 Since the target returned a iSCSI Name of "iscsi", the initiator 1713 will now use the SendTargets text command to find out which target 1714 names are actually supported at this address. It will then create 1715 new connections for each target, and do the login scenario shown 1716 in example 1. 1718 Answers to Potentially Frequently Asked Questions 1720 What happens if an Initiator Name is not unique? 1722 - Targets will authenticate both as same entity 1723 - Targets will believe that one initiator is using 1724 them via different network interfaces. 1725 - Initiators may end up sharing a device by 1726 accident. 1728 Appendix B: iSCSI Login Scenarios 1729 B.1. Introduction 1731 The Initiator Name MUST always be sent during login. As a target may 1732 use the Initiator Name as part of its access control mechanism, an 1733 initiator that does not send its Name stands the risk that it will be 1734 excluded from accessing some or all of its targets. 1736 The target Name MUST be sent in the login phase (with the exception 1737 that the key-word iscsi can replace unknown target). This can enable 1738 the distinction between several (virtual of physical) storage 1739 entities in the device. 1741 The iSCSI Names MUST be sent in the Login Request message, 1742 establishing the login session (together with the other login 1743 parameters). The iSCSI Names MUST be in text command format - UTF-8 1744 coded as described in section 3. 1746 The target MUST response to the login request with the appropriate 1747 status. The status codes are defined in the iSCSI draft [7]. 1749 B.2. Request Format 1751 The requests and responses are in key=value format. When more than 1752 one Value is required, a comma separator is used, i.e., 1753 key=value1,value2,..valuen. 1755 The key words are: 1757 +-----------------------------------------+ 1758 | Key | Description | 1759 +------------------+----------------------+ 1760 | InitiatorName | Initiator's Name | 1761 | TargetName | Target's Name | 1762 | TargetAlias | Target's Alias | 1763 | InitiatorAlias | Initiator's Alias | 1764 | TargetAddress | Target IP:Port | 1766 +-----------------------------------------+ 1768 In the Login Request command, the initiator uses the keys and the 1769 appropriate iSCSI Names as values. For example: 1771 I->Login Request 1772 InitiatorName= fqn.com.os.hostid.34567890 1773 InitiatorAlias= myhost 1774 TargetName= fqn.com.acme.diskarray.sn.8675309 1776 Here, both initiator and target Name are presented. Other parameters 1777 (security, negotiation) MAY be added. 1779 In the following example, only the initiator's Name is presented (the 1780 key-word iscsi is used): 1782 I->Login Request 1783 InitiatorName= fqn.com.os.hostid.34567890 1784 TargetName= iscsi 1786 Other parameters (security, negotiation) MAY be added. 1788 B.3. Response Format 1790 The response to the login request can be to accept the request, to 1791 reject it or to proceed for further processing (authentication). This 1792 status should be reflected on the response message. 1794 B.4. Examples 1796 B.4.1 Successful login, known target: 1798 I->Login Request 1799 InitiatorName= fqn.com.os.hostid.34567890 1800 InitiatorAlias= myhost 1801 TargetName= fqn.com.acme.diskarray.sn.8675309 1803 If no further process is needed: 1805 T->Login Response ("login accept 00", F set) 1806 TargetName= fqn.com.acme.diskarray.sn.8675309 1807 TargetAlias= foo 1809 Or, if more authentication and/or negotiation is required: 1811 T->Login Response ("challenge 20", F clear) 1812 . 1813 . authentication/negotiation 1814 . 1815 T->Login Response ("login accept", F set) 1816 TargetName= fqn.com.acme.diskarray.sn.8675309 1817 TargetAlias= foo 1819 In this case, target name is specified in the request. The response 1820 Reflects the iSCSI Names, indicating successful login. 1821 Target Alias MAY be presented. 1823 B.4.2 Successful login, unknown target: 1825 I->Login Request 1826 InitiatorName= fqn.com.os.hostid.34567890 1827 InitiatorAlias= myhost 1828 TargetName= iscsi 1829 . 1830 . authentication/negotiation 1831 . 1832 T->Login Response ("login accept", F set) 1833 TargetName= fqn.com.acme.diskarray.sn.8675309 1834 TargetAlias= foo 1836 If there is a single iSCSI Name at the IP address and TCP port 1837 to which the initiator has connected, this will work. 1838 he target returns its Name so the initiator can keep it 1839 for future use. 1841 Note that in the case of partial response, the target Name is 1842 reflected Only after the authentication process. 1844 B.4.3 Login to a canonical target, for the SendTargets command. 1846 The initiator MUST use the key word iscsi as target's Name: 1848 I->Login Request 1849 InitiatorName= fqn.com.os.hostid.34567890 1850 InitiatorAlias= myhost 1851 TargetName= iscsi 1852 . 1853 . authentication/negotiation 1854 . 1855 T->Login Response ("login accept", F set) 1856 TargetName= iscsi 1858 Since the target returned a iSCSI Name of "iscsi", the initiator 1859 MAY now use the SendTargets text command to find out which 1860 target Names are actually supported at this address. 1861 It will then create new connections for each target, and do 1862 the login scenario shown in 1863 A.4.1. 1865 B.4.4 Redirection 1867 If a target has moved, or is accessible only via a proxy, the target 1868 may respond with one of several redirection status codes, along with 1869 one or more TargetAddress fields specifying the new location(s) of 1870 the target. 1872 Note that a "moving target" is not changing its identity, or Name. It 1873 is only changing its address. A target returning a redirect status 1874 SHOULD also include one or more TargetAddress fields specifying the 1875 new locations of the target. 1877 For example, if the target moved temporarily: 1879 I->Login Request 1881 InitiatorName= fqn.com.os.hostid.34567890 1882 InitiatorAlias= myhost 1883 TargetName= fqn.com.acme.diskarray.sn.8675309 1884 . 1885 . authentication/negotiation 1886 . 1887 T->Login Response ("Target moved temporarily 31", F set) 1888 TargetName= fqn.com.acme.diskarray.sn.8675309 1889 TargetAddress= 10.1.40.50:384 1890 TargetAddress= storage1.mydata.com 1892 (The same goes for the permanent move - code 32). Note that if TCP 1893 port is not specified, the canonical port is assumed. 1895 The login response terminates the session and the initiator SHOULD 1896 start a new login session with the forwarded target. Further 1897 parameters MAY be reflected on other key=value pairs. 1899 Or, if a proxy is required for this target: 1901 I->Login Request 1902 InitiatorName= fqn.com.os.hostid.34567890 1903 InitiatorAlias= myhost 1904 TargetName= fqn.com.acme.diskarray.sn.8675309 1905 . 1906 . authentication/negotiation 1907 . 1908 T->Login Response ("Proxy required 33", F set) 1909 TargetName= fqn.com.acme.diskarray.sn.8675309 1910 TargetAddress= 10.1.40.50:384 1912 If more than one proxy exist, their addresses can be reflected in a 1913 list format. 1915 B.4.5 Login fail 1917 In case of login failure - forbidden target, unauthorized initiator 1918 and so on, the target terminates the session. 1920 I->Login Request 1921 InitiatorName= fqn.com.os.hostid.34567890 1922 TargetName= fqn.com.acme.diskarray.sn.8675309 1923 T->Login Response ("forbidden target 42", F set) 1925 In this example, the initiator is not allowed on the required target. 1926 The initiator SHOULD terminate the login session and MAY try 1927 connecting to another target. 1929 I->Login Request 1930 InitiatorName= fqn.com.os.hostid.34567890 1931 TargetName= fqn.com.acme.diskarray.sn.8675309 1932 T->Login Response ("Target removed 44", F set) 1934 In this case the target has been removed. In contrast with codes 31 1935 and 32 (in B.4.4), no redirection information is supplied. 1937 I->Login Request 1939 InitiatorName= fqn.com.os.hostid.34567890 1940 TargetName= fqn.com.acme.diskarray.sn.8675309 1941 T->Login Response ("Target Conflict 45", F set) 1943 Here, the target is busy with another initiator and cannot handle 1944 another one. The initiator MAY try again later. This can be the case 1945 of simple devices that can handle one device or the target has 1946 reached the limit of its initiators' capacity. In contrast to the 1947 previous examples, this rejection is temporary. 1949 I->Login Request 1950 InitiatorName= fqn.com.os.hostid.34567890 1951 TargetName= fqn.com.acme.diskarray.sn.8675309 1952 T->Login Response ("Target removed 44", F set) 1954 Here, the target has been removed. The initiator SHOULD terminate the 1955 login session. It MAY query the SNS for the new location of the 1956 target. (This should apply for the case when the target was not found 1957 - code 44). 1959 In any case of the 4x and 5x class, there is no name reflection on 1960 the Login response. However, detailed messages can be carried on 1961 other key=value pairs. 1963 B.4.6 Proxy Login 1965 When the initiator logs to a target via an (iSCSI) proxy, the 1966 following procedure is applied: 1968 The initiator connects to the proxy's port and sends a login request 1969 of the destination target's Name and address: 1971 I->Login Request 1972 InitiatorName= fqn.com.os.hostid.34567890 1973 TargetName= fqn.com.acme.diskarray.sn.8675309 1974 TargetAddress= 10.1.30.75:240 1976 Using the TargetAddress key saves the discovery process of the 1977 target. The proxy logs into the required target with the initiator's 1978 Name. The results of the login are reflected back to the initiator. 1980 Note that a transparent (iSCSI) proxy does not have an iSCSI 1981 Name of its own. 1983 Appendix C: iSCSI Proxies and Firewalls Taxonomy 1985 iSCSI has been designed to allow SCSI initiators and targets 1986 to communicate over an arbitrary network. This, making some 1987 assumptions about authentication and security, means that in 1988 theory, the whole internet could be used as one giant storage 1989 network. 1991 However, there are many access and scaling problems that would 1992 come up when this is attempted. 1994 1. Most iSCSI targets are only meant to be accessed by one or 1996 a few initiators. Discovering everything would be silly. 1998 2. The initiator and target may be owned by separate entities, 1999 each with their own directory services, authentication, and 2000 other schemes. An iSCSI-aware proxy may be required to 2001 map between these things. 2003 3. Many environments use non-routable IP addresses, such as the 2004 10. network. 2006 For these and other reasons, various types of firewalls and proxies 2007 will be deployed for iSCSI, similar in nature to those already 2008 handling protocols such as HTTP and FTP. 2010 1. Port Redirector 2012 A port redirector is a stateless device that is not aware of iSCSI. 2013 It is used to do Network Address Translation (NAT), which can map 2014 IP addresses between routable and non-routable domains, as well as 2015 map TCP ports. While devices providing these capabilities can often 2016 filter based on IP addresses and TCP ports, they generally do not 2017 provide meaningful security, and are used instead to resolve 2018 internal network routing issues. 2020 Since it is entirely possible that these devices are used as 2021 routers and/or aggregators between a firewall and an iSCSI 2022 initiator or target, iSCSI connections must be operable through 2023 them. 2025 Effects on iSCSI: 2027 - iSCSI-level data integrity checks must not include information 2028 from the TCP or IP headers, as these may be changed in between 2029 the initiator and target. 2031 - iSCSI messages that specify a particular initiator or target, 2032 such as login requests and third party requests, should specify 2033 the initiator or target in a location-independent manner. 2034 This is accomplished using the iSCSI Name. 2036 2. SOCKS server 2038 A SOCKS server can be used to map TCP connections from one network 2039 domain to another. It is aware of the state of each TCP 2040 connection. 2042 The SOCKS server provides authenticated firewall traversal for 2043 applications that are not firewall-aware. Conceptually, SOCKS is 2044 a "shim-layer" that exists between the application (i.e., iSCSI) 2045 and TCP. 2047 To use SOCKS, the iSCSI initiator must be modified to use the 2048 encapsulation routines in the SOCKS library. The initiator 2049 the opens up a TCP connection to the SOCKS server, typically on 2050 the canonical SOCKS port 1080. A subnegotiation then occurs, 2051 during which the initiator is either authenticated or denied 2052 the connection request. If authenticated, the SOCKS server then 2054 opens a TCP connection to the iSCSI target using addressing 2055 information sent to it by the initiator in the SOCKS shim. The 2056 SOCKS server then forwards iSCSI commands, data, and responses 2057 between the iSCSI initiator and target. 2059 Use of the SOCKS server requires special modifications to the 2060 iSCSI initiator. No modifications are required to the iSCSI 2061 target. 2063 As a SOCKS server can map most of the addresses and information 2064 contained within the IP and TCP headers, including sequence 2065 numbers, its effects on iSCSI are identical to those in the port 2066 redirector. 2068 3. iSCSI Proxy 2070 An iSCSI proxy is similar to proxies available in HTTP. 2071 The initiator is aware of the actual addresses of the targets, 2072 but instead of connecting to the addresses, connects instead 2073 to a proxy's address. The proxy, in turn, connects to the 2074 actual targets. This is similar to the HTTP/1.1 proxy, where 2075 the client passes the entire URL (including IP and TCP address) 2076 to the proxy, rather than just the path name. 2078 An iSCSI proxy can provide some good iSCSI-level access 2079 control and other functionality, while adding fairly light 2080 configuration responsibilities. 2082 Effects on iSCSI: 2084 - When logging in to a target at a proxy address instead of the 2085 actual address, the target should include the TargetAddress (IP 2086 address and TCP port) of the target, in addition to its iSCSI Name. 2087 Note, however, that this directly conflicts with the statement made 2088 regarding NAT firewalls. Since the iSCSI Name can uniquely 2089 identify an iSCSI device, the TargetAddress must then be used by 2090 the proxy as a hint on where to find the iSCSI Name, and not as the 2091 final authority. 2093 - This is beginning to be covered in the iSCSI specification. 2095 Having the address passed with the iSCSI Name would allow an iSCSI 2096 proxy to exist without extra configuration or name services. 2097 Using this type of proxy can eliminate the need to implement SOCKS. 2099 4. SCSI gateway 2101 This gateway presents logical targets (iSCSI Names) to the 2102 initiators, and maps them to real iSCSI targets as it chooses. 2103 The initiator sees this gateway as a real iSCSI target, and is 2104 unaware of any proxy or gateway behavior. The gateway may 2105 manufacture its own iSCSI Names,or use those provided by the 2106 real devices. This type of gateway is used to represent parallel 2107 SCSI, Fibre Channel, SSA, or other devices as iSCSI devices. 2109 Nearly any capability that could be imagined is possible with this 2111 type of gateway, but it may require more configuration than an 2112 iSCSI proxy. 2114 Effects on iSCSI: 2116 - Since the initiator is unaware of any addresses beyond the 2117 gateway, the gateway's own address is for all practial 2118 purposes the real address of a target. Only the iSCSI Name 2119 needs to be passed. This is already done in iSCSI, so there are 2120 no further requirements to support SCSI gateways. 2122 5. Stateful Inspection Firewall (stealth iSCSI firewall) 2124 The Stealth model would exist as an iSCSI-aware firewall, that 2125 is invisible to the initiator, but provides capabilities found 2126 in the iSCSI proxy. 2128 Effects on iSCSI: 2130 - Since this is invisible, I don't think there are any 2131 additional requirements on the iSCSI protocol for this 2132 one. 2134 This one is more difficult in some ways to implement, simply 2135 because it has to be part of a standard firewall product, 2136 rather than part of an iSCSI-type product. For this reason, 2137 I would not expect to see these implemented for a while. 2139 Also note that this type of firewall is only effective 2140 in the outbound direction (allowing an initiator behind the 2141 firewall to connect to an outside target), unless the iSCSI target 2142 is located in a DMZ. It does not provide adequate security 2143 otherwise. 2145 8. References 2146 [1] Pascoe, R., "Building Networks on the Fly", in IEEE Spectrum, 2147 March, 2001. 2149 [2] John, R., "UPnP, Jini and Salutation- A look at some popular 2150 coordination frameworks for future networked devices", 2151 http://www.cswl.com/whiteppr/tech/upnp.html", June 17, 1999. 2153 [3] http://www.srvloc.org 2155 [4] Freed, N., "Behavior of and Requirements for Internet Firewalls", 2156 RFC 2979, October 2000. 2157 [5] ANSI/IEEE Std 802-1990, Name: IEEE Standards for Local and 2158 Metropolitan Area Networks: Overview and Architecture 2160 [6] Kessler, G. and Shepard, S., "A Primer On Internet and TCP/IP 2161 Tools 2162 and Utilities", RFC 2151, June 1997. 2164 [7] Satran, J., Sapuntzakis, C., Wakeley, M., Von Stamwitz, P., 2165 Haagens, R., Zeidner, E., Dalle Ore, L., Klein, Y., "iSCSI", 2166 draft-ietf-ips-iscsi-00.txt, February, 2000. 2168 [8] Gibbons, K., Tseng, J. and Monia, C., "iSNS Internet Storage Name 2169 Service", draft-tseng-ips-isns-00.txt, October 2000. 2171 [9] RFC 1737, "Functional Requirements for Uniform Resource Names". 2173 [10] RFC 1035, "Domain Names - Implementation and Specification". 2174 OUI - "IEEE OUI and Company_Id Assignments", 2175 http://standards.ieee.org/regauth/oui/index.shtml 2176 [11]EUI - "Guidelines for 64-bit Global Identifier (EUI-64) 2177 Registration Authority 2178 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html 2180 [12] RFC 2396, "Uniform Resource Identifiers". 2181 [13] RFC 2276, "Architectural Principles of URN Resolution". 2183 [14] RFC 2483, "URI Resolution Services". 2185 [15] RFC 2141, "URN Syntax". 2187 [16] RFC 2611, "URN Namespace Definition Mechanisms". 2189 [17] RFC 2608, SLP Version 2. 2190 [18] RFC 2610, DHCP Options for the Service Location Protocol. 2192 [19] P. Sarkar et al, "A Standard for Bootstrapping Clients using the 2193 iSCSI Protocol", draft-ietf-ips-iscsi-boot-01. 2194 [21] M. Bakke et al,"Finding iSCSI Targets and Name Servers using 2195 SLP", draft-bakke-iscsi-SLP-template.00. 2196 [ More references to add to the end of NDT: ] 2198 [22]] Sun Microsystems, "Java Language Specification", section 2199 7.7 "Unique Package Names", 2000, 2201 http://java.sun.com/docs/books/jls/second_edition/html/jTOC.doc.html. 2203 [23]] Flanagan, et. al, "Java in a Nutshell", O'Reilly, 1997. 2205 6. Contact Author 2206 Kaladhar Voruganti 2207 650 Harry Road 2208 IBM Almaden Research 2209 San Jose, CA 2210 USA 2211 Email: kaladhar@us.ibm.com 2213 Voruganti Internet Draft Expires October 2001 2215 iSCSI Naming and Discovery OCtober 2001 2217 "Copyright (C) The Internet Society (date). All Rights Reserved. This 2218 document and translations of it may be copied and furnished to 2219 others, and derivative works that comment on or otherwise explain it 2220 or assist in its implementation may be prepared, copied, published 2221 and distributed,in whole or in part, without restriction of any kind, 2222 provided that the above copyright notice and this paragraph are 2223 included on all such copies and derivative works. However, this 2224 document itself may not be modified in any way, Full Copyright 2225 Statement such as by removing the copyright notice or references to 2226 the Internet Society or other Internet organizations, except as 2227 needed for the purpose of developing Internet standards in which case 2228 the procedures for copyrights defined in the Internet Standards 2229 process must be followed, or as required to translate it into 2230 languages other than English. 2232 The limited permissions granted above are perpetual and will not be 2233 revoked by the Internet Society or its successors or assigns. 2235 This document and the information contained herein is provided on an 2236 "As IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2237 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED , INCLUDING 2238 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2239 HEREIN 2240 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2241 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE" 2243 Voruganti iSCSI Naming and Discovery Draft Expires October 2001