[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] Explicit link identifier
Hi Syam,
I looked into that when trying to work out how to put these things
together. The problem I had was that if we have a separate option,
and we end up mostly just using prefix identifiers, then we'll either
have a prefix appearing twice in RAs (once in the LinkID option and
once in the PIO/LPO), or we continue to allow the LinkID prefix to be
indicated by a flag on the relevant prefix and then have the hosts
having to look for the LinkID in either a PIO, or LPO, or LinkIDO.
Neither sounded too good.
The format I mentioned below does allow for a variable length
identifier, but with an upper limit of 128 bits.
Any thoughts?
Brett.
Syam Madanapalli wrote:
> Hi Brett,
>
> I think it is worth to relook into the Link Identifier option. Current
> definition
> is to have identifier flag in either PIO or LPIO. A host receives the LinkID
> in PIO in one RA and LPIO in other RAs. PIO contains the life time of the
> LinkID (prefix life time) and LPIO does not.
>
> So I am wondering if it is good to have a seperate LinkID Option which
> can carry any type Identifier with variable length and life time.
>
> Regards,
> Syam
>
>
> On 11/7/05, Brett Pentland <brett.pentland@eng.monash.edu.au> wrote:
>
>>Hello DNAers,
>>
>>draft-pentland-dna-protocol3-00.txt includes a concept of a link
>>identifier prefix that is implicit. Routers know the LinkID prefix
>>and make sure they include it in RAs just to ensure that there is
>>always overlap between the prefix sets included in RAs on the link.
>>Hosts don't because they are just looking for an RA with no previously
>>seen prefixes to indicate movement.
>>
>> From a few recent conversations there does seem to be some interest
>>in having an explicit link identifier.
>>
>>One way to do this might be to have a flag in the Learned Prefix
>>Option (LPO) that indicates that Prefix 1 in the option is the
>>LinkID prefix.
>>
>>For now only prefix LinkIDs would be considered, but if hosts take
>>note of the LinkID, and use it as a further check on whether it is
>>still at the old link even when there are no matching prefixes in
>>the RA, then a future extension could make use of non-prefix
>>LinkIDs by having another flag that indicates that the "prefix 1"
>>is in fact *not* a prefix. i.e. It is the LinkID, but should not
>>be added to DNAHostPrefixList. That extension would also need to
>>define how routers would select a LinkID and how they would reach
>>agreement on it amongst themselves.
>>
>>Here is a suggested LPO format. The change from the existing draft
>>is to shift the Prefix Len fields by 8 bits, and to add the two
>>flags to the new space. The rest is the same, but the first prefix
>>field may be interpreted differently, depending on the flags.
>>
>> 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 |L|P| Reserved | Prefix Len 1 |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | ... | Prefix Len N | Padding |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | |
>> + +
>> | |
>> + Prefix 1 +
>> | |
>> + +
>> | |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | |
>> + +
>> | |
>> + Prefix 2 +
>> | |
>> + +
>> | |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> ~ ...
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> | |
>> + +
>> | |
>> + Prefix N +
>> | |
>> + +
>> | |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>Some text would be needed to say how routers fill the flags, etc., and
>>what to do if the LinkID prefix is one that would normally be in a PIO.
>>Should we add a flag to the PIO format to indicate that that prefix is
>>the LinkID, or does that prefix just end up in both a PIO and the LPO?
>>There would also need to be some text in the Host Operations section
>>that explains how to interpret the LinkID since in the draft at present,
>>hosts don't know about the LinkID.
>>
>>So what do folks think? Is this a sensible way of including an
>>explicit identifier? Is 128 bits enough for future non-prefix
>>identifiers? Is this something worth pursuing? If so, why?
>>Those that have expressed interest have said that having an explicit
>>identifier is important for mesh networks, but it would be useful to
>>hear more about that or if there are other reasons as well.
>>
>>Cheers,
>>Brett.
>>