1) Is there an issue with multicast RAs vs. unicast RAs? I.e., would it help if the RAs were unicast rather than multicast? (Or is there no true unicast in the networks we are talking about). My assumption is that use of IP multicast is not an issue here, since no one has suggested this.
I assume you mean "no true multicast" and not unicast. No, the issue isn't with lack of multicast support, IFICT.
2) What I'm clearing hearing is that it will be common to have devices in "dormant" mode for long periods of time, i.e., hours. The desire is that they not be bothered with RAs during that time (if that is the only only traffic they would be getting, i.e., no other packets are being sent their way).
Yes, that's the basic problem. A subsidiary problem is the one I mentioned about lack of bidirectional connectivity. This doesn't occur in cellular networks, but it could occur in other networks. I don't know about 802.11, I've been told that it could happen there, but I haven't checked that assertion in detail.
3) The current ND specs have an upper limit of 30 minutes on the interval between router advertisements. That should be changed, to allow deployments to use a higher value. (that is the assertion/problem.)
This is certainly possible and one could do it, but at some point one must ask what is the point of having the multicast RA if the timeout is something like 2 days. If the point of the multicast RA is to allow softstate to time out to preserve memory, then a very lengthy interval will certainly decrease the effectiveness of that. Also, FWIW, it won't please the cellular guys, because what they have right now doesn't ever require a traffic channel to come up unless there is traffic specifically for that terminal (i.e. either unicast or for a global multicast address that the terminal has subscribed to).
What makes this all not as easy as it sounds is that periodic RAs are a simple protocol. Send them periodically (and somewhat frequently) so that if one or two get lost, hosts continue operating and nothing breaks. Even if they miss two, they'll receive a third one soon enough. That works pretty well when the periodic interval is short. It doesn't really work at all, when the periodic interval is hours apart. Unless the RAs are delivered with a high degree of reliability.
Most simple and elegant. If the last hop is wired, it's about perfect.
How reliably will the periodic RAs be delivered in the networks at issue here? Are they essentially reliable link layers?
The cellular networks typically have extensive ARQ support (something like a maximum of 8 for wcdma I think) to ensure that the packet gets across. They also have lots of support in the network for radio resource management, so it is almost never the case that the link will get congested. If a terminal tries to claim more bandwidth then it is subscribed for, it just doesn't get it. This isn't true for 802.11. The ARQ support is pretty good, but if the link gets congested, the backoff time tends to increase, especially with CBR traffic like VoIP. The apps then tend to time out. So it's possible that a multicast RA would be dropped, unless it was somehow given higher priority and the wireless link was running 802.11e.
jak
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
