Selon James Kempf <[EMAIL PROTECTED]>: > There is an assumption here that the "L2 paging system" is run off the AR. > This is not necesarily the case. It won't be for Wimax, for example.
Hello, OK. The discussion about Wimax now ;-) But this should be orthogonal to our problem. In paging, in general, the system (AR in this case) doesn't know where the dormant host is located. The mobile host is "asked" to report its exact location, i.e. cell. (This is what is meant by "paging"). *The BSs don't know anything about the dormant host*. The host is paged in all cells of the paging area. That's why wireless bandwidth needs to be consumed for paging in all cells of the paging area. (This is a well-known problem of paging. 100s of research papers attempted to reduce this bandwidth cost.) Then, the host hears the paging message while sleeping in one of the cells, wakes up, and a location update is sent. The AR has now learned the current BS of the host. The packet that triggered paging is forwarded to the current BS of the host. Filtering of the RA by the BS is too late. Because the host was already paged in all cells and woken up. pars > > jak > > ----- Original Message ----- > From: "Pars MUTAF" <[EMAIL PROTECTED]> > To: "James Kempf" <[EMAIL PROTECTED]> > Cc: "Erik Nordmark" <[EMAIL PROTECTED]>; <ipv6@ietf.org> > 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]>; <ipv6@ietf.org> > >> 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]>; <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 > >> >> -------------------------------------------------------------------- > >> > > >> > >> > > > > > > > > > > ---------------------------------------------------------------- > > This message was sent using IMP, the Internet Messaging Program. > > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
