I like this text. Thank you. > On 28 Feb 2019, at 11:34, Pascal Thubert (pthubert) <[email protected]> > wrote: > > Dear Eliot and all: > > For the AND/OR discussion, I propose the following example: > > As an example say that we have a simple network as represented in > Figure 17, and we want to enable PREOF between an ingress node I and > an egress node E. > > +-+ +-+ > -- |A| ------ |C| -- > / +-+ +-+ \ > / \ > +-+ +-+ > |I| |E| > +-+ +-+ > \ / > \ +-+ +-+ / > -- |B| ------- |D| -- > +-+ +-+ > > Figure 17: Scheduling PREOF on a Simple Network > > The assumption for this particular problem is that a 6TiSCH node has > a single radio, so it cannot perform 2 receive and/or transmit > operations at the same time, even on 2 different channels. > > Say we have 6 possible channels, and at least 10 timeslots per > slotframe. Figure 18 shows a possible schedule whereby each > transmission is retried 2 or 3 times, and redundant copies are > forwarded in parallel via A and C on the one hand, and B and D on the > other, providing time diversity, spatial diversity though different > physical paths, and frequency diversity. > > +----+----+----+----+----+----+----+----+----+ > channelOffset 0 | | | | | | |B->D| | | ... > +----+----+----+----+----+----+----+----+----+ > channelOffset 1 | |I->A| |A->C|B->D| | | | | ... > +----+----+----+----+----+----+----+----+----+ > channelOffset 2 |I->A| | |I->B| |C->E| |D->E| | ... > +----+----+----+----+----+----+----+----+----+ > channelOffset 3 | | | | |A->C| | | | | ... > +----+----+----+----+----+----+----+----+----+ > channelOffset 4 | | |I->B| | |B->D| | |D->E| ... > +----+----+----+----+----+----+----+----+----+ > channelOffset 5 | | |A->C| | | |C->E| | | ... > +----+----+----+----+----+----+----+----+----+ > slotOffset 0 1 2 3 4 5 6 7 9 > > > Figure 18: Example Global Schedule > > This translates in a different slotframe for every node that provides > the waking and sleeping times, and the channelOffset to be used when > awake. Figure 19 shows the corresponding slotframe for node A. > > > +----+----+----+----+----+----+----+----+----+ > channelOffset |CO 2|CO 1|CO 5|CO 1|CO 3| | | | | ... > +----+----+----+----+----+----+----+----+----+ > slotOffset 0 1 2 3 4 5 6 7 9 > > > Figure 19: Example Node A slotframe > > In that example, the logical relationship between the timeslots is: > > > +------+---------------------+------------------------+ > | Node | rcv slotOffset | xmit slotOffset | > +------+---------------------+------------------------+ > | I | N/A | (0 OR 1) AND (2 OR 3) | > | A | (0 OR 1) | (2 OR 3 OR 4) | > | B | (2 OR 3) | (4 OR 5 OR 6) | > | C | (2 OR 3 OR 4) | (5 OR 6) | > | D | (4 OR 5 OR 6) | (7 OR 8) | > | E | (5 OR 6 OR 7 OR 8) | N/A | > +------+---------------------+------------------------+ > > > Figure 20: Logical Relationship > > > > All the best, > > Pascal > > From: Pascal Thubert (pthubert) > Sent: mardi 26 février 2019 15:08 > To: 'Eliot Lear' <[email protected]>; iot-dir <[email protected]>; > [email protected]; [email protected]; Suresh Krishnan > <[email protected]> > Cc: Carlos Pignataro (cpignata) <[email protected]>; CARLOS JESUS BERNARDOS > CANO <[email protected]> > Subject: RE: Early IoT-Dir review of draft-ietf-6tisch-architecture-19 > > Hello Eliot > > Many thanks for your early review! And yes, I agree that a smaller committee > is great to clean up the major aspects before opening to the wider public. > > Please see below (in purple in the text): > > First, the good. > > I commend you on using the early review option! This provides you the > opportunity to consider substantial changes prior to garnered consensus, > saving you lots of time and energy. > > You have much of the content that is necessary to explain the architecture. > In several reads I became confident that much of this will actually work. > Clearly the approach is quite flexible to support a great many deployments. > It seems to me you have identified all the right building blocks. > > Ø Yes, and we have built it (2 open source plus a major private > implementations) and interop tested it (with ETSI) over the recent years : ) > > Major issues > > The bad. It took me several reads over a week to really get it, and I was > trying. > This document introduces a great many concepts. It is not clear to me that > they should all be introduced in one document. As a test, ask yourself this > question: what would the reader lose if you did not include Section 4.4.3? > If you are going to introduce all of these concepts, then you need to pay a > bit more attention to the organization. Your hint that you have a problem in > this regard is your table of contents: you are spending roughly 12 pages to > describe what you label as “High Level Architecture”. Section 3 needs to be > sufficiently succinct that it fits into Section 1. Otherwise it must be > combined into Section 4, which in turn could be broken up into major > sections. I also would have expected something of a mapping between Sections > 3 and 4: that is, high level in one, details in the other. But that’s not > really what we get. Section 3.7 and 3.8 feel as though it really belongs in > Section 4. > Section 4.4.3 positions the future work at PAW. This is what enables the > “deterministic thing” and is the major mode of operation in the pre-6tisch > art of process control network. We could not really ignore it. The split with > a high level architecture is a result of a review by Ralph long ago. Ralph > expected a succinct high level architecture and the doc with section 3 and 4 > as one was too deep and wide. I agree with you that 3.7 and 3.8 could move to > section 4, this would reduce section 3 down to 8 pages and get us closer to > what Ralph expected I guess. > The outlook of the ToC would then be: > 2. Terms and References . . . . . . . . . . . . . . . . . . . . 4 > 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 > 2.3. References . . . . . . . . . . . . . . . . . . . . . . . 10 > 2.4. Subset of a 6LoWPAN Glossary . . . . . . . . . . . . . . 11 > 3. High Level Architecture . . . . . . . . . . . . . . . . . . . 12 > 3.1. 6TiSCH Stack . . . . . . . . . . . . . . . . . . . . . . 12 > 3.2. TSCH: A Deterministic MAC Layer . . . . . . . . . . . . . 14 > 3.3. Scheduling TSCH . . . . . . . . . . . . . . . . . . . . . 14 > 3.4. Routing and Forwarding Over TSCH . . . . . . . . . . . . 16 > 3.5. A Non-Broadcast Multi-Access Radio Mesh Network . . . . . 17 > 3.6. A Multi-Link Subnet Model . . . . . . . . . . . . . . . . 19 > 4. Architecture Components . . . . . . . . . . . . . . . . . . . 20 > 4.1. 6LoWPAN (and RPL) . . . . . . . . . . . . . . . . . . . . 20 > 4.1.1. RPL-Unaware Leaves and 6LoWPAN ND . . . . . . . . . . 21 > 4.1.2. RPL Root And 6LBR . . . . . . . . . . . . . . . . . . 21 > 4.2. Network Access and Addressing . . . . . . . . . . . . . . 22 > 4.2.1. Join Process . . . . . . . . . . . . . . . . . . . . 22 > 4.2.2. Registration . . . . . . . . . . . . . . . . . . . . 24 > 4.3. TSCH and 6top . . . . . . . . . . . . . . . . . . . . . . 26 > > Works? > > > > > While there are some illustrations, there are not any examples of how this > stuff is intended to function in practice. I will readily concede that > examples are hard to write and get right, but they’re still important, and > perhaps nowhere more-so with your AND and OR discussion in Section 4.7.2. My > suggestion is that you seriously consider the validity of any component that > you cannot show an example for. I think visualising schedules in several > instances would help, for example. > will do, but that will take time and I do not want to hold my answer : ) > You have quite a number of groupings and disparate explanations of them. In > this document alone you have cells, slots, slot frames, bundles, tracks, and > packets. These are fundamental to your architecture. There needs to be a > single section that introduces these, and shows how they fit together. It is > not necessary in this introductory session to detail every aspect of these > groupings, but simply to show their relationship to one another. You have a > lot of the right diagrams in Sections 3 and 4, but one wants to understand > the big picture before delving into the components. > I can do that too, and place text in section 2 or 3. There is a difficult > tension between the desire to shrink those sections that you expressed > earlier and the request you’re making here. > Sections 2.2, 2.3, and 2.4 should be combined and reduced. Keep in mind that > the style of the IETF is to define on first use. What you want to avoid is > the reader having to continuously flip back to the glossary. People aren’t > reading this stuff on paper anymore. You might think this a minor issue. > However, what you have told me, your dear reader, in Section 2.3 in > particular is that I am unlikely to understand this architecture without > having a full understanding of a year’s worth of reading, when that’s clearly > not the case. > Problem there. We were asked to merge the 6TiSCH terminology document > https://tools.ietf.org/html/draft-ietf-6tisch-terminology-10 > <https://tools.ietf.org/html/draft-ietf-6tisch-terminology-10> into the > architecture to save RFC numbers and IESG cycles. We already used “define on > first use” but the terminology was also useful when coming back to the doc or > not reading it serially, as well as when reading another draft from the WG. I > can move it to the appendix if that looks better, but I do not think we > should eliminate or shrink dramatically what used to be a WG document just > like that. We could try to convince Suresh (cc) to resplit but there is > little hope. > · To this end, you should include in your introduction something like > Figure 4 that introduces the components. You might also state some of the > operating assumptions of the devices involved, and focus on a few use cases > as to how it would be applied (see examples above). > Will do; I’ll come back to you when I have progressed on all the above and > probably published a rev so you can diff through easily. Note that again, > this goes against a desire for increased conciseness. My understanding of > what you describe looks a lot like a full book on 6TiSCH. I have no time to > write that, I would if I did, and the reader is probably not expecting that > from an IETF specification > Minor issues > You are referencing BCP 14 but not really using it. If you are referencing > it to explain that you do not mean to be making normative statements, I think > it is best to plainly say just that. > It’s a nits thingy since we are going for std track. I’ll let the IESG sort > that out with the DetNet architecture and will mimic when they are done. > In Section 4.6, figures 12, 13, and 14: these diagrams are a bit too > abstract. Please add the components and label what is being sent between them. > I realise you probably didn’t originate the term but Join > Registrar/Coordinator (JRC) is an odd acronym. Is this intended to be two > architectural components combined into one or just a bit of terminology > indecision on the part of the designers ;-)? > In Section 4.2.5, you write: > In order to ensure that the medium is free of > contending packets when time comes for a scheduled transmission, a > window of time is defined around the scheduled transmission where the > medium must, as much as practcally feasible, be free of contending > energy. > · It is probably worth stating this in terms of whose responsibility it > is to find that quiet frequency (thenode’s, right?). One question this > raises is how much energy the node must consume to do that search, the > architectural assumption being that it can do so efficiently. > > This really depends on the “Schedule Management Mechanism”.. The optimal is > when a central controller owns hard cells and assigns them, in that case the > node is a slave and does not consume energy for scanning. Else the use of > chunks reduces the space where a node needs to scan for activity. > I suggest adding the marked text below (note that section 4.4 is now 4.5 > after moving pieces of section 3 in section 4: > 4.3.5. SlotFrames and CDU matrix > > 6TiSCH enables IPv6 best effort (stochastic) transmissions over a MAC > layer that is also capable of scheduled (deterministic) > transmissions. In order to ensure that the medium is free of > contending packets when time comes for a scheduled transmission, a > window of time is defined around the scheduled transmission where the > medium must, as much as practically feasible, be free of contending > energy. > > One simple way to obtain such a window is to format time and > frequencies in cells of transmission of equal duration. This is the > method that is adopted in IEEE Std 802.15.4 TSCH as well as the Long > Term Evolution (LTE) of cellular networks. > > In order to describe that formatting of time and frequencies, the > 6TiSCH architecture defines a global concept that is called a Channel > Distribution and Usage (CDU) matrix. A CDU matrix is defined > centrally as part of the network definition. It is a matrix of cells > with an height equal to the number of available channels (indexed by > ChannelOffsets) and a width (in timeslots) that is the period of the > network scheduling operation (indexed by slotOffsets) for that CDU > matrix. There are different models for scheduling the usage of the > cells, which place the responsibility of avoiding collisions either > on a central controller or on the devices themselves, at an extra > cost in terms of energy to scan for free cells (more in Section 4.5). > > > Nits: > > There are more nits than these, but this is a start. > > Definitions: > > Layer-2 vs. Layer 3 bundle: > > a Layer-3 bundle pair maps > s/a Layer-3 bundle pair maps/A Layer-3 bundle maps/ > > o I meant a pair of bundles. Reworded below: > > > > Layer-2 vs. Layer-3 bundle: Bundles are associated for either > Layer-2 (switching) or Layer-3 (routing) forwarding > operations. A pair of Layer-3 bundles (one for each > direction) maps to an IP Link with a neighbor, whereas a > set of Layer-2 bundles (a number per neighbor, either > from or to the neighbor) corresponds to the relation of > one or more incoming bundle(s) from the previous-hop > neighbor(s) with one or more outgoing bundle(s) to the > next-hop neighbor(s) along a Track. > > Cell: > A single element in the TSCH schedule > My suggestion is that you be more explicit: don’t use the word “element”. > Perhaps something like this: “A period of time in the TSCH schedule set aside > for data transmission that is identified by… > > o It is really a cell in the CDU matrix identified by channeloffset and > slotoffset. What about: > > cell: A unit of transmission resource in the CDU matrix, a cell > is identified by a slotOffset and a channelOffset. A > cell can be scheduled or unscheduled. > > > channelOffset: > > Does a channelOffset necessarily imply channel hopping? What happens if the > offset remains constant across a row? > > o It is really a cell in the CDU matrix identified by channeloffset and > slotoffset. What about: > > channelOffset: Identifies a row in the TSCH schedule. The number of > channelOffset values is bounded by the number of > available frequencies. The channelOffset translates into > a frequency with a function that depends o the absolute > time when the communication takes place, resulting in a > channel hopping operation. > > > > > Hard cell: > A scheduled cell which the 6top sublayer cannot relocate > “Cannot” means it is beyond its means to do so. I think you mean “may not”. > o done > > > Track: > Expand DODAG-> Destination Oriented Directed Acyclic Graph > o proposal: > > > > Track: A Track is a Directed Acyclic Graph (DAG) that is used as > a complex multi-hop path to the destination(s) of the > path. In the case of unicast traffic, the Track is a > Destination Oriented DAG (DODAG) where the root of the > DODAG is the destination of the unicast traffic. A Track > enables replication, elimination and reordering functions … > > > Section 3.6, 1st para: > This architecture requires work to standardize the the > s/the the/the/ > o done > > > > Section 4.1 > > First para, s/Root/root/, as used in RFC 6550. > o done > > > > Section 4.2: > As a result of the process of chunk ownership appropriation, the RPL > parent has exclusive authority to decide which cell in the > appropriated chunk can be used by which node in its interference > domain. In other words, it is implicitly delegated the right to > manage the portion of the CDU matrix that is represented by the > chunk. The RPL parent may thus orchestrate which transmissions occur > in any of the cells in the chunk, by allocating cells from the chunk > to any form of communication (unicast, multicast) in any direction > between itself and its children. > > This twice-redundant. I can understand reinforcing the point. My > suggestion: drop the last sentence. > > o done > > > > Section 4.5.5: > > Formatting issues. If you are quoting text, please source your quote. > Otherwise, do not indent. Also... > In one hand, a > Just remove that. > o done > > > Same para below: > It results that a frame > s/It results that a frame/It results in a frame/ > o done, twice > > > > > Section 4.7.2: > This sentence does not parse: > As it goes, 6TiSCH expects that timeslots corresponding to copies of > a same packet along a Track are correlated by configuration, and does > not need to process the sequence numbers. > Who does not need to process sequence #s? Be specific. > > > o In DetNet Packet Replication and Elimination Function (PREF), multiple > copies of a packet can be received and duplicates can be recognized and > eliminated because they have the same sequence number. > > o What about > > 4.8.2. Replication, Retries and Elimination > > 6TiSCH supports the PREOF operations of elimination and reordering of > packets along a complex Track, but has no requirement about whether a > sequence number would be tagged in the packet for that purpose. With > 6TiSCH, the schedule can tell when multiple receive timeslots > correspond to copies of a same packet, in which case the receiver may > avoid listening to the extra copies once it had received one instance > of the packet. > > > > The semantics of the configuration will enable correlated timeslots > to be grouped for transmit (and respectively receive) with a 'OR' > relations, and then a 'AND' relation would be configurable between > groups. > s/with an ‘OR’/with an ‘OR’/ > s/with an ‘AND’/with an ‘AND’/ > o done, for both > > > The 'OR' relation > indicates that if a transmission is acknowledged, then further > transmissions should not be attempted for timeslots in that group. > s/acknowledged, then further transmissions/acknowledged. In this case,/ > > o done >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
