Internet DRAFT - draft-grant-iscsi-eui64node

draft-grant-iscsi-eui64node



  Internet Draft                                 Expires July 2002
                                     
                                                         Rob Grant 
                                                            McDATA

                                                       Todd Sperry 
                                                           Adaptec 

                            Jan. 21, 2002 

                   iSCSI EUI64-based Node Naming
                 draft-grant-iscsi-eui64node-00.txt

   Status of this Memo


   This document is an Internet-Draft and is in full conformance 
   with all provisions of Section 10 of RFC2026 [1]. 

   Internet-Drafts are working documents of the Internet 
   Engineering Task Force (IETF), its areas, and its working 
   groups.  Note that other groups may also distribute working 
   documents as Internet-Drafts. Internet-Drafts are draft 
   documents valid for a maximum of six months and may be 
   updated, replaced, or made obsolete by other documents at any 
   time.  It is inappropriate to use Internet-Drafts as 
   reference material or to cite them other than as "work in 
   progress." 

   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt 
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html.

   Abstract

   This document proposes a new method of identifying iSCSI Nodes
   beyond the iSCSI name. The new method uses a 64-bit field to be
   compatible with technologies using 64-bit identifiers such as EUI-64.
   These technologies include Fibre Channel and Infiniband, but may also
   extend to storage features such as failover, LUN-level masking or 
   storage asset management.

   The preferred method for distribution of this new 64-bit identifier 
   is through registration with iSNS. An alternative method is also 
   proposed whereby an optional Operational Key is added to the Text 
   field of an iSCSI Login PDU.




  draft-grant-iscsi-eui64node-00.txt                     Page [2]


     ____________   /\/\/\/\/\/\   _____   /\/\/\/\/\/\   ____________
     |   portal1|===/          \==| GW1 |==/          \===|port1      |
     |  iSCSI   |   \    IP    /   -----   \    FC    /   |   FC      |
     |  Node    |   /  Network \   _____   /  Fabric  \   |   Node    |
     |   portal2|===/          \==| GW2 |==/          \===|port2      |
      ----------    \/\/\/\/\/\/   -----   \/\/\/\/\/\/   ------------
 
                  
                                Figure 1: an FC to iSCSI Gateway
    

              
Problem Statement:
As an example of where a 64-bit node-level identifier could be used, 
Figure 1 shows a network topology with two gateway (or bridge) devices 
between an iSCSI network and a Fibre Channel fabric. Also shown is a 
single iSCSI Node with 2 portals and a single FC node with 2 ports. 

In order for a gateway to login to a FC device (FLOGI, PLOGI), the 
gateway must provide a FC World Wide Node Name (WWNN) and a World 
Wide Port Name (WWPN) - both of which are 64-bit identifiers. 

While it is possible for a gateway to generate such World Wide Names as 
needed, using various techniques, arbitrary assignments of WWNN by 
different gateways to represent iSCSI devices is not desirable. The WWPN, 
however, can be assigned by the gateway device, as it corresponds to the 
actual physical port being used.

While this example is particular to Fibre Channel to iSCSI Gateways, 
the use of 64-bit identifiers is not unique to Fibre Channel. Other 
technologies also use the EUI-64 format as identifiers (for example, 
Infiniband  uses a EUI-64 format Globally Unique Identifier or GUID). 
Further, other storage functions (automatic failover, some types 
of access control, asset management) have built on this use of 64-bit 
identification of nodes independent of the transport. The example of
an iSCSI-to-FC Gateway, however, will be used to discuss various 
alternatives to achieving a 64-bit identifier. 


Why Involve the iSCSI End Node?

A simple approach would be to have the gateway provide an identifier. 
This approach, however, could result in different gateways using a 
different WWNN to represent the same iSCSI node (GW1 and GW2 in the 
Figure). If this occurs, storage functions built on 64-bit node 
identification would have no way of identifying that the 2 
Gateways are representing the same node. 

A more sophisticated implementation may attempt to have a particular 
gateway use a Fabric Service (on either the IP or FC fabric) to 
get some consistency of naming between gateways. These implementations, 
however, may suffer from inconsistency across Gateways 
(particularly between vendors). As well, they may suffer from 
inconsistency in naming during error or failure conditions (such as 
the failure of a Gateway or fabric service). While these issues may be 
addressed, the resolutions involve a great deal of complexity. 
Finally, they may still ultimately fail to identify that multiple ports 
in reality represent a single node. 




