jak
----- Original Message -----
From: "Pars MUTAF" <[EMAIL PROTECTED]>
To: "James Kempf" <[EMAIL PROTECTED]>
Cc: "Erik Nordmark" <[EMAIL PROTECTED]>; <[email protected]>
Sent: Wednesday, September 20, 2006 10:16 AM
Subject: Re: Proposal to change aspects of Neighbor Discovery
> Selon James Kempf <[EMAIL PROTECTED]>:
>
>> Why can't the BS simply filter the RA? It looks at the IP packet
>> header,
>> if
>> the packet was sent to All Hosts Multicast and it's ICMP RA it drops
>> that
>> packet for those mobile nodes that are dormant.
>
>
> Because by the time the BS received the RA, the host was already paged
> and woken up.
>
> Here is the protocol:
>
> AR: access router
> RA: router advertisement
> MH: mobile host
> BS: base station
>
> 1. The AR generates a unicast periodic unsolicited RA destined for MH.
> 2. The host is dormant, then the RA is forwarded to the L2 paging
> subsystem.
> 3. The paging subsystem pages the host in its current L2 paging area.
> 4. All BSs in the paging area, alert the MH.
> 5. The MH wakes up in its current cell, and brings up a traffic
> channel.
> 6. The system forwards the periodic unsolicited RA to the host.
>
> You are proposing to filter the RA in the final step (step 6).
> This is useless. The host was already paged and woken up.
>
> The RA should be filtered by the paging subsystem. I.e. it should be
> filtered
> before the host is paged and woken up.
>
> The goal of the I-D by Raj and Syam was turning-off the periodic RAs
> and
> avoid
> paging and waking up the host. If you wish to do the same through
> "filtering"
> (i.e. without modifying the AR impl.), then you need to filter the RA
> before
> the host is paged.
>
> (Otherwise the BS wakes up the MH, before it receives the RA.)
>
>
> Greets,
> pars
>
>
>
>
>>
>> jak
>>
>>
>> ----- Original Message -----
>> From: "Pars Mutaf" <[EMAIL PROTECTED]>
>> To: "James Kempf" <[EMAIL PROTECTED]>
>> Cc: "Erik Nordmark" <[EMAIL PROTECTED]>; <[email protected]>
>> Sent: Wednesday, September 20, 2006 2:25 AM
>> Subject: Re: Proposal to change aspects of Neighbor Discovery
>>
>>
>> > On Mon, 2006-09-11 at 20:02 +0200, Pars Mutaf wrote:
>> >> 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.
>> >
>> > hi,
>> >
>> > While talking with a colleague, we have realized that paging by
>> > the BS isn't possible in fact (I don't remember who proposed it,
>> > it looked like an anonymous magic solution).
>> > Because, when the BS receives a link-layer paging message, it
>> > cannot figure out whether:
>> >
>> > 1/ The paging message was triggered by an incoming session, or
>> > 2/ The paging message was triggered by a periodic RA.
>> >
>> > In conclusion, if filtering of the periodic RAs is considered as
>> > the best solution (not my argument), it should be done at the
>> > paging agent. This is not only more optimal (as I argued above),
>> > this is the only solution.
>> >
>> > The BS can of course filter the RA after paging, but it's too
>> > late. The host is woken up, the paging bandwidth is consumed.
>> >
>> > (UIMS, this point also applies to 16ng, and when paging agent = AR.)
>> >
>> > pars
>> >
>> >
>> >> 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]>;
>> >> > <[email protected]>;
>> >> > "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
>> >> [email protected]
>> >> Administrative Requests:
>> >> https://www1.ietf.org/mailman/listinfo/ipv6
>> >> --------------------------------------------------------------------
>> >
>>
>>
>
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
