Hi Zach,
The ND documents states this definition:
LoWPAN Router
A LoWPAN node that forwards datagrams between arbitrary source-
destination pairs using a single 6LoWPAN interface performing IP
routing on that interface.
Is it important to emphasize the use of "a single interface"? I'm
curious why this was specified here (or why it was not added to the
analogous definition of a LoWPAN Mesh Node).
Are there LoWPAN nodes with more than one interface? If yes, can it be
ruled out that they are routers? If no, shouldn't the number of
interfaces be left open?
Dominik
On Tue, Sep 22, 2009 at 5:21 AM, Zach Shelby <[email protected]> wrote:
> A new version of 6lowpan-nd is now available. I fixed a few bugs that
> Carsten found and improved the terminology with Joakim's feedback. Still
> shooting at nd-07 before the Hiroshima cutoff, so keep the comments coming.
>
> http://www.ietf.org/id/draft-ietf-6lowpan-nd-06.txt
>
> Changes from -05 to -06:
>
> o Fixed the Prf codes (#52).
>
> o Corrected the OIIO TID field to 8-bits. Changed the Nonce/OII
> order in both the OIIO and the NR/NC. (#53)
>
> o Corrected an error in Table 1 (#54).
>
> o Fixed asymmetric and a misplaced transient in the 6lowpan
> terminology section.
>
> o Added Updates RFC4861 to header
>
> Zach
>
> -------- Original Message --------
> Subject: New Version Notification for draft-ietf-6lowpan-nd-06
> Date: Mon, 21 Sep 2009 14:15:52 -0700 (PDT)
> From: IETF I-D Submission Tool <[email protected]>
> To: [email protected]
> CC:
> [email protected],[email protected],[email protected],[email protected],[email protected]
>
>
> A new version of I-D, draft-ietf-6lowpan-nd-06.txt has been successfuly
> submitted by Zach Shelby and posted to the IETF repository.
>
> Filename: draft-ietf-6lowpan-nd
> Revision: 06
> Title: 6LoWPAN Neighbor Discovery
> Creation_date: 2009-09-22
> WG ID: 6lowpan
> Number_of_pages: 61
>
> Abstract:
> This document specifies Neighbor Discovery optimized for 6LoWPAN.
> The 6LoWPAN format allows IPv6 to be used over energy and bandwidth
> constrained wireless networks often making use of multihop
> topologies. However, the use of standard IPv6 Neighbor Discovery
> with 6LoWPAN has several problems. Standard Neighbor Discovery was
> not designed for non-transitive wireless links, and the standard IPv6
> link concept and heavy use of multicast makes it unpractical. This
> document specifies a new ND mechanism allowing for the efficient
> detection of duplicate addresses over entire LoWPANs, which also
> optimizes other ND operations. In addition, context dissemination,
> claim and defend address generation, and the support of Extended
> LoWPANs over Backbone Links are specified.
>
>
>
>
> The IETF Secretariat.
>
>
>
> --
> http://www.sensinode.com
> http://zachshelby.org - My blog “On the Internet of Things”
> Mobile: +358 40 7796297
>
> Zach Shelby
> Head of Research
> Sensinode Ltd.
> Kidekuja 2
> 88610 Vuokatti, FINLAND
>
> This e-mail and all attached material are confidential and may contain
> legally privileged information. If you are not the intended recipient,
> please contact the sender and delete the e-mail from your system without
> producing, distributing or retaining copies thereof.
> _______________________________________________
> 6lowpan mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6lowpan
>
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
