Subject: [6lowpan] [Fwd: New Version Notification for draft-ietf-6lowpan-nd-04]

From: Zach Shelby <[email-masked]>
Date: Sun, 12 Jul 2009 23:42:05 +0300

Hi,

A new version of draft-ietf-6lowpan-nd is now available:

http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-nd-04.txt

I will present this in Stockholm, if there are any issues you want me to 
particularly touch on during the WG meeting, please drop me an e-mail.

    Changes since -03:

       o Moved Ad-hoc LoWPAN operation to Section 7 and made ULA prefix
       generation a features useful also in Simple and Extended LoWPANs.
       (#41)

       o Added a 32-bit Owner Nonce to the NR/NC messages and the
       Whiteboard, removed the TID history. (#39)

       o Improved the duplicate OII detection algorithm using the Owner
       Nonce. (#39)

       o Clarified the use of Source and Target link-layer options in
       NR/NC. (#43)

       o Included text on the use of alternative methods to acquire
       addresses. (#38)

       o Removed S=2 from Address Option (not needed). (#36)

       o Added a section on router dissemination consistency. (#44)

       o Small improvements and extensive editing. (#42, #37, #35)

- Zach

-------- Original Message --------
Subject: New Version Notification for draft-ietf-6lowpan-nd-04
Date: Sun, 12 Jul 2009 13:32:47 -0700 (PDT)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
CC: 
[email-masked],[email-masked],[email-masked],[email-masked]

A new version of I-D, draft-ietf-6lowpan-nd-04.txt has been successfuly 
submitted by Zach Shelby and posted to the IETF repository.

Filename:	 draft-ietf-6lowpan-nd
Revision:	 04
Title:		 6LoWPAN Neighbor Discovery
Creation_date:	 2009-07-12
WG ID:		 6lowpan
Number_of_pages: 56

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 inefficient.  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.

---

From: Hamid Mukhtar <[email-masked]>
Date: Tue, 21 Jul 2009 11:32:54 +0900

Dear Zach,

I had a few queries on the current ND.

Firstly, what are the assumed capabilities of the 6LoWPAN Routers (the
forwarding devices), are they supposed to have more memory than the
end devices or are they assumed to be static or main-powered. I
presume they are not deployed for the sole purpose of forwarding.
Moreover, is the availability of a router in every 6LoWPAN link
assumed ?

Secondly, is the use of Neighbor and destination cache optional for
the 6LoWPAN node in the new ND.

Lastly, I guess some elaboration is needed for the routing of
ER_ANYCAST. Is it assumed that the ROLL routing protocol, once they
have a consensus over it, or some other routing protocol would be in
place for that?

Thanks,
Hamid

On Mon, Jul 13, 2009 at 5:42 AM, Zach Shelby <[email-masked]> wrote:
> I will present this in Stockholm, if there are any issues you want me to particularly touch on during the WG meeting, please drop me an e-mail.
>
>   Changes since -03:
>
> CC: [email-masked],[email-masked],[email-masked],[email-masked]
>
>
> A new version of I-D, draft-ietf-6lowpan-nd-04.txt has been successfuly submitted by Zach Shelby and posted to the IETF repository.
>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 22 Jul 2009 12:07:05 -0400

Zach,

> Date: Sun, 12 Jul 2009 23:42:05 +0300
> From: Zach Shelby <[email-masked]>
>

I skimmed through the changes and they are definitely an
improvement.  Using a nonce is simpler and more foolproof
than the TID history, and uses less RAM as well.

Given the reduced reliance on the TID, perhaps it could be a
single byte.  The 32-bit valid lifetime field in the Prefix
Information Option definitely seems like overkill.  That is
a lot of precision.  Saving space in the ND options may not
matter a lot, given how rarely they are sent, but reducing
the size of a whiteboard entry would be good.

                                    -Richard Kelsey

---

From: Zach Shelby <[email-masked]>
Date: Mon, 27 Jul 2009 16:49:58 +0300

Hi,

> Moreover, is the availability of a router in every 6LoWPAN link

Of course a LoWPAN router will need a bit more memory than a host, but 
this depends mostly on the routing protocol state needed. ND only 
requires some RA variables and prefix information to be stored in 
addition to normal host state. They do not necessarily need to be mains 
powered. Routers can of course act as hosts as well.

> the 6LoWPAN node in the new ND.

The neighbor cache is required, but the number of entries is usually 
pretty small as these are nodes you communicate with in link-local 
scope. If you only communicate with your on-link router then you don't 
necessarily have any neighbor cache entries.

The destination cache is a MAY - thus optional.

> have a consensus over it, or some other routing protocol would be in

It is assumed that a routing protocol knows how to deal with ER_ANYCAST. 
ND is agnostic to which routing protocol (if any) is used in the LoWPAN. 
ROLL is an obvious candidate for sure.

- Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND