iSNS/SLP Comparison

[Joshua Tseng <jtseng@NishanSystems.com>]

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