Let me be more specific. It will not convince 3GPP and Wimax Forum that
periodic, multicast RAs should be deployed in their network. 3GPP2 already
does not use RA beacons for Mobile IPv4.
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
--------------------------------------------------------------------
