Subject: [6tsch] doodle poall for a call

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 4 Feb 2013 17:24:31 +0000

Hi :

In order to prepare for Orlando, it would be good that we have an open call and discuss goals. Ideally that would help us figure a content for a Bar Bof. Short term, we probably need to clarify:

1) what TSCH is. A draft (a few pages) would be useful to explain where is plays, and where it could play in the future.  What's so specific and why it's so important that we work on it. This would ultimately be a reference to support a WG creation. This doc must be very clear on what the real problem is. The way I read it the root problem is the TS aspect, while the CH can be probably be hidden in a sublayer, which we need to specify and provide interface with for routing and forwarding. And we have goals of 1) enabling deterministic flows, 2) maintaining budgets of jitter and latency 3) optimizing energy consumption.

Volunteers?

2) A scope for the work items. That's a (set of) 802.15.4e TSCH LLNs and a probably backbone to scale the cases like industrial - we can point to /  reuse the problem and applicability statements from ROLL as a source of information -. In turn, a bar bof in Orlando  would help us figure the real deliverables. We already got a lot of feedback from the list. So far I've seen that we want:

a) an architecture that shows how the existing standards work together. Includes the likes of PANA, RPL (OF), 6LoWPAN, FoRCES...
     Various flows must be described if they need different handlings. The architecture will show missing pieces and overlaps. I think we want to start discussing those in our first round so that we can solve them later.
b) a link model. Probably split in generic (IPv6 abstraction) and specific (4e implementation).
     Probably the link local protocols (often mcast, eg NA or DIA) will use a shared slot and traffic will use dedicated slot but routing does not need to know.
c) a sublayer specification to implement that model, including IE level exchange information and IP based interface to negotiate bandwidth from fwd plane.  This could be handled as a simple congestion feedback from fwd plane. Or a knowledge of throughput like in slot/s as was mentioned on the list but I do not see that L3 really needs that visibility.
d) a RPL OF that leverages that sublayer. RPL base should be transparent. But the OF handles the peerings and the metrics so it will definitely know.

Who's coming?

Also (later?):
e) a reservation protocol to optimize a sequence of hops from/to the root. Optimizing relays implies a common sense of time along the path so that what comes in goes out rapidly.
f) an openflow type of approach if the central computer needs to control both the path and the channel/slot sequence.
g) filling the gaps, like fragment handling, DAD across a backbone, ...

I created a doodle to get your availability. From there, I'll schedule a weekly call and we'll see if that is an efficient tool or not...

Please go to
http://doodle.com/9vq5qmxzdg6w63t7

Cheers,

Pascal

Pascal Thubert
IPv6 Engineering

[email-masked]<mailto:[email-masked]>
Phone :+33 497 23 26 34
Mobile :+33 619 98 29 85

Cisco Systems
Village d'Entreprises Green Side bat. T3
400, Avenue Roumanille
06410 Biot - Sophia Antipolis
France
Cisco.com<http://www.cisco.com/global/FR/>

[Description: http://www.cisco.com/web/europe/images/email/signature/vertical04.jpg]

For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 4 Feb 2013 09:37:03 -0800

Pascal,

Thanks for putting the Doodle together, I've added my name.

I'm planning on coming to Orlando. I've also started a write-up for your
item 1). I should be able to upload a first version by the end of the week.

Thomas

