SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: iSCSI - structured values



    I think that the 16 bit qualifier is good enough for the vendor(s) to 
    define a dynamic locally unique value. The rest of the fields
    make up for the need of the vendor to assign a statically unique ID.  Add 
    this to the initiator name and you have a large enough play-field.
    
    On the target side - cooperation is not hindered by a requirement for 
    APIs.
    The naming service does to PG allocation.
    
    I find also the header increase argument perilous - as somebody has 
    already pointed out we are moving to a headers only protocol world - who 
    needs data?
    
    Julo
    
    
    
    
    Mark Bakke <mbakke@cisco.com>
    Sent by: owner-ips@ece.cmu.edu
    07-12-01 22:37
    
     
            To:     Keith McCloghrie <kzm@cisco.com>
            cc:     ips@ece.cmu.edu
            Subject:        Re: iSCSI - structured values
    
     
    
    
    I agree with Keith on this; the new ISID format went a long
    way to solve the problem of a single initiator name being
    "represented" by multiple interface cards; I think that the
    same thing needs to be extended to target portal groups.
    Expanding the available identifier space in the ISID (and
    target portal group) to at least 3 bytes allows the convenience
    of a MAC address to be used for these identifiers.
    
    This also allows multiple gateways to represent the same
    initiator or target, without having to create different iSCSI
    names for each representation of the same initiator or
    target.  I think that solving this problem (which we almost
    have already) would help these solutions scale much better.
    
    --
    Mark
    
    Keith McCloghrie wrote:
    > 
    > Hi,
    > 
    > The following ideas came up in a discussion I had about iSCSI.
    > 
    > The first issue is about the algorithm to use for allocating the
    > structured ISID values, which contain three fields:
    > 
    >  - The Type field identifies the format:
    >            00h     - IEEE OUI
    >            01h     - IANA Enterprise Number (EN)
    >            02h     - "Random"
    >            03h-FFh - Reserved
    >  - The Naming Authority field identifies the vendor or organization
    >  - The Qualifier field is a 16 bit value that provides a range of
    >    possible values for the ISID within the Type and Naming Authority
    >    namespace.
    > 
    > The "notes" in draft-ietf-ips-iscsi-name-disc-03.txt specify:
    > 
    >      (a) As noted, the structure of the ISID namespace provides each
    >      vendor with its own piece of the ISID namespace.  In effect, this
    >      provides for a vendor-partitioning of that namespace within each
    >      initiator.
    > 
    > So, this puts the onus on a "vendor" to come up with the vendor's own
    > scheme for allocating ISID values.  For the situation where a vendor
    > wants to assign different values to different interfaces/HBAs, the
    > simplest scheme would be to use a unique value which is shipped with
    > each product, such as a MAC address.  This would be simple because it
    > would obviate any need to coordinate between different interfaces
    > (even those from the same vendor).  In fact, the first three bytes of
    > a 6-byte MAC address are an IEEE OUI, which is exactly what type=0
    > specifies, except that the MAC address has 3 more bytes, and the
    > Qualifier field is only 2 bytes.  So, in order to allow vendors to
    > adopt such a simple scheme, I'd like to propose that the Qualifier
    > field be enlarged to at least 3 bytes.  It probably doesn't make much
    > sense to make the overall ISID to be 7 bytes long.  So, how about
    > making the Qualifier be 4 bytes so that the ISID is 8 bytes long ?
    > As far as I'm aware the performance impact of this is virtually
    > negligible, and so I can't really see any disadvantage in doing so.
    > 
    > The second issue concerns Portal Group Tags.  It seems that despite
    > the difference in terminology, that an ISID and a Portal Group Tag
    > are corresponding concepts.  For example, a SCSI Port Name is defined
    > as "the iSCSI Name + 'i' or 't' + ISID or Portal Group Tag".  However,
    > a Portal Group Tag is defined as a 16-bit integer.  Now, I understand
    > that an ISID was originally defined as a 16-bit integer, before its
    > format was expanded (as discussed above).  So, with the correspondence
    > of ISID and Portal Group Tag, surely it makes sense for a Portal Group
    > Tag to have the same format as an ISID.  This will allow vendors of
    > iSCSI targets with multiple interfaces/HBAs to use a simple scheme as
    > and when they need to assign different Portal Group Tag values to the
    > different interfaces/HBAs.  So, whether or not the ISID format is
    > changed based on the first issue above, I propose that the same
    > structured format be used for both ISIDs and Portal Group Tags.
    > 
    > Keith.
    
    -- 
    Mark A. Bakke
    Cisco Systems
    mbakke@cisco.com
    763.398.1054
    
    
    
    


Home

Last updated: Mon Dec 10 20:17:48 2001
8023 messages in chronological order