Subject: [6tsch] recycle unused track cells (was: Routing vs. switching)

From: Thomas Watteyne <[email-masked]>
Date: Mon, 3 Jun 2013 19:47:02 -0700

Pascal,

I agree that a single bit is enough to differentiate between switched
packets and routed packets. During the call on Friday, we identified 3
locations where that bit could live:
- somewhere in the 6LoWPAN header. Too high?
- as an IEEE802.15.4e IE: too many bytes for a single bit?
- represented by the fact that the destination MAC address is a broadcast
address.

Agreed?

In the latter case, what would a multicast MAC address look like? Assuming
we're using long addresses address, we could set the multicast bit in the
EUI64. Are you imagining having the next hop address with that bit set, or
assigning a specific track identifier, encoded as a multicast address?

Also, once the network is running, I'm assuming we will be using short 2B
addresses. It's not clear how we can fit the multicast bit in there.

Thomas

On Mon, Jun 3, 2013 at 3:08 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> 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
>
>
> > 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
>

---

From: Pascal Thubert <[email-masked]>
Date: Mon, 3 Jun 2013 21:30:58 -0700

Hello Thomas:

Le 3 juin 2013 à 19:47, Thomas Watteyne <[email-masked]> a écrit :

> Pascal,
> 
> I agree that a single bit is enough to differentiate between switched packets and routed packets. During the call on Friday, we identified 3 locations where that bit could live:
> - represented by the fact that the destination MAC address is a broadcast address.
> 
> Agreed?
> 

So far so good

> In the latter case, what would a multicast MAC address look like? Assuming we're using long addresses address, we could set the multicast bit in the EUI64. Are you imagining having the next hop address with that bit set, or assigning a specific track identifier, encoded as a multicast address?
> 

I thought the latter to be honest. Elsevit could have been based on the destination address. Nothing cast in stone at the moment, rather opening possibilities.

> Also, once the network is running, I'm assuming we will be using short 2B addresses. It's not clear how we can fit the multicast bit in there.
> 

That´s the beauty of GMPLS... 

We can reserve one single well-known value of a short address to mean "the mcast address of the track" in a compressed form, can´t we?

Cheers,

Pascal

> Thomas
> 
> On Mon, Jun 3, 2013 at 3:08 PM, Pascal Thubert (pthubert) <[email-masked]> wrote:
>> 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
>> 
>> 
>> 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 ;
>> >

---

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

On the side, Thomas,

We have to expect that the dest MAC may be used by 6LoWPAN to uncompress the dest IP if the node at the end of the track is the destination.

It would make sense that the track metadata indicates that the 6TUS should rewrite the dmac before punting and which mac should be used.

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: lundi 3 juin 2013 19:47
To: [email-masked]
Subject: [6tsch] recycle unused track cells (was: Routing vs. switching)

Pascal,

Agreed?

Thomas

On Mon, Jun 3, 2013 at 3:08 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Qin:

Makes sense?

Pascal

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

Hi Pascal,

Thanks
Qin

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

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

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 6 Jun 2013 10:08:39 -0700

Pascal,

Completely agree, we cannot loose the MAC destination address information
altogether. I'm wondering if this could not be recreated on-the-fly by the
end node of the track.

That is, assuming the following track
A->B->C->D
i.e. D is the last hop

C could still use bcast dmac, D would just replace it by its own MAC when
inflating 6LoWPAN.

I assume this is similar to what you had in mind?

Thomas

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

>  On the side, Thomas,****
>
> ** **
>
> We have to expect that the dest MAC may be used by 6LoWPAN to uncompress
> the dest IP if the node at the end of the track is the destination.****
>
> ** **
>
> It would make sense that the track metadata indicates that the 6TUS should
> rewrite the dmac before punting and which mac should be used.****
>
> ** **
>
> Cheers,****
>
> ** **
>
> Pascal****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Thomas Watteyne
> *Sent:* lundi 3 juin 2013 19:47
> *To:* [email-masked]
> *Subject:* [6tsch] recycle unused track cells (was: Routing vs. switching)
> ****
>
> ** **
>
> Pascal,****
>
> ** **
>
> locations where that bit could live:****
>
> - somewhere in the 6LoWPAN header. Too high?****
>
> - as an IEEE802.15.4e IE: too many bytes for a single bit?****
>
> address.****
> ** **
> Agreed?****
> ** **
> assigning a specific track identifier, encoded as a multicast address?****
>
> ** **
>
> addresses. It's not clear how we can fit the multicast bit in there.****
>
> ** **
>
> Thomas****
>
> ** **
>
> [email-masked]> wrote:****
>
> Hello Qin:
>
> Pascal****
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Jun 2013 17:35:32 +0000

Perfect sync : )