On Mon, Feb 4, 2013 at 9:24 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hi :****
>
> ** **
>
> In order to prepare for Orlando, it would be good that we have an open
> call and discuss goals. Ideally that would help us figure a content for a
> Bar Bof. Short term, we probably need to clarify:****
>
> ** **
>
> 1) what TSCH is. A draft (a few pages) would be useful to explain where is
> plays, and where it could play in the future.  What’s so specific and why
> it’s so important that we work on it. This would ultimately be a reference
> to support a WG creation. This doc must be very clear on what the real
> problem is. The way I read it the root problem is the TS aspect, while the
> CH can be probably be hidden in a sublayer, which we need to specify and
> provide interface with for routing and forwarding. And we have goals of 1)
> enabling deterministic flows, 2) maintaining budgets of jitter and latency
> 3) optimizing energy consumption. ****
>
> ** **
>
> Volunteers?****
>
> ** **
>
> 2) A scope for the work items. That’s a (set of) 802.15.4e TSCH LLNs and a
> probably backbone to scale the cases like industrial – we can point to /
>  reuse the problem and applicability statements from ROLL as a source of
> information -. In turn, a bar bof in Orlando  would help us figure the real
> deliverables. We already got a lot of feedback from the list. So far I’ve
> seen that we want:****
>
> ** **
>
> a) an architecture that shows how the existing standards work together.
> Includes the likes of PANA, RPL (OF), 6LoWPAN, FoRCES… ****
>
>      Various flows must be described if they need different handlings. The
> architecture will show missing pieces and overlaps. I think we want to
> start discussing those in our first round so that we can solve them later.
> ****
>
> b) a link model. Probably split in generic (IPv6 abstraction) and specific
> (4e implementation). ****
>
>      Probably the link local protocols (often mcast, eg NA or DIA) will
> use a shared slot and traffic will use dedicated slot but routing does not
> need to know.****
>
> c) a sublayer specification to implement that model, including IE level
> exchange information and IP based interface to negotiate bandwidth from fwd
> plane.  This could be handled as a simple congestion feedback from fwd
> plane. Or a knowledge of throughput like in slot/s as was mentioned on the
> list but I do not see that L3 really needs that visibility.****
>
> d) a RPL OF that leverages that sublayer. RPL base should be transparent.
> But the OF handles the peerings and the metrics so it will definitely know.
> ****
>
> ** **
>
> Who’s coming?****
>
> ** **
>
> Also (later?):****
>
> e) a reservation protocol to optimize a sequence of hops from/to the root.
> Optimizing relays implies a common sense of time along the path so that
> what comes in goes out rapidly.****
>
> f) an openflow type of approach if the central computer needs to control
> both the path and the channel/slot sequence.****
>
> g) filling the gaps, like fragment handling, DAD across a backbone, …****
>
> ** **
>
> I created a doodle to get your availability. From there, I'll schedule a
> weekly call and we'll see if that is an efficient tool or not…****
>
> ** **
>
> Please go to ****
>
> http://doodle.com/9vq5qmxzdg6w63t7 ****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Pascal****
>
> ** **
>
> ** **
>
>
> *Pascal Thubert*
> *IPv6 Engineering*
>
> [email-masked]
> Phone :*+33 497 23 26 34*
> Mobile :*+33 619 98 29 85*****
>
>
> *Cisco Systems*
> France****
> Cisco.com <http://www.cisco.com/global/FR/>****
>
> [image: Description:
> http://www.cisco.com/web/europe/images/email/signature/vertical04.jpg]****
>
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html ****
>
> This e-mail may contain confidential and privileged material for the sole
> use of the intended recipient. Any review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient (or
> authorized to receive for the recipient), please contact the sender by
> reply e-mail and delete all copies of this message.****
>
> ** **
>
> ** **
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>

---

From: Xavier Vilajosana <[email-masked]>
Date: Mon, 04 Feb 2013 09:39:28 -0800

Hi Pascal,

I am also coming to Orlando.

I'm volunteer on working with Thomas on item 1.

regards.
Xavi

On 04/02/13 09:37, Thomas Watteyne wrote:
> I'm planning on coming to Orlando. I've also started a write-up for 
> your item 1). I should be able to upload a first version by the end of 
> the week.
>
> Thomas
>
> On Mon, Feb 4, 2013 at 9:24 AM, Pascal Thubert (pthubert) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi :
>
>     In order to prepare for Orlando, it would be good that we have an
>     open call and discuss goals. Ideally that would help us figure a
>     content for a Bar Bof. Short term, we probably need to clarify:
>
>     1) what TSCH is. A draft (a few pages) would be useful to explain
>     where is plays, and where it could play in the future.  What's so
>     specific and why it's so important that we work on it. This would
>     ultimately be a reference to support a WG creation. This doc must
>     be very clear on what the real problem is. The way I read it the
>     root problem is the TS aspect, while the CH can be probably be
>     hidden in a sublayer, which we need to specify and provide
>     interface with for routing and forwarding. And we have goals of 1)
>     enabling deterministic flows, 2) maintaining budgets of jitter and
>     latency 3) optimizing energy consumption.
>
>     Volunteers?
>
>     2) A scope for the work items. That's a (set of) 802.15.4e TSCH
>     LLNs and a probably backbone to scale the cases like industrial --
>     we can point to /  reuse the problem and applicability statements
>     from ROLL as a source of information -. In turn, a bar bof in
>     Orlando  would help us figure the real deliverables. We already
>     got a lot of feedback from the list. So far I've seen that we want:
>
>     a) an architecture that shows how the existing standards work
>     together. Includes the likes of PANA, RPL (OF), 6LoWPAN, FoRCES...
>
>          Various flows must be described if they need different
>     handlings. The architecture will show missing pieces and overlaps.
>     I think we want to start discussing those in our first round so
>     that we can solve them later.
>
>          Probably the link local protocols (often mcast, eg NA or DIA)
>     will use a shared slot and traffic will use dedicated slot but
>     routing does not need to know.
>
>     c) a sublayer specification to implement that model, including IE
>     level exchange information and IP based interface to negotiate
>     bandwidth from fwd plane.  This could be handled as a simple
>     congestion feedback from fwd plane. Or a knowledge of throughput
>     like in slot/s as was mentioned on the list but I do not see that
>     L3 really needs that visibility.
>
>     d) a RPL OF that leverages that sublayer. RPL base should be
>     transparent. But the OF handles the peerings and the metrics so it
>     will definitely know.
>
>     Who's coming?
>
>     Also (later?):
>
>     e) a reservation protocol to optimize a sequence of hops from/to
>     the root. Optimizing relays implies a common sense of time along
>     the path so that what comes in goes out rapidly.
>
>     f) an openflow type of approach if the central computer needs to
>     control both the path and the channel/slot sequence.
>
>     I created a doodle to get your availability. From there, I'll
>     schedule a weekly call and we'll see if that is an efficient tool
>     or not...
>
>     Please go to
>
>     [email-masked] <mailto:[email-masked]>
>     Phone :*+33 497 23 26 34 <tel:%2B33%20497%2023%2026%2034>*
>     Mobile :*+33 619 98 29 85 <tel:%2B33%20619%2098%2029%2085>*
>
>     	
>
>
>     *Cisco Systems*
>     Cisco.com <http://www.cisco.com/global/FR/>
>
>     	
>
>     Description:
>     http://www.cisco.com/web/europe/images/email/signature/vertical04.jpg
>
>     http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>     This e-mail may contain confidential and privileged material for
>     the sole use of the intended recipient. Any review, use,
>     distribution or disclosure by others is strictly prohibited. If
>     you are not the intended recipient (or authorized to receive for
>     the recipient), please contact the sender by reply e-mail and
>     delete all copies of this message.
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: [email-masked]
Date: Mon, 4 Feb 2013 09:47:07 -0800

