Subject: Re: [6tsch] Routing vs. switching

From: "Qin Wang" <[email-masked]>
Date: Mon, 3 Jun 2013 13:13:47 -0700

Hi Pascal,

I don't understand strategy a) clearly. According to my understanding on
"Track", it consists of a sequence of cells along a multihop path, and
there is one and only one cell for a pair of nodes (i.e. fixed next hop
neighbor). Then, how does multicast Mac address function? What do you mean
by reusing a cell?

I guess that the strategy a) will be used to solve the problem of
(A->C->B, D->C->E). That is, there is a cell in node-C with multicast
address to both node-B and node-E. So, the cell can be reused in the two
tracks. Correct?

Thanks
Qin

> Dear all ;
>
> We had a great discussion today at the weekly call about routing that
> relies on 1 hop cell bundles vs. switching that operates on end to end
> tracks.
>
> We agreed that merging and splitting tracks could require queuing at
> intermediate nodes to absorb burst collisions from multiple sources and
> decided to go for the watertight pipes.
>
> We proposed 2 additional strategies:
>
> a) define a multicast mac address for the track, so we can 1) reuse a
> track cell that is not used by a deterministic packet for hop by hop L3
> traffic as differentiated by its unicast MAC destination and 2) forward
> with no change to the destination.
>
> b) let the PCE install routes as well as tracks. With that strategy, A PCE
> route is an alternate to a track that would allow cell reuse and L3 QoS
> operation. We leverage the deterministic Class of service (that's
> Deterministic Forwarding, DF, though encoded 0xEF). And we can emulate RPL
> local instances as indexed by the tuple (source address,
> local_instance_id) and forward the packet with the same rules are RPL,
> along the routing table indexed by the instance ID.
>
> Comments welcome!
>
> Cheers,
>
> Pascal
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 3 Jun 2013 22:08:17 +0000

Hello Qin:

I expect that without this proposal, the dest mac of a packet would be the next L2 node, so that the next hop picks it and passes it to 6TUS layer.
With the proposal, all nodes along a track would accept the multicast dest mac address associated to that track, so the packet is recognized as receivable by this node at L2 and yet can be forwarded at 6TUS layer without dest MAC rewrite. 

Reusing the cell would be the case where this router did not receive a frame on the track incoming slot, so the outgoing slot will be wasted. If we have a packet for which the next hop the same router as the receiver of the wasted cell, then we'd want to use the cell to progress the packet one hop. But then the receiver router needs to figure out that this is not a frame to be switched at 6TUS layer but a packet to be routed at L3. The trick is that in this case, the destination MAC address would be effectively that of the receiver router so 6TUS would punt the packet to L3.

Reusing a cell between 2 tracks is not the idea because there might be collisions. Here we are talking about using an unsed cell opportunistically for L3 best effort traffic. If there is an unused track cell, it adds up to the bundle between the 2 adjacent routers for that particular slotframe.

Makes sense?

Pascal

-----Original Message-----
From: Qin Wang [mailto:[email-masked]] 
Sent: lundi 3 juin 2013 13:14
To: Pascal Thubert (pthubert)
Cc: [email-masked]
Subject: Re: [6tsch] Routing vs. switching

Hi Pascal,

I don't understand strategy a) clearly. According to my understanding on "Track", it consists of a sequence of cells along a multihop path, and there is one and only one cell for a pair of nodes (i.e. fixed next hop neighbor). Then, how does multicast Mac address function? What do you mean by reusing a cell?

I guess that the strategy a) will be used to solve the problem of (A->C->B, D->C->E). That is, there is a cell in node-C with multicast address to both node-B and node-E. So, the cell can be reused in the two tracks. Correct?

Thanks
Qin

