Hello Maria Rita > Hi Pascal, > > Thanks for having put this together. > I have read the draft v01 since long time, and only now finally able to > provide you some feedback. > > The draft explains well how the 6TiSCH architecture works, when a > centralized approach is used, and what is needed from DetNet to build > schedules in a centralized fashion, for setting up tracks, tagging packets, > etc. > > There is only one concept that IMHO is not that clear, and it creates a bit of > confusion. > You use Track for explaining two different concepts (based on my > understanding). > At the beginning (pag. 5) you describe a track as: > > << is a complex form of a uni-directional Circuit ([I-D.ietf-6tisch- > terminology]). As opposed to a simple circuit that is a sequence of nodes > and links, a Track is shaped as a directed acyclic graph towards a destination > to support multi-path forwarding and route around failures. A Track may > also > branch off and rejoin, for the purpose of the so-called Packet Replication > and Elimination (PRE), over non congruent branches. >>
Yes, We have not really discussed PRP vs. ARQ, we should dig more and the draft is an occasion to do that. PRP allows multiple copies to circulate over different paths and eliminates the duplications at some places in the network (or the end point). It is really a different form of reliability with additional diversity (spatial diversity). What we defined is that a PCE configures is an incoming bundle and an outgoing bundle. Packets received on an incoming bundle are switched on an outgoing bundle. There may be multiple ways for using that, and that's a PCE game to decide how it works. For instance we allow a packet to be received by more than one node since the destination MAC is 0xFFFF. Two or more nodes may be listening on a same time slot which is common to their incoming bundles (or 2 different time slots in the same outgoing bundle), in which case we achieve a frame replication. Some incoming slots may be coming from different peers in which case we are doing an elimination. Now the questions are: Do we define a pair of bundles per packet in which case we do not need a sequence counter? Do we want ARQ and then how does it work? > and still according to this, at pag. 9 you refer to a track as a possible > <<6TiSCH topology>>. Well a track defines a topology, right? It is computed by the PCE as opposed to RPL but that is still a graph, isn't it? > > This in IMHO in conflict with the definition of track to which we are (or at > least I am) used, according to [I-D.ietf-6tisch-terminology]), and which you > also use inside this draft: > > << A Track is a unidirectional path between a source and a destination. In a > Track cell, the normal operation of IEEE802.15.4 Automatic Repeat-reQuest > (ARQ) usually happens, though the acknowledgment may be omitted in > some cases, for instance if there is no scheduled cell > for a retry..... A Track is thus formed end-to-end as a succession of > paired > bundles, a receive bundle from the previous hop and a transmit bundle to > the next hop along the Track, and a cell in such a bundle belongs to at most > one Track.>> > > Is there maybe the need to differentiate the two concepts with two > different terms, or is it me missing something? I think we want to extend the definition f track so that it can be more complex than a suite of node. What do others think? > > Another thing, that I would like to discuss is about chunk. > At pag. 8, you write: > > << The appropriation of a chunk can be requested explicitly by the PCE to > any node. After a successful appropriation, the PCE owns the cells in that > chunk, and may use them as hard cells to set up Tracks. >> > > In my understanding, it should be other nodes to request the appropriation > of a chunk to the PCE. > The PCE should own all of them, being the one building the CDU, and the > chunks. Then different (parent) nodes in the network may ask for chunks, > and they will assign the cells within the chunk to their children. Is it > correct? > > Finally, something that 6TiSCH may need from DetNet is also the > management/coordination of several PCEs. > It is luckily that we will have more than one PCE, and we will need some > mechanisms to coordinate the inter-controllers synchronization, especially > if a track is crossing several domains, under the control of different PCEs. > Of course we first need to solve the simplest scenario, with one PCE, but we > should take into account also this. Well, the bundle manager is logically a different entity, so logically the PCE appropriates some bundles as well. The difference is that the chunks that the PCE owns are composed of hard cells. Do we agree? > Thank you, > Maria Rita > > > > -----Original Message----- > From: detnet [mailto:[email protected]] On Behalf Of Pascal Thubert > (pthubert) > Sent: Thursday, June 4, 2015 6:02 PM > To: [email protected] > Cc: [email protected] > Subject: [Detnet] FW: New Version Notification for draft-thubert-6tisch- > 4detnet-00.txt > > Dear all: > > I prepared this based on Archie-1 to support 6TiSCH needs at DetNet. > It is only a 00 and I'll enrich it soon. Still I thought relevant to share the > early work. > > What do you all think? > > Pascal > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: jeudi 4 juin 2015 17:58 > To: Pascal Thubert (pthubert); Pascal Thubert (pthubert) > Subject: New Version Notification for draft-thubert-6tisch-4detnet-00.txt > > > A new version of I-D, draft-thubert-6tisch-4detnet-00.txt > has been successfully submitted by Pascal Thubert and posted to the IETF > repository. > > Name: draft-thubert-6tisch-4detnet > Revision: 00 > Title: 6TiSCH requirements for DetNet > Document date: 2015-06-04 > Group: Individual Submission > Pages: 19 > URL: https://www.ietf.org/internet-drafts/draft-thubert-6tisch- > 4detnet-00.txt > Status: https://datatracker.ietf.org/doc/draft-thubert-6tisch-4detnet/ > Htmlized: https://tools.ietf.org/html/draft-thubert-6tisch-4detnet-00 > > > Abstract: > This document builds on the 6TiSCH architecture that defines, among > others, mechanisms to establish and maintain deterministic routing > and scheduling in a centralized fashion. The document details > dependencies on DetNet and PCE controller to express topologies and > capabilities, as well as abstract state that the controller must be > able to program into the network devices to enable deterministic > forwarding operations. > > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > detnet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/detnet > > _______________________________________________ > detnet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/detnet _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