Pascal,

I have added my name to Doodle.

What is the time for Orlando meeting?

Qin

>> latency
>> transparent.

---

From: Robert Assimiti <[email-masked]>
Date: Mon, 4 Feb 2013 14:49:59 -0500

Pacscal,

I would also like to volunteer to help with both part 1 and 2. Look forward to also seeing everyone in Orlando.

I would also like to add that for part one we should also consider:

*        Enabling distributed flows that allow for high scalability needed for NAN/MANs

*        Centralized versus distributed link scheduler

*        Optimizing for latency

Thks

Robert Assimiti

From: [email-masked] [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Monday, February 04, 2013 12:25 PM
To: [email-masked]
Subject: [6tsch] doodle poall for a call

Hi :

Volunteers?

Who's coming?

Also (later?):

Please go to

Cheers,

Pascal

Pascal Thubert
IPv6 Engineering

Cisco Systems

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Feb 2013 15:08:49 -0500

>>>>> "pthubert" == pthubert  <Pascal> writes:
    pthubert> 1) what TSCH is. A draft (a few pages) would be useful to
    pthubert> explain where is plays, and where it could play in the
    pthubert> future.  What's so specific and why it's so important that

If not a draft, then references (URLs), to the minimal set of parts of
the IEEE document that one needs to understand.

    pthubert> a) an architecture that shows how the existing standards
    pthubert> work together. Includes the likes of PANA, RPL (OF),
    pthubert> 6LoWPAN, FoRCES...  Various flows must be described if
    pthubert> they need different handlings. The architecture will show
    pthubert> missing pieces and overlaps. I think we want to start
    pthubert> discussing those in our first round so that we can solve
    pthubert> them later.  b) a link model. Probably split in generic
    pthubert> (IPv6 abstraction) and specific (4e implementation).
    pthubert> Probably the link local protocols (often mcast, eg NA or
    pthubert> DIA) will use a shared slot and traffic will use dedicated
    pthubert> slot but routing does not need to know.  c) a sublayer
    pthubert> specification to implement that model, including IE level
    pthubert> exchange information and IP based interface to negotiate
    pthubert> bandwidth from fwd plane.  This could be handled as a
    pthubert> simple congestion feedback from fwd plane. Or a knowledge
    pthubert> of throughput like in slot/s as was mentioned on the list
    pthubert> but I do not see that L3 really needs that visibility.  d)
    pthubert> a RPL OF that leverages that sublayer. RPL base should be
    pthubert> transparent. But the OF handles the peerings and the
    pthubert> metrics so it will definitely know.

