Hello,
The issue was raised again in 16ng, so I'm trying to help
moving forward on this issue. (I dropped out my dormant mode
reliability concerns for future work, but I hope this has
complemented the discussion.)
I have a couple of comments on the signaling analysis made
by Erik and James:
IMHO the comparison of RS/RA signaling vs unsolicited/periodic
RA is incomplete. At the IP layer, the cost RS/RA is clearly
twice the cost of unsolicited/periodic RA. I agree. This
doubles the load on the AR's interface (if I understand
correctly).
However, at the link layer the situation is inversed
(especially on wireless links). Most of the unsolicited RAs
trigger paging (say 90% of them). This means that most of
the unsolicited/periodic RAs trigger N paging messages, plus
the paging protocol exchange messages, plus the RA. In addition,
the resource being consumed is the paging channel, which is
scarce. But I ignore the exact paging packet sizes.
As for the RA filtering possibility:
Filtering at the base stations may not be enough. Filtering should
be done at link-layer paging agents (I'm using the generic term).
Otherwise, the paging agent will unnecessarily generate N messages
(per RA), which will later be dropped by the base stations. Filtering
should also be made at the base stations. Because some of the RAs
will trigger paging, the others won't.
In addition to other comments, my personal suggestion to the
authors would be: not only focusing on the energy cost but also
the paging cost, and resubmitting the draft. The solution is also
unclear. The RAs should be turned OFF, or the RA interval should
be increased? Which one? If they are not necessarily turned OFF,
they should be spread over time to avoid paging channel congestion.
This argument also applies to the current maximum period (30min).
But precisely how they are spread?
My two cents.
pars
ps: On more point. If the proposal is made for 16ng, the number of
hosts in the subnet reported by Raj, which was several hundred
thousands (in the context of 3GPP) does not apply probably. In
16ng, there will probably be only one paging area under the AR (not
sure yet). In this case, if filtering is considered as the best
solution, it can work at the BS. Because the AR is the paging agent.
On Tue, 2006-09-05 at 12:54 -0700, James Kempf wrote:
> 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
--------------------------------------------------------------------
