[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] Explicit link identifier
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.
>