> Let me be more specific. It will not convince 3GPP and Wimax > Forum that > periodic, multicast RAs should be deployed in their network.
=> Well, I don't think that's specific, but obviously you do. 3GPP *already* defined the use of IPv6 and already recommends setting the lifetime to a max. So please tell us if there are any official statememnts or documents from 3GPP to indicate concerns about this. Otherwise what you say is your opinion, which is fine, but if that's the case you shouldn't speak on behalf of 3GPP. > 3GPP2 already > does not use RA beacons for Mobile IPv4. => Completely different issue. ND is not a MIP function and is certainly not a "beacon" and we're not trying to make it one. A message every 30 mins is not a beacon. Hesham > > jak > > ----- Original Message ----- > From: "Soliman, Hesham" <[EMAIL PROTECTED]> > To: "James Kempf" <[EMAIL PROTECTED]>; "Thomas Narten" > <[EMAIL PROTECTED]> > Cc: "Erik Nordmark" <[EMAIL PROTECTED]>; > <ipv6@ietf.org>; "ext Pars > MUTAF" <[EMAIL PROTECTED]> > Sent: Friday, September 01, 2006 3:00 AM > Subject: RE: Proposal to change aspects of Neighbor Discovery > > > > > > > > 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, > > => Honestly, James, please don't make these blanket statements about > such a > large group of people. As a "cellular guy" I'm quite happy > with anything > between 1 to > 2 hrs and I'm not hurting too much with the 30 minute limit > either. None > of the cellular > guys I know complained too much about the 30 minute limit when I told > them. Of course if it's > one hour they'll be happier but to say they don't want > anything at all > is outlandish. oops, > I'm starting to generalise! Better stop now. > > > Thanks, > Hesham > > > > 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 > > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
