Subject: Re: [DNA] DNAO format revision?

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 06 Jun 2005 18:07:22 -0700

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
>