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
