iSNS, SLP, and FCIP

[Black_David@emc.com]

The interim meeting notes indicate that we need to
make progress on this.  Let me start by injecting
a couple of things that either weren't discussed at
or may not have been clear from the interim meeting:

(1) 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.

(2) 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.

One caveat about the analogy in (1) above - Fibre Channel
zones are above the level of FCIP and completely transparent
to it. SLP and iSNS for FCIP would be used only for tunnel
setup - telling each FCIP device about peers to whom it
should establish TCP connections for FCIP.  Also, both of
these have some impact on iSCSI use of iSNS - I'll pick up
that topic in a separate message.

Going back over the meeting notes on this subject, I see
the following topics:

(1) Change notification (RFC 3082)
(2) Scope vs. discovery domains
(3) Periodic re-registration timing values
(4) SLP only supports strings
(5) Centralized administration

Taking these up in order ...

-- (1) Change notification

There are two cases here, initial discovery and loss of
connectivity.

For initial discovery, FCIP may not need change notification
*because* it's a peer to peer protocol (as opposed to client-
server), so it doesn't matter who sets up the initial TCP
connection.  For the situation in which some FCIP devices
are up and running and a new one comes up, SLP-based discovery
at the new device is sufficient to set up everything.

The FCIP draft doesn't appear to contain any words about how
to deal with concurrent setup - i.e., both peers initiate setup
at the same time, resulting in two parallel TCP connections that
aren't associated with a single FC link.  Some text on this topic
should be added to the FCIP draft.

For loss of connectivity, either FCIP or something running over
it (e.g., FSPF) is going to heartbeat each connection, and so
no external mechanism seems to be necessary.

The one situation that doesn't seem to be covered here is a
partial loss of connectivity (FCIP device loses touch with one
of its peers, but not all of them).  These scenarios tend to be
messy, and I'm not sure how iSNS compares to SLP in dealing
with them (loss of connectivity to an iSNS server seems to
have more severe impacts than loss of connectivity to an SLP
DA).

-- (2) Scope vs. discovery domains

For FCIP, these appear to be essentially the same concept since
SLP scopes can overlap in the same fashion as iSNS discovery domains.
iSNS is somewhat better at information hiding - with SLP, each agent
knows what scope(s) it's in, whereas with iSNS, that information is
private to the nameserver (similar to Fibre Channel).  This may make
a big difference if static configuration and more than a handful
of scopes are involved, but appears to be less of an issue if
DHCP is used.

-- (3) Periodic re-registration

SLP registrations with a Directory Agent carry a lifetime
that defines both how long the DA can cache the registration
and the period within which the registration must be
refreshed.  This results in additional traffic to do the
refreshes.  Lifetimes are measured in seconds, and RFC 2608
recommends a default of 5 minutes before an idle TCP connection
is closed.  This suggests that a few minutes for a re-registration
period may be reasonable, and doesn't sound like a cause for
a lot of traffic for moderate-sized configurations.  iSNS
usage should generate less traffic, regardless.

-- (4) SLP only supports strings

As does iSCSI.  OTOH, turning an X.509 cert into a string is
not exactly pleasant, but OTOH FCIP doesn't seem to have a
requirement for distributing non-string parameters.  This
may change as FCIP security is more tightly specified.

-- (5) Centralized administration

RFC 2610 provides a way for DHCP to be used to centrally
administer SLP (and do so in a fashion where the only
multicast-like things are DHCP's link-level broadcasts).
On the assumption that FCIP connectivity among N devices
is considerably simpler in structure than typical FC zoning
among N ports, this seems to scale up to reasonable-sized
configurations (several dozen FCIP devices should not be a
problem, I'm not sure about more than 100).

This is all for further discussion and comment, although
it does not appear to present a strong case for use of
iSNS with FCIP.

Thanks,
--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
---------------------------------------------------