[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] DNAO format revision?
Hi Greg,
If my understanding is correct we can analyse three prefix options as
follows.
Current format: does not suit bcoz of the 8 byte alignment.
But it has good characterstic of having the prefix length for each of the
prefix mentioned just before the prefix. So processing is easier.
About varient 1: What if the number of prefixes exceed the 6? I know still
We can add the additional 8 bytes for the prefix length with appropriate
padding.
to start prefix on 8 byte alignment. also we can find the starting of the
prefix information
using length field in the DNAO and assuming the length of each prefix as
128.
About varient 2: Again the same problem when number of prefixes exceed 5.
(again same solution can do). Here the additional problem is that - How we
will decide the
length of the prefix exactly represented. Shall we assume whenever the
length is less than or equal to
64 bits it will be always 8 bytes? In that case: If in future a need arised
to advertise
16 bytes to represent the address even though the prefix is 64 bit. (Same as
'R' bit in MIPv6).
Then with this approach we are restricting such possibility.
IMHO, desired features could be:
1) 8 byte alignment. (I think 4 byte alignment is also fine)
2) Save bytes when the prefix length is less than or equal to 64 bit.
3) Can represent prefix with 64 and 128 bit even the though the prefix
length is less than 64.
4) Easy for processing.
In this respect we can make changes to varient 2 to have prefix
representation of any bytes.
OR come up with different variant.
Let me know your opinion on the same.
Thanks and Regards,
Wable R. U.
----- Original Message -----
From: "Greg Daley" <greg.daley@eng.monash.edu.au>
To: <dna@eng.monash.edu.au>; "Erik Nordmark" <erik.nordmark@sun.com>
Sent: Monday, May 23, 2005 7:51 AM
Subject: [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
>
>
>