It's not at all clear to that, in the non-optimized form, that there are
any on-wire-changes to anything necessary.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Feb 2013 15:09:30 -0500

>>>>> "qinwang" == qinwang  <[email-masked]> writes:
    qinwang> What is the time for Orlando meeting?

There is no time set yet.

---

From: <[email-masked]>
Date: Mon, 4 Feb 2013 20:57:32 +0000

Hi Pascal,

I can help on PANA part.  I will attend Orlando meeting.

Yoshihiro Ohba

From: [email-masked] [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, February 05, 2013 2:25 AM
To: [email-masked]
Subject: [6tsch] doodle poall for a call

Hi :

1) what TSCH is. A draft (a few pages) would be useful to explain where is plays, and where it could play in the future.  What’s so specific and why it’s so important that we work on it. This would ultimately be a reference to support a WG creation. This doc must be very clear on what the real problem is. The way I read it the root problem is the TS aspect, while the CH can be probably be hidden in a sublayer, which we need to specify and provide interface with for routing and forwarding. And we have goals of 1) enabling deterministic flows, 2) maintaining budgets of jitter and latency 3) optimizing energy consumption.

Volunteers?

2) A scope for the work items. That’s a (set of) 802.15.4e TSCH LLNs and a probably backbone to scale the cases like industrial - we can point to /  reuse the problem and applicability statements from ROLL as a source of information -. In turn, a bar bof in Orlando  would help us figure the real deliverables. We already got a lot of feedback from the list. So far I’ve seen that we want:

a) an architecture that shows how the existing standards work together. Includes the likes of PANA, RPL (OF), 6LoWPAN, FoRCES…

Who’s coming?

Also (later?):
e) a reservation protocol to optimize a sequence of hops from/to the root. Optimizing relays implies a common sense of time along the path so that what comes in goes out rapidly.
f) an openflow type of approach if the central computer needs to control both the path and the channel/slot sequence.
g) filling the gaps, like fragment handling, DAD across a backbone, …

I created a doodle to get your availability. From there, I'll schedule a weekly call and we'll see if that is an efficient tool or not…

Please go to

Cheers,

Pascal

Pascal Thubert
IPv6 Engineering

Cisco Systems

---

From: Nick Moore <[email-masked]>
Date: Tue, 05 Feb 2013 14:39:05 +1100

On 05/02/13 04:24, Pascal Thubert (pthubert) wrote:
>
> I created a doodle to get your availability. From there, I'll schedule 
> a weekly call and we'll see if that is an efficient tool or not...
>

Sadly, I'm not my usual cheery self at 03:00 (Australian time) ... 
still, the world being round [1] it is likely impossible to find a time 
that suits everyone.

