Depth-First Forwarding (DFF) in Unreliable Networks
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: RFC Editor <firstname.lastname@example.org> Subject: Document Action: 'Depth-First Forwarding in Unreliable Networks (DFF)' to Experimental RFC (draft-cardenas-dff-14.txt) 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. Additionally, one of the authors' addresses has changed: Sandra Céspedes email@example.com Icesi University Calle 18 #122-135, Pance Cali, Colombia Tel +57 (2) 5552334 Also, please add Abdussalam Baryun (University of Glamorgan) to the acknowledgements. He reviewed the document during IETF last call, but was accidentally left out of the acknowledgments.