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

[Thomas Watteyne <[e-mail]>]

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
>