SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    iSCSI: Rationale behind the SLP draft



    
    David Black has requested that I send something to the
    list showing the rationale behind the SLP draft, including
    its fit in the big picture and its relationship with iSNS.
    Here's an attempt to do so.  I believe it to be consistent
    with the Naming & Discovery, iSNS, and iSCSI/SLP drafts,
    and their IETF-50 presentations.
    
    The relevant drafts are:
    
      draft-ietf-ips-iSCSI-name-disc-00
      draft-ietf-ips-isns-00
      draft-bakke-iscsi-slp-00
    
    Naming and Discovery Requirements
    
    These are the discovery and name services requirements
    from draft-ietf-ips-iscsi-name-disc-00.  From a discovery
    requirements point-of-view, SLP and iSNS provide some
    similar services.  SLP provides very simple discovery services
    for smaller networks; iSNS provides more comprehensive
    management services for larger networks.  Where they overlap,
    SLP and iSNS can interoperate fairly easily.
    
    1. Multicast method to discover targets, to allow zero-
       configuration of initiators and targets.
    
       SLP provides this.
    
    2. A method to look up a WWUI, and get one or more addresses.
       "Where is target <wwui>?"
    
       SLP and iSNS both provide this.
    
    3. A method to find targets that a given initiator should access.
       "I am initiator <wwui>; which targets should I access?"
    
       SLP and iSNS both provide this.
    
    4. Ability to limit discovery to relevant initiators and targets.
    
       iSNS uses Discovery Domain, which are used to limit which initiators 
       and targets can discover each other.  Each target and initiator
       belong to Discovery Domain; the iSNS will not allow initiators to
       discover targets outside their domain.
    
       SLP uses a named Scope.  Each target and initiator is configured
       with one or more scope names; a target will only respond to an
       initiator who has a matching scope.  Note that this is not a
       security mechanism; an initiator can ask for any scope it wishes,
       and a target can respond to any scope it wishes.  This provides
       a simple mechanism to limit discovery, but does not attempt to
       provide security.
       
    5. Access Lists by initiator WWUI
    
       SLP and iSNS both provide the ability to store a list of initiator
       WWUIs that are allowed access to a given target.
    
    6. iSCSI Object Model support
    
       SLP registers only the targets
       iSNS registers targets, initiators, network entities, portals
    
    7. TLV Message Format
    
       SLP and iSNS both do this.  However, SLP uses a text key and
       value for its attributes; iSNS uses a binary key value.
    
    8. Authentication of discovery messages
    
       iSNS uses SLP's authentication mechanism
    
    9. Registration and Query
    
       SLP registers targets only
       iSNS registers targets, inititors, network entities, portals
    
    10. State Change Notification
    
       iSNS provides a state change service for which entities can
       register.
    
       SLP does not provide state change or event notification.  There
       is a draft on doing some notification, but it is not adequate for
       propagating attribute changes, which are necessary for an
       initiator to discover that it has gained (or lost) access to
       a target, or that a target has added a new address.
    
    11. Light-weight Protocol
    
       Neither protocol should be too much of a burden to implement.
    
       Adding authentication to the protocol can be done later, and will be
       the same effort for both.  In the case that both SLP and iSNS are
       supported in the same product, they can share the code for this
       feature.
    
    12. Compatibility with Boot Requirements
    
       Both the SLP template and the iSNS specification have worked to
       ensure that they fit in with the boot requirements.
    
       SLP has defined DHCP options that allow it to locate a directory
       agent, avoiding multicast traffic from initiators in a DHCP
       environment.
    
    13. Compatibility with LDAP
    
       Although this is not a requirement, we have seen the desire for
       interworking with LDAP discussed on the list enough that it may
       merit a requirement at some point.  Both SLP and iSNS are designed
       with LDAP compatibility in mind.
    
    14.  Entity Status Inquiry/Heartbeat
    
      iSNS provides an ESI/heartbeat ping message to monitor the
      availability of initiators and targets.  The heartbeat is
      originated by the iSNS server.
    
      We have not defined this capability for SLP.  It may be possible
      to do something similar if targets advertise themselves with a
      shorter lifetime, and initiators expire their discovered targets
      appropriately.  Adding a directory agent (DA) may be required for
      this to work properly.
    
    15.  Distribution of X.509v3 Public Key certificates
      
      iSNS provides this capability.
    
      Our SLP template does not attempt to do this for two reasons:
    
        - SLP attributes are strings; the binary certificates would have
          to be escaped or uuencoded.
    
        - iSCSI only registers targets; there is no way for targets
          to discover an initiator's certificate.
    
    16. Usage of Multicast
    
      SLP normally relies on multicast, for initiators to request
      advertisements from targets.  Multicast use can be eliminated
      at the expense of adding a DA, and configuring its address on
      each of the initiators and targets.
      
      iSNS does not use multicast.
    
    
    We had originally started out looking for something to fulfill the
    multicast requirements that iSNS did not do.  However, we found that
    if one already had SLP, it was just as easy to find individual
    targets, or at least canonical targets using it as it was to locate
    an iSNS service.  SLP can then be used to handle discovery for
    simpler host and device environments, and iSNS could be added later
    to help manage these environments.      
    
    SLP and iSNS both fulfill many of the requirements from
    the naming & discovery draft.  However, they don't completely
    overlap, and they take two different approaches to discovery.
    
    SLP provides Discovery of Targets.
    
      SLP is used for discovery ONLY.  It uses a distributed
      model, that can start with initiators and targets, and
      no directory servers.  It can add Directory Agents to
      scale to medium-sized environments and reduce or eliminate
      the use of multicast.  Some work is underway on mesh-
      enhanced SLP (mSLP), which provides peer-to-peer information
      exchange between DAs for larger environments.  
    
      From a pure discovery point of view, SLP's chief weakness
      is that it does not yet have a notification mechanism.
    
      - Discovery of iSCSI targets
      - Discovery of iSNS services
      - Multicast-optional discovery mechanism for targets and
        other name services.
      - Open source implementations
      - Existing standard protocols
    
    iSNS provides Centralized Management of Initiators and Targets.
    
      In addition to target discovery, iSNS provides higher-level
      functions such as centralized access management, active
      monitoring, public-key certificate management, and state-change 
      notifications.
    
      - Discovery of iSCSI targets
      - Centralized management of initiator and target access
      - Active monitoring of initiators and targets
      - State change notification
    
    Using SLP with iSNS
    
    Although SLP and iSNS solve several of the same problems, they
    are fairly well-suited to interoperating.  They share a common
    authentication structure, which is not something one would want
    to code twice.  SLP can be used to do basic discovery where
    configuring an iSNS server is not warranted, and can help
    discover iSNS servers in environments where centralized management
    is needed.  It is relatively simple for an iSNS server to
    provide a proxy SLP service agent on behalf of the targets it
    manages, allowing initiators to participate that implement only
    the basic SLP.  Similarly, an iSNS server can work with gateways
    to provide its services for targets that support only SLP.
    
    When initiators and targets support BOTH SLP and iSNS, there
    are a few rules that should be followed:
    
    1. Initiators can use both SLP and iSNS concurrently to discover
       their targets.  In fact, an initiator should be able to use
       more than one iSNS, if it is accessing storage from two
       different providers.  This allows an initiator to discover
       its locally-managed devices using SLP, and its centrally-
       managed devices using iSNS.
    
    2. Targets should be advertised using a single discovery method.
       A target should be advertised either with SLP, or with a
       single iSNS environment.  Targets discovered multiple ways
       would probably not break anything, but a target discovered
       via multiple services could produce conflicting information
       to the initiator.
    
    3. Gateways or iSCSI proxies can be used to provide local SLP
       discovery of targets that are managed using iSNS.
    
    Implementation Approach
    
    I recommend a three-phase approach to implementing iSCSI
    naming and discovery.  The first phase is to simply support the
    WWUIs, and their use with the iSCSI protocol, and allow static
    configuration of hosts and targets.  The second is to support
    SLP for simple discovery.  This should be relatively quick to 
    implement, as the source for SLP is readily available.  The third
    would be to support iSNS as a storage management capability.
    
    1. Simple naming and configuration
    
      - Admins configure targets with some form of access list, which
        may include the initiator WWUIs that are supposed to access
        them.
    
      - Admins configure initiators with the canonical target "iscsi"
        for targets that may provide them services.
    
      - Initiators use the SendTargets text command to discovery their
        targets.  This eliminates configuring target WWUIs in the
        initiator.
    
    2. SLP for multicast and simple discovery
    
      - Instead of configuring initiators with target addresses, admins
        enable SLP on the initiator.
    
      - Targets also enable SLP, and are discovered by the initiators.
    
    3. iSNS for centralized management
    
      - Initiators and targets are configured to be managed by an iSNS
        service.
    
      - Admins configure both hosts and targets from the iSNS server.
    
      - Initiators and targets use the iSNS protcol to discover each other.
    
    Other Discovery Protocols
    
      There are several other discovery protocols; each has its
      strengths and weaknesses.  Here are some of them.  Take a look
      at "Building Networks on the Fly", IEEE Spectrum, March 2001
      for more information on these.
    
    1. DNS SRV Records - these seemed too limiting, and there did
       not seem to be much point in making DNS do more.  The SLP
       folks started their work because DNS SRV records didn't meet
       their requirements.
    
    2. LDAP, with an appropriate schema defined, could handle iSCSI
       registrations and queries, and distribute essentially the
       same information as SLP.  There are three reasons we didn't
       go directly to LDAP:
    
       1. LDAP would require a heavier implementation than SLP
       2. LDAP would not solve the multicast requirements
       3. SLP is built to be compatible with LDAP; SLP can be used
          by iniators and targets, with LDAP as a back-end database.
          This is left as an exercise for the implementor.
    
    3. Jini is controlled by a single company, and is tied to a
       particular programming language, which is not appropriate
       for an internet standard.
    
    4. UPnP from Microsoft is based on XML data with an HTTP transport.
       XML has a lot of merit for application interfaces like these, but
       the code for XML and HTTP could be a bit heavy for a really simple
       device.  It's company-controlled anyway, so we can't use it.
    
    5. Salutation - Have not explored this in depth.  Salutation has
       been around longer than the other protocols.  It is made to be
       more flexible; it does not assume IP.
    
    6. Bluetooth, HAVi - These are done by controlled-membership
       organizations, and are designed for specific non-IP environments.
    
    
    -- 
    Mark A. Bakke
    Cisco Systems
    mbakke@cisco.com
    763.398.1054
    


Home

Last updated: Tue Sep 04 01:05:18 2001
6315 messages in chronological order