Compressing Large Indices?

[Tim Jenkins <tjenkins@TimeStep.com>]

Hi,

I have a question related to the IPsec Monitoring MIBs that John Shriver and
I are working on.

We have a table that has a number of indices. It's actually a helper table
to look up specific rows of another table that has an arbitrary integer as
index. Unfortunately, two of the indices of the first table are variable
length octet strings. (They're actually the phase 1 IDs used in IKE, so have
a type as well as a raw octet buffer.)

This violates the sub-identifier length limits, as well as chewing up lots
of space on the wire. So, it was suggested that we use a hash of the desired
indices that are variable length to be the real indices and put the desired
indices (the IDs) in the table. Alternatively, I was thinking about using a
single hash whose inputs are all of the desired indices of this table, since
there are a few of them.

So, the questions are:
1) Is this the best approach?
2) If so, what hash should we use? (I guess I'm looking for a precedent,
rather than inventing something.)

For the hash selection, we can tolerate a hash function that is not
particularly collision resistant, since there's already the possibility of
duplicates based on the raw IDs and we have to deal with that, but the
potential table size is very large in some vendors' implementations,
certainly exceeding 10,000 entries, and perhaps even an order of magnitude
larger.

A draft of the MIB is available at
<http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-monitor-mib-00.txt
>. The tables that must be changed are "saByCreatorsTable" and
"suiteByCreatorsTable".

Thanks for any help,

Tim

---
Tim Jenkins             Newbridge Networks Corporation
tjenkins@timestep.com          http://www.timestep.com
timj@newbridge.com            http://www.newbridge.com
(613) 599-3610 x4304               Fax: (613) 599-3617