Re: RE: AD request / L2 Triggers Chapter Statement

James Kempf writes:
> > 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.

That's 802.11.  That's not plain old 802.  If you have an Ethernet
bridge in the way, then you're sunk.  That's the problem I referred
to.

> 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.

Personally, I think it's a terrible mistake for these devices to use
an IP-based protocol for this purpose.  802 is (currently) agnostic
with respect to network layer protocols, and I think this is a very
good property.  In particular, 802 defines a family of Spanning Tree
messages used to eliminate loops in an 802 network.  These are,
naturally enough, not based on IP.  I see no reason that this related
feature should be a special thing that only IP can use.

What happens if I'm running OSI over my 802 network?  Such a thing is
not completely unheard of.

What happens if I *don't* want to give my bridges separate IP
addresses?  What are the security implications?  What security
protocols are defined for this exchange?

Fortunately, this is an IEEE issue, not an IETF issue, unless the
proponents of this protocol want to introduce it to the IETF as an
I-D.

> 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.

Yes.  However, it's a general 802 problem.  The fact that it bothers
some people in particular for this one application doesn't mean that a
special solution for this one case is warranted.

> 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.

Really?  In that case, something is horribly broken.  There's nothing
at all in PPP that gives you such an absurd link establishment delay.
If it takes you more than 4 or 5 round-trip-times to establish a PPP
link (typically an order of milliseconds for most *usable* link
technologies, not seconds), then you have some serious implementation
bugs to worry about first.

> 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.

Requirements documents are never standards-track.

> 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.

If this is done, *please* address the general problem: notification of
remote L2 failure in 802-based protocols.  Solving the problem for one
particular case is (in my opinion) a very bad thing to do.

> 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.

Fortunately, that message already exists, at least for IP: see RFC
1868.

It's not ICMP, though.  Is that a necessary feature?

> Do you think these possible tasks are valueless?

Some appear to me to be so, but that's quite beside the point.

The point is whether or not these things actually belong in the IETF.
I don't think that the IETF owns the IEEE protocols, nor that the IETF
should set out to modify the IEEE protocols.  IETF participants who
have particular 802-related hobbyhorses certainly ought to be involved
in the IEEE to get those protocols changed to taste.

-- 
James Carlson, Solaris Networking         <[email protected]>
SUN Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

_______________________________________________
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/