SLP, iSNS, and iSCSI

[Black_David@emc.com]

I previously noted a couple of thing about SLP that
appear not to have been part of prior discussions:

[A] SLP scopes are allowed to overlap in a fashion
similar to Fibre Channel zones -- Service, User,
and Directory Agents can each be in multiple scopes.

[B] RFC 2610 specifies DHCP options for configuring
SLP Directory Agent locations and SLP scopes for both
User and Service Agents.  This would allow DHCP to be
used for centralized administration of an SLP
infrastructure, and works even when DHCP is not used
for IP address assignment.

Going back to Josh Tseng's analysis of SLP and
iSNS for iSCSI, Josh covered the following topics:

(1) State Change Notification
(2) Multicast
(3) Zoning and Discovery Domains
(4) Heartbeat
(5) Non-string attributes
(6) Security

This is a note about the impact that [A] and [B]
have on these 6 items, plus some related comments
based on the SLP notification mechanism in RFC 3082

-- (1) State Change Notification

[A] and [B] don't seem to affect this area.  RFC 3082
provides some level of support (but see next item).
From a process standpoint, RFC 3082 is experimental,
and hence can't be required by a standards-track
document.  Unlike FCIP, iSCSI is client-server and
hence has a use/need for some way of informing clients
(Initiators) that a new server (Target) has appeared.

-- (2) Multicast

SLP requires both service and directory agents to listen for
multicast requests, but can be configured in a fashion where
they're never used.  The RFC 3082 notification mechanism
*requires* multicast, which is likely to be an issue in
larger networks and some VPN situations.

-- (3) Zoning and Discovery Domains

Both [A] and [B] matter here, and the appropriate
comparison is probably SLP + DHCP vs. iSNS.  For
SLP + DHCP, it looks like SLP scope is usable in the
same fashion as an iSNS Zone/Discovery Domain, modulo
issues with State Change Notification [(1) above].

-- (4) Heartbeat

Neither [A], [B] nor RFC 3082 affect this area, but
it doesn't seem to be a major issue -- the concern
is how long an SLP Directory Agent may cache information
for and hence how often an SLP Service
Agent has to refresh its registration(s).  A few minutes
might be a good answer here since that's the default time
for SLP to keep idle TCP connections open.

-- (5) Non-string based attributes

[A], [B], and RFC 3082 appear not to have any effect here.
Whether we need to distribute things like X.509 certs through
the SNS appears to be an open issue.

-- (6) Security

The fact that multiple scopes can be used and that the
DEFAULT SLP scope can be removed from SLP directory agents
(RFC 2608, Section 12.4) appears to remove the argument
that the SLP Directory Agent is a central point of trust.
DHCP doesn't need to replace it as a central point, as
DHCP is readily partitionable along network topology
boundaries.

An important note about this area is that iSCSI access
control departs from the model(s) used in Fibre Channel
in an important aspect.  In Fibre Channel, end systems
trust the Fabric to handle certain aspects of access
control - both soft and hard zoning are primarily
implemented in switches (and soft zoning also trusts
HBAs to not do port scans).  For iSCSI, Targets are going
to find themselves more involved in access control and
authentication of Initiators.  There will be cases such
as strict VLAN configuration along with no layer 3 gateway
out of the VLAN reproduce Fibre Channel-like configurations,
but iSCSI will need to operate in more general networks.

This is all for discussion.  An initial take on this
is that State Change Notification (1) is still an area
in which SLP appears to fall short of iSNS, especially
if RFC 3082 notification is ruled out of bounds due to
its dependence on multicast.  OTOH, DHCP appears to
be a viable route to central administration of SLP.

Comments?,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------