FW: iSNS/SLP Comparison

[Joshua Tseng <jtseng@NishanSystems.com>]

I've been asked to re-post this message.  Once again,
if anyone has comments on SLP and how it can/cannot
be used in the SNS role, please respond to the
this message on the reflector.  Same for any other protocol
(LDAP, SNMP, RADIUS, COPS, etc...). 

Thanks,
Josh

>  -----Original Message-----
> From: 	Joshua Tseng  
> Sent:	Thursday, March 22, 2001 10:01 AM
> To:	ips@ece.cmu.edu
> Subject:	iSNS/SLP Comparison
> 
> Folks,
> 
> As promised, here is the text of the detailed analysis completed several
> weeks ago on
> the feasibility of using the SLP protocol to support the storage name
> service functionality
> for iSCSI.  This issue was hashed and rehashed multiple times within the
> Naming &
> Discovery Team.  Mark Bakke and I had numerous online and offline
> discussions on
> SLP and iSNS, and in the end we both concluded that SLP would not provide
> the needed
> functionality for a storage name service.  Rather, we agreed SLP can be
> used to do
> simple discovery of iSCSI targets in a device-centric management model,
> without the
> aid of the iSNS.  On the other hand, iSNS would provide the centralized
> management
> function that would allow iSCSI to scale to enterprise-class networks.
> 
> The bottom line is that iSNS is a storage-aware application that is aware
> of client attributes,
> and can take appropriate action when events occur in the network.  SLP is
> a generic
> discovery protocol and has no intelligence of storage devices and their
> attributes.  LDAP
> alone is inappropriate for a similar reason in that it is a generic
> protocol, not an application.
> However, both LDAP and SLP can be used to support the iSNS application.
> LDAP to
> store and distribute attribute values in a directory-enabled iSNS
> implementation, and
> SLP to discover the iSNS service itself.
> 
> Josh
> 
> ---------------------------------------------
> 
> Comparisons between iSNS and SLPv2:
> 
> 1)  State Change Notification:  
> 
> SLPv2 does not currently support it.  This is an important function that
> exists in enterprise-scale Fibre Channel SANs.  For SLPv2 to be feasible
> for large enterprise-scale storage networks, it would have to incorporate
> an asynchronous messaging mechanism that is closely tied to entities
> identified by service attributes.  Specifically, this means SLPv2 must
> develop the intelligence to recognize a significant event, identify the
> entities (i.e., WWUI's) that are affected by that event by examining the
> DD/Zoning of each entity, and send a directed unicast message to the
> entities represented by those WWUI's.
> 
> Such functionality seems to be beyond the intent and scope of SLP.  WWUI
> would be stored as an attribute, and in SLP, attributes are simple values
> which carry no significance to SLP.  It is beyond the purpose of SLP to
> interpret the contents of any attribute stored for a service.  However, in
> order to support SCN's, SLP would need interpret the WWUI attribute values
> and map it to a destination IP address (i.e., extract the URL attribute
> and query for an IP address) for the State Change Notification.
> 
> Therefore, we cannot count on SLP's ability to fulfill the State Change
> Notification requirement, even with future upgrades to the SLP protocol.
> 
> 2)  Multicast
> 
> RFC 2608 contains "MUST" language that requires SA's to listen to
> multicast requests from UA's and DA's.  However, in order to fulfill the
> SNS role, SA's do not need this capability, and multicast should not be
> used in many cases.  An implementer will be faced with the choice of
> either compliance with the RFC 2608 and implementing a capability that is
> not needed, or being non-compliant and implementing only what is needed
> for the SNS.  There are other areas in SLP which describe capabilities
> that are not needed for SNS.
> 
> Multicast is not required for SNS because it may not be available in some
> networks, particularly the Public Internet or in a business partner's
> network.  I shall assume no multicast functionality, since SNS must be
> able to work over the Public Internet per IETF Charter.
> 
> 3)  Zoning/Discovery Domains:
> 
> The scoping functionality cannot be used for "Zoning/Discovery Domain"
> capability, because common scoping is a requirement for even DA's and SA's
> to communicate with each other.  SLP assumes SA's, UA's, and DA's are
> already configured with the appropriate scoping, and SLP itself cannot be
> used to create, delete, or modify a scoping of an SA, UA, or DA, because
> they can't even communicate unless they already have common scoping.
> Therefore, a new attribute such as "Zone" in Mark's template is needed.
> But is the Zone an attribute of the WWUI or iSCSI instance?
> 
> At the current time, it's unclear if the service represents a single WWUI,
> or an "iSCSI Instance" which may have multiple WWUI's.  Either way, there
> is a disadvantage:
> 
> a.  If the service registers an iSCSI Instance, then the Zone/Discovery
> Domain is an attribute of the service (i.e., iSCSI instance), and not of
> the WWUI (i.e., iSCSI device), ALL WWUI's belonging to the iSCSI instance
> must be assigned to the same Zone/Discovery Domain.  That means, if an
> iSCSI target device has 50 WWUI's, then all 50 must be assigned to the
> same Discovery Domain, and initiators must perform an iSCSI login to each
> of the 50 devices.  While a native iSCSI device with 50 controllers may be
> rare, the real impact is on iSCSI-FC gateways.  The gateway must proxy for
> a network of Fibre Channel devices, and the gateway will likely represent
> each FC device with a WWUI (using the "eui.xxx" WWUI format).  But that
> means the user has no means of limiting access and discovery to a subset
> of devices in the FC network.
> 
> b.  If the "service" registers a single WWUI, then each "iSCSI instance"
> will have to register multiple times if it supports more than one WWUI.
> Once again, an iSCSI-FC gateway will have a large number of individual
> registration messages to send for any change to its attributes, and
> updates to receive for any change in status to other members in a common
> Zoning/Discovery Domain.  For example, if the gateway supports 50 FC
> devices that are in a common Zone with initiator I, and initiator I is
> somehow removed from the Zone then the iSCSI-FC gateway will need to query
> the DA 50 times in order to make this simple update.
> 
> And the last significant issue I'm aware of with Zones/Discovery Domains
> is that since the Zone is already an attribute, additional attributes
> cannot be associated with the Zone.  This means a VLAN tag, multicast
> group address, or user-assigned symbolic name cannot be stored as an
> attribute of the Zone, in the DA.
> 
> 4)  Heartbeat/Client Status Inquiry:
> 
> SLP accomplishes this function through a multicast DAAdvert.  However, SLP
> does not specify an alternative if multicast is not available.  Rather,
> SLP relies on the SA's and the UA's to continue refreshing their
> registrations in the DA at regular intervals.  The refresh interval is
> dependent on the SA and UA settings, and is an interval between 0 and 18
> hours.  Since the DA has no control over the interval at which SA's send
> in registrations, it could get overwhelmed if there are a large number of
> SA's and UA's query for and register data.  And the only way that the DA
> can discover (in the absence of multicast) that an SA has been removed
> from the network, is to wait until the timeout interval expires for SA
> registration refresh.  Set the expiration timer too low, and the SA's will
> be re-registering with the DA too often and overwhelm it.  Set the timer
> too high, and it could be hours or days before the DA discovers that an SA
> (i.e., iSCSI target) has disappeared.  That would be unacceptable for an
> enterprise-class user.
> 
> This is the original reason why SLP relied on the multicast advertisement.
> There is no unicast advertisement originated by the DA that I am aware of
> that is not in response to a multicast request by an SA.
> 
> On the other hand, iSNS unicasts heartbeat messages to each iSNS client,
> and can adjust the interval at which it is comfortable sending out
> heartbeats, depending on its processing load.
> 
> 5)  Non-string-based attributes:
> 
> SLP is optimized to store and transmit string-based attributes.  However,
> the SNS must be able to store non-string attributes, such as an X.509
> public key certificate.  The only way that SLP can do this is if it
> escapes each byte of binary data.  This "escaped" SLP formatting will
> effectively double the size of the original X.509 certificate.  This is an
> additional burden for iSCSI devices, that will need to take the X.509
> "blob" and place an "/" between every byte of binary data.  Processing
> requirements for the DA host (which are already significantly more than
> iSNS server from the above issues 1-4), will also be increased as the a
> companion application on the DA host may need to extract the original
> certificate so that it can verify the signature and authenticate its
> origin.
> 
> Also, doubling the size of the X.509 certificate in the SLP protocol
> message may overflow the size of the multicast datagram, which is a no-no.
> 
> 6)  Security:
> 
> Because the DA, SA, and UA are all using the same scope ("SNS"), and Zone
> is now an attribute of the iSCSI device (either the WWUI or the iSCSI
> Instance), the DA (i.e., the SNS) must trust each of the SA's as far as
> access authorization.  Although initiators are not supposed to change the
> attributes of a target, nothing prevents a wayward initiator from doing it
> anyway.  Once again, attribute values have no significance to SLP, and
> there is no way for SLP to disallow a query or registration command by
> examining the value stored in an attribute field for the service that is
> the object of the query or request.
> 
> This will become an issue when sharing the DA database with a business
> partner.  Even if a new special "Zone" or "Discovery Domain" is created,
> and only devices that an enterprise intends to share with the business
> partner is placed into that "Discovery Domain", there is nothing which
> prevents the business partner from doing an SLP query with no "Discovery
> Domain" attribute.  This will result in ALL devices registered in the DA
> being returned.  The business partner now has access to all devices stored
> in the DA, and can do unlimited damage if they desire.
> 
> CONCLUSION:
> 
> I believe there may be other issues which have yet to be discovered,
> regarding use of SLP in the SNS role for a large enterprise-class storage
> network.  My suggestion is that we limit the use of SLP in iSCSI to
> discovery only.  We can recomend and use SLP for simple discovery of iSCSI
> devices, as well as discovery of the iSNS.  But let's not encourage SLP to
> be used in a role for which it was not designed.
> 
> My concern is that if we talk or hint about the possibility of using SLP
> to fulfill the SNS role, those that take this path will invest
> considerable engineering effort only to find in the end that there are
> insurmountable issues in supporting large, enterprise-class storage area
> networks.  SLP simply was not designed for the SNS role.  Attempting to
> force SLP to do what it wasn't designed for will result in consequences
> down the road if anyone takes our errant advice to do so.
> 
> Josh
>