[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: reserving some SAIDs

Russ,

	We have a slight problem with alignming the SILS SAID and the
IPSP SAID, in that we were planning to make the four high order bits
of the SAID a version number field for the protocol, leaving us with 
a 28-bit SAID.  This doesn't show up in Ran's diagram.  The motivation
was that a different version of IPSP should retain the same protocol
ID (its not a big space), and we wanted a way to distinguish among
a few different versions of IPSP.

	Still, the discussion of 4 reserved values for SAIDs is a
useful one, even if we don't wind up using the same bits.  I
understand the motivation for having a bit to differentiate between
multicast and unicast SAIDs, because the selection criteria is
different, i.e., in the latter case the destinations do not select the
SAID.  Is the model that, for a packet with a multicast SAID, this
SAID may not be unique at the destination, because the same SAID may
have been used for different multicast address groups to which the
destination may belong?  In that case, is the intent to use the
destination multicast address to uniquely qualify the SAID?  If the
recipient examines the desitnation address first, and then looks for
SAIDs based on that qualifier, the processing would seem to be the
same for unicast and multicast.  This approach would make the task of
selecting a multicast SAID easier for whoever manages the multicast
address, since there would be no requirement for global uniqueness,
only uniqueness relative to the multicast address.  That makes sense
to me, but I wanted to get confirmation from your perspective in the
SILS community.  Any feedback from Internet multicast experts would
be appreciated too.

	The second aspect of the reserved SAIDs is use for key and
system management.  I assume the intent here is to use the same
protocol ID for key/system management packets, but to reserve these
two SAIDs to allow such packets to be vectored to the key/system
management entity.  Is this mostly a means of economizing on protocol
ID space and allowing efficient vectoring for all security-related
packets?  I'm not sure that we have a need for the system (vs. key)
management aspect of this, but it would not be too wasteful to reserve
the obvious value for that or some other purpose.  Again, just
checking to make sure that the intent behind the standards text is
understood.

Steve
References: