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

From: [email-masked]
Date: Thu, 29 Sep 2005 10:26:00 -0700

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: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Bernard
Aboba
Sent: Thursday, September 29, 2005 10:02 AM
To: [email-masked]; [email-masked]
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.

---

From: gabriel montenegro <[email-masked]>
Date: Thu, 29 Sep 2005 11:45:40 -0700 (PDT)

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