[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

stds-802-handoff: FW: BOUNCE stds-802-handoff@majordomo.ieee.org: Non-member submission from ["James Kempf" <kempf@docomolabs-usa.com>]



Fowarded for a non member
DJ

-----Original Message-----
From: owner-stds-802-handoff@majordomo.ieee.org
[mailto:owner-stds-802-handoff@majordomo.ieee.org] 
Sent: Wednesday, February 11, 2004 9:17 AM
To: owner-stds-802-handoff@majordomo.ieee.org
Subject: BOUNCE stds-802-handoff@majordomo.ieee.org: Non-member
submission from ["James Kempf" <kempf@docomolabs-usa.com>] 


[...]

Pekka,

> > One useful output of the DNA discussions would be that the 
> > experience we gain can be fed into the link-layer designers as 
> > requirements or nice-to-have features. We talked about that, and the

> > WG decided not to include an official deliverable for this purpose. 
> > I personally believe that
> > producing such a document would be useful and doable.
>
> I pretty much agree with you that a document targeted to link-layer 
> designers would be highly useful.  However, it was felt as a part of 
> the DNA chartering process that it is better to focus, in the WG, on 
> issues that clearly belong to the IETF.
>
> If you would like to go on further with link layer issues, I would 
> suggest you to try to get some people from the IAB involved, as IAB is

> supposed to co-ordinate the work with other standard bodies. James is 
> probably interested, but as usual may have a different

Whatever gave you that idea? :-)

> point of view from you.  Hence, I guess working with Bernard is 
> probably the best way to go forward, as he is also deeply involved in 
> this work.  Maybe Itojun could also help.  Thinking about the actual 
> editing work, my guess is that Jari might be willing to work on such a

> document, too.
>
> Hence, maybe you could create a kind of ad hoc group or a "design 
> team", working together with the IAB, to produce such a document? It 
> could then be circulated in a number of WGs (DNA, MIPv4, MIPv6, 
> MIPSHOP, DHC, IPv6, SEND, ...) before putting it out for the IETF LC.
>

A group of us, including Alper and myself, had a draft a couple years
ago that was targetted explicitly at requirements for IP handover
directed at wireless link layer designers. It was intended to be
somewhat like the PILC RFC (RFC 3150, BCP 48). Alper and I attempted to
get some traction around the IETF for the draft, but no working group
was really interested in sponsoring it or forming around it, and
eventually it was dropped for draft-yegin-dna-l2-hints-00.txt, which is
somewhat more explicit about what are link layer hints/triggers on
current link layers. In the sense that the current draft reflects the
drawbacks of the wireless link layers it discusses (which were not
designed for high performance IP handover), it is somewhat limited as a
vehicle for advising the 802 wireless groups about how to move forward,
though it is a start at describing how link triggers or hints would be
used for implementing IP handover on the link layers it covers, which is
what IETF cares about.

For myself, I think doing a draft with requirements on link layers for
high performance IP handover as input the the 802 Handoff ESG (soon to
be 802.21) and other IEEE wireless groups is still an excellent idea and
I would certainly be interested in reviving that draft and working more
on it, or taking the content and moving it to a new draft. Whether it is
done in DNA or not is not particularly important, the draft can also be
made as an individual contribution. The important points are 1) that it
reflects the understanding of those in the IETF community who are
familiar with wireless and understand the problems with existing link
layer and IP handover, and 2) that it is circulated widely in all the
802 wireless WGs (802.16, 802.15, 802.20, and 802.11n) so that its
recommendations are taken seriously by the 802 wireless link design
groups and discussed with IETF if there are any questions.

I would be willing to work with Bernard on this as part of our IAB work
to promote a better wireless Internet.

            jak