Tony, > > ... > > We cannot assume all MNs can "anticipate movement". Not all > > link-layers > > have this capability. > > A MN 'can anticipate movement' because that is what it does by > definition. What it may not be able to figure out is the candidate list > of where it may end up.
What I really meant was this second one.. > The fact that some link layer implementations > have chosen not to expose knowledge of potential alternatives is > possibly due to a lack of requirements to do so. I know the 802.11 > implementation I am using is fully aware of the candidate set of layer 1 > associations, ..by listening to the baecons. But even that would require your wlan card to scan all the channels. They don't normally do that, until they really have to (i.e., current radio conditions are deteriorating), or your management application tells it to do so, because while scanning, it has to hold the data traffic. A card usually has only one transceiver. > though it doesn't attempt to bind the IP stack until I > select one. It would be easy for it to bind IP to all, but prioritize to > the selected one until it was out of range. If it did so, all possible > destinations could have run a full DAD in the background, well in > advance of the move. I don't think this is as easy as it sounds. Your MN has to: - collect a list of candidate access points (a costly scanning operation) - somehow map this information to associated prefix information, and an agent on the associated IP subnet (how?) - send a proxy-DAD request to that server (this protocol needs to be defined) ... and make sure this process concludes before your MN has to handover. > > Even if the MN implementation chose not to associate with all possible > layer 1 neighbors, the ones it does have an association with will also > be able to hear a partial list of the candidate set, and could provide > that to the MN if the implementation provided a path from the layer 1 > receiver to a control plane process. > > It is true that a standards effort can not assume that all > implementations will provide a full spectrum of capability, but it is > also true that it MUST NOT assume that ignoring a collision avoidance > system will not really do any harm. If people want to be mobile, but a Sure. Actually, my comment is not against what you are saying here. I guess an approach like a proxy-DAD can be a candidate solution to this problem. Another candidate is server-based DAD that I'm currently working on. It involves a server keeping track of currently used IP addresses on a subnet, and assisting mobiles that know how to consult this server. > specific link-layer doesn't provide the tools to make that work > correctly without problems, the link-layer will fade from the market > place. > > Tony alper -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
