Re: [DNA] Explicit link identifier

[Raquel Morera <raquel@research.telcordia.com>]

Hi Brett,

   I think having the option of an explicit link identifier is actually 
a very good idea.
In mesh/ad-hoc networks, adding an explicit link ID can help identifying 
the link (i.e. mesh) independently of the prefixes that connect the 
network to the internet.
I do not know yet how DNA and link identifier would fit in the protocols 
designed for these networks (not even sure if there is a consensus in 
the definition of a "link"), but having the option would be great as it 
gives us the flexibility to explore it when needed.

Thanks,
   Raquel


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