The key is that D knows from the track meta that it is the end point and that the mac address is expected to be a certain mac address, whether that's expressed in compressed as 2 or 8 bytes.
It is important that there is no confusion possible between what the sender at the ingress of the track thinks the mac and IP are and what the receiver thinks at the other end. Since even the short address is now lost, we need to enforce that the track endpoint mac address is known and checked at ingress, and known and overwritten at egress as you detail below.

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: jeudi 6 juin 2013 10:09
To: [email-masked]
Subject: Re: [6tsch] recycle unused track cells (was: Routing vs. switching)

Pascal,

Completely agree, we cannot loose the MAC destination address information altogether. I'm wondering if this could not be recreated on-the-fly by the end node of the track.

C could still use bcast dmac, D would just replace it by its own MAC when inflating 6LoWPAN.

Thomas

On Tue, Jun 4, 2013 at 4:14 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
On the side, Thomas,

Cheers,

Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Thomas Watteyne
Sent: lundi 3 juin 2013 19:47
To: [email-masked]<mailto:[email-masked]>
Subject: [6tsch] recycle unused track cells (was: Routing vs. switching)

Pascal,

Agreed?

Thomas

Makes sense?

Pascal

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

Hi Pascal,

Thanks
Qin

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 06 Jun 2013 11:03:22 -0700

Hi,

maybe I am missing something:

"Since even the short address is now lost, we need to enforce that the 
track endpoint mac address is known and checked at ingress, and known 
and overwritten at egress as you detail below."

are we sure that this is needed? As the PCE installs the tracks and the 
PCE knows what is doing, forwarding can be done blindly right? A node 
knows that it is the end of the track because in its forwarding table 
there is no mapping for that input bundle. (No forwarding), so checking 
seems no needed as nodes can trust whatever the PCE installs. So, an 
node that does not have a forwarding entry on the table just pushes up 
the packet to 6lowpan and puts its MAC address on the destination mac of 
the receive packet.

:-)
X

Al 06/06/13 10:35, En/na Pascal Thubert (pthubert) ha escrit:
>
> Perfect sync : )
>
> The key is that D knows from the track meta that it is the end point 
> and that the mac address is expected to be a certain mac address, 
> whether that's expressed in compressed as 2 or 8 bytes.
>
> It is important that there is no confusion possible between what the 
> sender at the ingress of the track thinks the mac and IP are and what 
> the receiver thinks at the other end. Since even the short address is 
> now lost, we need to enforce that the track endpoint mac address is 
> known and checked at ingress, and known and overwritten at egress as 
> you detail below.
>
> Cheers,
>
> Pascal
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Thomas Watteyne
> *Sent:* jeudi 6 juin 2013 10:09
> *To:* [email-masked]
> *Subject:* Re: [6tsch] recycle unused track cells (was: Routing vs. 
> switching)
>
> Pascal,
>
> Completely agree, we cannot loose the MAC destination address 
> information altogether. I'm wondering if this could not be recreated 
> on-the-fly by the end node of the track.
>
> On Tue, Jun 4, 2013 at 4:14 PM, Pascal Thubert (pthubert) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> On the side, Thomas,
>
> We have to expect that the dest MAC may be used by 6LoWPAN to 
> uncompress the dest IP if the node at the end of the track is the 
> destination.
>
> It would make sense that the track metadata indicates that the 6TUS 
> should rewrite the dmac before punting and which mac should be used.
>
> Cheers,
>
> Pascal
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]>] *On 
> Behalf Of *Thomas Watteyne
> *To:* [email-masked] <mailto:[email-masked]>
> In the latter case, what would a multicast MAC address look like? 
> Assuming we're using long addresses address, we could set the 
> multicast bit in the EUI64. Are you imagining having the next hop 
> address with that bit set, or assigning a specific track identifier, 
> encoded as a multicast address?
>
> Also, once the network is running, I'm assuming we will be using short 
> 2B addresses. It's not clear how we can fit the multicast bit in there.
>
> Thomas
>
> On Mon, Jun 3, 2013 at 3:08 PM, Pascal Thubert (pthubert) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> 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.
>
> 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: Qin Wang [mailto:[email-masked] <mailto:[email-masked]>]
> Cc: [email-masked] <mailto:[email-masked]>
> 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 ;
> >
> > [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Jun 2013 18:17:22 +0000

Hello Xavi:

It certainly can work without any check, but it's probably good to have one. Say the MAC changes, or there is a change of path, or anything.
When we did 6LoWPAN compression, in particular for the UDP checksum, we were very conscious that we were removing some safe guards. You can't remove them all...

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: jeudi 6 juin 2013 11:03
To: [email-masked]
Subject: Re: [6tsch] recycle unused track cells (was: Routing vs. switching)

Hi,

"Since even the short address is now lost, we need to enforce that the track endpoint mac address is known and checked at ingress, and known and overwritten at egress as you detail below."

are we sure that this is needed? As the PCE installs the tracks and the PCE knows what is doing, forwarding can be done blindly right? A node knows that it is the end of the track because in its forwarding table there is no mapping for that input bundle. (No forwarding), so checking seems no needed as nodes can trust whatever the PCE installs. So, an node that does not have a forwarding entry on the table just pushes up the packet to 6lowpan and puts its MAC address on the destination mac of the receive packet.

:-)
X

