idnits 2.17.1 draft-tseng-ips-isns-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: ---------------------------------------------------------------------------- ** 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 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 1651 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 233 has weird spacing: '...arantee consi...' == Line 760 has weird spacing: '...ificate vari...' == Line 927 has weird spacing: '...rovided bit 3...' -- 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 (October 2000) is 8592 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? '1' on line 1136 looks like a reference -- Missing reference section? '2' on line 1138 looks like a reference -- Missing reference section? 'RFC 1035' on line 189 looks like a reference -- Missing reference section? '802-1990' on line 1562 looks like a reference -- Missing reference section? 'DSS' on line 1559 looks like a reference -- Missing reference section? 'FC-GS-3' on line 1554 looks like a reference -- Missing reference section? '3' on line 1140 looks like a reference -- Missing reference section? '1-21' on line 1170 looks like a reference -- Missing reference section? '101-106' on line 1178 looks like a reference -- Missing reference section? 'RFC1035' on line 1550 looks like a reference -- Missing reference section? 'STD0035' on line 1551 looks like a reference -- Missing reference section? 'RFC2065' on line 1552 looks like a reference -- Missing reference section? 'FC-GS-2' on line 1553 looks like a reference -- Missing reference section? 'RFC2609' on line 1556 looks like a reference -- Missing reference section? 'IEEE802.1Q' on line 1557 looks like a reference -- Missing reference section? 'RFC1510' on line 1558 looks like a reference -- Missing reference section? 'SPC' on line 1565 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 19 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft K. Gibbons 2 J. Tseng 3 Expires April 2001 C. Monia 4 Nishan Systems 6 October 2000 8 iSNS Internet Storage Name Service 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Comments 32 Comments should be sent to the ips mailing list (ips@ece.cmu.edu) 33 or to the authors. 35 1. Abstract 37 The Internet Storage Name Service (iSNS) provides a generic 38 framework for configuring and managing various storage entities and 39 their usage attributes in an IP-based storage network. iSNS 40 integrates Fibre Channel name server and DNS mechanisms into a 41 common naming and resource-discovery framework. The iSNS Protocol 42 (iSNSP) defines how entities communicate with the iSNS server to 43 discover and utilize available networked storage resources. The 44 iSNS server MAY be supported by a consolidated iSNS directory 45 database, which serves as a repository to store information about 46 various storage resources, providing easy access to topology 47 information for storage entities. 49 2. Conventions used in this document 51 iSNS refers to the framework consisting of the storage network 52 model and associated services. 54 Gibbons, Tseng, Monia 2 56 iSNS October 2000 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 60 this document are to be interpreted as described in RFC-2119 [2]. 62 3. iSNS Overview 64 IP network entities use the Domain Name System (DNS) to resolve 65 mappings of DNS names to IP addresses. Fibre Channel-based storage 66 entities use a Storage Name Server (SNS) to discover other storage 67 entities and their addressing information. The iSNSP provides a 68 common framework to supply both DNS and SNS services for all 69 storage entities. 71 Although the DNS and SNS infrastructures MAY be managed separately, 72 nevertheless they must provide consistent naming and addressing 73 information to both IP-based and Fibre Channel-based storage 74 entities. The iSNS Protocol (iSNSP) provides a common framework 75 for integration of these naming services for both IP and Fibre 76 Channel-based storage entities. 78 This framework builds upon the association of IP and Fibre Channel 79 objects, and the resulting consistency guarantees among these 80 objects. Regardless of the underlying implementation, the framework 81 presents the illusion of common IP and Fibre Channel objects. . 82 Some attributes of these database objects may be applicable to 83 Fibre Channel-based entities, while other attributes may be 84 applicable only to IP-based iSCSI entities. Still other attributes 85 such as World Wide Port Name may be used by both Fibre Channel and 86 iSCSI entities. Values stored as attributes for both iSCSI and 87 Fibre Channel devices SHALL be consistent regardless of whether 88 they are accessed for use by iSCSI or Fibre Channel devices. The 89 consistency guarantee MAY be implemented through a consolidated 90 information base. 92 Gibbons, Tseng, Monia 3 94 iSNS October 2000 96 The following diagram shows an example of Fibre Channel clients and IP 97 clients accessing SNS and DNS data via iSNS server and DNS server: 99 +------------+ +-----------+ +-----------+ 100 | | LDAP | Directory | LDAP | iSNS | 101 | DNS Server |<-------->| Database |<-------->| Server | 102 | | | | | | 103 +------+-----+ +-----+-----+ +-----+-----+ 104 | | | 105 | DNS | LDAP iSNSP | 106 |Queries | | 107 +------+----------------------+----------------------+-----+ 108 | | 109 | IP Network | 110 | | 111 +------+----------------------+----------------------+-----+ 112 | | | 113 | +-------+------+ | 114 | | FC-IP / | | 115 | |Gateway /iSNS | | 116 | | Proxy /Server| | 117 | +-------+------+ | 118 | | | 119 +----+----+ +----+----+ +----+----+ 120 | iSCSI | | Fibre | | iSCSI | 121 |Initiator| | Channel | | Target | 122 | | | Network | | | 123 +---------+ +---------+ +---------+ 124 iSNS Client Entities 126 In the above example, each iSNS Client Entity has its attributes 127 committed to the directory database, regardless of whether the 128 client is a Fibre Channel entity, or an IP-based entity. 130 A DNS server receiving a DNS resolve request can use the directory 131 database to resolve DNS names to IP addresses. Changes to DNS name 132 mappings due to DNS Zone transfers and other DNS protocol events 133 will be reflected directory update messages to the database, and 134 consistently reflected in subsequent iSNSP queries and SCN's. 136 The iSNS server may be a standalone entity, or it may be integrated 137 into another network entity such as a Fibre Channel-iSCSI gateway 138 proxy device. The iSNS directory database may be cohosted with the 139 iSNS server, or it may be a separate infrastructure based on 140 distributed directory database services such as LDAP. 142 3.1 iSNS Functional Components 144 Gibbons, Tseng, Monia 4 146 iSNS October 2000 148 There are four functional components required by devices operating 149 in a IP-based storage network: 151 1) A Name Service Providing Storage Resource Discovery 152 2) State Change Notification Service 153 3) Network Zoning Service 154 4) Domain Name System (DNS) Service (see RFC 1035) 156 3.1.1 Name Registration Service 158 The iSNS provides a registration function to allow all entities in 159 a storage network to register and query the directory. This allows 160 an iSNS client initiator to obtain information about iSNS client 161 target devices from the iSNS server. This service is modeled on the 162 Fiber Channel Name Services described in FC-GS-2, with extensions, 163 operating within the context of an IP network. 165 3.1.2 State Change Notification Service 167 The State Change Notification service provides functionality for 168 issuing notifications about network events that may affect the 169 operational state of iSNS entities. The State Change Notification 170 service gives an iSNS client the ability to register for 171 notification of events detected or received by the iSNS server from 172 an iSNS client entity. This service provides the Fiber Channel 173 State Change Notification service, with extensions, operating 174 within the context of an IP network. 176 3.1.3 Network Zoning Service 178 The Network Zoning Service implements the functionality to support 179 grouping of iSNS client devices into domains for administrative and 180 access control purposes. Devices must be in common zones in order 181 to "see" each other and communicate through the network. Devices 182 can be a member of multiple zones simultaneously. 184 3.1.4 DNS Name Service 186 The iSNS framework unifies the above storage services used in Fibre 187 Channel with the Domain Name System (DNS) service in IP-based 188 networks. A detailed description of the Domain Name System (DNS) 189 protocol is found in [RFC 1035], and is beyond the scope of this 190 document. In the iSNS framework, the DNS host names can be given to 191 storage controllers, HBA's, gateways, and iSCSI NICs. To create a 192 unified iSNS framework, DNS naming features now coexist with 193 storage concepts such as World Wide Names (WWN's). For example, 194 WWN's can now be used as a key in an iSNS query to discover the DNS 195 Name and Path of a particular storage device. Similarly, the iSNS 196 directory database can be used to support queries by DNS resolvers. 198 Gibbons, Tseng, Monia 5 200 iSNS October 2000 202 3.2 iSNS Architectural Components 204 3.2.1 iSNS Client 206 Entities which initiate transactions using the iSNS protocol will 207 hereafter be referred to as iSNS clients. iSNS clients register 208 their attribute information in the iSNS server through use of the 209 iSNS protocol. 211 3.2.2 iSNS Server 213 The iSNS server resides at an IP address in the network, and 214 responds to TCP and UDP-based iSNSP messages at a TBD port. It may 215 be implemented on a stand-alone host computer or network management 216 station, or integrated into one or more switches in the network. 217 Administration of the iSNS server is similar to established 218 processes for administering DNS servers. The primary functional 219 difference between the iSNS and classical DNS is the ability for 220 client entities to write information to the server database using 221 the iSNSP. 223 The iSNS server responds to iSNS and DNS protocol queries and 224 requests, and initiates iSNS protocol State Change Notifications. 225 Properly authenticated registration request information is stored 226 in an internal or external database. 228 3.2.3 iSNS Directory Database 230 The iSNS database is a repository for the iSNS server(s) and DNS 231 server(s) to store information about DNS Names, IP Addresses, Fibre 232 Channel storage attributes (WWNN, Port ID, etc...), and iSCSI 233 storage attributes. The database SHALL guarantee consistency 234 between data stored and retrieved by iSNS server(s) and DNS 235 server(s). This database MAY be implemented using a distributed 236 directory database such as LDAP, and MAY be implemented using a 237 single common database for both iSNS servers and DNS servers. 239 3.2.4 World Wide Name (WWN) Identifiers 241 iSNS client entities use a set of identifiers to uniquely identify 242 the device (Node) and each network interface (Port) associated with 243 the device. A unique 64-bit World Wide Name (WWN) is assigned to 244 each node and each port on the device. The three WWN types are 245 Node Name (WWNN), Port Name (WWPN), and Fabric Port Name (FWWN). 246 These globally unique identifiers are used during the device 247 registration process, and are assigned values conforming to IEEE 248 Naming Assignment Authority (NAA) type 1, 2, 5, or 6. This format 249 is found in ANSI/IEEE Std 802-1990 [802-1990]. 251 Editor's note: iSCSI naming conventions are TBD by IPS working 252 group. 254 Gibbons, Tseng, Monia 6 256 iSNS October 2000 258 3.2.5 IP Address 260 The IP address is used to identify a network interface of an IP 261 storage gateway or native device in an IP network. 263 3.2.6 DNS Name 265 A DNS Name is assigned to a network node having one or more storage 266 devices. Each IP storage device is distinguished by the Path 267 field. The DNS Name uses a hierarchical name space consisting of 268 one or more labels, each of at most 63 characters. A period is 269 used to separate the labels. The iSNS uses a fully qualified 270 domain name consisting of up to 255 characters. Each Domain Name 271 maps to an IP Address. More information about the DNS Domain Name 272 can be found in RFC 1035. 274 3.3 Compatible Naming Convention Example 276 The above components of the iSNS architectural framework support 277 the use of Fibre Channel naming conventions as well as the URL 278 convention common in IP networking. The framework allows iSCSI 279 naming conventions to be mapped to naming conventions used in Fibre 280 Channel. For example, the following URL format can be implemented 281 and translated to the Fibre Channel naming convention through use 282 of the iSNS server: 284 iscsi://server1.nishansystems.com/device3?WWPN=c2ae3253f3 286 The iSCSI client parsing this URL would submit an iSNSP query to 287 the iSNS server, using the keys DNS Name = 288 "server1.nishansystems.com", Path = "device3" and WWPN = 289 "c2ae3253f3". The iSNS directory database would retrieve the 290 attribute IP Address = ww.xx.yy.zz as the proxy IP gateway address 291 to the Fibre Channel fabric. DevGetNext queries to the iSNS server 292 will allow the iSCSI client to further discover additional targets 293 in the Fibre Channel fabric by returning their WWPN's. 295 3.4 iSNS Applicability 297 iSNSP functions in networks under cooperative administrative 298 control. Such networks permit a policy to be implemented regarding 299 security, multicast routing, and organization of services and 300 clients into groups. Through leveraging of an Internet-based 301 distributed database framework such as LDAP, iSNS functionality can 302 be broadly extended to the Public Internet. Additionally, the iSNS 303 framework leverages existing DNS mechanisms, where zone transfer of 304 domain information may take place from upstream authorities in the 305 DNS hierarchy. 307 Gibbons, Tseng, Monia 7 309 iSNS October 2000 311 The iSNSP provides a common framework for providing the above 312 services for IP-based storage devices such as native iSCSI storage 313 products, as well as FCP-based devices such as existing Fibre 314 Channel storage devices. 316 4. iSCSI/Fibre Channel Database Objects 318 iSNS provides the framework for archiving and retrieval of topology 319 information of iSCSI and Fibre Channel-based storage devices. This 320 architecture defines objects which represent storage entity 321 components in both Fibre Channel and IP-based storage devices. 323 The following architecture framework includes all elements needed 324 to describe both iSCSI-based and FCP-based (Fibre Channel) storage 325 device attributes in the iSNS directory database. Existing Fibre 326 Channel storage resources can now be described to iSCSI-based iSNS 327 clients for access through a proxy iSCSI/Fibre Channel gateway. 329 Four object entities are defined in this architecture framework. 330 They are IP STORAGE NODE, STORAGE ENTITY, ZONE and STORAGE PORT. 331 Each of these objects are defined in sections 4.1, 4.2, 4.3, and 332 4.4. 334 The following diagram shows how database objects are used to 335 represent storage components (with the exception of Zones). Each 336 object has a set of attributes described in section 5., which may 337 be applicable in either a iSCSI or Fibre Channel network, or both. 338 Objects are denoted in all CAPITAL letters. 340 Gibbons, Tseng, Monia 8 342 iSNS October 2000 344 +----------------------------------------------------------------+ 345 | IP Network | 346 +--------------------+---------------------+---------------------+ 347 | | 348 IP Address 1 o o IP Address 2 349 | | 350 +--------------------|---------------------|---------------------+ 351 | | | | 352 | +----------------+---------------------+-----------------+ | 353 | | Service Delivery Subsystem (FC or internal dev bus) | | 354 | +--------+ +---------------------+ +-----------+ +-------+ | 355 | | | | | | | | 356 | | | | | | | | 357 | +--------+ +-------+ +-----+ +-----------+ +-------+ | 358 | | |STORAGE| | | |STORAGE| |STORAGE| | | 359 | | | PORT | | | | PORT | | PORT | | | 360 | | +-------+ | | +-------+ +-------+ | | 361 | | | | | | 362 | | | | 000000000000000000000 | | 363 | | | | Logical Units | | 364 | | | | | | 365 | | initiator | | target | | 366 | | STORAGE ENTITY | | STORAGE ENTITY | | 367 | +------------------+ +-----------------------------+ | 368 | | 369 | IP STORAGE NODE | 370 +----------------------------------------------------------------+ 372 4.1 IP Storage Node Object 374 The IP Storage Node object defines an IP endpoint node that 375 originates or terminates a TCP/IP connection. An IP End Node may 376 contain one or more Storage Entity objects. This object may be 377 used to define a native iSCSI storage device, iSCSI NIC, a Fibre 378 Channel-iSCSI gateway, or any other storage device with an IP 379 address. In the case of a Fibre Channel to IP gateway, the IP 380 storage node object may support one or more native Fibre Channel 381 storage devices. One or more IP address attribute values may be 382 assigned to an IP Storage Node object entity. 384 The following are attributes of the IP Storage Node object. Each 385 attribute is described in more detail in section 5.4. 386 Applicability indicates whether the attribute is used by an iSCSI 387 device or a Fibre Channel device, or both. A gateway device will 388 need to support both iSCSI and Fibre Channel attributes. 390 The following attributes are described in more detail in sections 391 5.4. 393 The Key Attribute column indicates the attribute is a search key 394 used to query the database. 396 Gibbons, Tseng, Monia 9 398 iSNS October 2000 400 Applicability 401 Attribute iSCSI Fibre Channel Key Attribute 402 --------- ----- ------------- ------------- 403 IP Address * * 404 Management IP Address * * 405 DNS Name * * 406 Client Certificate 407 Port Number 409 4.2 Storage Entity Object 411 The Storage Entity object defines an individual storage initiator 412 or target. This entity may be a RAID device, a Fibre Channel HBA, 413 or other individual storage device. The Storage Entity may have 414 one or more Storage Port objects. 416 The following are attributes of the Storage Entity object. Each 417 attribute is described in more detail in section 5.4. Applicability 418 indicates whether the attribute is used by an iSCSI device or a 419 Fibre Channel device, or both. A gateway device will need to 420 support both iSCSI and Fibre Channel attributes. 422 The following attributes are described in more detail in sections 423 5.4. 425 Applicability 426 Attribute iSCSI Fibre Channel Key Attribute 427 --------- ----- ------------- ------------- 428 Node Name * * 429 Node Symbolic Name * 430 FC Node IPA * 431 Node Type * * 433 4.3 Zone Object 435 Zoning is a security and management mechanism used to partition 436 storage resources. Zoning prevents initiators from potentially 437 logging in to every possible target during device discovery. When 438 queried, the iSNS server will only provide information on storage 439 entities in a common zone. Initiators will thus not be able to 440 "see" devices that are not in a common zone. 442 A Zone entity contains one or more Storage Ports. Storage Ports 443 that are in the same Zone entity can "see" each other, and can thus 444 communicate without restrictions. 446 The following are attributes of the Zone object. Each attribute is 447 described in more detail in section 5.4. Applicability indicates 448 whether the attribute is used by an iSCSI device or a Fibre Channel 449 device, or both. A gateway device will need to support both iSCSI 450 and Fibre Channel attributes. 452 Gibbons, Tseng, Monia 10 454 iSNS October 2000 456 The following attributes are described in more detail in sections 457 5.4. 459 Applicability 460 Attribute iSCSI Fibre Channel Key Attribute 461 --------- ----- ------------- ------------- 462 Zone ID * * * 463 Zone Tag * * * 464 Zone Symbolic Name * * 465 Zone Member (WWPN) * * 466 Zone Member (IP Address) * 467 Zone Member Priority * * 469 4.4 Storage Port Object 471 The Storage Port object defines an individual service delivery port 472 that services a Storage Entity. The Storage Port provides the 473 interconnect between the Storage Entity and its Logical Units with 474 the Service Delivery Subsystem. The Service Delivery Subsytem may 475 be a Fibre Channel interconnect, or an internal device bus, 476 depending on the specific type of Storage Entity being supported by 477 the Storage Port. A Storage Port may be a member of one or more 478 Zone entities. 480 The following attributes are described in more detail in sections 481 5.4. 483 Applicability 484 Attribute iSCSI Fibre Channel Key Attribute 485 --------- ----- ------------- ------------- 486 Port Name (WWPN) * * * 487 FC Hard Address * 488 Fabric Port Name (FWWN) * * 489 Port_ID * 490 Port_Symbolic Name * 491 Port_Type * * 492 FC Class of Service * 493 FC Port IP Address * 494 Path * 496 5. iSNS Message Protocol 498 The following describes the format of the iSNS Protocol: 500 Gibbons, Tseng, Monia 11 502 iSNS October 2000 504 Byte MSb LSb 505 Offset 7 6 5 4 3 2 1 0 506 +----------------------------------+ 507 0 | iSNSP VERSION | 2 Bytes 508 +----------------------------------+ 509 2 | FUNCTION ID | 2 Bytes 510 +----------------------------------+ 511 4 | MESSAGE LENGTH | 2 Bytes 512 +----------------------------------+ 513 6 | FLAGS | 2 Bytes 514 +----------------------------------+ 515 8 | TRANSACTION ID | 2 Bytes 516 +----------------------------------+ 517 10 | MESSAGE PAYLOAD | N Bytes 518 +----------------------------------+ 519 10 + N | AUTHENTICATION BLOCK (if present)| L Bytes 520 +----------------------------------+ 521 Total Length = 10 + N + L 523 5.1 iSNS Message Header 525 The iSNSP header contains the iSNSP VERSION, FUNCTION ID, MESSAGE 526 LENGTH, FLAGS, and TRANSACTION ID fields as defined below: 528 iSNSP VERSION - Currently 0x0001 530 FUNCTION ID defines the type of iSNS message. It contains a value 531 as defined in the "ID" column in the tables below. The following 532 messages are iSNSP request messages: 534 Message Description Abbreviation Func ID Support 535 ------------------- ------------ ------- ------- 536 Register Device Attribute Req RegDevAttr 0x0001 Required 537 Device Attribute Query Request DevAttrQry 0x0002 Required 538 Device Get Next Request DevGetNext 0x0003 Optional 539 Deregister Device Request DeregDev 0x0004 Required 540 SCN Register Request SCNReg 0x0005 Required 541 State Change Notification SCN 0x0006 Required 542 Register Zone RegZone 0x0007 Required 543 Deregister Zone DeregZone 0x0008 Required 544 Register Device in Zone RegDevZone 0x0009 Required 545 Deregister Device in Zone DeregDevZone 0x000A Required 546 Port Status Inquiry PSI 0x000B Optional 547 PSI Update PSIUpdate 0x000C Optional 548 Name Service Heartbeat Heartbeat 0x000D Required 549 RESERVED 0x0000-8000 551 The following are iSNSP response messages: 553 Gibbons, Tseng, Monia 12 555 iSNS October 2000 557 Response Message Description Abbreviation Func_ID Support 558 ---------------------------- ------------ ------- ------- 559 Register Device Attribute RegDevRsp 0x8001 Required 560 Device Attribute Query Response DevAttrQryRsp 0x8002 Required 561 Device Get Next Response DevGetNextRsp 0x8003 Optional 562 Deregister Device Response DeregDevRsp 0x8004 Required 563 SCN Register Response SCNRegRsp 0x8005 Required 564 Register Zone Response RegZoneRsp 0x8006 Required 565 Deregister Zone Response DeregZoneRsp 0x8007 Required 566 Register Device in Zone Response RegDevZoneRsp 0x8008 Required 567 Deregister Device in Zone Resp DeregDevZoneRsp 0x8009 Required 568 RESERVED 0x800A-FFFF 570 iSNS MESSAGE LENGTH - Specifies the length of the MESSAGE PAYLOAD 571 field in bytes. 573 FLAGS - Indicates additional information about the message and the 574 type of iSNS entity that generated the message. The following 575 table displays the valid flags: 577 Bit Field Flag 578 --------- ---- 579 0-12 RESERVED 580 13 Authentication Block Present 581 14 Sender is the iSNS server 582 15 Sender is the iSNS client 584 TRANSACTION ID - Is set to a unique value for each request message. 585 Replies must use the same TRANSACTION ID value as the associated 586 iSNS request message. If a message is retransmitted, the same 587 TRANSACTION ID value must be used. 589 5.2 iSNS Message Payload 591 The MESSAGE PAYLOAD is of variable length and contains attributes 592 used for registration and query operations. Each iSNS attribute is 593 specified in the iSNSP message payload using Tag-Length-Value (TLV) 594 format, as shown below: 596 +----------+----------+-------------------+ 597 | attr_id | attr_len | attr_val | 598 +----------+----------+-------------------+ 600 attr_id (ID) - a 2-byte field that identifies the attribute as 601 defined in section 5.4. This field contains the ID of the 602 indicated attribute. 604 attr_len (Length) - a 2-byte field that indicates the length, in 605 bytes, of the attribute value to follow. 607 Gibbons, Tseng, Monia 13 609 iSNS October 2000 611 attr_val (Value) - a variable-length field containing the attribute 612 value. 614 The above format is used to identify each attribute in the iSNS 615 message payload. Each iSNSP request message contains several 616 attributes in the above format to identify the requesting iSNS 617 client and register or query for attribute values in the iSNS 618 server. 620 For iSNS response messages sent by the iSNS server to the client, a 621 4-byte ERROR CODE field is prepended to the MESSAGE PAYLOAD. This 622 field contains 0x0000 (NO ERROR) if the original iSNSP request 623 message was processed normally by the iSNS server. Error codes are 624 described in the following table: 626 Error Code Error Description 627 ---------- ----------------- 628 0 No Error 629 1 Unknown Error 630 2 Format Error 631 3 Invalid Registration 632 4 Scope Not Supported 633 5 Authentication Unknown 634 6 Authentication Absent 635 7 Authentication Failed 636 8 Entry Requested Not Found 637 9 Version Not Supported 638 10 Internal Bus Error 639 11 Busy Now 640 12 Option Not Understood 641 13 Invalid Update 642 14 Message Not Supported 643 15 Refresh Rejected 645 5.3 Message Authentication 647 iSNSP provides an optional message authentication capability. 648 Network interactions using iSNSP occur in short transactions, and 649 are generally not sesion based. The iSNS client connects to the 650 iSNS server only when information needs to be registered or 651 queried. 653 Public Key Encryption MAY be used for message authentication. If a 654 public key infrastructure is not available, a shared secret 655 algorithm MAY alternatively be used. A shared secret mechanism may 656 leverage a Kerberos server, or may involve manual distribution of a 657 private key to the iSNS server and each iSNS client. 659 If a PKI is available with an X.509 certificate authority, then 660 public key authentication of clients is possible. The 662 Gibbons, Tseng, Monia 14 664 iSNS October 2000 666 authentication block leverages the DSA with SHA-1 algorithm, which 667 can easily integrate into a public key infrastructure. 669 The SNSP optional authentication block is a digital signature for 670 the message. The authentication block contains the following 671 information: 673 1. A time stamp, to prevent replay attacks 674 2. A structured authenticator containing a signature calculated 675 over the time stamp and the message being secured 676 3. An indicator of the cryptographic algorithm that was used to 677 calculate the signature. 678 4. An indicator of the keying material and algorithm parameters, 679 used to calculate the signature. 681 The authentication block is described in the following figure: 683 Byte MSb LSb 684 Offset 7 6 5 4 3 2 1 0 685 +----------------------------------+ 686 0 | BLOCK STRUCTURE DESCRIPTOR | 2 Bytes 687 +----------------------------------+ 688 2 | AUTHENTICATION BLOCK LENGTH | 2 Bytes 689 +----------------------------------+ 690 4 | TIMESTAMP | 4 Bytes 691 +----------------------------------+ 692 8 | SPI STRING LENGTH | 1 Byte 693 +----------------------------------+ 694 9 | SPI STRING | N Bytes 695 +----------------------------------+ 696 9 + N | STRUCTURED AUTHENTICATOR | M Bytes 697 +----------------------------------+ 698 Total Length = 9 + N + M 700 BLOCK STRUCTURE DESCRIPTOR (BSD) - Defines the structure and 701 algorithm to use for the STRUCTURED AUTHENTICATOR. Currently, the 702 only defined value for BSD is 0x0002, which represents DSA with 703 SHA-1. Details on DSA can be found in [DSS]. BSD values from 704 0x0000 to 0x7FFF are assigned by IANA, while 0x8000 to 0x8FFF are 705 for private use. The BSD value 0x0002 is compatible with the X.509 706 PKI specification, allowing easy integration of the STRUCTURED 707 AUTHENTICATOR format with an existing PKI infrastructure. 709 AUTHENTICATION BLOCK LENGTH - Defines the length of the 710 authentication block, beginning with the BSD field and running 711 through the last byte of the STRUCTURED AUTHENTICATOR. 713 TIMESTAMP - This is a 4-byte unsigned, fixed-point integer giving 714 the number of seconds since midnight, January 1, 1970. 716 SPI STRING LENGTH - The length of the SPI STRING field. 718 Gibbons, Tseng, Monia 15 720 iSNS October 2000 722 SPI STRING (Security Parameters Index) - Index to the key and 723 algorithm used by the message recipient to decode the STRUCTURED 724 AUTHENTICATOR field. 726 STRUCTURED AUTHENTICATOR - Contains the digital signature. For the 727 default BSD value of 0x0002, this field contains the binary ASN.1 728 encoding of output values from the DSA with SHA-1 signature 729 calculation. 731 5.4 iSNS Client Registration Attributes 733 When an iSNS client registers with the iSNS server, it provides 734 attribute values to describe the entity characteristics and 735 capabilities. The attributes are also returned by the iSNS server 736 in response to queries. The following table lists all iSNSP 737 message attributes for device registration and queries: 739 Attribute Name Size(bytes) ID Reg Key Query Key 740 -------------- ----------- -- ------- --------- 741 Node Name (WWNN) 8 1 1 1,4, 9&10 or 18&19 742 Node Symbolic Name 0-255 2 1 1,4, 9&10 or 18&19 743 Management IP Address 16 3 1 1,4, 9&10 or 18&19 744 Port Name (WWPN) 8 4 1 1 or 9&10 745 FC Node IPA 8 5 1 1,4 or 9&10 746 FC Hard Address 3 6 1 1,4 or 9&10 747 Fabric Port Name (FWWN) 8 7 1 1,4 or 9&10 748 Node Type 2 8 1 1,4 or 9&10 749 IP Address 16 9 4 1,4 or 19 750 Port ID 3 10 4 4 751 Port Symbolic Name 0-255 11 4 4 or 9&10 752 Port Type 2 12 4 4 or 9&10 753 FC Class of Service 4 13 4 4 or 9&10 754 FC Port IP Address 16 14 4 4 or 9&10 755 FC-4 Types 32 15 4 4 or 9&10 756 Port Reg Timestamp 8 16 4 4 or 9&10 757 Transport Protocol 2 17 4 4 or 9&10 758 DNS Name 0-255 18 1 or 9 1,4 or 9&10 759 Path 0-255 19 1 or 9 1,4 or 9&10 760 Client Certificate variable 20 1 1,4, 9&10 or 18&19 761 Port Number 2 21 4 4 or 9&10 763 The following is a description of the columns used in the above 764 table: 766 Size - indicates the attribute length. Variable-length identifiers 767 are NULL character terminated, which is included in the length. 769 ID - the value used to identify the attribute. 771 Gibbons, Tseng, Monia 16 773 iSNS October 2000 775 Registration Key - indicates the attribute ID that is the unique 776 key used for attribute registration. This attribute is also known 777 as the primary key for the iSNS directory database entry. 779 Query Key - indicates the attribute ID(s) that is (are) the unique 780 key used to query the iSNS directory database. 782 iSNS client attributes are defined below: 784 5.4.1 Node Name (WWNN) 786 Node Name is a 64-bit identifier that uniquely identifies the 787 device node in the network. This required field is provided by the 788 iSNS client entity. The format of the Node Name (WWNN) is as 789 defined in section 3.2.4. 791 5.4.2 Node Symbolic Name 793 This is a variable-length text-based description of up to 255 794 bytes, that is associated with the device node in the network. The 795 text field contains user-readable ASCII text and is terminated with 796 at least one NULL character. This optional field is normally 797 provided by the iSNS client during registration. However, a 798 network management application can update this field as required. 799 The Node Symbolic Name provides a user-readable description of the 800 device entry in the iSNS. The use of the Node Symbolic Name is 801 consistent with Fibre Channel. 803 5.4.3 Management IP Address 805 This optional field is provided by the iSNS client. It contains 806 the IP Address used to manage the node. The Management IP Address 807 is a 16-byte field that may contain either a 32-bit IPv4 or 128-bit 808 IPv6 address. When this field contains an IPv4 value, the most 809 significant 12 bytes are set to 0x00. 811 5.4.4 Port Name (WWPN) 813 This 64-bit identifier uniquely defines the device port. This 814 required field is provided by the iSNS client entity. The format 815 of the Port Name (WWPN) is defined in section 3.2.4. 817 5.4.5 FC Node Initial Process Associator 819 This optional field is included for compatibility with Fibre 820 Channel, and is provided by the iSNS client entity. The initial 821 process associator can be used for communication between Fibre 822 Channel devices. 824 5.4.6 FC Hard Address 826 Gibbons, Tseng, Monia 17 828 iSNS October 2000 830 This optional is the 24-bit NL Port Identifier, included in the 831 iSNSP for compatibility with Fibre Channel Arbitrated Loop devices 832 and topologies. 834 5.4.7 Fabric Port Name (FWWN) 836 This 64-bit identifier uniquely defines the fabric port. If the 837 iSNS client is attached to a fabric port with a registered Port 838 Name, then that fabric Port Name shall be indicated in this field. 839 This field is included in the iSNSP for compatibility with Fibre 840 Channel fabric devices and topologies. 842 5.4.8 Node Type 844 This 16-bit field is a bitmap indicating the type of node. The 845 fields are defined as below. An enabled bit indicates the node has 846 the corresponding characteristics. 848 Bit Field Node Type 849 --------- --------- 850 0 (Lsb) Target 851 1 Initiator 852 2 Proxy 853 3 Switch 854 All Others RESERVED 856 This field will be consistent with the FC-4 Feature bits described 857 in [FC-GS-3] if the node represents a Fibre Channel device. The 858 default value for this field is 0x0000, which is "unknown". 860 5.4.9 IP Address 862 This is the IP address associated with a device port in the 863 network. This required field is provided by the iSNS client. When 864 an IPv4 value is contained in this field, the most significant 12 865 bytes are set to 0x00. 867 5.4.10 Port ID 869 Along with the IP Address, this field uniquely identifies a native 870 Fibre Channel device port in the network, and maps one-to-one to a 871 specific Port Name (WWPN) entry. The Port ID is only used for 872 native Fibre Channel storage devices, and is unused for native IP- 873 based storage devices. 875 5.4.11 Port Symbolic Name 877 A variable-length text-based description of up to 256 bytes, that 878 is associated with the iSNS-registered device port in the network. 879 The text field contains user-readable ASCII text and is terminated 880 with at least one NULL character. This optional field is normally 882 Gibbons, Tseng, Monia 18 884 iSNS October 2000 886 provided by the iSNS client during registration. However, network 887 management application can update this field as required. The use 888 of the Symbolic Name provides the user with a readable description 889 of the port entry in the iSNS directory database. 891 5.4.12 Port Type 893 Indicates the type of device port. This is provided by the iSNS 894 client entity. Encoded values for this field are listed in the 895 following table: 897 Type Description 898 ---- ----------- 899 0x0000 Unidentified/Null Entry 900 0x0001 Fibre Channel N_Port 901 0x0002 Fibre Channel NL_Port 902 0x0003 Fibre Channel F/NL_Port 903 0x0004-0080 RESERVED 904 0x0081 Fibre Channel F_Port 905 0x0082 Fibre Channel FL_Port 906 0x0083 RESERVED 907 0x0084 Fibre Channel E_Port 908 0x0085-00FF RESERVED 909 0xFF10 iSCSI Port 910 0xFF11 RESERVED (for mFCP Port*) 911 0xFF12 RESERVED (for iFCP Port*) 912 0xFF13-FFFF RESERVED 914 * To be defined later. 916 5.4.13 Class of Service (COS) 918 This is a 32-bit bit-map field that indicates the COS types that 919 are supported by the registered port. This required field is 920 provided by the iSNS client. The COS values are equivalent to 921 Fibre Channel COS values. The valid COS types, and associated bit- 922 map, are listed in the following table: 924 Class of Service Description Bit-Map 925 ---------------- ----------- --------- 926 2 Delivery Confirmation Provided bit 2 set 927 3 Delivery Confirmation Not Provided bit 3 set 928 RESERVED other 930 5.4.14 FC Port IP Address 932 The IP address associated with the device port in the network. 933 This optional field is included for compatibility with Fibre 934 Channel. When an IPv4 value is contained in this field, the most 935 significant 12 bytes are set to 0x00. This value is provided by 936 the iSNS client. 938 Gibbons, Tseng, Monia 19 940 iSNS October 2000 942 5.4.15 FC-4 Types 944 An 8-word bit-map of the FC-4 protocol types supported by the 945 associated port. This required field is provided by the iSNS 946 client. This field can be used to support Fibre Channel devices. 948 5.4.16 Port Registration Timestamp 950 Indicates the time that the most recent device port registration 951 updates occurred. It is the time, in milliseconds, after the 952 standard base time of 00:00:00 GMT on january 1, 1970, that the 953 last update occurred. The timestamp is used to ensure the SNS 954 directory does not contain entries for non-existent port devices. 956 5.4.17 Transport Protocol 958 Contains a bit map that indicates the type of transport protocol 959 that the iSNS client supports for transport of storage traffic. 960 This bit map is indicated below: 962 Bit Field Transport Protocol Supported 963 --------- ---------------------------- 964 0 UDP 965 1 TCP 966 2 SCTP 967 Others RESERVED 969 5.4.18 DNS Name 971 Identifies a node in the IP storage network. The DNS Name, along 972 with the Path, uniquely identify a Node Name (WWNN). It uses 973 existing naming conventions defined in RFC1035. Each DNS Name maps 974 to one IP-addressable node. A node having an IP Address may have 975 more than one storage device. For example, a host at a single IP 976 address may have several device controllers that can be 977 independently addressed by initiators. The Path attribute 978 distinguishes among multiple devices which may reside in an IP- 979 addressable node. 981 5.4.19 Path 983 Along with the DNS Name, the Path uniquely identifies a native IP- 984 based storage device. The Path distinguishes among multiple IP- 985 based storage entities which may reside at the same IP address. 986 Note that the Path is used only with native IP-based storage 987 devices, and native Fibre Channel devices do not need a Path. The 988 Path field is similar to that of the UNIX file format. 990 5.4.20 Client Certificate 992 Gibbons, Tseng, Monia 20 994 iSNS October 2000 996 This optional attribute MAY contain a X.509 certificate with the 997 public key of the iSNS client. This certificate is used by the 998 iSNS client to authenticate itself for storage transfers with other 999 storage entities. Initiators wishing to communicate with a target 1000 storage device MAY retrieve the target's X.509 certificate from the 1001 name server in order to encrypt a secret session key using the 1002 target's public key contained in the certificate. 1004 5.4.21 Port Number 1006 Contains the TCP or UDP port number being used for communication 1007 with the iSNS server by the iSNS client. 1009 5.4 Zone Registration Attributes 1011 iSNS clients can be placed into zoned areas of control. When an 1012 iSNS client or Network Management System registers a zone, it 1013 provides attribute values to describe the zone characteristics and 1014 capabilities. The following table lists the iSNSP zone attributes: 1016 Attribute Name Size(bytes) ID Reg Key Query Key 1017 -------------- ----------- -- ------- --------- 1018 Zone ID 2 101 101 1019 Zone Tag 2 102 101 101 1020 Zone Symbolic Name 1-64 103 101 101 1021 Zone Member (WWN) 8 104 101 101 1022 Zone Member (IP Addr) 16 105 101 101 1023 Zone Member Priority 1 106 101,105,106 101,104,105 1025 Zone ID - a unique identifier used in the iSNS directory database 1026 to indicate the zone. This value is used as the key for any zone 1027 attribute query. 1029 Zone Tag - the tag used to identify the the zone in the network. 1031 Zone Symbolic Name - an ASCII, variable-length string that is 1032 NULL-terminated. This is an optional user-readable field that can 1033 be used to assist a network administrator in tracking the zone 1034 function. 1036 Zone Member (WWPN) - the Port Name of an iSNS client that is a 1037 member of the zone. The zone may have a list of 0 to n members. 1038 Membership is represented by the Port Name of the iSNS client being 1039 listed. 1041 Zone Member (IP Addr) - the IP address of an iSNS client that is a 1042 member of the zone. The zone may have a list of 0 to n members. 1043 This IP address indicates that all storage entities using this IP 1044 address are members of the zone. 1046 Gibbons, Tseng, Monia 21 1048 iSNS October 2000 1050 Zone Member Priority - the 802.1P/Q priority being used for this 1051 zone member in the network. This value can range from 0 to 7, and 1052 is based on valid 802.1P/Q priority tag values. 1054 5.5 State Change Notification and Port Status Inquiry Flags 1056 A State Change Notification (SCN) allows an iSNS client to be 1057 notified of changes within a zone, network, or existing device 1058 attribute values in the iSNS directory database. An iSNS client 1059 registers for SCN's using the SCN Registration Request command. 1060 The SCN message is sent to the iSNS client by the iSNS server. 1062 The types of changes for which an SCN is sent is based on the flags 1063 set in the EVENT TYPE FLAGS field. The EVENT TYPE FLAGS field is a 1064 16-bit mask containing flags for different event types. 1066 Port Status Inquiry (PSI) allows an iSNS server to verify that an 1067 iSNS client port is still connected to the network. The PSI 1068 message is sent to the iSNS client by the server to verify port 1069 status. If enabled, the iSNS server will send a PSI to request a 1070 Port Status Inquiry Update message from the SCE. 1072 The following table displays the flags in the EVENT TYPE FLAGS 1073 field used in SCNReg, SCN and PSI messages: 1075 Bit Field Flag Description 1076 --------- ---------------- 1077 0 CHANGE IN ZONE MEMBERSHIP 1078 1 CHANGE IN NETWORK 1079 2 CHANGE IN DEVICE REGISTRATION PARAMETERS 1080 3 DEVICE ADDED 1081 4 DEVICE REMOVED 1082 5 PORT STATUS UPDATE REQUESTED (for PSI message) 1084 CHANGE IN ZONE MEMBERSHIP - indicates a change has occurred in a 1085 zone that the iSNS client is a member of. A client can be a member 1086 of multiple zones. This flag indicates that a change in 1087 registration parameters or membership has occured, either an 1088 addition or deletion, to a zone that the client is a member of. 1090 CHANGE IN NETWORK - indicates a change in the network has occurred. 1091 The change may be anywhere in the network of devices. This flag is 1092 administratively controlled, and may not be allowed by the iSNS 1093 server except for use by an IP address associated with a Network 1094 Management Station. 1096 CHANGE TO DEVICE REGISTRATION PARAMETERS - indicates a change in a 1097 device registration in the network or zones that the client is a 1098 member of. This flag is used in conjunction with CHANGE IN ZONE 1099 MEMBERSHIP and CHANGE IN NETWORK flags indicate whether the change 1101 Gibbons, Tseng, Monia 22 1103 iSNS October 2000 1105 in device registration occurred in a zone or the network. This 1106 flag may be administratively enabled/disabled. 1108 DEVICE ADDED - indicates a device addition has occurred in the 1109 network or zone. This flag is used in conjunction with CHANGE IN 1110 ZONE MEMBERSHIP and CHANGE IN NETWORK flags indicate whether the 1111 addition occurred in a zone or the network. 1113 DEVICE REMOVED - indicates a device removal has occurred in the 1114 network or zone. This flag is used in conjunction with CHANGE IN 1115 ZONE MEMBERSHIP and CHANGE IN NETWORK flags indicate whether the 1116 removal occurred in a zone or the network. 1118 6. iSNSP Message Descriptions 1120 The message payload follows the iSNSP header described in section 1121 5.1. The request message payload contains a list of attributes, 1122 each in TLV format described in section 5.2. 1124 The iSNSP request message payload contains a list of attributes, 1125 and has the following format: 1127 +----------------------------------------+ 1128 | Source Attribute | 1129 +----------------------------------------+ 1130 | Key Attribute[1] | 1131 +----------------------------------------+ 1132 | Key Attribute[2] (if present) | 1133 +----------------------------------------+ 1134 | . . . | 1135 +----------------------------------------+ 1136 | Op Attribute[1] | 1137 +----------------------------------------+ 1138 | Op Attribute[2] (if present) | 1139 +----------------------------------------+ 1140 | Op Attribute[3] (if present) | 1141 +----------------------------------------+ 1142 | . . . | 1143 +----------------------------------------+ 1145 The source attribute is used to identify the iSNS client to the 1146 iSNS server. The key attribute is used to identify the entry (or 1147 entries) in the iSNS server for the request operation. Following 1148 the key attribute is a list of one or more operating attributes 1149 directly related to the actual iSNS request message. The number of 1150 each attribute (key & operating) depends on the specific iSNSP 1151 request or operation being performed. Some iSNSP messages may not 1152 specify any attributes. 1154 Gibbons, Tseng, Monia 23 1156 iSNS October 2000 1158 The response message contains a 4-byte ERROR CODE field, and 1159 depending on the specific iSNSP request, may be followed by a list 1160 of attributes. 1162 The following table lists each iSNSP message, allowable source 1163 attribute ID's, key attribute ID's, and operating attribute ID's. 1165 Message Source/Dest Attr Key Attribute Operating Attr 1166 ------- ---------------- ------------- -------------- 1167 RegDevAttr 1,4,9 1,4,9,18&19 multiple[1-21] 1168 RegDevRsp -- -- -- 1169 DevAttrQry 4,9 1,4,9,18&19 multiple[1-21] 1170 DevAttrQryRsp -- -- multiple[1-21] 1171 DevGetNext 4,9 1,4,9,18&19 -- 1172 DevGetNextRsp -- -- 1,4,9,18&19 1173 DeregDev 4,9 1,4,9,18&19 -- 1174 DeregDevRsp -- -- -- 1175 SCNReg 4,9 1,4,9,18&19 -- 1176 SCNRegRsp -- -- -- 1177 SCN 4,9 (dest) -- -- 1178 RegZone 4,9 (dest) 101 multiple[101-106] 1179 RegZoneRsp -- -- -- 1180 DeregZone 4,9 101 -- 1181 DeregZoneRsp -- -- -- 1182 RegDevZone 4,9 101 4,9 1183 RegDevZoneRsp -- -- -- 1184 DeregDevZone 4,9 101 4,9 1185 DeregDevZoneRsp -- -- -- 1186 PSI 4,9 (dest) -- -- 1187 PSIUpdate 4,9 -- -- 1188 Heartbeat -- -- -- 1190 The above table lists attribute ID's from section 5.4 that can be 1191 used for each role (source, key, and operating attribute) in the 1192 iSNSP message. The source attribute is that of the iSNS client, 1193 used in the registration or query message. The key attribute is 1194 the attribute used to look up the operating attribute in the iSNS 1195 directory database. The operating attribute(s) is the attribute(s) 1196 in the iSNS directory database which is to be added, modified, 1197 deleted, or queried. 1199 If more than one operating attribute can be used, "multiple" is 1200 noted in the entry. A "--" entry indicates that the iSNSP message 1201 does not use the attribute role (source/dest, key, or operating 1202 attribute). Note that the SCN and PSI messages specify the 1203 destination attribute in place of the source attribute. 1205 6.1 Register Device Attribute Request (RegDevAttr) 1207 The Register Device Attribute Request (RegDevAttr) message provides 1208 an iSNS client with the means to register device attributes. The 1210 Gibbons, Tseng, Monia 24 1212 iSNS October 2000 1214 iSNS client formulates a register attribute request by specifying a 1215 source, query key(s), and list of attributes to register. All 1216 values are in Tag Length Value format. 1218 The source attribute of the request is the IP address or the 8-byte 1219 Port Name (WWPN) of the iSNS client performing the query. The key 1220 attribute(s) is based on the type of attributes being registered, 1221 and is the IP Address, DNS Name & Path, Node Name (WWNN), or Port 1222 Name (WWPN) of the client being registered. If the key attribute 1223 matches an existing entry in the iSNS directory database, then the 1224 attribute values corresponding to the key entry will be replaced 1225 with new values sent in the message. Multiple attributes 1226 associated with the one database key attribute can be registered. 1228 The source attribute does not need to have been previously 1229 registered for the registration to succeed. The use of a Port Name 1230 (WWPN) as source does not automatically register it in the 1231 database--it is registered by including the attribute as part of a 1232 registration using a Node Name (WWNN) as a key. However, a Node 1233 Name (WWNN) is registered the first time it is used as a key, so it 1234 does not necessarily have to be listed among the attributes to be 1235 registered. 1237 The RegDevAttr request message payload includes the source 1238 attribute (IP Address, Node Name, or Port Name), the key attribute 1239 (IP Address, DNS Name & Path, Node Name or Port Name), and one or 1240 more operating attributes. 1242 6.2 Register Device Attribute Response (DevAttrRsp) 1244 If device attributes are successfully addded to the iSNS directory 1245 database as a result of DevAttrReg, then an acknowledgement with an 1246 error code of NO ERROR (0) is returned to the iSNS client. If the 1247 registration request is unsuccessful, the appropriate error code 1248 will be returned. 1250 6.3 Device Attribute Query Request (DevAttrQry) 1252 Once iSNS client attributes have been registered in the name 1253 service, queries can be made to obtain attributes related to a 1254 specific key. The Device Attribute Query Request (DevAttrQry) 1255 messages provide an iSNS client with the means to query the iSNS 1256 server for device attributes. 1258 The key attribute for the DevAttrQry is Node Name (WWNN), Port Name 1259 (WWPN), or a key set consisting of DNS Name and Path. The 1260 attribute list contains desired attributes. The length field for 1261 each requested attribute shall be of length 0. 1263 Gibbons, Tseng, Monia 25 1265 iSNS October 2000 1267 The iSNS server uses the key in the request message to query its 1268 database, and then returns the corresponding entry or entries for 1269 each requested attribute back to the client. 1271 The DevAttrQry request message payload includes the source 1272 attribute (IP Address or Port Name), the key attribute(s), and one 1273 or more operating attributes. 1275 6.4 Device Attribute Query Response (DevAttrQryRsp) 1277 The iSNS server uses the DevAttrQryRsp message to send back the 1278 attribute query results back to the iSNS client. A successful 1279 query will result in attribute values and length fields in the 1280 original TLV-formatted DevAttrQry request to be appropriately 1281 filled in. A failed query as a result of an inappropriate source 1282 and/or key attribute(s) will result in the message payload being 1283 replaced with the 4-byte ERROR CODE field. If there is no entry 1284 for queried attributes, the TLV-formatted attribute block will be 1285 returned with the length field set to 0 or a negative value error 1286 code. 1288 In addition to the ERROR CODE field, the DevAttrQryRsp message 1289 contains a list of operating attributes corresponding to the 1290 original request message. The attribute values resulting from the 1291 query are represented in the TLV format described in section 5.2. 1293 6.5 Device Get Next Request (DevGetNext) 1295 This message provides the iSNS client with the means to 1296 sequentially retrieve IP Addresses, DNS Name & Paths, Node Names 1297 and Port Names from devices in zones to which the client has 1298 access. The source of the query is represented by the IP Address 1299 or 8-byte Port Name (WWPN) of the client performing the query. The 1300 key tag is the IP Address, DNS Name & Path, Node Name (WWNN), or 1301 Port Name (WWPN). If the key length value entered is zero, 1302 signifying an empty key value field, the first accessible IP 1303 Address, DNS Name, Node Name, or Port Name instance shall be 1304 returned to the client. 1306 The DevGetNext request message payload contains a source attribute 1307 (IP Address or Port Name) and a key attribute (IP Address, DNS Name 1308 & Path, Node Name or Port Name). 1310 6.6 Device Get Next Response (DevGetNextRsp) 1312 The iSNS server uses the DevGetNextRsp to return the results of the 1313 DevGetNext request message. If the DevGetNext query does not 1314 identify an IP Address, DNS Name & Path, Node Name, or Port Name 1315 following the key provided in the query, and the query completed 1316 properly, the attribute value length field is set to zero. 1318 Gibbons, Tseng, Monia 26 1320 iSNS October 2000 1322 The DevGetNextRsp response message payload returns the queried 1323 attribute resulting from the original DevGetNext request (IP 1324 Address, DNS Name & Path, Node Name, or Port Name). 1326 6.7 Deregister Device Request (DeregDev) 1328 An iSNS client port or device is removed from the iSNS directory 1329 database by using the Deregister Device Request (DeregDev). Upon 1330 receiving the DeregDev, the iSNS server removes all attributes 1331 associated with the IP Address, DNS Name & Path, Node Name (WWNN) 1332 or Port Name (WWPN) key, and sends state change notifications 1333 (SCNs) to registered iSNS clients that are in the same Zone as the 1334 removed device or port. After removing the port or device, the 1335 iSNS server sends back an acknowledgement to the iSNS client. 1337 The DeregDev request message payload contains a single source 1338 attribute (IP Address or Port Name) and key attributes (IP Address, 1339 DNS Name & Path, Node Name or Port Name). 1341 6.8 Deregister Device Response (DeregDevRsp) 1343 If device attributes are successfully removed from the iSNS 1344 directory database as a result of a Deregister Device Request 1345 (DeregDev), the DeregDevRsp message with error code of NO ERROR(0) 1346 is returned to the original iSNS client. The DeregDevRsp response 1347 message payload does not contain any attributes. 1349 6.9 SCN Registration Request (SCNReg) 1351 The State Change Notification Registration Request (SCNReg) message 1352 allows an iSNS client to register an IP Address or Port Name (WWPN) 1353 for State Change Notification (SCN) messages. SCN messages allow 1354 an iSNS client to be notified of changes within the zone or network 1355 (if adminstratively allowed) that the device port is a member of. 1357 In place of the attribute list for other iSNSP message types, the 1358 SCNReg has the 16-bit INTERESTED EVENT TYPE FLAGS field described 1359 in section 5.5, which comes immediately after the key attribute. 1360 The following displays the format of the SCNReg message payload: 1362 Byte MSb LSb 1363 Offset 7 6 5 4 3 2 1 0 1364 +----------------------------------+ 1365 0 | source attribute | 12 Bytes 1366 +----------------------------------+ 1367 12 | key attribute | 12 Bytes 1368 +----------------------------------+ 1369 24 | EVENT TYPE FLAGS | 2 Bytes 1370 +----------------------------------+ 1371 Total Length = 26 1373 Gibbons, Tseng, Monia 27 1375 iSNS October 2000 1377 Section 5.5 describes each flag used in the EVENT TYPE FLAGS field. 1379 6.10 SCN Registration Response (SCNRegRsp) 1381 If the iSNS client successfully registered for state change 1382 notifications, an acknowledgement with the ERROR CODE field set to 1383 NO ERROR(0) is returned to the client. This message does not 1384 contain any attributes. 1386 6.11 State Change Notification (SCN) 1388 The State Change Notification is a special message which allows a 1389 registered iSNS client to be notified of changes within a zone, 1390 network (if administratively allowed), or other device registration 1391 parameters in the iSNS directory database. The notification is 1392 indicated in the EVENT TYPE FLAGS field described in section 5.5. 1393 A time stamp is included in this message following the EVENT TYPE 1394 FLAGS field. This time stamp is a 4-byte unsigned, fixed-point 1395 integer giving the number of seconds since midnight, January 1, 1396 1970. The format of the message payload of the SCN message is as 1397 follows: 1399 Byte MSb LSb 1400 Offset 7 6 5 4 3 2 1 0 1401 +----------------------------------+ 1402 0 | destination attribute | 12 Bytes 1403 +----------------------------------+ 1404 12 | EVENT TYPE FLAGS | 2 Bytes 1405 +----------------------------------+ 1406 14 | TIME STAMP | 4 Bytes 1407 +----------------------------------+ 1408 Total Length = 18 1410 Destination attribute contains the IP Address or Port_Name in TLV 1411 format of the iSNS client to receive the SCN message. There is no 1412 response message to the SCN message by the iSNS client. 1414 6.12 Register Zone (RegZone) 1416 This message allows an iSNS client to create a new Zone to be 1417 stored in the iSNS directory database. Once created, Port Names 1418 can be added and deleted from the Zone. 1420 Zones are defined using Zone IDs, Zone tags, and Symbolic Names. 1421 Zone registration attributes are described in section 5.4. 1423 The RegZone message payload contains the source attribute (IP 1424 Address or Port Name), key attribute (Zone ID), and one or more 1425 Zone attributes (Zone Tag, Zone Symbolic Name, Zone Member [IP 1426 Address or WWPN], and Zone Member Priority). 1428 Gibbons, Tseng, Monia 28 1430 iSNS October 2000 1432 6.13 Register Zone Response (RegZoneRsp) 1434 The Register Zone Response (RegZoneRsp) message is used by the iSNS 1435 server to acknowledge a RegZone message. If a Zone is successfully 1436 created with the requested attributes, the RegZoneRsp is returned 1437 to the client with an ERROR CODE of NO ERROR(0). The message 1438 payload contains no attributes. 1440 6.14 Deregister Zone (DeregZone) 1442 This message allows an iSNS client to delete an existing Zone from 1443 the iSNS directory database. A zone with non-zero membership 1444 cannot be deleted. The DeregZone message payload contains the 1445 source attribute (IP Address or Port Name) and key attribute (Zone 1446 ID). 1448 6.15 Deregister Zone Response (DeregZoneRsp) 1450 This message is used by the iSNS server to acknowledge a DeregZone 1451 request. If the zone was successfully deregistered, an 1452 acknowledgement is sent with an ERROR CODE of NO ERROR(0). The 1453 DeregZoneRsp message payload does not contain any attributes. 1455 6.16 Register Device in Zone (RegDevZone) 1457 Devices can be added to a zone by registering the port names of the 1458 devices. Adding an IP Address or Port Name (WWPN) to the zone 1459 provides access to all other device ports in the zone. 1461 The RegDevZone message payload contains the source attribute (IP 1462 Address or Port Name), key attribute (Zone ID), and one or more 1463 Zone attributes (Zone Tag, Zone Symbolic Name, Zone Member [IP 1464 Address or Port_Name], and Zone Member Priority). 1466 6.17 Register Device in Zone Response (RegDevZoneRsp) 1468 This message provides confirmation that the RegDevZone message was 1469 received and processed by the iSNS server. If the device was 1470 successfully registered in the zone, an acknowledgement is sent 1471 with an ERROR CODE of NO ERROR(0). The RegDevZoneRsp message 1472 payload does not contain any attributes. 1474 6.18 Deregister Device in Zone (DeregDevZone) 1476 Devices can be removed from a Zone by deleting their IP Address or 1477 Port Names (WWPN) from the Zone. Deleting devices from a zone 1478 removes access to that device from all other devices in that Zone. 1480 The DeregDevZone request message payload contains the source 1481 attribute (IP Address or Port Name), key attribute (Zone ID), and 1483 Gibbons, Tseng, Monia 29 1485 iSNS October 2000 1487 the operating attribute (IP Address or Port Name) of the device 1488 being deregistered. 1490 6.19 Deregister Device in Zone Response (DeregDevZoneRsp) 1492 This message provides confirmation that the DeregDevZone message 1493 was received and processed by the iSNS server. If the device was 1494 successfully deregistered from the zone, an acknowledgement is sent 1495 with an ERROR CODE of NO ERROR(0). The DeregDevZoneRsp message 1496 payload does not contain any attributes. 1498 6.20 Port Status Inquiry (PSI) 1500 The Port Status Inquiry (PSI) message provides the iSNS server with 1501 the ability to verify that a registered iSNS client is still 1502 accessible. The format of the PSI is similar to the SCN message, 1503 and uses the same EVENT TYPE FLAGS field. The types of events and 1504 flags are listed in section 5.5. 1506 The PSI request message payload contains the attribute (IP Address 1507 or Port Name) of the device being inquired for status. 1509 6.21 Port Status Inquiry Update (PSIUpdate) 1511 This message provides confirmation that the PSI message was 1512 received and processed by the iSNS client. If the client is still 1513 accessible by the iSNS server, then it will respond and confirm 1514 accessibility through the PSIUpdate message. 1516 The PSIUpdate response message payload contains the source 1517 attribute (IP Address or Port Name) of the responding device. 1519 6.22 Name Service Heartbeat (Heartbeat) 1521 The iSNS server sends out a multicast heartbeat message. The 1522 heartbeat can be used by iSNS clients to verify connectivity, as 1523 well as to discover the iSNS server. The period of the heartbeat 1524 is included in the message, with default period of 15 seconds. 1525 There is no response to the Heartbeat message. 1527 7. Security Considerations 1529 7.1 Data Integrity and Authentication 1531 Data integrity and authentication requirements for communication 1532 between iSNS clients and server can be achieved through use of the 1533 authentication block. 1535 7.2 Security Model 1537 Gibbons, Tseng, Monia 30 1539 iSNS October 2000 1541 The iSNS server will leverage existing security mechanisms 1542 currently used to secure resources such as DNS servers, e-mail 1543 relays servers, and other sensitive and otherwise vulnerable 1544 network resources. Existing firewalls with stateful inspection 1545 technology can examine incoming traffic from the Public Internet, 1546 and protect against active attacks. 1548 8. References 1550 [RFC1035] Domain Implentation and Specification 1551 [STD0035] Domain Name System 1552 [RFC2065] Domain Name System Security Extensions 1553 [FC-GS-2] Fibre Channel Generic Services-2, ANSI NCITS 288 1554 [FC-GS-3] Fibre Channel Generic Services-3, NCITS Working 1555 Draft Rev 6.42, June 7, 2000 1556 [RFC2609] Service Templates and Service 1557 [IEEE802.1Q] Standard for Virtual Bridged Local Area Networks 1558 [RFC1510] The Kerberos Network Authentication Service 1559 [DSS] FIPS PUB 186-2, National Institute of Standards and 1560 Technology, Digital Signature Standard(DSS), 1561 Technical Report 1562 [802-1990] ANSI/IEEE Std 802-1990, Name: IEEE Standards for 1563 Local and Metropolitan Area Networks: Overview and 1564 Architecture 1565 [SPC] SCSI-3 Primary Commands, ANSI NCITS 995D, Revision 1566 11a 1568 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1569 9, RFC 2026, October 1996. 1571 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1572 Levels", BCP 14, RFC 2119, March 1997 1574 9. Author's Addresses 1576 Josh Tseng 1577 Kevin Gibbons 1578 Charles Monia 1579 Nishan Systems 1580 3850 North First Street 1581 San Jose, CA 95134-1702 1582 Phone: (408) 519-3749 1583 Email: jtseng@nishansystems.com 1585 Gibbons, Tseng, Monia 31 1587 iSNS October 2000 1589 Full Copyright Statement 1591 "Copyright (C) The Internet Society, September 18, 2000. All Rights 1592 Reserved. This document and translations of it may be copied and 1593 furnished to others, and derivative works that comment on or 1594 otherwise explain it or assist in its implmentation may be 1595 prepared, copied, published and distributed, in whole or in part, 1596 without restriction of any kind, provided that the above copyright 1597 notice and this paragraph are included on all such copies and 1598 derivative works. However, this document itself may not be modified 1599 in any way, such as by removing the copyright notice or references 1600 to the Internet Society or other Internet organizations, except as 1601 needed for the purpose of developing Internet standards in which 1602 case the procedures for copyrights defined in the Internet 1603 Standards process must be followed, or as required to translate it 1604 into 1606 Gibbons, Tseng, Monia 32 1608 iSNS October 2000