draft-grant-iscsi-eui64node-00.txt                     Page [3]

A simple place to create consistent node-level identification is in the 
actual nodes. Further, having an iSCSI node "own" its 64-bit identity 
is consistent with other iSCSI naming.


How a Node Constructs a EUI64NN

A simple method would be to have an iSCSI HBA create an EUI-64 
identifier using its Ethernet MAC address (EUI-64 identifers can be 
made from EUI-48 or MAC-48 identifiers). This allows simple 
implementations to use entities which already exist (the MAC address) 
while allowing more sophisticated implementations (that can be aware of 
multiple NICs) to use some other method to form a consistent node-level 
identification.

Communicating an EUI-64 Node Name Using iSNS

The preferred method for an iSCSI End Node to communicate an EUI64 Node 
Name is to register it with an iSNS Server. For this, the definition of 
the "iFCP FC Device Node Name (WWNN)" attribute of [iSNSID] would be 
expanded to include iSCSI nodes and renamed the 
"EUI-64 Node Name (EUI64NN)". This attribute would become a required 
attribute for iSCSI Storage Nodes supporting iSNS. The methods for 
iSNS attributes as defined in [iSNSID] are then used by end devices, 
gateways or other entities to register and query for EUI64NNs.

Communicating an EUI-64 Node Name During iSCSI Login

As an alternative for iSCSI storage nodes that do not support iSNS, 
this paper proposes a new optional Operational Key to be added to the 
Text field of an iSCSI Login PDU.  This approach may be appropriate for 
nodes which are statically configured or use other discovery mechanisms
such as SLP. The new Operational Key, termed the EUI64NN, would 
represent the EUI-64 Node Name. An example of an an EUI64NN 
Operational Key built from a 48-bit IEEE Standard 802.1A Universal LAN 
MAC address  "0x123456789abc" would be EUI64NN=0x1000123456789abc.


Example of EUI64NN Communication During an iSCSI Login 

The following shows an example of negotiation of the EUI64NN 
Operational Key during login.

I-> Login (..., T=1) 
           	InitiatorName=iqn.1999-07.com.os.hostid.77 
           	TargetName=iqn.1999-07.com.acme.diskarray.sn.88
       	EUI64NN=0x1000123456789abc
T-> Login (..., T=0) 
      	EUI64NN=0x1000123456789def, 0x1000123456789ghi, 
0x1000123456789jkl
I-> Login (..., T=1) 
     	EUI64NN=0x1000123456789abc
T-> Login (..., T=1) 
      	EUI64NN=0x1000123456789abc




draft-grant-iscsi-eui64node-00.txt                     Page [4]

Acknowledgements
The authors would like to thank Anil Rijhsinghani, Ernest Dainow, 
Henry Yang and David Wu for their help in preparing this Internet Draft.


   Authors' Addresses: 

         Rob Grant
         McDATA Corp. 
         111 Gordon Baker Rd.
         North York, Ontario
         Tel: (416) 496-6564 
         robert.grant@mcdata.com

         Todd Sperry 
         Adaptec, Inc. 
         691 South Milpitas Boulevard 
         Milpitas, Ca. 95035 
         Phone: (408) 957-4980 
         Email: todd_sperry@adaptec.com 

   Full Copyright Statement 
   Copyright (C) The Internet Society (2000).
     All Rights Reserved. 

   This document and translations of it may be copied and 
   furnished to others, and derivative works that comment on or 
   otherwise explain it or assist in its implementation may be 
   prepared, copied, published and distributed, in whole or in 
   part, without restriction of any kind, provided that the 
   above copyright notice and this paragraph are included on all 
   such copies and derivative works. 

   However, this document itself may not be modified in any way, 
   such as by removing the copyright notice or references to the 
   Internet Society or other Internet organizations, except as 
   needed for the purpose of developing Internet standards in 
   which case the procedures for copyrights defined in the 
   Internet Standards process must be followed, or as required 
   to translate it into languages other than English. 

   The limited permissions granted above are perpetual and will 
   not be revoked by the Internet Society or its successors or 
   assigns.  This document and the information contained herein 
   is provided on an "AS IS" basis and THE INTERNET SOCIETY AND 
   THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, 
   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 
   THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 
   RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 
   FITNESS FOR A PARTICULAR PURPOSE.

 Expires July 2002