Erik,
Couple points.
Most cellular networks don't have more than one active last hop router, so
the issue of multiple routers doesn't apply.
Regarding the number of packets, the question is over what period of time
are the packets sent. If the router needs to emulate multicast, then the M*N
unicast RAs either need to be spread out over some period or you'd end up
with congestion. It's true that the number of packets is more if explicit
solicitation is done, but is that such an issue given the bandwidth
available on modern wired and wireless links? Again also, the RS/RAs could
be spread over a longer time period to reduce the possibility of congestion.
Regarding filtering for dormant mode hosts, having the BS filter out the
multicast RAs is certainly an option, since the BSs will know which hosts
are in dormant mode. This would not require any special protocol to tell the
last hop router which hosts are in dormant mode or not, if the BSs are IP
devices. In current 3G networks, they aren't, but in Wimax they will be.
However, at least one cellular SDO (3GPP2) has declined to specify beacon
RAs for MIPv4 movement detection, I believe primarily because of dormant
mode (Kuntal can correct me if I am wrong here). So I suspect if IETF does
nothing on this, the cellular SDOs will simply ignore the IETF
recommendation because it doesn't apply to their networks, and will specify
that multicast RAs are not done, because most of the people active in Wimax
Forum are 3GPP2 people so they are familiar with the way 3GPP2 does it. Of
course, maybe IETF doesn't care in the end whether or not this gets deployed
in cellular networks, in which case, leaving it as it is in RFC 2461 and
saying "if you feel this is an issue for dormant mode hosts, then have the
BS filter" is fine.
jak
----- Original Message -----
From: "Erik Nordmark" <[EMAIL PROTECTED]>
To: "James Kempf" <[EMAIL PROTECTED]>
Cc: "Basavaraj Patil" <[EMAIL PROTECTED]>; <ipv6@ietf.org>; "ext
Pars MUTAF" <[EMAIL PROTECTED]>
Sent: Thursday, August 31, 2006 5:17 PM
Subject: Re: Proposal to change aspects of Neighbor Discovery
James Kempf wrote:
I think the proposal was not to keep the router information until it was
explicitly invalidated but rather that the host could individually
solicit prior to the expiration of the lifetime. The router information
state is still soft state, its just that the renewal is different. 2641
explicitly prohibits solicitation except for 5 specific cases, and
renewing a router table entry is not one of them.
For some types of wireless links, multicast unsolicited router
advertisements are not really that helpful in determining router
reachability, because the host may be able to hear the router, but not
transmit. If the host depends on a multicast unsolicited router
advertisement, it could end up with a lengthy NUD procedure before it
determined that it couldn't really use the router. That's one reason why
an RS-RA exchange would be more useful. Another is the issue of dormant
mode hosts, which is I think what prompted the original posting on this
thread.
But the cost of solicited advertisement in terms of load on the network is
higher than unsolicited.
Assume there are N routers on the link, and M hosts.
With unsolicted multicast advertisements we get N multicast RAs per time
period. If we assume the the link layer emulates multicast with repeated
unicast, that would end up bring M*N unicast RAs per time period.
With solicited RAs, presumbly we'd want the RS to be unicast instead of
sent to all-routers, right? (Otherwise we'd have a ton of multicast RSs to
handle.)
Thus each host would need to unicast at least one RS per time period. But
with N routers providing potentially different information it would seem
each host needing to unicast an RS to each one each time period. Thus we'd
end up with N*M RSs plus N*M RAs in response; twice the number of packets!
Note that is addition to sending more packets, such an approach can not
robustly deal with a replacement of a router.
When a new router comes up it initially multicasts a few rapid RAs. But
all those could be lost. The fact that the new router (as well as others)
keep on multicasting RAs periodically means that even if the initial RAs
were lost, the hosts would sooner or later receive an RA. Without this, we
can easily get into states where the new router is introduced, and a day
later the old router is turned off, yet there might be hosts which do not
know there is a new router.
Thus you'd need to have the hosts fall back to sending *multicast* RSs to
compensate for the lack of periodic RAs.
To me the dormant host seems like a red herring.
For a dormant node there is a filter somewhere which determines what
packets will make it wake up. I guess this filter could be either in the
NIC/radio on the host, or in the network. If it is in the network, then a
match on the filter would make the network send the "wakeup" signal to the
host.
Given this, we can get the desired behavior of not having the host wakeup
due to periodic RAs if the wakeup filter blocks (doesn't wake up) from a
RA.
This means that when the host wakes up it might find that its default
routers and/or prefixes have timed out. But we need to deal with that in
the solicited RA case as well (presumably we don't want to have the host
wake up every time period to send the RS/RSs.)
And dealing with that case can be done by just invoking the DNA
procedures - send a unicast RS to a known router and wait for an RA in
response.
Thus I don't see an alternative to periodic RAs that is more attractive;
the alternative seems to cause more packets and be less robust.
Erik
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
