Hi Karl, Thanks for your input.
My responses are in-line. On 7/4/06, Mayer Karl <[EMAIL PROTECTED]> wrote:
Hi Samita, A few comments and questions about your new version. - page 4, chapter 3 point 2 you state Neighbor Solicitation but it should be a Router Solicitation, right?
Yes. Router Solicitation should be more expilicit term.
- 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?
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.
- 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. 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
