Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.21] [DNA] Prefix information for link identification in DNA



Hello Yoshihiro,

I would like to make a general statement regarding the definition of PoA.

I believe that the application of the PoA definition to an AP/BS/Switch/Router
(i.e., to a network node) is not appropriate and may generate confusion. The PoA
definition should instead be tightly associated with the notion of "link": the
PoA is in fact a particular case of link endpoint, or, even better, one endpoint
on a particular type of link ("a link that has a UE as one of its endpoints"). A
given network node may contain multiple link endpoints, some of which are PoA's
while others are not.

After establishing that a PoA is a link endpoint and not a network node, the
group can find it easier to determine if the PoA definition should only apply to
the L2 case (i.e., PoA is intrinsically an L2-link endpoint, no matter if
residing in a BS, AP, switch, or router) or generically to both L2 and L3 cases
(so that "L2 PoA" and "L3 PoA" must be used to identify the specific case being
considered). This way the forwarding capabilities of the network node (L2 switch
or L3 router) become orthogonal to the definition of PoA (although it remains
true that no L3 PoA can be found in an L2 switch).

Thanks,

Andrea


Yoshihiro Ohba wrote:
> 
> 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.
> >