Re: RE: AD request / L2 Triggers Chapter Statement

"James Kempf" <[email protected]> Tue, 18 Jun 2002 08:40:43 -0700
Newsgroups gmane.ietf.pilc
Message-ID <016801c216de$831e3160$0f6015ac@T23KEMPF>
> Right.  That document describes exactly what IPv6 packets look like on
> 802 media.  It doesn't describe what the internal interfaces necessary
> to do that might look like.  You can implement RFC 2464 using STREAMS,
> function calls, system calls, or just about anything you care to.
>

If you look at "Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) specifications", ANSI/IEEE Std 802.11
1999-00-00, there is defined in Section 7.2.3 .6 the reassociation
management frame format. This is sent between the host and the access
point when the host reassociates with an new access point upon handover.
As such, it is verifiable for standards conformance.

Similarly, 802.11f, "Recommended Practice for Multi-Vendor Access Point
Interoperability via an Inter-Access Point Protocol Across Distribution
Systems Supporting IEEE 802.11 Operation," draft January 2002 (IAPP),
describes an IP-based protocol that is sent between access points when a
host reassociates. As such, it is verifable for standards confromance.

Currently, the interaction between these and the Mobile IP protocols
defined in draft-ietf-mobileip-fast-mipv6-04.txt and
draft-ietf-mobileip-lowlatency-handoffs-v4-xx.txt (now expired) is
undefined. In fact, if you take a look at these protocols, it becomes
difficult to see how they could contribute to improving Mobile IP
handover performance, given the typical 802.11 network of bridging
access points connected up to routers. In fact, for IAPP, the net effect
on Mobile IP handover looks like it might be fairly negative.

A similar case can be made for Bluetooth. Referring to Brent Miller's
book, Bluetooth defines IP as running over PPP. As for handoff
performance, the amount of time required to establish a link between a
Bluetooth piconet master and slave looks like it would be on the order
of seconds, effectively ruling out any high performance Mobile IP
handover.

One of the hypotheses (developed by talking with some people active in
the 802.11 development) is that if the 802.11 committee and Bluetooth
SIG had had a set of requirements for supporting high performance Mobile
IP handover, they might have had an easier time defining their Layer 2
protocols to be more Mobile IP handover friendly. So one possible task
for a Layer 2 triggers working group is to define those requirements.
Such a document would not be used for standards conformance testing, but
just as an informational document for other standards bodies that need
guidance.

Another possiblility is to define "Mobile IP Handover over 802.11", in
which the wire format for the interaction between Mobile IP and a fast
handover protocol between the briging access point and the router would
be defined, that would be appropriate for standards confromance testing.
At the moment, this is not an option, since the 802.11 committee does
not have the right Layer 2 protocol to effectively provide the optimized
handover information to the router, though it might be possible to
define in the context of an extension to IAPP. Similar documents would
be needed for other wireless protocols, of course, as has been done for
IP over the wire.

A final option, on which there is currently some work, is an ICMP
message that would allow an access point to inform a router that a new
host has appeared (or an old one disappeared). This could also be used,
for example, between an Ethernet switch and a router when the switch
received a 10BaseT electrical signal that a new host appeared or
disappeared.  As such, it would have applicability beyond wireless.

Do you think these possible tasks are valueless?

            jak



_______________________________________________
pilc mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pilc
http://www.ietf.org/html.charters/pilc-charter.html
http://pilc.grc.nasa.gov/