Cheers,

Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: jeudi 6 juin 2013 10:09
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tsch] recycle unused track cells (was: Routing vs. switching)

Pascal,

Thomas

Cheers,

Pascal

Pascal,

Agreed?

Thomas

Makes sense?

Pascal

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

Hi Pascal,

Thanks
Qin

6tsch mailing list

---

From: "Qin Wang" <[email-masked]>
Date: Thu, 6 Jun 2013 12:33:12 -0700

Hi Pascal, Xavi, and all,

I want to confirm the concept of Track and its establishment, because what
we are talking about here are highly related with the interpretation of
Track.

My understanding about Track comes from the
draft-palattella-6tsch-terminology-01, i.e. "A determined sequence of
cells along a multi-hop path.
This is typically the result of a reservation."

But I feel the Track being talked about here implies more than it. I guess
the establishment of a Track not only involves a schedule built with cell
command, but also involves a mapping table which is established via the
new command "Label switching command". Correct?

If yes, I will agree with Thomas that we don't need a track-ID. But, it
may arise another question, i.e. should a mapping table be applied to a
schedule built with soft-cell command?

Thanks
Qin

> Hello Xavi:
>
> It certainly can work without any check, but it's probably good to have
> one. Say the MAC changes, or there is a change of path, or anything.
> When we did 6LoWPAN compression, in particular for the UDP checksum, we
> were very conscious that we were removing some safe guards. You can't
> remove them all...
>
> Cheers,
>
> Pascal
>
> track endpoint mac address is known and checked at ingress, and known and
> overwritten at egress as you detail below."
>
> seems no needed as nodes can trust whatever the PCE installs. So, an node
> that does not have a forwarding entry on the table just pushes up the
> packet to 6lowpan and puts its MAC address on the destination mac of the
> receive packet.
>
> :-)
> X
>
>
>
>
> The key is that D knows from the track meta that it is the end point and
> that the mac address is expected to be a certain mac address, whether
> that's expressed in compressed as 2 or 8 bytes.
> sender at the ingress of the track thinks the mac and IP are and what the
> receiver thinks at the other end. Since even the short address is now
> lost, we need to enforce that the track endpoint mac address is known and
> checked at ingress, and known and overwritten at egress as you detail
> below.
>
> Cheers,
>
> Pascal
>
> From: [email-masked]<mailto:[email-masked]>
> [mailto:[email-masked]] On Behalf Of Thomas Watteyne
> <[email-masked]<mailto:[email-masked]>> wrote:
> On the side, Thomas,
>
> the dest IP if the node at the end of the track is the destination.
>
> rewrite the dmac before punting and which mac should be used.
>
> Cheers,
>
> Pascal
>
> From: [email-masked]<mailto:[email-masked]>
> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of Thomas Watteyne
> <[email-masked]<mailto:[email-masked]>> wrote:
> Hello Qin:
>
> 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: Thomas Watteyne <[email-masked]>
Date: Mon, 10 Jun 2013 18:04:06 -0700

Qin,

I believe that you are thinking about the case where a distributed
scheduler allocates some (soft) cells along a track. I don't see any reason
to limit the use of 6tus-based switching to hard cells only. While it makes
most sense to do 6tus-based track installation and switching in the
presence of a PCE (i.e. fully deterministic behavior), I would keep the
"switching vs routing" and "hard vs soft cells" distinction orthogonal.

Makes sense?

Thomas

On Thu, Jun 6, 2013 at 12:33 PM, Qin Wang <[email-masked]> wrote:

> > From: [email-masked] [mailto:[email-masked]] On Behalf
> Of
> > Xavier Vilajosana
> should
> Assuming
> the
> dest
> > From: Qin Wang [mailto:[email-masked]<mailto:[email-masked]
> >]

---

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

Thomas,

I think that from "switching vs routing" point of view, soft cell and hard
cell are same. The problem we have to address is how to establish a track
in distributed way. The current soft cell related commands may not be
enough.

Thought?
Qin

>> and
>> node
>> and
>> information
>> uncompress
>> > EUI64. Are you imagining having the next hop address with that bit
>> set,
>> or
>> 2B
>> If
>> > we have a packet for which the next hop the same router as the
>> receiver
>> of
>> > effectively that of the receiver router so 6TUS would punt the packet
>> to
>> > L3.
>> >
>> track
>> > From: Qin Wang
>> [mailto:[email-masked]<mailto:[email-masked]
>> >]
>> on
>> two