Subject: Re: [6lowpan] 6lowpan ND joint-work goals

From: "Samita Chakrabarti" <[email-masked]>
Date: Tue, 2 Sep 2008 18:49:47 -0700

Hi Paul,

Sorry for the delay in my response.

The new concept of link is defined by Jonathan Hui's draft on route-over ND.

As far as I understand, they extended the concept of link from the
traditional IP subnet link to a concept where link is bounded by the
radio reachability. Since the sensors are not connected by the wired
link, the definition, as I understand is the link which encompasses
the neighbors who can send/receive messages to each-other.

Jonathan or David, please correct if this definition is incorrect.

Thanks,
-Samita

On Sun, Aug 17, 2008 at 11:52 PM, Paul Chilton <[email-masked]> wrote:
> Hi Samita
> This set of design goals looks like it will meet the WG requirements.
> However, I am not sure I understand the bullet point
>
> "Define a link that serves 6lowpan common deployment"
>
> Could you expand on what you mean by this?
> Thanks
> Paul
>
> On Sun, 2008-08-10 at 17:14 -0700, Samita Chakrabarti wrote:
>> Hi All:
>>
>> Since we are starting to work on the combined ND solution for 6lowpan,
>> as one of the members of the ad-hoc ND team, I thought it would be
>> very useful to verify our solution guidelines with the working group.
>> I am starting with a few bullet points, please check if that meets our
>> (6lowpan wg) requirements. Please feel free to suggest modification
>> when it makes sense.
>>
>> ND Design goals:
>>
>>
>> * Neighbor discovery using IPv6 ND protocol or its variant
>> * The solution will use unicast/anycast messages to reduce mulitcast
>> * The solution should look into minimizing number of total ND messages
>> *  Initial boot-strapping information and fault-tolerance should be
>> addressed if possible
>> * This solution must provide methods for IPv6 address allocation in
>> 6lowpan nodes
>> * Define a link that serves 6lowpan common deployment
>> * The design should work with mesh-under(L2) and route-over(L3) routing
>> * The design should be scalable for adding new nodes into the network
>> * The solution should also keep in mind that 6lowpan is a low bW network
>> * The ND design  may not necessarily address mobility in boot-strapping
>>    and address assignment, but it may be extendable to address
>> mobility in future.
>> * The design will use IPv6 auto-configuration as the main method for
>> address assignment; however stateful address configuration will also
>> be considered
>>
>>
>> Thanks,
>> -Samita
>> _______________________________________________
>> 6lowpan mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/6lowpan
>
> Paul Chilton
> Jennic Ltd
> Furnival Street
> Sheffield, UK
> S10 3DX
>
>
>
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Tue, 2 Sep 2008 19:16:19 -0700

Hi Mr. Kang,

I believe Jonathan Hui already responded to your question.

Sorry for the delayed response.

We had discussions on the new concept of this link at Dublin IETF
following Jonathan's draft presentation.

If folks still have questions on the new definition of link which
covers both single and multihop, this might be a good time to discuss
it on the mailing list.

Regards,
-Samita

On Mon, Aug 18, 2008 at 10:17 AM, Chol Su Kang <[email-masked]> wrote:
> Hi Samita,
> I have questions on
> Has there been any discussion on this 6lowpan common deployment link?
>
> Chol Su Kang
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Geoff Mulligan
> Sent: Friday, August 15, 2008 2:48 PM
> To: Samita Chakrabarti
> Cc: [email-masked]; 6lowpan
> Subject: Re: [6lowpan] 6lowpan ND joint-work goals
>
> So is this correct?  Did Samita summarize the guidelines correctly.
>
> What is the plan for the design team.
>
>        geoff
>