I understand now, thanks. On Thursday, September 8, 2016, Shwetha Bhandari (shwethab) < [email protected]> wrote:
> Hi Thomas, > > Yes, if it is v6 then hbh option - > https://tools.ietf.org/html/draft-brockners-inband-oam- > transport-01#section-3.1 > > For Lijo’s use-case the below proposal was to define a new type in hbh > option defined here - https://tools.ietf.org/html/ > draft-brockners-inband-oam-data-01#section-3.3 > > Thanks, > Shwetha > From: Thomas Watteyne <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > Date: Thursday, September 8, 2016 at 3:47 PM > To: Lijo Thomas <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > Cc: "[email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>" < > [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>>, > Shwetha bhandari <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > Subject: Re: [6tisch] Time to Live - ASN in a packet > > Shwetha, > I fail to understand how this option would be carried. I assume a > hop-by-hop IPv6 extension header? > Thomas > > On Wednesday, August 31, 2016, Lijo Thomas <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> Hi all, >> >> >> >> This is for your information. >> >> >> >> Following are the mail interactions with Shwetha regarding the subject >> >> >> >> Further inputs on the topic are most welcome.. >> >> >> Thanks & Regards >> >> Lijo Thomas >> >> >> >> >> -------- Forwarded Message -------- >> >> *Subject: * >> >> Re: [6tisch] Time to Live - ASN in a packet >> >> *Date: * >> >> Fri, 26 Aug 2016 18:29:34 +0530 (IST) >> >> *From: * >> >> Lijo Thomas <[email protected]> >> >> *Reply-To: * >> >> Lijo Thomas <[email protected]> >> >> *To: * >> >> Shwetha Bhandari (shwethab) <[email protected]> >> >> >> >> >> >> Hi Shwetha, >> >> >> >> Your proposal sounds good ! >> >> >> >> Since the intermediate nodes does not have to modify the packet, your >> suggestion suits the constrained environments as well. >> >> >> >> Thanks & Regards >> >> Lijo Thomas >> >> >> On August 26, 2016 at 2:14 PM "Shwetha Bhandari (shwethab)" >> <[email protected]> wrote: >> >> Hi Lijo, >> >> >> >> Very interesting use case, thanks for sharing the details. >> >> >> >> So at a minimum you will need to: >> >> - timestamp when the packet starts its journey in the deterministic >> domain >> - A threshold delay that is acceptable >> >> The above can be expressed as a future timestamp that specifies the >> cutoff time to deliver the packet to its destination. >> >> >> >> Given this, the intermediate hops need not update the value, but only >> read it to check the time remaining as the clocks are synchronized. >> >> Is that a fair assumption? >> >> >> >> If yes perhaps we can define a new type of Edge to Edge option that we >> have defined here - https://tools.ietf.org/html/dr >> aft-brockners-inband-oam-data-01#section-3.3 >> >> That will include the [timestamp + max delay] at the originator and be >> examined at every hop and used for scheduling. >> >> Something like: >> >> 0 1 2 3 >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | Option Type | Opt Data Len | OAM-E2E-Type | reserved | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | E2E Option data format determined by iOAM-E2E-Type | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> iOAM-E2E-Type: 8-bit identifier of a particular in-band OAM E2E >> >> variant. >> >> 0: E2E option data is a 64-bit sequence number added to a >> >> specific tube which is used to identify packet loss and >> >> reordering for that tube. >> >> 1: E2E option data is a 64-bit timestamp ….. >> >> >> >> >> >> Thoughts? >> >> >> >> Thanks, >> >> Shwetha >> >> >> >> >> >> *From: *Lijo Thomas < [email protected]> >> *Reply-To: *Lijo Thomas < [email protected]> >> *Date: *Friday, August 26, 2016 at 11:59 AM >> *To: *Shwetha bhandari < [email protected]> >> *Cc: *"Frank Brockners (fbrockne)" < [email protected]>, " >> [email protected]" < [email protected]>, " >> [email protected]" < [email protected]> >> *Subject: *Re: [6tisch] Time to Live - ASN in a packet >> >> >> >> Hi Shwetha, >> >> Thanks for the very useful inputs! >> >> I thought I will briefly describe the context. >> >> We are implementing a distributed scheduling scheme on a 6tisch network >> to >> support flows with strict delay contstaints. In some sense, we are >> working on >> deterministic networking. As you might be aware, there are several >> distributed >> algorithms in the literature such as EDF, LLF and so forth where >> intermediate >> nodes schedules packets based on the per-flow delay requirements, >> remaining >> time left to reach the destination, delay already experienced. These >> distributed debt based schemes attempt to meet the deadlines of the >> flows, >> thereby enabling us to realise deterministic networks. >> >> Therefore, the scheduler running on the nodes need to know the remaining >> time >> left before which the packet should reach the receiver. Since the 6tisch >> network is time synchronized, we are thinking of using ASN as a means to >> update the remaining time left. The originator specifies the maximum time >> limit. >> >> I went through your draft. Thanks for the same! From my understanding, it >> appears that we may have to use OAM-trace-type : 0x00001001 for our >> requirement. >> >> I am not sure if the above type can be used in our problem setting. >> >> Hence I would like to know if there is any specfic format explicitly >> defined >> considering the case of LLNs for including the Time field in hop by hop >> header, >> something similar to inclusion of RPL packet information in HbH. >> >> I would like to discuss more on this topic if you feel it is interesting. >> >> >> >> Thanks & Regards >> >> Lijo Thomas >> >> >> >> >> >> >> On August 26, 2016 at 5:44 AM "Shwetha Bhandari (shwethab)" < >> [email protected]> wrote: >> >> Hi Lijo, >> >> >> >> We have the implementation in VPP <http://wiki.fd.io/view/VPP>, you can >> refer to the code here >> <https://gerrit.fd.io/r/gitweb?p=vpp.git;a=blob;f=vnet/vnet/ip/ip6_hop_by_hop.c;h=7038556848c3d325b6612678a903f26cbf671de5;hb=HEAD>. >> >> >> If you want to try it out in your experiment do let us know we can help >> with more documentation to bring it up. >> >> >> >> We have some of our demos available here >> <https://www.youtube.com/channel/UC0WJOAKBTrftyosP590RrXw>. >> >> Do keep us posted on the hardware study and any modification that you try >> for constrained environment. >> >> >> >> Thanks, >> >> Shwetha >> >> >> >> *From: *Lijo Thomas < [email protected]> >> *Reply-To: *Lijo Thomas < [email protected]> >> *Date: *Thursday, August 25, 2016 at 5:48 PM >> *To: *Shwetha bhandari < [email protected]> >> *Cc: *"Frank Brockners (fbrockne)" < [email protected]> >> *Subject: *Re: [6tisch] Time to Live - ASN in a packet >> >> >> >> Hi Shwetha, >> >> >> >> Excellent.. >> >> >> >> Thanks for the inputs, we are looking for a solution exactly suggested >> by you. >> >> >> >> we are implementing our algorithm on hardware and will get back to you . >> >> >> >> Thanks & Regards >> >> Lijo Thomas >> >> >> >> >> >> >> On August 25, 2016 at 3:54 PM "Shwetha Bhandari (shwethab)" < >> [email protected]> wrote: >> >> Hi Lijo, >> >> >> >> We are trying something similar with In-band OAM – defining HbH options >> to collect timestamps, node, interface information as the packet traverses >> the nodes. Please take a look at the following: >> >> https://tools.ietf.org/html/draft-brockners-inband-oam-data- >> 01#section-3.1 >> <https://tools.ietf.org/html/draft-brockners-inband-oam-data-01> >> >> https://tools.ietf.org/html/draft-brockners-inband-oam-trans >> port-01#section-3.1 >> >> >> >> Thanks, >> >> Shwetha >> >> >> >> *From: *6tisch < [email protected]> on behalf of Lijo Thomas < >> [email protected]> >> *Reply-To: *Lijo Thomas < [email protected]> >> *Date: *Thursday, August 25, 2016 at 3:37 PM >> *To: *Thomas Watteyne < [email protected]>, "Pascal Thubert >> (pthubert)" < [email protected]> >> *Cc: *" [email protected]" < [email protected]> >> *Subject: *Re: [6tisch] Time to Live - ASN in a packet >> >> >> >> >> Hi Pascal & Thomas, >> >> The problem is inline with Pascal's comment on "looking for per packet >> information to as to monitor and maybe influence the forwarding and >> delivery" >> >> We are proposing a debt based distributed scheduling scheme where nodes >> make forwarding decisions based on the PDR and end-to-end delay requirement >> of flows. >> >> We simulated our algorithm using 6tisch simulator and got encouraging >> results. For this, we plugged in ASN value in the application payload and >> the intermediate node updates the ASN value before forwarding. >> >> Now we are implementing the algorithm on the hardware using OpenWSN >> environment and intend to do inline with the standard. >> >> We are actually contemplating on HbH at L3, similar to RPL RPI as >> described in RFC 6553 >> >> But we would like to understand that if any options is available in the >> 6tisch framework. >> >> Expecting your valuable comments..!!!!!!!!!! >> >> >> >> Thanks & Regards >> >> Lijo Thomas >> >> >> >> >> >> >> On August 25, 2016 at 1:39 PM "Pascal Thubert (pthubert)" < >> [email protected]> wrote: >> >> Hello Lijo: >> >> >> >> Like Thomas, I’d love to understand what your case and solution approach >> is. Is asynchronous OAM like the openWSN application enough for you? Or >> else are you looking for per packet information to as to monitor and maybe >> influence the forwarding and delivery? >> >> >> >> In the latter case, your work may be related to other efforts, and if >> your experimentation is successful then why not consider a more general >> applicability? >> >> >> >> All in all I have this feeling that time-aware forwarding is on the way, >> in which exact shape and form is left TBD: >> >> - DetNet is discussing validating the end-to-end latency of >> individual packets to make sure that the delivery was within bounds. Is >> that similar to your need? >> >> - I’ve participated to work where the QoS of the packet was >> estimated at each hop depending on whether the packet was early or late vs. >> a predefined schedule. This makes things much simpler but slightly less >> deterministic than a tight scheduling. >> >> - There’s also OAM work that uses HbH headers to monitor the >> packets as they flow along the network (IOW, in band as opposed to >> asynchronous OAM packets) >> >> >> >> My understanding is that you want HbH behavior. >> >> - If you are doing a mesh, you can probable hack a mesh header. >> >> - But if you are considering a larger applicability (I hope so!) >> then you probably want to hack at L3. >> >> >> >> You can find tons of ideas of what can be done at L3 in various >> environments in https://tools.ietf.org/html/draft-dt-detnet-dp-alt-03, >> which is pending adoption call. >> >> >> >> But if you narrow down to 6TiSCH, then you probably want to design you >> own option in the HbH header and incode it in a 6LoRH similar to the RPL >> RPI. You may use ASN to start with, but when going standard you’ll have to >> abstract that a little bit, even if the data in the packet is unchanged. >> >> >> >> Very keen to hear more! >> >> >> >> Pascal >> >> >> >> *From:* 6tisch [mailto:[email protected]] *On Behalf Of *Thomas >> Watteyne >> *Sent:* jeudi 25 août 2016 08:28 >> *To:* Lijo Thomas <[email protected]> >> *Cc:* [email protected] >> *Subject:* Re: [6tisch] Time to Live - ASN in a packet >> >> >> >> Lijo, >> >> >> >> It looks like you are describing two things: the TTL (or hop limit in >> IPv6 parlance) which decrements by one by each router, and some timestamp >> which can be used to measure end -to-end latency. I'm assuming the latter. >> >> >> >> I'm also assuming you are doing this as part of an experiment, to look at >> the end-to-end/hop-by-hop latency. In that context, you probably aren't >> looking for standardizing that (or even standards-compliance during your >> experiment), but more at an implementation technique to keep that >> information. >> >> >> >> Of course, the answer depends entirely on the information we are missing. >> But assuming you are playing with the OpenWSN implementation, there is >> already an application called rrt which sends the ASN as application >> payload at the source, and records the ASN when the DAGroot has received >> that. You can then substract one by the other and do some stats. Please ask >> further questions to the OpenWSN community [1] as such technical discussion >> on a particular implementation doesn't belong on the 6TiSCH WG ML. >> >> >> >> If you are using the commercial SmartMesh IP solution by Linear Tech [2], >> good news, all of that is already built in. The manager (~DAGroot) keeps >> track of timing and can send you average latencies for each of your nodes. >> If you're interested, you can look at these numbers "live" on deployments >> in Argentina [3,4] or California [5]. As you might imagine, >> latency/throughput/lifetime trade-off for one another, so there is a handy >> "performance estimator" tool you can use [6,7]. For further question on >> this topic, please use www.dustcloud.org. >> >> >> >> Finally, looking at lowering latency in 6TiSCH has been an important >> research topic in the last year or so. Look for example at the "Low-Latency >> Scheduling Function" [8] work which lowers the per-hop latency to 10's of >> ms withing the 6TiSCH framework. >> >> >> >> Thomas >> >> >> >> [1] www.openwsn.org >> >> [2] www.linear.com/dust >> >> [3] http://www.savethepeaches.com/ >> >> [4] PEACH: Predicting Frost Events in Peach Orchards Using IoT >> Technology. Thomas Watteyne, Ana Laura Diedrichs, Keoma Brun-Laguna, Javier >> Emilio Chaar, Diego Dujovne, Juan Carlos Taffernaberry, Gustavo Mercado. >> EAI Endorsed Transactions on the Internet of Things, to appear in 2016. >> >> [5] http://www.snowhow.io/ >> >> [6] http://www.linear.com/docs/42452 >> >> [7] Industrial IEEE802.15.4e Networks: Performance and Trade-offs. Thomas >> Watteyne, Joy Weiss, Lance Doherty, Jonathan Simon. IEEE International >> Conference on Communications (IEEE ICC), Internet of Things Symposium, >> London, UK, 8-12 June 2015. >> >> [8] LLSF: Low Latency Scheduling Function for 6TiSCH Networks. Tengfei >> Chang, Thomas Watteyne, Qin Wang, Xavier Vilajosana.... IEEE International >> Conference on Distributed Computing in Sensor Systems (DCOSS), Washington, >> DC, USA, 26-28 May 2016. >> >> >> >> On Thu, Aug 25, 2016 at 7:57 AM, Lijo Thomas <[email protected]> wrote: >> >> Hi all, >> >> >> >> We are working on problem which needs the *Time to Live (TTL) >> information* in terms of *ASN * to be included as part of the Packet. >> >> >> >> We require the intermediate nodes to update TTL at each hop. >> >> >> >> How this information can be passed in a 6tisch framework. >> >> >> >> Suggestions are welcome.. >> >> >> >> Thanks & Regards >> >> Lijo Thomas >> >> >> >> >> >> >> ------------------------------------------------------------ >> ------------------------------------------------------------------- >> [ C-DAC is on Social-Media too. Kindly follow us at: >> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] >> >> This e-mail is for the sole use of the intended recipient(s) and may >> contain confidential and privileged information. If you are not the >> intended recipient, please contact the sender by reply e-mail and destroy >> all copies and the original message. Any unauthorized review, use, >> disclosure, dissemination, forwarding, printing or copying of this email >> is strictly prohibited and appropriate legal action will be taken. >> ------------------------------------------------------------ >> ------------------------------------------------------------------- >> >> >> _______________________________________________ >> 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 >> >> _______________________________________ >> >> >> >> >> >> ------------------------------------------------------------ >> ------------------------------------------------------------------- >> [ C-DAC is on Social-Media too. Kindly follow us at: >> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] >> >> This e-mail is for the sole use of the intended recipient(s) and may >> contain confidential and privileged information. If you are not the >> intended recipient, please contact the sender by reply e-mail and destroy >> all copies and the original message. Any unauthorized review, use, >> disclosure, dissemination, forwarding, printing or copying of this email >> is strictly prohibited and appropriate legal action will be taken. >> ------------------------------------------------------------ >> ------------------------------------------------------------------- >> >> >> _______________________________________________ >> 6tisch mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6tisch >> >> >> ------------------------------------------------------------ >> ------------------------------------------------------------------- >> [ C-DAC is on Social-Media too. Kindly follow us at: >> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] >> >> This e-mail is for the sole use of the intended recipient(s) and may >> contain confidential and privileged information. If you are not the >> intended recipient, please contact the sender by reply e-mail and destroy >> all copies and the original message. Any unauthorized review, use, >> disclosure, dissemination, forwarding, printing or copying of this email >> is strictly prohibited and appropriate legal action will be taken. >> ------------------------------------------------------------ >> ------------------------------------------------------------------- >> >> >> >> >> >> ------------------------------------------------------------ >> ------------------------------------------------------------------- >> [ C-DAC is on Social-Media too. Kindly follow us at: >> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] >> >> This e-mail is for the sole use of the intended recipient(s) and may >> contain confidential and privileged information. If you are not the >> intended recipient, please contact the sender by reply e-mail and destroy >> all copies and the original message. Any unauthorized review, use, >> disclosure, dissemination, forwarding, printing or copying of this email >> is strictly prohibited and appropriate legal action will be taken. >> ------------------------------------------------------------ >> ------------------------------------------------------------------- >> >> >> >> >> >> ------------------------------------------------------------ >> ------------------------------------------------------------------- >> [ C-DAC is on Social-Media too. Kindly follow us at: >> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] >> >> This e-mail is for the sole use of the intended recipient(s) and may >> contain confidential and privileged information. If you are not the >> intended recipient, please contact the sender by reply e-mail and destroy >> all copies and the original message. Any unauthorized review, use, >> disclosure, dissemination, forwarding, printing or copying of this email >> is strictly prohibited and appropriate legal action will be taken. >> ------------------------------------------------------------ >> ------------------------------------------------------------------- >> >> >> >> ------------------------------------------------------------ >> ------------------------------------------------------------------- >> [ C-DAC is on Social-Media too. Kindly follow us at: >> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] >> >> This e-mail is for the sole use of the intended recipient(s) and may >> contain confidential and privileged information. If you are not the >> intended recipient, please contact the sender by reply e-mail and destroy >> all copies and the original message. Any unauthorized review, use, >> disclosure, dissemination, forwarding, printing or copying of this email >> is strictly prohibited and appropriate legal action will be taken. >> ------------------------------------------------------------ >> ------------------------------------------------------------------- >> > > > -- > _______________________________________ > > 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 > _______________________________________ > > -- _______________________________________ 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