> intermediate nodes to absorb burst collisions from multiple sources 
> and decided to go for the watertight pipes.
>
> track cell that is not used by a deterministic packet for hop by hop 
> L3 traffic as differentiated by its unicast MAC destination and 2) 
> forward with no change to the destination.
>
> b) let the PCE install routes as well as tracks. With that strategy, A 
> PCE route is an alternate to a track that would allow cell reuse and 
> L3 QoS operation. We leverage the deterministic Class of service 
> (that's Deterministic Forwarding, DF, though encoded 0xEF). And we can 
> emulate RPL local instances as indexed by the tuple (source address,

---

From: "Qin Wang" <[email-masked]>
Date: Tue, 4 Jun 2013 06:19:34 -0700

Hi Pascal,

It makes sense to me. I want to confirm my understanding further.

(1) Regarding the multicast address, it functions as a track-ID, or a
label of a reserved route in layer 2.5. Correct?

(2) Regarding to reusing cell, it supports multiple queues with different
QoS, saying the packets associated with the track has higher priority, and
the best effort packets has lower priority. Correct?

If my understanding is correct, a parameter like trackID (which will be
used as multicast address) may be needed in the cell reservation related
commands of 6tus.

Thanks
Qin

> Hello Qin:
>
> I expect that without this proposal, the dest mac of a packet would be the
> next L2 node, so that the next hop picks it and passes it to 6TUS layer.
> With the proposal, all nodes along a track would accept the multicast dest
> mac address associated to that track, so the packet is recognized as
> receivable by this node at L2 and yet can be forwarded at 6TUS layer
> without dest MAC rewrite.
>
> Reusing the cell would be the case where this router did not receive a
> frame on the track incoming slot, so the outgoing slot will be wasted. If
> we have a packet for which the next hop the same router as the receiver of
> the wasted cell, then we'd want to use the cell to progress the packet one
> hop. But then the receiver router needs to figure out that this is not a
> frame to be switched at 6TUS layer but a packet to be routed at L3. The
> trick is that in this case, the destination MAC address would be
> effectively that of the receiver router so 6TUS would punt the packet to
> L3.
>
> Reusing a cell between 2 tracks is not the idea because there might be
> collisions. Here we are talking about using an unsed cell
> opportunistically for L3 best effort traffic. If there is an unused track
> cell, it adds up to the bundle between the 2 adjacent routers for that
> particular slotframe.
>
> Makes sense?
>
> Pascal
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 4 Jun 2013 15:28:09 +0000

Hello Qin:

(1) Regarding the multicast address, it functions as a track-ID, or a label of a reserved route in layer 2.5. Correct?

[Pascal] Yes, that would be an added value. The main goal is to make sure that any intermediate node accepts the packet. Alternatively we could use broadcast (0xFFFF) on all the tracks but then we need to make sure that the node only forwards along the track.

(2) Regarding to reusing cell, it supports multiple queues with different QoS, saying the packets associated with the track has higher priority, and the best effort packets has lower priority. Correct?

[Pascal] Actually the prioritization and packet drop management is done at L3. If we have received a packet along the track, then that packet goes out next, with no control from IP. But if there was no packet in along the track at the current iteration of the schedule, then we have one free cell for that iteration. What we can do at 6TUS layer is add that particular cell in that particular iteration of the schedule to the bundle that is used for L3 as link to the next hop router. When the cell time arrives, we pick the highest priority packet from the L3 outgoing queue on the link towards the particular next hop of that cell and transmit. The next hop router can pick that packet and punt it.

If my understanding is correct, a parameter like trackID (which will be used as multicast address) may be needed in the cell reservation related commands of 6tus.

[Pascal] I think that could be useful. 

 : )
 
Pascal

> Hello Qin:
>
> I expect that without this proposal, the dest mac of a packet would be 
> the next L2 node, so that the next hop picks it and passes it to 6TUS layer.
> With the proposal, all nodes along a track would accept the multicast 
> dest mac address associated to that track, so the packet is recognized 
> as receivable by this node at L2 and yet can be forwarded at 6TUS 
> layer without dest MAC rewrite.
>
> frame on the track incoming slot, so the outgoing slot will be wasted. 
> If we have a packet for which the next hop the same router as the 
> receiver of the wasted cell, then we'd want to use the cell to 
> progress the packet one hop. But then the receiver router needs to 
> figure out that this is not a frame to be switched at 6TUS layer but a 
> packet to be routed at L3. The trick is that in this case, the 
> destination MAC address would be effectively that of the receiver 
> router so 6TUS would punt the packet to L3.
>
> opportunistically for L3 best effort traffic. If there is an unused 
> track cell, it adds up to the bundle between the 2 adjacent routers 
> for that particular slotframe.
>
> Makes sense?
>
> Pascal
>
>
> I don't understand strategy a) clearly. According to my understanding 
> on "Track", it consists of a sequence of cells along a multihop path, 
> and there is one and only one cell for a pair of nodes (i.e. fixed 
> next hop neighbor). Then, how does multicast Mac address function? 
> What do you mean by reusing a cell?
>
> address to both node-B and node-E. So, the cell can be reused in the 
> two tracks. Correct?
>
> Thanks
> Qin
>
>
>> Dear all ;
>>
>> relies on 1 hop cell bundles vs. switching that operates on end to 
>> end tracks.
>>
>> b) let the PCE install routes as well as tracks. With that strategy, 
>> A PCE route is an alternate to a track that would allow cell reuse 
>> and
>> (that's Deterministic Forwarding, DF, though encoded 0xEF). And we 
>> can emulate RPL local instances as indexed by the tuple (source 
>> address,
>> local_instance_id) and forward the packet with the same rules are 
>> RPL, along the routing table indexed by the instance ID.
>>
>> Comments welcome!
>>
>> Cheers,
>>
>> Pascal

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 04 Jun 2013 10:57:04 -0700

Hi, my 2 cents and to don't lose the focus and try to bring a simple 
picture of what we are addressing:

1-The general case of Packet Switching at L2.5 will not use any header. 
The PCE will install the mappings between input and output cells and 
tracks will be tight water pipes. (no sharing of resources). Forwarding 
will be done by 6tus, i.e looking input cell into the table and 
inserting the packet in the corresponding queue so it can be relayed at 
the appropriate output cell.

2-As an add-on we are discussing to add support for cell reuse, which 
won't be the general case or at least not as common as 1). In the case 
of cell reuse the track-ID will be used as destination address. We are 
proposing to use a multi-cast destination address when we want to 
express that a flow can use track-shared cells.

3-When 6tus has to relay a packet, and has nothing to sent in a 
particular slot, will pick another packet from a multicast queue which 
has a multicast address so the resource can be shared.

So when inserting a packet into a queue, if the destination address is 
the multicast address it will be assigned a different priority than 
packets with specific destination address, and will be relayed using the 
bundle of cells that are identified by that multicast address. This 
means that the switching table needs another field, i.e the track-id 
which needs to be shared by all the nodes in the track, in that way 
6tus, upon receiving a packet in a cell, will look at the input cell, 
destination address and will find the output cell and will put the 
packet in the corresponding queue.

am I missing something?

X

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 4 Jun 2013 22:22:47 +0000

Hello Xavi:

1-The general case of Packet Switching at L2.5 will not use any header. 
The PCE will install the mappings between input and output cells and tracks will be tight water pipes. (no sharing of resources). Forwarding will be done by 6tus, i.e looking input cell into the table and inserting the packet in the corresponding queue so it can be relayed at the appropriate output cell.

[Pascal] This is probably not entirely true. 6TUS is above 802.15.4 and I expect that the radio NIC will match the MAC destination prior to passing the packet to 6TUS. The proper claim would be that the headers above L2 are not relevant to 6TUS switching operation. This is why I wanted a mcast or brdcast destination for packets that are 6TUS switched; if I'm correct this saves us from updating the destination mac at each hop.

2-As an add-on we are discussing to add support for cell reuse, which won't be the general case or at least not as common as 1). In the case of cell reuse the track-ID will be used as destination address. We are proposing to use a multi-cast destination address when we want to express that a flow can use track-shared cells.

[Pascal] The other way around. The unicast would be for the cuckoo packet that opportunistically surfs the tack for one hop. The dest mac in that case is that of the next hop router. The multicast (or broadcast) is used to indicate that any NIC along the track is supposed to accept the frame and pass it to 6TUS. 6TUS would read the dest MAC and if 1) it is, say 0xFFFF, and 2) the frame was received over a track, it will forward the frame along the track. Otherwise punt to IP.

