Subject: [6lo] FW: New Version Notification for draft-thubert-6lo-forwarding-fragments-01.txt

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 14 Feb 2014 13:13:13 +0000

Dear all,

In the light of recent exchanges on the ROLL and 6TiSCH mailing lists, I suggest we focus discussions on this draft on the 6lo ML.
Considering that we are getting effective contribution indicating that the end-to-end ARQ is effectively needed, I decided to republish to reboot the work.
Once we get past the "is it really needed" question, the next fair question is whether the proposed mechanism is adapted and to evaluate eventual alternates. 

If you agree that we need fragment forwarding and recovery *please shime in*.
If you are willing to spend effective time on it and contribute to the solution, *please shime in*.
In any case, please cc the 6lo mailing list *only*.

Cheers,

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: vendredi 14 février 2014 14:05
To: Jonathan Hui (johui); Pascal Thubert (pthubert); Jonathan Hui (johui); Pascal Thubert (pthubert)
Subject: New Version Notification for draft-thubert-6lo-forwarding-fragments-01.txt

A new version of I-D, draft-thubert-6lo-forwarding-fragments-01.txt
has been successfully submitted by Pascal Thubert and posted to the IETF repository.

Name:		draft-thubert-6lo-forwarding-fragments
Revision:	01
Title:		LLN Fragment Forwarding and Recovery
Document date:	2014-02-14
Group:		Individual Submission
Pages:		14
URL:            http://www.ietf.org/internet-drafts/draft-thubert-6lo-forwarding-fragments-01.txt
Status:         https://datatracker.ietf.org/doc/draft-thubert-6lo-forwarding-fragments/
Htmlized:       http://tools.ietf.org/html/draft-thubert-6lo-forwarding-fragments-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-thubert-6lo-forwarding-fragments-01

Abstract:
   In order to be routed, a fragmented packet must be reassembled at
   every hop of a multihop link where lower layer fragmentation occurs.
   Considering that the IPv6 minimum MTU is 1280 bytes and that an an
   802.15.4 frame can have a payload limited to 74 bytes in the worst
   case, a packet might end up fragmented into as many as 18 fragments
   at the 6LoWPAN shim layer.  If a single one of those fragments is
   lost in transmission, all fragments must be resent, further
   contributing to the congestion that might have caused the initial
   packet loss.  This draft introduces a simple protocol to forward and
   recover individual fragments that might be lost over multiple hops
   between 6LoWPAN endpoints.

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