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

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

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





> 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 <[e-mail]> wrote:
>
>> 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
>> >
>>
>> _______________________________________________
>> 6tsch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
> _______________________________________________
> 6tsch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tsch
>