Hello Xavi: I agree, and we’ll note that we have yet to define a locally track ID if we need it.
The architecture has it that a L2 track is identified by a source IPv6 address and a local instance ID, both present in packets. This tuple is globally significant. But we have not defined how that translates in a local ID, like a MPLS label. That label would not circulate in the packets if the time slot information is enough to figure it out and perform the track switching operation (for all, cf Xavi’s paper on G-MPLS). We’ll also note that recent work on DetNet data plane (https://tools.ietf.org/html/draft-dt-detnet-dp-alt-00#section-4.2.7.2) indicates that we could have more than one bundle out along a track, to enable frame replication. Let us make a side thread on that. To ChongGang’s point, we also have yet to define RSVP-like reservations using soft cells (as opposed to PCE-based using hard cells), and that process will very probably leverage 6P at each hop. DetNet has not yet provided guidance on how that would be done, but it would be great that this group considers how we’d like it done, so we can influence DetNet. Take care, Pascal From: [email protected] [mailto:[email protected]] On Behalf Of Xavier Vilajosana Sent: vendredi 22 avril 2016 05:09 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]<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