3-When 6tus has to relay a packet, and has nothing to sent in a particular slot, will pick another packet from a multicast queue which has a multicast address so the resource can be shared.

[Pascal] Again you have the unicast / mcast reversed from the original proposal. The proposal is that highest priority unicast packet for which the next hop router coincides with the next hop of the track is opportunistically placed on the wasted cell... this adds a cell to the bundle between the 2 adjacent routers, but only when there is no received frame along the track.

So when inserting a packet into a queue, if the destination address is the multicast address it will be assigned a different priority than packets with specific destination address, and will be relayed using the bundle of cells that are identified by that multicast address. This means that the switching table needs another field, i.e the track-id which needs to be shared by all the nodes in the track, in that way 6tus, upon receiving a packet in a cell, will look at the input cell, destination address and will find the output cell and will put the packet in the corresponding queue.

[] Making sure we are clear here: The proposal is to reuse the cell for just one hop, not for the final destination. There is already little chance that we have many packets queued with the next hop that coincides with the remote router over the wasted cell.

am I missing something?

[Pascal] Yes, since you had it reversed about the multicast, I think you went through a very different path...

Cheers,

Pascal

Al 04/06/13 08:28, En/na Pascal Thubert (pthubert) ha escrit:
>> I expect that without this proposal, the dest mac of a packet would 
>> be the next L2 node, so that the next hop picks it and passes it to 6TUS layer.
>> dest mac address associated to that track, so the packet is 
>> recognized as receivable by this node at L2 and yet can be forwarded 
>> at 6TUS layer without dest MAC rewrite.
>>
>> Reusing the cell would be the case where this router did not receive 
>> a frame on the track incoming slot, so the outgoing slot will be wasted.
>> figure out that this is not a frame to be switched at 6TUS layer but 
>> a packet to be routed at L3. The trick is that in this case, the 
>> Reusing a cell between 2 tracks is not the idea because there might 
>> be collisions. Here we are talking about using an unsed cell 
>>> We had a great discussion today at the weekly call about routing 
>>> that relies on 1 hop cell bundles vs. switching that operates on end 
>>> to end tracks.
>>>
>>> a) define a multicast mac address for the track, so we can 1) reuse 
>>> a track cell that is not used by a deterministic packet for hop by 
>>> hop

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 04 Jun 2013 15:40:51 -0700

Hi Pascal,
let me argue a little :-)

> [Pascal] This is probably not entirely true. 6TUS is above 802.15.4 and I expect that the radio NIC will match the MAC destination prior to passing the packet to 6TUS. The proper claim would be tha…

