Thanks Chonggang for clarifying! On Fri, Apr 22, 2016 at 4:19 PM, Wang, Chonggang < [email protected]> wrote:
> Hi Xavier, > > > > Agreed. My comment actually should be for SF0 draft. I just clarified that > in the call. > > > > Thanks, > > Chonggang > > > > *From:* [email protected] [mailto:[email protected]] *On Behalf > Of *Xavier Vilajosana > *Sent:* Thursday, April 21, 2016 11:09 PM > *To:* Wang, Chonggang <[email protected]> > *Cc:* Pascal Thubert (pthubert) <[email protected]>; [email protected] > *Subject:* Re: [6tisch] Call for adoption for > draft-wang-6tisch-6top-protocol-00 > > > > Dear Chonggang, > > > > thanks for your comment. The 6P protocol offers a metadata field whose > content is defined by the scheduling policy. The metadata can specify > whether the cells to be added/remove/counted/ etc.. belong to a particular > slotframe, a particular bundle, a particular chunk, etc.. In this sense 6P > is just a L2 handshake protocol between 2 nodes (represented by macA and > macB as you indicate). The content in the metadata field to be agreed is > defined by the SF. > > > > My feeling however is that a bundle is just a grouping abstraction, > representing indistinguishable cells in terms of behaviour between two > node. A node can track itself the mapping of cells to a bundle, I think > this is internal to the node and the counterpart(neighbor node) can group > them as well by only knowing the trackID right? the 6top message already > contains the source (macA), the destination (macB) and the metadata field > can contain the trackID to indicate that these cells need to be mapped to > the specific track ID. If eventually the node considers them in a bundle, > this is transparent to the counter part no? > > > > Does this make sense? > > > > kind regards, > > Xavi > > > > 2016-04-21 23:14 GMT+02:00 Wang, Chonggang < > [email protected]>: > > Hi Pascal and All, > > I have read this I-D. I support to adopt it as the working group draft if > it addresses the following comment: > > ~~~ Beginning of Comment ~~~ > In 6TiSCH architecture and terminology working group documents, the > concept of ?Bundle? has been proposed to represent a link between nodes. > > For example, in the architecture I-D: ?With 6TiSCH, the link abstraction > is implemented as a bundle of cells; the size of a bundle is optimal when > both the energy wasted idle listening and the packet drops due to > congestion loss are minimized. This can be maintained if the number of > cells in a bundle is adapted dynamically, and with enough reactivity, to > match the variations of best-effort traffic.? > > In the terminology I-D: ?A bundle represents a half-duplex link between > nodes, one transmitter and one or more receivers, with a bandwidth that > amount to the sum of the cells in the bundle. A bundle is globally > identified by (source MAC, destination MAC, TrackID). At Layer 3 a pair of > bundles forms a link. By usining a well-known constant, NULLT, as TrackId > for a L3 link, the IP link between adjacent nodes A and B comprises 2 > bundles: (macA, macB, NULLT) and (macB, macA, NULLT).? > > Therefore, since 6top I-D aims to enable distributed scheduling, I suggest > that the 6top protocol should support ?Bundle? as defined in the > architecture and terminology I-Ds; For example, to contain the bundle > information in 6P messages in Section 4.2. > ~~~ End of Comment ~~~ > > > -----Original Message----- > From: 6tisch [mailto:[email protected]] On Behalf Of Pascal Thubert > (pthubert) > Sent: Monday, April 18, 2016 12:20 AM > To: [email protected] > Subject: [6tisch] Call for adoption for draft-wang-6tisch-6top-protocol-00 > > Dear All: > > Following up on the rough consensus at the 6TiSCH WG meeting at IETF 95: > This is a call for adoption of draft-wang-6tisch-6top-protocol-00 which > details the 6P protocol and proposes a solution for a chartered item. > Please respond by Friday to this mail indicating whether you agree or not > with this adoption, and preferably provide some rationale to support your > position. > The chairs will evaluate the consensus at the interim, and decide whether > the adoption is confirmed or the call needs to be prolonged. > > Thanks un advance! > > The chairs, > > Pascal > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
