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