Hi Samita, Thanks for your quick response. See comments inline... >> - page 6, chapter 4: you state "The IPv6 router which sits >in the boundary of the LowPan is a PAN co-ordinator." Since >only one PAN co-ordinator is allowed per LowPan this implies >that the LowPan is only connected by one IPv6 router to the >outside world. I think it is beneficial and applicable to have >more than one IPv6 router (gateway) that connects the LowPan >to external networks (e.g. for redundancy, loadsharing, >reaching differnet offlink networks, etc.). If you agree you >could reword the sentence and state: "One of the IPv6 router >which sits in the boundary of the LowPan is the PAN >co-ordinator." A second gateway (IPv6 router) may overtake the >role of the PAN coordinator in case that one is failing >(alternate PAN coordinator) or the PAN coordinator may >redirect offlink traffic to a second >gateway due to being overloaded. > >At last IETF, we discussed on the signle point of failure >issue of single > IPv6 router per lowpan. >SInce there is single PAN co-ordinator in a lowpan, we would >have to figure out how it switches the PAN-coordinator >functionality as well. The IPv6 router function should be a >function of PAN-coordinator switch at L2. Once we know about >the PAN-co-ordinator switch and load-balancing we can fix the >text or define an appropriate L3 behavior for that. > >> >> - page 8, section 5.1: For your statement "[TBD: how can it >also find >>out about the other addresses? Guess based on the advertised >prefixes?]" I would recommend that for each address a node >configures it sends a Neighbor Solicitation to the PAN >coordinator. This way, the PAN coordinator would get a >complete L2-L3 association table of on-link nodes. > >Alternately, (if we want to avoid NS messages to the PAN >co-ord) the PAN co- ordinator can automatically associate >global IPv6-addresses in the L2-L3 table based on the prefix >advertisement. Usually NS to a router happens to its >link-local address, are you saying each node to send NS to the >router's global IPv6 address?
So you would conclude from the EUI-64 identifier of the link-local address (received in the RS) also the non-link-local addresses, right? This is only possible in case *all* IP addresses are constructed by concatenating the respective prefix with the EUI-64 identifier. However, draft-ietf-6lowpan-format-03 leaves flexibility in the constructing of non-link-local IP addresses so I am not sure whether we can rely on this (or at least we have to make this an requirement). Therefore my proposal was to send for each configured IPv6 address an NS message to the PAN coordinator with the respective IPv6 address as source address and the Source Link Layer Address option. The destination address could be any of the router's IPv6 addresses, the link-local address as well. > >> This would also answer your last bullet point in section 9 >and removes the need for your section 6.1. > >6.1 redirect messages for address resolution is useful because >it distributes the load of future messages to the respective nodes. > Also, since the router advertises off-link >(L=0) in RA, the node sends data directly to the router; this >saves cost of NS. >So, I think 6.1 redirect method might be useful for saving messages. > Now I got your point. >> >> - page 8, section 5.2: I would not introduce an additional >signalling protocol, e.g. among coordinators, to enhance RA >processing but would keep periodic RAS and go for your option >2 (use L2 unicast to send RAs). The resulting overhead should >be acceptable (setting an appropriate interval is a network >designer issue). An additional signalling protocol has also an >overhead and complexity, and requires additional processing in >coordinators, which are likely to be battery powered as well. > >Ok. I understand that you suggest using L2 unicast to send RA >to each node. > >> Maybe we could think of a signalling protocol between PAN >coordinator >>and alternate PAN coordinators (e.g. IPv6 routers that >provide external connectivity) so that an alternate PAN >coordinator can quickly establishes itself as PAN coordinator >in case the primary one fails. > >Do you have any idea to switch PAN co-ordinators at L2 layer? >If so, we could link IPv6-router switch along with that. Not much about this is written in the IEEE 802.15.4-2003 standard and I have no access to the IEEE 802.15.4b-2003 standard (and I don't think they solve this issue there). I assume 802.15.4 leaves it up to higher layers (e.g. to the 6lowpan layer) to deal with PAN coordinator selection. When sending an Association Request message, a node can signal its wilingness to be an alternate PAN coordinator via a respective flag. Similar to other failover mechanisms, a PAN coordinator receiving such a message with the flag set could subsequently send periodically an alive message just to his alternate PAN coordinators. In case an alternate PAN coordinator does not receive an alive message anymore it could perform an election process among all alternate PAN coordinators and become the PAN coordinator. Clearly, there are open issues and these are just first thoughts. Best regards, Karl > >Regards, >-Samita > > >> >-----Ursprüngliche Nachricht----- >> >Von: Samita Chakrabarti [mailto:[EMAIL PROTECTED] >> >Gesendet: Sonntag, 25. Juni 2006 01:30 >> >An: [email protected] >> >Betreff: [6lowpan] 6lowpan-nd version 2 >> > >> >Erik and I have updated >> >draft-chakrabarti-6lowpan-ipv6-nd-02.txt and submitted for >> >publication. The new update includes a section on generic >application >> >of this draft for non-multicast, non-broadcast network. At the last >> >wg meeting, the request was made for such an update for the Wimax >> >effort on IPv6. >> > >> >Two questions to the working group and the chairs: >> > >> > 1) Should this draft( 6lowpan-ipv6-nd) be published as a WG >> >document ? >> > 2) Are we OK with publishing the draft as "IPv6 Neighbor >Discovery >> >Optimization >> > for IEEE 802.15.4 and other non-multicast networks" >so that it >> >contains >> > specifics on 6lowpan and a generic guideline for >other relevant >> >networks? >> > >> >Comments are welcome. >> > >> > >> >- Samita >> > >> >_______________________________________________ >> >6lowpan mailing list >> >[email protected] >> >https://www1.ietf.org/mailman/listinfo/6lowpan >> > >> > _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
