Hi, From 6tisch-architecture draft, it is clear that we have two types of bundles namely L2-bundle (Track forwarding) and L3-bundle (IP Forwarding). As of now Scheduling Function Zero (SFID) and 6P protocol seems to ADD/DELETE the cells dynamically to L3-bundle for neighbor-to-neighbor scheduling.
Hence, TrackID needs to be transmitted in 6P transactions to add/delete cells in specific L3-bundle (MacA, MacB, TrackID). This TrackID in-turn helps to ADD/DELETE the cells to L2-bundle for hop-by-hop scheduling in the future. One question that needs to be clarified is “Will the 6top generate a unique random number for TrackID or 6top will it try to map the IPv6 flow-dependent meta-data to TrackID in neighbor-to-neighbor scheduling ? ” 6tish Architecture draft: Section 4.5.1.1(Transport mode track forwarding). It is mentioned that “Protocol Data Unit (PDU) is associated with flow-dependent meta-data that refers uniquely to the Track”. Since packets will reach to network layer in IP forwarding (neighbor-to-neighbor scheduling), it is fine to generate unique TrackID for L3-bundle without considering the PDU flow-dependent meta-data for Neighbor-to-Neighbor Scheduling. But for hop-by-hop scheduling in the future, track forwarding through G-MPLS at 6top needs to generate TrackID with “flow-dependent-meta-data” for specific end-to-end track. Hence, TrackID generation in L2-bundle needs to consider flow characteristics from Network layer. My 2 cents, Satish From: 6tisch [mailto:[email protected]] On Behalf Of Xavier Vilajosana Sent: 2016年4月22日 11:09 To: Wang, Chonggang Cc: Pascal Thubert (pthubert); [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]<mailto:[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]<mailto:[email protected]>] On Behalf Of Pascal Thubert (pthubert) Sent: Monday, April 18, 2016 12:20 AM To: [email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
