Re: [6tisch] Time to Live - ASN in a packet
Thomas Watteyne <thomas.watteyne@inria.fr> Thu, 08 September 2016 10:24 UTC
Return-Path: <thomas.watteyne@inria.fr>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B1112B0C2 for <6tisch@ietfa.amsl.com>; Thu, 8 Sep 2016 03:24:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.406
X-Spam-Level:
X-Spam-Status: No, score=-8.406 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.001, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g808jj6TELVF for <6tisch@ietfa.amsl.com>; Thu, 8 Sep 2016 03:24:10 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A173B12B187 for <6tisch@ietf.org>; Thu, 8 Sep 2016 03:24:09 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.30,300,1470693600"; d="scan'208,217";a="235693489"
Received: from mail-wm0-f51.google.com ([74.125.82.51]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 08 Sep 2016 12:24:05 +0200
Received: by mail-wm0-f51.google.com with SMTP id w12so4148030wmf.0 for <6tisch@ietf.org>; Thu, 08 Sep 2016 03:24:05 -0700 (PDT)
X-Gm-Message-State: AE9vXwOK4rSW+oedX5zoh3cvuT04aI8Fw90LPzmNf4UHl5j5F5Wpk49m7zmfcNCII1PyC5gLLliqO+0f79LfNA==
X-Received: by 10.28.157.139 with SMTP id g133mr2271871wme.82.1473330245519; Thu, 08 Sep 2016 03:24:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.80.173.135 with HTTP; Thu, 8 Sep 2016 03:24:04 -0700 (PDT)
In-Reply-To: <D3F738FE.3A41FC%shwethab@cisco.com>
References: <1341829088.7730.1472216374565.JavaMail.open-xchange@webmail.cdac.in> <57C6C853.7090809@ece.iisc.ernet.in> <015b01d20383$6f8baeb0$4ea30c10$@cdac.in> <CADJ9OA-i-U42d6aU269s_ScfYnp4yyoHuzceZDShFg7SyP7qjw@mail.gmail.com> <D3F738FE.3A41FC%shwethab@cisco.com>
From: Thomas Watteyne <thomas.watteyne@inria.fr>
Date: Thu, 08 Sep 2016 12:24:04 +0200
X-Gmail-Original-Message-ID: <CADJ9OA8rV_M8mCUJQfEKtPQh3zg-ABiv_G+4xMsGrZjY0n+RLQ@mail.gmail.com>
Message-ID: <CADJ9OA8rV_M8mCUJQfEKtPQh3zg-ABiv_G+4xMsGrZjY0n+RLQ@mail.gmail.com>
To: "Shwetha Bhandari (shwethab)" <shwethab@cisco.com>
Content-Type: multipart/alternative; boundary="001a114b2e0aebd867053bfc6dab"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/KWWsv9dYCaRtMj0XAJoY3958azY>
Cc: Lijo Thomas <lijo@cdac.in>, "6tisch@ietf.org" <6tisch@ietf.org>
Subject: Re: [6tisch] Time to Live - ASN in a packet
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Sep 2016 10:24:15 -0000
I understand now, thanks. On Thursday, September 8, 2016, Shwetha Bhandari (shwethab) < shwethab@cisco.com> 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 <thomas.watteyne@inria.fr > <javascript:_e(%7B%7D,'cvml','thomas.watteyne@inria.fr');>> > Date: Thursday, September 8, 2016 at 3:47 PM > To: Lijo Thomas <lijo@cdac.in > <javascript:_e(%7B%7D,'cvml','lijo@cdac.in');>> > Cc: "6tisch@ietf.org <javascript:_e(%7B%7D,'cvml','6tisch@ietf.org');>" < > 6tisch@ietf.org <javascript:_e(%7B%7D,'cvml','6tisch@ietf.org');>>, > Shwetha bhandari <shwethab@cisco.com > <javascript:_e(%7B%7D,'cvml','shwethab@cisco.com');>> > 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 <lijo@cdac.in > <javascript:_e(%7B%7D,'cvml','lijo@cdac.in');>> 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 <lijo@cdac.in> >> >> *Reply-To: * >> >> Lijo Thomas <lijo@cdac.in> >> >> *To: * >> >> Shwetha Bhandari (shwethab) <shwethab@cisco.com> >> >> >> >> >> >> 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)" >> <shwethab@cisco.com> 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 < lijo@cdac.in> >> *Reply-To: *Lijo Thomas < lijo@cdac.in> >> *Date: *Friday, August 26, 2016 at 11:59 AM >> *To: *Shwetha bhandari < shwethab@cisco.com> >> *Cc: *"Frank Brockners (fbrockne)" < fbrockne@cisco.com>, " >> malati@ece.iisc.ernet.in" < malati@ece.iisc.ernet.in>, " >> anand@ece.iisc.ernet.in" < anand@ece.iisc.ernet.in> >> *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)" < >> shwethab@cisco.com> 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 < lijo@cdac.in> >> *Reply-To: *Lijo Thomas < lijo@cdac.in> >> *Date: *Thursday, August 25, 2016 at 5:48 PM >> *To: *Shwetha bhandari < shwethab@cisco.com> >> *Cc: *"Frank Brockners (fbrockne)" < fbrockne@cisco.com> >> *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)" < >> shwethab@cisco.com> 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 < 6tisch-bounces@ietf.org> on behalf of Lijo Thomas < >> lijo@cdac.in> >> *Reply-To: *Lijo Thomas < lijo@cdac.in> >> *Date: *Thursday, August 25, 2016 at 3:37 PM >> *To: *Thomas Watteyne < thomas.watteyne@inria.fr>, "Pascal Thubert >> (pthubert)" < pthubert@cisco.com> >> *Cc: *" 6tisch@ietf.org" < 6tisch@ietf.org> >> *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)" < >> pthubert@cisco.com> 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:6tisch-bounces@ietf.org] *On Behalf Of *Thomas >> Watteyne >> *Sent:* jeudi 25 août 2016 08:28 >> *To:* Lijo Thomas <lijo@cdac.in> >> *Cc:* 6tisch@ietf.org >> *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 <lijo@cdac.in> 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 >> 6tisch@ietf.org >> 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 >> 6tisch@ietf.org >> 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] Time to Live - ASN in a packet Lijo Thomas
- Re: [6tisch] Time to Live - ASN in a packet Thomas Watteyne
- Re: [6tisch] Time to Live - ASN in a packet Pascal Thubert (pthubert)
- Re: [6tisch] Time to Live - ASN in a packet Thomas Watteyne
- Re: [6tisch] Time to Live - ASN in a packet Lijo Thomas
- Re: [6tisch] Time to Live - ASN in a packet Shwetha Bhandari (shwethab)
- Re: [6tisch] Time to Live - ASN in a packet Thomas Watteyne
- Re: [6tisch] Time to Live - ASN in a packet Pascal Thubert (pthubert)
- Re: [6tisch] Time to Live - ASN in a packet Thomas Watteyne
- Re: [6tisch] Time to Live - ASN in a packet Lijo Thomas
- [6tisch] FW: Re: Time to Live - ASN in a packet Lijo Thomas
- Re: [6tisch] Time to Live - ASN in a packet Shwetha Bhandari (shwethab)
- Re: [6tisch] Time to Live - ASN in a packet Thomas Watteyne
- Re: [6tisch] Time to Live - ASN in a packet Thomas Watteyne
- Re: [6tisch] Time to Live - ASN in a packet Pascal Thubert (pthubert)
- Re: [6tisch] Time to Live - ASN in a packet Michael Richardson