RE: Re : [802.21] contributions for upcoming May 2004 meeting - ARID
Hi all,
How is it possible to get access to the current version of our requirement documents, as well the presentations that were made during the may meeting? The folder that was accessible from the local network in the meeting premises is not available from outside....
thanx
Eric Njedjou
> -----Original Message-----
> From: owner-stds-802-21@listserv.ieee.org
> [mailto:owner-stds-802-21@listserv.ieee.org]On Behalf Of
> Michael.G.Williams@nokia.com
> Sent: mercredi 5 mai 2004 00:36
> To: xiaoyu.liu@SAMSUNG.COM; ajayrajkumar@LUCENT.COM
> Cc: cchaplin@SJ.SYMBOL.COM; STDS-802-21@listserv.ieee.org
> Subject: RE: Re : [802.21] contributions for upcoming May
> 2004 meeting -
> ARID
>
>
> In addition to the ARID concept, the NAI was also proposed
> (informally). Under the general concept of "hints" there are
> a number of distinguishing bits of info (like the prefixes)
> that might be useful. There might even be L2 info ;^)
>
> If the mobile is going to participate in generating hints, it
> might need a way to refer to the network attachment point for
> informing about a handoff proactively.
>
> Since we have the IETF groups (DNA, Mobile IPv6 and v4,
> MIPSHOP, IRTF MOBOPTS) interested in our services, let's make
> an effort to understand their input/requirements and meet them.
>
> Best Regards,
> Michael Williams
> IEEE 802.21 Vice Chair
>
> -----Original Message-----
> From: owner-stds-802-21@LISTSERV.IEEE.ORG
> [mailto:owner-stds-802-21@LISTSERV.IEEE.ORG]On Behalf Of ext
> Liu Xiaoyu
> Sent: Wednesday, April 28, 2004 5:52 PM
> To: Ajay Rajkumar
> Cc: Clint Chaplin; STDS-802-21@listserv.ieee.org
> Subject: Re : [802.21] contributions for upcoming May 2004 meeting -
> ARID
>
>
>
> Another potential issue when ARID (or AR IP address) is used
> as L3 handoff information:
>
> In a scenario discussed in IETF DNA WG
> (http://www.ctie.monash.edu.au/dna/DNAv6JH58.ppt, slide 5),
> two Access Routers and two Access Points connected by
> Ethernet, each Access Router advertising different prefix.
>
>
> | |
> __|____ __ |____
> | | | |
> | Router | | Router |
> |___1__| |___2__ |
> | |
> | |
> ___|______(Ethernet) ____|_____
> | |
> ____|____ ____|____
> | | | |
> | AP 1 | | AP 2 |
> |________| |________|
> \
> \
> \
> ________
> | |
> | STA |
> |_______|
>
>
> In this scenario, a mobile node/STA will receive two prefixes
> from both router 1 and router 2. Thus, the concept of "Link
> ID" is proposed in IETF DNA WG to avoid this problem.
>
> In case of ARID (or AR IP address), it means that the mobile
> node/STA will receive two ARIDs from both Access Router 1 and
> Access Router 2. So, even when the STA does not move, it
> will initiate a L3 handoff, resulting in a Ping-Pang effect.
>
> Regards,
> ------------------------
> Xiaoyu Liu
> Senior Researcher
> Samsung AIT
> NPTG, i-Networking Lab,
> Tel: +82-31-280-9615
> Fax: +82-31-280-9569
> Email: xiaoyu.liu@samsung.com
>
>
>
>
> ------- Original Message -------
> Sender : Ajay Rajkumar<ajayrajkumar@LUCENT.COM>
> Date : Apr 29, 2004 04:36
> Title : Re: [802.21] contributions for upcoming May 2004
> meeting - ARID
>
> That is exactly the point I brought up earlier regarding
> channel utilization, if
> under default condition layer 3 information (e.g. ARID) is
> being carried in a
> beacon. On the other hand, there may be certain conditions
> under which it may be
> permissible (e.g. certain triggers!).
>
> Also, on the same note, ARID would be useful only if it has sufficient
> information in it. For example, an 8 bit field (as suggested
> earlier) may not
> suffice. It would have to be a minimum of an AR IP address
> (32 bits for IPv4) or
> else something similar.
>
> -ajay
>
> On 4/28/2004 2:49 PM, Clint Chaplin wrote:
> > Yes, the beacon is extensible in the way you recommend, but
> I think the
> > issue is more pragmatic: just how big do we want to make the beacon?
> > It's already pretty darn large and growing, and with multiple BSSIDs
> > sharing a single radio for multi-BSSID setups, the beacon time is
> > becoming a fair fraction of the total available time.
> >
> > Clint (JOATMON) Chaplin
> >
> >
> >>>>Mike MORETON <mike.moreton@ST.COM> 4/28/04 01:10:18 >>>
> >>>
> > All,
> >
> > In some senses anyone can extend the 802.11 beacon as there
> is now an
> > OUI based extension mechanism. So for example, the WiFi
> alliance's WPA
> > security extension to 802.11 uses an IE identified with (as
> I remember)
> > the Microsoft OUI.
> >
> > So if 802.21 get an OUI allocated to them (probably not
> difficult) they
> > could add whatever they want to the 802.11 beacon.
> >
> > I would suggest that it would be best to go slightly beyond that and
> > get 802.11 to allocate a specific IE for 802.21 use.
> 802.21 could then
> > create their own "sub-type" field, and have whatever IEs
> they wanted.
> >
> > I don't think it's a good idea to get 802.11 to add a new IE for
> > specific 802.21 features (in this case ARID) as that imposes a
> > maintenance headache for the future.
> >
> > Mike.
> >
> >
> >
> > -----Original Message-----
> > From: owner-stds-802-21@listserv.ieee.org
> > [mailto:owner-stds-802-21@listserv.ieee.org] On Behalf Of Johnston,
> > Dj
> > Sent: Wednesday, April 28, 2004 4:08 AM
> > To: S. Daniel Park; steve.lee@SAMSUNG.COM; McCann, Stephen;
> > stds-802-21
> > Cc: ajayrajkumar@LUCENT.COM; Pyungsoo Kim; cchaplin@symbol.com
> > Subject: RE: contributions for upcoming May 2004 meeting - ARID
> >
> > Daniel,
> >
> > There are four potential venues I can think of.
> >
> > 802.21 is an obvious place, since this is a small item of L3 context
> > information that can be used for optimization of the
> handover process,
> > regardless of the media type. In fact I think you will find
> 802.21 to
> > be
> > fairly receptive to this idea, since I remember the ARID being
> > discussed
> > several times as a suitable thing to include in the handover
> > information
> > that 802.21 could make available.
> >
> > 802.16e or 802.16 Netman may want to adopt this as an efficiency
> > measure.
> >
> > 802.11r 'Fast BSS Transition' may or may not want to address this,
> > based
> > on a determination of whether the ARID could change during a BSS
> > transition.
> >
> > 802.11 WIEN has something of a cellular interworking angle.
> If Mobile
> > IP
> > is the unifying medium in an 802.11/cellular interworking scenario
> > that
> > WIEN ultimately addresses, the some representation of the ARID would
> > be
> > appropriate.
> >
> > Within 802.21 and 802.16 I see no conflict. It is
> appropriate for the
> > same information to be available by both means. The point of
> > supporting
> > it in 802.16 would be that it could be passed at a lower layer and
> > thus
> > in a more timely fashion than 802.21 might achieve over that medium.
> >
> > Within 802.11, I suspect you do not need more than one group to
> > address
> > this, so its one of either 802.11r or WIEN. Given Steve's input, it
> > looks like WIEN might be keen to help out.
> >
> > So I suggest you bring this to 802.21 as a proposal for an item of
> > 'media independent handover information' that we should support and
> > provide the necessary information relating to its use and semantics.
> >
> > In 802.16, I suggest steering clear of 802.16e, they are
> heavily into
> > a
> > comment resolution cycle and don't have room for new material. The
> > 802.16 Netman SG in the medium term is likely to lead to a PAR that
> > addresses optimized mobility procedures. I have ARID
> advertisments on
> > my
> > list of things to address in Netman and so we may have time
> to discuss
> > this in the July meeting in Portland. If you are going to
> Shenzen for
> > the 802.16 meeting in May, then you are welcome to bring it up as a
> > scope item for Netman.
> >
> > In 802.11, take it to WIEN.
> >
> > DJ
> > 802.16 Netman SG chair
> >
> >
> > -----Original Message-----
> > From: owner-stds-802-21@LISTSERV.IEEE.ORG
> > [mailto:owner-stds-802-21@LISTSERV.IEEE.ORG] On Behalf Of S. Daniel
> > Park
> > Sent: Tuesday, April 27, 2004 6:13 PM
> > To: steve.lee@samsung.com; 'McCann, Stephen'; 'stds-802-21'
> > Cc: ajayrajkumar@LUCENT.COM; 'Pyungsoo Kim'
> > Subject: RE: contributions for upcoming May 2004 meeting - ARID
> >
> >
> > Steve, please see my inline comments.
> >
> >
> >
> >>-----Original Message-----
> >>From: Sungjin Lee [mailto:steve.lee@samsung.com]
> >>Sent: Wednesday, April 28, 2004 9:48 AM
> >>To: 'S. Daniel Park'; 'McCann, Stephen'; 'stds-802-21'
> >>Cc: ajayrajkumar@LUCENT.COM; 'Pyungsoo Kim'
> >>Subject: RE: contributions for upcoming May 2004 meeting - ARID
> >>
> >>
> >>Hi Daniel, Stephen and all HO guys
> >>
> >>In my understanding, that kind of issue (e.g. ARID into
> >>beacon) is fit to be discussed within 802.21. The ARID formant,
> >>recommended usage examples and scenarios also could be discussed and
> >>then put into the documentation released as 802.21 spec. based on
> >>agreement between 802.21 attendees.
> >>
> >>However, the specific way to provide that ARID information over the
> >>air interface should be discussed within each WG. In fact, It sould
> >
> > be
> >
> >
> >>discussed within 802.11 WG to propose the changed Beacon frame
> >>structure including ARID and within 802.16 to propose the changed
> >>DL-MAP or NBR-ADV message including ARID.
> >
> >
> > It was my original question, so I guess this work is useful
> > for related WG such as 802.11, 802.16 but the contribution should be
> > discussed in the 80.21, of course we have to get the agreement of
> > 802.11
> > to insert ARID into the beacon. Of course we have to get
> the agreement
> > of 802.16 if ARID would be applied for 802.16.
> >
> > correct ? or am I missing anything ?
> >
> > I am not sure how I can get the agreement of 802.11 to
> > insert ARID into the beacon. Do I have to propose it to the
> 802.11 as
> > a
> > document ? or 802.21 can be responsible for this collaboration. I am
> > so
> > curious...
> >
> >
> > Regards.
> >
> > - Daniel (Soohong Daniel Park)
> > - Mobile Platform Laboratory, SAMSUNG Electronics.
> >
> >
> ______________________________________________________________
> __________
> > This email has been scanned for computer viruses.
>