[Roll] New Version Notification for draft-thubert-roll-forwarding-frags-01.txt

["Pascal Thubert (pthubert)" <[e-mail]>]

Dear WG:

As you know well, 6LoWPAN will fragment packets that are too wide for the MTU, which is likely to happen in a number of cases, unless the 802.15.4g MAC is used.

As a consequence, in a route-over RPL subnet, a large packet must be reassembled at each hop to be routed and fragmented again. 

Streamlining the fragments will improve latency, and will save memory and CPU in the intermediate nodes.

This draft enables the forwarding of fragments, which selective acknowledgement and flow control capabilities, end to end over the LLN.

Upon a private request, I resubmitted the draft with a simplification, that is the removal of en encoding that would compress the acknowledgement bitmap.

I also restored some text about Congestion notification, in order to validate the need with the group.

Please let the authors know if you have interest in pursuing this work, 

Pascal


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: lundi 25 février 2013 11:42
To: Pascal Thubert (pthubert)
Cc: Jonathan Hui (johui)
Subject: New Version Notification for draft-thubert-roll-forwarding-frags-01.txt


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

Filename:	 draft-thubert-roll-forwarding-frags
Revision:	 01
Title:		 LLN Fragment Forwarding and Recovery
Creation date:	 2013-02-25
Group:		 Individual Submission
Number of pages: 16
URL:             http://www.ietf.org/internet-drafts/draft-thubert-roll-forwarding-frags-01.txt
Status:          http://datatracker.ietf.org/doc/draft-thubert-roll-forwarding-frags
Htmlized:        http://tools.ietf.org/html/draft-thubert-roll-forwarding-frags-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-thubert-roll-forwarding-frags-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.

                                                                                  


The IETF Secretariat