I see, however updating next hop is not a problem as in the schedule we 
have thet L2 address the cell is pointing to (in case of tx). So my 
question is now. Is that needed? does it introduce any advantage, does 
it introduce more complexity? note that from the implementation point of 
view by default we rewrite destination (next hop) as this is what it is 
supposed to be done. Having this "special" condition will require 
"special handling". Just thoughts as I am in favour of simple things.
> [Pascal] The other way around. The unicast would be for the cuckoo packet that opportunistically surfs the tack for one hop. The dest mac in that case is that of the next hop router. The multicast…
I see, now. this is considering that we use a multicast address for any 
packet that goes through a label switched path.

> [Pascal] Again you have the unicast / mcast reversed from the original proposal. The proposal is that highest priority unicast packet for which the next hop router coincides with the next hop of th…

Agreed.
> [] Making sure we are clear here: The proposal is to reuse the cell for just one hop, not for the final destination. There is already little chance that we have many packets queued with the next ho…
This is simpler. If hop by hop matches a track then the policy will 
apply at each hop. But this is a particular case and addressing the one 
hop case is more than ok to me.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 4 Jun 2013 23:05:02 +0000

Hi Pascal,

[Pascal] Most certainly!!! Thanks for this...

Hello Xavi:

I see, however updating next hop is not a problem as in the schedule we have thet L2 address the cell is pointing to (in case of tx). So my question is now. Is that needed? does it introduce any advantage, does it introduce more complexity? note that from the implementation point of view by default we rewrite destination (next hop) as this is what it is supposed to be done. Having this "special" condition will require "special handling". Just thoughts as I am in favour of simple things.

[Pascal] We need a bit somewhere below 6TUS to differentiate the native packet that should be forwarded along the track vs. the cuckoo that this proposal injects opportunistic in the wasted cell. This is the main reason for the different destination MAC. Now making it broadcast ensures that the NIC card will read it and pass it up to 6TUS. The optimization of not rewriting the dmac is really a side effect.

[Pascal] The other way around. The unicast would be for the cuckoo packet that opportunistically surfs the tack for one hop. The dest mac in that case is that of the next hop router. The multicast (or broadcast) is used to indicate that any NIC along the track is supposed to accept the frame and pass it to 6TUS. 6TUS would read the dest MAC and if 1) it is, say 0xFFFF, and 2) the frame was received over a track, it will forward the frame along the track. Otherwise punt to IP.
I see, now. this is considering that we use a multicast address for any packet that goes through a label switched path.

Agreed.

[] Making sure we are clear here: The proposal is to reuse the cell for just one hop, not for the final destination. There is already little chance that we have many packets queued with the next hop that coincides with the remote router over the wasted cell.
This is simpler. If hop by hop matches a track then the policy will apply at each hop. But this is a particular case and addressing the one hop case is more than ok to me.

[] Very cool :)

Pascal

am I missing something?

Cheers,

Pascal

Hello Qin:

  : )

Pascal

Hello Qin:

Makes sense?

Pascal

-----Original Message-----

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

Hi Pascal,

two tracks. Correct?

Thanks

Qin

Dear all ;

to end tracks.

hop

and

address,

Comments welcome!

Cheers,

Pascal

6tsch mailing list

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

6tsch mailing list

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

6tsch mailing list

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

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 4 Jun 2013 17:28:06 -0700

Wait, wait, Let me join the argument!

I feel like maintaining a track_ID is a complex thing to do. We will have
problems related to of spatial ID reuse, stale information, etc. Yes, there
are techniques to handle those cases, but for sure the simplest thing is
avoiding it altogether.

So what about this (slight variation of what was said, probably nothing
new):
- Tracks are installed as we always have assumed: dedicated unicast cells
put back-to-back, implicit label switching, bundle-in-bundle-out switching
table. *But*, the MAC destination address of all packets is the broadcast
address. That is, "broadcast destination==switch along track".
- if a cell in the track is not used, and there is a packet in the sender's
queue which could use it, it uses the cell, but in that case the MAC
destination address is the next hop's MAC address. That is, "unicast
destination==send up the stack".

IMO, this is the simplest solution, and does not require any track IDs.
However, if we decide to do so, it will be hard to make this optional,
since we are changing the well-known behavior of destination MAC address.

Thomas

