Thomas

[1] IEEE802.15.4e, Section 6.2.19.3

[2]=A0IEEE802.15.4e, Section 5.1.1a

On Tu= e, Jan 29, 2013 at 6:05 AM, Michael Richardson <mcr+ietf@sandelman.ca<= /a>> wrote:

>>>>> "Nick" =3D=3D Nick Moore <nick@zoic.org> writes:

=A0 =A0 Nick> * Should all this

=A0 =A0 Nick> be happening down in the MAC layer instead?

=A0 =A0 >> No.

=A0 =A0 Nick> OK, but why? =A0What makes this an L3 (/ L2.5) thing?

=A0 =A0 Nick> I'm not just asking to be contrarian, if this is to be= come an
=A0 =A0 Nick> IETF WG that'd be part of the charter ...

A number of reasons.
1) the bufferbloat results suggests that buffering at L2 is a bad
=A0 =A0thing. =A0While very resource constrained nodes are unlikely to have= much
=A0 =A0buffer at all, this is not true for edge/gateway nodes, and it is =A0 =A0increasing untrue of various wearable and PAN-type devices such as =A0 =A0smartphones which will get LLN interfaces.

=A0 =A0It was particularly a surprise to many layer-3 types what the 802.11=
=A0 =A0access point people are doing at layer 2. =A0A lot of it invalidates=
=A0 =A0significant architectural assumptions. =A0In many cases, the layer-2=
=A0 =A0optimizations are coding to the benchmarks, rather than the real tra= ffic.

2) layer-3 (and higher) may need to make (re-)prioritization decisions base= d
=A0 =A0upon what the transimission schedule is.
=A0 =A0Consider an actuator of some kind (a device that includes a fire
=A0 =A0supressor...) that, due to its critical nature has multiple layer-2<= br> =A0 =A0connections using different technologies. =A0Maybe IPv6 over CAN ove= r
=A0 =A09600 baud multi-drop RS422 and 4e. =A0Layer-3 LLNs can easily build = a
=A0 =A0DAG that includes both transports, realize that as slow as the 4e =A0 =A0might be, it's usually still faster for non-critical traffic tha= n the CAN.

=A0 =A0The layer-3 DAG would actually permit the the device to be addressed=
=A0 =A0by the application using a single IPv6 address, with the network
=A0 =A0figuring out how to get things there. =A0That means less complexity = and
=A0 =A0network knowledge required by the application.

=A0 =A0There may be times during the 4e cycle when the CAN is faster than =A0 =A0the wireless. =A0There also could be congestion on the 4e which woul= d
=A0 =A0cause the slot to be missed. =A0If the packet remained queued for th= e
=A0 =A0same layer-2, it would remain for an entire cycle.

3) In the ethernet world, I point to STP and its variants as layer-2
=A0 =A0attempts to do routing, which failed. =A0Well, it does what it was =A0 =A0advertised to do (detect and disable loops), but it turns out that =A0 =A0we need much more than that.
=A0 =A0People have gone to layer-3 solutions like OSPF instead, because it<= br> =A0 =A0provides diagnostics, works across vendors, and it responds much
=A0 =A0faster. And we also have TRILL.

--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works

_______________________________________________
6tsch mailing list
6tsch@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/6tsch

--f46d042dfd354a1b8504d472e686-- From maria-rita.palattella@uni.lu Tue Jan 29 13:14:09 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0B021F8888 for <6tsch@ietfa.amsl.com>; Tue, 29 Jan 2013 13:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDPWnNKXTUSg for <6tsch@ietfa.amsl.com>; Tue, 29 Jan 2013 13:14:07 -0800 (PST) Received: from hercules.uni.lu (hercules.uni.lu [158.64.76.33]) by ietfa.amsl.com (Postfix) with ESMTP id 15E0121F875A for <6tsch@ietf.org>; Tue, 29 Jan 2013 13:14:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,561,1355094000"; d="scan'208,217";a="21956940" Received: from unknown (HELO TPOL.uni.lux) ([10.21.2.5]) by hercules.uni.lu with ESMTP; 29 Jan 2013 22:14:04 +0100 Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by TPOL.uni.lux ([fe80::e14d:a815:d7d8:d9a6%10]) with mapi id 14.01.0438.000; Tue, 29 Jan 2013 22:14:04 +0100 From: Maria Rita PALATTELLA To: Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org> Thread-Topic: [6tsch] Welcome to the "6tsch" mailing list Thread-Index: AQHN+oslS9BIhoHFekufmuDjST986phZHG0AgAEvBYCABUR/AIAAFe8AgAAsSACAAHtbAIAAZEqAgAAdsVQ= Date: Tue, 29 Jan 2013 21:14:03 +0000 Message-ID: References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca>, In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.34.0.8] Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185171E2hoshiunilux_" MIME-Version: 1.0 Subject: Re: [6tsch] Welcome to the "6tsch" mailing list X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 21:14:09 -0000 --_000_F085911F642A6847987ADA23E611780D185171E2hoshiunilux_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thomas, for sure it is a long email, but full of interesting info and thoughts! I totally agree with you about the idea of having a 6tsch layer, between TS= CH and RPL. Actually, TASA (Traffic-Aware Scheduling Algorithm [1-3]) is bu= ilt on such idea. TASA is a centralized scheduling algorithm, running on a master node in a I= EEE802.1.5.4e network. It allows to build TSCH schedule, based on the netwo= rk topology and the traffic load. Thus, it uses the information related to = the paths, coming from RPL, and those related to the traffic (i.e., average= traffic load generated by each node) in order to provide time slots/channe= l hops patterns, able to fulfill given requirements (i.e., duty cycle, thro= ughput, etc.) . You can find more info and details here: * [1] Palattella, Maria Rita; Accettura, Nicola; Dohler, Mischa; Grieco= , Luigi Alfredo; Boggia, Gennaro: Traffic Aware Scheduling Algorithm for Mu= lti-Hop IEEE 802.15.4e Networks, Pe= rsonal Indoor and Mobile Radio Communications (PIMRC), 2012 IEEE 23rd Inter= national Symposium on, 2012, pp. 327-332 * [2] Palattella, Maria Rita; Accettura, Nicola; Dohler, Mischa; Grieco= , Luigi Alfredo; Boggia, Gennaro: Traffic-Aware Time-Critical Scheduling In= Heavily Duty-Cycled IEEE 802.15.4e For An Industrial IoT, Proc. of IEEE Sensors 2012, 2012. * [3] Accettura, Nicola; Palattella, Maria Rita; Dohler, Mischa; Grieco= , Luigi Alfredo; Boggia, Gennaro: Standardized Power-Efficient & Internet-E= nabled Communication Stack for Capillary M2M Networks, Proc. of IEEE WCNC 2012, Workshop on Internet of Things= Enabling Technologies, 2012, pp. 226-231, ISBN: 978-1-4673-0681-2 Of course, I will be more than happy in providing more information, and dis= cuss more about TASA in case you may find in it a possible solution to our = problem (or at least, part of the problem)! Best Regards, Maria Rita ________________________________ From: 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of Thomas W= atteyne [watteyne@eecs.berkeley.edu] Sent: Tuesday, January 29, 2013 9:04 PM To: 6tsch@ietf.org Subject: Re: [6tsch] Welcome to the "6tsch" mailing list Nick, Michael, Very interesting discussion, indeed. I can't resist to add my 2c. IEEE802.15.4e TSCH makes a subtle distinction between a link ("a single slo= t scheduled from mote A to mote B") and a path ("union of all links between= A and B"). A link is attached a tuple [1]. If multiple links are scheduled to the same neighbor, they ar= e typically equivalent, i.e. the MAC layer sends the packet on whichever of= these links happens to show up after the packet was put in the MAC queue. = Since the slotframe repeats over time (and the length of the slotframe is t= ypically constant), each link gives you a "quantum" of bandwidth to a given= neighbor. By modifying the number of links in a path, you modify the resou= rces allocated between two neighbors. The TSCH standard is *extremely* flexible, and you can implement lots of fa= nciness within the standard. Implementations can for example keep per-link = statistics: at any time, you can know how many packets you sent/received, f= or each neighbor and for each link. Based on this information, you can play= with the queuing behavior (e.g. wait for this link to show up because this= one is behaving bad), or with the schedule (e.g. link 14 to neighbor A is = worse than all the other to this neighbor, let's talk to mote A to replace = it with another one). TSCH really only defines how to execute the schedule,= so there's lots (and lots) of room for defining behavior. Maybe too much room to be handled entirely by RPL. As I see it, RPL only wa= nts to know about some cost associated with the topology, and uses that to = compute multi-hop routes. In particular, I believe RPL is more interested i= n paths (the "performance" of the connection between two neighbors), rather= than the individual links making up each path. In my opinion (and this is,= I believe, perfectly in line with Xavi's comment), we could define a 6tsch= layer which sits between TSCH and RPL. The goal of this layer would be to = (1) turn some throughput requirements into links in the schedule and (2) co= llect information and feedback path statistics to RPL. Implementations of this layer can be all over the spectrum: it can be contr= olled by an outside (central) scheduler, it can implement some neighbor-to-= neighbor communication to set up a schedule in a distributed fashion, or an= ything in-between. The goal is, I believe, to avoid for RPL to have to spec= ify the exact slot to send on, RPL tells the 6tsch layer to "send this pack= et to neighbor A". To come back to Michael's comment, I believe that, with this setup, RPL act= ually can be using traditional metrics (ETX, bandwidth, latency, etc), the = 6tsch layer taking care of MAC specifics. One last thing I believe is important: what TSCH does define is how to freq= uency hop. At each occurrence of a slot in the slotframe, the frequency to = communicate on is recalculated [2], and is different from the last time. Th= is means that neither the 6tsch layer nor RPL need to worry about the actua= l frequency to communicate on; the schedule just looks like a grid. I realize now this became a quite long e-mail, thanks for ready through her= e! Thoughts? Thomas [1] IEEE802.15.4e, Section 6.2.19.3 [2] IEEE802.15.4e, Section 5.1.1a On Tue, Jan 29, 2013 at 6:05 AM, Michael Richardson > wrote: >>>>> "Nick" =3D=3D Nick Moore > writes= : Nick> * Should all this Nick> be happening down in the MAC layer instead? >> No. Nick> OK, but why? What makes this an L3 (/ L2.5) thing? Nick> I'm not just asking to be contrarian, if this is to become an Nick> IETF WG that'd be part of the charter ... A number of reasons. 1) the bufferbloat results suggests that buffering at L2 is a bad thing. While very resource constrained nodes are unlikely to have much buffer at all, this is not true for edge/gateway nodes, and it is increasing untrue of various wearable and PAN-type devices such as smartphones which will get LLN interfaces. It was particularly a surprise to many layer-3 types what the 802.11 access point people are doing at layer 2. A lot of it invalidates significant architectural assumptions. In many cases, the layer-2 optimizations are coding to the benchmarks, rather than the real traffic= . 2) layer-3 (and higher) may need to make (re-)prioritization decisions base= d upon what the transimission schedule is. Consider an actuator of some kind (a device that includes a fire supressor...) that, due to its critical nature has multiple layer-2 connections using different technologies. Maybe IPv6 over CAN over 9600 baud multi-drop RS422 and 4e. Layer-3 LLNs can easily build a DAG that includes both transports, realize that as slow as the 4e might be, it's usually still faster for non-critical traffic than the CA= N. The layer-3 DAG would actually permit the the device to be addressed by the application using a single IPv6 address, with the network figuring out how to get things there. That means less complexity and network knowledge required by the application. There may be times during the 4e cycle when the CAN is faster than the wireless. There also could be congestion on the 4e which would cause the slot to be missed. If the packet remained queued for the same layer-2, it would remain for an entire cycle. 3) In the ethernet world, I point to STP and its variants as layer-2 attempts to do routing, which failed. Well, it does what it was advertised to do (detect and disable loops), but it turns out that we need much more than that. People have gone to layer-3 solutions like OSPF instead, because it provides diagnostics, works across vendors, and it responds much faster. And we also have TRILL. -- Michael Richardson >,= Sandelman Software Works _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch --_000_F085911F642A6847987ADA23E611780D185171E2hoshiunilux_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thomas,

for sure it is a long email, but full of interesting info and thoughts!

I totally agree with you about the idea of having a 6tsch layer, between TS= CH and RPL. Actually, TASA (Traffic-Aware Scheduling Algorithm [1-3]) is bu= ilt on such idea.

TASA is a centralized scheduling algorithm, running on a master node in a I= EEE802.1.5.4e network. It allows to build TSCH schedule, based on the netwo= rk topology and the traffic load. Thus, it uses the information related to = the paths, coming from RPL, and those related to the traffic (i.e., average traffic load generated by each= node) in order to provide time slots/channel hops patterns, able to fulfil= l given requirements (i.e., duty cycle, throughput, etc.) .

You can find more info and details here:

[1] Palattella, Maria Rita; Accettura, Nicola; Dohler, Mischa; Grieco, = Luigi Alfredo; Boggia, Gennaro: Traffic Aware Scheduling Algorithm for Multi-Hop IEEE 802.15.4e Networks, Personal Indoor and Mobile Radio Communications (PIMRC), 2012 IE= EE 23rd International Symposium on, 2012, pp. 327-332
[2] Palattella, Maria Rita; Accettura, Nicola; D= ohler, Mischa; Grieco, Luigi Alfredo; Boggia, Gennaro: Traffic-Aware Time-Critical Scheduling In Heavily Duty-Cycled IEEE 802.15.= 4e For An Industrial IoT, Proc. of IEEE Sensors 2012, 2012.
[3] Accettura, Nicola; Palattella, Maria Rita; Dohler, Mischa; Grieco, = Luigi Alfredo; Boggia, Gennaro: Standardized Power-Efficient & Internet-Enabled Communication Stack fo= r Capillary M2M Networks, Proc. of IEEE WCNC 2012, Workshop on I= nternet of Things Enabling Technologies, 2012, pp. 226-231, ISBN: 978-1-4673-0681-2

Of course, I will be more than happy in providing more information, and = discuss more about TASA in case you may find in it a possible solution to o= ur problem (or at least, part of the problem)!

Best Regards,
Maria Rita

From: 6tsch-bounces@ietf.org [6tsch-bou= nces@ietf.org] on behalf of Thomas Watteyne [watteyne@eecs.berkeley.edu] Sent: Tuesday, January 29, 2013 9:04 PM
To: 6tsch@ietf.org
Subject: Re: [6tsch] Welcome to the "6tsch" mailing list

Nick, Michael,

Very interesting discussion, indeed. I can't resist to add my 2c.

IEEE802.15.4e TSCH makes a subtle distinction between a link (&= quot;a single slot scheduled from mote A to mote B") and a path ("union of all links between A and B"). A link is att= ached a <neighbor, slotOffset, channelOffset, TX|RX> tuple [1]. If mu= ltiple links are scheduled to the same neighbor, they are typically equival= ent, i.e. the MAC layer sends the packet on whichever of these links happens to show up after the packet was put in the MAC queu= e. Since the slotframe repeats over time (and the length of the slotframe i= s typically constant), each link gives you a "quantum" of bandwidth to a given neighbo= r. By modifying the number of links in a path, you modify the resources allocated between two neighbors.

The TSCH standard is *extremely* flexible, and you can implement lots = of fanciness within the standard. Implementations can for example keep per-= link statistics: at any time, you can know how many packets you sent/receiv= ed, for each neighbor and for each link. Based on this information, you can play with the queuing behavior (e= .g. wait for this link to show up because this one is behaving bad), or wit= h the schedule (e.g. link 14 to neighbor A is worse than all the other to t= his neighbor, let's talk to mote A to replace it with another one). TSCH really only defines how to execute= the schedule, so there's lots (and lots) of room for defining behavior.

Maybe too much room to be handled entirely by RPL. As I see = it, RPL only wants to know about some cost associated with the topology, an= d uses that to compute multi-hop routes. In particular, I believe RPL is mo= re interested in paths (the "performance" of the connection between two nei= ghbors), rather than the individual links making up each path. In my opinion (and this is, I believe, pe= rfectly in line with Xavi's comment), we could define a 6tsch layer which sits bet= ween TSCH and RPL. The goal of this layer would be to (1) turn some through= put requirements into links in the schedule and (2) collect information and feedback pa= th statistics to RPL.

Implementations of this layer can be all over the spectrum: it can be = controlled by an outside (central) scheduler, it can implement some neighbo= r-to-neighbor communication to set up a schedule in a distributed fashion, = or anything in-between. The goal is, I believe, to avoid for RPL to have to specify the exact slot to send = on, RPL tells the 6tsch layer to "send this packet to neighbor A".

To come back to Michael's comment, I believe that, with th= is setup, RPL actually can be using traditional metrics (ETX, bandwidth, la= tency, etc), the 6tsch layer taking care of MAC specifics.

One last thing I believe is important: what TSCH does define is= how to frequency hop. At each occurrence of a slot in the slotframe, the f= requency to communicate on is recalculated [2], and is different from the l= ast time. This means that neither the 6tsch layer nor RPL need to worry about the actual frequency to= communicate on; the schedule just looks like a grid.

I realize now this became a quite long e-mail, thanks for ready throug= h here!

Thoughts?

Thomas

[1] IEEE802.15.4e, Section 6.2.19.3

[2] IEEE802.15.4e, Section 5.1.1a

On Tue, Jan 29, 2013 at 6:05 AM, Michael Richard= son <mcr+= ietf@sandelman.ca> wrote:

>>>>> "Nick" =3D=3D Nick Moore <nick@zoic.org> writes:

Nick> * Should all this

Nick> be happening down in the MAC layer instead?

>> No.

Nick> OK, but why? What makes this an L3 (/ L2.5) th= ing?

Nick> I'm not just asking to be contrarian, if this is to = become an
Nick> IETF WG that'd be part of the charter ...

A number of reasons.
1) the bufferbloat results suggests that buffering at L2 is a bad
thing. While very resource constrained nodes are unlikel= y to have much
buffer at all, this is not true for edge/gateway nodes, and it= is
increasing untrue of various wearable and PAN-type devices suc= h as
smartphones which will get LLN interfaces.

It was particularly a surprise to many layer-3 types what the = 802.11
access point people are doing at layer 2. A lot of it in= validates
significant architectural assumptions. In many cases, th= e layer-2
optimizations are coding to the benchmarks, rather than the re= al traffic.

2) layer-3 (and higher) may need to make (re-)prioritization decisions base= d
upon what the transimission schedule is.
Consider an actuator of some kind (a device that includes a fi= re
supressor...) that, due to its critical nature has multiple la= yer-2
connections using different technologies. Maybe IPv6 ove= r CAN over
9600 baud multi-drop RS422 and 4e. Layer-3 LLNs can easi= ly build a
DAG that includes both transports, realize that as slow as the= 4e
might be, it's usually still faster for non-critical traffic t= han the CAN.

The layer-3 DAG would actually permit the the device to be add= ressed
by the application using a single IPv6 address, with the netwo= rk
figuring out how to get things there. That means less co= mplexity and
network knowledge required by the application.

There may be times during the 4e cycle when the CAN is faster = than
the wireless. There also could be congestion on the 4e w= hich would
cause the slot to be missed. If the packet remained queu= ed for the
same layer-2, it would remain for an entire cycle.

3) In the ethernet world, I point to STP and its variants as layer-2
attempts to do routing, which failed. Well, it does what= it was
advertised to do (detect and disable loops), but it turns out = that
we need much more than that.
People have gone to layer-3 solutions like OSPF instead, becau= se it
provides diagnostics, works across vendors, and it responds mu= ch
faster. And we also have TRILL.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works

_______________________________________________
6tsch mailing list
6tsch@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/6tsch

--_000_F085911F642A6847987ADA23E611780D185171E2hoshiunilux_-- From nick@zoic.org Tue Jan 29 19:29:46 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C6221F89E1 for <6tsch@ietfa.amsl.com>; Tue, 29 Jan 2013 19:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdjlob3o+pKo for <6tsch@ietfa.amsl.com>; Tue, 29 Jan 2013 19:29:46 -0800 (PST) Received: from mercury.zoic.org (mercury.zoic.org [50.19.98.71]) by ietfa.amsl.com (Postfix) with ESMTP id 136EE21F86CA for <6tsch@ietf.org>; Tue, 29 Jan 2013 19:29:46 -0800 (PST) Received: from [10.107.2.2] (cthulhu.zoic.org [180.94.115.42]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nick) by mercury.zoic.org (Postfix) with ESMTPSA id 3DB338036F for <6tsch@ietf.org>; Wed, 30 Jan 2013 03:26:59 +0000 (UTC) Message-ID: <510893A6.60506@zoic.org> Date: Wed, 30 Jan 2013 14:29:42 +1100 From: Nick Moore User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: 6tsch@ietf.org References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050108080206040108000800" Subject: Re: [6tsch] Welcome to the "6tsch" mailing list X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 03:29:46 -0000 This is a multi-part message in MIME format. --------------050108080206040108000800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 30/01/13 07:04, Thomas Watteyne wrote: > > Maybe too much room to be handled entirely by RPL. As I see it, RPL > only wants to know about some cost associated with the topology, and > uses that to compute multi-hop routes. In particular, I believe RPL is > more interested in /paths/ (the "performance" of the connection > between two neighbors), rather than the individual /links /making up > each path. In my opinion (and this is, I believe, perfectly in line > with *Xavi*'s comment), we could define a /6tsch/ layer which sits > between TSCH and RPL. The goal of this layer would be to (1) turn some > throughput requirements into /links /in the schedule and (2) collect > information and feedback /path/ statistics to RPL. [...] > To come back to *Michael*'s comment, I believe that, with this setup, > RPL actually can be using traditional metrics (ETX, bandwidth, > latency, etc), the /6tsch/ layer taking care of MAC specifics. > Yep, that makes sense! And as per Michael's comments, RPL can then handle the routing across different L2s. On 29/01/13 15:09, Michael Richardson wrote: > I agree. It's just that this is a new kind of metric: in the past we > have things like abtracted ETX, bandwidth available, power, latency, > etc... none of these things are a cyclic f(t). This new info is. Is it appropriate for the 6tsch routing metrics to change (or as you put it, to be a cyclic function) *within* the period of a slotframe? For example, if node A is trying to transmit to node D and can go via either node B or node C, then the "best route" may toggle back and forth between B and C depending on which has the next available link(s), potentially multiple times per slotframe period. Is this good behaviour? I guess in the LoWPAN world it might be. I think I'd better stop asking open-ended questions now and go read some stuff :-) -----Nick -- Nick Moore 0409 656 267 --------------050108080206040108000800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 30/01/13 07:04, Thomas Watteyne wrote:

Maybe too much room to be handled entirely by RPL. As I see it, RPL only wants to know about some cost associated with the topology, and uses that to compute multi-hop routes. In particular, I believe RPL is more interested in paths (the "performance" of the connection between two neighbors), rather than the individual links making up each path. In my opinion (and this is, I believe, perfectly in line with Xavi's comment), we could define a 6tsch layer which sits between TSCH and RPL. The goal of this layer would be to (1) turn some throughput requirements into links in the schedule and (2) collect information and feedback path statistics to RPL.

[...]

To come back to Michael's comment, I believe that, with this setup, RPL actually can be using traditional metrics (ETX, bandwidth, latency, etc), the 6tsch layer taking care of MAC specifics.

Yep, that makes sense! And as per Michael's comments, RPL can then handle the routing across different L2s.

On 29/01/13 15:09, Michael Richardson wrote:

I agree. It's just that this is a new kind of metric: in the past we have things like abtracted ETX, bandwidth available, power, latency, etc... none of these things are a cyclic f(t). This new info is.

Is it appropriate for the 6tsch routing metrics to change (or as you put it, to be a cyclic function) *within* the period of a slotframe?

For example, if node A is trying to transmit to node D and can go via either node B or node C, then the "best route" may toggle back and forth between B and C depending on which has the next available link(s), potentially multiple times per slotframe period. Is this good behaviour? I guess in the LoWPAN world it might be.

I think I'd better stop asking open-ended questions now and go read some stuff :-)

-----Nick

-- 
Nick Moore <nick@zoic.org> 0409 656 267

--------------050108080206040108000800-- From qinwang@berkeley.edu Wed Jan 30 13:38:01 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130BF21F87D5 for <6tsch@ietfa.amsl.com>; Wed, 30 Jan 2013 13:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSROINRuoaQ5 for <6tsch@ietfa.amsl.com>; Wed, 30 Jan 2013 13:38:00 -0800 (PST) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9534821F87E4 for <6tsch@ietf.org>; Wed, 30 Jan 2013 13:37:59 -0800 (PST) Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1U0fLv-0005YY-Fz; Wed, 30 Jan 2013 13:37:57 -0800 Received: from 173.49.9.236 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Wed, 30 Jan 2013 13:37:56 -0800 Message-ID: <642eb7a76ca79076e97b391cc9aeabdf.squirrel@calmail.berkeley.edu> In-Reply-To: <510893A6.60506@zoic.org> References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> <510893A6.60506@zoic.org> Date: Wed, 30 Jan 2013 13:37:56 -0800 From: qinwang@berkeley.edu To: "Nick Moore" User-Agent: SquirrelMail/1.4.21-2.berkeley MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: 6tsch@ietf.org Subject: Re: [6tsch] Welcome to the "6tsch" mailing list X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 21:38:01 -0000 Hi, As Thomas and Xavi explained, RPL is responsible for choosing a *Path*, i.e. next hop neighbor, and asking TSCH to forward packets; and TSCH provides a mechanism to use *Links* (neighbor, slot, channel, TX/RX), which is the mapping of a *Path*, to conduct forwarding. Thus, the missing piece is how to establish and maintain the *Links*. My understanding is that 6tsch will fill the gap. In addition, considering resource constraints of devices and characteristics of IoT, 6tsch should be very simple and flexible for wide range of application in terms of mobility, density, latency,and so on. In UC@Berkeley, we have designed a protocol, called uRes. The function of uRes is to establish and maintain the *Links* with neighbors. uRes is a distributed protocol, i.e. the computation and communication for link reservation just happen locally. uRes is coded in Information Elements (IEs) of IEEE802.15.4e, thus, just fits to TSCH and provides flexibility for further optimization and extension. uRes has been implemented in OpenWSN (openwsn.berkeley.edu). Regards Qin > On 30/01/13 07:04, Thomas Watteyne wrote: >> >> Maybe too much room to be handled entirely by RPL. As I see it, RPL >> only wants to know about some cost associated with the topology, and >> uses that to compute multi-hop routes. In particular, I believe RPL is >> more interested in /paths/ (the "performance" of the connection >> between two neighbors), rather than the individual /links /making up >> each path. In my opinion (and this is, I believe, perfectly in line >> with *Xavi*'s comment), we could define a /6tsch/ layer which sits >> between TSCH and RPL. The goal of this layer would be to (1) turn some >> throughput requirements into /links /in the schedule and (2) collect >> information and feedback /path/ statistics to RPL. > [...] > >> To come back to *Michael*'s comment, I believe that, with this setup, >> RPL actually can be using traditional metrics (ETX, bandwidth, >> latency, etc), the /6tsch/ layer taking care of MAC specifics. >> > > Yep, that makes sense! And as per Michael's comments, RPL can then > handle the routing across different L2s. > > > On 29/01/13 15:09, Michael Richardson wrote: >> I agree. It's just that this is a new kind of metric: in the past we >> have things like abtracted ETX, bandwidth available, power, latency, >> etc... none of these things are a cyclic f(t). This new info is. > > Is it appropriate for the 6tsch routing metrics to change (or as you put > it, to be a cyclic function) *within* the period of a slotframe? > > For example, if node A is trying to transmit to node D and can go via > either node B or node C, then the "best route" may toggle back and forth > between B and C depending on which has the next available link(s), > potentially multiple times per slotframe period. Is this good > behaviour? I guess in the LoWPAN world it might be. > > > I think I'd better stop asking open-ended questions now and go read some > stuff :-) > > -----Nick > > -- > Nick Moore 0409 656 267 > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > From twatteyne@gmail.com Wed Jan 30 16:24:01 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23FFA21F87DF for <6tsch@ietfa.amsl.com>; Wed, 30 Jan 2013 16:24:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aLTF7OE4gXU for <6tsch@ietfa.amsl.com>; Wed, 30 Jan 2013 16:24:00 -0800 (PST) Received: from mail-da0-f46.google.com (mail-da0-f46.google.com [209.85.210.46]) by ietfa.amsl.com (Postfix) with ESMTP id 623A221F87EE for <6tsch@ietf.org>; Wed, 30 Jan 2013 16:23:58 -0800 (PST) Received: by mail-da0-f46.google.com with SMTP id p5so1010936dak.33 for <6tsch@ietf.org>; Wed, 30 Jan 2013 16:23:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=GKTVm0ZTtHg2HalhnGp/ybF/vii7Sh5+dToxJO5KXyc=; b=PfCl/nDmW183GNUQXYSb8mJgc7Ax8vGLGgniBY5u9KQnRPAk//KOxT3rP6oEaAEq/0 NMcHEv6IpZmO+D5gCClKiriAB9OR4Dsf+seUVjJ0JoJ+7E3S9Z1P8CZu5Mv/hZ8kt6bx qcbBAu4IJyxPxwH3hPDncfGPS2rlSBiAwAwzMEFsr3Y6nvZW6yny19ZIlCv/Bsrpq2cT xKiR7Dvt66VZPffFYuBJuuoAwOxFVzFzPbVtx9JEZ3ANXR46X6iyJAUaschx4Jh5h2ZT 71joSAlMy9IV684eb8GRDvKnpZXFRIdG5XRRtMMKy/7L66Ey9ZuihENxOXlUAxf2pvyp serw== MIME-Version: 1.0 X-Received: by 10.66.52.79 with SMTP id r15mr15648713pao.46.1359591837944; Wed, 30 Jan 2013 16:23:57 -0800 (PST) Sender: twatteyne@gmail.com Received: by 10.66.121.33 with HTTP; Wed, 30 Jan 2013 16:23:57 -0800 (PST) In-Reply-To: <510893A6.60506@zoic.org> References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> <510893A6.60506@zoic.org> Date: Wed, 30 Jan 2013 16:23:57 -0800 X-Google-Sender-Auth: xPixct7di0yRbCSgnbfWVoQMDY8 Message-ID: From: Thomas Watteyne To: 6tsch@ietf.org Content-Type: multipart/alternative; boundary=bcaec543094c8a4a8304d48aa45f Subject: Re: [6tsch] Welcome to the "6tsch" mailing list X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 00:24:02 -0000 --bcaec543094c8a4a8304d48aa45f Content-Type: text/plain; charset=ISO-8859-1 Nick, That's quite some cross-layering! If I understand correctly, the metric could be function of how long until the next slot, i.e. if a slot to mote B is closer than mote C, then I will modify my routing metric to favor mote B. This would lead to very dynamic routing metrics, indeed. Thomas On Tue, Jan 29, 2013 at 7:29 PM, Nick Moore wrote: > On 30/01/13 07:04, Thomas Watteyne wrote: > > > Maybe too much room to be handled entirely by RPL. As I see it, RPL only > wants to know about some cost associated with the topology, and uses that > to compute multi-hop routes. In particular, I believe RPL is more > interested in *paths* (the "performance" of the connection between two > neighbors), rather than the individual *links *making up each path. In my > opinion (and this is, I believe, perfectly in line with *Xavi*'s > comment), we could define a *6tsch* layer which sits between TSCH and > RPL. The goal of this layer would be to (1) turn some throughput > requirements into *links *in the schedule and (2) collect information and > feedback *path* statistics to RPL. > > [...] > > > To come back to *Michael*'s comment, I believe that, with this setup, > RPL actually can be using traditional metrics (ETX, bandwidth, latency, > etc), the *6tsch* layer taking care of MAC specifics. > > > Yep, that makes sense! And as per Michael's comments, RPL can then handle > the routing across different L2s. > > > On 29/01/13 15:09, Michael Richardson wrote: > > I agree. It's just that this is a new kind of metric: in the past we have > things like abtracted ETX, bandwidth available, power, latency, etc... none > of these things are a cyclic f(t). This new info is. > > > Is it appropriate for the 6tsch routing metrics to change (or as you put > it, to be a cyclic function) *within* the period of a slotframe? > > For example, if node A is trying to transmit to node D and can go via > either node B or node C, then the "best route" may toggle back and forth > between B and C depending on which has the next available link(s), > potentially multiple times per slotframe period. Is this good behaviour? > I guess in the LoWPAN world it might be. > > > I think I'd better stop asking open-ended questions now and go read some > stuff :-) > > -----Nick > > -- > Nick Moore 0409 656 267 > > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > > --bcaec543094c8a4a8304d48aa45f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Nick,

That's quite some cross-layering! If I understand correctly, = the metric could be function of how long until the next slot, i.e. if a slo= t to mote B is closer than mote C, then I will modify my routing metric to = favor mote B. This would lead to very dynamic routing metrics, indeed.

Thomas

On Tue, Jan 29, 2013 a= t 7:29 PM, Nick Moore <nick@zoic.org> wrote:

=20 =20 =20
On 30/01/13 07:04, Thomas Watteyne wrote:

Maybe too much room to be handled=A0entirely=A0by RPL. As I see it, RPL only wants to know about some cost associated with the topology, and uses that to compute multi-hop routes. In particular, I believe RPL is more interested in paths (the "performance" of the connection between two neighbor= s), rather than the individual links making up each path. In my opinion (and this is, I believe, perfectly in line with Xa= vi's comment), we could define a 6tsch layer which sits between TSCH and RPL. The goal of this layer would be to (1) turn some throughput requirements into links in the schedule and (2) collect information and feedback path statistics to RPL.

[...]

To come back to=A0Michael's comment, I believe that, with this setup, RPL actually can be using traditional metrics (ETX, bandwidth, latency, etc), the 6tsch layer taking care of MAC specifics.

Yep, that makes sense!=A0 And as per Michael's comments, RPL can th= en handle the routing across different L2s.=A0

On 29/01/13 15:09, Michael Richardson wrote:
I agree. It's just that this is a new kind of metric: in the past we hav= e things like abtracted ETX, bandwidth available, power, latency, etc... none of these things are a cyclic f(t). This new info is.

Is it appropriate for the 6tsch routing metrics to change (or as you put it, to be a cyclic function) *within* the period of a slotframe?
For example, if node A is trying to transmit to node D and can go via either node B or node C, then the "best route" may toggle= back and forth between B and C depending on which has the next available link(s), potentially multiple times per slotframe period.=A0 Is this good behaviour?=A0 I guess in the LoWPAN world it might be.=A0

I think I'd better stop asking open-ended questions now and go read some stuff :-)

-----Nick

--=20 Nick Moore <nick@zoic= .org> 0409 656 267
_______________________________________________
6tsch mailing list
6tsch@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/6tsch

--bcaec543094c8a4a8304d48aa45f-- From nick@zoic.org Wed Jan 30 17:44:15 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FB921F845F for <6tsch@ietfa.amsl.com>; Wed, 30 Jan 2013 17:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icdZznZZ9l0C for <6tsch@ietfa.amsl.com>; Wed, 30 Jan 2013 17:44:14 -0800 (PST) Received: from mercury.zoic.org (mercury.zoic.org [50.19.98.71]) by ietfa.amsl.com (Postfix) with ESMTP id 05EAA21F8460 for <6tsch@ietf.org>; Wed, 30 Jan 2013 17:44:14 -0800 (PST) Received: from [10.107.1.104] (oldcthulhu.zoic.org [150.101.166.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nick) by mercury.zoic.org (Postfix) with ESMTPSA id 91EC281B78 for <6tsch@ietf.org>; Thu, 31 Jan 2013 01:41:23 +0000 (UTC) Message-ID: <5109CC68.9090506@zoic.org> Date: Thu, 31 Jan 2013 12:44:08 +1100 From: Nick Moore User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: IETF 6TSCH <6tsch@ietf.org> References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> <510893A6.60506@zoic.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [6tsch] Welcome to the "6tsch" mailing list X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 01:44:15 -0000 On 31/01/13 11:23, Thomas Watteyne wrote: > Nick, > That's quite some cross-layering! If I understand correctly, the > metric could be function of how long until the next slot, i.e. if a > slot to mote B is closer than mote C, then I will modify my routing > metric to favor mote B. This would lead to very dynamic routing > metrics, indeed. Yeah. So in this scenario the 6TSCH sub-layer is either: * Telling RPL "latency is 50ms. 40ms. 30ms. 20ms. 10ms. Boris, you missed your train, now it is 100ms. 90ms ..." * Telling RPL "latency is (t_0 - t) mod k ms, work it out for yourself." (I think this is what Michael meant by "cyclic f(t)") My concern with the former is that it seems very chatty. How often is too often? How often is often enough? My concern with the latter is that it seems rather a complicated thing to add to RPL, especially when you've got multiple hops involved in a route, with potentially different and varying slotframe periods. Any comments from anyone with RPL (etc) implementation experience? My concern overall is excessively dynamic routing, indeed :-) Is it sufficient for 6TSCH to tell RPL an *average* latency of slotframe period / 2 and leave it at that? -----Nick -- Nick Moore 0409 656 267 From twatteyne@gmail.com Wed Jan 30 17:54:53 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C576C21F872E for <6tsch@ietfa.amsl.com>; Wed, 30 Jan 2013 17:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.357 X-Spam-Level: X-Spam-Status: No, score=0.357 tagged_above=-999 required=5 tests=[AWL=-3.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXgR46USiQdG for <6tsch@ietfa.amsl.com>; Wed, 30 Jan 2013 17:54:53 -0800 (PST) Received: from mail-da0-f41.google.com (mail-da0-f41.google.com [209.85.210.41]) by ietfa.amsl.com (Postfix) with ESMTP id 69D0721F8726 for <6tsch@ietf.org>; Wed, 30 Jan 2013 17:54:52 -0800 (PST) Received: by mail-da0-f41.google.com with SMTP id e20so1052510dak.28 for <6tsch@ietf.org>; Wed, 30 Jan 2013 17:54:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=07XNyCdRbR5hLoWIIQLjUeLbPE56jrFNVtXgCeE96Xs=; b=ja/xzxUNDSw/uIz1zMUfNWcoXXB9TkZOK3fQPvIlFqVKKdsP+DEfXsEEMhY7984VFN q1W2b0dR03HKuGbXSlc/e/RnBDXax4hOUNj8pMRUG70E/dC4aDMMYzUBfHmatQCH7I96 skFkx9f6NFpkLdmlizRUEOSyGnoP1DmiXL3cC1CvT3bbKPMvBCQwBQgupUzv0uwL1aTw BIaknc7aKC9pF0dEKyXxtvvtDNohvW47SFsq9SgKEklgqfQJM/tcdFZkf2+pRUU8Bpek xyDfEig+YPmneGAQRycSclmGbZ8jnR6GvBScR6sdTXWqBBPmKXggS1+MQScHNPa+UGIX 5ABQ== MIME-Version: 1.0 X-Received: by 10.66.77.200 with SMTP id u8mr16185274paw.43.1359597291132; Wed, 30 Jan 2013 17:54:51 -0800 (PST) Sender: twatteyne@gmail.com Received: by 10.66.121.33 with HTTP; Wed, 30 Jan 2013 17:54:50 -0800 (PST) In-Reply-To: <5109CC68.9090506@zoic.org> References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> <510893A6.60506@zoic.org> <5109CC68.9090506@zoic.org> Date: Wed, 30 Jan 2013 17:54:50 -0800 X-Google-Sender-Auth: cC9RPgra6g_pIvB5gamYQ6Flcgo Message-ID: From: Thomas Watteyne To: 6tsch@ietf.org Content-Type: multipart/alternative; boundary=f46d042e007993563304d48be95b Subject: Re: [6tsch] Welcome to the "6tsch" mailing list X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 01:54:53 -0000 --f46d042e007993563304d48be95b Content-Type: text/plain; charset=ISO-8859-1 Nick, I would argue that 6tsch should deal with MAC layer specificities and present an aggregate view to RPL. In TSCH, we're dealing with multiple links to the same neighbor, which might be confusing for the routing layer to deal with. On top of that, 6tsch might want to switch links around, in which case maybe the metric really doesn't change from a routing point of view. I believe that 6tsch can express both bandwidth and latency by looking at the schedule and the per-link statistics. That is, bandwidth would be something like the sum of links per slotframe, weighted by the ETX on each link. This would represent "how many packet can I get to this neighbor, per unit time", taking into account that there might be multiple links, and lossy links. Taking it one step further, 6tsch could be instructed to maintain 6pkt/s to neighbor A. If on average ETX to A is 50%, 6tsch will put in 12 link/s. If something happens and the ETX now goes to 75%, 6tsch could remove 2 links. All of that without requiring any intervention from RPL, and without impact of the routing. Thomas On Wed, Jan 30, 2013 at 5:44 PM, Nick Moore wrote: > On 31/01/13 11:23, Thomas Watteyne wrote: > >> Nick, >> That's quite some cross-layering! If I understand correctly, the metric >> could be function of how long until the next slot, i.e. if a slot to mote B >> is closer than mote C, then I will modify my routing metric to favor mote >> B. This would lead to very dynamic routing metrics, indeed. >> > > Yeah. So in this scenario the 6TSCH sub-layer is either: > > * Telling RPL "latency is 50ms. 40ms. 30ms. 20ms. 10ms. Boris, you > missed your train, now it is 100ms. 90ms ..." > * Telling RPL "latency is (t_0 - t) mod k ms, work it out for yourself." > (I think this is what Michael meant by "cyclic f(t)") > > My concern with the former is that it seems very chatty. How often is too > often? How often is often enough? > > My concern with the latter is that it seems rather a complicated thing to > add to RPL, especially when you've got multiple hops involved in a route, > with potentially different and varying slotframe periods. Any comments > from anyone with RPL (etc) implementation experience? > > My concern overall is excessively dynamic routing, indeed :-) Is it > sufficient for 6TSCH to tell RPL an *average* latency of slotframe period / > 2 and leave it at that? > > > -----Nick > -- > Nick Moore 0409 656 267 > ______________________________**_________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/**listinfo/6tsch > --f46d042e007993563304d48be95b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Nick,

I would argue that 6tsch should deal with MAC laye= r=A0specificities=A0and present an aggregate view to RPL. In TSCH, we'r= e dealing with multiple links to the same neighbor, which might be confusin= g for the routing layer to deal with. On top of that, 6tsch might want to s= witch links around, in which case maybe the metric really doesn't chang= e from a routing point of view.

I believe that 6tsch can express both bandwidth and lat= ency by looking at the schedule and the per-link statistics. That is, bandw= idth would be something like the sum of links per slotframe, weighted by th= e ETX on each link. This would represent "how many packet can I get to= this neighbor, per unit time", taking into account that there might b= e multiple links, and lossy links.

Taking it one step further, 6tsch could be instructed t= o maintain 6pkt/s to neighbor A. If on average ETX to A is 50%, 6tsch will = put in 12 link/s. If something happens and the ETX now goes to 75%, 6tsch c= ould remove 2 links. All of that without requiring any intervention from RP= L, and without impact of the routing.

Thomas

On Wed, Jan 30, 2013 at 5:44 P= M, Nick Moore <nick@zoic.org> wrote:

On 31/01/13 11:23, Thomas Watteyne wrote:

Nick,
That's quite some cross-layering! If I understand correctly, the metric= could be function of how long until the next slot, i.e. if a slot to mote = B is closer than mote C, then I will modify my routing metric to favor mote= B. This would lead to very dynamic routing metrics, indeed.

Yeah. =A0So in this scenario the 6TSCH sub-layer is either:

* Telling RPL "latency is 50ms. =A040ms. =A030ms. =A020ms. =A010ms. = =A0Boris, you missed your train, now it is 100ms. =A090ms ..."
* Telling RPL "latency is (t_0 - t) mod k ms, work it out for yourself= ." (I think this is what Michael meant by "cyclic f(t)")

My concern with the former is that it seems very chatty. =A0How often is to= o often? =A0How often is often enough?

My concern with the latter is that it seems rather a complicated thing to a= dd to RPL, especially when you've got multiple hops involved in a route= , with potentially different and varying slotframe periods. =A0Any comments= from anyone with RPL (etc) implementation experience?

My concern overall is excessively dynamic routing, indeed :-) =A0Is it suff= icient for 6TSCH to tell RPL an *average* latency of slotframe period / 2 a= nd leave it at that?

-----Nick
--
Nick Moore <nick@zoic= .org> 0409 656 267
_______________________________________________
6tsch mailing list
6tsch@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/6tsch

--f46d042e007993563304d48be95b-- From xvilajosana@eecs.berkeley.edu Wed Jan 30 17:59:03 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF2721F8757 for <6tsch@ietfa.amsl.com>; Wed, 30 Jan 2013 17:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mvQbWryeF1z for <6tsch@ietfa.amsl.com>; Wed, 30 Jan 2013 17:59:02 -0800 (PST) Received: from cm02fe.IST.Berkeley.EDU (cm02fe.IST.Berkeley.EDU [169.229.218.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF5921F845F for <6tsch@ietf.org>; Wed, 30 Jan 2013 17:59:02 -0800 (PST) Received: from dhcp-33-135.eecs.berkeley.edu ([128.32.33.135]) by cm02fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:xvilajosana@eecs.berkeley.edu) (envelope-from ) id 1U0jQa-0000lt-7P for 6tsch@ietf.org; Wed, 30 Jan 2013 17:59:01 -0800 Message-ID: <5109CFE4.30501@eecs.berkeley.edu> Date: Wed, 30 Jan 2013 17:59:00 -0800 From: Xavier Vilajosana User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: 6tsch@ietf.org References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> <510893A6.60506@zoic.org> <5109CC68.9090506@zoic.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020705030607060101050003" Subject: Re: [6tsch] Welcome to the "6tsch" mailing list X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 01:59:03 -0000 This is a multi-part message in MIME format. --------------020705030607060101050003 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Nick, I see it like Thomas, for example the 6tsch sublayer tells us: the average latency for that link is 40ms the latest set of packets (x) have traveled in 32ms the max latency ever is 66ms the min latency ever is 28ms etc... whit that RPL can make very clever decisions on how to build a topology. X On 30/01/13 17:54, Thomas Watteyne wrote: > Nick, > > I would argue that 6tsch should deal with MAC layer specificities and > present an aggregate view to RPL. In TSCH, we're dealing with multiple > links to the same neighbor, which might be confusing for the routing > layer to deal with. On top of that, 6tsch might want to switch links > around, in which case maybe the metric really doesn't change from a > routing point of view. > > I believe that 6tsch can express both bandwidth and latency by looking > at the schedule and the per-link statistics. That is, bandwidth would > be something like the sum of links per slotframe, weighted by the ETX > on each link. This would represent "how many packet can I get to this > neighbor, per unit time", taking into account that there might be > multiple links, and lossy links. > > Taking it one step further, 6tsch could be instructed to maintain > 6pkt/s to neighbor A. If on average ETX to A is 50%, 6tsch will put in > 12 link/s. If something happens and the ETX now goes to 75%, 6tsch > could remove 2 links. All of that without requiring any intervention > from RPL, and without impact of the routing. > > Thomas > > On Wed, Jan 30, 2013 at 5:44 PM, Nick Moore > wrote: > > On 31/01/13 11:23, Thomas Watteyne wrote: > > Nick, > That's quite some cross-layering! If I understand correctly, > the metric could be function of how long until the next slot, > i.e. if a slot to mote B is closer than mote C, then I will > modify my routing metric to favor mote B. This would lead to > very dynamic routing metrics, indeed. > > > Yeah. So in this scenario the 6TSCH sub-layer is either: > > * Telling RPL "latency is 50ms. 40ms. 30ms. 20ms. 10ms. > Boris, you missed your train, now it is 100ms. 90ms ..." > * Telling RPL "latency is (t_0 - t) mod k ms, work it out for > yourself." (I think this is what Michael meant by "cyclic f(t)") > > My concern with the former is that it seems very chatty. How > often is too often? How often is often enough? > > My concern with the latter is that it seems rather a complicated > thing to add to RPL, especially when you've got multiple hops > involved in a route, with potentially different and varying > slotframe periods. Any comments from anyone with RPL (etc) > implementation experience? > > My concern overall is excessively dynamic routing, indeed :-) Is > it sufficient for 6TSCH to tell RPL an *average* latency of > slotframe period / 2 and leave it at that? > > > -----Nick > -- > Nick Moore > 0409 656 267 > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > > > > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch --------------020705030607060101050003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Hi Nick,

I see it like Thomas, for example the 6tsch sublayer tells us:

the average latency for that link is 40ms
the latest set of packets (x) have traveled in 32ms
the max latency ever is 66ms
the min latency ever is 28ms
etc...

whit that RPL can make very clever decisions on how to build a topology.

X

On 30/01/13 17:54, Thomas Watteyne wrote:

Nick,

I would argue that 6tsch should deal with MAC layer specificities and present an aggregate view to RPL. In TSCH, we're dealing with multiple links to the same neighbor, which might be confusing for the routing layer to deal with. On top of that, 6tsch might want to switch links around, in which case maybe the metric really doesn't change from a routing point of view.

I believe that 6tsch can express both bandwidth and latency by looking at the schedule and the per-link statistics. That is, bandwidth would be something like the sum of links per slotframe, weighted by the ETX on each link. This would represent "how many packet can I get to this neighbor, per unit time", taking into account that there might be multiple links, and lossy links.

Taking it one step further, 6tsch could be instructed to maintain 6pkt/s to neighbor A. If on average ETX to A is 50%, 6tsch will put in 12 link/s. If something happens and the ETX now goes to 75%, 6tsch could remove 2 links. All of that without requiring any intervention from RPL, and without impact of the routing.

Thomas

On Wed, Jan 30, 2013 at 5:44 PM, Nick Moore <nick@zoic.org> wrote:

On 31/01/13 11:23, Thomas Watteyne wrote:

Nick,
That's quite some cross-layering! If I understand correctly, the metric could be function of how long until the next slot, i.e. if a slot to mote B is closer than mote C, then I will modify my routing metric to favor mote B. This would lead to very dynamic routing metrics, indeed.

Yeah. So in this scenario the 6TSCH sub-layer is either:

* Telling RPL "latency is 50ms. 40ms. 30ms. 20ms. 10ms. Boris, you missed your train, now it is 100ms. 90ms ..."
* Telling RPL "latency is (t_0 - t) mod k ms, work it out for yourself." (I think this is what Michael meant by "cyclic f(t)")

My concern with the former is that it seems very chatty. How often is too often? How often is often enough?

My concern with the latter is that it seems rather a complicated thing to add to RPL, especially when you've got multiple hops involved in a route, with potentially different and varying slotframe periods. Any comments from anyone with RPL (etc) implementation experience?

My concern overall is excessively dynamic routing, indeed :-) Is it sufficient for 6TSCH to tell RPL an *average* latency of slotframe period / 2 and leave it at that?

-----Nick
--
Nick Moore <nick@zoic.org> 0409 656 267
_______________________________________________
6tsch mailing list
6tsch@ietf.org
https://www.ietf.org/mailman/listinfo/6tsch
_______________________________________________
6tsch mailing list
6tsch@ietf.org
https://www.ietf.org/mailman/listinfo/6tsch

--------------020705030607060101050003-- From nick@zoic.org Wed Jan 30 22:26:46 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07D121F8503 for <6tsch@ietfa.amsl.com>; Wed, 30 Jan 2013 22:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.705 X-Spam-Level: X-Spam-Status: No, score=0.705 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTfJZq8covsp for <6tsch@ietfa.amsl.com>; Wed, 30 Jan 2013 22:26:46 -0800 (PST) Received: from mercury.zoic.org (mercury.zoic.org [50.19.98.71]) by ietfa.amsl.com (Postfix) with ESMTP id 3E54E21F8496 for <6tsch@ietf.org>; Wed, 30 Jan 2013 22:26:46 -0800 (PST) Received: from [10.223.201.192] (unknown [1.152.64.241]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nick) by mercury.zoic.org (Postfix) with ESMTPSA id 04E3A81BA2 for <6tsch@ietf.org>; Thu, 31 Jan 2013 06:23:56 +0000 (UTC) References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> <510893A6.60506@zoic.org> <5109CC68.9090506@zoic.org> From: Nick Moore Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (10A523) In-Reply-To: Message-Id: <53F3B30A-12C6-4D0F-8C47-D6C5BA37DB3A@zoic.org> Date: Thu, 31 Jan 2013 17:26:42 +1100 To: IETF 6TSCH <6tsch@ietf.org> Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: [6tsch] Welcome to the "6tsch" mailing list X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 06:26:46 -0000 Thomas Watteyne wrote: > I would argue that 6tsch should deal with MAC layer specificities and pres= ent an aggregate view to RPL. I think that makes sense as an initial goal at least. If some brave soul manages to work out a more sophisticated version that all= ows for the cyclic nature of TSCH latency they can always call it 6TSCHbis (= pronounce *that*!) --=20 Nick Moore (+61) 409 656 267= From mischa.dohler@cttc.es Thu Jan 31 06:42:55 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB0B21F8583 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 06:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.684 X-Spam-Level: X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTZ4WvxZ1ce7 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 06:42:55 -0800 (PST) Received: from marchena.puc.rediris.es (marchena.puc.rediris.es [IPv6:2001:720:418:ca00::4]) by ietfa.amsl.com (Postfix) with ESMTP id D671621F857C for <6tsch@ietf.org>; Thu, 31 Jan 2013 06:42:54 -0800 (PST) Received: from [84.88.62.208] (helo=leo) by marchena.puc.rediris.es with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1U0vLo-00052c-OK for 6tsch@ietf.org; Thu, 31 Jan 2013 15:42:52 +0100 Received: from [84.88.61.89] (pcmdohler.cttc.es [84.88.61.89]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by leo (Postfix) with ESMTPSA id 410121FC31 for <6tsch@ietf.org>; Thu, 31 Jan 2013 15:42:48 +0100 (CET) X-Envelope-From: mischa.dohler@cttc.es Message-ID: <510A82E4.6010906@cttc.es> Date: Thu, 31 Jan 2013 15:42:44 +0100 From: Mischa Dohler User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: 6tsch@ietf.org References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> <510893A6.60506@zoic.org> <642eb7a76ca79076e97b391cc9aeabdf.squirrel@calmail.berkeley.edu> In-Reply-To: <642eb7a76ca79076e97b391cc9aeabdf.squirrel@calmail.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SPF-Received: 4 X-Spamina-Bogosity: Ham Subject: Re: [6tsch] Welcome to the "6tsch" mailing list X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 14:42:56 -0000 Qin, I like this and would like to hear more about it. Do you have some papers/results? You can turn the problem as you want* but if you really want a multihop system to scale (beyond some 500-1000 nodes), you need a distributed system and some machine learning** on top. This is because in static link topologies, the aggregate set of locally-chosen links will converge eventually to the optimal path; there will be no routing solution for ergodic (completely dynamic) link topologies beyond DTN approaches (just take it); and non-ergodic (but also non-static) link topologies, where links are occasionally in outage, can only be handled in a distributed fashion. So I am all in for seeing how you could make .15.4e & RPL work closely together in a distributed fashion. Thanks, Mischa. * The adhoc community is very good at this: they have published zillions of papers, proposed millions of protocols, have loads of RFCs but no viable product after 50 years of work - mobility/dynamics are very fundamental problems which you can only solve meaningfully with one-hop star-topology technology ... wait ... this is cellular. ** We recently standardized some machine learning approaches in a broadband standard; setting was different but problem the same. __________________________________ Mischa Dohler Director of Research, CTTC Distinguished Lecturer, IEEE Editor-in-Chief, ETT BoD, Worldsensing Mob: +34 679 094 007 Tel: +34 936 452 909 Fax: +34 936 452 901 www.cttc.es/home/mdohler __________________________________ On 30/01/2013 22:37, qinwang@berkeley.edu wrote: > Hi, > > As Thomas and Xavi explained, RPL is responsible for choosing a *Path*, > i.e. next hop neighbor, and asking TSCH to forward packets; and TSCH > provides a mechanism to use *Links* (neighbor, slot, channel, TX/RX), > which is the mapping of a *Path*, to conduct forwarding. Thus, the missing > piece is how to establish and maintain the *Links*. My understanding is > that 6tsch will fill the gap. In addition, considering resource > constraints of devices and characteristics of IoT, 6tsch should be very > simple and flexible for wide range of application in terms of mobility, > density, latency,and so on. > > In UC@Berkeley, we have designed a protocol, called uRes. The function of > uRes is to establish and maintain the *Links* with neighbors. uRes is a > distributed protocol, i.e. the computation and communication for link > reservation just happen locally. uRes is coded in Information Elements > (IEs) of IEEE802.15.4e, thus, just fits to TSCH and provides flexibility > for further optimization and extension. uRes has been implemented in > OpenWSN (openwsn.berkeley.edu). > > > Regards > Qin > > > > >> On 30/01/13 07:04, Thomas Watteyne wrote: >>> Maybe too much room to be handled entirely by RPL. As I see it, RPL >>> only wants to know about some cost associated with the topology, and >>> uses that to compute multi-hop routes. In particular, I believe RPL is >>> more interested in /paths/ (the "performance" of the connection >>> between two neighbors), rather than the individual /links /making up >>> each path. In my opinion (and this is, I believe, perfectly in line >>> with *Xavi*'s comment), we could define a /6tsch/ layer which sits >>> between TSCH and RPL. The goal of this layer would be to (1) turn some >>> throughput requirements into /links /in the schedule and (2) collect >>> information and feedback /path/ statistics to RPL. >> [...] >> >>> To come back to *Michael*'s comment, I believe that, with this setup, >>> RPL actually can be using traditional metrics (ETX, bandwidth, >>> latency, etc), the /6tsch/ layer taking care of MAC specifics. >>> >> Yep, that makes sense! And as per Michael's comments, RPL can then >> handle the routing across different L2s. >> >> >> On 29/01/13 15:09, Michael Richardson wrote: >>> I agree. It's just that this is a new kind of metric: in the past we >>> have things like abtracted ETX, bandwidth available, power, latency, >>> etc... none of these things are a cyclic f(t). This new info is. >> Is it appropriate for the 6tsch routing metrics to change (or as you put >> it, to be a cyclic function) *within* the period of a slotframe? >> >> For example, if node A is trying to transmit to node D and can go via >> either node B or node C, then the "best route" may toggle back and forth >> between B and C depending on which has the next available link(s), >> potentially multiple times per slotframe period. Is this good >> behaviour? I guess in the LoWPAN world it might be. >> >> >> I think I'd better stop asking open-ended questions now and go read some >> stuff :-) >> >> -----Nick >> >> -- >> Nick Moore 0409 656 267 >> >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch >> > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch From mcr@sandelman.ca Thu Jan 31 08:33:54 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E09A21F84B6 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 08:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Psc5JH4BPwz for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 08:33:53 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 5E07421F8473 for <6tsch@ietf.org>; Thu, 31 Jan 2013 08:33:53 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A5D8320168; Thu, 31 Jan 2013 11:39:27 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id CC8F663765; Thu, 31 Jan 2013 11:32:53 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BC6C4636B6; Thu, 31 Jan 2013 11:32:53 -0500 (EST) From: Michael Richardson To: Nick Moore In-Reply-To: <510893A6.60506@zoic.org> References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> <510893A6.60506@zoic.org> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: 6tsch@ietf.org Subject: Re: [6tsch] Welcome to the "6tsch" mailing list X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 16:33:54 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Nick" =3D=3D Nick Moore writes: Nick> On 29/01/13 15:09, Michael Richardson wrote: >> I agree. It's just that this is a new kind of metric: in the past >> we have things like abtracted ETX, bandwidth available, power, >> latency, etc... none of these things are a cyclic f(t). This new >> info is. Nick> Is it appropriate for the 6tsch routing metrics to change (or Nick> as you put it, to be a cyclic function) *within* the period of Nick> a slotframe? Yes/No. What I think should happen is that RPL be presented with essentially two (possibly more! TBD) links. It will create two DODAGs, one for the top of the cycle, and one for the bottom of the cycle. The routing system will then essentially need two routing tables: one for each side of the cycle.=20=20 Nick> For example, if node A is trying to transmit to node D and can Nick> go via either node B or node C, then the "best route" may Nick> toggle back and forth between B and C depending on which has Nick> the next available link(s), potentially multiple times per Nick> slotframe period. Is this good behaviour? I guess in the Nick> LoWPAN world it might be. I think it would be acceptable behaviour. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUQqctYqHRg3pndX9AQKIQgP/RR+pWNo9B0oGkENmJ8IHUk4fOnPVcRe0 F9hsGQzCy5jioS+f0lNnRG/jt9b8Q+whT52Hs/rcOFHgAE1CaeO/flA9BiLhN2+1 N3fIoDAGU79BqKvVNwZ8dFfGiZ/Ert1SILBlZdoZFrl80xr0XDS+LTZuwzRlmJWQ 1XbiyxYjqbk= =YzKo -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Thu Jan 31 08:36:03 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B3021F8599 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 08:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEdOr79CSdU9 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 08:36:03 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id EA4F821F84B6 for <6tsch@ietf.org>; Thu, 31 Jan 2013 08:36:02 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 20ECE20168 for <6tsch@ietf.org>; Thu, 31 Jan 2013 11:41:39 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 37D1E63765; Thu, 31 Jan 2013 11:35:05 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2897F636B6 for <6tsch@ietf.org>; Thu, 31 Jan 2013 11:35:05 -0500 (EST) From: Michael Richardson To: 6tsch@ietf.org In-Reply-To: References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> <510893A6.60506@zoic.org> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [6tsch] Welcome to the "6tsch" mailing list X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 16:36:03 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Thomas" =3D=3D Thomas Watteyne writes: Thomas> Nick, That's quite some cross-layering! If I understand Thomas> correctly, the metric could be function of how long until Thomas> the next slot, i.e. if a slot to mote B is closer than mote Thomas> C, then I will modify my routing metric to favor mote Thomas> B. This would lead to very dynamic routing metrics, indeed. These routing metrics do not change dynamically, they change cyclically. That's important, because it means that trickle can still be used to efficiently flood the routing metrics. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUQqdOYqHRg3pndX9AQJTiwQAoNFYDl6tFSkBA2jG2wfQ+BtWBdyxHgOi O/QMyUAIAYNl3UCH4xsSkWs6Ai2xtnwoaoIpmmeYv+V6sgLqPMN7d6WnWv13SDxw Q4YjlZ5M4BUwkxiP125JrOgs5xn/C9q3yH26lKEO5Cf0AxFRBznM/YjnqJrKkT+i R7tFyd0G07g= =rMEB -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Thu Jan 31 08:40:45 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F0821F841A for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 08:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOmw6qswkMd5 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 08:40:44 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id CA29F21F8414 for <6tsch@ietf.org>; Thu, 31 Jan 2013 08:40:41 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0547320168 for <6tsch@ietf.org>; Thu, 31 Jan 2013 11:46:18 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id D611763765; Thu, 31 Jan 2013 11:39:42 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BEF1C636B6 for <6tsch@ietf.org>; Thu, 31 Jan 2013 11:39:42 -0500 (EST) From: Michael Richardson To: IETF 6TSCH <6tsch@ietf.org> In-Reply-To: <5109CC68.9090506@zoic.org> References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> <510893A6.60506@zoic.org> <5109CC68.9090506@zoic.org> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [6tsch] Welcome to the "6tsch" mailing list X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 16:40:45 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Nick" =3D=3D Nick Moore writes: Nick> Yeah. So in this scenario the 6TSCH sub-layer is either: Nick> Telling RPL "latency is (t_0 - t) mod k ms, work it out for Nick> yourself." (I think this is what Michael meant by "cyclic Nick> f(t)") yes. Nick> My concern with the former is that it seems very chatty. How Nick> often is too often? How often is often enough? Nick> My concern with the latter is that it seems rather a Nick> complicated thing to add to RPL, especially when you've got Nick> multiple hops involved in a route, with potentially different Nick> and varying slotframe periods. Any comments from anyone with Nick> RPL (etc) implementation experience? (yes, I'm an implementer, but my implementation is not well tested...) What I hope will happen is that the cyclic f(t) in the metrics will have a horizon of some kind. That is, some number of hops from a given node Q, it won't matter what happens above Q for nodes below Q. (a diagram would help here) Otherwise, we might have a situation where the number of routes across a network might be 2^n, with each layer contributing another DODAG to calculate.=20 =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUQqeToqHRg3pndX9AQJSQgP/d0Pzzp1+AmINkCJUpQEDk+9vxr/1PnXd UsE7iyZmAmadTigb0jrw4EwhbAxDDN1HX7qqINTG3aq5XudcV1nhsjTPPQjA3lo5 lImW+VGABpG3Yrl1DGhY2kBZJ/3dttxKli5RBqKCfTKiXtGoyjgfL8picNyOcYKv qZCdYV+GLI8= =O/r/ -----END PGP SIGNATURE----- --=-=-=-- From d.sturek@att.net Thu Jan 31 08:50:34 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC7B21F8546 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 08:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDAZAwYk-V0B for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 08:50:30 -0800 (PST) Received: from nm20-vm0.access.bullet.mail.mud.yahoo.com (nm20-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.29]) by ietfa.amsl.com (Postfix) with ESMTP id 6869F21F84D7 for <6tsch@ietf.org>; Thu, 31 Jan 2013 08:50:30 -0800 (PST) Received: from [66.94.237.194] by nm20.access.bullet.mail.mud.yahoo.com with NNFMP; 31 Jan 2013 16:50:30 -0000 Received: from [98.138.84.183] by tm5.access.bullet.mail.mud.yahoo.com with NNFMP; 31 Jan 2013 16:50:30 -0000 Received: from [127.0.0.1] by smtp105.sbc.mail.ne1.yahoo.com with NNFMP; 31 Jan 2013 16:50:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1359651029; bh=T/w8EskjCE9SGDwUTRDvgowTsQ2Bc/6Mc8a+FM32O5Y=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=tzXX+9vAlntS0IbFqRklGe+0wdZ/zaH0bgHqjxPththdmfwEdEf9uzVXs54AG+6rCc/vKE1QXUGW+9l9e66osiYZMSRffWiFFJ3zMnWlpljhaQwxpaT89CaWTvF88bPB9/p7nfXwc4WuYzpuQwrfXOLGwTtjLNM90PDGaU/TpA0= X-Yahoo-Newman-Id: 976840.19355.bm@smtp105.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: JOv7m9QVM1ndwK7e0i3nmwo2OmxYVLsp4Y3fDIyXQtLy7qj GGXfyEo1dfW4PMOPpF3AuTAgVooTvPwKU3VXSU5_gKWbC6EABBgo6MNx26lw 3hZGz6GApuTcEARMc_MvTCID89xCLUjbZwjNb_oIN0aed7Qjgp2IRc3yAyw8 ySbTvIzkqWXQioj5qCU3Y1PkVCHq7vFI7R9JDgApEB_E7QfPBMm0N2phl3zU rhq3C3jabAnhfvtGx0CX2jWYVJfg_uEJM.MmjwozpSw9KNgI2cW1ZPnvxLtA aKFjjDtL2LavCWhflF3n3eXTsTnmQsS7di65wJnvavk2MO_CmK1P7hTSkpiA ZwwJyegu2rbnrdeouGDepcq7zGzYWoX6ZQs3PnmSp4foEWcRl3PGp.wUULGF ScYGIuxh_.ZsF5ArkzZGq0BLhJUtz.V2LSDfmSzZU5FxOO7FcMgDaSX4tVcK npMzbMCnSIhUj2QY- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.199] (d.sturek@69.108.51.4 with login) by smtp105.sbc.mail.ne1.yahoo.com with SMTP; 31 Jan 2013 16:50:29 +0000 UTC User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Thu, 31 Jan 2013 08:50:26 -0800 From: Don Sturek To: IETF 6TSCH <6tsch@ietf.org> Message-ID: Thread-Topic: Suggestion In-Reply-To: <19160.1359650382@sandelman.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [6tsch] Suggestion X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 16:50:34 -0000 Just a suggestion from someone monitoring the reflector..... It would be hugely useful if the topic of the all various threads did not all read: " re: Welcome to the "6tsch" mailing list". Some of the embedded topics in these e-mails are interesting while others I might pass on if I knew the actual contents..... Thanks! Don From abdussalambaryun@gmail.com Thu Jan 31 08:52:52 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FCE21F8433 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 08:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8to230NtMs5 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 08:52:51 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id BC92421F871F for <6tsch@ietf.org>; Thu, 31 Jan 2013 08:52:49 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id ds1so587034wgb.4 for <6tsch@ietf.org>; Thu, 31 Jan 2013 08:52:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=XUkj6xc0mlK3Wsq5/LMsurY2z6+QFwj/JsKOfqiXuYo=; b=inZSovPYkT4AjeIbberVt2heeBsEK4ywsygrSDrmz6Ikl1GCSm4QAEe9kh12f5gLic q2OapUFaI4qUxYpxpD+ph1irqQbz+LG6Va+5rOAZ818qtLawUM+RQBiPc8bJ/6WFDkBf x9D0XbxqMQIRiFZry4tyZCDOstBAqj3VxHq1pxM1LKlTH0tU+48kABnbb4kOC0b9eFXF EiT7CHnNTiqSGGsNvuagCAVAZbMbTpPXKezhFtqJSYuH7XoflcXY7kCb9561gBPSqc1r AyuSpEHTKWV/5aVxWXC3c8Z/OupRnWgjPT0xG64njKQ6SSAatibRRozui2U6BetLpaZP p3Ww== MIME-Version: 1.0 X-Received: by 10.180.86.36 with SMTP id m4mr16477740wiz.5.1359651167317; Thu, 31 Jan 2013 08:52:47 -0800 (PST) Received: by 10.180.14.33 with HTTP; Thu, 31 Jan 2013 08:52:47 -0800 (PST) In-Reply-To: <510893A6.60506@zoic.org> References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> <510893A6.60506@zoic.org> Date: Thu, 31 Jan 2013 17:52:47 +0100 Message-ID: From: Abdussalam Baryun To: 6tsch@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [6tsch] Welcome to the "6tsch" mailing list X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 16:52:52 -0000 Could some one refer me to an initial draft submitted if available for this group? to make group ideas and basis for discussions, I usually prefer joining discussions that at least have an I-D on table :) Thanking you. AB From twatteyne@gmail.com Thu Jan 31 09:24:50 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5805221F84F8 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 09:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsGp7B8CEIBM for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 09:24:49 -0800 (PST) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id D7CBD21F8414 for <6tsch@ietf.org>; Thu, 31 Jan 2013 09:24:49 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id kp14so1823260pab.33 for <6tsch@ietf.org>; Thu, 31 Jan 2013 09:24:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IErZ/mXECE8D6/ige9jHLIkHyMlImJQO1nJ2vK5FuUs=; b=nbmCVsehqrKUwu3O6YdWHT6TqqRHUJ9Fqtxqnyp5EIp9R7IbIQPXOq6CV+C4PBaZbZ DhqBypcu9aEpHmZqfTymyEMPpUTa8/Ui7vx+FzaR6rbukiutssSdUS52iJ+t3ioacgYJ 9FMDTK1YlarT/LdXErIIAF8EMotnNsrTZ1sVoVvYaEd8zmMbCgzXJJC9ditEbFospWYW 40d5fmsnSJ2JmaPUBwPGiqwFMo1Ks/8nYX4rt88fznJxmmyJECTwgIHet8/gG7oB002E cMjXEkuwUZ5HqL+lOcoCmrfEcZ7raQ9YL+07i3bCvGwc9LXXARYTYF5gEjQCgzY7Sju2 iREQ== MIME-Version: 1.0 X-Received: by 10.66.52.79 with SMTP id r15mr22442476pao.46.1359653089605; Thu, 31 Jan 2013 09:24:49 -0800 (PST) Sender: twatteyne@gmail.com Received: by 10.66.121.33 with HTTP; Thu, 31 Jan 2013 09:24:49 -0800 (PST) In-Reply-To: References: <19160.1359650382@sandelman.ca> Date: Thu, 31 Jan 2013 09:24:49 -0800 X-Google-Sender-Auth: hkX3nqth1kJL9W-bauUNAytWZLo Message-ID: From: Thomas Watteyne To: Don Sturek Content-Type: multipart/alternative; boundary=bcaec543094c6c773b04d498e776 Cc: IETF 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] Suggestion X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 17:24:50 -0000 --bcaec543094c6c773b04d498e776 Content-Type: text/plain; charset=ISO-8859-1 Don, Thanks for the suggestion. We got a bit carried away :) Thomas On Thu, Jan 31, 2013 at 8:50 AM, Don Sturek wrote: > > > Just a suggestion from someone monitoring the reflector..... > > It would be hugely useful if the topic of the all various threads did not > all read: " re: Welcome to the "6tsch" mailing list". Some of the > embedded topics in these e-mails are interesting while others I might pass > on if I knew the actual contents..... > > Thanks! > > Don > > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > --bcaec543094c6c773b04d498e776 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Don,

Thanks for the suggestion. We got a bit carried awa= y :)

Thomas

On T= hu, Jan 31, 2013 at 8:50 AM, Don Sturek <d.sturek@att.net> wr= ote:

Just a suggestion from someone monitoring the reflector.....

It would be hugely useful if the topic of the all various threads did not all read: =A0" re: =A0Welcome to the "6tsch" mailing list&qu= ot;. =A0 Some of the
embedded topics in these e-mails are interesting while others I might pass<= br> on if I knew the actual contents.....

Thanks!

Don

_______________________________________________
6tsch mailing list
6tsch@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/6tsch

--bcaec543094c6c773b04d498e776-- From twatteyne@gmail.com Thu Jan 31 09:33:45 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0797821F861A for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 09:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Iy+t7Or8E9S for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 09:33:43 -0800 (PST) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by ietfa.amsl.com (Postfix) with ESMTP id 72DA021F85DA for <6tsch@ietf.org>; Thu, 31 Jan 2013 09:33:43 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id hz10so1827906pad.37 for <6tsch@ietf.org>; Thu, 31 Jan 2013 09:33:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=XkmMWjUOtkxFEhO2PsF5fwBj1gJzjGAv9+RA8jq/NAs=; b=LWL6LsVJ9U0ubDzkKO65B5IV4zjvU6nDBqCS+zN/aP3VvJl39AHCaUQgkqpv2lJ2Vx Ri8hZGJD5osMvCRfaP4Vo3qEQXL4IK8D16Zryi0zjKeTTOV98aWosaj9U4RrQ7Cc8EpY AdyzWsUER62n1eMV/9Hkl2HEj6gI7XZwlqXn9bhAvFbRoTcutjSMsu0/03J2JoL43Qte E0zDRZiDe2hjlUgyU+KYAiQJRSB1Rjvqi6gkghenXN5KOqdLo+j1xAOjCAsQsSZJeXZg nQBxy1x+ft34a4npArMkFjn7vXWshk0qMqPHckUYtA7xRkLoBoX6AJUBd0QGB9HN/Uxr Qd7Q== MIME-Version: 1.0 X-Received: by 10.66.77.200 with SMTP id u8mr22448933paw.43.1359653622897; Thu, 31 Jan 2013 09:33:42 -0800 (PST) Sender: twatteyne@gmail.com Received: by 10.66.121.33 with HTTP; Thu, 31 Jan 2013 09:33:42 -0800 (PST) Date: Thu, 31 Jan 2013 09:33:42 -0800 X-Google-Sender-Auth: bWV9r0QK-Vwka_RTh9i1UC3wNdI Message-ID: From: Thomas Watteyne To: "6tsch@ietf.org" <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=f46d042e007935dcea04d4990771 Subject: [6tsch] TASA: centralized scheduling X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 17:33:45 -0000 --f46d042e007935dcea04d4990771 Content-Type: text/plain; charset=ISO-8859-1 Maria Rita, Thanks for introducing TASA to the group. As per Don's suggestion, allow me to branch this thread and edit the header. I will do the same with Qin's uRes proposal. Thomas On Tue, Jan 29, 2013 at 1:14 PM, Maria Rita PALATTELLA < maria-rita.palattella@uni.lu> wrote: > Thomas, > > for sure it is a long email, but full of interesting info and thoughts! > > I totally agree with you about the idea of having a 6tsch layer, between > TSCH and RPL. Actually, TASA (Traffic-Aware Scheduling Algorithm [1-3]) is > built on such idea. > > TASA is a centralized scheduling algorithm, running on a master node in a > IEEE802.1.5.4e network. It allows to build TSCH schedule, based on the > network topology and the traffic load. Thus, it uses the information > related to the paths, coming from RPL, and those related to the traffic > (i.e., average traffic load generated by each node) in order to provide > time slots/channel hops patterns, able to fulfill given requirements (i.e., > duty cycle, throughput, etc.) . > > You can find more info and details here: > > > - [1] Palattella, Maria Rita; Accettura, Nicola; Dohler, Mischa; > Grieco, Luigi Alfredo; Boggia, Gennaro: Traffic Aware Scheduling > Algorithm for Multi-Hop IEEE 802.15.4e Networks, > Personal Indoor and Mobile Radio Communications (PIMRC), 2012 IEEE 23rd > International Symposium on, 2012, pp. 327-332 > - [2] Palattella, Maria Rita; Accettura, Nicola; Dohler, Mischa; > Grieco, Luigi Alfredo; Boggia, Gennaro: Traffic-Aware Time-Critical > Scheduling In Heavily Duty-Cycled IEEE 802.15.4e For An Industrial IoT, > Proc. of IEEE Sensors 2012, 2012. > - [3] Accettura, Nicola; Palattella, Maria Rita; Dohler, Mischa; > Grieco, Luigi Alfredo; Boggia, Gennaro: Standardized Power-Efficient & > Internet-Enabled Communication Stack for Capillary M2M Networks, > Proc. of IEEE WCNC 2012, Workshop on Internet of Things Enabling > Technologies, 2012, pp. 226-231, ISBN: 978-1-4673-0681-2 > > > Of course, I will be more than happy in providing more information, and > discuss more about TASA in case you may find in it a possible solution to > our problem (or at least, part of the problem)! > Best Regards, > Maria Rita > > > ------------------------------ > *From:* 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of > Thomas Watteyne [watteyne@eecs.berkeley.edu] > *Sent:* Tuesday, January 29, 2013 9:04 PM > *To:* 6tsch@ietf.org > > *Subject:* Re: [6tsch] Welcome to the "6tsch" mailing list > > Nick, Michael, > > Very interesting discussion, indeed. I can't resist to add my 2c. > > IEEE802.15.4e TSCH makes a subtle distinction between a *link *("a > single slot scheduled from mote A to mote B") and a *path *("union of all > links between A and B"). A link is attached a channelOffset, TX|RX> tuple [1]. If multiple links are scheduled to the > same neighbor, they are typically equivalent, i.e. the MAC layer sends the > packet on whichever of these links happens to show up after the packet was > put in the MAC queue. Since the slotframe repeats over time (and the length > of the slotframe is typically constant), each *link* gives you a > "quantum" of bandwidth to a given neighbor. By modifying the number of > links in a *path*, you modify the resources allocated between two > neighbors. > > The TSCH standard is *extremely* flexible, and you can implement lots of > fanciness within the standard. Implementations can for example keep > per-link statistics: at any time, you can know how many packets you > sent/received, for each neighbor and for each link. Based on this > information, you can play with the queuing behavior (e.g. wait for this > link to show up because this one is behaving bad), or with the schedule > (e.g. link 14 to neighbor A is worse than all the other to this neighbor, > let's talk to mote A to replace it with another one). TSCH really only > defines how to execute the schedule, so there's lots (and lots) of room for > defining behavior. > > Maybe too much room to be handled entirely by RPL. As I see it, RPL only > wants to know about some cost associated with the topology, and uses that > to compute multi-hop routes. In particular, I believe RPL is more > interested in *paths* (the "performance" of the connection between two > neighbors), rather than the individual *links *making up each path. In my > opinion (and this is, I believe, perfectly in line with *Xavi*'s > comment), we could define a *6tsch* layer which sits between TSCH and > RPL. The goal of this layer would be to (1) turn some throughput > requirements into *links *in the schedule and (2) collect information and > feedback *path* statistics to RPL. > > Implementations of this layer can be all over the spectrum: it can be > controlled by an outside (central) scheduler, it can implement some > neighbor-to-neighbor communication to set up a schedule in a distributed > fashion, or anything in-between. The goal is, I believe, to avoid for RPL > to have to specify the exact slot to send on, RPL tells the *6tsch* layer > to "send this packet to neighbor A". > > To come back to *Michael*'s comment, I believe that, with this setup, > RPL actually can be using traditional metrics (ETX, bandwidth, latency, > etc), the *6tsch* layer taking care of MAC specifics. > > One last thing I believe is important: what TSCH *does* define is how to > frequency hop. At each occurrence of a slot in the slotframe, the frequency > to communicate on is recalculated [2], and is different from the last time. > This means that neither the *6tsch* layer nor RPL need to worry about the > actual frequency to communicate on; the schedule just looks like a grid. > > I realize now this became a quite long e-mail, thanks for ready through > here! > > Thoughts? > > Thomas > > [1] IEEE802.15.4e, Section 6.2.19.3 > [2] IEEE802.15.4e, Section 5.1.1a > > On Tue, Jan 29, 2013 at 6:05 AM, Michael Richardson > wrote: > >> >> >>>>> "Nick" == Nick Moore writes: >> Nick> * Should all this >> Nick> be happening down in the MAC layer instead? >> >> >> No. >> >> Nick> OK, but why? What makes this an L3 (/ L2.5) thing? >> >> Nick> I'm not just asking to be contrarian, if this is to become an >> Nick> IETF WG that'd be part of the charter ... >> >> A number of reasons. >> 1) the bufferbloat results suggests that buffering at L2 is a bad >> thing. While very resource constrained nodes are unlikely to have much >> buffer at all, this is not true for edge/gateway nodes, and it is >> increasing untrue of various wearable and PAN-type devices such as >> smartphones which will get LLN interfaces. >> >> It was particularly a surprise to many layer-3 types what the 802.11 >> access point people are doing at layer 2. A lot of it invalidates >> significant architectural assumptions. In many cases, the layer-2 >> optimizations are coding to the benchmarks, rather than the real >> traffic. >> >> 2) layer-3 (and higher) may need to make (re-)prioritization decisions >> based >> upon what the transimission schedule is. >> Consider an actuator of some kind (a device that includes a fire >> supressor...) that, due to its critical nature has multiple layer-2 >> connections using different technologies. Maybe IPv6 over CAN over >> 9600 baud multi-drop RS422 and 4e. Layer-3 LLNs can easily build a >> DAG that includes both transports, realize that as slow as the 4e >> might be, it's usually still faster for non-critical traffic than the >> CAN. >> >> The layer-3 DAG would actually permit the the device to be addressed >> by the application using a single IPv6 address, with the network >> figuring out how to get things there. That means less complexity and >> network knowledge required by the application. >> >> There may be times during the 4e cycle when the CAN is faster than >> the wireless. There also could be congestion on the 4e which would >> cause the slot to be missed. If the packet remained queued for the >> same layer-2, it would remain for an entire cycle. >> >> 3) In the ethernet world, I point to STP and its variants as layer-2 >> attempts to do routing, which failed. Well, it does what it was >> advertised to do (detect and disable loops), but it turns out that >> we need much more than that. >> People have gone to layer-3 solutions like OSPF instead, because it >> provides diagnostics, works across vendors, and it responds much >> faster. And we also have TRILL. >> >> -- >> Michael Richardson , Sandelman Software Works >> >> >> >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch >> >> > > --f46d042e007935dcea04d4990771 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Maria Rita,

Thanks for introducing TASA to the group. As per Don's = suggestion, allow me to branch this thread and edit the header. I will do t= he same with Qin's uRes proposal.

Thomas

On Tue, Jan 29, 2013 at 1:14 PM, Maria Rita PALATTELLA &l= t;maria-r= ita.palattella@uni.lu> wrote:

Thomas,

for sure it is a long email, but full of interesting info and thoughts!

I totally agree with you about the idea of having a 6tsch layer, between TS= CH and RPL. Actually, TASA (Traffic-Aware Scheduling Algorithm [1-3]) is bu= ilt on such idea.

TASA is a centralized scheduling algorithm, running on a master node in a I= EEE802.1.5.4e network. It allows to build TSCH schedule, based on the netwo= rk topology and the traffic load. Thus, it uses the information related to = the paths, coming from RPL, and those related to the traffic (i.e., average traffic load generated by each= node) in order to provide time slots/channel hops patterns, able to fulfil= l given requirements (i.e., duty cycle, throughput, etc.) .

You can find more info and details here:

[1] Palattella, Maria Rita; Accettura, Nicola; Dohler, Mischa; Grieco, = Luigi Alfredo; Boggia, Gennaro: = Traffic Aware Scheduling Algorithm for Multi-Hop IEEE 802.15.4e Networks, Personal Indoor and Mobile Radio Communications (PIMRC), 2012 IEE= E 23rd International Symposium on, 2012, pp. 327-332
[2] Palattella, Maria Rita; Accettura, Nicola; D= ohler, Mischa; Grieco, Luigi Alfredo; Boggia, Gennaro: = Traffic-Aware Time-Critical Scheduling In Heavily Duty-Cycled IEEE 802.15.4= e For An Industrial IoT, Proc. of IEEE Sensors 2012, 2012.

[3] Accettura, Nicola; Palattella, Maria Rita; Dohler, Mischa; Grieco, = Luigi Alfredo; Boggia, Gennaro: = Standardized Power-Efficient & Internet-Enabled Communication Stack for= Capillary M2M Networks, Proc. of IEEE WCNC 2012, Workshop on In= ternet of Things Enabling Technologies, 2012, pp. 226-231, ISBN: 978-1-4673-0681-2

Of course, I will be more than happy in providing more information, and = discuss more about TASA in case you may find in it a possible solution to o= ur problem (or at least, part of the problem)!

Best Regards,
Maria Rita

Fro= m: 6tsch-bo= unces@ietf.org [6tsch-bounces@ietf.org] on behalf of Thomas Watteyne [watteyne@eecs.berkeley.= edu]
Sent: Tuesday, January 29, 2013 9:04 PM
To: 6tsch@ietf.o= rg

Subject: Re: [6tsch] Welcome to the "6tsch" mailing list

Nick, Michael,

Very interesting discussion, indeed. I can't resist to add my 2c.<= /div>

IEEE802.15.4e TSCH makes a subtle distinction between a link (&= quot;a single slot scheduled from mote A to mote B") and a path ("union of all links between A and B"). A link is att= ached a <neighbor, slotOffset, channelOffset, TX|RX> tuple [1]. If mu= ltiple links are scheduled to the same neighbor, they are typically equival= ent, i.e. the MAC layer sends the packet on whichever of these links happens to show up after the packet was put in the MAC queu= e. Since the slotframe repeats over time (and the length of the slotframe i= s typically constant), each link gives you a "quantum" of bandwidth to a given neighbo= r. By modifying the number of links in a path, you modify the resources allocated between two neighbors.

The TSCH standard is *extremely* flexible, and you can implement lots = of fanciness within the standard. Implementations can for example keep per-= link statistics: at any time, you can know how many packets you sent/receiv= ed, for each neighbor and for each link. Based on this information, you can play with the queuing behavior (e= .g. wait for this link to show up because this one is behaving bad), or wit= h the schedule (e.g. link 14 to neighbor A is worse than all the other to t= his neighbor, let's talk to mote A to replace it with another one). TSCH really only defines how to execute= the schedule, so there's lots (and lots) of room for defining behavior= .

Maybe too much room to be handled=A0entirely=A0by RPL. As I see it, RP= L only wants to know about some cost associated with the topology, and uses= that to compute multi-hop routes. In particular, I believe RPL is more int= erested in paths (the "performance" of the connection between two nei= ghbors), rather than the individual links making up each path. In my opinion (and this is, I believe, pe= rfectly in line with Xavi's comment), we could define a 6tsch layer which sits= between TSCH and RPL. The goal of this layer would be to (1) turn some thr= oughput requirements into links in the schedule and (2) collect information and feedback pa= th statistics to RPL.

Implementations of this layer can be all over the spectrum: it can be = controlled by an outside (central) scheduler, it can implement some neighbo= r-to-neighbor communication to set up a schedule in a distributed fashion, = or anything in-between. The goal is, I believe, to avoid for RPL to have to specify the exact slot to send = on, RPL tells the 6tsch layer to "send this packet to neighbor A".

To come back to=A0Michael's comment, I believe that, with t= his setup, RPL actually can be using traditional metrics (ETX, bandwidth, l= atency, etc), the 6tsch layer taking care of MAC specifics.

One last thing I believe is important: what TSCH does define is= how to frequency hop. At each occurrence of a slot in the slotframe, the f= requency to communicate on is recalculated [2], and is different from the l= ast time. This means that neither the 6tsch layer nor RPL need to worry about the actual frequency to= communicate on; the schedule just looks like a grid.

I realize now this became a quite long e-mail, thanks for ready throug= h here!

Thoughts?

Thomas

[1] IEEE802.15.4e, Section 6.2.19.3

[2]=A0IEEE802.15.4e, Section 5.1.1a

On Tue, Jan 29, 2013 at 6:05 AM, Michael Richard= son <mcr+ietf@san= delman.ca> wrote:

>>>>> "Nick" =3D=3D Nick Moore <nick@zoic.org> writes:

=A0 =A0 Nick> * Should all this

=A0 =A0 Nick> be happening down in the MAC layer instead?

=A0 =A0 >> No.

=A0 =A0 Nick> OK, but why? =A0What makes this an L3 (/ L2.5) thing?

=A0 =A0 Nick> I'm not just asking to be contrarian, if this is to be= come an
=A0 =A0 Nick> IETF WG that'd be part of the charter ...

A number of reasons.
1) the bufferbloat results suggests that buffering at L2 is a bad
=A0 =A0thing. =A0While very resource constrained nodes are unlikely to have= much
=A0 =A0buffer at all, this is not true for edge/gateway nodes, and it is =A0 =A0increasing untrue of various wearable and PAN-type devices such as =A0 =A0smartphones which will get LLN interfaces.

=A0 =A0It was particularly a surprise to many layer-3 types what the 802.11=
=A0 =A0access point people are doing at layer 2. =A0A lot of it invalidates=
=A0 =A0significant architectural assumptions. =A0In many cases, the layer-2=
=A0 =A0optimizations are coding to the benchmarks, rather than the real tra= ffic.

2) layer-3 (and higher) may need to make (re-)prioritization decisions base= d
=A0 =A0upon what the transimission schedule is.
=A0 =A0Consider an actuator of some kind (a device that includes a fire
=A0 =A0supressor...) that, due to its critical nature has multiple layer-2<= br> =A0 =A0connections using different technologies. =A0Maybe IPv6 over CAN ove= r
=A0 =A09600 baud multi-drop RS422 and 4e. =A0Layer-3 LLNs can easily build = a
=A0 =A0DAG that includes both transports, realize that as slow as the 4e =A0 =A0might be, it's usually still faster for non-critical traffic tha= n the CAN.

=A0 =A0The layer-3 DAG would actually permit the the device to be addressed=
=A0 =A0by the application using a single IPv6 address, with the network
=A0 =A0figuring out how to get things there. =A0That means less complexity = and
=A0 =A0network knowledge required by the application.

=A0 =A0There may be times during the 4e cycle when the CAN is faster than =A0 =A0the wireless. =A0There also could be congestion on the 4e which woul= d
=A0 =A0cause the slot to be missed. =A0If the packet remained queued for th= e
=A0 =A0same layer-2, it would remain for an entire cycle.

3) In the ethernet world, I point to STP and its variants as layer-2
=A0 =A0attempts to do routing, which failed. =A0Well, it does what it was =A0 =A0advertised to do (detect and disable loops), but it turns out that =A0 =A0we need much more than that.
=A0 =A0People have gone to layer-3 solutions like OSPF instead, because it<= br> =A0 =A0provides diagnostics, works across vendors, and it responds much
=A0 =A0faster. And we also have TRILL.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works

_______________________________________________
6tsch mailing list
6tsch@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/6tsch

--f46d042e007935dcea04d4990771-- From twatteyne@gmail.com Thu Jan 31 09:39:02 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 912E021F86A5 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 09:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.209 X-Spam-Level: X-Spam-Status: No, score=-1.209 tagged_above=-999 required=5 tests=[AWL=-0.814, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id thZl7Y8DAYKZ for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 09:39:01 -0800 (PST) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEBD21F86A2 for <6tsch@ietf.org>; Thu, 31 Jan 2013 09:39:01 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id bj3so675686pad.20 for <6tsch@ietf.org>; Thu, 31 Jan 2013 09:39:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=h2o5PhhjCAVOB1rboW7VtJ3IV0iUwIAnKsyMMwawOhQ=; b=s1+8L/p4NC/ptE6eH1MrWxi5gfrpCxyMoeNZoV0AuBZ+7PrQYvXbAYJSmb7CLTj1C1 HAJoqFXVJCiZ8YFkCqPdKaQJ6UjYesQcB+aMHskRCHyWZnrgfVmqFOx9zDldLLB/fF+G 4EKHjDqPPscT9O/nF58ow1s+cHjUqsRGVxalawOX/ojJHYNk+p84Jj4OKqkBtEBLQfT4 e38FqvPPV1tU3BsYFsRJaJBVjk1fPiK5DHcuBHFFcrK95FDva7lOITA+awAXr7W5GInp zMvOpVgNCWMw55YYXTOvgPP3q4S8/2RT3i6Sfho9QIw5bIsxsCN50orixpTTJG0VmA6N gShA== MIME-Version: 1.0 X-Received: by 10.68.197.9 with SMTP id iq9mr24012493pbc.130.1359653941290; Thu, 31 Jan 2013 09:39:01 -0800 (PST) Sender: twatteyne@gmail.com Received: by 10.66.121.33 with HTTP; Thu, 31 Jan 2013 09:39:01 -0800 (PST) Date: Thu, 31 Jan 2013 09:39:01 -0800 X-Google-Sender-Auth: OdnXVB7fKZfhCLd1CfF1lHKHtqk Message-ID: From: Thomas Watteyne To: IETF 6TSCH <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=e89a8ff1c85c3025b804d4991aae Subject: [6tsch] uRes: distributed scheduling X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 17:39:02 -0000 --e89a8ff1c85c3025b804d4991aae Content-Type: text/plain; charset=ISO-8859-1 Qin, Thanks for introducing uRes. As per Don's suggestion, I'm branching this thread and editing the subject. Thomas On Thu, Jan 31, 2013 at 6:42 AM, Mischa Dohler wrote: > Qin, > > I like this and would like to hear more about it. Do you have some > papers/results? > > You can turn the problem as you want* but if you really want a multihop > system to scale (beyond some 500-1000 nodes), you need a distributed system > and some machine learning** on top. This is because in static link > topologies, the aggregate set of locally-chosen links will converge > eventually to the optimal path; there will be no routing solution for > ergodic (completely dynamic) link topologies beyond DTN approaches (just > take it); and non-ergodic (but also non-static) link topologies, where > links are occasionally in outage, can only be handled in a distributed > fashion. > > So I am all in for seeing how you could make .15.4e & RPL work closely > together in a distributed fashion. > > Thanks, > Mischa. > > * The adhoc community is very good at this: they have published zillions > of papers, proposed millions of protocols, have loads of RFCs but no viable > product after 50 years of work - mobility/dynamics are very fundamental > problems which you can only solve meaningfully with one-hop star-topology > technology ... wait ... this is cellular. > > ** We recently standardized some machine learning approaches in a > broadband standard; setting was different but problem the same. > > ______________________________**____ > > Mischa Dohler > > Director of Research, CTTC > Distinguished Lecturer, IEEE > Editor-in-Chief, ETT > BoD, Worldsensing > > Mob: +34 679 094 007 > Tel: +34 936 452 909 > Fax: +34 936 452 901 > > www.cttc.es/home/mdohler > ______________________________**____ > > > On 30/01/2013 22:37, qinwang@berkeley.edu wrote: > >> Hi, >> >> As Thomas and Xavi explained, RPL is responsible for choosing a *Path*, >> i.e. next hop neighbor, and asking TSCH to forward packets; and TSCH >> provides a mechanism to use *Links* (neighbor, slot, channel, TX/RX), >> which is the mapping of a *Path*, to conduct forwarding. Thus, the missing >> piece is how to establish and maintain the *Links*. My understanding is >> that 6tsch will fill the gap. In addition, considering resource >> constraints of devices and characteristics of IoT, 6tsch should be very >> simple and flexible for wide range of application in terms of mobility, >> density, latency,and so on. >> >> In UC@Berkeley, we have designed a protocol, called uRes. The function of >> uRes is to establish and maintain the *Links* with neighbors. uRes is a >> distributed protocol, i.e. the computation and communication for link >> reservation just happen locally. uRes is coded in Information Elements >> (IEs) of IEEE802.15.4e, thus, just fits to TSCH and provides flexibility >> for further optimization and extension. uRes has been implemented in >> OpenWSN (openwsn.berkeley.edu). >> >> >> Regards >> Qin >> >> >> >> >> On 30/01/13 07:04, Thomas Watteyne wrote: >>> >>>> Maybe too much room to be handled entirely by RPL. As I see it, RPL >>>> only wants to know about some cost associated with the topology, and >>>> uses that to compute multi-hop routes. In particular, I believe RPL is >>>> more interested in /paths/ (the "performance" of the connection >>>> between two neighbors), rather than the individual /links /making up >>>> each path. In my opinion (and this is, I believe, perfectly in line >>>> with *Xavi*'s comment), we could define a /6tsch/ layer which sits >>>> between TSCH and RPL. The goal of this layer would be to (1) turn some >>>> throughput requirements into /links /in the schedule and (2) collect >>>> information and feedback /path/ statistics to RPL. >>>> >>> [...] >>> >>> To come back to *Michael*'s comment, I believe that, with this setup, >>>> RPL actually can be using traditional metrics (ETX, bandwidth, >>>> latency, etc), the /6tsch/ layer taking care of MAC specifics. >>>> >>>> Yep, that makes sense! And as per Michael's comments, RPL can then >>> handle the routing across different L2s. >>> >>> >>> On 29/01/13 15:09, Michael Richardson wrote: >>> >>>> I agree. It's just that this is a new kind of metric: in the past we >>>> have things like abtracted ETX, bandwidth available, power, latency, >>>> etc... none of these things are a cyclic f(t). This new info is. >>>> >>> Is it appropriate for the 6tsch routing metrics to change (or as you put >>> it, to be a cyclic function) *within* the period of a slotframe? >>> >>> For example, if node A is trying to transmit to node D and can go via >>> either node B or node C, then the "best route" may toggle back and forth >>> between B and C depending on which has the next available link(s), >>> potentially multiple times per slotframe period. Is this good >>> behaviour? I guess in the LoWPAN world it might be. >>> >>> >>> I think I'd better stop asking open-ended questions now and go read some >>> stuff :-) >>> >>> -----Nick >>> >>> -- >>> Nick Moore 0409 656 267 >>> >>> ______________________________**_________________ >>> 6tsch mailing list >>> 6tsch@ietf.org >>> https://www.ietf.org/mailman/**listinfo/6tsch >>> >>> >> ______________________________**_________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/**listinfo/6tsch >> > > ______________________________**_________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/**listinfo/6tsch > --e89a8ff1c85c3025b804d4991aae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Qin,

Thanks for introducing uRes. As per Don's suggestion, I'm = branching this thread and editing the subject.

Thomas

On Thu, Jan 31, 2013 at 6:42 AM, Mischa Dohler <mischa.dohler@cttc.es> wrote:

Qin,

I like this and would like to hear more about it. Do you have some papers/r= esults?

You can turn the problem as you want* but if you really want a multihop sys= tem to scale (beyond some 500-1000 nodes), you need a distributed system an= d some machine learning** on top. This is because in static link topologies= , the aggregate set of locally-chosen links will converge eventually to the= optimal path; there will be no routing solution for ergodic (completely dy= namic) link topologies beyond DTN approaches (just take it); and non-ergodi= c (but also non-static) link topologies, where links are occasionally in ou= tage, can only be handled in a distributed fashion.

So I am all in for seeing how you could make .15.4e & RPL work closely = together in a distributed fashion.

Thanks,
Mischa.

* The adhoc community is very good at this: they have published zillions of= papers, proposed millions of protocols, have loads of RFCs but no viable p= roduct after 50 years of work - mobility/dynamics are very fundamental prob= lems which you can only solve meaningfully with one-hop star-topology techn= ology ... wait ... this is cellular.

** We recently standardized some machine learning approaches in a broadband= standard; setting was different but problem the same.

__________________________________

Mischa Dohler

Director of Research, CTTC
Distinguished Lecturer, IEEE
Editor-in-Chief, ETT
BoD, Worldsensing

Mob: +34 679 094 007
Tel: +34 936 452 909
Fax: +34 936 452 901

www.cttc.es/h= ome/mdohler
__________________________________

On 30/01/2013 22:37, qinwang@berkeley.edu wrote:

Hi,

As Thomas and Xavi explained, RPL is responsible for choosing a *Path*,
i.e. next hop neighbor, and asking TSCH to forward packets; and TSCH
provides a mechanism to use *Links* (neighbor, slot, channel, TX/RX),
which is the mapping of a *Path*, to conduct forwarding. Thus, the missing<= br> piece is how to establish and maintain the *Links*. =A0My understanding is<= br> that 6tsch will fill the gap. In addition, considering resource
constraints of devices and characteristics of IoT, 6tsch should be very
simple and flexible for wide range of application in terms of mobility,
density, latency,and so on.

In UC@Berkeley, we have designed a protocol, called uRes. The function of uRes is to establish and maintain the *Links* with neighbors. uRes is a
distributed protocol, i.e. the computation and communication for link
reservation just happen locally. uRes is coded in Information Elements
(IEs) of IEEE802.15.4e, thus, just fits to TSCH and provides flexibility for further optimization and extension. uRes has been implemented in
OpenWSN (openwsn.= berkeley.edu).

Regards
Qin

On 30/01/13 07:04, Thomas Watteyne wrote:

Maybe too much room to be handled entirely by RPL. As I see it, RPL
only wants to know about some cost associated with the topology, and
uses that to compute multi-hop routes. In particular, I believe RPL is
more interested in /paths/ (the "performance" of the connection between two neighbors), rather than the individual /links /making up
each path. In my opinion (and this is, I believe, perfectly in line
with *Xavi*'s comment), we could define a /6tsch/ layer which sits
between TSCH and RPL. The goal of this layer would be to (1) turn some
throughput requirements into /links /in the schedule and (2) collect
information and feedback /path/ statistics to RPL.

[...]

To come back to *Michael*'s comment, I believe that, with this setup, RPL actually can be using traditional metrics (ETX, bandwidth,
latency, etc), the /6tsch/ layer taking care of MAC specifics.

Yep, that makes sense! =A0And as per Michael's comments, RPL can then handle the routing across different L2s.

On 29/01/13 15:09, Michael Richardson wrote:

I agree. It's just that this is a new kind of metric: in the past we have things like abtracted ETX, bandwidth available, power, latency,
etc... none of these things are a cyclic f(t). This new info is.

Is it appropriate for the 6tsch routing metrics to change (or as you put it, to be a cyclic function) *within* the period of a slotframe?

For example, if node A is trying to transmit to node D and can go via
either node B or node C, then the "best route" may toggle back an= d forth
between B and C depending on which has the next available link(s),
potentially multiple times per slotframe period. =A0Is this good
behaviour? =A0I guess in the LoWPAN world it might be.

I think I'd better stop asking open-ended questions now and go read som= e
stuff :-)

-----Nick

--
Nick Moore <nick@zoic= .org> 0409 656 267

_______________________________________________
6tsch mailing list
6tsch@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
6tsch@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
6tsch@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/6tsch

--e89a8ff1c85c3025b804d4991aae-- From qinwang@berkeley.edu Thu Jan 31 11:52:05 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70D2621F8868 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 11:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.841 X-Spam-Level: X-Spam-Status: No, score=-5.841 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7mP9ZJZz1Bj for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 11:52:04 -0800 (PST) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2851421F8863 for <6tsch@ietf.org>; Thu, 31 Jan 2013 11:52:03 -0800 (PST) Received: from cm01ws.ist.berkeley.edu ([169.229.218.163] helo=calmail.berkeley.edu) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1U10Ay-00062t-5L; Thu, 31 Jan 2013 11:52:02 -0800 Received: from 173.49.9.236 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Thu, 31 Jan 2013 11:52:00 -0800 Message-ID: <7f028996a970643a107d4793038bdb5d.squirrel@calmail.berkeley.edu> In-Reply-To: References: Date: Thu, 31 Jan 2013 11:52:00 -0800 From: qinwang@berkeley.edu To: "Thomas Watteyne" User-Agent: SquirrelMail/1.4.21-2.berkeley MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IETF 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] uRes: distributed scheduling X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 19:52:05 -0000 Hi Mischa, Instead of talking about distributed/centralized scheduling policy, I would like to clarify the function of 6tsch according to my understanding. 6tsch is a sub-layer between RPL and TSCH. Basically, 6tsch should provide two functions, one is to establish and maintain the *Links* (neighbor, slot, channel, TX/RX), which reflects bandwidth requirement from upper layer, and is used by TSCH; another function is to provide statistics on Link/Path Quality, which will be used by RPL to choose Path, and by itself to maintain good Path quality. Ideally, 6tsch should not correlate with link scheduling policies. In another word, it should support both link schedulers running on some center and link scheduler running on each node. Fortunately, TSCH already provide services like add-link/remove-link, which allow the center device set its scheduling results into each node. Then, the missing part is some sort mechanism which allow nodes establish and maintain their *Links* locally. That is what uRes is designed for. Qin > Qin, > Thanks for introducing uRes. As per Don's suggestion, I'm branching this > thread and editing the subject. > Thomas > > On Thu, Jan 31, 2013 at 6:42 AM, Mischa Dohler > wrote: > >> Qin, >> >> I like this and would like to hear more about it. Do you have some >> papers/results? >> >> You can turn the problem as you want* but if you really want a multihop >> system to scale (beyond some 500-1000 nodes), you need a distributed >> system >> and some machine learning** on top. This is because in static link >> topologies, the aggregate set of locally-chosen links will converge >> eventually to the optimal path; there will be no routing solution for >> ergodic (completely dynamic) link topologies beyond DTN approaches (just >> take it); and non-ergodic (but also non-static) link topologies, where >> links are occasionally in outage, can only be handled in a distributed >> fashion. >> >> So I am all in for seeing how you could make .15.4e & RPL work closely >> together in a distributed fashion. >> >> Thanks, >> Mischa. >> >> * The adhoc community is very good at this: they have published zillions >> of papers, proposed millions of protocols, have loads of RFCs but no >> viable >> product after 50 years of work - mobility/dynamics are very fundamental >> problems which you can only solve meaningfully with one-hop >> star-topology >> technology ... wait ... this is cellular. >> >> ** We recently standardized some machine learning approaches in a >> broadband standard; setting was different but problem the same. >> >> ______________________________**____ >> >> Mischa Dohler >> >> Director of Research, CTTC >> Distinguished Lecturer, IEEE >> Editor-in-Chief, ETT >> BoD, Worldsensing >> >> Mob: +34 679 094 007 >> Tel: +34 936 452 909 >> Fax: +34 936 452 901 >> >> www.cttc.es/home/mdohler >> ______________________________**____ >> >> >> On 30/01/2013 22:37, qinwang@berkeley.edu wrote: >> >>> Hi, >>> >>> As Thomas and Xavi explained, RPL is responsible for choosing a *Path*, >>> i.e. next hop neighbor, and asking TSCH to forward packets; and TSCH >>> provides a mechanism to use *Links* (neighbor, slot, channel, TX/RX), >>> which is the mapping of a *Path*, to conduct forwarding. Thus, the >>> missing >>> piece is how to establish and maintain the *Links*. My understanding >>> is >>> that 6tsch will fill the gap. In addition, considering resource >>> constraints of devices and characteristics of IoT, 6tsch should be very >>> simple and flexible for wide range of application in terms of mobility, >>> density, latency,and so on. >>> >>> In UC@Berkeley, we have designed a protocol, called uRes. The function >>> of >>> uRes is to establish and maintain the *Links* with neighbors. uRes is a >>> distributed protocol, i.e. the computation and communication for link >>> reservation just happen locally. uRes is coded in Information Elements >>> (IEs) of IEEE802.15.4e, thus, just fits to TSCH and provides >>> flexibility >>> for further optimization and extension. uRes has been implemented in >>> OpenWSN (openwsn.berkeley.edu). >>> >>> >>> Regards >>> Qin >>> >>> >>> >>> >>> On 30/01/13 07:04, Thomas Watteyne wrote: >>>> >>>>> Maybe too much room to be handled entirely by RPL. As I see it, RPL >>>>> only wants to know about some cost associated with the topology, and >>>>> uses that to compute multi-hop routes. In particular, I believe RPL >>>>> is >>>>> more interested in /paths/ (the "performance" of the connection >>>>> between two neighbors), rather than the individual /links /making up >>>>> each path. In my opinion (and this is, I believe, perfectly in line >>>>> with *Xavi*'s comment), we could define a /6tsch/ layer which sits >>>>> between TSCH and RPL. The goal of this layer would be to (1) turn >>>>> some >>>>> throughput requirements into /links /in the schedule and (2) collect >>>>> information and feedback /path/ statistics to RPL. >>>>> >>>> [...] >>>> >>>> To come back to *Michael*'s comment, I believe that, with this setup, >>>>> RPL actually can be using traditional metrics (ETX, bandwidth, >>>>> latency, etc), the /6tsch/ layer taking care of MAC specifics. >>>>> >>>>> Yep, that makes sense! And as per Michael's comments, RPL can then >>>> handle the routing across different L2s. >>>> >>>> >>>> On 29/01/13 15:09, Michael Richardson wrote: >>>> >>>>> I agree. It's just that this is a new kind of metric: in the past we >>>>> have things like abtracted ETX, bandwidth available, power, latency, >>>>> etc... none of these things are a cyclic f(t). This new info is. >>>>> >>>> Is it appropriate for the 6tsch routing metrics to change (or as you >>>> put >>>> it, to be a cyclic function) *within* the period of a slotframe? >>>> >>>> For example, if node A is trying to transmit to node D and can go via >>>> either node B or node C, then the "best route" may toggle back and >>>> forth >>>> between B and C depending on which has the next available link(s), >>>> potentially multiple times per slotframe period. Is this good >>>> behaviour? I guess in the LoWPAN world it might be. >>>> >>>> >>>> I think I'd better stop asking open-ended questions now and go read >>>> some >>>> stuff :-) >>>> >>>> -----Nick >>>> >>>> -- >>>> Nick Moore 0409 656 267 >>>> >>>> ______________________________**_________________ >>>> 6tsch mailing list >>>> 6tsch@ietf.org >>>> https://www.ietf.org/mailman/**listinfo/6tsch >>>> >>>> >>> ______________________________**_________________ >>> 6tsch mailing list >>> 6tsch@ietf.org >>> https://www.ietf.org/mailman/**listinfo/6tsch >>> >> >> ______________________________**_________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/**listinfo/6tsch >> > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > From qinwang@berkeley.edu Thu Jan 31 11:52:07 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E164021F8462 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 11:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.841 X-Spam-Level: X-Spam-Status: No, score=-5.841 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3o-LFw5qJiH for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 11:52:06 -0800 (PST) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id F311121F8863 for <6tsch@ietf.org>; Thu, 31 Jan 2013 11:52:05 -0800 (PST) Received: from cm01ws.ist.berkeley.edu ([169.229.218.163] helo=calmail.berkeley.edu) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1U10B1-0002rz-B4; Thu, 31 Jan 2013 11:52:05 -0800 Received: from 173.49.9.236 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Thu, 31 Jan 2013 11:52:03 -0800 Message-ID: <4d3823059bff05a90e90da68e421f0b7.squirrel@calmail.berkeley.edu> In-Reply-To: References: Date: Thu, 31 Jan 2013 11:52:03 -0800 From: qinwang@berkeley.edu To: "Thomas Watteyne" User-Agent: SquirrelMail/1.4.21-2.berkeley MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IETF 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] uRes: distributed scheduling X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 19:52:07 -0000 Hi Mischa, Instead of talking about distributed/centralized scheduling policy, I would like to clarify the function of 6tsch according to my understanding. 6tsch is a sub-layer between RPL and TSCH. Basically, 6tsch should provide two functions, one is to establish and maintain the *Links* (neighbor, slot, channel, TX/RX), which reflects bandwidth requirement from upper layer, and is used by TSCH; another function is to provide statistics on Link/Path Quality, which will be used by RPL to choose Path, and by itself to maintain good Path quality. Ideally, 6tsch should not correlate with link scheduling policies. In another word, it should support both link schedulers running on some center and link scheduler running on each node. Fortunately, TSCH already provide services like add-link/remove-link, which allow the center device set its scheduling results into each node. Then, the missing part is some sort mechanism which allow nodes establish and maintain their *Links* locally. That is what uRes is designed for. Qin > Qin, > Thanks for introducing uRes. As per Don's suggestion, I'm branching this > thread and editing the subject. > Thomas > > On Thu, Jan 31, 2013 at 6:42 AM, Mischa Dohler > wrote: > >> Qin, >> >> I like this and would like to hear more about it. Do you have some >> papers/results? >> >> You can turn the problem as you want* but if you really want a multihop >> system to scale (beyond some 500-1000 nodes), you need a distributed >> system >> and some machine learning** on top. This is because in static link >> topologies, the aggregate set of locally-chosen links will converge >> eventually to the optimal path; there will be no routing solution for >> ergodic (completely dynamic) link topologies beyond DTN approaches (just >> take it); and non-ergodic (but also non-static) link topologies, where >> links are occasionally in outage, can only be handled in a distributed >> fashion. >> >> So I am all in for seeing how you could make .15.4e & RPL work closely >> together in a distributed fashion. >> >> Thanks, >> Mischa. >> >> * The adhoc community is very good at this: they have published zillions >> of papers, proposed millions of protocols, have loads of RFCs but no >> viable >> product after 50 years of work - mobility/dynamics are very fundamental >> problems which you can only solve meaningfully with one-hop >> star-topology >> technology ... wait ... this is cellular. >> >> ** We recently standardized some machine learning approaches in a >> broadband standard; setting was different but problem the same. >> >> ______________________________**____ >> >> Mischa Dohler >> >> Director of Research, CTTC >> Distinguished Lecturer, IEEE >> Editor-in-Chief, ETT >> BoD, Worldsensing >> >> Mob: +34 679 094 007 >> Tel: +34 936 452 909 >> Fax: +34 936 452 901 >> >> www.cttc.es/home/mdohler >> ______________________________**____ >> >> >> On 30/01/2013 22:37, qinwang@berkeley.edu wrote: >> >>> Hi, >>> >>> As Thomas and Xavi explained, RPL is responsible for choosing a *Path*, >>> i.e. next hop neighbor, and asking TSCH to forward packets; and TSCH >>> provides a mechanism to use *Links* (neighbor, slot, channel, TX/RX), >>> which is the mapping of a *Path*, to conduct forwarding. Thus, the >>> missing >>> piece is how to establish and maintain the *Links*. My understanding >>> is >>> that 6tsch will fill the gap. In addition, considering resource >>> constraints of devices and characteristics of IoT, 6tsch should be very >>> simple and flexible for wide range of application in terms of mobility, >>> density, latency,and so on. >>> >>> In UC@Berkeley, we have designed a protocol, called uRes. The function >>> of >>> uRes is to establish and maintain the *Links* with neighbors. uRes is a >>> distributed protocol, i.e. the computation and communication for link >>> reservation just happen locally. uRes is coded in Information Elements >>> (IEs) of IEEE802.15.4e, thus, just fits to TSCH and provides >>> flexibility >>> for further optimization and extension. uRes has been implemented in >>> OpenWSN (openwsn.berkeley.edu). >>> >>> >>> Regards >>> Qin >>> >>> >>> >>> >>> On 30/01/13 07:04, Thomas Watteyne wrote: >>>> >>>>> Maybe too much room to be handled entirely by RPL. As I see it, RPL >>>>> only wants to know about some cost associated with the topology, and >>>>> uses that to compute multi-hop routes. In particular, I believe RPL >>>>> is >>>>> more interested in /paths/ (the "performance" of the connection >>>>> between two neighbors), rather than the individual /links /making up >>>>> each path. In my opinion (and this is, I believe, perfectly in line >>>>> with *Xavi*'s comment), we could define a /6tsch/ layer which sits >>>>> between TSCH and RPL. The goal of this layer would be to (1) turn >>>>> some >>>>> throughput requirements into /links /in the schedule and (2) collect >>>>> information and feedback /path/ statistics to RPL. >>>>> >>>> [...] >>>> >>>> To come back to *Michael*'s comment, I believe that, with this setup, >>>>> RPL actually can be using traditional metrics (ETX, bandwidth, >>>>> latency, etc), the /6tsch/ layer taking care of MAC specifics. >>>>> >>>>> Yep, that makes sense! And as per Michael's comments, RPL can then >>>> handle the routing across different L2s. >>>> >>>> >>>> On 29/01/13 15:09, Michael Richardson wrote: >>>> >>>>> I agree. It's just that this is a new kind of metric: in the past we >>>>> have things like abtracted ETX, bandwidth available, power, latency, >>>>> etc... none of these things are a cyclic f(t). This new info is. >>>>> >>>> Is it appropriate for the 6tsch routing metrics to change (or as you >>>> put >>>> it, to be a cyclic function) *within* the period of a slotframe? >>>> >>>> For example, if node A is trying to transmit to node D and can go via >>>> either node B or node C, then the "best route" may toggle back and >>>> forth >>>> between B and C depending on which has the next available link(s), >>>> potentially multiple times per slotframe period. Is this good >>>> behaviour? I guess in the LoWPAN world it might be. >>>> >>>> >>>> I think I'd better stop asking open-ended questions now and go read >>>> some >>>> stuff :-) >>>> >>>> -----Nick >>>> >>>> -- >>>> Nick Moore 0409 656 267 >>>> >>>> ______________________________**_________________ >>>> 6tsch mailing list >>>> 6tsch@ietf.org >>>> https://www.ietf.org/mailman/**listinfo/6tsch >>>> >>>> >>> ______________________________**_________________ >>> 6tsch mailing list >>> 6tsch@ietf.org >>> https://www.ietf.org/mailman/**listinfo/6tsch >>> >> >> ______________________________**_________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/**listinfo/6tsch >> > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > From qinwang@berkeley.edu Thu Jan 31 11:52:09 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91A1221F84EA for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 11:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.841 X-Spam-Level: X-Spam-Status: No, score=-5.841 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7r5MARLO1-w for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 11:52:09 -0800 (PST) Received: from cm03fe.IST.Berkeley.EDU (cm03fe.IST.Berkeley.EDU [169.229.218.144]) by ietfa.amsl.com (Postfix) with ESMTP id 50B5621F8499 for <6tsch@ietf.org>; Thu, 31 Jan 2013 11:52:09 -0800 (PST) Received: from cm01ws.ist.berkeley.edu ([169.229.218.163] helo=calmail.berkeley.edu) by cm03fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from ) id 1U10B4-0002un-AQ; Thu, 31 Jan 2013 11:52:08 -0800 Received: from 173.49.9.236 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Thu, 31 Jan 2013 11:52:06 -0800 Message-ID: <7b45d10167602da575c822c83f825936.squirrel@calmail.berkeley.edu> In-Reply-To: References: Date: Thu, 31 Jan 2013 11:52:06 -0800 From: qinwang@berkeley.edu To: "Thomas Watteyne" User-Agent: SquirrelMail/1.4.21-2.berkeley MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: IETF 6TSCH <6tsch@ietf.org> Subject: Re: [6tsch] uRes: distributed scheduling X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 19:52:10 -0000 Hi Mischa, Instead of talking about distributed/centralized scheduling policy, I would like to clarify the function of 6tsch according to my understanding. 6tsch is a sub-layer between RPL and TSCH. Basically, 6tsch should provide two functions, one is to establish and maintain the *Links* (neighbor, slot, channel, TX/RX), which reflects bandwidth requirement from upper layer, and is used by TSCH; another function is to provide statistics on Link/Path Quality, which will be used by RPL to choose Path, and by itself to maintain good Path quality. Ideally, 6tsch should not correlate with link scheduling policies. In another word, it should support both link schedulers running on some center and link scheduler running on each node. Fortunately, TSCH already provide services like add-link/remove-link, which allow the center device set its scheduling results into each node. Then, the missing part is some sort mechanism which allow nodes establish and maintain their *Links* locally. That is what uRes is designed for. Qin > Qin, > Thanks for introducing uRes. As per Don's suggestion, I'm branching this > thread and editing the subject. > Thomas > > On Thu, Jan 31, 2013 at 6:42 AM, Mischa Dohler > wrote: > >> Qin, >> >> I like this and would like to hear more about it. Do you have some >> papers/results? >> >> You can turn the problem as you want* but if you really want a multihop >> system to scale (beyond some 500-1000 nodes), you need a distributed >> system >> and some machine learning** on top. This is because in static link >> topologies, the aggregate set of locally-chosen links will converge >> eventually to the optimal path; there will be no routing solution for >> ergodic (completely dynamic) link topologies beyond DTN approaches (just >> take it); and non-ergodic (but also non-static) link topologies, where >> links are occasionally in outage, can only be handled in a distributed >> fashion. >> >> So I am all in for seeing how you could make .15.4e & RPL work closely >> together in a distributed fashion. >> >> Thanks, >> Mischa. >> >> * The adhoc community is very good at this: they have published zillions >> of papers, proposed millions of protocols, have loads of RFCs but no >> viable >> product after 50 years of work - mobility/dynamics are very fundamental >> problems which you can only solve meaningfully with one-hop >> star-topology >> technology ... wait ... this is cellular. >> >> ** We recently standardized some machine learning approaches in a >> broadband standard; setting was different but problem the same. >> >> ______________________________**____ >> >> Mischa Dohler >> >> Director of Research, CTTC >> Distinguished Lecturer, IEEE >> Editor-in-Chief, ETT >> BoD, Worldsensing >> >> Mob: +34 679 094 007 >> Tel: +34 936 452 909 >> Fax: +34 936 452 901 >> >> www.cttc.es/home/mdohler >> ______________________________**____ >> >> >> On 30/01/2013 22:37, qinwang@berkeley.edu wrote: >> >>> Hi, >>> >>> As Thomas and Xavi explained, RPL is responsible for choosing a *Path*, >>> i.e. next hop neighbor, and asking TSCH to forward packets; and TSCH >>> provides a mechanism to use *Links* (neighbor, slot, channel, TX/RX), >>> which is the mapping of a *Path*, to conduct forwarding. Thus, the >>> missing >>> piece is how to establish and maintain the *Links*. My understanding >>> is >>> that 6tsch will fill the gap. In addition, considering resource >>> constraints of devices and characteristics of IoT, 6tsch should be very >>> simple and flexible for wide range of application in terms of mobility, >>> density, latency,and so on. >>> >>> In UC@Berkeley, we have designed a protocol, called uRes. The function >>> of >>> uRes is to establish and maintain the *Links* with neighbors. uRes is a >>> distributed protocol, i.e. the computation and communication for link >>> reservation just happen locally. uRes is coded in Information Elements >>> (IEs) of IEEE802.15.4e, thus, just fits to TSCH and provides >>> flexibility >>> for further optimization and extension. uRes has been implemented in >>> OpenWSN (openwsn.berkeley.edu). >>> >>> >>> Regards >>> Qin >>> >>> >>> >>> >>> On 30/01/13 07:04, Thomas Watteyne wrote: >>>> >>>>> Maybe too much room to be handled entirely by RPL. As I see it, RPL >>>>> only wants to know about some cost associated with the topology, and >>>>> uses that to compute multi-hop routes. In particular, I believe RPL >>>>> is >>>>> more interested in /paths/ (the "performance" of the connection >>>>> between two neighbors), rather than the individual /links /making up >>>>> each path. In my opinion (and this is, I believe, perfectly in line >>>>> with *Xavi*'s comment), we could define a /6tsch/ layer which sits >>>>> between TSCH and RPL. The goal of this layer would be to (1) turn >>>>> some >>>>> throughput requirements into /links /in the schedule and (2) collect >>>>> information and feedback /path/ statistics to RPL. >>>>> >>>> [...] >>>> >>>> To come back to *Michael*'s comment, I believe that, with this setup, >>>>> RPL actually can be using traditional metrics (ETX, bandwidth, >>>>> latency, etc), the /6tsch/ layer taking care of MAC specifics. >>>>> >>>>> Yep, that makes sense! And as per Michael's comments, RPL can then >>>> handle the routing across different L2s. >>>> >>>> >>>> On 29/01/13 15:09, Michael Richardson wrote: >>>> >>>>> I agree. It's just that this is a new kind of metric: in the past we >>>>> have things like abtracted ETX, bandwidth available, power, latency, >>>>> etc... none of these things are a cyclic f(t). This new info is. >>>>> >>>> Is it appropriate for the 6tsch routing metrics to change (or as you >>>> put >>>> it, to be a cyclic function) *within* the period of a slotframe? >>>> >>>> For example, if node A is trying to transmit to node D and can go via >>>> either node B or node C, then the "best route" may toggle back and >>>> forth >>>> between B and C depending on which has the next available link(s), >>>> potentially multiple times per slotframe period. Is this good >>>> behaviour? I guess in the LoWPAN world it might be. >>>> >>>> >>>> I think I'd better stop asking open-ended questions now and go read >>>> some >>>> stuff :-) >>>> >>>> -----Nick >>>> >>>> -- >>>> Nick Moore 0409 656 267 >>>> >>>> ______________________________**_________________ >>>> 6tsch mailing list >>>> 6tsch@ietf.org >>>> https://www.ietf.org/mailman/**listinfo/6tsch >>>> >>>> >>> ______________________________**_________________ >>> 6tsch mailing list >>> 6tsch@ietf.org >>> https://www.ietf.org/mailman/**listinfo/6tsch >>> >> >> ______________________________**_________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/**listinfo/6tsch >> > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > From pister@eecs.berkeley.edu Thu Jan 31 15:29:25 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2781E21F8896 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 15:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQVJhn4Qv-e5 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 15:29:24 -0800 (PST) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id AAB6621F84C9 for <6tsch@ietf.org>; Thu, 31 Jan 2013 15:29:24 -0800 (PST) Received: from dhcp-32-89.eecs.berkeley.edu ([128.32.32.89]) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:pister@eecs.berkeley.edu) (envelope-from ) id 1U13ZL-0005hy-FW; Thu, 31 Jan 2013 15:29:24 -0800 Message-ID: <510AFE56.5010401@eecs.berkeley.edu> Date: Thu, 31 Jan 2013 15:29:26 -0800 From: Kris Pister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Nick Moore , 6tsch@ietf.org References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> <510893A6.60506@zoic.org> <5109CC68.9090506@zoic.org> In-Reply-To: <5109CC68.9090506@zoic.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [6tsch] Welcome to the "6tsch" mailing list X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 23:29:25 -0000 I agree that both of those mechanisms of communicating to RPL have issues. However, an interface that exposes the underlying cell matrix (link schedule) and time base seems like a requirement in any case. One of the big benefits of tsch is the availability of a shared sense of time across the network. This has important benefits to applications (sequence of events detection, feedback control, global timestamps, ...) as well as security (replay, joining, broadcast authentication), and others. So for sure we need a mechanism where network time can be exposed to higher layers. We also need a mechanism to expose the schedule, because for many applications the higher layer is going to want to do something in relation to radio slot activity. For example, schedule a radar tank measurement at a time when there is no mote radio activity, or take a data sample right before a TX link to maximize freshness. How RPL or some other protocol makes use of these features is probably a long and polarizing discussion. If possible I'd like to define the mechanism for access to the information, but defer the details of policy for future IDs. ksjp On 1/30/2013 5:44 PM, Nick Moore wrote: > On 31/01/13 11:23, Thomas Watteyne wrote: >> Nick, >> That's quite some cross-layering! If I understand correctly, the >> metric could be function of how long until the next slot, i.e. if a >> slot to mote B is closer than mote C, then I will modify my routing >> metric to favor mote B. This would lead to very dynamic routing >> metrics, indeed. > > Yeah. So in this scenario the 6TSCH sub-layer is either: > > * Telling RPL "latency is 50ms. 40ms. 30ms. 20ms. 10ms. Boris, you > missed your train, now it is 100ms. 90ms ..." > * Telling RPL "latency is (t_0 - t) mod k ms, work it out for > yourself." (I think this is what Michael meant by "cyclic f(t)") > > My concern with the former is that it seems very chatty. How often is > too often? How often is often enough? > > My concern with the latter is that it seems rather a complicated thing > to add to RPL, especially when you've got multiple hops involved in a > route, with potentially different and varying slotframe periods. Any > comments from anyone with RPL (etc) implementation experience? > > My concern overall is excessively dynamic routing, indeed :-) Is it > sufficient for 6TSCH to tell RPL an *average* latency of slotframe > period / 2 and leave it at that? > > -----Nick From pister@eecs.berkeley.edu Thu Jan 31 15:31:27 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C98221F844A for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 15:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-2.501, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eL9IZfpsqTM1 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 15:31:26 -0800 (PST) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id B298821F842C for <6tsch@ietf.org>; Thu, 31 Jan 2013 15:31:22 -0800 (PST) Received: from dhcp-32-89.eecs.berkeley.edu ([128.32.32.89]) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:pister@eecs.berkeley.edu) (envelope-from ) id 1U13bF-0006vC-58 for 6tsch@ietf.org; Thu, 31 Jan 2013 15:31:22 -0800 Message-ID: <510AFECC.7090503@eecs.berkeley.edu> Date: Thu, 31 Jan 2013 15:31:24 -0800 From: Kris Pister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: 6tsch@ietf.org References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> <510893A6.60506@zoic.org> <5109CC68.9090506@zoic.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040006040904090901030903" Subject: Re: [6tsch] Welcome to the "6tsch" mailing list X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 23:31:27 -0000 This is a multi-part message in MIME format. --------------040006040904090901030903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit And let's not forget about power and energy. I'm sorry Dave, but I'm afraid that I can't do that right now. ksjp On 1/30/2013 5:54 PM, Thomas Watteyne wrote: > Nick, > > I would argue that 6tsch should deal with MAC layer specificities and > present an aggregate view to RPL. In TSCH, we're dealing with multiple > links to the same neighbor, which might be confusing for the routing > layer to deal with. On top of that, 6tsch might want to switch links > around, in which case maybe the metric really doesn't change from a > routing point of view. > > I believe that 6tsch can express both bandwidth and latency by looking > at the schedule and the per-link statistics. That is, bandwidth would > be something like the sum of links per slotframe, weighted by the ETX > on each link. This would represent "how many packet can I get to this > neighbor, per unit time", taking into account that there might be > multiple links, and lossy links. > > Taking it one step further, 6tsch could be instructed to maintain > 6pkt/s to neighbor A. If on average ETX to A is 50%, 6tsch will put in > 12 link/s. If something happens and the ETX now goes to 75%, 6tsch > could remove 2 links. All of that without requiring any intervention > from RPL, and without impact of the routing. > > Thomas > > On Wed, Jan 30, 2013 at 5:44 PM, Nick Moore > wrote: > > On 31/01/13 11:23, Thomas Watteyne wrote: > > Nick, > That's quite some cross-layering! If I understand correctly, > the metric could be function of how long until the next slot, > i.e. if a slot to mote B is closer than mote C, then I will > modify my routing metric to favor mote B. This would lead to > very dynamic routing metrics, indeed. > > > Yeah. So in this scenario the 6TSCH sub-layer is either: > > * Telling RPL "latency is 50ms. 40ms. 30ms. 20ms. 10ms. > Boris, you missed your train, now it is 100ms. 90ms ..." > * Telling RPL "latency is (t_0 - t) mod k ms, work it out for > yourself." (I think this is what Michael meant by "cyclic f(t)") > > My concern with the former is that it seems very chatty. How > often is too often? How often is often enough? > > My concern with the latter is that it seems rather a complicated > thing to add to RPL, especially when you've got multiple hops > involved in a route, with potentially different and varying > slotframe periods. Any comments from anyone with RPL (etc) > implementation experience? > > My concern overall is excessively dynamic routing, indeed :-) Is > it sufficient for 6TSCH to tell RPL an *average* latency of > slotframe period / 2 and leave it at that? > > > -----Nick > -- > Nick Moore > 0409 656 267 > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > > > > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch --------------040006040904090901030903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit And let's not forget about power and energy.

I'm sorry Dave, but I'm afraid that I can't do that right now.

ksjp

On 1/30/2013 5:54 PM, Thomas Watteyne wrote:

Nick,

I would argue that 6tsch should deal with MAC layer specificities and present an aggregate view to RPL. In TSCH, we're dealing with multiple links to the same neighbor, which might be confusing for the routing layer to deal with. On top of that, 6tsch might want to switch links around, in which case maybe the metric really doesn't change from a routing point of view.

I believe that 6tsch can express both bandwidth and latency by looking at the schedule and the per-link statistics. That is, bandwidth would be something like the sum of links per slotframe, weighted by the ETX on each link. This would represent "how many packet can I get to this neighbor, per unit time", taking into account that there might be multiple links, and lossy links.

Taking it one step further, 6tsch could be instructed to maintain 6pkt/s to neighbor A. If on average ETX to A is 50%, 6tsch will put in 12 link/s. If something happens and the ETX now goes to 75%, 6tsch could remove 2 links. All of that without requiring any intervention from RPL, and without impact of the routing.

Thomas

On Wed, Jan 30, 2013 at 5:44 PM, Nick Moore <nick@zoic.org> wrote:

On 31/01/13 11:23, Thomas Watteyne wrote:

Nick,
That's quite some cross-layering! If I understand correctly, the metric could be function of how long until the next slot, i.e. if a slot to mote B is closer than mote C, then I will modify my routing metric to favor mote B. This would lead to very dynamic routing metrics, indeed.

Yeah. So in this scenario the 6TSCH sub-layer is either:

* Telling RPL "latency is 50ms. 40ms. 30ms. 20ms. 10ms. Boris, you missed your train, now it is 100ms. 90ms ..."
* Telling RPL "latency is (t_0 - t) mod k ms, work it out for yourself." (I think this is what Michael meant by "cyclic f(t)")

My concern with the former is that it seems very chatty. How often is too often? How often is often enough?

My concern with the latter is that it seems rather a complicated thing to add to RPL, especially when you've got multiple hops involved in a route, with potentially different and varying slotframe periods. Any comments from anyone with RPL (etc) implementation experience?

My concern overall is excessively dynamic routing, indeed :-) Is it sufficient for 6TSCH to tell RPL an *average* latency of slotframe period / 2 and leave it at that?

-----Nick
--
Nick Moore <nick@zoic.org> 0409 656 267
_______________________________________________
6tsch mailing list
6tsch@ietf.org
https://www.ietf.org/mailman/listinfo/6tsch
_______________________________________________
6tsch mailing list
6tsch@ietf.org
https://www.ietf.org/mailman/listinfo/6tsch

--------------040006040904090901030903-- From robert.assimiti@nivis.com Thu Jan 31 15:41:19 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05A221F89C0 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 15:41:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eroKDrVAknCU for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 15:41:19 -0800 (PST) Received: from smtp.nivis.com (smtp.nivis.com [65.205.163.2]) by ietfa.amsl.com (Postfix) with ESMTP id DE67821F8441 for <6tsch@ietf.org>; Thu, 31 Jan 2013 15:41:18 -0800 (PST) Received: from ATLEXCH02.nivis.com ([10.0.0.18]) by ATLEXCH02.nivis.com ([10.0.0.18]) with mapi; Thu, 31 Jan 2013 18:41:18 -0500 From: Robert Assimiti To: "qinwang@berkeley.edu" , Nick Moore Date: Thu, 31 Jan 2013 18:41:16 -0500 Thread-Topic: [6tsch] Welcome to the "6tsch" mailing list Thread-Index: Ac3/MhfrgkDQAMxvTJWHKv6E+HqhCAA2EpKw Message-ID: <67442429D9C35E4C975B89BE73BD33D0963577207E@ATLEXCH02.nivis.com> References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> <510893A6.60506@zoic.org> <642eb7a76ca79076e97b391cc9aeabdf.squirrel@calmail.berkeley.edu> In-Reply-To: <642eb7a76ca79076e97b391cc9aeabdf.squirrel@calmail.berkeley.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "6tsch@ietf.org" <6tsch@ietf.org> Subject: Re: [6tsch] Welcome to the "6tsch" mailing list X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 23:41:20 -0000 Qin, Thanks for bringing up uRes. There are many out there that argue that TSCH = (and any other media allocation scheme that has TDNA based DNA) is not inhe= rently well suited for (mesh, multi-path) network that rely on distributed = routing decisions. They claim that TSCH can only be efficiently utilized in= highly deterministic systems in which a central computation engine (that i= ncludes a link scheduler) makes all the decisions in the network. The analo= gy used is one to Smart Objects being automatic pianos that play the music = sheet that this computation engine puts in front of them. In my experience, TSCH renders itself very well to a combination of both na= mely a central arbitration and distributed intelligence. The WLAN coordinat= or (which typically resides in the LBR) is responsible for setting up a ne= twork maintenance slotframe (used for enhanced beacons, etc). The Smart Obj= ect form/maintain/select the links locally. In terms of the interaction between TSCH and RPL there is little coordinati= on needed, since RPL does not need to be aware of the underlying TSCH sched= ule.=20 The coordination needed consists in (recommended, not mandatory): 1. Ensuring that the RPL DODAG parent is the current 802.15.4e coordinator = =20 2. Defining some sort of informative service access point that allows the M= AC to feed various metrics collected to RPL When we designed our RPL_over_TSCH Smart Object platform, we also identifie= d a need to define additional IEs (which is fully condoned and encouraged b= y 4e) that would allow TSCH Smart Objects to better coordinate and accommod= ate the MAC agnostic RPL layer. =20 Robert Assimiti Nivis Director of Technology and Standards Office [678]-202-6859 Mobile [404]-578-0205 -----Original Message----- From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of q= inwang@berkeley.edu Sent: Wednesday, January 30, 2013 4:38 PM To: Nick Moore Cc: 6tsch@ietf.org Subject: Re: [6tsch] Welcome to the "6tsch" mailing list Hi, As Thomas and Xavi explained, RPL is responsible for choosing a *Path*, i.e= . next hop neighbor, and asking TSCH to forward packets; and TSCH provides = a mechanism to use *Links* (neighbor, slot, channel, TX/RX), which is the m= apping of a *Path*, to conduct forwarding. Thus, the missing piece is how t= o establish and maintain the *Links*. My understanding is that 6tsch will = fill the gap. In addition, considering resource constraints of devices and = characteristics of IoT, 6tsch should be very simple and flexible for wide r= ange of application in terms of mobility, density, latency,and so on. In UC@Berkeley, we have designed a protocol, called uRes. The function of u= Res is to establish and maintain the *Links* with neighbors. uRes is a dist= ributed protocol, i.e. the computation and communication for link reservati= on just happen locally. uRes is coded in Information Elements (IEs) of IEEE802.15.4e, thus, just fits to TSCH and provides flexibility fo= r further optimization and extension. uRes has been implemented in OpenWSN = (openwsn.berkeley.edu). Regards Qin > On 30/01/13 07:04, Thomas Watteyne wrote: >> >> Maybe too much room to be handled entirely by RPL. As I see it, RPL=20 >> only wants to know about some cost associated with the topology, and=20 >> uses that to compute multi-hop routes. In particular, I believe RPL=20 >> is more interested in /paths/ (the "performance" of the connection=20 >> between two neighbors), rather than the individual /links /making up=20 >> each path. In my opinion (and this is, I believe, perfectly in line=20 >> with *Xavi*'s comment), we could define a /6tsch/ layer which sits=20 >> between TSCH and RPL. The goal of this layer would be to (1) turn=20 >> some throughput requirements into /links /in the schedule and (2)=20 >> collect information and feedback /path/ statistics to RPL. > [...] > >> To come back to *Michael*'s comment, I believe that, with this setup,=20 >> RPL actually can be using traditional metrics (ETX, bandwidth,=20 >> latency, etc), the /6tsch/ layer taking care of MAC specifics. >> > > Yep, that makes sense! And as per Michael's comments, RPL can then=20 > handle the routing across different L2s. > > > On 29/01/13 15:09, Michael Richardson wrote: >> I agree. It's just that this is a new kind of metric: in the past we=20 >> have things like abtracted ETX, bandwidth available, power, latency,=20 >> etc... none of these things are a cyclic f(t). This new info is. > > Is it appropriate for the 6tsch routing metrics to change (or as you=20 > put it, to be a cyclic function) *within* the period of a slotframe? > > For example, if node A is trying to transmit to node D and can go via=20 > either node B or node C, then the "best route" may toggle back and=20 > forth between B and C depending on which has the next available=20 > link(s), potentially multiple times per slotframe period. Is this=20 > good behaviour? I guess in the LoWPAN world it might be. > > > I think I'd better stop asking open-ended questions now and go read=20 > some stuff :-) > > -----Nick > > -- > Nick Moore 0409 656 267 > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch From robert.assimiti@nivis.com Thu Jan 31 15:46:58 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DDB21F84E8 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 15:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.052 X-Spam-Level: X-Spam-Status: No, score=0.052 tagged_above=-999 required=5 tests=[AWL=-2.350, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUxcRweIzgTf for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 15:46:57 -0800 (PST) Received: from smtp.nivis.com (smtp.nivis.com [65.205.163.2]) by ietfa.amsl.com (Postfix) with ESMTP id 97A2E21F8488 for <6tsch@ietf.org>; Thu, 31 Jan 2013 15:46:57 -0800 (PST) Received: from ATLEXCH02.nivis.com ([10.0.0.18]) by ATLEXCH02.nivis.com ([10.0.0.18]) with mapi; Thu, 31 Jan 2013 18:46:47 -0500 From: Robert Assimiti To: Thomas Watteyne , "6tsch@ietf.org" <6tsch@ietf.org> Date: Thu, 31 Jan 2013 18:46:45 -0500 Thread-Topic: [6tsch] Welcome to the "6tsch" mailing list Thread-Index: Ac3/VfmBcvKtq0XIR5aVjJeZSguhdwAtsVUA Message-ID: <67442429D9C35E4C975B89BE73BD33D0963577207F@ATLEXCH02.nivis.com> References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> <510893A6.60506@zoic.org> <5109CC68.9090506@zoic.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_67442429D9C35E4C975B89BE73BD33D0963577207FATLEXCH02nivi_" MIME-Version: 1.0 Subject: Re: [6tsch] Welcome to the "6tsch" mailing list X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 23:46:58 -0000 --_000_67442429D9C35E4C975B89BE73BD33D0963577207FATLEXCH02nivi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thomas, I full heartedly second everything that you stated. Robert From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of T= homas Watteyne Sent: Wednesday, January 30, 2013 8:55 PM To: 6tsch@ietf.org Subject: Re: [6tsch] Welcome to the "6tsch" mailing list Nick, I would argue that 6tsch should deal with MAC layer specificities and prese= nt an aggregate view to RPL. In TSCH, we're dealing with multiple links to = the same neighbor, which might be confusing for the routing layer to deal w= ith. On top of that, 6tsch might want to switch links around, in which case= maybe the metric really doesn't change from a routing point of view. I believe that 6tsch can express both bandwidth and latency by looking at t= he schedule and the per-link statistics. That is, bandwidth would be someth= ing like the sum of links per slotframe, weighted by the ETX on each link. = This would represent "how many packet can I get to this neighbor, per unit = time", taking into account that there might be multiple links, and lossy li= nks. Taking it one step further, 6tsch could be instructed to maintain 6pkt/s to= neighbor A. If on average ETX to A is 50%, 6tsch will put in 12 link/s. If= something happens and the ETX now goes to 75%, 6tsch could remove 2 links.= All of that without requiring any intervention from RPL, and without impac= t of the routing. Thomas On Wed, Jan 30, 2013 at 5:44 PM, Nick Moore > wrote: On 31/01/13 11:23, Thomas Watteyne wrote: Nick, That's quite some cross-layering! If I understand correctly, the metric cou= ld be function of how long until the next slot, i.e. if a slot to mote B is= closer than mote C, then I will modify my routing metric to favor mote B. = This would lead to very dynamic routing metrics, indeed. Yeah. So in this scenario the 6TSCH sub-layer is either: * Telling RPL "latency is 50ms. 40ms. 30ms. 20ms. 10ms. Boris, you mis= sed your train, now it is 100ms. 90ms ..." * Telling RPL "latency is (t_0 - t) mod k ms, work it out for yourself." (I= think this is what Michael meant by "cyclic f(t)") My concern with the former is that it seems very chatty. How often is too = often? How often is often enough? My concern with the latter is that it seems rather a complicated thing to a= dd to RPL, especially when you've got multiple hops involved in a route, wi= th potentially different and varying slotframe periods. Any comments from = anyone with RPL (etc) implementation experience? My concern overall is excessively dynamic routing, indeed :-) Is it suffic= ient for 6TSCH to tell RPL an *average* latency of slotframe period / 2 and= leave it at that? -----Nick -- Nick Moore > 0409 656 267 _______________________________________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch --_000_67442429D9C35E4C975B89BE73BD33D0963577207FATLEXCH02nivi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thomas,

I full= heartedly second everything that you stated.

Robert

From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces= @ietf.org] On Behalf Of Thomas Watteyne
Sent: Wednesday, J= anuary 30, 2013 8:55 PM
To: 6tsch@ietf.org
Subject: Re:= [6tsch] Welcome to the "6tsch" mailing list

Nick,=

I would argue that 6tsch should deal with MAC layer = ;specificities and present an aggregate view to RPL. In TSCH, we're de= aling with multiple links to the same neighbor, which might be confusing fo= r the routing layer to deal with. On top of that, 6tsch might want to switc= h links around, in which case maybe the metric really doesn't change from a= routing point of view.

I believe that 6tsch can ex= press both bandwidth and latency by looking at the schedule and the per-lin= k statistics. That is, bandwidth would be something like the sum of links p= er slotframe, weighted by the ETX on each link. This would represent "= how many packet can I get to this neighbor, per unit time", taking int= o account that there might be multiple links, and lossy links.

Taking it one step further, 6ts= ch could be instructed to maintain 6pkt/s to neighbor A. If on average ETX = to A is 50%, 6tsch will put in 12 link/s. If something happens and the ETX = now goes to 75%, 6tsch could remove 2 links. All of that without requiring = any intervention from RPL, and without impact of the routing.

Thomas=

On Wed, Jan 30, 2013 at 5:44 PM, N= ick Moore <nick@zoic.= org> wrote:

On 31/01/13 11:2= 3, Thomas Watteyne wrote:

Nick,
That'= s quite some cross-layering! If I understand correctly, the metric could be= function of how long until the next slot, i.e. if a slot to mote B is clos= er than mote C, then I will modify my routing metric to favor mote B. This = would lead to very dynamic routing metrics, indeed.

Yeah. So= in this scenario the 6TSCH sub-layer is either:

* Telling RPL "= ;latency is 50ms. 40ms. 30ms. 20ms. 10ms. Bor= is, you missed your train, now it is 100ms. 90ms ..."
* Telli= ng RPL "latency is (t_0 - t) mod k ms, work it out for yourself."= (I think this is what Michael meant by "cyclic f(t)")

My = concern with the former is that it seems very chatty. How often is to= o often? How often is often enough?

My concern with the latter= is that it seems rather a complicated thing to add to RPL, especially when= you've got multiple hops involved in a route, with potentially different a= nd varying slotframe periods. Any comments from anyone with RPL (etc)= implementation experience?

My concern overall is excessively dynami= c routing, indeed :-) Is it sufficient for 6TSCH to tell RPL an *aver= age* latency of slotframe period / 2 and leave it at that?

-----Nick
--
Nick Moore <nick@zoic.org> 0409 = 656 267
_______________________________________________
6tsch mailing= list
6tsch@ietf.org=
https://www.ietf.org/mailman/listinfo/6tsch

= --_000_67442429D9C35E4C975B89BE73BD33D0963577207FATLEXCH02nivi_-- From robert.assimiti@nivis.com Thu Jan 31 15:59:18 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87E9021F8886 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 15:59:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.665 X-Spam-Level: X-Spam-Status: No, score=-1.665 tagged_above=-999 required=5 tests=[AWL=0.934, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsiDEIOirmQQ for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 15:59:18 -0800 (PST) Received: from smtp.nivis.com (smtp.nivis.com [65.205.163.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4D621F84FB for <6tsch@ietf.org>; Thu, 31 Jan 2013 15:59:14 -0800 (PST) Received: from ATLEXCH02.nivis.com ([10.0.0.18]) by ATLEXCH02.nivis.com ([10.0.0.18]) with mapi; Thu, 31 Jan 2013 18:59:14 -0500 From: Robert Assimiti To: Nick Moore , IETF 6TSCH <6tsch@ietf.org> Date: Thu, 31 Jan 2013 18:59:12 -0500 Thread-Topic: [6tsch] Welcome to the "6tsch" mailing list Thread-Index: Ac3/e/OlCO+x5ObIS9emOHhXZC/FQwAkXMnQ Message-ID: <67442429D9C35E4C975B89BE73BD33D09635772081@ATLEXCH02.nivis.com> References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> <510893A6.60506@zoic.org> <5109CC68.9090506@zoic.org> <53F3B30A-12C6-4D0F-8C47-D6C5BA37DB3A@zoic.org> In-Reply-To: <53F3B30A-12C6-4D0F-8C47-D6C5BA37DB3A@zoic.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [6tsch] Welcome to the "6tsch" mailing list X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 23:59:18 -0000 This is where dedicated and shared slots come into play at the TSCH. In TSCH, all slots and are links are created equal. One could devise a sche= me where slots could be shared or dedicated. Dedicated slots could also be = prioritized. These would allow a 6TSCHbis device to be able to guarantee latencies. Robert Assimiti -----Original Message----- From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of N= ick Moore Sent: Thursday, January 31, 2013 1:27 AM To: IETF 6TSCH Subject: Re: [6tsch] Welcome to the "6tsch" mailing list Thomas Watteyne wrote: > I would argue that 6tsch should deal with MAC layer specificities and pre= sent an aggregate view to RPL. I think that makes sense as an initial goal at least. If some brave soul manages to work out a more sophisticated version that al= lows for the cyclic nature of TSCH latency they can always call it 6TSCHbis= (pronounce *that*!) -- Nick Moore (+61) 409 656 267 ____________________________= ___________________ 6tsch mailing list 6tsch@ietf.org https://www.ietf.org/mailman/listinfo/6tsch From nick@zoic.org Thu Jan 31 16:22:30 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB9521F8916 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 16:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDwf-YByp3nE for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 16:22:30 -0800 (PST) Received: from mercury.zoic.org (mercury.zoic.org [50.19.98.71]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8E221F88ED for <6tsch@ietf.org>; Thu, 31 Jan 2013 16:22:30 -0800 (PST) Received: from [10.107.2.2] (cthulhu.zoic.org [180.94.115.42]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nick) by mercury.zoic.org (Postfix) with ESMTPSA id 4ADDB81C51 for <6tsch@ietf.org>; Fri, 1 Feb 2013 00:19:39 +0000 (UTC) Message-ID: <510B0AC1.60103@zoic.org> Date: Fri, 01 Feb 2013 11:22:25 +1100 From: Nick Moore User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: 6tsch@ietf.org References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> <510893A6.60506@zoic.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6tsch] 6tsch status ... X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 00:22:30 -0000 On 01/02/13 03:52, Abdussalam Baryun wrote: > Could some one refer me to an initial draft submitted if available for > this group? to make group ideas and basis for discussions, I think this is more of a virtual BOF so far, and we're still trying to work out the scope of the proposed WG. Anyone here got any further documents to put on the table? (I'm paraphrasing several very long, detailed and interesting posts here, probably inaccurately, so with apologies to the authors ...) The main divide in the conversation so far seems to be whether 6TSCH is: a) a "shim" between RPL and 4e's TSCH, requiring no mods to RPL but only able to express the "aggregate" behaviour of a link across the entire slotframe. or b) an extension to RPL to make it TSCH aware, allowing for fine control of latencies within slotframes. Also, a couple of people have brought up protocols building TSCH networks, do we think this is in scope for 6TSCH or is 6TSCH only concerned with passively optimizing for the networks built by these protocols? -----Nick -- Nick Moore 0409 656 267 From nick@zoic.org Thu Jan 31 16:23:26 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4691421F8971 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 16:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+oWl8uwqCeE for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 16:23:26 -0800 (PST) Received: from mercury.zoic.org (mercury.zoic.org [50.19.98.71]) by ietfa.amsl.com (Postfix) with ESMTP id D368421F896B for <6tsch@ietf.org>; Thu, 31 Jan 2013 16:23:25 -0800 (PST) Received: from [10.107.2.2] (cthulhu.zoic.org [180.94.115.42]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nick) by mercury.zoic.org (Postfix) with ESMTPSA id 4709E81C5D for <6tsch@ietf.org>; Fri, 1 Feb 2013 00:20:36 +0000 (UTC) Message-ID: <510B0AFB.9080506@zoic.org> Date: Fri, 01 Feb 2013 11:23:23 +1100 From: Nick Moore User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: 6tsch@ietf.org References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> <510893A6.60506@zoic.org> <5109CC68.9090506@zoic.org> <510AFE56.5010401@eecs.berkeley.edu> In-Reply-To: <510AFE56.5010401@eecs.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [6tsch] Exposing network time (etc) to higher layers. X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 00:23:26 -0000 On 01/02/13 10:29, Kris Pister wrote: > So for sure we need a mechanism where network time can be exposed to > higher layers. Hey, that's a really interesting thought, especially given the drifty nature of mote clocks. -----Nick -- Nick Moore 0409 656 267 From xvilajosana@eecs.berkeley.edu Thu Jan 31 16:28:41 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1C521F8A00 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 16:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.348 X-Spam-Level: X-Spam-Status: No, score=-5.348 tagged_above=-999 required=5 tests=[AWL=1.251, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJZwAJBm5IzI for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 16:28:40 -0800 (PST) Received: from cm04fe.IST.Berkeley.EDU (cm04fe.IST.Berkeley.EDU [169.229.218.145]) by ietfa.amsl.com (Postfix) with ESMTP id E9BD221F89F9 for <6tsch@ietf.org>; Thu, 31 Jan 2013 16:28:40 -0800 (PST) Received: from dhcp-33-135.eecs.berkeley.edu ([128.32.33.135]) by cm04fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:xvilajosana@eecs.berkeley.edu) (envelope-from ) id 1U14Uh-0000Sn-FZ for 6tsch@ietf.org; Thu, 31 Jan 2013 16:28:40 -0800 Message-ID: <510B0C36.5060307@eecs.berkeley.edu> Date: Thu, 31 Jan 2013 16:28:38 -0800 From: Xavier Vilajosana User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: 6tsch@ietf.org References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> <510893A6.60506@zoic.org> <5109CC68.9090506@zoic.org> <510AFE56.5010401@eecs.berkeley.edu> <510B0AFB.9080506@zoic.org> In-Reply-To: <510B0AFB.9080506@zoic.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [6tsch] Exposing network time (etc) to higher layers. X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 00:28:41 -0000 Motes keep aligned with guard times smaller than 1ms, also motes share the global ASN, with that in mind, would not be difficult to expose network time. Time accuracy might then depended on the energy constraints of the networks. As more tight synchronization more packets on the air. X. On 31/01/13 16:23, Nick Moore wrote: > On 01/02/13 10:29, Kris Pister wrote: >> So for sure we need a mechanism where network time can be exposed to >> higher layers. > > Hey, that's a really interesting thought, especially given the drifty > nature of mote clocks. > > -----Nick > From pister@eecs.berkeley.edu Thu Jan 31 16:30:55 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64AE321F8A09 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 16:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ggx8e3TFTaVH for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 16:30:54 -0800 (PST) Received: from cm01fe.IST.Berkeley.EDU (cm01fe.IST.Berkeley.EDU [169.229.218.142]) by ietfa.amsl.com (Postfix) with ESMTP id DADD821F89F9 for <6tsch@ietf.org>; Thu, 31 Jan 2013 16:30:54 -0800 (PST) Received: from dhcp-32-89.eecs.berkeley.edu ([128.32.32.89]) by cm01fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth plain:pister@eecs.berkeley.edu) (envelope-from ) id 1U14Wq-0000gL-57 for 6tsch@ietf.org; Thu, 31 Jan 2013 16:30:54 -0800 Message-ID: <510B0CBF.4090500@eecs.berkeley.edu> Date: Thu, 31 Jan 2013 16:30:55 -0800 From: Kris Pister User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: 6tsch@ietf.org References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> <510893A6.60506@zoic.org> <5109CC68.9090506@zoic.org> <53F3B30A-12C6-4D0F-8C47-D6C5BA37DB3A@zoic.org> <67442429D9C35E4C975B89BE73BD33D09635772081@ATLEXCH02.nivis.com> In-Reply-To: <67442429D9C35E4C975B89BE73BD33D09635772081@ATLEXCH02.nivis.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [6tsch] Welcome to the "6tsch" mailing list X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 00:30:55 -0000 Agree. My hope is that we define a very simple shared slot system for network joining, and then define the mechanism for adding additional links, be they shared or dedicated. Once we have that in place it will be easy for people to get networks up and running, and also easy to try out new ideas for optimizing performance. The advertising information element contains a superframe length, and a small number (one?) of shared links. This provides a duty-cycled slotted-aloha MAC, with a duty cycle controlled by the choice of superframe length. For some applications this is all they need. One slot every 100ms gets you a few percent duty cycle and sub-second multi-hop response time in low-traffic networks. DIOs, DAOs, RAs, etc. all use the shared bandwidth. With that as initial synchronization and discovery, then very fancy things can be built on top, either with distributed, centralized, or (for me ideally) hybrid approaches, with either dedicated, shared, or mixed links. Such a big playground! ksjp On 1/31/2013 3:59 PM, Robert Assimiti wrote: > This is where dedicated and shared slots come into play at the TSCH. > > In TSCH, all slots and are links are created equal. One could devise a scheme where slots could be shared or dedicated. Dedicated slots could also be prioritized. > > These would allow a 6TSCHbis device to be able to guarantee latencies. > > Robert Assimiti > > -----Original Message----- > From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of Nick Moore > Sent: Thursday, January 31, 2013 1:27 AM > To: IETF 6TSCH > Subject: Re: [6tsch] Welcome to the "6tsch" mailing list > > Thomas Watteyne wrote: > >> I would argue that 6tsch should deal with MAC layer specificities and present an aggregate view to RPL. > I think that makes sense as an initial goal at least. > > If some brave soul manages to work out a more sophisticated version that allows for the cyclic nature of TSCH latency they can always call it 6TSCHbis (pronounce *that*!) > > -- > Nick Moore (+61) 409 656 267 _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch From twatteyne@gmail.com Thu Jan 31 17:50:03 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552EF21F884A for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 17:50:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQxx+rZBmv4b for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 17:50:02 -0800 (PST) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id C23BF21F8840 for <6tsch@ietf.org>; Thu, 31 Jan 2013 17:50:02 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id un15so1910703pbc.10 for <6tsch@ietf.org>; Thu, 31 Jan 2013 17:50:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=8NN8Bk0M6/uRsO61UIQCnDcd3v4IsD7xDlB/6hhNTzY=; b=O5NPSPnhYRRSN9S4ooi6Dg0w3haVmbggWgCiGxfoQ2GDsL/O8HePcKLsQBKP2ub+QI flKdifkvBRbCQVmHyqVtFSEBuFKEAFPPs57kFOT6hEXXFmPpzfRZ+FWcIrGTxd2kJa9X OtE4wzW2fkwIatn/es40mlJ8XYFi3tpQQxvThoyJ/DfMik411Ph9ojjIGY8O2N4PpJ2L /rCZStsZxbkCORkLqsQQdFUJXgeURXhJl7cgUhk8M7YtzuKSF9E8+jVpXP0gY93yz9ge kTYy0FGfaXrCXX2mWnLqpwJo7A4cQhyrJQoBYMDWaAF6pIwFSNptyEIwozjmbhmsF/Ai Qktw== MIME-Version: 1.0 X-Received: by 10.68.224.165 with SMTP id rd5mr27999004pbc.49.1359683402477; Thu, 31 Jan 2013 17:50:02 -0800 (PST) Sender: twatteyne@gmail.com Received: by 10.66.121.33 with HTTP; Thu, 31 Jan 2013 17:50:02 -0800 (PST) In-Reply-To: <510B0C36.5060307@eecs.berkeley.edu> References: <6867.1359070318@sandelman.ca> <28723.1359138027@sandelman.ca> <5107381E.6000108@zoic.org> <3072.1359432324@sandelman.ca> <51076FAA.6030509@zoic.org> <20253.1359468324@sandelman.ca> <510893A6.60506@zoic.org> <5109CC68.9090506@zoic.org> <510AFE56.5010401@eecs.berkeley.edu> <510B0AFB.9080506@zoic.org> <510B0C36.5060307@eecs.berkeley.edu> Date: Thu, 31 Jan 2013 17:50:02 -0800 X-Google-Sender-Auth: 0SgXUAXvSANeC3yw4DqbOOl2-QY Message-ID: From: Thomas Watteyne To: IETF 6TSCH <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=e89a8ff253c436306304d49ff625 Subject: Re: [6tsch] Exposing network time (etc) to higher layers. X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 01:50:03 -0000 --e89a8ff253c436306304d49ff625 Content-Type: text/plain; charset=ISO-8859-1 Agreed. TSCH is built to compensate for clock drift by using all (incl. data) packets to re-synchronize, and send keep-alive packets when not enough data packets are sent to satisfy a "good enough" synchronization. You can get the motes in your network synchronized within 10's of us. In fact, the better synchronized, the less long you have to listen for a packet (since you always have to listen early in case your neighbor mote drifted), so tight synchronization is a power *benefit*, not a power cost. As pointed out by Kris, this becomes really interesting for the application to timestamp its payload. Are you thinking of any particular use of tight synchronization by the routing layer? On Thu, Jan 31, 2013 at 4:28 PM, Xavier Vilajosana < xvilajosana@eecs.berkeley.edu> wrote: > Motes keep aligned with guard times smaller than 1ms, also motes share the > global ASN, with that in mind, would not be difficult to expose network > time. Time accuracy might then depended on the energy constraints of the > networks. As more tight synchronization more packets on the air. > > X. > > > > On 31/01/13 16:23, Nick Moore wrote: > >> On 01/02/13 10:29, Kris Pister wrote: >> >>> So for sure we need a mechanism where network time can be exposed to >>> higher layers. >>> >> >> Hey, that's a really interesting thought, especially given the drifty >> nature of mote clocks. >> >> -----Nick >> >> > ______________________________**_________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/**listinfo/6tsch > --e89a8ff253c436306304d49ff625 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Agreed. TSCH is built to compensate for clock drift by using all (incl. dat= a) packets to re-synchronize, and send keep-alive packets when not enough d= ata packets are sent to satisfy a "good enough" synchronization. = You can get the motes in your network synchronized within 10's of us. I= n fact, the better synchronized, the less long you have to listen for a pac= ket (since you always have to listen early in case your neighbor mote drift= ed), so tight synchronization is a power *benefit*, not a power cost.

As pointed out by Kris, this becomes really interesting for = the application to timestamp its payload. Are you thinking of any particula= r use of tight synchronization by the routing layer?

On Thu, Jan 31, 2013 at 4:28 PM, Xavier= Vilajosana <xvilajosana@eecs.berkeley.edu> wrot= e:

Motes keep aligned with guard times smaller = than 1ms, also motes share the global ASN, with that in mind, would not be = difficult to expose network time. Time accuracy might then depended on the = energy constraints of the networks. As more tight synchronization more pack= ets on the air.

X.

On 31/01/13 16:23, Nick Moore wrote:

On 01/02/13 10:29, Kris Pister wrote:

So for sure we need a mechanism where network time can be exposed to higher= layers.

Hey, that's a really interesting thought, especially given the drifty n= ature of mote clocks.

-----Nick

_______________________________________________
6tsch mailing list
6tsch@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/6tsch

--e89a8ff253c436306304d49ff625-- From pascal.thubert@gmail.com Thu Jan 31 23:15:06 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C707521F88BC for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 23:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okevtO5FjiN8 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 23:15:06 -0800 (PST) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id B456F21F88C8 for <6tsch@ietf.org>; Thu, 31 Jan 2013 23:15:05 -0800 (PST) Received: by mail-la0-f54.google.com with SMTP id gw10so2579635lab.27 for <6tsch@ietf.org>; Thu, 31 Jan 2013 23:15:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=gPBDVufqPztarJqWYLaYAaIIpozD7UZWxZvi7T7cqBs=; b=zvtSN5Pc4tH2sqCdSdWrHtKBPurN59m6y2XvrvipV5F73ZdH1p+ajvg6ttAmj+xtvy lnk38L2AiaJJHSaqIMrvwbNxR/DCvZgUqYBl+O7o4LqHS0e+NQFEN/7oH1RlvrBJkgtS TYyucZai+v/5APnkCtz5SiDmEZth8JS1759+QIGlBMlrLf7LtqsRLLLGBSAKvliYAUUa yI+LPiperkZjdqh6pa2dDa7Tt1CGsGEUoNxbBPEHPiITVV7x4/Hx9K/NNPZPzUpbdNc6 fKTY8R+gk2+6YH5JQMgfXjtAoDa0b5zBLQOKYVfNKiRKn4hnj7M/8yOAvwN8OR4HCKVY kLeg== MIME-Version: 1.0 X-Received: by 10.112.44.161 with SMTP id f1mr4334310lbm.29.1359702904610; Thu, 31 Jan 2013 23:15:04 -0800 (PST) Received: by 10.112.27.40 with HTTP; Thu, 31 Jan 2013 23:15:04 -0800 (PST) Date: Fri, 1 Feb 2013 08:15:04 +0100 Message-ID: From: Pascal Thubert To: IETF 6TSCH <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=bcaec554d1fea1213204d4a48053 Subject: [6tsch] Dynamic Channel Allocation X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 07:15:06 -0000 --bcaec554d1fea1213204d4a48053 Content-Type: text/plain; charset=ISO-8859-1 Hi: When talking of radio links, there is sort of chicken and an egg problem between routing and peering selection / link bandwidth allocation. If we do not set up a adjacency with a neighbor, then routing cannot use that neighbor in the route computation and we will never know how much traffic would pass between hte 2 in an optimal world.OTOH, we cannot physically allocate stuff at the link level for all possible peers either. One way of running around that problem is to virtualize the links so that the router thinks there is bandwidth, even though potentially no slot is physically allocated. And then, we need to be able to allocate more and more slots to a particular neighbor as the routing drives more and more traffic through that peering. RPL makes life a lot easier, because it enables a selection of parent/children that limits the number of initial peering, and thus of slots to be allocated. Still, I can see the need of a virtualization of the available bandwidth for consumption by the routing piece, and a Dynamic Channel Allocation mechanism triggered the forwarding piece - or some reservation mechanism should we put something like that in place for a few particular flows. As the size of the network grows, and the number of usages grow beyond critical command and control, link utilization becomes statistical, and an exagerated use of (centrally controlled) reservation depletes the available resources much faster than they are actually used. Link utilization is better observed and managed by the local device in a reactive fashion. This is another argument along the lines that Mischa, Robert and Thomas discussed earlier that we want a distributed mechanism for the bulk of the operations. The shim layer that was already discussed has a lot of value to enable that virtualization and dynamic allocation. On principle I'm all for it. I'm just unclear how much of it is above IP (like we placed ND above IP as opposed to ARP) and how mush is under IP, the the 15.4 IEs. Could there be an IP abstraction that we could reuse in other similar link layers? --bcaec554d1fea1213204d4a48053 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi:

When talking of radio links, there is sort of chicken and an egg= problem between routing and peering selection / link bandwidth allocation.=

If we do not set up a adjacency with a neighbor, then routing cann= ot use that neighbor in the route computation and we will never know how mu= ch traffic would pass between hte 2 in an optimal world.OTOH, we cannot phy= sically allocate stuff at the link level for all possible peers either.

One way of running around that problem is to=A0 virtualize the links so= that the router thinks there is bandwidth, even though potentially no slot= is physically allocated. And then, we need to be able to allocate more and= more slots to a particular neighbor as the routing drives more and more tr= affic through that peering.

RPL makes life a lot easier, because it enables a selection of parent/c= hildren that limits the number of initial peering, and thus of slots to be = allocated. Still, I can see the need of a virtualization of the available b= andwidth for consumption by the routing piece, and a Dynamic Channel Alloca= tion mechanism triggered the forwarding piece - or some reservation mechani= sm should we put something like that in place for a few particular flows.
As the size of the network grows, and the number of usages grow beyond = critical command and control, link utilization becomes statistical, and an = exagerated use of (centrally controlled) reservation depletes the available= resources much faster than they are actually used. Link utilization is bet= ter observed and managed by the local device in a reactive fashion. This is= another argument along the lines that Mischa, Robert and Thomas discussed = earlier that we want a distributed mechanism for the bulk of the operations= .

The shim layer that was already discussed has a lot of value to enable = that virtualization and dynamic allocation. On principle I'm all for it= . I'm just unclear how much of it is above IP (like we placed ND above = IP as opposed to ARP) and how mush is under IP, the the 15.4 IEs. Could the= re be an IP abstraction that we could reuse in other similar link layers?

--bcaec554d1fea1213204d4a48053-- From pascal.thubert@gmail.com Thu Jan 31 23:53:25 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB7F21F8804 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 23:53:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.799, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iqxz+kf3KKC for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 23:53:23 -0800 (PST) Received: from mail-lb0-f178.google.com (mail-lb0-f178.google.com [209.85.217.178]) by ietfa.amsl.com (Postfix) with ESMTP id DFA2921F8550 for <6tsch@ietf.org>; Thu, 31 Jan 2013 23:53:22 -0800 (PST) Received: by mail-lb0-f178.google.com with SMTP id n1so4288520lba.37 for <6tsch@ietf.org>; Thu, 31 Jan 2013 23:53:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=Omd91RHasRpKLWKguQg7EBTSglm3RF6MWjOdhc0pQx4=; b=J2UpBFiyiWY7lSgUar17ZyPlBlk/CNZ/OzeCPysTvWwfvcgNBIXcOIz9YS0xK8aJJG i7/+Og/7iLEsTeTZnKPlyz8Aw+e3ueoA0fQXjgXYGtZ1bz1h4UezABWfXq7WDKHHltMS O1eZcsELVewl8Gg/zbgzFgRfA0Oa+2CbaNh53TtJO6Aq01w8uDtKH/Sb+CO4yXlyVmTC e+35KwKCl4NCAZ63gWEU/TeGxi28P/J8rwLYUO1J1oWi+4q7BXJ6T9V53IsKUm+OKNIB x4eA8jqM9psCZr2GxsUA2UKI8nWWR7uPBOIkFgjj3y/UlNlvZmZ3UJTmQniUfKZz4Rfo 460A== MIME-Version: 1.0 X-Received: by 10.152.147.103 with SMTP id tj7mr10391538lab.54.1359705201811; Thu, 31 Jan 2013 23:53:21 -0800 (PST) Received: by 10.112.27.40 with HTTP; Thu, 31 Jan 2013 23:53:21 -0800 (PST) Date: Fri, 1 Feb 2013 08:53:21 +0100 Message-ID: From: Pascal Thubert To: IETF 6TSCH <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=e89a8f234d2b8d9fdb04d4a509b7 Subject: [6tsch] green light analogy X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 07:53:25 -0000 --e89a8f234d2b8d9fdb04d4a509b7 Content-Type: text/plain; charset=ISO-8859-1 Hi: For what it's worth, I've been using the analogy of a city and green/red lights to describe 6TSCH outside. Considering the city as a system of green lights: 1) The minimum coordination happens between the lights of intersecting streets. That minimum coordination is often the best can do but yields a low (car) throughput on crowded avenues. As Robert indicated, it seems to make sense that the coordinator is the RPL parent. 2) When main avenues are clearly identified, cities have found ways to arrange the schedules of the green lights so that cars running at an expected speed do not need to stop for a number of lights in a row. RPL optimizes for P2MP / MP2P, so as to while preserving a controlled latency. For instance we may be able to organize sequences of time slots to / from the root, with a concentration as we reach the root in order to address statistical multiplexingy. 3) And then there are (exceptional) police and firemen cars that take over regardless of what the allocation is. In that dynamic case (analogous to alarms and alerts), the police cars and firemen trucks will pass even if they do not have the green lights. It's not only QoS, but also the fact that the next hop for that priority packet must be listening at a given time slot that was not necessarily for him in normal conditions. ISA100 can achieve something like that with multiple prioritized superframes. What exactly can we do with 4e? 4) And then there are (very exceptional) official cars that will never need to stop. Analogous to the scheduled world of command and control, some external grand master will arrange in advance that a an official convoy will get all the green lights along its path. In a mostly distributed world the Path Computing Engine can hardly have visibility on all the real (and probably quite dynamic) channel allocations. So how can we handle this? Black list some slots and let the PCE have full control on that limited number of slots? Let the PCE play blindly and make room for what it has computed? Or simply use some RSVP like technique whereby the PCE computes the path but does not see the channels any better than RPL does? In that case a source-routed reservation message could allocate channels on its way in a still distributed fashion. Thoughts? -- Pascal --e89a8f234d2b8d9fdb04d4a509b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi:

For what it's worth,=A0 I've been using the analogy of a= city and green/red lights to describe 6TSCH outside. Considering the city = as a system of green lights:

1) The minimum coordination happens bet= ween the lights of intersecting streets. That minimum coordination is often= the best can do but yields a low (car) throughput on crowded avenues. As R= obert indicated, it seems to make sense that the coordinator is the RPL par= ent.

2) When main avenues are clearly identified, cities have found ways to = arrange the schedules of the green lights so that cars running at an expect= ed speed do not need to stop for a number of lights in a row. RPL optimizes= for P2MP / MP2P, so as to=A0 while preserving a controlled latency. For in= stance we may be able to organize sequences of time slots to / from the roo= t, with a concentration as we reach the root in order to address statistica= l multiplexingy.

3) And then there are (exceptional) police and=20 firemen cars that take over regardless of what the allocation is. In that d= ynamic case (analogous to alarms and alerts), the=20 police cars and firemen trucks will pass even if they do not have the=20 green lights. It's not only QoS, but also the fact that the next hop fo= r that priority packet must be listening at a given time slot that was not = necessarily for him in normal conditions. ISA100 can achieve something like= that with multiple prioritized superframes. What exactly can we do with 4e= ?

4) And then there are (very exceptional) official cars that will never = need to stop. Analogous to the=20 scheduled world of command and control, some external grand master will=20 arrange in advance that a an official convoy will get all the green=20 lights along its path. In a mostly distributed world the Path Computing Eng= ine can hardly have visibility on all the real (and probably quite dynamic)= channel allocations. So how can we handle this? Black list some slots and = let the PCE have full control on that limited number of slots? Let the PCE = play blindly and make room for what it has computed? Or simply use some RSV= P like technique whereby the PCE computes the path but does not see the cha= nnels any better than RPL does? In that case a source-routed reservation me= ssage could allocate channels on its way in a still distributed fashion.
Thoughts?

--
Pascal --e89a8f234d2b8d9fdb04d4a509b7-- From twatteyne@gmail.com Thu Jan 31 23:53:50 2013 Return-Path: X-Original-To: 6tsch@ietfa.amsl.com Delivered-To: 6tsch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7E821F8828 for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 23:53:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.07 X-Spam-Level: X-Spam-Status: No, score=-2.07 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fz+NeqQVIKRz for <6tsch@ietfa.amsl.com>; Thu, 31 Jan 2013 23:53:49 -0800 (PST) Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by ietfa.amsl.com (Postfix) with ESMTP id 283B121F8804 for <6tsch@ietf.org>; Thu, 31 Jan 2013 23:53:49 -0800 (PST) Received: by mail-pa0-f47.google.com with SMTP id bj3so1004052pad.20 for <6tsch@ietf.org>; Thu, 31 Jan 2013 23:53:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=m94BKd8bTJKo1/m+bFFyRr8UDMW340LngO/j7WBfzQA=; b=eIAtHCyI7XEbPWLi0BTnxrN5WG439upOPYafAKLSqYJeVpweTdQotRc4IF84LaThS7 UjdZUu2wvUr8bkAoAdQwBBiCYiffADuYPwHMgbjoW/Pxcvl8nGFCNWXjGv/Mf+839w/M sdOYucrD60r4n192/QllN1TjP11Ul451AnNYYdLX5QRUdJ9y9BRAnVMncZWNfkt+E/Ba bgdYUbeG7tSicEQjOnbeVbT79DReTsEdibE83AzMS8RObRSUxArOHSYGZvU3gBoK/QN0 g/AN7TzBbdOmawvmdYbpkxW6mY9OA6uOeFYwnCuXPVBGWX1l0dm05DOALQs8zXlUNOjd 4lNw== MIME-Version: 1.0 X-Received: by 10.66.85.101 with SMTP id g5mr27700650paz.17.1359705228857; Thu, 31 Jan 2013 23:53:48 -0800 (PST) Sender: twatteyne@gmail.com Received: by 10.66.121.33 with HTTP; Thu, 31 Jan 2013 23:53:48 -0800 (PST) In-Reply-To: References: Date: Thu, 31 Jan 2013 23:53:48 -0800 X-Google-Sender-Auth: lgEBIUIjNXn_9e43mhDs_QNQ0c0 Message-ID: From: Thomas Watteyne To: IETF 6TSCH <6tsch@ietf.org> Content-Type: multipart/alternative; boundary=f46d042ef5492a534004d4a50b50 Subject: Re: [6tsch] Dynamic Channel Allocation X-BeenThere: 6tsch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 07:53:50 -0000 --f46d042ef5492a534004d4a50b50 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pascal, A couple of thoughts inline. Thomas On Thu, Jan 31, 2013 at 11:15 PM, Pascal Thubert wrote: > Hi: > > When talking of radio links, there is sort of chicken and an egg problem > between routing and peering selection / link bandwidth allocation. > > If we do not set up a adjacency with a neighbor, then routing cannot use > that neighbor in the route computation and we will never know how much > traffic would pass between hte 2 in an optimal world.OTOH, we cannot > physically allocate stuff at the link level for all possible peers either= . > > One way of running around that problem is to virtualize the links so tha= t > the router thinks there is bandwidth, even though potentially no slot is > physically allocated. And then, we need to be able to allocate more and > more slots to a particular neighbor as the routing drives more and more > traffic through that peering. > The chicken and egg problem is indeed a real complexity: how to manage the feedback loop between changing the schedule and changing the routes. To borrow some ideas from Kris, 15.4e includes the notion of shared (i.e. slotted Aloha) slots: the network could bootstrap with only a couple of shared slots, offering the possibility for a mote to communicate with any of its neighbors. This base enables some control traffic to be exchanged to set up dedicated slots. The simplest possible case could be to run on shared slots only. This is what we did about a year of so ago during an IPSO interop event. > RPL makes life a lot easier, because it enables a selection of > parent/children that limits the number of initial peering, and thus of > slots to be allocated. Still, I can see the need of a virtualization of t= he > available bandwidth for consumption by the routing piece, and a Dynamic > Channel Allocation mechanism triggered the forwarding piece - or some > reservation mechanism should we put something like that in place for a fe= w > particular flows. > > As the size of the network grows, and the number of usages grow beyond > critical command and control, link utilization becomes statistical, and a= n > exagerated use of (centrally controlled) reservation depletes the availab= le > resources much faster than they are actually used. Link utilization is > better observed and managed by the local device in a reactive fashion. Th= is > is another argument along the lines that Mischa, Robert and Thomas > discussed earlier that we want a distributed mechanism for the bulk of th= e > operations. > > The shim layer that was already discussed has a lot of value to enable > that virtualization and dynamic allocation. On principle I'm all for it. > I'm just unclear how much of it is above IP (like we placed ND above IP a= s > opposed to ARP) and how mush is under IP, the the 15.4 IEs. Could there b= e > an IP abstraction that we could reuse in other similar link layers? > > Could we borrow some ideas from traditional Internet resource management systems? In the end, 15.4e does give us a very straightforward unit of bandwidth (slots) and a stable topology (thanks to channel hopping). The shim layer could sit right on top of 15.4e, and receive request to add/remove links. The "brains" that give the orders could be many things: some traffic observation unit inside the mote, a centralized scheduling engine (=E0 la TASA), or some distributed resource reservation mechanism su= ch as RSVP. The interface to the shim layer could be keps extremely simple: - "add/remove this particular slot". This could be used by some omniscient central scheduler which builds a highly optimized schedule, or - "always maintain 3 slots per second to this neighbor". This could be used by some more distributed scheduling entity (e.g. RSVP?). It's then the shim layer's responsibility to put in the slots needed to meet that requirement. > > > > > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch > > --f46d042ef5492a534004d4a50b50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Pascal,

A couple of thoughts inline.

Thomas

On Thu, Jan 31, 2013 at 11:15 PM, Pascal Thubert <= pascal.thubert@gmail.com> wrote:

Hi:

When talking of radio links, ther= e is sort of chicken and an egg problem between routing and peering selecti= on / link bandwidth allocation.

If we do not set up a adjacency with a neighbor, then routing cannot us= e that neighbor in the route computation and we will never know how much tr= affic would pass between hte 2 in an optimal world.OTOH, we cannot physical= ly allocate stuff at the link level for all possible peers either.

One way of running around that problem is to=A0 virtualize the links so= that the router thinks there is bandwidth, even though potentially no slot= is physically allocated. And then, we need to be able to allocate more and= more slots to a particular neighbor as the routing drives more and more tr= affic through that peering.

The chicken and egg problem is indeed a re= al complexity: how to manage the feedback loop between changing the schedul= e and changing the routes. To borrow some ideas from Kris, 15.4e includes t= he notion of shared (i.e. slotted Aloha) slots: the network could bootstrap= with only a couple of shared slots, offering the possibility for a mote to= communicate with any of its neighbors. This base enables some control traf= fic to be exchanged to set up dedicated slots.

The simplest possible case could be to run on shared sl= ots only. This is what we did about a year of so ago during an IPSO interop= event.

=A0

RPL makes life a lot easier, because it enables a selection of parent/child= ren that limits the number of initial peering, and thus of slots to be allo= cated. Still, I can see the need of a virtualization of the available bandw= idth for consumption by the routing piece, and a Dynamic Channel Allocation= mechanism triggered the forwarding piece - or some reservation mechanism s= hould we put something like that in place for a few particular flows.

As the size of the network grows, and the number of usages grow beyond = critical command and control, link utilization becomes statistical, and an = exagerated use of (centrally controlled) reservation depletes the available= resources much faster than they are actually used. Link utilization is bet= ter observed and managed by the local device in a reactive fashion. This is= another argument along the lines that Mischa, Robert and Thomas discussed = earlier that we want a distributed mechanism for the bulk of the operations= .

=A0

The shim layer that was already discussed has a lot of value = to enable that virtualization and dynamic allocation. On principle I'm = all for it. I'm just unclear how much of it is above IP (like we placed= ND above IP as opposed to ARP) and how mush is under IP, the the 15.4 IEs.= Could there be an IP abstraction that we could reuse in other similar link= layers?

Could we borrow some ideas from tradit= ional Internet resource management systems? In the end, 15.4e does give us = a very straightforward unit of bandwidth (slots) and a stable topology (tha= nks to channel hopping).

The shim layer could sit right on top of 15.4e, and rec= eive request to add/remove links. The "brains" that give the orde= rs could be many things: some traffic observation unit inside the mote, a c= entralized scheduling engine (=E0=A0la TASA), or some distributed resource = reservation mechanism such as RSVP.

The interface to the shim layer could be keps extremely= simple:

- "add/remove this particular slot". This coul= d be used by some omniscient central scheduler which builds a highly optimi= zed schedule, or

- "always maintain 3 slots per second to this neighbor". Thi= s could be used by some more distributed scheduling entity (e.g. RSVP?). It= 's then the shim layer's responsibility to put in the slots needed = to meet that requirement.

=A0

_______________________________________________
6tsch mailing list
6tsch@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/6tsch

--f46d042ef5492a534004d4a50b50--