Satish, all, I agree that many more cool things can be done with 6P, for example establishing a track by reserving cells along the multi-hop path between source and destination.
The design choice for 6P has been to provide minimal information in the headers, and leave a generic "metadata" field allowing you to do all of that. That is, you can use today's 6P to do multi-hop track reservation. The "only" thing you have to do is write an SF which says how the metadata field is used. This prevents us from having to spin the 6P version. Makes sense? Thomas On Fri, Apr 22, 2016 at 10:35 AM, Satish Anamalamudi (Satish Anamalamudi) < [email protected]> wrote: > 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]>: > > 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