I won't be in Orlando either.  Pity, I'd love to be involved :-(. Happy 
to help with editing, etc.

-----Nick

[1] classic premature optimization, doesn't scale well.

-- 
Nick Moore <[email-masked]> 0409 656 267

---

From: [email-masked]
Date: Mon, 4 Feb 2013 20:31:25 -0800

Pascal,

I will attend the meeting in Orlando.

Qin

> Bar Bof. Short term, we probably need to clarify:
>
> plays, and where it could play in the future.  What's so specific and why
> it's so important that we work on it. This would ultimately be a reference
> 3) optimizing energy consumption.
>
> Volunteers?
>
> 2) A scope for the work items. That's a (set of) 802.15.4e TSCH LLNs and a
> probably backbone to scale the cases like industrial - we can point to /
> information -. In turn, a bar bof in Orlando  would help us figure the
> real deliverables. We already got a lot of feedback from the list. So far
> I've seen that we want:
>
> Includes the likes of PANA, RPL (OF), 6LoWPAN, FoRCES...
> architecture will show missing pieces and overlaps. I think we want
> to start discussing those in our first round so that we can solve
> them later.
> (4e implementation).
> use a shared slot and traffic will use dedicated slot but routing
> does not need to know.
> exchange information and IP based interface to negotiate bandwidth from
> fwd plane.  This could be handled as a simple congestion feedback from fwd
> list but I do not see that L3 really needs that visibility.
> what comes in goes out rapidly.
> both the path and the channel/slot sequence.
> weekly call and we'll see if that is an efficient tool or not...
>
> Please go to
> [Description:
> http://www.cisco.com/web/europe/images/email/signature/vertical04.jpg]
>
> by others is strictly prohibited. If you are not the intended recipient
> (or authorized to receive for the recipient), please contact the sender by
> reply e-mail and delete all copies of this message.
>
>
>

---

From: Grieco <[email-masked]>
Date: Tue, 5 Feb 2013 09:31:45 +0100

Dear Pascal,

Many thanks for the poll: I added my name too. I can contribute to 1).

Cheers

Alfredo

--
Luigi Alfredo Grieco, PhD
Assistant Professor
Department of Electrical and Information Engineering
Politecnico di Bari
Via Orabona 4 - 70125 - Bari - Italy
+39 080 5963 911
telematics.poliba.it/grieco
Skype id: l.alfredo.grieco
Mobile: +39 3346715672

On 4 Feb 2013, at 18:24, "Pascal Thubert (pthubert)" <[email-masked]> wrote:

> 2) A scope for the work items. That’s a (set of) 802.15.4e TSCH LLNs and a probably backbone to scale the cases like industrial – we can point to /  reuse the problem and applicability statements from ROLL as a source of information -. In turn, a bar bof in Orlando  would help us figure the real deliverables. We already got a lot of feedback from the list. So far I’ve seen that we want:
>  
> Cisco.com

---

From: Pascal Thubert <[email-masked]>
Date: Tue, 5 Feb 2013 13:18:20 +0100

Hello:

We have a clear problem with the Asia/pac zone. We need to discuss what we
can do, like have 2 separate calls and share minutes, or wha else?t

The draw for the time being is between Wednesdays and Fridays, 9AM Pacific
18H CET...

Please weight in!

-- 
Pascal

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Feb 2013 10:49:38 -0500

>>>>> "Pascal" == Pascal Thubert <[email-masked]> writes:
    Pascal> We have a clear problem with the Asia/pac zone. We need to
    Pascal> discuss what we can do, like have 2 separate calls and share
    Pascal> minutes, or wha else?t

Post drafts, and use email.

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 5 Feb 2013 12:22:21 -0500

the usual way to deal with large range of timezones is to have the North America west coast start very early (like 5am). there is no perfect solution.

Marc.

Le 2013-02-05 à 07:18, Pascal Thubert a écrit :

> Hello:
> 
> We have a clear problem with the Asia/pac zone. We need to discuss what we can do, like have 2 separate calls and share minutes, or wha else?t
> 
> The draw for the time being is between Wednesdays and Fridays, 9AM Pacific 18H CET...
> 
> Please weight in!
> 
> -- 
> Pascal _______________________________________________
> 6tsch mailing list
> [email-masked]

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 6 Feb 2013 12:44:58 +0100

Hi Pascal, and all,

I will not be able to attend, but happy to participate remotely in 1 and 2,

Thanks,
AB

On 2/4/13, Pascal Thubert (pthubert) <[email-masked]> wrote:
> Hi :
>
> In order to prepare for Orlando, it would be good that we have an open call
> and discuss goals. Ideally that would help us figure a content for a Bar
> Bof. Short term, we probably need to clarify:
>
> deliverables. We already got a lot of feedback from the list. So far I've
> seen that we want:
>
> architecture will show missing pieces and overlaps. I think we want to start
> discussing those in our first round so that we can solve them later.
>      Probably the link local protocols (often mcast, eg NA or DIA) will use
> a shared slot and traffic will use dedicated slot but routing does not need
> to know.
> Optimizing relays implies a common sense of time along the path so that what
> comes in goes out rapidly.
> authorized to receive for the recipient), please contact the sender by reply
> e-mail and delete all copies of this message.
>
>
>
>