Subject: [DNA] Explicit link identifier

From: Brett Pentland <[email-masked]>
Date: Mon, 07 Nov 2005 19:00:14 +1100

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.

---

From: Syam Madanapalli <[email-masked]>
Date: Mon, 07 Nov 2005 19:30:58 +0530

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

---

From: Brett Pentland <[email-masked]>
Date: Wed, 09 Nov 2005 11:55:39 +1100

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.

---

From: Raquel Morera <[email-masked]>
Date: Wed, 09 Nov 2005 03:27:22 -0800

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