On Tue, Jun 4, 2013 at 4:05 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  ** **
> ** **
> ****
> *[Pascal] Most certainly!!! Thanks for this…*
>
> * *
>
>
> Al 04/06/13 15:22, En/na Pascal Thubert (pthubert) ha escrit:****
>
> Hello Xavi:****
>
> ** **
>
> 1-The general case of Packet Switching at L2.5 will not use any header. ****
>
> The PCE will install the mappings between input and output cells and tracks will be tight water pipes. (no sharing of resources). Forwarding will be done by 6tus, i.e looking input cell into the table and inserting the packet in the corresponding queue so it can be relayed at the appropriate output cell.****
>
> ** **
>
> [Pascal] This is probably not entirely true. 6TUS is above 802.15.4 and I expect that the radio NIC will match the MAC destination prior to passing the packet to 6TUS. The proper claim would be that the headers above L2 are not relevant to 6TUS switching operation. This is why I wanted a mcast or brdcast destination for packets that are 6TUS switched; if I'm correct this saves us from updating the destination mac at each hop. ****
>
>
> question is now. Is that needed? does it introduce any advantage, does it
> introduce more complexity? note that from the implementation point of view
> by default we rewrite destination (next hop) as this is what it is supposed
> to be done. Having this "special" condition will require "special
> handling". Just thoughts as I am in favour of simple things.
>
> ****
>
> ** **
>
> *[Pascal] We need a bit somewhere below 6TUS to differentiate the native packet that should be forwarded along the track vs. the cuckoo that this proposal injects opportunistic in the wasted cell. This is the main reason for the different destination MAC. Now making it broadcast ensures that the NIC card will read it and pass it up to 6TUS. The optimization of not rewriting the dmac is really a side effect.*****
>
>  ** **
>
> 2-As an add-on we are discussing to add support for cell reuse, which won't be the general case or at least not as common as 1). In the case of cell reuse the track-ID will be used as destination address. We are proposing to use a multi-cast destination address when we want to express that a flow can use track-shared cells.****
>
> ** **
>
> [Pascal] The other way around. The unicast would be for the cuckoo packet that opportunistically surfs the tack for one hop. The dest mac in that case is that of the next hop router. The multicast (or broadcast) is used to indicate that any NIC along the track is supposed to accept the frame and pass it to 6TUS. 6TUS would read the dest MAC and if 1) it is, say 0xFFFF, and 2) the frame was received over a track, it will forward the frame along the track. Otherwise punt to IP.****
>
> ****
> ** **
> 3-When 6tus has to relay a packet, and has nothing to sent in a particular slot, will pick another packet from a multicast queue which has a multicast address so the resource can be shared.****
>
> ** **
>
> [Pascal] Again you have the unicast / mcast reversed from the original proposal. The proposal is that highest priority unicast packet for which the next hop router coincides with the next hop of the track is opportunistically placed on the wasted cell... this adds a cell to the bundle between the 2 adjacent routers, but only when there is no received frame along the track.****
>
>
> Agreed.
>
> ****
>
> ** **
>
> So when inserting a packet into a queue, if the destination address is the multicast address it will be assigned a different priority than packets with specific destination address, and will be relayed using the bundle of cells that are identified by that multicast address. This means that the switching table needs another field, i.e the track-id which needs to be shared by all the nodes in the track, in that way 6tus, upon receiving a packet in a cell, will look at the input cell, destination address and will find the output cell and will put the packet in the corresponding queue.****
>
> ** **
>
> [] Making sure we are clear here: The proposal is to reuse the cell for just one hop, not for the final destination. There is already little chance that we have many packets queued with the next hop that coincides with the remote router over the wasted cell.****
>
> This is simpler. If hop by hop matches a track then the policy will apply
> at each hop. But this is a particular case and addressing the one hop case
> is more than ok to me.
>
> ****
>
> ** **
>
> *[] Very cool **J***
>
>  * *
>
> *Pascal*****
>
>  ** **
>
> am I missing something?****
>
> ** **
>
> [Pascal] Yes, since you had it reversed about the multicast, I think you went through a very different path...****
>
>  ** **
>
> Cheers,****
>
> ** **
>
> Pascal****
>
> ** **
>
> ** **
>
> Al 04/06/13 08:28, En/na Pascal Thubert (pthubert) ha escrit:****
>
>  Hello Qin:****
>
> ** **
>
> It makes sense to me. I want to confirm my understanding further.****
>
> ** **
>
> (1) Regarding the multicast address, it functions as a track-ID, or a label of a reserved route in layer 2.5. Correct?****
>
> ** **
>
> [Pascal] Yes, that would be an added value. The main goal is to make sure that any intermediate node accepts the packet. Alternatively we could use broadcast (0xFFFF) on all the tracks but then we need to make sure that the node only forwards along the track.****
>
> ** **
>
> (2) Regarding to reusing cell, it supports multiple queues with different QoS, saying the packets associated with the track has higher priority, and the best effort packets has lower priority. Correct?****
>
> ** **
>
> [Pascal] Actually the prioritization and packet drop management is done at L3. If we have received a packet along the track, then that packet goes out next, with no control from IP. But if there was no packet in along the track at the current iteration of the schedule, then we have one free cell for that iteration. What we can do at 6TUS layer is add that particular cell in that particular iteration of the schedule to the bundle that is used for L3 as link to the next hop router. When the cell time arrives, we pick the highest priority packet from the L3 outgoing queue on the link towards the particular next hop of that cell and transmit. The next hop router can pick that packet and punt it.****
>
> ** **
>
> If my understanding is correct, a parameter like trackID (which will be used as multicast address) may be needed in the cell reservation related commands of 6tus.****
>
> ** **
>
> [Pascal] I think that could be useful.****
>
> ** **
>
>   : )****
>
>   ****
>
> Pascal****
>
> ** **
>
> ** **
>
> ** **
>
>  Hello Qin:****
>
> ** **
>
> I expect that without this proposal, the dest mac of a packet would ****
>
> be the next L2 node, so that the next hop picks it and passes it to 6TUS layer.****
>
> With the proposal, all nodes along a track would accept the multicast ****
>
> dest mac address associated to that track, so the packet is ****
>
> recognized as receivable by this node at L2 and yet can be forwarded ****
>
> at 6TUS layer without dest MAC rewrite.****
>
> ** **
>
> Reusing the cell would be the case where this router did not receive ****
>
> a frame on the track incoming slot, so the outgoing slot will be wasted.****
>
> If we have a packet for which the next hop the same router as the ****
>
> receiver of the wasted cell, then we'd want to use the cell to ****
>
> progress the packet one hop. But then the receiver router needs to ****
>
> figure out that this is not a frame to be switched at 6TUS layer but ****
>
> a packet to be routed at L3. The trick is that in this case, the ****
>
> destination MAC address would be effectively that of the receiver ****
>
> router so 6TUS would punt the packet to L3.****
>
> ** **
>
> Reusing a cell between 2 tracks is not the idea because there might ****
>
> be collisions. Here we are talking about using an unsed cell ****
>
> opportunistically for L3 best effort traffic. If there is an unused ****
>
> track cell, it adds up to the bundle between the 2 adjacent routers ****
>
> for that particular slotframe.****
>
> ** **
>
> Makes sense?****
>
> ** **
>
> Pascal****
>
> ** **
>
> ** **
>
> -----Original Message-----****
>
> From: Qin Wang [mailto:[email-masked] <[email-masked]>]****
>
> Sent: lundi 3 juin 2013 13:14****
>
> To: Pascal Thubert (pthubert)****
>
> Cc: [email-masked]****
>
> Subject: Re: [6tsch] Routing vs. switching****
>
> ** **
>
> Hi Pascal,****
>
> ** **
>
> I don't understand strategy a) clearly. According to my understanding ****
>
> on "Track", it consists of a sequence of cells along a multihop path, ****
>
> and there is one and only one cell for a pair of nodes (i.e. fixed ****
>
> next hop neighbor). Then, how does multicast Mac address function?****
>
> What do you mean by reusing a cell?****
>
> ** **
>
> I guess that the strategy a) will be used to solve the problem of ****
>
> (A->C->B, D->C->E). That is, there is a cell in node-C with multicast ****
>
> address to both node-B and node-E. So, the cell can be reused in the ****
>
> two tracks. Correct?****
>
> ** **
>
> Thanks****
>
> Qin****
>
> ** **
>
> ** **
>
>  Dear all ;****
>
> ** **
>
> We had a great discussion today at the weekly call about routing ****
>
> that relies on 1 hop cell bundles vs. switching that operates on end ****
>
> to end tracks.****
>
> ** **
>
> We agreed that merging and splitting tracks could require queuing at ****
>
> intermediate nodes to absorb burst collisions from multiple sources ****
>
> and decided to go for the watertight pipes.****
>
> ** **
>
> We proposed 2 additional strategies:****
>
> ** **
>
> a) define a multicast mac address for the track, so we can 1) reuse ****
>
> a track cell that is not used by a deterministic packet for hop by ****
>
> hop****
>
> L3 traffic as differentiated by its unicast MAC destination and 2) ****
>
> forward with no change to the destination.****
>
> ** **
>
> b) let the PCE install routes as well as tracks. With that strategy, ****
>
> A PCE route is an alternate to a track that would allow cell reuse ****
>
> and****
>
> L3 QoS operation. We leverage the deterministic Class of service ****
>
> (that's Deterministic Forwarding, DF, though encoded 0xEF). And we ****
>
> can emulate RPL local instances as indexed by the tuple (source ****
>
> address,****
>
> local_instance_id) and forward the packet with the same rules are ****
>
> RPL, along the routing table indexed by the instance ID.****
>
> ** **
>
> Comments welcome!****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Pascal****
>
> _______________________________________________****
>
> 6tsch mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>
>  ** **
>
>  _______________________________________________****
>
> 6tsch mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>  ** **
>
> _______________________________________________****
>
> 6tsch mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>  ** **
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 04 Jun 2013 20:27:45 -0400

I think that Xavi was quoted by Pascal saying:
   xavi> 1-The general case of Packet Switching at L2.5 will not
   xavi> use any header.  
   xavi> The PCE will install the mappings between input and output
   xavi> cells and tracks will be tight water pipes. (no sharing of
   xavi> resources). Forwarding will be done by 6tus, i.e looking
   xavi> input cell into the table and inserting the packet in the
   xavi> corresponding queue so it can be relayed at the
   xavi> appropriate output cell. 

So, if one wants to model this, take each track as a seperate (point
to point?!) virtual interface with a per-interface forwarding table.

   pthubert> This is probably not entirely true. 6TUS is above 802.15.4
   pthubert> and I expect that the radio NIC will match the MAC
   pthubert> destination prior to passing the packet to 6TUS. 

Yes, that's true...  I thought that Xavi meant that no additional header
would be necessary.  We might not even need the IPv6 HBH header to
indicate the instanceID.

   pthubert> claim would be that the headers above L2 are not relevant
   pthubert> to 6TUS switching operation. This is why I wanted a mcast
   pthubert> or brdcast destination for packets that are 6TUS switched;
   pthubert> if I'm correct this saves us from updating the destination
   pthubert> mac at each hop. 

That's an interesting idea.

    pthubert> [Pascal] Again you have the unicast / mcast reversed from
    pthubert> the original proposal. The proposal is that highest
    pthubert> priority unicast packet for which the next hop router
    pthubert> coincides with the next hop of the track is
    pthubert> opportunistically placed on the wasted cell... this adds a
    pthubert> cell to the bundle between the 2 adjacent routers, but
    pthubert> only when there is no received frame along the track. 

nice.  I am concerned that it pushes buffer usage upwards in the DODAG,
and this might exhaust something higher up, rather than have the packet
die lower down.  I don't know that this matters, but it might an energy
issue, I haven't thought about this a lot yet.

    pthubert> [] Making sure we are clear here: The proposal is to reuse
    pthubert> the cell for just one hop, not for the final
    pthubert> destination. There is already little chance that we have
    pthubert> many packets queued with the next hop that coincides with
    pthubert> the remote router over the wasted cell. 

How does the receiver know that this is a opportunistic use of the track?

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 04 Jun 2013 17:47:03 -0700

I like that idea (+1).

  I am only worried about the "implicit knowledge" that we are 
introducing, i.e L2.5 knows that broadcast packets pertain to a track.. 
I am afraid that this knowledge is not strong enough to prevent strange 
things happening.. Ex: a node decides to broadcast a data packet (not 
sure if it is a real case), and this data packet is transported to some 
edge of the network while the purpose was to broadcast something to 
neighbours.  As I said, not sure if this is a real case.

Besides, the constrain to determine if a packet is for a label switched 
track or not should be destination address == broadcast and frame type 
==DATA. We don't want to label switch commands or beacons right?

regards,
Xavi

Al 04/06/13 17:28, En/na Thomas Watteyne ha escrit:
> I feel like maintaining a track_ID is a complex thing to do. We will 
> have problems related to of spatial ID reuse, stale information, etc. 
> Yes, there are techniques to handle those cases, but for sure the 
> simplest thing is avoiding it altogether.
>
> So what about this (slight variation of what was said, probably 
> nothing new):
> - Tracks are installed as we always have assumed: dedicated unicast 
> cells put back-to-back, implicit label switching, bundle-in-bundle-out 
> switching table. _But_, the MAC destination address of all packets is 
> the broadcast address. That is, "broadcast destination==switch along 
> track".
> - if a cell in the track is not used, and there is a packet in the 
> sender's queue which could use it, it uses the cell, but in that case 
> the MAC destination address is the next hop's MAC address. That is, 
> "unicast destination==send up the stack".
>
> IMO, this is the simplest solution, and does not require any track 
> IDs. However, if we decide to do so, it will be hard to make this 
> optional, since we are changing the well-known behavior of destination 
> MAC address.
>
> Thomas
>
>
> On Tue, Jun 4, 2013 at 4:05 PM, Pascal Thubert (pthubert) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Pascal,
>     */[Pascal] Most certainly!!! Thanks for this.../*
>
>     *//*
>
>
>     I see, however updating next hop is not a problem as in the
>     schedule we have thet L2 address the cell is pointing to (in case
>     of tx). So my question is now. Is that needed? does it introduce
>     any advantage, does it introduce more complexity? note that from
>     the implementation point of view by default we rewrite destination
>     (next hop) as this is what it is supposed to be done. Having this
>     "special" condition will require "special handling". Just thoughts
>     as I am in favour of simple things.
>
>       
>
>     */[Pascal] We need a bit somewhere below 6TUS to differentiate the native packet that should be forwarded along the track vs. the cuckoo that this proposal injects opportunistic in the wasted cell. This is the main reason for the different destination MAC. Now making it broadcast ensures that the NIC card will read it and pass it up to 6TUS. The optimization of not rewriting the dmac is really a side effect./*
>
>       
>
>     I see, now. this is considering that we use a multicast address
>     for any packet that goes through a label switched path.
>
>
>       
>
>     This is simpler. If hop by hop matches a track then the policy
>     will apply at each hop. But this is a particular case and
>     addressing the one hop case is more than ok to me.
>
>       
>
>     */[] Very cool/**/J/**//*
>
>     */  /*
>
>     */Pascal/*
>
>       
>
>     am I missing something?
>
>       
>
>                 Cc:[email-masked]  <mailto:[email-masked]>
>
>                     [email-masked]  <mailto:[email-masked]>
>
>             [email-masked]  <mailto:[email-masked]>
>
>         [email-masked]  <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>

---

From: "Qin Wang" <[email-masked]>
Date: Tue, 4 Jun 2013 18:36:19 -0700

Hi Thomas,

Although I haven't had good way to maintaining track-ID, I'm wondering how
to install a Track and dedicate the track to a specific packet stream
without a track-ID. Let me explain what my concern is.

With 6tus commands, a set of cells are installed in a node, saying 4
cells, in which we want cell-1 belong to Track-1, cell-2 belong to
Track-2, and cell-3,4 be cells for the best effort packets. Without
track-ID, how does 6tus know the usage of each cell?

Do I miss something?

Qin

> sender's
>> the appropriate output cell.****
>>
>> ** **
>>
>> [Pascal] This is probably not entirely true. 6TUS is above 802.15.4 and
>> I expect that the radio NIC will match the MAC destination prior to
>> passing the packet to 6TUS. The proper claim would be that the headers
>> above L2 are not relevant to 6TUS switching operation. This is why I
>> wanted a mcast or brdcast destination for packets that are 6TUS
>> switched; if I'm correct this saves us from updating the destination mac
>> at each hop. ****
>>
>>
>> it
>> *[Pascal] We need a bit somewhere below 6TUS to differentiate the native
>> packet that should be forwarded along the track vs. the cuckoo that this
>> proposal injects opportunistic in the wasted cell. This is the main
>> reason for the different destination MAC. Now making it broadcast
>> ensures that the NIC card will read it and pass it up to 6TUS. The
>> optimization of not rewriting the dmac is really a side effect.*****
>>
>>  ** **
>>
>> express that a flow can use track-shared cells.****
>>
>> ** **
>>
>> [Pascal] The other way around. The unicast would be for the cuckoo
>> packet that opportunistically surfs the tack for one hop. The dest mac
>> in that case is that of the next hop router. The multicast (or
>> broadcast) is used to indicate that any NIC along the track is supposed
>> to accept the frame and pass it to 6TUS. 6TUS would read the dest MAC
>> and if 1) it is, say 0xFFFF, and 2) the frame was received over a track,
>> it will forward the frame along the track. Otherwise punt to IP.****
>>
>> has a multicast address so the resource can be shared.****
>>
>> ** **
>>
>> [Pascal] Again you have the unicast / mcast reversed from the original
>> proposal. The proposal is that highest priority unicast packet for which
>> the next hop router coincides with the next hop of the track is
>> opportunistically placed on the wasted cell... this adds a cell to the
>> bundle between the 2 adjacent routers, but only when there is no
>> received frame along the track.****
>>
>>
>> Agreed.
>>
>> ****
>>
>> ** **
>>
>> packet in the corresponding queue.****
>>
>> ** **
>>
>> [] Making sure we are clear here: The proposal is to reuse the cell for
>> just one hop, not for the final destination. There is already little
>> chance that we have many packets queued with the next hop that coincides
>> with the remote router over the wasted cell.****
>>
>> apply
>> [Pascal] Yes, since you had it reversed about the multicast, I think you
>> went through a very different path...****
>>
>>  ** **
>>
>> Cheers,****
>>
>> ** **
>>
>> Pascal****
>>
>> ** **
>>
>> ** **
>>
>> label of a reserved route in layer 2.5. Correct?****
>>
>> ** **
>>
>> [Pascal] Yes, that would be an added value. The main goal is to make
>> sure that any intermediate node accepts the packet. Alternatively we
>> could use broadcast (0xFFFF) on all the tracks but then we need to make
>> sure that the node only forwards along the track.****
>>
>> ** **
>>
>> (2) Regarding to reusing cell, it supports multiple queues with
>> different QoS, saying the packets associated with the track has higher
>> priority, and the best effort packets has lower priority. Correct?****
>>
>> ** **
>>
>> [Pascal] Actually the prioritization and packet drop management is done
>> at L3. If we have received a packet along the track, then that packet
>> goes out next, with no control from IP. But if there was no packet in
>> along the track at the current iteration of the schedule, then we have
>> one free cell for that iteration. What we can do at 6TUS layer is add
>> that particular cell in that particular iteration of the schedule to the
>> bundle that is used for L3 as link to the next hop router. When the cell
>> time arrives, we pick the highest priority packet from the L3 outgoing
>> queue on the link towards the particular next hop of that cell and
>> transmit. The next hop router can pick that packet and punt it.****
>>
>> ** **
>>
>> commands of 6tus.****

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 10 Jun 2013 17:52:02 -0700

Qin,

I believe that we agree that this track ID is not some number which goes
into a header, i.e. it's not something you send over the air. Agreed?

If we agree, what it then is is simply an "administrative" number of
represent a track. In that case, can we not use the ID of the slotframe?
(maybe not)

Thomas

---

From: "Qin Wang" <[email-masked]>
Date: Thu, 13 Jun 2013 11:19:21 -0700

Thomas,

I agree the track-ID is not a number in a header. But, it may not be a ID
of slotframe. In my mind, a slotframe can include more than one Track,
just like that shown in
https://bitbucket.org/6tsch/meetings/src/5b67d87897b4d6f90657483b9458b832bf969d4d/130607_webex/slides_130607_webex.ppt?at=master#

How do you think?

Qin

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 17 Jun 2013 22:14:10 -0700

Agreed,