Document Action: 'Depth-First Forwarding in Unreliable Networks (DFF)' to Experimental RFC (draft-cardenas-dff-14.txt)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The IESG has approved the following document:
- 'Depth-First Forwarding in Unreliable Networks (DFF)'
  (draft-cardenas-dff-14.txt) as Experimental RFC

This document has been reviewed in the IETF but is not the product of an
IETF Working Group.

The IESG contact person is Ted Lemon.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-cardenas-dff/




Technical Summary 

  This document specifies the "Depth-First Forwarding" (DFF) protocol 
  for IPv6 networks, a data forwarding mechanism that can increase 
  reliability of data delivery in networks with dynamic topology 
  and/or lossy links. The protocol operates entirely on the 
  forwarding plane, but may interact with the routing plane. DFF 
  forwards data packets using a mechanism similar to a "depth-first 
  search" for the destination of a packet. The routing plane may be 
  informed of failures to deliver a packet or loops. This document 
  specifies the DFF mechanism both for IPv6 networks (as specified in 
  RFC2460) and in addition also for LoWPAN "mesh-under" networks (as 
  specified in RFC4944). 

Working Group Summary 

  This document was not adopted in a Working Group.  It might have
  been an appropriate work item for the 6lowpan working group.  Reviews
  should be requested on the 6lowpan, manet and roll mailing lists.

Document Quality 

  There are currently two known implementations of the protocol.  One 
  is used on top of IEEE 802.11 and the other on top of IEEE 
  802.15.4. The authors, through this publication hope to elicit 
  further implementation and experimentation with this protocol and 
  concept. 

  Thomas Clausen has reviewed nearly every draft of this document and 
  provided detailed comments and critiques, which have been addressed 
  by the authors. 

Personnel 

  Document Shepherd: Geoff Mulligan 
  Responsible AD: Ted Lemon

RFC Editor Note

The author has requested the following change to address a concern raised during the GEN-ART review that got missed in subsequent updates:

OLD:
If no Processed Tuple (henceforth denoted the "current tuple")
     exists in the Processed Set, with:
     +  P_orig_address = the Originator Address of the current Packet;
        AND;
     +  P_seq_number = the sequence number of the current Packet.

NEW:
If no Processed Tuple (henceforth denoted the "current tuple")
     exists in the Processed Set, where both of the following
conditions are true:
     +  P_orig_address = the Originator Address of the current Packet;
        AND;
     +  P_seq_number = the sequence number of the current Packet.





[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux