LLN Fragment Forwarding and Recovery
draft-thubert-6lo-forwarding-fragments-04

Document Type Active Internet-Draft (individual)
Last updated 2017-01-10
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
6lo                                                      P. Thubert, Ed.
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                                  J. Hui
Expires: July 14, 2017                                         Nest Labs
                                                        January 10, 2017

                  LLN Fragment Forwarding and Recovery
               draft-thubert-6lo-forwarding-fragments-04

Abstract

   In order to be routed, a fragmented 6LoWPAN 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.

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 July 14, 2017.

Copyright Notice

   Copyright (c) 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents

Thubert & Hui             Expires July 14, 2017                 [Page 1]
Internet-Draft    LLN Fragment Forwarding and Recovery      January 2017

   (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.  Rationale . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  New Dispatch types and headers  . . . . . . . . . . . . . . .   8
     6.1.  Recoverable Fragment Dispatch type and Header . . . . . .   8
     6.2.  Fragment acknowledgment Dispatch type and Header  . . . .   8
   7.  Fragments Recovery  . . . . . . . . . . . . . . . . . . . . .  10
   8.  Forwarding Fragments  . . . . . . . . . . . . . . . . . . . .  11
     8.1.  Upon the first fragment . . . . . . . . . . . . . . . . .  12
     8.2.  Upon the next fragments . . . . . . . . . . . . . . . . .  13
     8.3.  Upon the fragment acknowledgments . . . . . . . . . . . .  13
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  14
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     12.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   In most Low Power and Lossy Network (LLN) applications, the bulk of
   the traffic consists of small chunks of data (in the order few bytes
   to a few tens of bytes) at a time.  Given that an 802.15.4 frame can
   carry 74 bytes or more in all cases, fragmentation is usually not
   required.  However, and though this happens only occasionally, a
   number of mission critical applications do require the capability to
   transfer larger chunks of data, for instance to support a firmware
   upgrades of the LLN nodes or an extraction of logs from LLN nodes.
Show full document text