Subject: Re: [DNA] DNAO format revision?

From: Greg Daley <[email-masked]>
Date: Wed, 25 May 2005 09:43:05 +1000

Hi Wable, 

----- Original Message -----
From: Ranjitsinh Wable <[email-masked]>
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

---

From: Ranjitsinh Wable <[email-masked]>
Date: Wed, 25 May 2005 12:57:27 +0530

Hi Greg,

We can have different formats for the same.
but everything comes with their own advantages and limitations.

Below I suggested one more varients. Let me know your opinion on the same.

But I also perfer the Varient 1 you proposed as
it is more simple and no problem of 16 bytes representation
of prefexes which are less than or equal to 64. Only problem it will waste 
some bytes.
But its ok, unless somebody comes up with some good solution.

Thanks and Regards,
Wable R. U.

Varient 3:

    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     |               Reserved 
|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix Len 1  |     Resv      | R|               Reserved 
|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 
|
   + 
+
   | 
|
   +                               Prefix 1 (128 bits) 
+
   | 
|
   + 
+
   | 
|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix Len 2  |     Resv      | R|                Reserved 
|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 
|
   +                                Prefix 2 (64bits) 
+
   | 
|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix Len 3  |     Resv      | R|                Reserved 
|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 
|
   + 
+
   | 
|
   +                                Prefix 3 (64bits) 
+
   | 
|
   + 
+
   | 
|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                 Padding(32 Bit) 
|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here the Prefix 1 is 128 bit R = 1.
Prefix 2 R =0.
Prefix 3 is 64 bit but still represented with the 16 byte so R=1.

Assuming the fact that most of the time the prefix length will be less than 
or equal to 64
we will be able to save at max 4 bytes per prefix. Alignment will be 4 
bytes.

Also here we have reserved field to convey more informations about the 
prefixes.
I agree there is no such need now and hence may be just place holders.