Re: [DNA] DNAO format revision?

[Greg Daley <Greg.Daley@eng.monash.edu.au>]

Hi Wable, 

----- Original Message -----
From: Ranjitsinh Wable <wable@samsung.com>
Date: Tuesday, May 24, 2005 9:17 pm
Subject: 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.

One pointer/reference is needed rather than two, so I guess that
may be called 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.

Yes, it was intentional to use the length to describe the number of 
prefixes.
This is only available since the records are constant length, though.

Also, the padding beyond the sixth is intentional also.

 
> 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.

The mechanism provides for 65-128 bit addresses to have a length
of 16 octets (actually, I'm providing  8 << ((unsigned) plen - 64)
octets of space in RADVD).


> 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.

I'm unsure as to the application for this though.
More elaboration may be needed.

> 4) Easy for processing.

Sounds good.  

If you've got some ideas of how these can be put together, 
I think we'd be interested.

> In this respect we can make changes to varient 2 to have prefix 
> representation of any bytes.
> OR come up with different variant.

Perhaps.  There's a trade off between future proofing an idea 
(depends a lot on the future), and goal 4...

> Let me know your opinion on the same.
 
Perhaps the idea of Variant 1 would suit in the short term...
It's sufficiently simple, and though it doesn't reduce the number
of octets used, it may be able to support future use...

I'd be happy to see more ideas, but perhaps Variant 1 will do 
for now (for the reasons Erik mentioned).

Greg