Re: [6lo] Magnus Westerlund's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)
Hi Magnus, Thanks for your detailed review and really appreciate your time taken for the effort . Please find our below response for the frame work query addressed by you. One of the main use cases of the draft is the industrial automation and control applications. The end point of such applications puts the deadline information as per its delay requirements. I agree that the underlying 6Lo network needs to ensure that the deadline is met using its delay sensitive routing and scheduling mechanisms while forwarding the packet along the path. The 6Lo network can support such a QoS requirement through end-to-end provisioning of the required network resources either centrally and/or in a distributed fashion . In the case of a 6tisch network, one could think of setting up tracks [draft-ietf-6tisch-architecture] along with delay aware Scheduling Function implemented by the intermediate nodes. The deadline draft works well within the context of the framework described in the draft-6tisch-architecture draft. The 6tisch architecture draft defines tracks which could either be set up by a centralised entity PCE or by setting up tracks in a distributed fashion by reserving network resources that provide end-to-end delay guarantees. Packets of application flows can be sent over these tracks and scheduled based on their deadlines. The CAC can be exercised where reservation fails for a new track setup. There are situations like asynchronous time critical emergency messages where track set up delay is not acceptable. In such cases, we can use distributed on-the-fly scheduling using 6P protocol described in RFC 8480 that takes into consideration the deadline information. There are several deadline based scheduling algorithms that have proposed in the literature including the basic Earliest Deadline First (EDF). Based on our deadline draft, we implemented this scheme over a 6tisch network running on OpenWSN protocol stack and our draft implementation has been merged with the OpenWSN environment for future downloads too. We would be happy to add some additional text specifying that ** a network monitoring entity with call admission policy is expected to be in place for observation and consequently better results during real implementations**. Hope this address your few concerns and based on your response we will update the draft. Happy to receive your further thoughts and valuable inputs. Thanks & Regards, Lijo Thomas -Original Message- From: 6lo <6lo-boun...@ietf.org> On Behalf Of Magnus Westerlund Sent: 03 June 2019 18:27 To: Charlie Perkins ; The IESG Cc: draft-ietf-6lo-deadline-t...@ietf.org; 6lo-cha...@ietf.org; Samita Chakrabarti ; Shwetha Bhandari ; 6lo@ietf.org Subject: Re: [6lo] Magnus Westerlund's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT) Hi Charlie, Please see for further comments inline. On 2019-05-30 23:16, Charlie Perkins wrote: > On 5/13/2019 6:41 AM, Magnus Westerlund via Datatracker wrote: >> Magnus Westerlund has entered the following ballot position for >> draft-ietf-6lo-deadline-time-04: Discuss >> >> >> >> >> - >> - >> DISCUSS: >> - >> - >> >> The security consideration section have significant short comings as >> this mechanism enables multiple ways to attack both the packet and >> the system to my understanding. I would appreaciate your clarifications on these matters. >> >> First of all by changing the dead-line so that it gets dropped >> because it is already late, alternatively move the deadline time out >> further in time (later), so that the forwarders may deliver it so >> late that the receiver considers it to late. > Agreed that this vulnerability should be mentioned in the Security > Considerations. > > >> Secondly, there is the question if extensive use of this header will >> cause overload or affect the scheduling of packet transmission affect >> other traffic negatively. There appear to exist potential for new >> ways of bad interflow interactions here. > If other packet transmissions have to be pre-empted in order for the > deadline to be met for a particular packet, then indeed this could > affect other traffic. It is also a matter of possible interest what > might happen if there were two packets in the transmission queue with > the same or different deadlines. However, the processing in these > cases is a local matter at each intermediate point, and out of scope for this > draft. Does this also belong to be mentioned in the Security > Considerations? Yes, I think so, as it points to a requirement to consi
Re: [6lo] Magnus Westerlund's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)
Hi Magnus, Thanks for the great response, we will update the draft accordingly. Thanks & Regards, Lijo Thomas -Original Message- From: Magnus Westerlund Sent: 05 June 2019 17:23 To: Lijo Thomas ; 'Charlie Perkins' ; 'The IESG' Cc: 6lo-cha...@ietf.org; 'Samita Chakrabarti' ; 'Shwetha Bhandari' ; 6lo@ietf.org; an...@ece.iisc.ernet.in; 'satish anamalamudi' ; draft-ietf-6lo-deadline-t...@ietf.org Subject: Re: [6lo] Magnus Westerlund's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT) Hi, Thanks for providing some background information. From my perspective I think there are some benefit to indicate the context the solution was developed in. Note this is really comment level and not required. On 2019-06-05 07:54, Lijo Thomas wrote: > Hi Magnus, > > Thanks for your detailed review and really appreciate your time taken > for the effort . > > Please find our below response for the frame work query addressed by you. > > One of the main use cases of the draft is the industrial automation > and control applications. The end point of such applications puts the > deadline information as per its delay requirements. > > I agree that the underlying 6Lo network needs to ensure that the > deadline is met using its delay sensitive routing and scheduling > mechanisms while forwarding the packet along the path. The 6Lo network > can support such a QoS requirement through end-to-end provisioning of > the required network resources either centrally and/or in a distributed fashion . > > In the case of a 6tisch network, one could think of setting up tracks > [draft-ietf-6tisch-architecture] along with delay aware Scheduling > Function implemented by the intermediate nodes. The deadline draft > works well within the context of the framework described in the > draft-6tisch-architecture draft. The 6tisch architecture draft defines > tracks which could either be set up by a centralised entity PCE or by > setting up tracks in a distributed fashion by reserving network > resources that provide end-to-end delay guarantees. Packets of > application flows can be sent over these tracks and scheduled based on > their deadlines. The CAC can be exercised where reservation fails for > a new track setup. There are situations like asynchronous time > critical emergency messages where track set up delay is not > acceptable. In such cases, we can use distributed on-the-fly > scheduling using 6P protocol described in RFC 8480 that takes into consideration the deadline information. > > There are several deadline based scheduling algorithms that have > proposed in the literature including the basic Earliest Deadline First > (EDF). Based on our deadline draft, we implemented this scheme over a > 6tisch network running on OpenWSN protocol stack and our draft > implementation has been merged with the OpenWSN environment for future downloads too. > > We would be happy to add some additional text specifying that ** a > network monitoring entity with call admission policy is expected to be > in place for observation and consequently better results during real implementations**. The proposed sentence appears problematic from two perspective. One that it might be an overly complex solution for certain closed systems. Secondly, is it really "call admission" rather than flow admission? I think the right way forward here is that you document the security issues that anyone that intend to deploy this needs to consider. I think that discussion can discuss potential mitigations, but without specific surround contexts it is impossible to mandate any such. Cheers Magnus > > Hope this address your few concerns and based on your response we will > update the draft. > > Happy to receive your further thoughts and valuable inputs. > > Thanks & Regards, > Lijo Thomas > > -Original Message- > From: 6lo <6lo-boun...@ietf.org> On Behalf Of Magnus Westerlund > Sent: 03 June 2019 18:27 > To: Charlie Perkins ; The IESG > > Cc: draft-ietf-6lo-deadline-t...@ietf.org; 6lo-cha...@ietf.org; Samita > Chakrabarti ; Shwetha Bhandari > ; 6lo@ietf.org > Subject: Re: [6lo] Magnus Westerlund's Discuss on > draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT) > > Hi Charlie, > > Please see for further comments inline. > > On 2019-05-30 23:16, Charlie Perkins wrote: >> On 5/13/2019 6:41 AM, Magnus Westerlund via Datatracker wrote: >>> Magnus Westerlund has entered the following ballot position for >>> draft-ietf-6lo-deadline-time-04: Discuss >>> >>> >>> >>> >>> >>> - >>> - >>> DISCUSS: >>> ---
Re: [6lo] [SPF:fail] RE: uncompressed form
Hi Pascal, Thanks for your inputs. The draft specifies variable length deadline-time representation, only required no. of bits to be carried and no compression methods are followed . The current revision is capable of carrying deadline time in ntp format also. We envisaged to use dispatch routing header for transporting deadline time. We agree your point that once the packet leaves the RPL network, then the deadline information has to be carried in hop-by-hop header. In fact we mentioned required text for calculating deadline time, while traversing through different time zones. Thanks & Regards, Lijo Thomas From: Pascal Thubert (pthubert) Sent: 23 May 2019 17:38 To: Abdussalam Baryun Cc: draft-ietf-6lo-deadline-t...@ietf.org; 6lo@ietf.org Subject: [SPF:fail] RE: [6lo] uncompressed form Dear all The use case is when the data sync is not in the RPL domain or the packet has to fly outside the RPL domain. E.g., A PLC virtualized in a MEC. The root needs to uncompress the packet and forward. The draft is missing the uncompressed form. All the best, Pascal From: Abdussalam Baryun < <mailto:abdussalambar...@gmail.com> abdussalambar...@gmail.com> Sent: jeudi 23 mai 2019 13:31 To: Pascal Thubert (pthubert) < <mailto:pthub...@cisco.com> pthub...@cisco.com> Cc: <mailto:draft-ietf-6lo-deadline-t...@ietf.org> draft-ietf-6lo-deadline-t...@ietf.org; <mailto:6lo@ietf.org> 6lo@ietf.org Subject: Re: [6lo] uncompressed form On Thu, May 23, 2019 at 7:54 AM Pascal Thubert (pthubert) < <mailto:pthub...@cisco.com> pthub...@cisco.com> wrote: Dear all: I was rereading deadline and realized that the draft does not provide an umcompressed form. What of the packet flies beyond the RPL domain? I think the information should be useful there too. why useful? could you explain the use case? Also we always claimed that RFC8138 is an encoding and that we can always turn a packet to uncompressed and back. Deadline creates an exception to that rule, which changes RFC 8138 into a sub IP protocol as opposed to a compression. All in all, I think that an IPv6 header (e.g., a new option in a hop-by-hop header) should be provided, even if for now it appears to be for completeness only. What do others think? I need to know the use case. Best regards, AB [ 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. ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] I-D Action: draft-ietf-6lo-deadline-time-04.txt
Hi all, A new version of the deadline draft has been released addressing various reviewers' comments. Thanks a lot for all the reviews.. Happy to receive further comments !! Thanks & Regards, Lijo Thomas -Original Message- From: 6lo <6lo-boun...@ietf.org> On Behalf Of internet-dra...@ietf.org Sent: 09 March 2019 03:04 To: i-d-annou...@ietf.org Cc: 6lo@ietf.org Subject: [6lo] I-D Action: draft-ietf-6lo-deadline-time-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Networks of Resource-constrained Nodes WG of the IETF. Title : Packet Delivery Deadline time in 6LoWPAN Routing Header Authors : Lijo Thomas Satish Anamalamudi S.V.R Anand Malati Hegde Charles E. Perkins Filename: draft-ietf-6lo-deadline-time-04.txt Pages : 18 Date: 2019-03-08 Abstract: This document specifies a new type for the 6LoWPAN routing header containing the deadline time for data packets, designed for use over constrained networks. The deadline time enables forwarding and scheduling decisions for time critical IoT M2M applications that operate within time-synchronized networks that agree on the meaning of the time representations used for the deadline time values. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6lo-deadline-time-04 https://datatracker.ietf.org/doc/html/draft-ietf-6lo-deadline-time-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-deadline-time-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo [ 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. ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Call for adoption of draft-hou-6lo-plc
Hi all, IPv6 over PLC seems to be useful. I support the adoption of this draft. Thanks & Regards, Lijo Thomas -Original Message- From: 6lo <6lo-boun...@ietf.org> On Behalf Of Carles Gomez Montenegro Sent: 24 January 2019 13:17 To: Gabriel Montenegro ; lo <6lo@ietf.org>; samita.chakraba...@verizon.com Cc: draft-hou-6lo-...@ietf.org Subject: Re: [6lo] Call for adoption of draft-hou-6lo-plc Dear all, I also support adoption of this draft. As it has been expressed, this draft is needed for running IPv6 over PLC, which is a widely used technology in relevant application domains. About the document itself, it already has a good structure and good content, therefore, in my opinion, it is a good basis for a WG document. Cheers, Carles > I support the adoption of this draft. PLC is widely used in the 6lo > scenarios and thus should be covered. > > Regards, > Rahul > > > From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of Gabriel > Montenegro > Sent: 17 January 2019 06:45 > To: lo <6lo@ietf.org>; samita.chakraba...@verizon.com > Cc: draft-hou-6lo-...@ietf.org > Subject: [6lo] Call for adoption of draft-hou-6lo-plc > > Hi folks, > > > This message initiates a 2 week call-for-adoption for: > https://datatracker.ietf.org/doc/draft-hou-6lo-plc/ > > (currently at rev 5) > > > Please send your opinion (for or against) to the mailing list on > adopting this document as a 6lo WG document. > > > > This call for adoption will end at 00:00 UTC on January 30, 2019. > > > > Regards, > > Chairs > > ___ > 6lo mailing list > 6lo@ietf.org > https://www.ietf.org/mailman/listinfo/6lo > ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo [ 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. ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Last Call: (Packet Delivery Deadline time in 6LoWPAN Routing Header) to Proposed Standard
Hi Tal, Thanks for your comments. The scope of our deadline-time draft is confined to a resource constrained 6lo network and hence specifies the DT/OT time representation that is suited for such networks. The draft specifies an encoding method for expressing the deadline time of a packet for its transmission over a resource constrained 6lo network. So really, the interpretation of Time Unit is scoped to the underlying network technology and the definition(s) of time it provides as specified by the underlying network. So we feel the won’t be applicable to our case. For providing more clarity as indicated by Suresh Krishnan too, we will add appropriate text in the next revision. Happy to receive further comments if any; Thanks & Regards, Lijo Thomas <https://www.codetwo.com/> From: 6lo <6lo-boun...@ietf.org> On Behalf Of Tal Mizrahi Sent: 23 December 2018 14:20 To: i...@ietf.org Cc: draft-ietf-6lo-deadline-t...@ietf.org; 6lo-cha...@ietf.org; Samita Chakrabarti ; n...@ietf.org; 6lo@ietf.org; ntp-cha...@ietf.org; sur...@kaloom.com; IETF-Announce Subject: Re: [6lo] Last Call: (Packet Delivery Deadline time in 6LoWPAN Routing Header) to Proposed Standard Hi, I am not a 6lo native, but I reviewed the draft specifically from a timestamp formatting perspective. In the NTP working group we currently have a draft in WGLC that presents guidelines for defining timestamp formats. https://tools.ietf.org/html/draft-ietf-ntp-packet-timestamps-05 I believe that the definitions of the timestamps (DT and OT) in draft-ietf-6lo-deadline-time should be more detailed. For example, aspects about the epoch and the potential effect of leap seconds are currently not described in the current draft. I would suggest to follow the timestamp specification template of Section 3 in draft-ietf-ntp-packet-timestamps-05. Thanks, Tal. On Mon, Dec 10, 2018 at 2:27 PM The IESG mailto:iesg-secret...@ietf.org> > wrote: The IESG has received a request from the IPv6 over Networks of Resource-constrained Nodes WG (6lo) to consider the following document: - 'Packet Delivery Deadline time in 6LoWPAN Routing Header' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org <mailto:i...@ietf.org> mailing lists by 2018-12-24. Exceptionally, comments may be sent to i...@ietf.org <mailto:i...@ietf.org> instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a new type for the 6LoWPAN routing header containing the delivery deadline time for data packets. The deadline time enables forwarding and scheduling decisions for time critical IoT M2M applications that need deterministic delay guarantees over constrained networks and operate within time-synchronized networks. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: draft-ietf-6tisch-terminology: Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e (None - IETF stream) [ 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. ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] I-D Action: draft-ietf-6lo-deadline-time-03.txt
Hi, We have posted a the new version (03) of our deadline-time draft , addressing the review comments of 1. Wesley Eddy 2. Donald E. Eastlake 3. Samita Chakrabarti. https://tools.ietf.org/pdf/draft-ietf-6lo-deadline-time-03.pdf Thanks all for your valuable inputs and happy to receive your further comments if any; Thanks & Regards, Lijo Thomas -Original Message- From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: 16 October 2018 09:51 To: i-d-annou...@ietf.org Cc: 6lo@ietf.org Subject: [6lo] I-D Action: draft-ietf-6lo-deadline-time-03.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Networks of Resource-constrained Nodes WG of the IETF. Title : Packet Delivery Deadline time in 6LoWPAN Routing Header Authors : Lijo Thomas Satish Anamalamudi S.V.R Anand Malati Hegde Charles E. Perkins Filename: draft-ietf-6lo-deadline-time-03.txt Pages : 17 Date: 2018-10-15 Abstract: This document specifies a new type for the 6LoWPAN routing header containing the delivery deadline time for data packets. The deadline time enables forwarding and scheduling decisions for time critical IoT M2M applications that need deterministic delay guarantees over constrained networks and operate within time-synchronized networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6lo-deadline-time-03 https://datatracker.ietf.org/doc/html/draft-ietf-6lo-deadline-time-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-deadline-time-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo [ 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. ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Iotdir early review of draft-ietf-6lo-deadline-time-02
Dear Wesley, Thanks for your valuable comments. Please find the inline answers (marked as LT >>) for your comments in the below email. Happy to receiver your further inputs ... Thanks & Regards Lijo Thomas On September 19, 2018 at 10:02 AM Wesley Eddy wrote: Reviewer: Wesley Eddy Review result: Ready with Issues The draft is easily readable and can be understood and should be simple to implement by someone working in the area. I only have one technical issue that I think should definitely need to be resolved, and a few small editorial comments. Technical issues: - The point of the D-bit is confusing. It is supposed to indicate whether the packet MUST be dropped when the deadline is exceeded. However, if the D-bit is zero, the document says that a 6LR "MAY" forward the packet anyways. Since this uses MAY rather than "MUST" or "MUST NOT", it seems like there should be some example use case, scenario, or rationale for why an implementer would choose one way or the other, or how they would include logic to make the decision when the D-bit is 0. Fundamentally though, I'm also unsure why a sender would include a deadline and then set the D-bit to 0 ... is it maybe something like they still want the packet to be delivered so that network measurements of current latency or other properties can be measured using the packet? If the deadline is missed due to congestion/contention causing increased delays, then it seems prudent to always drop the packet, in which case the D-bit would not be needed. >> LT : As you rightly noted, the primary reason for giving an option 0 for 'D' >> bit is for making delay measurements, >> >> and >> also to perform packet delay analysis on the bottleneck segments that are >> causing the deadline to exceed and take remedial action if possible. Will the below additional text substantiate the usage of D bit set to 0 case: " The usage of D bit set to 0 implies the packet MAY be forwarded on an exception basis, if the forwarding node is NOT in a situation of constrained resource, and if there are reasons to suspect that downstream nodes might find it useful (delay measurements, interpolations, etc.) " Kindly let me know your inputs .. Editorial comments: - In Section 1, 2nd paragraph, it would probably be good to explain what an elective RH is and define 6LoRHE as an elective 6LoRH here, before "6LoRHE" is used in the Deadline-6LoRHE name. >> LT : Will update the draft with the corrections - In Section 1, last paragraph, it would be good to add informative references for the last two sentences mentioning Bluetooth and Wi-SUN work in this area. >> LT : Will put the informative references. - In Section 4, last paragraph, it might be worth mentioning for clarity that there are also potentially long serialization delay and MAC layer contention delays in some of the relevant network types. These could dominate propagation and queueing that are mentioned, in some feasible cases. >> LT : Nice suggestion, will update the draft. - The "Length of DT field" and "Length of OT field" descriptions seem a bit light, although from the examples it is clear, but they could be replaced with something more clear like "Length of DT field as an unsigned 3-bit integer, encoding the length of the field in octets, minus one." >> LT : Will modify the draft and make the corrections based on the inputs >> provided. [ 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. ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] Working Group call for adoption on draft-watteyne-6lo-minimal-fragment and draft-thubert-6lo-forwarding-fragments
Hi all, I support the adoption of both the drafts. And I believe both the drafts will be useful for the real field implementations using 6LoWPAN networks. Thanks & Regards, Lijo Thomas From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of Gabriel Montenegro Sent: 12 September 2018 23:18 To: lo Subject: Re: [6lo] Working Group call for adoption on draft-watteyne-6lo-minimal-fragment and draft-thubert-6lo-forwarding-fragments Folks, This CfA was over a while back. I saw no messages in response. We have discussed these drafts several times in f2f meetings and the interest level has been good. Nevertheless, I'd like to get some *explicit messages in support of the Call for Adoption*. If you think these drafts should be adopted (or not), please send a message to that effect in response. Let's give it another week. Thanks, Gabriel From: 6lo < <mailto:6lo-boun...@ietf.org> 6lo-boun...@ietf.org> On Behalf Of Gabriel Montenegro Sent: 15 August, 2018 17:33 To: lo < <mailto:6lo@ietf.org> 6lo@ietf.org> Subject: [6lo] Working Group call for adoption on draft-watteyne-6lo-minimal-fragment and draft-thubert-6lo-forwarding-fragments Hi folks, Per discussion in Montreal, there was consensus in the room to adopt the two drafts output by the Fragmentation Design Team: <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf ..org%2Fhtml%2Fdraft-watteyne-6lo-minimal-fragment%2F=02%7C01%7CGabriel. Montenegro%40microsoft.com%7C676a7c74d0e5457c051e08d6030fd132%7C72f988bf86f1 41af91ab2d7cd011db47%7C1%7C0%7C636699763806670559=x32dZk2Qpp0pVB7ZZsKF GACy6eMSGxgXGjeLxscaYuo%3D=0> MailScanner has detected a possible fraud attempt from "na01.safelinks.protection.outlook.com" claiming to be MailScanner has detected definite fraud in the website at "na01.safelinks.protection.outlook.com". Do not trust this website: https://tools.ietf.org/html/draft-watteyne-6lo-minimal-fragment/ <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf ..org%2Fhtml%2Fdraft-thubert-6lo-forwarding-fragments%2F=02%7C01%7CGabri el.Montenegro%40microsoft.com%7C676a7c74d0e5457c051e08d6030fd132%7C72f988bf8 6f141af91ab2d7cd011db47%7C1%7C0%7C636699763806680567=GnQasPX7bRRhPQSSZ 7cnAWmzcTSIQZ%2BPkAQOR9Yg2y8%3D=0> MailScanner has detected a possible fraud attempt from "na01.safelinks.protection.outlook.com" claiming to be MailScanner has detected definite fraud in the website at "na01.safelinks.protection.outlook.com". Do not trust this website: https://tools.ietf.org/html/draft-thubert-6lo-forwarding-fragments/ This message initiates a 2 week call-for-adoption to confirm the Montreal consensus on the list. Please send your opinion (for or against) to the mailing list on adopting these documents as 6lo WG documents. This call for adoption will end at 00:00 UTC on August 29, 2018. Regards, Chairs [ 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. ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
Re: [6lo] I-D Action: draft-ietf-6lo-deadline-time-02.txt
Hi Samita and all, No, I am not aware of any IPR that applies to 6lo-deadline draft. Thanks & Regards, Lijo Thomas From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of Samita Chakrabarti Sent: 04 September 2018 02:04 To: Lijo Thomas Cc: lo Subject: Re: [6lo] I-D Action: draft-ietf-6lo-deadline-time-02.txt Hi Lijo and co-authors, Are you aware of any IPR involving the method described in the 6lo-deadline draft? If yes, please record the IPR at https://datatracker.ietf.org/ipr/search/?submit=draft <https://datatracker.ietf.org/ipr/search/?submit=draft=draft-ietf-6lo-deadline-time> =draft-ietf-6lo-deadline-time as soon as possible. Shepherd writeup will wait for the confirmation from your side. Thanks, -Samita On Fri, Aug 31, 2018 at 6:00 AM Lijo Thomas mailto:l...@cdac..in> > wrote: Hi all, Published a new version -02 of our draft which addressed the review comments from Georgios and Samita. Will be happy to receive your feedback and further inputs ... https://tools.ietf.org/html/draft-ietf-6lo-deadline-time-02 Thanks & Regards, Lijo Thomas -Original Message- From: 6lo [mailto:6lo-boun...@ietf.org <mailto:6lo-boun...@ietf.org> ] On Behalf Of internet-dra...@ietf.org <mailto:internet-dra...@ietf.org> Sent: 31 August 2018 14:48 To: i-d-annou...@ietf.org <mailto:i-d-annou...@ietf.org> Cc: 6lo@ietf.org <mailto:6lo@ietf.org> Subject: [6lo] I-D Action: draft-ietf-6lo-deadline-time-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over Networks of Resource-constrained Nodes WG of the IETF. Title : Packet Delivery Deadline time in 6LoWPAN Routing Header Authors : Lijo Thomas Satish Anamalamudi S.V.R Anand Malati Hegde Charles E. Perkins Filename: draft-ietf-6lo-deadline-time-02.txt Pages : 15 Date: 2018-08-31 Abstract: This document specifies a new type for the 6LoWPAN routing header containing the delivery deadline time for data packets. The deadline time enables forwarding and scheduling decisions for time critical IoT M2M applications that need deterministic delay guarantees over constrained networks and operate within time-synchronized networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6lo-deadline-time-02 https://datatracker.ietf.org/doc/html/draft-ietf-6lo-deadline-time-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-deadline-time-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org> . Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ 6lo mailing list 6lo@ietf.org <mailto:6lo@ietf.org> https://www.ietf.org/mailman/listinfo/6lo [ 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. ___ 6lo mailing list 6lo@ietf.org <mailto:6lo@ietf.org> https://www.ietf.org/mailman/listinfo/6lo [ 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. ___
Re: [6lo] working group last call (wg lc) on https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/
Dear Georgios, Thanks for the feedback, responding to your query : Deadline Time (DT) by itself does not guarantee deterministic behaviour, but its information enables intermediate nodes to implement delay sensitive scheduling and routing algorithms towards achieving deterministic behaviour. As a use case application of our draft, we implemented a basic EDF policy in OpenWSN 6tisch stack. Please find the link for our openwsn implementation https://github.com/openwsn-berkeley/openwsn-fw/tree/develop/openapps/uexpiration Thanks & Regards, Lijo Thomas From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of Georgios Z. Papadopoulos Sent: 24 July 2018 13:49 To: Lijo Thomas Cc: draft-ietf-6lo-deadline-t...@ietf.org; an...@ece.iisc.ernet.in; Malati Hegde; Samita Chakrabarti; Gabriel Montenegro; lo; Charlie Perkins; satishnaid...@gmail.com Subject: Re: [6lo] working group last call (wg lc) on https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/ Hello Lijo, Thank you so much for your detailed comments. I appreciate it very much. I am happy with your response, I just have one last clarification point, see below: On Jul 24, 2018, at 09:38, Lijo Thomas mailto:l...@cdac.in> > wrote: Dear Georgios, Thanks for your valuable suggestions and we really appreciate for taking your valuable time for the review . Please find our comments inline below marked as (*** [LT]) We will be happy to receive your further inputs !!! Thanks & Regards, Lijo Thomas From: 6lo [ <mailto:6lo-boun...@ietf.org> mailto:6lo-boun...@ietf.org] On Behalf Of Georgios Z. Papadopoulos Sent: 17 July 2018 21:40 To: <mailto:l...@cdac.in> l...@cdac.in Cc: <mailto:draft-ietf-6lo-deadline-t...@ietf.org> draft-ietf-6lo-deadline-t...@ietf.org; <mailto:an...@ece.iisc.ernet.in> an...@ece.iisc.ernet.in; Malati Hegde; Samita Chakrabarti; Gabriel Montenegro; lo; Charlie Perkins; <mailto:satishnaid...@gmail.com> satishnaid...@gmail.com Subject: Re: [6lo] working group last call (wg lc) on <https://datatracker..ietf.org/doc/draft-ietf-6lo-deadline-time/> https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/ Dear Lijo and co-authors, I went through the draft, please find my comments below: — — High level comments: */ [GP] The draft defines the Deadline Time (DT), but it is not clear to me how the arrival of the datagram within this pre-defined DT period is guaranteed? Indeed, the draft provides the necessary DT information, however, the only action I could observe is the delay-sensitive datagram to be dropped if the indicated DT is elapsed. *** [LT] Yes, the Deadline Time (DT) specifies the maximum allowable delay before which the packet should be delivered to the destination. The proposed draft provides a mechanism for transporting the DT information. By incorporating deadline based scheduling/routing mechanisms within the intermediate nodes using DT, one could guarantee deterministic behavior in terms of delay. [GP] Would you agree that this draft do not guarantees deterministic behavior in terms of delay, but it provides the information of maximum allowable delay for a packet to be delivered to the destination? To be more precise, for instance, lets us consider the following multi-hop network A—> B —> C. According this draft, it will required 2 timeslots (or 20ms) for a packet to be delivered at the DODAG Root C. However, if there is an external interference from A to B, then A may need to retransmit multiple times in order the datagram to be received by B. Then there are two options according to the draft: a) the datagram is dropped, to reduce the traffic, energy consumption. b) the datagram is delivered even if the deadline time is crossed, i.e., as you said in your e-mail “in some scenarios where the intention is also to know the total delay experienced by the packets in a network” In both bases, a and b, there is no guarantee that the datagram will be delivered in predefined time, i.e., in deterministic behavior. — — Thank you so much, Georgios Georgios Z. Papadopoulos, Ph.D. Associate Professor, IMT Atlantique, Rennes web: www.georgiospapadopoulos.com <http://www.georgiospapadopoulos.com> twitter:@gzpapadopoulos <https://twitter.com/gzpapadopoulos?ref_src=twsrc%5Etfw_url=http://georgiospapadopoulos.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 inten
Re: [6lo] working group last call (wg lc) on https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/
Dear Georgios, Thanks for your valuable suggestions and we really appreciate for taking your valuable time for the review . Please find our comments inline below marked as (*** [LT]) We will be happy to receive your further inputs !!! Thanks & Regards, Lijo Thomas From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of Georgios Z. Papadopoulos Sent: 17 July 2018 21:40 To: l...@cdac.in Cc: draft-ietf-6lo-deadline-t...@ietf.org; an...@ece.iisc.ernet.in; Malati Hegde; Samita Chakrabarti; Gabriel Montenegro; lo; Charlie Perkins; satishnaid...@gmail.com Subject: Re: [6lo] working group last call (wg lc) on https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/ Dear Lijo and co-authors, I went through the draft, please find my comments below: — — High level comments: */ [GP] The draft defines the Deadline Time (DT), but it is not clear to me how the arrival of the datagram within this pre-defined DT period is guaranteed? Indeed, the draft provides the necessary DT information, however, the only action I could observe is the delay-sensitive datagram to be dropped if the indicated DT is elapsed. *** [LT] Yes, the Deadline Time (DT) specifies the maximum allowable delay before which the packet should be delivered to the destination. The proposed draft provides a mechanism for transporting the DT information. By incorporating deadline based scheduling/routing mechanisms within the intermediate nodes using DT, one could guarantee deterministic behavior in terms of delay. */ [GP] I noticed that there are two different notations for LBR and 6LBR. Shouldn’t be always 6LBR (6LBR1 and 6LBR2 when it comes to the use-cases in Section 6), instead of LBR, LBR1, LBR2 or 6LBR? *** [LT] Agreed, we will update the draft. */ “D flag (1 bit): The 'D' flag, set by the Sender, indicates the action to be taken when a 6LR detects that the deadline time has elapsed. If 'D' bit is 1, then the 6LR MUST drop the packet if the deadline time is elapsed. If 'D' bit is 0, then the 6LR MAY ignore the deadline time and forward the packet.” [GP] It is not clear to me why the datagram should be dropped, if the 6LR detects that the DL has elapsed? To reduce the traffic in the network or ? *** [LT] Yes that was the motivation of having 'D' flag to begin with. We could save bandwidth, and energy etc., by discarding packets whose deadlines are crossed when 'D' flag is set to 1. [GP] Then, the main difference in networks where this DRAFT is not considered, is that the packets are not dropped? Because otherwise the packets are forwarded (when ‘D’ bit is 0). *** [LT] Yes, moreover in some scenarios where the intention is also to know the total delay experienced by the packets in a network, this could be obtained by setting 'D' bit set to 0. In such scenarios, we may want to receive the packets even though the deadline is crossed. Detailed comments: */ 5. Deadline-6LoRHE Format “Deadline-6LoRHE encoding with 'O' flag set to 1 : DTL = 001, OTL = 001, TU = '10', EXP = 2, DT = 0x22B, OT = 0x22A” [GP] What about the ‘D’ here? *** [LT] We will update the example by putting 'D' bit = 1. */ 6. Deadline-6LoRHE in Three Network Scenarios [GP] Any router/device may drop the datagram (if it detects that the indicated time has elapsed), both 6LR (Relay devices) and 6LBR (DODAG Root)? */ 6.1. Scenario 1: Endpoints in the same DODAG (N1) in non-storing mode. “Then 6LR begins hop-by-hop operation to forward the packet towards the 6LBR” [GP] Then 6LR begins or “Then the 6LRs begin”? (not only one 6LR but each 6LR). OR it should be written as in Scenario 6.3 : “Subsequently, each 6LR will perform hop-by-hop operation to forward the packet towards the 6LBR.” *** [LT] Nice suggestion, will update. */ 6.2. Scenario 2: Endpoints in Networks with Dissimilar L2 Technologies. “Subsequently, 6LR will perform hop- by-hop operation to forward the packet towards the 6LBR” [GP] Subsequently, “EACH” 6LR OR it should be written as in Scenario 6.3 : “Subsequently, each 6LR will perform hop-by-hop operation to forward the packet towards the 6LBR.” *** [LT] Will modify the draft */ 6.3. Scenario 3: Packet transmission across different DODAGs (N1 to N2). “Once the packet reaches LBR2, it updates the Deadline-6LoRHE by adding the current time of DODAG2.” [GP] is not clear to me, why “adding”, why not “subtracting”, as you mention in page 10. *** [LT] Thanks for pointing it out, we will modify the text it as in page 10. [GP] Furthermore, in the example later of 6TiSCH network: Instead of supposing an example of ASN 20050, would make sense actually to have ASN 20030, based on the topology in Figure 6, that comes with three hops. Similarly, the rest of the math operations could be more specific, based on the topology in Figure 6. *** [LT] Great observation, we will update the example !! */ In Scenario 2: [GP] (Optionally) DODAG 1 could be indicated/highlighted in the Figu
Re: [6lo] IETF WG state changed for draft-ietf-6lo-deadline-time
Dear 6lo chairs, We wish to know how we could take our draft forward. We will be happy to receive your suggestions and move forward. Thanks & Regards, Lijo Thomas -Original Message- From: IETF Secretariat [mailto:ietf-secretariat-re...@ietf.org] Sent: 21 June 2018 02:27 To: draft-ietf-6lo-deadline-t...@ietf.org; 6lo-cha...@ietf.org; samitac.i...@gmail.com Subject: IETF WG state changed for draft-ietf-6lo-deadline-time The IETF WG state of draft-ietf-6lo-deadline-time has been changed to "WG Consensus: Waiting for Write-Up" from "In WG Last Call" by Gabriel Montenegro: https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/ --- [ 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. --- ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
[6lo] Open implementations on 6lo - draft-ietf-6lo-deadline-time
Hi Samita, We implemented our 6lo draft in open source OpenWSN environment and got merged with the main distribution. Please find the github links for the same. https://github.com/openwsn-berkeley/openwsn-fw/tree/develop/openapps/uexpiration https <https://github.com/openwsn-berkeley/openwsn-fw/pull/355> :// <https://github.com/openwsn-berkeley/openwsn-fw/pull/355> github.com/openwsn-berkeley/openwsn-fw/pull/355 <https://github.com/openwsn-berkeley/openwsn-fw/pull/355> Have a look and include in the Wikipedia page if it suits. Thanks & Regards, Lijo Thomas From: 6lo [mailto:6lo-boun...@ietf.org] On Behalf Of Samita Chakrabarti Sent: 09 July 2018 09:24 To: Carles Gomez Montenegro Cc: lo Subject: Re: [6lo] An article on 6Lo Hi Carles, Thanks so much for setting the example and spreading words about IETF 6lo work. Others, if you have any repository on the open implementations on 6lo please let this wg know. I plan to update the wikipedia page with some basic information on 6lo WG plus documents and will request the WG to update accordingly. Best regards, -Samita On Thu, Jul 5, 2018 at 12:44 AM, Carles Gomez Montenegro mailto:carle...@entel.upc.edu> > wrote: Dear all, In the last IETF meeting, one of the topics discussed during the 6Lo WG session was promoting 6Lo. One thing that hopefully may contribute in this regard is an article we published few months ago in IEEE Communications Magazine: C. Gomez, J. Paradells, C. Bormann, J. Crowcroft, "From 6LoWPAN to 6Lo: Expanding the Universe of IPv6-Supported Technologies for the Internet of Things", IEEE Communications Magazine, Vol. 55, Issue 2, Dec 2017, pp. 148-155. The IEEE link to the article is: https://ieeexplore.ieee.org/document/8198820 For folks that do not have access to IEEE, a preprint can be found here: https://www.researchgate...net/publication/318472017_From_6LoWPAN_to_6Lo_Expanding_the_Universe_of_IPv6-Supported_Technologies_for_the_Internet_of_Things <https://www.researchgate.net/publication/318472017_From_6LoWPAN_to_6Lo_Expanding_the_Universe_of_IPv6-Supported_Technologies_for_the_Internet_of_Things> We hope this can be useful to the community. Cheers, Carles ___ 6lo mailing list 6lo@ietf.org <mailto:6lo@ietf.org> https://www.ietf.org/mailman/listinfo/6lo --- [ 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. --- ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
[6lo] New Version Notification for draft-lijo-6lo-expiration-time-03.txt
Hi All, A new version of I-D, draft-lijo-6lo-expiration-time-03.txt has been successfully submitted and posted to the IETF repository. https://www.ietf.org/id/draft-lijo-6lo-expiration-time-03.txt The draft has been revised according to the comments received during IETF 98 meeting. One of the notable aspects of this version is the inclusion of "Network ASN" as one of the time units. Special thanks to Dale for this great suggestion Happy to receive comments and valuable feedbacks. 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. --- 6lo Lijo Thomas Internet-Draft C-DAC Intended status: Standards Track P. Akshay Expires: December 23, 2017 Indian Institute of Science Satish Anamalamudi Huaiyin Institute of Technology S.V.R.Anand Malati Hegde Indian Institute of Science C. Perkins Futurewei June 21, 2017 Packet expiration time in 6LoWPAN Routing Header draft-lijo-6lo-expiration-time-03 Abstract This document specifies a new type for the 6LoWPAN Dispatch Page 1 for carrying the expiration time of data packets within the 6LoWPAN routing header. The expiration time is useful in making forwarding and scheduling decisions for time critical IoT M2M applications that need deterministic delay guarantees over constrained networks and operate within time-synchronized networks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 23, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. Lijo Thomas, et al. Expires December 23, 2017 [Page 1] Internet-Draft 6lo Expiration Time June 2017 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 6LoRHE Generic Format . . . . . . . . . . . . . . . . . . . . 3 4. Deadline-6LoRH Description . . . . . . . . . . . . . . . . . 3 5. Deadline-6LoRH Format . . . . . . . . . . . . . . . . . . . . 4 6. Deadline-6LoRH in Three Network Scenarios . . . . . . . . . . 6 6.1. Scenario 1: Endpoints in the same DODAG (N1) in
[6lo] FW: New Version Notification for draft-lijo-6lo-expiration-time-02.txt
Hi All, A new version of I-D, draft-lijo-6lo-expiration-time-02.txt has been successfully submitted and posted to the IETF repository. https://www.ietf.org/internet-drafts/draft-lijo-6lo-expiration-time-02.txt The draft has been revised according to the comments received during IETF 97 meeting and on the mailing lists. Thanks to Pascal, Thomas and Dale for their comments. Happy to receive comments and feedback on the new version. Thanks and Regards, Lijo Thomas -Original Message- From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] Sent: 13 March 2017 23:41 To: S.V.R Anand; Charles Perkins; Satish Anamalamudi; Lijo Thomas; Malati Hegde; P.M. Akshay; Charles E. Perkins Subject: New Version Notification for draft-lijo-6lo-expiration-time-02.txt A new version of I-D, draft-lijo-6lo-expiration-time-02.txt has been successfully submitted by Charles E. Perkins and posted to the IETF repository. Name: draft-lijo-6lo-expiration-time Revision: 02 Title: Packet expiration time in 6LoWPAN Routing Header Document date: 2017-03-13 Group: Individual Submission Pages: 13 URL: https://www.ietf.org/internet-drafts/draft-lijo-6lo-expiration-time-02.txt Status: https://datatracker.ietf.org/doc/draft-lijo-6lo-expiration-time/ Htmlized: https://tools.ietf.org/html/draft-lijo-6lo-expiration-time-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-lijo-6lo-expiration-time-02 Abstract: This document specifies a new type to the 6LoWPAN Dispatch Page 1 for carrying the expiration time of data packets within the 6LoWPAN routing header. The expiration time is useful in making forwarding and scheduling decisions for time critical IoT M2M applications that need deterministic delay guarantees over constrained networks and operate within time-synchronized networks. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --- [ 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. --- 6lo Lijo Thomas Internet-Draft C-DAC Intended status: Standards Track P. Akshay Expires: September 14, 2017 Indian Institute of Science Satish Anamalamudi Huaiyin Institute of Technology S.V.R.Anand Malati Hegde Indian Institute of Science C. Perkins Futurewei March 13, 2017 Packet expiration time in 6LoWPAN Routing Header draft-lijo-6lo-expiration-time-02 Abstract This document specifies a new type to the 6LoWPAN Dispatch Page 1 for carrying the expiration time of data packets within the 6LoWPAN routing header. The expiration time is useful in making forwarding and scheduling decisions for time critical IoT M2M applications that need deterministic delay guarantees over constrained networks and operate within time-synchronized networks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite
[6lo] IETF 97 : Comments : draft-lijo-6lo-expiration-time-00.txt
Hi Thomas, Thanks for your valuable comments during the draft IETF97 presentation Your suggestion of including packet origination time along with the expiration time is very nice, as it conveys very useful information to the intermediate nodes as well as the receiver to know how much time has already been elapsed. We will update the draft based on your suggestion. But I foresee an interesting problem when we include the packet origination time. While it is straightforward when the source and destination belong to the same time zone, it is tricky if they belong to different time zones, as the origination time will be invalid once the packet crosses over to network segments with different time zones. For instance, when the packet traverses across 2 LBRs belonging to different 6TiSCH networks due to different ASN time spaces. We plan to discuss our resolution to such scenarios in our draft. Suggestions are most welcome Thanks & Regards, Lijo Thomas From: 6lo [ <mailto:6lo-boun...@ietf.org> mailto:6lo-boun...@ietf.org] On Behalf Of Lijo Thomas Sent: 29 October 2016 14:35 To: <mailto:6lo@ietf.org> 6lo@ietf.org Subject: [6lo] Fwd: New Version Notification for draft-lijo-6lo-expiration-time-00.txt Hi all, We have submitted a new draft t which proposes a new 6LoWPAN routing header type for conveying packet expiration time information. <https://www.ietf.org/internet-drafts/draft-lijo-6lo-expiration-time-00.txt> https://www.ietf.org/internet-drafts/draft-lijo-6lo-expiration-time-00.txt Your comments are highly appreciated. Regards Lijo Thomas -- Original Message -- From: <mailto:internet-dra...@ietf.org> internet-dra...@ietf.org To: "S.V.R Anand" < <mailto:an...@ece.iisc.ernet.in> an...@ece.iisc.ernet.in>, Satish Anamalamudi < <mailto:satishnaid...@gmail.com> satishnaid...@gmail.com>, Lijo Thomas < <mailto:l...@cdac.in> l...@cdac.in>, "P.M. Akshay" < <mailto:aksha...@ece.iisc.ernet.in> aksha...@ece.iisc.ernet.in>, Malati Hegde < <mailto:mal...@ece.iisc.ernet.in> mal...@ece.iisc.ernet.in>, Charles Perkins < <mailto:charl...@computer.org> charl...@computer.org> Date: October 29, 2016 at 11:43 AM Subject: New Version Notification for draft-lijo-6lo-expiration-time-00.txt A new version of I-D, draft-lijo-6lo-expiration-time-00.txt has been successfully submitted by Lijo Thomas and posted to the IETF repository. Name: draft-lijo-6lo-expiration-time Revision: 00 Title: Packet expiration time in 6LoWPAN Routing Header Document date: 2016-10-28 Group: Individual Submission Pages: 11 URL: <https://www.ietf.org/internet-drafts/draft-lijo-6lo-expiration-time-00.txt> https://www.ietf.org/internet-drafts/draft-lijo-6lo-expiration-time-00.txt Status: <https://datatracker.ietf.org/doc/draft-lijo-6lo-expiration-time/> https://datatracker.ietf.org/doc/draft-lijo-6lo-expiration-time/ Htmlized: <https://tools.ietf.org/html/draft-lijo-6lo-expiration-time-00> https://tools.ietf.org/html/draft-lijo-6lo-expiration-time-00 Abstract: This document specifies a new type to the 6LoWPAN Dispatch Page 1 [I-D.ietf-roll-routing-dispatch] for carrying the expiration time of data packets within the 6LoWPAN routing header. The expiration time is useful in making forwarding and scheduling decisions for time critical IoT M2M applications that need deterministic delay guarantees over constrained networks and operate within time- synchronized networks. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: <https://www.facebook.com/CDACINDIA> 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
[6lo] Fwd: New Version Notification for draft-lijo-6lo-expiration-time-00.txt
Hi all, We have submitted a new draft t which proposes a new 6LoWPAN routing header type for conveying packet expiration time information. https://www.ietf.org/internet-drafts/draft-lijo-6lo-expiration-time-00.txt Your comments are highly appreciated. Regards Lijo Thomas -- Original Message -- From: internet-dra...@ietf.org To: "S.V.R Anand" <an...@ece.iisc.ernet.in>, Satish Anamalamudi <satishnaid...@gmail.com>, Lijo Thomas <l...@cdac.in>, "P.M. Akshay" <aksha...@ece.iisc.ernet.in>, Malati Hegde <mal...@ece.iisc.ernet.in>, Charles Perkins <charl...@computer.org> Date: October 29, 2016 at 11:43 AM Subject: New Version Notification for draft-lijo-6lo-expiration-time-00.txt A new version of I-D, draft-lijo-6lo-expiration-time-00.txt has been successfully submitted by Lijo Thomas and posted to the IETF repository. Name: draft-lijo-6lo-expiration-time Revision: 00 Title: Packet expiration time in 6LoWPAN Routing Header Document date: 2016-10-28 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-lijo-6lo-expiration-time-00.txt Status: https://datatracker.ietf.org/doc/draft-lijo-6lo-expiration-time/ Htmlized: https://tools.ietf.org/html/draft-lijo-6lo-expiration-time-00 Abstract: This document specifies a new type to the 6LoWPAN Dispatch Page 1 [I-D.ietf-roll-routing-dispatch] for carrying the expiration time of data packets within the 6LoWPAN routing header. The expiration time is useful in making forwarding and scheduling decisions for time critical IoT M2M applications that need deterministic delay guarantees over constrained networks and operate within time- synchronized networks. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --- [ 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. --- ___ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
