RE: [DNA] Prefix information for link identification in DNA

[gabriel montenegro <itijibox-dna@yahoo.com>]

Are both discussions focusing on the same type of link? 
This cautionary note from http://tools.ietf.org/wg/dna/draft-pentland-dna-protocol-01.txt
is worth keeping in mind:

   The term "link" is used as defined in RFC 2460 [2].  NOTE: this is
   completely different from the term "link" as used by IEEE 802, etc.

As for the question on the subject line, I agree with Bernard in that 
as long as DNA causes no harm, we should be ok. The way I see it, DNA is two
things: an optimization over a base mechanism (eliminating delays in base ND/RD),
and new functionality (identifying links). As for the optimization part, I see
it justified when you do have routers and when you do have established sessions
for time-sensitive apps. But if you're suddenly going to a network in which there
are no routers, I find this usage scenario not very likely. Yes, there's counter-examples
in ad-hoc networks, but derailing DNA to target this would probably add much delay to the
much more prevalent router-based scenarios. So I question if one
needs the optimization part of DNA. One may wish to benefit from identifying links
("Am I at a different router-less/ad-hoc network than the one I was at before?"),
and to use the "link-ID" (as opposed to CPL) proposal within DNA. 
I hear similar things have been proposed by research groups on 
ad-hoc already, so they're interested. 

At any rate, even if one does adopt, say, link-ID for ad-hoc, it's not clear to me 
whether fully specifying its application for ad-hoc belongs in DNA. Perhaps 
AUTOCONF (or MANET) needs this functionality and could feed that requirement to DNA. 
But after taking the base definition  from DNA they could pursue a fuller specification
there. 

-gabriel

--- Michael.G.Williams@nokia.com wrote:

> Colleagues,
> 
> Within IEEE 802.21 WG last session, there was some discussion of how to
> identify or name a "link" for use in remote scope/remote references if
> necessary. This issue was also raised in the "link indications" paper in
> progress from Bernard Aboba. Let's have some email list discussion on if
> there is any relation or synergy possible with the thread below.
> 
> Best Regards,
> Michael
> 
> -----Original Message-----
> From: owner-dna@ecselists.eng.monash.edu.au
> [mailto:owner-dna@ecselists.eng.monash.edu.au] On Behalf Of ext Bernard
> Aboba
> Sent: Thursday, September 29, 2005 10:02 AM
> To: brett.pentland@eng.monash.edu.au; dna@eng.monash.edu.au
> Subject: RE: [DNA] Prefix information for link identification in DNA
> 
> >He thought that it is questionable to assume that:
> >
> >    1) Every network has a router.
> >    2) you can name a network using one of its prefixes.
> 
> There are certainly adhoc networks in which there is no router.
> However, 
> detecting attachment to such a network is quite difficult, because nodes
> may join and leave and therefore there is no L3 invariant.  That is why
> the
> DNAv4 reachability test cannot be used to detect attachment to adhoc
> networks, but rather adhoc attachment is concluded after failiure of all
> other approaches (reachability test, DHCPv4, etc.)
> 
> I would also agree that there are situations in which a network cannot
> be named using one of its prefixes.  In DNAv4, a private network is not
> suitable for identification because it is not unique.
> 
> >So if a link has no router and no prefixes except the link-local prefix
> 
> >(which will be the same for all links) we have a problem.
> 
> I would say that a "problem" only occurs if DNA somehow makes the
> situation worse.  If a link has no router and no prefixes except
> link-local, then the best that can be achieved is for a host to utilize
> the link-local address.  
> Unless DNA somehow impedes that, it may not do any good, but it also
> does no harm.
> 
> >I'm not sure what we can reasonably do at layer 3 if there is(are) no 
> >router(s) present on the link to help the hosts identify the link.  
> >(Any ideas?)
> 
> The best you can do at L3 is to use a link-local address.
> 
> 
>