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