idnits 2.17.1 draft-ietf-ips-iscsi-disc-reqts-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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. == 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 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Abstract' ) ** The document seems to lack an Introduction section. ** 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. ** There are 290 instances of too long lines in the document, the longest one being 17 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 66 has weird spacing: '...bes the iSCSI...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- 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 738 looks like a reference -- Missing reference section? '6' on line 120 looks like a reference -- Missing reference section? '8' on line 742 looks like a reference -- Missing reference section? '1' on line 723 looks like a reference -- Missing reference section? '2' on line 725 looks like a reference -- Missing reference section? '3' on line 729 looks like a reference -- Missing reference section? '4' on line 731 looks like a reference -- Missing reference section? '5' on line 734 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 iSCSI Mark Bakke 3 Internet Draft Cisco 5 Joe Czap 6 IBM 8 Jim Hafner 9 IBM 11 Howard Hall 12 Pirus 14 Jack Harwood 15 EMC 17 John Hufferd 18 IBM 20 Yaron Klein 21 Sanrad 23 Lawrence Lamers 24 San Valley Systems 26 Joshua Tseng 27 Nishan 29 Kaladhar Voruganti 30 IBM 32 draft-ietf-ips-iscsi-disc-reqts-01.txt January, 2001 33 Expires July 2001 35 iSCSI Naming and Discovery Requirements 37 Status of this Memo 39 This document is an Internet-Draft and is in full conformance with 40 all provisions of Section 10 of RFC2026 except that the right to 41 produce derivative works is not granted. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF), its areas, and its working groups. Note that 45 other groups may also distribute working documents as Internet- 46 Drafts. Internet-Drafts are draft documents valid for a maximum of 47 six months and may be updated, replaced, or obsoleted by other 48 documents at any time. It is inappropriate to use Internet- Drafts 49 as reference material or to cite them other than as "work in 50 progress." 51 The list of current Internet-Drafts can be accessed at 52 http://www.ietf.org/ietf/1id-abstracts.txt 53 Voruganti Internet Draft Expires July 2001 1 55 iSCSI Naming and Discovery November 2000 57 The list of Internet-Draft Shadow Directories can be accessed at 58 http://www.ietf.org/shadow.html. 60 Comments 61 Comments should be sent to the ips mailing list (ips@ece.cmu.edu) or to 62 kaladhar@us.ibm.com 64 1. Abstract 66 This document describes the iSCSI [7] naming and discovery requirements. The 67 requirements presented in this document have been agreed to by the members of 68 the iSCSI naming and discovery team. This document complements the iSCSI IETF 69 draft. Flexibility is the key guiding principle behind this requirements 70 document. That is, an effort has been made to satisfy the needs of both small 71 isolated environments, as well as large environments requiring secure/scalable 72 solutions. 74 This document has been organized into the following sections: 75 a) Section 3 presents the naming requirements. 76 b) Section 4 discusses the discovery requirements. 77 c) Section 5 presents Storage Name Server (SNS) requirements. 78 d) Section 6 briefly discusses other existing discovery protocols. 80 2. Conventions used in this document 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 84 this document are to be interpreted as described in RFC-2119. 86 3. Naming Requirements 87 In order for an iSCSI initiator to connect to an iSCSI target, the initiator 88 needs to provide information about the Network Entity object, Portal Object and 89 the target Storage Node object. The details of these three iSCSI objects are as 90 follows: 92 a) Network Entity Object 93 The Network Entity object represents a device or gateway that is accessible from 94 the IP network. This device or gateway may support one or more initiators or 95 targets that are either internal to the storage device or accessible through a 96 network behind the gateway. Each initiator or target is represented by 97 subordinate Storage Node objects. The Network Entity object is identified by its 98 IP address. 100 b) Portal Object 101 object within the Network Entity object can be obtained. A Network Entity object 102 must have one or more Portal objects, each of which is usable by Storage Node 103 objects contained in that Network Entity object to gain access to the IP 104 network. The Portal object is identified by its IP address and Port number. The 105 Portal object's IP address can be different than the Network Entity IP address. 106 There is a canonical iSCSI TCP port present at each Network Entity object. 107 However, Storage Node objects can also be accessed via non-canonical 108 iSCSI TCP ports. 110 c) Storage Node Object 111 The Storage Node object defines an individual iSCSI initiator or target. 112 There may be one or more Storage Node objects within the Network Entity 113 object. A Storage Node object is identified by its world wide unique 114 identifier (WWUI). There is a requirement to have the ability to generate 115 world wide unique identifiers (WWUIs) for both iSCSI initiators and targets. 116 However, it is not mandatory for the initiators and targets to use WWUIs 117 because a globally unique identifier might not be required in some simple, 118 isolated iSCSI configurations. WWUIs are useful because in some cases (e.g. when 119 DHCP services [6] are used etc), the combination of IP address and port number 120 [6] cannot uniquely identify an initiator or a target. 122 There is a default Storage Node object present at every target network entity 123 that can be accessed without specifying the WWUI. However, if there are multiple 124 iSCSI target Storage Nodes that are serviced by a single Network Entity and 125 Portal objects, then it is necessary for the initiator to specify the target 126 Storage Node WWUI to uniquely identify the target storage node. An alias string 127 could also be associated with a target storage node. The target alias helps an 128 organization to associate their own semantic meaning with the target alias 129 string. For example, the alias string could represent the organizational 130 hierarchy in which the storage device resides such as: 131 CompanyXXX.com/research/dept1/individual/storage_device1 132 However, the target alias string is not a substitute for the target WWUI. 134 3.1 World Wide Unique Identifier 136 The WWUI uniquely identifies iSCSI initiators and targets. The initiator WWUI 137 corresponds to the logical operating system on which the initiator is running, 138 and the target WWUI corresponds to the target Storage Node entity. The WWUI may 139 be displayed by user interfaces, but is generally uninterpreted and used as an 140 opaque binary string for comparison with other WWUI values. 142 The use of the naming authority means that WWUIs can be assigned by virtually 143 any uniqueness scheme that can be devised by OS vendors, driver or iSCSI NIC 144 vendors, device vendors, gateway vendors, and even the customer. 146 The format of the iSCSI WWUI is as follows: 148 WWUI = Length + Type + Type-dependent format 150 Length is 1 byte and includes Type and the rest of the WWUI, but not itself. 152 (including Length), and a maximum type-dependent format of 254 bytes. 154 The minimum length of a WWUI is 2; the WWUI would consist of just 155 the Length field (== 1), and a Type field. 157 Type is 1 byte and is as follows (similar, but not identical to SPC-2 VPD) 159 00 - No_Authority (not guaranteed to be unique) 160 01 - ASCII (using reversed DNS name as Naming Authority) 161 02 - IEEE EUI-64 162 03 - Unicode (DNS naming authority) 163 04 - Generic Binary WWUI (to be considered) 165 Addition of new types requires approval to become an iSCSI standard. 167 Open Question: Should all occurences of "ASCII" in this 168 document be replaced with "UTF-8"? So far, we 169 have had no votes for UTF-8. 171 Open Question: Should the WWUI be padded to a 4-byte boundary? 172 Please see discussion on transporting a WWUI. 174 Use of the ASCII format is recommended when possible for the following 175 reasons: 177 - an ASCII WWUI is easier to type and differentiate in a user 178 interface. 180 - An ASCII WWUI can use a DNS name as a naming authority. It can 181 be assumed that anyone who wants to name targets or initiators 182 owns a DNS name. The same is not true for either OUI or SCSI 183 Vendor ID. This also means that end users can name their own 184 targets and initiators, for whatever their purposes may be. 186 - WWUIs are only used during login and discovery phases, so the 187 overhead does not get in the way of the data path. 189 The IEEE format is recommended when: 191 - There is an existing IEEE unique name that must be communicated 192 to iSCSI. 194 The Unicode format is recommended in place of ASCII when: 196 - Human-readable format is desired, and a character set other 197 than ASCII is needed. 199 We may also consider adding a generic binary string format using a 200 manufacturer's OUI as a naming authority. 202 following formats: 204 No_WWUI Format 206 +------------+-----------+ 207 | Length = 1 | Type = 00 | 208 +------------+-----------+ 210 This format is used to indicate a NULL WWUI. 212 ASCII_WWUI Format 214 +------------------+-----------+------------------ 215 | Length = | Type = 01 | string 216 | 1+strlen(string) | | 217 +------------------+-----------+------------------ 219 The ASCII WWUI string is defined as follows: 221 String starts with a backwards domain name specifying the Naming 222 Authority, using dots as separators, just as in a regular domain 223 name. It's backwards, since it is not really used as a fully 224 qualified host name; only the necessary top levels need by used. 226 Basically, everything after the backwards domain name, followed 227 by another dot ".", can be assigned as needed by the owner of 228 the domain name. 230 Here is an example ASCII WWUI string: 232 3201com.acme.diskarrays.sn.a8675309 234 Where: 235 32 is the length of the string + length of Type 236 01 refers to ASCII WWUI type string 238 In the rest of this document even though the length field and the type 239 field values are in front of the WWUI string, they are not being 240 shown for 241 readability sake. 243 "com.acme" defines the Naming Authority. The owner of the DNS 244 name "acme.com" has the sole right of use of this name within 245 a WWUI. In this case, acme.com happens to manufacture disk 246 arrays. 248 "diskarrays" was picked arbitrarily by acme.com to use to 249 identify the disk arrays they manufacture. Another product 250 that ACME makes would use a different name, and have their 251 own namespace independent of the disk array group. 253 "sn" was picked by the disk array group of Acme to show that 254 what follows is a serial number. They could have just assumed 255 that all WWUIs are based on serial numbers, but they thought 256 something else. Adding "sn" was a future-proof measure. 258 "a8675309" is the serial number of the disk array, uniquely 259 identifying it from all other arrays. 261 Please note that WWUI is NOT an address - even though it uses a DNS 262 name, this is for the naming authority only; it is not an address 263 used to discover anything. 265 Note that we could have used the ASCII Vendor ID as a naming 266 authority. However, some large customers and service providers 267 may wish to use their own identification scheme, rather than 268 that provided by the manufacturer. These customers would not 269 likely have a registered Vendor ID, but the domain name we 270 used is ubiquitous, and seemed more appropriate. 272 Further examples of ASCII WWUIs are given at the end of this 273 document. 275 IEEE_WWUI 277 +------------+-----------+---------------------+ 278 | Length = 9 | Type = 02 | IEEE EUI-64 Address | 279 +------------+-----------+---------------------+ 281 The IEEE WWUI might be used when a manufacturer is already 282 basing unique identifiers on World-Wide Names as defined in 283 the SCSI SPC-2 specification. 285 It may also be used by a gateway representing a Fibre Channel 286 or SCSI device that is already adequately identified using a 287 world-wide name. 289 Unicode_WWUI 291 +------------------+-----------+------------------ 292 | Length = | Type = 03 | Unicode string 293 | 1+strlen(string) | | 294 +------------------+-----------+------------------ 296 This format is identical to the ASCII format, including the 297 use of the reversed domain name as the naming authority, except 298 that Unicode is used instead of ASCII. 300 Binary_WWUI Format (to be considered) 302 +------------------+-----------+------------------ 303 | Length = | Type = 04 | OUI | binary UI 304 | 1+len(binary UI) | | 3 bytes | 305 +------------------+-----------+------------------ 307 Initiator and Target Requirements for WWUI support: 309 Both shall support WWUIs of up to the maximum length. 311 Initiators and targets shall present their own WWUI as part of 312 the protocols defined elsewhere. 314 User interfaces should display any ASCII type WWUI as an 315 ASCII string, any binary format WWUI as a string of hex digits, 316 and all types unknown to the implementation as if the format 317 were binary. 319 Some WWUI Examples for Targets 321 - Assign to a target based on controller serial number 323 com.acme.diskarray.sn.8675309 325 See the ASCII WWUI example above for discussion. 327 - Assign to a target based on serial number and logical target alias 329 com.acme.diskarray.sn.8675309.oracle_database_1 331 Where oracle_database_1 might be a target alias assigned by 332 a user. 334 This would be useful for a controller that can present 335 different logical targets to different hosts. 337 Obviously, any naming authority may come up with its own scheme 338 and hierarchy for these names, and be just as valid. 340 A target WWUI should NEVER be assigned based on interface hardware, 341 or other hardware that can be swapped and moved to other devices. 343 Some WWUI Examples for Initiators 345 - Assign to the OS image by fully qualified host name 347 com.osvendor.dns.com.customer1.host_four 349 Note the use of two FQDNs - that of the naming 350 authority and also that of the host that is being 351 named. This can cause problems, due to limitations 352 imposed on the size of the WWUI. 354 ( write in what to do about this ) 356 - Assign to the OS image by OS install serial number 358 com.osvendor.newos5.12345-OEM-0067890-23456 360 Note that this breaks if an install CD is used more 361 than once. 363 com.mydisk.users.mbakke05657 365 Note that this could also be assigned to a particular 366 iSCSI address if more than one SP is used. 368 Some WWUI Examples for Gateways 370 ( needs work, but gateway vendors are a creative lot ) 372 Adding the WWUI to SCSI Third Party Commands 374 Work done on adding the WWUI address type to SCSI third 375 party commands, such as extended copy, is being done in 376 T10. 378 Using Initiator and Target WWUI During Login 380 The Initiator WWUI should always be sent during login. As a target 381 may use the Initiator WWUI as part of its access control mechanism, an 382 initiator that does not send its WWUI stands the risk that it will be 383 excluded from accessing some or all of its targets. 385 1. Both target WWUI and the target alias are specified I->Login Request 386 InitiatorWWUI: com.os.hostid.34567890 387 TargetWWUI: com.acme.diskarray.sn.8675309 388 TargetAlias: foo 389 . 390 . text commands flow here during authentication phase 391 . 392 T->Login Response 393 TargetWWUI: com.acme.diskarray.sn.8675309 394 TargetAlias: foo 396 2. Only Target WWUI is specified and no alias is specified. 398 I->Login Request 399 InitiatorWWUI: com.os.hostid.34567890 400 TargetWWUI: com.acme.diskarray.sn.8675309 401 . 402 . text commands flow here during authentication phase 403 . 404 T->Login Response 405 TargetWWUI: com.acme.diskarray.sn.8675309 406 TargetAlias: foo 408 3. Neither target alias nor WWUI is specified. If there is just 409 one target, or a default target, at the IP Address and port, 410 this will work. The target returns its WWUI so the initiator 411 can keep it for future use. 413 I->Login Request 414 InitiatorWWUI: com.os.hostid.34567890 415 . 417 . 418 T->Login Response 419 TargetWWUI: com.acme.diskarray.sn.8675309 420 TargetAlias: foo 422 Answers to Potentially Frequently Asked Questions 424 What happens if an Initiator WWUI is not unique? 426 - Targets will authenticate both as same entity 427 - Targets will believe that one initiator is using 428 them via different network interfaces. 429 - Initiators may end up sharing a device by 430 accident. 432 3.2 Alias String 433 The alias string is an ASCII string that is used to identify a Storage Node 434 object that can be accessed via a particular Network Entity object and a Portal 435 object. The alias string is a variable length, between 0 to 255 bytes, 436 user-readable ASCII text string. The alias string is terminated with at least 437 one NULL character. The alias string format is similar to that of the UNIX file 438 address format. 440 4. iSCSI Discovery 441 An iSCSI initiator Storage Node can discover an iSCSI target Storage Node 442 in the following different ways: 443 a) Target information is hard-coded at the initiator. 444 b) Initiator queries storage name servers. 445 c) Initiator issues a multicast discovery message to the targets and the 446 SNS. 447 d) Initiator queries a canonical iSCSI target Storage Node object at a Network 448 Entity object for a list of targets. 450 4.1 Target Information is hard-coded 451 The exact manner in which the target information is hard-coded at the initiator 452 is an implementation detail. The information could be present in some persistent 453 location (such as a file) that can be accessed by the initiator. 455 4.2 Initiator queries a Storage Name Server (SNS) 456 The initiator can query a SNS for a list of the targets that it can access. 457 The type of information that is stored at the SNS, and the list of query and 458 registration APIs that should be supported by the SNS server are described in 459 Section 5 below. The implementation details of the SNS are beyond the scope of 460 this document. 462 4.3 Initiator Issues a Multicast Message 463 An initiator can send a multicast message to both storage name servers and iSCSI 464 targets. An initiator MAY send a multicast "SNS discovery" message to the (TBD) 465 iSCSI discovery multicast address on a (TBD) well-known iSCSI UDP port. An iSCSI 466 SNS MUST register as part of the iSCSI discovery multicast group and SHALL 467 respond to this message indicating that it functions as an SNS. Targets MAY 468 Alternatively, an initiator MAY send a multicast "all storage discovery" message 469 to the same multicast address. A storage name server MUST respond to this 470 message as if the message were the "SNS discovery message". A registered 471 target MAY respond to this message indicating that it is an iSCSI target. 472 A device that provides both iSCSI target and storage name server functions SHALL 473 respond with a message indicating that it provides both services. Finally, 474 the initiator MAY send a multicast "iSCSI targets only" message to the same 475 multicast address, and only the iSCSI targets and the iSCSI devices that provide 476 both iSCSI target and storage name server functions MAY respond to this message. 477 The choice of static configuration, SNS discovery or all storage discovery 478 protocols is a configuration choice of the initiator. There is no 479 authentication process associated with the iSCSI discovery multicast 480 messages. 482 If the initiator receives one or more responses to the "SNS discovery" message, 483 it may interact with those device for its target discovery services. If an 484 initiator receives responses to the "all storage discovery" message from only 485 targets, it may attempt Login with each of those devices. If an initiator 486 receives responses to an "all storage discovery" message from both targets and 487 storage name servers, it may choose to interact with the storage name servers 488 for target discovery services and/or attempt Login directly with responding 489 registered targets. 491 In summary, this discovery approach is flexible in that the initiators have the 492 freedom to select static configuration, a multicast based discovery mechanism 493 for small, isolated iSCSI environments, or they can choose a scalable storage 494 name server based discovery mechanism for large iSCSI environments. 495 Additionally, targets may be configured to participate or not 496 participate in the multicast group (e.g., if there is an SNS available, then 497 they may chose either dynamically or by configuration not to register in the 498 group). 500 4.4 SendTargets Command 502 An initiator may, after the Login process, connect to an iSCSI 503 canonical target and request for a list of target WWUIs, via a separate 504 SendTargets command, at the particular Network Entity object and the Portal 505 object. The returned data for this request shall contain a list 506 of tuples, where each tuple consists of a target WWUI and an IP 507 address:Port and an optional alias string. The canonical target MUST support 508 this request and the returned list MUST contain at least one entry for the 509 canonical target itself. The initiator can then attempt iSCSI Login to each of 510 the targets specified in the returned list. 512 During the login command, the initiator sets the target alias to "iSCSI" 513 with a WWUI of "*". If the login succeeds, the initiator may send a 514 sendTargets text command. 516 The response to this command is a text response containing a list of 517 tuples. 519 The format of this text string is as follows: 521 522 TargetWWUI:com.acme.diskarray.sn.8675309 523 TargetAddress:10.1.0.45:3000 524 TargetAlias:foo/diskController1 525 TargetWWUI:com.acme.diskarray.sn.8888888 526 TargetAddress:10.1.0.46:3000 527 TargetAlias:foo/diskController2 529 A line containing the term TargetWWUI: is the start of a target; followed by its 530 address and alias, until the next targetWWUI: line. If no target addresses are 531 given, the initiator can log in to the same address as that used for in the 532 SendTargets command, and login to the default target. If multiple paths to the 533 WWUI are known, multiple address lines may be given. 535 4.4.1 Port Redirect Command 536 During the Login process, a target may redirect the initiator to connect to 537 another IP address:Port and then terminate the Login command (and its 538 connection). A target might do this for load balancing or it might do this to 539 provide multiple virtual targets through a simple initiator discovery protocol. 540 The target's response is a text string that is in the following format: 541 "REDIRECT: TargetWWUI:com.acme.diskarray.sn.999999 542 TargetAddress:10.1.0.49:3000 543 TargetAlias:foo/diskController3" 545 5. Storage Name Server (SNS) 547 The following section describes requirements for any Storage Name Server 548 used to support iSCSI. An example of a Storage Name Server is the iSNS 549 described in the draft document draft-ietf-ips-iSNS-00.txt [8]. 551 5.1 Overview 553 The SNS shall be architected using a client-server paradigm, with the SNS server 554 predominantly serving a passive role. SNS clients actively register and 555 manipulate entity objects and their attributes in the SNS server. The SNS 556 server MAY send asynchronous state change notifications to registered SNS 557 clients in response to an action by a SNS client. Examples of SNS clients 558 include initiators, targets, management stations, and switches. The SNS server 559 can be hosted on a target, switch, or stand-alone server. 561 5.2 Login Control and Zoning 563 The SNS MUST support Zoning and Login control. The SNS must provide SNS clients 564 with the ability to enforce zoning configurations which may exist on the SNS 565 server. Targets and management stations shall be able to register (i.e., 566 upload) Login Control and Zoning configurations to the iSNS if authorized by the 567 end user. 569 Zoning and Login control supports two separate purposes: 571 5.2.1 Discovery Domain Partitions 573 The SNS SHALL support the ability to partition the storage network into separate 574 performing the query is not in a common zone (i.e., "Discovery Domain") as the 575 SNS client that is the subject of the request. This capability prevents an 576 initiator from attempting an iSCSI login to every single target in a large 577 enterprise network, and is the iSCSI equivalent of "Soft" zoning. 579 5.2.2 Login Control 581 To support login access security which is specified in the current iSCSI draft 582 (Appendix A) [7] and MAY be implemented by the iSCSI target. The SNS shall 583 support login control by storing a mapping of initiators that are permitted to 584 access each target. Targets shall be able to query the SNS for 585 a list of initiators that are allowed login access. This list shall include 586 the key attribute (e.g., WWUI) used to identify the initiator. This capability 587 is the iSCSI equivalent of "Hard" zoning. 589 5.3 Object Model 591 The SNS MUST store the following objects and attributes: 593 Network Entity: 594 - Entity Identifier 595 - Management IP Address 596 - Entity Type (iSCSI) 598 Portal: 599 - Portal Index 600 - IP Address 601 - TCP Port Number 603 Storage Node: 604 - WWUI 605 - Alias 606 - Node Type (target or initiator or both) 608 Zone: 609 - Zone symbolic name 610 - Zone ID 611 - Zone Member: WWUI 612 - Zone Member: IP Address 614 A diagram of how the above objects are related is shown below. 616 +----------------------------------------------------------------+ 617 | IP Network | 618 +------------+--------------------------------------+------------+ 619 | | 620 | | 621 +-----+------+------+-----+ +-----+------+------+-----+ 622 | | PORTAL | | | | PORTAL | | 623 | | -IP Addr 1 | | | | -IP Addr 2 | | 624 | | -TCP Port 1 | | | | -TCP Port 2 | | 625 | +-----+ +-----+ | | +-----+ +-----+ | 626 | | | | | | | | 627 | | | | | | | | 628 | +--------+ +--------+ | | +-------+ +--------+ | 629 | | | | | | | | 630 | | -WWUI | | | | -WWUI | | 631 | | -Alias: "server1"| | | | Alias: "disk1" | | 632 | | -Type: initiator | | | | -Type: target | | 633 | | | | | | | | 634 | +-------------------+ | | +------------------+ | 635 | | | | 636 | NETWORK ENTITY | | NETWORK ENTITY | 637 | -Entity ID (DNS): | | -Entity ID (DNS): | 638 | "strg1.foo.com" | | "strg2.bar.com" | 639 | -Type: iSCSI | | -Type: iSCSI | 640 | | | | 641 +-------------------------+ +-------------------------+ 643 A ZONE contains one or more NETWORK ENTITY objects. Each NETWORK ENTITY 644 object contains one or more PORTAL objects, and one or more STORAGE NODE 645 objects. 647 5.4 SNS Message Format Requirements 649 The SNS protocol SHALL use a flexible and extensible message format such as 650 TLV (TLV is already used in many networking protocols such as DHCP). The SNS 651 protocol shall allow manipulation of multiple objects and attributes in the SNS 652 server through a single message and response. 654 5.5 SNS Authentication Requirements 656 The SNS protocol SHALL include optional authentication of SNS protocol 657 messages from SNS clients. The authentication mechanism will allow for 658 authentication of both client and server. 660 5.6 SNS Query and Registration Services Requirements 661 The SNS protocol allows initiators and targets to register themselves at 662 the SNS server. Initiators and targets can also query the SNS server for 663 information. For example, targets can register themselves at the SNS server, and 664 the initiators can query the SNS server about which targets they can access. 666 During registration, the initiators and the targets must provide the 667 following information: 668 a) Storage Entity ID 669 b) Portal object address (IP address and Port Number) 670 c) WWUI information 671 d) Storage node type 673 They could optionally also provide other information such as: 674 a) Zone related information 675 b) Alias string information 677 When querying address information in order to establish an iSCSI 678 connection, the query, 679 as a minimum, should return the following information: 680 a) Storage Entity IP address 682 The Portal Object IP address can be the same as the Storage Entity IP 683 address, and the Portal Object port number can be the (TBD) default iSCSI port 684 number. Furthermore, the WWUI of the target device can be queried by issuing the 685 SendTarget command to the default canonical iSCSI target present at the IP 686 5.7 State Change Notification Requirements 688 Asynchronous notification (State Change Notifications): The SNS must be 689 able to inform SNS clients of changes to its database, including changes or 690 modifications to zoning or login control policies and the 691 presence or absence of initiators and targets. These changes may occur as a 692 result of various events, including an SNS client actively manipulating changing 693 the SNS database, response or non-response to an 694 SNS heartbeat message, or a hardware interrupt delivered by the SNS host 695 platform (such as a switch). Asynchronous notification shall be delivered only 696 to SNS clients that register for the notification, and only for SNS clients that 697 are in the same Zone as the event. 699 5.8 The SNS protocol SHALL be a lightweight protocol that can be scaled down 700 for implementation on switches and targets, or scaled up for implementation on 701 servers. 703 5.9 The SNS SHALL meet the iSCSI boot requirements (see 704 draft-ietf-ips-iscsi-boot-00.txt). 706 6) Related Work 707 Jini [1], PnP [2] and Internet Server Location Protocol (SLP)[3] are some of the 708 other discovery protocols that are present in the industry. It is important to 709 note that there is no consensus in the industry as to which discovery protocol 710 should be used. Therefore, instead of adopting a specific existing protocol, 711 the NDT team has ensured that the iSCSI discovery mechanism contains the key 712 essential features of the above mentioned discovery protocols. The multicast 713 discovery mechanism, described above, provides iSCSI with the same discovery 714 capabilities as these other discovery protocols. 716 7. Outstanding Work Items 717 The following work items are still outstanding: 718 a) Impact of naming and discovery on iSCSI Login command. 719 b) Secure interaction between the storage director and the initiators 720 and the targets. 722 8. References 723 [1] Edwards, K., "Core Jini: In Depth: Discovery", Prentice Hall, 1999. 725 [2] John, R., "UPnP, Jini and Salutation- A look at some popular coordination 726 frameworks for future networked devices", 727 http://www.cswl.com/whiteppr/tech/upnp.html", June 17, 1999. 729 [3] http://www.srvloc.org 731 [4] Freed, N., "Behavior of and Requirements for Internet Firewalls", 732 RFC 2979, October 2000. 734 [5] ANSI/IEEE Std 802-1990, Name: IEEE Standards for Local and 735 Metropolitan Area Networks: Overview and Architecture 736 and Utilities", RFC 2151, June 1997. 738 [7] Satran, J., Sapuntzakis, C., Wakeley, M., Von Stamwitz, P., Haagens, 739 R., Zeidner, E., Dalle Ore, L., Klein, Y., "iSCSI", 740 draft-ietf-ips-iscsi-00.txt, November, 2000. 742 [8] Gibbons, K., Tseng, J. and Monia, C., "iSNS Internet Storage Name 743 Service", draft-tseng-ips-isns-00.txt, October 2000. 745 6. Contact Author 746 Kaladhar Voruganti 747 650 Harry Road 748 IBM Almaden Research 749 San Jose, CA 750 USA 751 Email: kaladhar@us.ibm.com 753 Voruganti Internet Draft Expires July 2001 755 iSCSI Naming and Discovery January 2001 757 "Copyright (C) The Internet Society (date). All Rights Reserved. This 758 document and translations of it may be copied and furnished to others, 759 and derivative works that comment on or otherwise explain it or assist 760 in its implementation may be prepared, copied, published and distributed, 761 in whole or in part, without restriction of any kind, provided that the 762 above copyright notice and this paragraph are included on all such 763 copies and derivative works. However, this document itself may not be 764 modified in any way, Full Copyright Statement 765 such as by removing the copyright notice or references to the 766 Internet Society or other Internet organizations, except as needed for 767 the purpose of developing Internet standards in which case the 768 procedures for copyrights defined in the Internet Standards process must 769 be followed, or as required to translate it into languages other than 770 English. 772 The limited permissions granted above are perpetual and will not be 773 revoked by the Internet Society or its successors or assigns. 775 This document and the information contained herein is provided on an 776 "As IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 777 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED , INCLUDING 778 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 779 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF