Subject: [6tsch] G-MPLS, implicit labeling, multiple tracks through one cell

From: <[email-masked]>
Date: Tue, 28 May 2013 14:49:16 +0000

Hello all,

Disclaimer:
I'm no expert in label switching. Please bear with me.
This mail will at least have the benefit of documenting the question and the answer.

Context:
I understand that the 15.4.e cell on which a frame was received by a node can be considered an implicit label. Therefore, we can avoid the overhead of explicitly carrying the label in the frame. Great!

Question:
If we have multiple tracks going through neighbor nodes X and Y, and supposing that their aggregated flow happily fits the data rate provided by one cell, wouldn't we like to be able to multiplex them onto the same cell in order to save on the wake-up/carrier_sense energy cost?
Am I right in saying that we, the 6tsch group, decided to forego the energy saving of multiplexing several tracks on one cell in return for the energy saving of not carrying the label in-band?
Did I miss anything?

Thanks

Dominique

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 28 May 2013 16:29:04 +0000

Hello Dominique:

The Time slot based "G-MPLS" forwarding will not look at the flow label so it does not care whether it is one or multiple flows that get ijected in the time slots.
What you will get is a regular transmit opportunity from A to B.
How the source fills it is its business (one or more flows from A to B), but it is not elastic so if the flows collide at some point there might be drops or latency added before a frame is placed in a track.
Once the frame is on track, it will follow each hop as scheduled.

I think we agree...

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: mardi 28 mai 2013 16:49
To: [email-masked]
Subject: [6tsch] G-MPLS, implicit labeling, multiple tracks through one cell

Hello all,

Disclaimer:

Context:

Question:

Thanks

Dominique

Thank you.

---

From: <[email-masked]>
Date: Wed, 29 May 2013 06:51:12 +0000

Hello Pascal,

Actually, I meant the following situation: one flow goes from A to U on track A-X-Y-U, another flow goes from B to V on track B-X-Y-V.
The two flows can't use the same cell between X and Y because Y has no way of telling them apart.
Correct?
Thanks

Dominique

De : Pascal Thubert (pthubert) [mailto:[email-masked]]
Envoyé : mardi 28 mai 2013 18:29
À : BARTHEL Dominique OLNC/OLPS; [email-masked]
Objet : RE: G-MPLS, implicit labeling, multiple tracks through one cell

Hello Dominique:

I think we agree...

Pascal

Hello all,

Disclaimer:

Context:

Question:

Thanks

Dominique

Thank you.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 29 May 2013 07:50:52 +0000

Hello Dominique:

The traditional Virtual circuit is actually a water tight pipe end to end. My mind image of a track is the same. Thus traffic from B cannot be merged into the A to U track.
I love the idea of merging flows like 1 to u and B to U in a many to one converging channel but even then you enter the world of statistical mux and QoS.

The case you represent does not use tracks at all. We'll have a bundle of cells off any router that can be used unicast or multicast, some of the latter probably reserved for a particular neighbor.
Packets received over such cell will not be G-MPLS switched. They will be punted to layer 3 through the 6LoWPAN sublayer. L3 will device either to route them or deliver locally (punt to L4) when this node is the destination.

In the former case, the packet will go down the stack again through the 6LoWPAN layer and the 6TUS sublayer will determine which bundle of cells can be used to reach the next hop router. You'll note that in this case, we cannot route fragments so IP packets would have to be reassembled at every hop. This is what the fragment forwarding and recovery draft is still useful. With that draft, the first frag installs forwarding states within the 6LoWPAN sublayer for the next fragments based on an explicit label placed in the 6LoWPAN datagram identifier.

We need a picture!!!

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]]
Sent: mercredi 29 mai 2013 08:51
To: Pascal Thubert (pthubert); [email-masked]
Subject: RE: G-MPLS, implicit labeling, multiple tracks through one cell

Hello Pascal,

Dominique

De : Pascal Thubert (pthubert) [mailto:[email-masked]]
Envoyé : mardi 28 mai 2013 18:29
À : BARTHEL Dominique OLNC/OLPS; [email-masked]<mailto:[email-masked]>
Objet : RE: G-MPLS, implicit labeling, multiple tracks through one cell

Hello Dominique:

I think we agree...

Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: mardi 28 mai 2013 16:49
To: [email-masked]<mailto:[email-masked]>
Subject: [6tsch] G-MPLS, implicit labeling, multiple tracks through one cell

Hello all,

Disclaimer:

Context:

Question:

Thanks

Dominique

Thank you.

Thank you.

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 29 May 2013 10:23:58 -0700

Would you agree that the issue you are bringing up is equivalent to the
statement that, with purely implicit labels, only fan-in is possible, not
fan-out.

A --           --> D
     \       /
      => C =
      /       \
B --           --> E

That is, given the following flows around mote C (and with the assumption
that both incoming and outgoing flows share the same cells), it is possible
to have A->C and B->C (e.g. fan-in), but not C->D and C->E.

The core issue you're raising is that there is a trade-off between
installing LSTs (Label Switching Tracks) and energy consumption. That is,
if you install water-tight pipes for all flows, you will waste energy if
data isn't flowing through those pipes, since nodes along those tracks will
be idle listening.

This might be a far-fetched, so please bear with me, but I see some
relationship between the problem you're raising and the use of CIR
(Committed Information Rate), EIR (Excess) and PIR (Peak) typically found
in protocols such as Frame Relay. These are used to limit under-use of
bandwidth, whereas we're more interested in not wasting energy, but the
problem can be described very similarly (I think). Now this only brings
more questions, since, to have this type of behavior, excess packets (i.e.
about the CIR) need to flow from the LST into some other bandwidth. Not
sure whether we want to go there.

Thomas

On Wed, May 29, 2013 at 12:50 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hello Dominique:****
>
> ** **
>
> The traditional Virtual circuit is actually a water tight pipe end to end.
> My mind image of a track is the same. Thus traffic from B cannot be merged
> into the A to U track. ****
>
> I love the idea of merging flows like 1 to u and B to U in a many to one
> converging channel but even then you enter the world of statistical mux and
> QoS.****
>
> ** **
>
> The case you represent does not use tracks at all. We’ll have a bundle of
> cells off any router that can be used unicast or multicast, some of the
> latter probably reserved for a particular neighbor.****
>
> Packets received over such cell will not be G-MPLS switched. They will be
> punted to layer 3 through the 6LoWPAN sublayer. L3 will device either to
> route them or deliver locally (punt to L4) when this node is the
> destination. ****
>
> ** **
>
> In the former case, the packet will go down the stack again through the
> 6LoWPAN layer and the 6TUS sublayer will determine which bundle of cells
> can be used to reach the next hop router. You’ll note that in this case, we
> cannot route fragments so IP packets would have to be reassembled at every
> hop. This is what the fragment forwarding and recovery draft is still
> useful. With that draft, the first frag installs forwarding states within
> the 6LoWPAN sublayer for the next fragments based on an explicit label
> placed in the 6LoWPAN datagram identifier.****
>
> ** **
>
> We need a picture!!!****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Pascal****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]]
>
> *Sent:* mercredi 29 mai 2013 08:51
> *To:* Pascal Thubert (pthubert); [email-masked]
> *Subject:* RE: G-MPLS, implicit labeling, multiple tracks through one cell
> ****
>
> ** **
>
> Hello Pascal,****
>
>  ****
>
> Actually, I meant the following situation: one flow goes from A to U on
> track A-X-Y-U, another flow goes from B to V on track B-X-Y-V.****
>
> The two flows can’t use the same cell between X and Y because Y has no way
> of telling them apart.****
>
> Correct?
> Thanks****
>
>  ****
>
> Dominique****
>
>  ****
>
> *De :* Pascal Thubert (pthubert) [mailto:[email-masked]<[email-masked]>]
>
> *Envoyé :* mardi 28 mai 2013 18:29
> *À :* BARTHEL Dominique OLNC/OLPS; [email-masked]
> *Objet :* RE: G-MPLS, implicit labeling, multiple tracks through one cell*
> ***
>
>  ****
>
> Hello Dominique:****
>
>  ****
>
> The Time slot based “G-MPLS” forwarding will not look at the flow label so
> it does not care whether it is one or multiple flows that get ijected in
> the time slots.****
>
> What you will get is a regular transmit opportunity from A to B. ****
>
> How the source fills it is its business (one or more flows from A to B),
> but it is not elastic so if the flows collide at some point there might be
> drops or latency added before a frame is placed in a track.****
>
> Once the frame is on track, it will follow each hop as scheduled.****
>
>  ****
>
> I think we agree… ****
>
>  ****
>
> Pascal****
>
>  ****
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of [email-masked]
> *Sent:* mardi 28 mai 2013 16:49
> *To:* [email-masked]
> *Subject:* [6tsch] G-MPLS, implicit labeling, multiple tracks through one
> cell****
>
>  ****
>
> Hello all,****
>
>  ****
>
> Disclaimer:****
>
> I’m no expert in label switching. Please bear with me.****
>
> This mail will at least have the benefit of documenting the question and
> the answer.****
>
>  ****
>
>  ****
>
> Context:****
>
> I understand that the 15.4.e cell on which a frame was received by a node
> can be considered an implicit label. Therefore, we can avoid the overhead
> of explicitly carrying the label in the frame. Great!****
>
>  ****
>
> Question:****
>
> If we have multiple tracks going through neighbor nodes X and Y, and
> supposing that their aggregated flow happily fits the data rate provided by
> one cell, wouldn’t we like to be able to multiplex them onto the same cell
> in order to save on the wake-up/carrier_sense energy cost?****
>
> Am I right in saying that we, the 6tsch group, decided to forego the
> energy saving of multiplexing several tracks on one cell in return for the
> energy saving of not carrying the label in-band?****
>
> Did I miss anything?****
>
>  ****
>
> Thanks****
>
>  ****
>
> Dominique****
>
> _________________________________________________________________________________________________________________________****
>
>  ****
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc****
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler****
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,****
>
> France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.****
>
>  ****
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;****
>
> they should not be distributed, used or copied without authorisation.****
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.****
>
> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.****
>
> Thank you.****
>
> _________________________________________________________________________________________________________________________****
>
> ** **
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc****
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler****
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,****
>
> France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.****
>
> ** **
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;****
>
> they should not be distributed, used or copied without authorisation.****
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.****
>
> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.****
>
> Thank you.****
>
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch

 <https://www.ietf.org/mailman/listinfo/6tsch>

---

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 29 May 2013 10:43:59 -0700

The key point here is that we are assuming that C can have a RX shared 
link from A and B and then C can either send to D and E in another slot. 
What is the benefit of that? Is it a general case? Why not having two 
cells at C one that receives from A and another that receives from B 
then transmission from C to D will happen in a cell and C to E in another.

for example node C switching table

in      out
1(A)   3(D)    -- receives at slot 1 from A and sends out at slot 3 to D
2(B)   4(E)     -- receives at slot 2 from B and sends out at slot 4 to E

In case we want to be able to send cross flows, i.e use D for a flow 
from B we can add more entries on the table and assign priorities

in      out     prio
1(A)   3(D)     1
2(B)   4(E)     1
1(A)   4(E)     2
2(B)   2(D)     2

Of course if the data rate is slower than the slotframe length*time of 
each slot then we will have idle listening at C.

Is that what you have in mind?
X

Al 29/05/13 10:23, En/na Thomas Watteyne ha escrit:
> Would you agree that the issue you are bringing up is equivalent to 
> the statement that, with purely implicit labels, only fan-in is 
> possible, not fan-out.
>
> A --           --> D
>      \       /
>       => C =
>      /       \
> B --           --> E
>
> That is, given the following flows around mote C (and with the 
> assumption that both incoming and outgoing flows share the same 
> cells), it is possible to have A->C and B->C (e.g. fan-in), but not 
> C->D and C->E.
>
> installing LSTs (Label Switching Tracks) and energy consumption. That 
> is, if you install water-tight pipes for all flows, you will waste 
> energy if data isn't flowing through those pipes, since nodes along 
> those tracks will be idle listening.
>
> (Committed Information Rate), EIR (Excess) and PIR (Peak) typically 
> found in protocols such as Frame Relay. These are used to limit 
> under-use of bandwidth, whereas we're more interested in not wasting 
> energy, but the problem can be described very similarly (I think). Now 
> this only brings more questions, since, to have this type of behavior, 
> excess packets (i.e. about the CIR) need to flow from the LST into 
> some other bandwidth. Not sure whether we want to go there.
>
> Thomas
>
>
> On Wed, May 29, 2013 at 12:50 AM, Pascal Thubert (pthubert) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hello Dominique:
>
>     The traditional Virtual circuit is actually a water tight pipe end
>     to end. My mind image of a track is the same. Thus traffic from B
>     cannot be merged into the A to U track.
>
>     I love the idea of merging flows like 1 to u and B to U in a many
>     to one converging channel but even then you enter the world of
>     statistical mux and QoS.
>
>     The case you represent does not use tracks at all. We'll have a
>     bundle of cells off any router that can be used unicast or
>     multicast, some of the latter probably reserved for a particular
>     neighbor.
>
>     Packets received over such cell will not be G-MPLS switched. They
>     will be punted to layer 3 through the 6LoWPAN sublayer. L3 will
>     device either to route them or deliver locally (punt to L4) when
>     this node is the destination.
>
>     In the former case, the packet will go down the stack again
>     through the 6LoWPAN layer and the 6TUS sublayer will determine
>     which bundle of cells can be used to reach the next hop router.
>     You'll note that in this case, we cannot route fragments so IP
>     packets would have to be reassembled at every hop. This is what
>     the fragment forwarding and recovery draft is still useful. With
>     that draft, the first frag installs forwarding states within the
>     6LoWPAN sublayer for the next fragments based on an explicit label
>     placed in the 6LoWPAN datagram identifier.
>
>     We need a picture!!!
>
>     Cheers,
>
>     Pascal
>
>     *From:[email-masked]
>     <mailto:[email-masked]>
>     [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     <mailto:[email-masked]>
>     Actually, I meant the following situation: one flow goes from A to
>     U on track A-X-Y-U, another flow goes from B to V on track B-X-Y-V.
>
>     *De :*Pascal Thubert (pthubert) [mailto:[email-masked]]
>     <mailto:[email-masked]>
>     *Objet :* RE: G-MPLS, implicit labeling, multiple tracks through
>     one cell
>
>     Hello Dominique:
>
>     The Time slot based "G-MPLS" forwarding will not look at the flow
>     label so it does not care whether it is one or multiple flows that
>     get ijected in the time slots.
>
>     How the source fills it is its business (one or more flows from A
>     to B), but it is not elastic so if the flows collide at some point
>     there might be drops or latency added before a frame is placed in
>     a track.
>
>     *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]] *On Behalf Of
>     [email-masked] <mailto:[email-masked]>
>     *To:* [email-masked] <mailto:[email-masked]>
>     *Subject:* [6tsch] G-MPLS, implicit labeling, multiple tracks
>     through one cell
>
>     Hello all,
>
>     Disclaimer:
>
>     I understand that the 15.4.e cell on which a frame was received by
>     a node can be considered an implicit label. Therefore, we can
>     avoid the overhead of explicitly carrying the label in the frame.
>     Great!
>
>     Question:
>
>     If we have multiple tracks going through neighbor nodes X and Y,
>     and supposing that their aggregated flow happily fits the data
>     rate provided by one cell, wouldn't we like to be able to
>     multiplex them onto the same cell in order to save on the
>     wake-up/carrier_sense energy cost?
>
>     Am I right in saying that we, the 6tsch group, decided to forego
>     the energy saving of multiplexing several tracks on one cell in
>     return for the energy saving of not carrying the label in-band?
>
>     Did I miss anything?
>
>     Thanks
>
>     Dominique
>
>     [email-masked] <mailto:[email-masked]>

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 29 May 2013 11:09:01 -0700

Xavi,

I agree that what you have in your e-mail is the normal way of doing
things. The group might decide that this is the only way (e.g.
Pascal's water-tight
pipes), in which case we just use that.

I believe what Dominique brings up (Dominique, please correct me if I'm
wrong), is that with this scheme, there is no cell reuse. So in your case,
C listens twice, once for A and once for B (of course, you can generalize
this to multiple cells, or different frame lengths). If there is no traffic
for A and B, C is wasting energy. Dominique's point is to see whether it's
possible to reuse the same cells at C for data coming from A and B, at the
cost of not having flow independence.

I hope this makes sense,
Thomas

On Wed, May 29, 2013 at 10:43 AM, Xavier Vilajosana <
[email-masked]> wrote:

> What is the benefit of that? Is it a general case? Why not having two cells
> at C one that receives from A and another that receives from B then
> transmission from C to D will happen in a cell and C to E in another.
>
> In case we want to be able to send cross flows, i.e use D for a flow from
> B we can add more entries on the table and assign priorities
>
> in      out     prio
> 1(A)   3(D)     1
> 2(B)   4(E)     1
> 1(A)   4(E)     2
> 2(B)   2(D)     2
>
>
> assumption that both incoming and outgoing flows share the same cells), it
> is possible to have A->C and B->C (e.g. fan-in), but not C->D and C->E.
>
>> The traditional Virtual circuit is actually a water tight pipe end to
>> end. My mind image of a track is the same. Thus traffic from B cannot be
>> merged into the A to U track.
>>
>> QoS.
>> latter probably reserved for a particular neighbor.
>>
>> destination.
>> track A-X-Y-U, another flow goes from B to V on track B-X-Y-V.
>>
>> The two flows can’t use the same cell between X and Y because Y has no
>> way of telling them apart.
>>
>> Correct?
>> Thanks
>>
>>
>>
>> Dominique
>>
>>
>>
>> *Objet :* RE: G-MPLS, implicit labeling, multiple tracks through one cell
>>
>>
>>
>> Hello Dominique:
>>
>>
>>
>> The Time slot based “G-MPLS” forwarding will not look at the flow label
>> so it does not care whether it is one or multiple flows that get ijected in
>> the time slots.
>>
>> drops or latency added before a frame is placed in a track.
>>
>> I think we agree…
>> *Subject:* [6tsch] G-MPLS, implicit labeling, multiple tracks through
>> one cell
>>
>>
>>
>> Hello all,
>>
>>
>>
>> Disclaimer:
>>
>> I’m no expert in label switching. Please bear with me.
>>
>> the answer.
>> of explicitly carrying the label in the frame. Great!
>>
>>
>>
>> Question:
>>
>> in order to save on the wake-up/carrier_sense energy cost?
>>
>> energy saving of not carrying the label in-band?
>>
>> Did I miss anything?
>>
>>
>>
>> Thanks
>>
>>
>>
>> Dominique
>>
> 6tsch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tsch
>
>
>

---

From: Kris Pister <[email-masked]>
Date: Wed, 29 May 2013 20:58:08 -0700

Some comments on the last several emails on this thread:
* it seems easy to have a table indexed by (MACsrcID, RXcell) that gives 
TXcellList
   o having only one entry in the cell means a leakfree track (as 
proposed by Xavi?)
   o  (0xFFFF,RXcell) --> TXcellList means any incoming packet goes out 
the same way (convergecast)
   o having several MACsrcIDs with different TXcellLists gives the two 
or more separate flows (as proposed by Dominique?)
* there had better be idle listens in any of these schemes (more RX 
bandwidth than needed) otherwise queues and latency both tend toward 
infinity
* if A and B both talk to C then:
     o    either they need to be explicitly scheduled to not collide, in 
which case you might as well just have a separate cell for A-->C and B-->C
     o    *or* you'd better have a *lot* idle listens, because you'll 
have slotted aloha chaotic collapse if you try to push more than PDR/e 
of the available bandwidth (absent the use of clever-but-not-general 
tricks that have been published over the years).

ksjp

On 5/29/2013 11:09 AM, Thomas Watteyne wrote:
> Pascal's water-tight pipes), in which case we just use that.
>
> I believe what Dominique brings up (Dominique, please correct me if 
> I'm wrong), is that with this scheme, there is no cell reuse. So in 
> your case, C listens twice, once for A and once for B (of course, you 
> can generalize this to multiple cells, or different frame lengths). If 
> there is no traffic for A and B, C is wasting energy. Dominique's 
> point is to see whether it's possible to reuse the same cells at C for 
> data coming from A and B, at the cost of not having flow independence.
>
> I hope this makes sense,
> Thomas
>
>
> On Wed, May 29, 2013 at 10:43 AM, Xavier Vilajosana 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     The key point here is that we are assuming that C can have a RX
>     shared link from A and B and then C can either send to D and E in
>     another slot. What is the benefit of that? Is it a general case?
>     Why not having two cells at C one that receives from A and another
>     that receives from B then transmission from C to D will happen in
>     a cell and C to E in another.
>
>     In case we want to be able to send cross flows, i.e use D for a
>     flow from B we can add more entries on the table and assign priorities
>
>     in      out     prio
>     1(A)   3(D)     1
>     2(B)   4(E)     1
>     1(A)   4(E)     2
>     2(B)   2(D)     2
>
>
>     Of course if the data rate is slower than the slotframe
>     length*time of each slot then we will have idle listening at C.
>
>>     Would you agree that the issue you are bringing up is equivalent
>>     to the statement that, with purely implicit labels, only fan-in
>>     is possible, not fan-out.
>>
>>     A --       --> D
>>          \     /
>>     => C =
>>          /       \
>>     B --       --> E
>>
>>     cells), it is possible to have A->C and B->C (e.g. fan-in), but
>>     not C->D and C->E.
>>
>>     The core issue you're raising is that there is a trade-off
>>     between installing LSTs (Label Switching Tracks) and energy
>>     consumption. That is, if you install water-tight pipes for all
>>     flows, you will waste energy if data isn't flowing through those
>>     pipes, since nodes along those tracks will be idle listening.
>>
>>     This might be a far-fetched, so please bear with me, but I see
>>     some relationship between the problem you're raising and the use
>>     of CIR (Committed Information Rate), EIR (Excess) and PIR (Peak)
>>     typically found in protocols such as Frame Relay. These are used
>>     to limit under-use of bandwidth, whereas we're more interested in
>>     not wasting energy, but the problem can be described very
>>     similarly (I think). Now this only brings more questions, since,
>>     to have this type of behavior, excess packets (i.e. about the
>>     CIR) need to flow from the LST into some other bandwidth. Not
>>         The traditional Virtual circuit is actually a water tight
>>         pipe end to end. My mind image of a track is the same. Thus
>>         traffic from B cannot be merged into the A to U track.
>>
>>         I love the idea of merging flows like 1 to u and B to U in a
>>         many to one converging channel but even then you enter the
>>         world of statistical mux and QoS.
>>
>>         The case you represent does not use tracks at all. We'll have
>>         a bundle of cells off any router that can be used unicast or
>>         multicast, some of the latter probably reserved for a
>>         particular neighbor.
>>
>>         Packets received over such cell will not be G-MPLS switched.
>>         They will be punted to layer 3 through the 6LoWPAN sublayer.
>>         L3 will device either to route them or deliver locally (punt
>>         to L4) when this node is the destination.
>>
>>         through the 6LoWPAN layer and the 6TUS sublayer will
>>         determine which bundle of cells can be used to reach the next
>>         hop router. You'll note that in this case, we cannot route
>>         fragments so IP packets would have to be reassembled at every
>>         hop. This is what the fragment forwarding and recovery draft
>>         is still useful. With that draft, the first frag installs
>>         forwarding states within the 6LoWPAN sublayer for the next
>>         fragments based on an explicit label placed in the 6LoWPAN
>>         datagram identifier.
>>
>>         We need a picture!!!
>>
>>         Cheers,
>>
>>         Pascal
>>
>>         Actually, I meant the following situation: one flow goes from
>>         A to U on track A-X-Y-U, another flow goes from B to V on
>>         track B-X-Y-V.
>>
>>         The Time slot based "G-MPLS" forwarding will not look at the
>>         flow label so it does not care whether it is one or multiple
>>         flows that get ijected in the time slots.
>>
>>         How the source fills it is its business (one or more flows
>>         from A to B), but it is not elastic so if the flows collide
>>         at some point there might be drops or latency added before a
>>         frame is placed in a track.
>>
>>         I understand that the 15.4.e cell on which a frame was
>>         received by a node can be considered an implicit label.
>>         Therefore, we can avoid the overhead of explicitly carrying
>>         the label in the frame. Great!
>>
>>         Question:
>>
>>         If we have multiple tracks going through neighbor nodes X and
>>         Y, and supposing that their aggregated flow happily fits the
>>         data rate provided by one cell, wouldn't we like to be able
>>         to multiplex them onto the same cell in order to save on the
>>         Am I right in saying that we, the 6tsch group, decided to
>>         forego the energy saving of multiplexing several tracks on
>>         one cell in return for the energy saving of not carrying the
>>         label in-band?
>>
>>         Did I miss anything?
>>
>>         Thanks
>>
>>         Dominique
>>

---

From: Pascal Thubert <[email-masked]>
Date: Thu, 30 May 2013 10:00:55 +0200

Hello Kris:

I think that before we talk solutions we need to make sure we agree on what
we are trying to achieve. I am concerned with having to manage traffic
bursts and selective drop operations at the 6TUS level. This would
certainly make it mode complex. What we have here:

- in one hand there is the classical reservation model where you book a
constant slot rate between A and B. in that model, there is no queuing,
just buffering one or 2 frames that can be transmitted in acceptable
schedule. Excess packets cannot even enter the pipe because there is just
no slot available for it, and any QoS or shaping must be done at ingress,
either at the end-device edge or at the network edge. The pipe could be
made larger than base traffic (excess rate as Thomas indicated) in order to
accomodate retries, and what is improved in terms of delivery ratio would
be paid in terms of jitter and latency, as you indicated in a previous
mail. A simpler variation of that model drops the retries from the tunnel
and places them in best effort shared bundles with a high QoS level (we are
defining deterministic class at this moment at the transport area WG). That
way, there is no need for QoS /drop operation to be done at 6TUS level, it
is all done at L3, adn all packets that are delivered by 6TUS arrive at
determined schedule.

- Then there is the convergecast that can accommodate multiple sources of
traffic for a same egress point. What we expect with this sort of network
is an statistical effect to that the throughput of egress pipe is actually
less than the sum of the ingress. On a deterministic source of traffic, we
could use that effect on additional bandwidth that is allocated for retries.

- In the case of multicast, we can think of a tree topology rooted at the
source  with all hops if a constant size and replication at the branching
nodes. If we are interested in such thing, we can invite Ice in the
discussion.

- and then there is routing at 6TUS layer as I understand you address in
this mail. In that case, we lose the grip on the expected flows, and
probably have to expect statistical multiplexing, effectively reporting
some of the L3 complexity into 6TUS.

 Tons of things are doable but I think that a core value of the MPLS tunnel
is the MP part. MPLS does not look inside the packets, so you can do any
protocol over it. As you and Xavi discussed, a clean MPLS layer is not even
aware it carries IPv6. This was heavily used in early IPv6 deployments with
IPv6 PE/VPE, over an MPLS backbone that was setup using IPv4 but could be
used for whatever after that. If 6TUS does not know of IPv6, the layer does
not know about HbH headers and so on either. This is important to allow
fragments through end to end.

The more tricks we play there, the more specific and complex we make the
6TUS sublayer. I'd start simple unless a basic use case is broken.

What do you think?

Pascal

2013/5/30 Kris Pister <[email-masked]>

>   o having only one entry in the cell means a leakfree track (as proposed
> by Xavi?)
>   o  (0xFFFF,RXcell) --> TXcellList means any incoming packet goes out the
> same way (convergecast)
>   o having several MACsrcIDs with different TXcellLists gives the two or
> more separate flows (as proposed by Dominique?)
>     o    *or* you'd better have a *lot* idle listens, because you'll have
> slotted aloha chaotic collapse if you try to push more than PDR/e of the
> available bandwidth (absent the use of clever-but-not-general tricks that
> have been published over the years).
>
> ksjp
>
>
> things. The group might decide that this is the only way (e.g. Pascal's water-tight
>>> The case you represent does not use tracks at all. We’ll have a bundle
>>> of cells off any router that can be used unicast or multicast, some of the
>>> Packets received over such cell will not be G-MPLS switched. They will
>>> be punted to layer 3 through the 6LoWPAN sublayer. L3 will device either to
>>> I understand that the 15.4.e cell on which a frame was received by a
>>> node can be considered an implicit label. Therefore, we can avoid the
>>> overhead of explicitly carrying the label in the frame. Great!
>>>
>>>
>>>
>>> Question:
>>>

-- 
Pascal

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Thu, 30 May 2013 08:27:30 +0000

Dear Pascal, Kris, all

Here are some figures that maybe will help us in carrying on the discuss on this topic on the ML and during Friday call!

Kind Regards,
Maria Rita

From: [email-masked] [mailto:[email-masked]] On Behalf Of Pascal Thubert
Sent: Thursday, May 30, 2013 10:01 AM
To: Kris Pister
Cc: Thomas Watteyne; 6TSCH; [email-masked]
Subject: Re: [6tsch] G-MPLS, implicit labeling, multiple tracks through one cell

Hello Kris:
I think that before we talk solutions we need to make sure we agree on what we are trying to achieve. I am concerned with having to manage traffic bursts and selective drop operations at the 6TUS level. This would certainly make it mode complex. What we have here:
- in one hand there is the classical reservation model where you book a constant slot rate between A and B. in that model, there is no queuing, just buffering one or 2 frames that can be transmitted in acceptable schedule. Excess packets cannot even enter the pipe because there is just no slot available for it, and any QoS or shaping must be done at ingress, either at the end-device edge or at the network edge. The pipe could be made larger than base traffic (excess rate as Thomas indicated) in order to accomodate retries, and what is improved in terms of delivery ratio would be paid in terms of jitter and latency, as you indicated in a previous mail. A simpler variation of that model drops the retries from the tunnel and places them in best effort shared bundles with a high QoS level (we are defining deterministic class at this moment at the transport area WG). That way, there is no need for QoS /drop operation to be done at 6TUS level, it is all done at L3, adn all packets that are delivered by 6TUS arrive at determined schedule.

- Then there is the convergecast that can accommodate multiple sources of traffic for a same egress point. What we expect with this sort of network is an statistical effect to that the throughput of egress pipe is actually less than the sum of the ingress. On a deterministic source of traffic, we could use that effect on additional bandwidth that is allocated for retries.
- In the case of multicast, we can think of a tree topology rooted at the source  with all hops if a constant size and replication at the branching nodes. If we are interested in such thing, we can invite Ice in the discussion.

- and then there is routing at 6TUS layer as I understand you address in this mail. In that case, we lose the grip on the expected flows, and probably have to expect statistical multiplexing, effectively reporting some of the L3 complexity into 6TUS.

 Tons of things are doable but I think that a core value of the MPLS tunnel is the MP part. MPLS does not look inside the packets, so you can do any protocol over it. As you and Xavi discussed, a clean MPLS layer is not even aware it carries IPv6. This was heavily used in early IPv6 deployments with IPv6 PE/VPE, over an MPLS backbone that was setup using IPv4 but could be used for whatever after that. If 6TUS does not know of IPv6, the layer does not know about HbH headers and so on either. This is important to allow fragments through end to end.

The more tricks we play there, the more specific and complex we make the 6TUS sublayer. I'd start simple unless a basic use case is broken.
What do you think?

Pascal

2013/5/30 Kris Pister <[email-masked]<mailto:[email-masked]>>
Some comments on the last several emails on this thread:
* it seems easy to have a table indexed by (MACsrcID, RXcell) that gives TXcellList
  o having only one entry in the cell means a leakfree track (as proposed by Xavi?)
  o  (0xFFFF,RXcell) --> TXcellList means any incoming packet goes out the same way (convergecast)
  o having several MACsrcIDs with different TXcellLists gives the two or more separate flows (as proposed by Dominique?)
* there had better be idle listens in any of these schemes (more RX bandwidth than needed) otherwise queues and latency both tend toward infinity
* if A and B both talk to C then:
    o    either they need to be explicitly scheduled to not collide, in which case you might as well just have a separate cell for A-->C and B-->C
    o    *or* you'd better have a *lot* idle listens, because you'll have slotted aloha chaotic collapse if you try to push more than PDR/e of the available bandwidth (absent the use of clever-but-not-general tricks that have been published over the years).

ksjp

I agree that what you have in your e-mail is the normal way of doing things. The group might decide that this is the only way (e.g. Pascal's water-tight pipes), in which case we just use that.

I believe what Dominique brings up (Dominique, please correct me if I'm wrong), is that with this scheme, there is no cell reuse. So in your case, C listens twice, once for A and once for B (of course, you can generalize this to multiple cells, or different frame lengths). If there is no traffic for A and B, C is wasting energy. Dominique's point is to see whether it's possible to reuse the same cells at C for data coming from A and B, at the cost of not having flow independence.

I hope this makes sense,
Thomas

On Wed, May 29, 2013 at 10:43 AM, Xavier Vilajosana <[email-masked]<mailto:[email-masked]>> wrote:
The key point here is that we are assuming that C can have a RX shared link from A and B and then C can either send to D and E in another slot. What is the benefit of that? Is it a general case? Why not having two cells at C one that receives from A and another that receives from B then transmission from C to D will happen in a cell and C to E in another.

in      out

In case we want to be able to send cross flows, i.e use D for a flow from B we can add more entries on the table and assign priorities

in      out     prio
1(A)   3(D)     1
2(B)   4(E)     1
1(A)   4(E)     2
2(B)   2(D)     2

Of course if the data rate is slower than the slotframe length*time of each slot then we will have idle listening at C.

Al 29/05/13 10:23, En/na Thomas Watteyne ha escrit:
Would you agree that the issue you are bringing up is equivalent to the statement that, with purely implicit labels, only fan-in is possible, not fan-out.

A --           --> D
     \       /
      => C =
     /       \
B --           --> E

That is, given the following flows around mote C (and with the assumption that both incoming and outgoing flows share the same cells), it is possible to have A->C and B->C (e.g. fan-in), but not C->D and C->E.

The core issue you're raising is that there is a trade-off between installing LSTs (Label Switching Tracks) and energy consumption. That is, if you install water-tight pipes for all flows, you will waste energy if data isn't flowing through those pipes, since nodes along those tracks will be idle listening.

This might be a far-fetched, so please bear with me, but I see some relationship between the problem you're raising and the use of CIR (Committed Information Rate), EIR (Excess) and PIR (Peak) typically found in protocols such as Frame Relay. These are used to limit under-use of bandwidth, whereas we're more interested in not wasting energy, but the problem can be described very similarly (I think). Now this only brings more questions, since, to have this type of behavior, excess packets (i.e. about the CIR) need to flow from the LST into some other bandwidth. Not sure whether we want to go there.

Thomas

On Wed, May 29, 2013 at 12:50 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Dominique:

We need a picture!!!

Cheers,

Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: mercredi 29 mai 2013 08:51
To: Pascal Thubert (pthubert); [email-masked]<mailto:[email-masked]>
Subject: RE: G-MPLS, implicit labeling, multiple tracks through one cell

Hello Pascal,

Dominique

Hello Dominique:

I think we agree...

Pascal

Hello all,

Disclaimer:

Context:

Question:

Thanks

Dominique

Thank you.

Thank you.

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

6tsch mailing list

[email-masked]<mailto:[email-masked]>

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

6tsch mailing list

[email-masked]<mailto:[email-masked]>

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

--
Pascal

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 30 May 2013 01:44:12 -0700

Maria Rita.

Wonderful stuff.

Quick questions:
- in Track Switching, what do the white X->Y cells represent?
- in IP Routing, little type boundle->bundle

Maybe it would be helpful to depict the format of the packets (i.e. which
headers go where) in the three cases. Most of those details are certainly
still in discussion.

Thomas

On Thu, May 30, 2013 at 1:27 AM, Maria Rita PALATTELLA <
[email-masked]> wrote:

>  Dear Pascal, Kris, all****
>
> ** **
>
> Here are some figures that maybe will help us in carrying on the discuss
> on this topic on the ML and during Friday call!****
>
> ** **
>
> Kind Regards,****
>
> Maria Rita****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Pascal Thubert
> *Sent:* Thursday, May 30, 2013 10:01 AM
> *To:* Kris Pister
> *Cc:* Thomas Watteyne; 6TSCH; [email-masked]
> *Subject:* Re: [6tsch] G-MPLS, implicit labeling, multiple tracks through
> one cell****
>
> ** **
>
> Hello Kris:****
>
> I think that before we talk solutions we need to make sure we agree on
> what we are trying to achieve. I am concerned with having to manage traffic
> certainly make it mode complex. What we have here:****
>
> determined schedule.****
> discussion.****
>  Tons of things are doable but I think that a core value of the MPLS
> tunnel is the MP part. MPLS does not look inside the packets, so you can do
> any protocol over it. As you and Xavi discussed, a clean MPLS layer is not
> even aware it carries IPv6. This was heavily used in early IPv6 deployments
> with IPv6 PE/VPE, over an MPLS backbone that was setup using IPv4 but could
> be used for whatever after that. If 6TUS does not know of IPv6, the layer
> does not know about HbH headers and so on either. This is important to
> allow fragments through end to end.
>
> 6TUS sublayer. I'd start simple unless a basic use case is broken.****
>
> What do you think?****
>
> ** **
>
> Pascal****
>
> ** **
>
> ** **
>
> 2013/5/30 Kris Pister <[email-masked]>****
>
> ksjp****
> On 5/29/2013 11:09 AM, Thomas Watteyne wrote:****
>
>  Xavi, ****
>
> ** **
>
> pipes), in which case we just use that.****
>
> ** **
>
> cost of not having flow independence.****
>
> ** **
>
> I hope this makes sense,****
>
> Thomas****
>
> ** **
>
> [email-masked]> wrote:****
>
> Al 29/05/13 10:23, En/na Thomas Watteyne ha escrit:****
>
> fan-out.****
> A --           --> D****
>      \       /****
>       => C =****
>      /       \****
> B --           --> E****
> to have A->C and B->C (e.g. fan-in), but not C->D and C->E.****
>
> ** **
>
> be idle listening.****
> sure whether we want to go there.****
>
> ** **
>
> Thomas****
>
> ** **
>
> [email-masked]> wrote:****
>
> Hello Dominique:****
>
>  ****
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>
> _______________________________________________****
>
> 6tsch mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>  ** **
>
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>
> ** **
>
> _______________________________________________****
>
> 6tsch mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>  ** **
>
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>
>
>
> --
> Pascal ****
>

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Thu, 30 May 2013 09:01:42 +0000

Thanks Thomas!

Quick answers:

-        With the white X->Y cells I wanted to show that even though in a track we use specific cells (those in green or purpose), within the same schedule we can have others equivalent cells (the white ones) that will be assigned to other tracks, or create a bundle for IP-routing. Am I wrong?

-        Sorry for the type, It is fixed in the attached file!

I do agree about having in the figures also the packets format, with headers, etc., but maybe we can do that once we agree/converge to a final solution. What do you think?

Maria Rita

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Thursday, May 30, 2013 10:44 AM
To: 6TSCH
Subject: Re: [6tsch] G-MPLS, implicit labeling, multiple tracks through one cell

Maria Rita.

Wonderful stuff.

Quick questions:

Maybe it would be helpful to depict the format of the packets (i.e. which headers go where) in the three cases. Most of those details are certainly still in discussion.

Thomas

On Thu, May 30, 2013 at 1:27 AM, Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>> wrote:
Dear Pascal, Kris, all

Kind Regards,
Maria Rita

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Pascal Thubert
Sent: Thursday, May 30, 2013 10:01 AM
To: Kris Pister
Cc: Thomas Watteyne; 6TSCH; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tsch] G-MPLS, implicit labeling, multiple tracks through one cell

Hello Kris:

Pascal

ksjp

I hope this makes sense,
Thomas

in      out

in      out     prio
1(A)   3(D)     1
2(B)   4(E)     1
1(A)   4(E)     2
2(B)   2(D)     2

A --           --> D
     \       /
      => C =
     /       \
B --           --> E

Thomas

We need a picture!!!

Cheers,

Pascal

Hello Pascal,

Dominique

Hello Dominique:

I think we agree...

Pascal

Hello all,

Disclaimer:

Context:

Question:

Thanks

Dominique

Thank you.

Thank you.

6tsch mailing list

6tsch mailing list

--
Pascal

---

From: Kris Pister <[email-masked]>
Date: Thu, 30 May 2013 16:19:10 -0700

My guess is that we are mostly on the same page, but as usual I have a 
hard time understanding the differences in what we're saying.

On 5/30/2013 1:00 AM, Pascal Thubert wrote:
> what we are trying to achieve.
OK, so what are you trying to achieve?  I'm trying to achieve high 
reliability, low power IPv6 communication over a multi-hop 15.4E network 
with the simplest possible solution that works, while providing a 
platform on which future optimizations can be made.  In that sense, I 
think that the whole tunnel idea is about two years ahead of where we 
are today, and it's a distraction from the important work that we should 
be doing.
> I am concerned with having to manage traffic bursts and selective drop 
> operations at the 6TUS level.
That sounds like something that would concern me as well.  How does it 
relate to my email?  Was there something implicit in what I wrote that 
means we have to handle traffic bursts and selective drop operations?  
That's certainly not what I was thinking.
> This would certainly make it mode complex. What we have here:
>
> - in one hand there is the classical reservation model where you book 
> a constant slot rate between A and B. in that model, there is no 
> queuing, just buffering one or 2 frames that can be transmitted in 
> acceptable schedule.
I don't understand the distinction between queuing and "buffering one or 
2 packets".  Whether you have a buffer (queue?) of length 1 or 1 billion 
packets, you still need more "gazoutas" than "gazintas" or you're in 
trouble, yes?
> Excess packets cannot even enter the pipe because there is just no 
> slot available for it,
I don't see how that could be true.  If we refer to Maria Rita's very 
nice track-switching.png and ignore B and V, and only look at the green 
links, then here is what can happen in a real network.
Superframe cycle 1: A --> X, X-->Y, Y-->U, success!
cycle 2: A-->X, X-->Y, Y-->U but U does not ACK (interference), packet 
stays in Y's buffer
cycle 3: A-->X, X-->Y, Y-->U and Y fails again.  Now Y has two packets 
in its buffers, which are now full.
cycle 4: A-->X, X-->Y, Y sends a NACK to X
cycle 5: A-->X, X-->Y, Y sends a NACK to X, now X's buffers are full.
cycle 6: A-->X, X sends a NACK to A
In this example the link from Y-->U is down a lot, but if we say that it 
only goes down 0.1% more often than the link from A-->X, then the same 
thing happens, you just multiply the cycle count by 1000 to see it.

> and any QoS or shaping must be done at ingress, either at the 
> end-device edge or at the network edge.
I don't think that this will work, unless by that you mean "this pipe to 
be able to carry 1 packet per second if all links work perfectly, 
therefore as the edge device I know that I should never send more than 
one packet every two seconds into the pipe, or I will be asking for trouble"
> The pipe could be made larger than base traffic (excess rate as Thomas 
> indicated) in order to accomodate retries, and what is improved in 
> terms of delivery ratio would be paid in terms of jitter and latency, 
> as you indicated in a previous mail. A simpler variation of that model 
> drops the retries from the tunnel and places them in best effort 
> shared bundles with a high QoS level (we are defining deterministic 
> class at this moment at the transport area WG). That way, there is no 
> need for QoS /drop operation to be done at 6TUS level, it is all done 
> at L3, adn all packets that are delivered by 6TUS arrive at determined 
> schedule.
This sounds more complicated, not less.
>
> - Then there is the convergecast that can accommodate multiple sources 
> of traffic for a same egress point. What we expect with this sort of 
> network is an statistical effect to that the throughput of egress pipe 
> is actually less than the sum of the ingress. On a deterministic 
> source of traffic, we could use that effect on additional bandwidth 
> that is allocated for retries.
Yes, that's a good idea.  It's a very nonlinear effect that shapes the 
individual path statistics, ~1/(1-x) at each hop, and hard to predict 
over a mesh.
>
> - In the case of multicast, we can think of a tree topology rooted at 
> the source  with all hops if a constant size and replication at the 
> branching nodes. If we are interested in such thing, we can invite Ice 
> in the discussion.
?  I don't understand this at all.
>
> - and then there is routing at 6TUS layer as I understand you address 
> in this mail. In that case, we lose the grip on the expected flows, 
> and probably have to expect statistical multiplexing, effectively 
> reporting some of the L3 complexity into 6TUS.
Switching not routing, right?
> tunnel is the MP part. MPLS does not look inside the packets, so you 
> can do any protocol over it. As you and Xavi discussed, a clean MPLS 
> layer is not even aware it carries IPv6. This was heavily used in 
> early IPv6 deployments with IPv6 PE/VPE, over an MPLS backbone that 
> was setup using IPv4 but could be used for whatever after that. If 
> 6TUS does not know of IPv6, the layer does not know about HbH headers 
> and so on either. This is important to allow fragments through end to 
> end.
This makes sense.
>
> The more tricks we play there, the more specific and complex we make 
> the 6TUS sublayer. I'd start simple unless a basic use case is broken.
Here I agree with you 100%.  I think that we are getting way ahead of 
ourselves.  I am still naively hopeful that we can get a simple RFC out 
the door early that defines how to set up a very simple slotted aloha 
version of the network as a default, and provides the hooks necessary to 
do all of the cool things that people are talking about now.  But the 
details of those cool things should remain out of scope (for the first 
RFC at least) until we have the simple stuff working in interops.  After 
that we can write lots of papers and IDs about how lousy the simple 
approach is relative to our super-duper ideas for PCEs, distributed 
scheduling and QoS, and leaky or tight pipes, and we'll have a common 
platform to stand on.

ksjp
>       o having several MACsrcIDs with different TXcellLists gives the
>     two or more separate flows (as proposed by Dominique?)
>     * there had better be idle listens in any of these schemes (more
>     RX bandwidth than needed) otherwise queues and latency both tend
>     toward infinity
>         o    either they need to be explicitly scheduled to not
>     collide, in which case you might as well just have a separate cell
>     for A-->C and B-->C
>         o    *or* you'd better have a *lot* idle listens, because
>     you'll have slotted aloha chaotic collapse if you try to push more
>     than PDR/e of the available bandwidth (absent the use of
>     clever-but-not-general tricks that have been published over the
>     years).
>
>     ksjp
>
>
>>     I agree that what you have in your e-mail is the normal way of
>>     doing things. The group might decide that this is the only way
>>     (e.g. Pascal's water-tight pipes), in which case we just use that.
>>
>>     I believe what Dominique brings up (Dominique, please correct me
>>     if I'm wrong), is that with this scheme, there is no cell reuse.
>>     So in your case, C listens twice, once for A and once for B (of
>>     course, you can generalize this to multiple cells, or different
>>     frame lengths). If there is no traffic for A and B, C is wasting
>>     energy. Dominique's point is to see whether it's possible to
>>     reuse the same cells at C for data coming from A and B, at the
>>     <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>         The key point here is that we are assuming that C can have a
>>         RX shared link from A and B and then C can either send to D
>>         and E in another slot. What is the benefit of that? Is it a
>>         general case? Why not having two cells at C one that receives
>>         from A and another that receives from B then transmission
>>         from C to D will happen in a cell and C to E in another.
>>
>>         In case we want to be able to send cross flows, i.e use D for
>>         a flow from B we can add more entries on the table and assign
>>         priorities
>>
>>         in      out     prio
>>         1(A)   3(D)     1
>>         2(B)   4(E)     1
>>         1(A)   4(E)     2
>>         2(B)   2(D)     2
>>
>>
>>>         Would you agree that the issue you are bringing up is
>>>         equivalent to the statement that, with purely implicit
>>>         labels, only fan-in is possible, not fan-out.
>>>
>>>         A -- --> D
>>>              \       /
>>>               => C =
>>>              /   \
>>>         B -- --> E
>>>
>>>         That is, given the following flows around mote C (and with
>>>         the assumption that both incoming and outgoing flows share
>>>         the same cells), it is possible to have A->C and B->C (e.g.
>>>         fan-in), but not C->D and C->E.
>>>
>>>         consumption. That is, if you install water-tight pipes for
>>>         all flows, you will waste energy if data isn't flowing
>>>         through those pipes, since nodes along those tracks will be
>>>         idle listening.
>>>
>>>         This might be a far-fetched, so please bear with me, but I
>>>         see some relationship between the problem you're raising and
>>>         the use of CIR (Committed Information Rate), EIR (Excess)
>>>         and PIR (Peak) typically found in protocols such as Frame
>>>         Relay. These are used to limit under-use of bandwidth,
>>>         whereas we're more interested in not wasting energy, but the
>>>         problem can be described very similarly (I think). Now this
>>>         only brings more questions, since, to have this type of
>>>         behavior, excess packets (i.e. about the CIR) need to flow
>>>         from the LST into some other bandwidth. Not sure whether we
>>>         want to go there.
>>>
>>>         Thomas
>>>
>>>
>>>             The traditional Virtual circuit is actually a water
>>>             tight pipe end to end. My mind image of a track is the
>>>             same. Thus traffic from B cannot be merged into the A to
>>>             U track.
>>>
>>>             I love the idea of merging flows like 1 to u and B to U
>>>             in a many to one converging channel but even then you
>>>             enter the world of statistical mux and QoS.
>>>
>>>             The case you represent does not use tracks at all. We’ll
>>>             have a bundle of cells off any router that can be used
>>>             unicast or multicast, some of the latter probably
>>>             reserved for a particular neighbor.
>>>
>>>             Packets received over such cell will not be G-MPLS
>>>             switched. They will be punted to layer 3 through the
>>>             6LoWPAN sublayer. L3 will device either to route them or
>>>             deliver locally (punt to L4) when this node is the
>>>             destination.
>>>
>>>             In the former case, the packet will go down the stack
>>>             again through the 6LoWPAN layer and the 6TUS sublayer
>>>             will determine which bundle of cells can be used to
>>>             reach the next hop router. You’ll note that in this
>>>             case, we cannot route fragments so IP packets would have
>>>             to be reassembled at every hop. This is what the
>>>             fragment forwarding and recovery draft is still useful.
>>>             With that draft, the first frag installs forwarding
>>>             states within the 6LoWPAN sublayer for the next
>>>             fragments based on an explicit label placed in the
>>>             6LoWPAN datagram identifier.
>>>
>>>             We need a picture!!!
>>>
>>>             Cheers,
>>>
>>>             Pascal
>>>
>>>             Actually, I meant the following situation: one flow goes
>>>             from A to U on track A-X-Y-U, another flow goes from B
>>>             to V on track B-X-Y-V.
>>>
>>>             The two flows can’t use the same cell between X and Y
>>>             because Y has no way of telling them apart.
>>>
>>>             Correct?
>>>             Thanks
>>>
>>>             Dominique
>>>
>>>             The Time slot based “G-MPLS” forwarding will not look at
>>>             the flow label so it does not care whether it is one or
>>>             multiple flows that get ijected in the time slots.
>>>
>>>             How the source fills it is its business (one or more
>>>             flows from A to B), but it is not elastic so if the
>>>             flows collide at some point there might be drops or
>>>             latency added before a frame is placed in a track.
>>>
>>>             *Subject:* [6tsch] G-MPLS, implicit labeling, multiple
>>>             tracks through one cell
>>>
>>>             Hello all,
>>>
>>>             Disclaimer:
>>>
>>>             Therefore, we can avoid the overhead of explicitly
>>>             carrying the label in the frame. Great!
>>>
>>>             Question:
>>>
>>>             If we have multiple tracks going through neighbor nodes
>>>             X and Y, and supposing that their aggregated flow
>>>             happily fits the data rate provided by one cell,
>>>             wouldn’t we like to be able to multiplex them onto the
>>>             same cell in order to save on the wake-up/carrier_sense
>>>             energy cost?
>>>
>>>             Am I right in saying that we, the 6tsch group, decided
>>>             to forego the energy saving of multiplexing several
>>>             tracks on one cell in return for the energy saving of
>>>             not carrying the label in-band?
>>>
>>>             Did I miss anything?
>>>
>>>             Thanks
>>>
>>>             Dominique
>>>

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 30 May 2013 22:17:09 -0700

Maria Rita,

Thanks for the updated figure! I am putting together some slides for the
call, I'll put your (updated) figure in pole position. Great discussion
material, thanks a million!

I agree that we haven't converged on what sequence of headers appear in a
switched packet, so let's not forget to discuss this on the call.

Thomas

On Thu, May 30, 2013 at 2:01 AM, Maria Rita PALATTELLA <
[email-masked]> wrote:

>  Thanks Thomas!****
>
> ** **
>
> Quick answers:****
>
> **-        **With the white X->Y cells I wanted to show that even though
> in a track we use specific cells (those in green or purpose), within the
> same schedule we can have others equivalent cells (the white ones) that
> will be assigned to other tracks, or create a bundle for IP-routing. Am I
> wrong?****
>
> **-        **Sorry for the type, It is fixed in the attached file!****
>
> ** **
>
> I do agree about having in the figures also the packets format, with
> headers, etc., but maybe we can do that once we agree/converge to a final
> solution. What do you think?****
>
> ** **
>
> Maria Rita   ****
>
> ** **
>
> Of *Thomas Watteyne
> *Sent:* Thursday, May 30, 2013 10:44 AM
> *To:* 6TSCH
>
> Maria Rita.****
> Wonderful stuff.****
> Quick questions:****
> - in Track Switching, what do the white X->Y cells represent?****
>
> - in IP Routing, little type boundle->bundle****
>
> ** **
>
> still in discussion.****
> [email-masked]> wrote:****
>