RE: [802.21] [DNA] Prefix information for link identification in DNA
Yoshihiro,
I'm not sure why should restrict the term PoA to have only a L2 meaning as you suggest below. I think we should distinguish clearly between L2 PoA and L3 PoA. For me, the L3 PoA is where the terminal gets IP conenctivity. E.g. for GPRS the L3 PoA is the IP link on which the GGSN is located. In L2, PoA is the point where the access-specific L2 connection terminates (e.g. an AP in 802.11).
Stefano
________________________________
From: ext Yoshihiro Ohba [mailto:yohba@TARI.TOSHIBA.COM]
Sent: Thu 9/29/2005 3:42 PM
To: STDS-802-21@LISTSERV.IEEE.ORG
Subject: Re: [802.21] [DNA] Prefix information for link identification in DNA
IETF and IEEE have different notion of "link". I think the IETF DNA
WG discussion below is for link identification for "IP link", whereas
I believe that IEEE 802.21 WG is interested in identifying "L2 link"
(i.e., a connection between UE and AP/BS/Switch/Hub).
Speaking about the latter, as I presented in the .21 WG last session,
an L2 link can be identified with a pair of PoA type and PoA
identifier, where a PoA is an L2 point of attachment such as
AP/BS/Switch. RADIUS NAS-Port-Type can be used as a PoA type. A
string that is unique within the PoA type (e.g., BSSID) can be used as
the PoA identifier. A special case would be that the UE is connected
to Ethernet via a hub which may not have any MAC address. In this
case, the PoA identifier can be null.
Also, we have to agree on the definition of PoA since the term PoA is
used in many places in the draft text. Some people are talking about
"L3 PoA" such as an access router, but I think this is confusing and
should not be considered. If we are interested in "L2 link", then the
definition of PoA should be the one (L2 PoA) that is more associated
with "L2 link" than IP link. Of course, an AP/BS/Switch may also have
the functionality of router, but even in this case we should not call
it L3 PoA.
Yoshihiro Ohba
On Thu, Sep 29, 2005 at 10:26:00AM -0700, Michael G. Williams 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.
>