Re: [6tsch] recycle unused track cells (was: Routing vs. switching)
"Qin Wang" <qinwang@berkeley.edu> Thu, 13 June 2013 18:27 UTC
Return-Path: <qinwang@berkeley.edu>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3284521F9A6D for <6tsch@ietfa.amsl.com>; Thu, 13 Jun 2013 11:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04zbvsc+KPhZ for <6tsch@ietfa.amsl.com>; Thu, 13 Jun 2013 11:27:47 -0700 (PDT)
Received: from cm06fe.IST.Berkeley.EDU (cm06fe.IST.Berkeley.EDU [169.229.218.147]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCBF21F99F7 for <6tsch@ietf.org>; Thu, 13 Jun 2013 11:27:46 -0700 (PDT)
Received: from cm02ws.ist.berkeley.edu ([169.229.218.164] helo=calmail.berkeley.edu) by cm06fe.ist.berkeley.edu with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (auth login:qinwang@berkeley.edu) (envelope-from <qinwang@berkeley.edu>) id 1UnCFE-0006vD-K5; Thu, 13 Jun 2013 11:27:37 -0700
Received: from 173.49.14.122 (SquirrelMail authenticated user qinwang@berkeley.edu) by calmail.berkeley.edu with HTTP; Thu, 13 Jun 2013 11:27:36 -0700
Message-ID: <7dce19fc1af2bc48e85b256302de59ce.squirrel@calmail.berkeley.edu>
In-Reply-To: <CADJ9OA9D67=dL1JQaA0PQxCWcOrE4ubQOW0msgeCR_H2rf7hsA@mail.gmail.com>
References: <CADJ9OA_T9EROk=9tZ9FO9UbVaH686drBgmFYi_ck0jesL8BovA@mail.gmail.com> <E045AECD98228444A58C61C200AE1BD84130768B@xmb-rcd-x01.cisco.com> <CADJ9OA8L_big_YRiMPC12CSxKzRmMcb2rWzA8H6=xyVU0ZSPew@mail.gmail.com> <E045AECD98228444A58C61C200AE1BD84130A90E@xmb-rcd-x01.cisco.com> <51B0CEEA.2000304@eecs.berkeley.edu> <E045AECD98228444A58C61C200AE1BD84130A9A0@xmb-rcd-x01.cisco.com> <0001a293ea238f51d2d22c3f10a1d16c.squirrel@calmail.berkeley.edu> <CADJ9OA9D67=dL1JQaA0PQxCWcOrE4ubQOW0msgeCR_H2rf7hsA@mail.gmail.com>
Date: Thu, 13 Jun 2013 11:27:36 -0700
From: Qin Wang <qinwang@berkeley.edu>
To: Thomas Watteyne <watteyne@eecs.berkeley.edu>
User-Agent: SquirrelMail/1.4.21-2.berkeley
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] recycle unused track cells (was: Routing vs. switching)
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jun 2013 18:27:56 -0000
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 <qinwang@berkeley.edu> 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: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf >> Of >> > Xavier Vilajosana >> > Sent: jeudi 6 juin 2013 11:03 >> > To: 6tsch@ietf.org >> > 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: 6tsch-bounces@ietf.org<mailto:6tsch-bounces@ietf.org> >> > [mailto:6tsch-bounces@ietf.org] On Behalf Of Thomas Watteyne >> > Sent: jeudi 6 juin 2013 10:09 >> > To: 6tsch@ietf.org<mailto:6tsch@ietf.org> >> > 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) >> > <pthubert@cisco.com<mailto:pthubert@cisco.com>> 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: 6tsch-bounces@ietf.org<mailto:6tsch-bounces@ietf.org> >> > [mailto:6tsch-bounces@ietf.org<mailto:6tsch-bounces@ietf.org>] On >> Behalf >> > Of Thomas Watteyne >> > Sent: lundi 3 juin 2013 19:47 >> > To: 6tsch@ietf.org<mailto:6tsch@ietf.org> >> > 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) >> > <pthubert@cisco.com<mailto:pthubert@cisco.com>> 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:qinwang@berkeley.edu<mailto:qinwang@berkeley.edu >> >] >> > Sent: lundi 3 juin 2013 13:14 >> > To: Pascal Thubert (pthubert) >> > Cc: 6tsch@ietf.org<mailto:6tsch@ietf.org> >> > 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 >> >> 6tsch@ietf.org<mailto:6tsch@ietf.org> >> >> https://www.ietf.org/mailman/listinfo/6tsch >> >> >> > >> > _______________________________________________ >> > 6tsch mailing list >> > 6tsch@ietf.org<mailto:6tsch@ietf.org> >> > https://www.ietf.org/mailman/listinfo/6tsch >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > >> > 6tsch mailing list >> > >> > 6tsch@ietf.org<mailto:6tsch@ietf.org> >> > >> > https://www.ietf.org/mailman/listinfo/6tsch >> > >> > _______________________________________________ >> > 6tsch mailing list >> > 6tsch@ietf.org >> > https://www.ietf.org/mailman/listinfo/6tsch >> > >> >> _______________________________________________ >> 6tsch mailing list >> 6tsch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tsch >> > _______________________________________________ > 6tsch mailing list > 6tsch@ietf.org > https://www.ietf.org/mailman/listinfo/6tsch >
- [6tsch] recycle unused track cells (was: Routing … Thomas Watteyne
- Re: [6tsch] recycle unused track cells (was: Rout… Pascal Thubert
- Re: [6tsch] recycle unused track cells (was: Rout… Pascal Thubert (pthubert)
- Re: [6tsch] recycle unused track cells (was: Rout… Thomas Watteyne
- Re: [6tsch] recycle unused track cells (was: Rout… Pascal Thubert (pthubert)
- Re: [6tsch] recycle unused track cells (was: Rout… Xavier Vilajosana
- Re: [6tsch] recycle unused track cells (was: Rout… Pascal Thubert (pthubert)
- Re: [6tsch] recycle unused track cells (was: Rout… Qin Wang
- Re: [6tsch] recycle unused track cells (was: Rout… Thomas Watteyne
- Re: [6tsch] recycle unused track cells (was: Rout… Qin Wang