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



On Fri, Sep 30, 2005 at 10:33:21AM -0500, stefano.faccin@nokia.com wrote:
> Yoshi,
> I agree that a PDP can be considered as a specific tyoe of link. Activation of some PDP contexts imply also obtaining an IP address (i.e. the first PDP), others don;t (subsequent PDP contexts activated in parallel to the first one). 

Yes, I think so.

> Another way of looking at this is that we can consider the whole set of PDP cntexts betweent he UE and a given GGSN as a single link, and when you create/delete PDP contexts you're modifying the link. 

This is IETF definition of "link" for 3GPP as described in RFC 3314.

> However, I am more comfortable with the previous definition.

Then, I think you are agreeing with "link==L2 link" definition for
802.21.

Yoshihiro Ohba


> Stefano
> 
> ________________________________
> 
> From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> Sent: Fri 9/30/2005 10:29 AM
> To: Faccin Stefano (Nokia-NRC/Dallas)
> Cc: yohba@tari.toshiba.com; STDS-802-21@listserv.ieee.org
> Subject: Re: [802.21] [DNA] Prefix information for link identification in DNA
> 
> 
> 
> Stefano,
> 
> Thanks for the answer. 
> 
> Next question is, should a Link-Up event be generated for each PDP
> context (primary or secondary) that shares the same IP address? 
> 
> Since each PDP context can have different QoS characteristics, I think
> it is good to define each PDP context as a "link" to have better
> handover control with QoS support.  If an IP address is immediately
> assigned when a PDP context is established, that is OK, it just means
> that at the time when a Link-Up event is generated for 3GPP, there is
> always IP connectivity.  Do you see a particular problem with defining
> a PDP context as a "link" in 802.21?
> 
> Also, I have a feeling that we might need a clear definition of "link"
> in each media-specific amendment.
> 
> Yoshihiro Ohba
> 
> 
> 
> On Fri, Sep 30, 2005 at 07:42:48AM -0500, stefano.faccin@nokia.com wrote:
> > Yoshi,
> > this is a good example. Link up (link_X) indicates that link_X is available to carry data. Since the MIH users of this event are at IP layer and above, they would not have use of an indication stating that the UE has setup a L2 connection with a BSS or SGSN (since that is only signalling, not user plane). Link up in this case means that the UE has a usable PDP context with a GGSN and therefore has been assigned and IP address, so that the link can be used to carry data. Connecting with the GGSN means automatically getting an IP address, by the way. You cannot getting a usable PSP context without getting an IP address.
> > 
> > Stefano
> >
> > ________________________________
> >
> > From: ext Yoshihiro Ohba [mailto:yohba@TARI.TOSHIBA.COM]
> > Sent: Thu 9/29/2005 8:43 PM
> > To: STDS-802-21@listserv.ieee.org
> > Subject: Re: [802.21] [DNA] Prefix information for link identification in DNA
> >
> >
> >
> > On Thu, Sep 29, 2005 at 07:07:43PM -0500, stefano.faccin@nokia.com wrote:
> > > 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).
> >
> > One question: Should a Link-Up event for GPRS be generated after the
> > UE is assigned an IP address, or just after L2 connectivity to some
> > link end-point (BSS, SGSN or GGSN?) is established?
> >
> > Yoshihiro Ohba
> >
> >
> >
> > > 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.
> > > >
> > >
> > >
> >
> >
> 
> 
> 
> 
> 
>