[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[DNA] DNAO format revision?
Hi DNA,
I've been talking to Erik and most of my questions regarding
the DNA proposal have been answered.
What I'd like to do now is to ask questions about message
formats and text, in a way which reinforces the hard work
undertaken by the DT.
Here's Q number 1:
Is there a DNA option format which we can agree upon which
preserves Prefix alignment on 8 octet boundaries?
I guess alignment is desirable to allow consistency with
earlier specifications 2461, 3810, and potentially allow
word-size based operations on some hosts.
At the moment, the option format contains a list of
sequential 17 octet records.
With 2 prefixes, the current format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Len 1 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ Prefix 1 +
| |
+ +-+-+-+-+-+-+-+-+
| | Prefix Len 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix 2 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (32bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Erik has convinced me of the need to support 128 bit
prefixes in DNA, for future expansion, but it may be
possible to achieve this while preserving alignment.
One variant makes use of the ordering of prefixes and
their lengths but uses two separate lists (one for
the lengths and one for the prefixes. Pad is introduced
at the end of the list of prefix lengths, instead
of at the end of the option.
I'll call this Variant #1:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Len 1 | Prefix Len 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (32bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix 1 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix 2 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It's also possible to have differing storage for
prefixes, so long as it is 8 octet aligned:
The differing legnths of prefix mean that a number of prefixes
indication is required a the front of the prefix length list,
to remove ambiguity (it's not inferred just by the option length).
I'll call this variant 2:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | # prefixes | Prefix Len 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Len 2 | Padding (24 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix 1 (128 bits) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Prefix 2 (64bits) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Variant 1 (along with the current option format) has
the advantage that records are constant length, and that
the prefix lengths don't have to be read in order to
locate any particular prefix.
Variant 2 has the advantage that if the prefix length is
less than or equal to 64 (today's common case), the
storage used is only 8 bytes. A host would have to read
the list of prefix lengths in order to parse the prefixes though.
Does anyone have an opinion as to whether a change to the
DNA option would be good or not?
Please respond indicating if you like any of the
existing proposals (Current, Variant 1 or Variant 2),
or prefer something different.
Greg