RE: iSCSI: Rationale behind the SLP draft

[Joshua Tseng <jtseng@NishanSystems.com>]

Doug & Mark,

My earlier response to Doug's message didn't seem to have gotten
posted. (Is there something up with the reflector server or something?)

The gist of my lost message is that LDAP is merely a network-based
information repository where applications can store and retrieve
their own application-specific data.  Similarly, database engines
such as a oracle and db2 are completely useless without an application
(e.g., peoplesoft or SAP) to drive them.  For IP storage, iSNS is
the application which can be layered on top of LDAP.  iSNS is the
storage-aware application that can monitor and manage access and
availability of IP storage devices.  And it MAY use LDAP to store
its data.

For a more detailed comparison of LDAP and iSNS, see section 3.4
of the current -01 iSNS draft.  I wrote this specifically with
Doug's concerns in mind, and I don't think I need to repeat the
material here.  The main point is that LDAP is a general purpose
tool.  If you build naming and discovery services directly on
the LDAP protocol, then you will live and die by its weaknesses.
There will be just as much work defining and implementing the
schema, and plus there will be many functions that LDAP will not
be able to perform, such as iSNS's ESI, which will have to be
incorporated into iSCSI or some other application.

Regards,
Josh 

> -----Original Message-----
> From: Douglas Otis [mailto:dotis@sanlight.net]
> Sent: Friday, March 16, 2001 10:16 PM
> To: Mark Bakke
> Cc: IPS
> Subject: RE: iSCSI: Rationale behind the SLP draft
> 
> 
> Mark,
> 
> The SLP multi-cast will not work to the same level as DHCP 
> due to a lack of
> co-operation with networking equipment.  LDAP can provide 
> information based
> on client attributes within 100k of code if embedded.  As LDAP can be
> structured, the size of LDAP data can be constrained to fit 
> within a switch
> without much wasted code and with an ability to extend other 
> devices.  For
> small local domain only versions, see slapd and slurpd.
> 
> The principle aspect provided by iSNS is signaling of fabric 
> configuration
> changes. Such could be done by configuring IPS servers to run 
> with a slave
> to then signal affected clients based on login information.  
> iSCSI does not
> but should provide signaling done by this external system 
> that now relays
> information out-of-band.  The iSNS describes LDAP as a 
> possible source of
> information so the same signaling between iSNS and LDAP could 
> exist between
> various IPS servers rather than all of their clients.  It 
> would become the
> task of the IPS server to signal clients already connected without a
> keep-alive heart-beat needed for persistent iSNS connections 
> otherwise.
> 
> As LDAP is extensible, provides needed features if a schema 
> is defined, and
> does not represent a burden for small to big configurations, the
> justification seems weak.  From what could have been a simple schema
> definition, there are now two inter-related beta servers with 
> vendor unique
> support to inter-operate with a beta protocol.  Do you see an 
> advantage of
> defining the schema as an alternative to these LDAP 
> front-ends?  Such a
> schema would help those wishing to make these front-ends and 
> for the tools
> to service them.  Without a schema, there can only be vendor unique
> solutions to support iSNS and there will be no vendor 
> inter-operability with
> respect to configuration exchanges.
> 
> Doug
> 
> > Doug-
> >
> > SLP provides the multicast discovery we were looking for, and does
> > not require DHCP, although it can work with it.  LDAP does 
> not provide
> > service location; it provides database access.  SLP also 
> looks like a
> > simpler protocol than LDAP, and a simpler way to specify 
> the template
> > (schema) for our attributes.
> >
> > LDAP provides database access; iSNS provides active management
> > services.  I could not see using LDAP to do what iSNS does.  Josh
> > could comment further on this one.
> >
> > Both SLP and iSNS are designed to be used with LDAP; an SLP DA
> > can use LDAP as its back-end database, and clients can be served
> > using both protocols.  We felt that this capability gives us a
> > way for those who want to set up LDAP to make use of it, without
> > forcing it to be implemented in our devices.
> >
> > Anyway, LDAP does meet several of our requirements, but it 
> stands right
> > in the middle of what SLP and iSNS are used for.  It doesn't quite
> > give us what we want on the low end, and it doesn't do the 
> management
> > on the high end.  It could, however, be utilized as an excellent
> > database access protocol for these other services to be built on,
> > but that would not have to be visible to hosts and devices.
> >
> > SLP already has DHCP extensions, security extensions, etc., iSNS
> > borrows them.  All we had to do for SLP was to define a template,
> > which is just a simple version of a schema.
> >
> > --
> > Mark
> >
> > Douglas Otis wrote:
> > >
> > > Mark,
> > >
> > > If I have two servers with similar information to promulgate
> > and expectation
> > > of multi-casts reaching the target, I may find SLP 
> efforts greater than
> > > desired over standard methods found using DHCP and LDAP.  DHCP
> > can provide
> > > information of the location of the LDAP server as already 
> defined in
> > > existing boot specifications.  The BOOTP-DHCP multi-cast 
> request already
> > > have relay provisions in routers and switches because of its
> > common use and
> > > has defined entries for LDAP server discovery.  You could have
> > defined an
> > > LDAP schema that would have covered both iSNS and SLP 
> without adding
> > > additional standards efforts for building yet another protocol
> > that does the
> > > same function as protocols already in common use.
> > >
> > > For an overview see:
> > > http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/1.html#RTFToC1
> > >
> > > Could you explain why LDAP is unsuitable for this application?
> > There are
> > > many conventions within LDAP in terms of extensibility that
> > seem to make it
> > > more suitable than SLP and iSNS.  You will also find 
> security extensions
> > > already in place for LDAP merged with BOOTP-DHCP.  It 
> seems you have
> > > problems to overcome that have already been solved.  Not 
> being clever, I
> > > tend to ask dumb questions.
> > >
> > > Doug
> > >
> > > > 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
> > > >
> >
> > --
> > Mark A. Bakke
> > Cisco Systems
> > mbakke@cisco.com
> > 763.398.1054
> >
>