[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] DNAO format revision?
variant 1. prefixes have always been 128 bit fields, atleast,
in whatever IETF IPv6 specs I have worked with.
Vijay
Greg Daley wrote:
> 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
>