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

["Qin Wang" <[e-mail]>]

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
>
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Xavier Vilajosana
> Sent: jeudi 6 juin 2013 11:03
> To: [e-mail]
> Subject: Re: [6tsch] recycle unused track cells (was: Routing vs.
> switching)
>
> 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: [e-mail]<mailto:[e-mail]>
> [mailto:[e-mail]] On Behalf Of Thomas Watteyne
> Sent: jeudi 6 juin 2013 10:09
> To: [e-mail]<mailto:[e-mail]>
> 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.
>
> 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)
> <[e-mail]<mailto:[e-mail]>> 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: [e-mail]<mailto:[e-mail]>
> [mailto:[e-mail]<mailto:[e-mail]>] On Behalf
> Of Thomas Watteyne
> Sent: lundi 3 juin 2013 19:47
> To: [e-mail]<mailto:[e-mail]>
> Subject: [6tsch] recycle unused track cells (was: Routing vs. switching)
>
> 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)
> <[e-mail]<mailto:[e-mail]>> 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:[e-mail]<mailto:[e-mail]>]
> Sent: lundi 3 juin 2013 13:14
> To: Pascal Thubert (pthubert)
> Cc: [e-mail]<mailto:[e-mail]>
> 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
>> [e-mail]<mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>
> _______________________________________________
> 6tsch mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/6tsch
>
>
>
>
>
>
> _______________________________________________
>
> 6tsch mailing list
>
> [e-mail]<mailto:[e-mail]>
>
> https://www.ietf.org/mailman/listinfo/6tsch
>
> _______________________________________________
> 6tsch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tsch
>