Skip to main content

Depth-First Forwarding in Unreliable Networks
draft-cardenas-dff-04

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 6971.
Authors Ulrich Herberg , Alvaro Cardenas , Tadashige Iwao , Michael L. Dow , Sandra Cespedes
Last updated 2012-03-02
RFC stream (None)
Formats
Reviews
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Became RFC 6971 (Experimental)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-cardenas-dff-04
Internet Engineering Task Force                               U. Herberg
Internet-Draft                                               A. Cardenas
Intended status: Experimental                                    T. Iwao
Expires: September 3, 2012                                       Fujitsu
                                                                  M. Dow
                                                               Freescale
                                                             S. Cespedes
                                                 U. Icesi/U. of Waterloo
                                                           March 2, 2012

             Depth-First Forwarding in Unreliable Networks
                         draft-cardenas-dff-04

Abstract

   This document describes the Depth-First Forwarding (DFF) protocol for
   IPv6 networks based on the LoWPAN adaptation layer.  The protocol is
   a mesh-under data forwarding mechanism that increases reliability of
   data delivery.

   DFF forwards data frames using a network-wide "depth-first search"
   for the Final Destination of the frame.  DFF may be used in
   conjunction with a mesh-under routing protocol, which provides
   "hints" for DFF in which order to try to send the frame to the
   neighbors discovered by the neighborhood discovery mechanism.  In
   that case, DFF can be used as local repair mechanism.

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 September 3, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the

Herberg, et al.         Expires September 3, 2012               [Page 1]
Internet-Draft                     DFF                        March 2012

   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (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 . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Protocol Dependencies  . . . . . . . . . . . . . . . . . .  5
   2.  Notation and Terminology . . . . . . . . . . . . . . . . . . .  5
     2.1.  Notation . . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  6
   4.  Protocol Overview and Functioning  . . . . . . . . . . . . . .  7
   5.  Information Sets . . . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  Neighbor List  . . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  Processed Set  . . . . . . . . . . . . . . . . . . . . . .  8
   6.  Frame Buffering  . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  Protocol Parameters and Constants  . . . . . . . . . . . . . . 12
   9.  Data Frame Generation and Processing . . . . . . . . . . . . . 12
     9.1.  Data Frame Generation  . . . . . . . . . . . . . . . . . . 12
     9.2.  Data Frame Processing  . . . . . . . . . . . . . . . . . . 14
     9.3.  Border Gateway . . . . . . . . . . . . . . . . . . . . . . 16
   10. Unsuccessful Frame Transmission  . . . . . . . . . . . . . . . 17
     10.1. Example: Transmission Failure Detection by IEEE
           802.15.4 . . . . . . . . . . . . . . . . . . . . . . . . . 17
     10.2. Procedures upon a Transmission Failure . . . . . . . . . . 17
   11. Getting the Next Hop for a Frame . . . . . . . . . . . . . . . 18
   12. Poisoning  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   13. Route Repair Mechanism . . . . . . . . . . . . . . . . . . . . 19
   14. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . 20
   15. Proposed Values for Parameters and Constants . . . . . . . . . 20
   16. Deployment Experience  . . . . . . . . . . . . . . . . . . . . 20
     16.1. Deployments in Japan . . . . . . . . . . . . . . . . . . . 20
     16.2. Kit Carson Electric Cooperative  . . . . . . . . . . . . . 20
     16.3. Simulations  . . . . . . . . . . . . . . . . . . . . . . . 21
     16.4. Open Source Implementation . . . . . . . . . . . . . . . . 21
   17. Security Considerations  . . . . . . . . . . . . . . . . . . . 21

Herberg, et al.         Expires September 3, 2012               [Page 2]
Internet-Draft                     DFF                        March 2012

     17.1. Attacks Out of Scope . . . . . . . . . . . . . . . . . . . 21
     17.2. Protecion Mechanisms of DFF  . . . . . . . . . . . . . . . 22
     17.3. End-to-end Security  . . . . . . . . . . . . . . . . . . . 22
     17.4. Attacks In Scope . . . . . . . . . . . . . . . . . . . . . 22
       17.4.1.  Denial of Service . . . . . . . . . . . . . . . . . . 22
       17.4.2.  Frame Modification  . . . . . . . . . . . . . . . . . 23
         17.4.2.1.  Return Flag Tampering . . . . . . . . . . . . . . 23
         17.4.2.2.  Duplicate Flag Tampering  . . . . . . . . . . . . 23
       17.4.3.  Frame Insertion . . . . . . . . . . . . . . . . . . . 24
       17.4.4.  Frame Replay  . . . . . . . . . . . . . . . . . . . . 24
       17.4.5.  Frame Deletion  . . . . . . . . . . . . . . . . . . . 24
       17.4.6.  Eavesdropping . . . . . . . . . . . . . . . . . . . . 25
       17.4.7.  Route Poisoning . . . . . . . . . . . . . . . . . . . 25
       17.4.8.  Man-in-the-Middle Attacks . . . . . . . . . . . . . . 25
   18. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
   19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
   20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
     20.1. Normative References . . . . . . . . . . . . . . . . . . . 26
     20.2. Informative References . . . . . . . . . . . . . . . . . . 26
   Appendix A.  Examples  . . . . . . . . . . . . . . . . . . . . . . 27
     A.1.  Example 1: Normal Delivery . . . . . . . . . . . . . . . . 27
     A.2.  Example 2: Forwarding with Link Failure  . . . . . . . . . 27
     A.3.  Example 3: Forwarding with Missed Link Layer
           Acknowledgment . . . . . . . . . . . . . . . . . . . . . . 28
     A.4.  Example 4: Forwarding with a Loop  . . . . . . . . . . . . 29
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30

Herberg, et al.         Expires September 3, 2012               [Page 3]
Internet-Draft                     DFF                        March 2012

1.  Introduction

   This document describes the Depth-First Forwarding (DFF) protocol for
   IPv6 networks based on the LoWPAN adaptation layer, as specified in
   [RFC4944].  The protocol is a mesh-under data forwarding mechanism
   that increases reliability of data delivery in networks with dynamic
   topologies.

   DFF forwards data frames using a network-wide "depth-first search"
   for the Final Destination of the frame.  DFF relies on a neighborhood
   discovery mechanism which lists neighbors of a node for the next hop
   of a data frame.  In addition, DFF may be used in conjunction with a
   mesh-under routing protocol, which provides "hints" for DFF in which
   order to try to send the frame to the neighbors discovered by the
   neighborhood discovery mechanism.

   If the frame makes no forward progress using the selected next hop,
   DFF will successively try all neighbors of the node (as determined by
   an additional mechanism, e.g. a mesh-under routing protocol, ND,
   HELLO message exchange).  If none of the next hops successfully
   receives the frame, DFF returns the frame to the previous hop, which
   in turn tries to send it to alternate neighbors.

   As network topologies do not necessarily form a tree, loops can
   occur.  Therefore, DFF contains a loop detection and avoidance
   mechanism.

   If DFF is used in conjunction with a mesh-under routing protocol, the
   cost of routes provided by that routing protocol may be updated while
   rerouting the frame through alternative next hops.  Thus, DFF
   provides an optional local route repair mechanism.

1.1.  Motivation

   In networks with dynamic topologies, even frequent exchanges of
   control messages between nodes for updating the routing tables cannot
   guarantee freshness of routes: frames may not be delivered to their
   Final Destination because the topology has changed since the last
   routing protocol update.

   While more frequent routing protocol updates could mitigate that
   problem to a certain extent, that requires network bandwidth (e.g.
   when flooding control messages through the network for route
   discovery).  This is an issue in networks with lossy links, where
   further control traffic exchange can worsen the network stability
   because of collisions (e.g. in the case of a network-wide flood of
   Route Request messages or Link State Advertisements).  Moreover,
   additional control traffic exchange drains energy from battery-driven

Herberg, et al.         Expires September 3, 2012               [Page 4]
Internet-Draft                     DFF                        March 2012

   nodes.

   The data-forwarding mechanism specified in this document allows for
   forwarding data frames along alternate paths for increasing
   reliability of data delivery, using a depth-first search.  The
   objective is to decrease the necessary control traffic overhead in
   the network, and in the same time to increase delivery success rates.
   If a mesh-under routing protocol is used in conjunction with DFF,
   that protocol can be informed about the updated topology, and routes
   can then be repaired.

1.2.  Protocol Dependencies

   DFF can be used as stand-alone forwarding mechanism, but may be used
   in conjunction with a mesh-under routing protocol which allows for
   providing an order of preference to which next hops a frame should be
   forwarded (e.g. the frame may be forwarded first to neighbors that
   are listed as next hops to the Final Destination, preferring those
   with the lowest route cost).

   DFF requires a list of bidirectional neighbors for each node, which
   must be provided by an external mechanism.  This specification
   assumes there is such a neighborhood discovery protocol in place and
   outlines the requirements for that protocol, as well as the
   interaction between DFF and a mesh-under routing protocol if such is
   used in conjunction with DFF.

2.  Notation and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119].

   Additionally, this document uses the notation in Section 2.1 and the
   terminology in Section 2.2.

2.1.  Notation

   The following notations are used in this document:

   List  - A list of elements is defined as [] for an empty list,
      [element] for a list with one element, and [element1, element2,
      ...] for a list with multiple elements.

Herberg, et al.         Expires September 3, 2012               [Page 5]
Internet-Draft                     DFF                        March 2012

   Concatenation of lists:  If L1 and L2 are lists, then L1@L2 is a new
      list with all elements of L2 concatenated to L1.

2.2.  Terminology

   All terms introduced in [RFC4944] are to be interpreted as described
   therein, in particular Originator Address, Final Destination Address,
   Source Address, and Destination Address.

   Additionally, this document uses the following terminology:

   Address  - An address is either a 16-bit short or a EUI-64 link layer
      address, as specified in [RFC4944].

   Packet  - An IPv6 packet.

   Frame  - A MAC layer data frame, using the LoWPAN adaption layer, as
      specified in [RFC4944].

3.  Applicability Statement

   This protocol:

   o  Is applicable for use in LoWPAN based networks, using the frame
      format for transmission of IPv6 packets defined in [RFC4944].  The
      LoWPAN adaption layer can be run on several MAC layer types, such
      as IEEE 802.15.4 [ieee802.15.4].

   o  Assumes addresses used in the network are either 16-bit short or
      EUI-64 link layer address, as specified in [RFC4944].

   o  Assumes that the underlying MAC layer provides means to detect if
      a frame has been successfully delivered to the next hop or not
      (e.g. by ACK messages).

   o  Operates as "mesh-under" forwarding protocol, i.e. on the link
      layer.  While the proposed mechanism could also be used as "route-
      over", this is not specified in this document and thus out of
      scope.

   o  Is designed to work in networks with lossy links or with a dynamic
      topology.

   o  Relies on an external neighborhood discovery mechanism, which must
      provide a list of bidirectional neighbors of a node.  In addition,
      DFF may use information from a mesh-under routing protocol used in
      conjunction with DFF.  Such a protocol provides "hints" to DFF in

Herberg, et al.         Expires September 3, 2012               [Page 6]
Internet-Draft                     DFF                        March 2012

      which order the neighbors should be successively tried as next hop
      for a frame.

   o  Increases reliability of data delivery by trying alternative
      paths, using a "depth-first forwarding" approach.

   o  Provides a loop detection mechanism, and an optional local route
      repair mechanism if a mesh-under routing protocol is used in
      conjunction with DFF.

   o  Is designed to work in a completely distributed manner, and does
      not depend on any central entity.

4.  Protocol Overview and Functioning

   DFF is a mesh-under data forwarding mechanism responsible for finding
   a path to a Final Destination of a frame, using a "depth-first
   search" in the network.  DFF operates on LoWPAN based networks (using
   the frame format and the transmission of IPv6 packets defined in
   [RFC4944]).

   DFF requires an external mechanism to discover the bidirectional
   neighborhood of a node.  The specification of such a mechanism is out
   of scope of this document.  The list of neighbors is required because
   DFF successively tries to forward a frame to all neighbors of a node
   during the depth-first search, and eventually returns it to the
   previous hop if the frame was not successfully received by any of the
   neighbors.

   In addition to the mandatory neighborhood information, DFF may use
   information from a mesh-under routing protocol that runs in
   conjunction with DFF.  Such a protocol can increase the efficiency of
   the depth-first search, as it allows for providing an order of
   preference which next hops to try first (e.g. by preferring neighbors
   that are listed in the mesh-under routing protocol as next hops along
   the path to the Final Destination, and by preferring next hops with a
   lower route cost).  If the topology as reflected by that mesh-under
   routing protocol represents the effective topology of the network,
   then DFF will forward the data frame along the path provided by the
   protocol.  However, if the topology has changed and the routing
   protocol has not yet converged, then DFF will try alternate paths.
   Compared to the typical forwarding mechanism in LoWPAN networks, a
   mesh-under routing protocol thus only serves DFF to give
   recommendations (or "hints") where to forward a frame.  That also
   implies that if the mesh-under routing protocol does not provide a
   route to a Final Destination, the data frame would not be dropped but
   forwarded by DFF, trying to find a path to that Final Destination.

Herberg, et al.         Expires September 3, 2012               [Page 7]
Internet-Draft                     DFF                        March 2012

   In order to avoid loops when forwarding a data frame towards its
   Final Destination, DFF stores a frame identifier (i.e. a sequence
   number) to detect loops.  DFF lists for each recently forwarded frame
   which neighbors that frame has already been sent to, allowing for
   trying to forward the frame to all candidates for the next hop.

   DFF requires additional header information for each data frame,
   provided by a LoWPAN header specified in this document.  This DFF
   header contains a sequence number used for identifying a frame
   uniquely, and two flags: RET and DUP.  If none of the transmissions
   of a data frame to the neighbors of a node has succeeded, the frame
   is returned to the previous hop, indicated by setting the return
   (RET) flag.  The previous hop then continues to try other neighbors
   in turn, resulting in a depth-first search in the network.

   Whenever a frame transmission to a neighbor has failed (as determined
   by the underlying MAC layer, e.g., using ACKs), the duplicate (DUP)
   flag is set in the frame header for the following transmissions.  The
   rationale is that the frame may have been successfully received by
   the neighbor and only the ACK has been lost, resulting in duplicates
   of the frame in the network.  The DUP flag tags such a possible
   duplicate.

   Whenever a node receives a frame that it has already forwarded (as
   identified by the sequence number of the frame), and which is not a
   duplicate (i.e.  DUP = 0), it will assume a loop and return the frame
   to the previous hop (with the RET flag set).  Optionally, if a mesh-
   under routing protocol is used in conjunction with DFF, the route
   using the next hop which resulted in the loop may be "poisoned" (i.e.
   the route cost may be increased).

5.  Information Sets

   This section specifies the information sets used by DFF.

5.1.  Neighbor List

   DFF requires access to a list of bidirectional neighbors of the node,
   provided by an external neighborhood discovery mechanism, which is
   not specified within this document.

5.2.  Processed Set

   Each node maintains a Processed Set in order to support the loop
   detection functionality.  The Processed Set lists sequence numbers of
   previously received frames, as well as a list of next hops to which
   the frame has been sent successively as part of the depth-first

Herberg, et al.         Expires September 3, 2012               [Page 8]
Internet-Draft                     DFF                        March 2012

   search mechanism.  The set consists of Processed Tuples:

      (P_orig_address, P_seq_number, P_prev_hop,
      P_next_hop_neighbor_list, P_time)

   where

      P_orig_address is is the Originator Address of the received frame;

      P_seq_number is the Sequence Number of the received frame;

      P_prev_hop is the Source Address (i.e. the previous hop) of the
      frame;

      P_next_hop_neighbor_list is a list of addresses of next hops to
      which the frame has been sent previously, as part of the depth-
      first search mechanism, as explained in Section 9.2;

      P_time specifies when this Tuple expires and MUST be removed.

6.  Frame Buffering

   While frames are processed by DFF, they need to be buffered in
   memory.  The design of this buffer remains a choice of the
   implementation, which also depends on the implementation of the
   underlying MAC layer.  This section provides some considerations for
   how to design the frame buffer, and how the DFF implementation
   interacts with the underlying MAC layer.

   If possible, it is recommended to share the memory with the
   underlying MAC layer, i.e. to store a frame in the same memory during
   processing of DFF operation (e.g. successive frame transmissions to
   different neighbors during the "depth-first search"), and during the
   actual transmission by the MAC layer.  Keeping a separated copy of
   the frame in memory under control of DFF would require additional
   memory resources.

   Once the underlying MAC layer has been tasked to transmit a frame, it
   will inform the upper layers (DFF) of success or failure (e.g., using
   a MAC layer acknowledgment and retransmission mechanism).  Depending
   on the implementation of the MAC layer, the frame may be deleted from
   memory in either cases (transmission success or failure).  However,
   in case of a transmission failure, DFF still needs a copy of the
   frame in order to resend to other neighbors.

   Therefore, one of the following two implementation designs is
   recommended (but other implementation designs may be possible):

Herberg, et al.         Expires September 3, 2012               [Page 9]
Internet-Draft                     DFF                        March 2012

   o  If the memory for the frames is shared between DFF and the MAC
      layer, the MAC layer must not delete frames from the buffer on its
      own.  Instead, the MAC layer should mark the frame as ready for
      deletion, so that DFF can decide when to delete the frame from
      memory.

   o  If the memory is not shared, but instead a copy of each frame is
      kept in memory under control of DFF, DFF can decide independently
      when to delete the frame from memory.

   In either of the above cases, DFF must not delete a frame from the
   memory if DFF is informed by the underlying MAC layer that the
   transmission of that frame has failed.  If the transmission has
   succeeded, the frame should be deleted from memory.  In Section 9
   (Frame Generation and Processing), the places where the frame must
   not be deleted from memory is explicitly stated, whereas otherwise
   the implementation may implicitly delete the frame from memory where
   appropriate.

   The size of the buffer should be large enough to contain all frames
   while they are processed by DFF.  The size depends on the available
   memory, the expected rate of incoming frames and their size, as well
   as the reliability of the network; the more the network is
   unreliable, the longer a frame has to be kept in the buffer while the
   frame is successively sent to the neighbors of the node.

   If the buffer is exhausted, no new frames can be accepted for
   processing by DFF until more space is available.  This memory
   exhaustion should be treated by the implementation in the same way as
   the underlying MAC layer treats buffer exhaustion.

7.  Frame Format

   This document assumes that the data forwarding is based on the LoWPAN
   adaptation layer ("mesh-under"), and that data frames conform with
   the format specified in [RFC4944].  In particular, [RFC4944] states
   that

      Additional mesh routing capabilities, such as specifying the mesh
      routing protocol, source routing, and so on may be expressed by
      defining additional routing headers that precede the fragmentation
      or addressing header in the header stack.

   Hence, all data frames to be forwarded using DFF MUST be preceded by
   the Mesh Addressing header defined in [RFC4944], and SHOULD be
   preceded by a header that identifies the DFF data forwarding
   mechanism.

Herberg, et al.         Expires September 3, 2012              [Page 10]
Internet-Draft                     DFF                        March 2012

   After these two headers, any other LoWPAN header, e.g. hop-by-hop
   options, header compression or fragmentation, MAY also be added
   before the actual payload.  Figure 1 depicts the Mesh Addressing
   header defined in [RFC4944], and Figure 2 depicts the DFF header.

                          1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |1 0|V|F|HopsLft| DeepHopsLeft  |orig. address, final address...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 1: Mesh Addressing Header

                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0 1| Mesh Forw |D|R|x|    Sequence Number      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 2: Header for DFF data frames

   Field definitions of the Mesh Addressing header are as specified in
   [RFC4944].

   Field definitions of the DFF header are as follows:

   Mesh Forw  - A 6-bit identifier that allows for the use of different
      mesh forwarding mechanisms.  As specified in [RFC4944], additional
      mesh forwarding mechanisms should use the reserved dispatch byte
      values following LOWPAN_BCO; therefore, 0 1 MUST precede Mesh
      Forw.  The value of Mesh Forw is LOWPAN_DFF.

   Duplicate frame flag (D)  - This flag is included in the DFF mesh
      header to indicate that the frame has been re-sent as a duplicate.
      The flag MUST be set to 1 by the node that re-sends the frame
      after detecting link-layer failure to deliver through the last
      attempted next-hop, as specified in Section 9.2.  Once the flag is
      set to 1, it MUST NOT be modified by nodes forwarding the frame.

   Return frame flag (R)  - This flag is included in the DFF mesh header
      to indicate that the frame has been returned to the previous hop
      after failure to deliver to all the available next-hops.  The flag
      MUST be set to 1 prior to forwarding the frame back to the
      previous hop and MUST be set to 0 prior to forwarding the frame to
      the selected next-hop, as specified in Section 9.2.  This flag is

Herberg, et al.         Expires September 3, 2012              [Page 11]
Internet-Draft                     DFF                        March 2012

      modified in a hop-by-hop basis.

   Reserved flag (x)  - This bit is reserved for future flag
      definitions.

   Sequence Number  - A 13-bit unsigned integer sequence number
      generated by the Originator, unique on a node for each new
      generated frame, as specified in Section 14.  The Originator
      Address concatenated with the Sequence Number represents an
      identifier of previously seen data frames.  Refer to Section 14
      for further information about the sequence numbers, in particular
      considerations for border gateways.

8.  Protocol Parameters and Constants

   The parameters and constants used in this specification are described
   in this section.

   P_HOLD_TIME  - is the time period after which a newly created or
      modified Processed Tuple expires and MUST be deleted.

   MAX_HOPS_LEFT  - is the initial value of Deep Hops Left in the Mesh
      Addressing header specified in [RFC4944].

9.  Data Frame Generation and Processing

   The following sections describe the process of handling a new IPv6
   packet, generated on a node (Section 9.1), as well as forwarding a
   data frame from another node (Section 9.2).  When DFF is used, the
   following specification MUST be used instead of the default frame
   delivery, specified in Section 11 of [RFC4944].

   In the following, it is assumed that all data frames are preceded by
   the Mesh Addressing header and the DFF header, as specified in
   Section 7.  In order to allow for interoperability with nodes not
   using DFF as forwarding mechanism, frames that are preceded by the
   Mesh Addressing header but not the DFF header are treated as
   specified in Section 11 of [RFC4944].

9.1.  Data Frame Generation

   When a new IPv6 packet is to be sent on a node, the datagram is
   encapsulated into LoWPAN frames as specified in [RFC4944] and
   described in Section 7, using the Mesh Addressing header, and in
   addition fragmentation headers (if required) and any other header
   that would be added by [RFC4944].

Herberg, et al.         Expires September 3, 2012              [Page 12]
Internet-Draft                     DFF                        March 2012

   For each of the resulting LoWPAN frames (denoted the "current
   frame"), the following steps MUST be performed before it is
   transmitted:

   1.  The following fields in the Mesh Addressing header to the current
       frame are set:

       *  V and F are set according to the used address length;

       *  Hops Left := 0xF (i.e. reserved value indicating that the Deep
          Hops Left field is following);

       *  Deep Hops Left := MAX_HOPS_LEFT;

       *  Originator Address := address of this node;

       *  Final Destination Address := address of the Final Destination.

   2.  Add the DFF header to the current frame (directly after the Mesh
       Addressing header), as specified in Section 7, with:

       *  Duplicate frame flag (D) := 0;

       *  Return frame flag (R) := 0;

       *  Sequence Number := a new Sequence Number of the frame (as
          defined in Section 14).

   3.  Select the next hop (denoted "next_hop") for the current frame,
       as specified in Section 11.

   4.  Add a Processed Tuple to the Processed Set with:

       *  P_orig_address := the Originator Address of the current frame;

       *  P_seq_number := the Sequence Number of the current frame;

       *  P_prev_hop := the Originator Address of the current frame;

       *  P_next_hop_neighbor_list := [next_hop];

       *  P_time := current time + P_HOLD_TIME.

   5.  Set the Source Address in the frame header to the node's own
       address and the Destination Address to next_hop.

   6.  Hand the current frame over to the underlying MAC layer for
       transmission.  The frame should be stored in memory (as discussed

Herberg, et al.         Expires September 3, 2012              [Page 13]
Internet-Draft                     DFF                        March 2012

       in Section 6), until the lower layer informs DFF of transmission
       success or failure.  If the transmission fails, the frame MUST
       NOT be deleted from the memory and the procedures in Section 10
       SHOULD be executed.

9.2.  Data Frame Processing

   If a frame (denoted the "current frame") is received on the node,
   then the following tasks MUST be performed:

   1.  If the frame is malformed (i.e. the frame format is not as
       expected by this specification or the checksum does not match the
       frame), drop the frame.

   2.  Otherwise, if the Final Destination Address from the Mesh
       Addressing header matches the address of this node, consume the
       frame as per normal delivery (i.e. (i) in case of a fragmented
       IPv6 packet, reassemble fragments as defined in Section 5 of
       [RFC4944], and (ii) send the payload (i.e. the IPv6 packet) to
       upper layers).

   3.  Otherwise, decrement the value of the Deep Hops Left field in the
       Mesh Addressing header.  Drop the frame if Deep Hops Left is
       decremented to zero.

   4.  If no Processed Tuple (denoted the "current tuple") exists in the
       Processed Set, with:

       +  P_orig_address = the Originator Address of the current frame,
          AND;

       +  P_seq_number = the Sequence Number of the current frame.

       Then:

       1.  add a Processed Tuple (denoted the "current tuple") with:

           +  P_orig_address := the Originator Address of the current
              frame;

           +  P_seq_number := the Sequence Number of the current frame;

           +  P_prev_hop := the Source Address (i.e. the previous hop)
              of the current frame;

           +  P_next_hop_neighbor_list := [];

Herberg, et al.         Expires September 3, 2012              [Page 14]
Internet-Draft                     DFF                        March 2012

           +  P_time := current time + P_HOLD_TIME.

       2.  Set RET to 0 in the frame DFF header.

       3.  Select the next hop (denoted "next_hop") for the current
           frame, as specified in Section 11.

       4.  P_next_hop_neighbor_list := P_next_hop_neighbor_list@
           [next_hop].

       5.  Set the Source Address in the frame header to the node's own
           address and the Destination Address field to next_hop.

       6.  Hand the current frame over to the underlying MAC layer for
           transmission.  The frame should be stored in memory (as
           discussed in Section 6), until the lower layer informs DFF of
           transmission success or failure.  If the transmission fails,
           the frame MUST NOT be deleted from the memory and the
           procedures in Section 10 SHOULD be executed.

   5.  Otherwise, if a tuple exists:

       1.  If the return flag of the current frame is not set (RET=0)
           (i.e. a loop has been detected):

           1.  Set RET := 1.

           2.  Set the Source Address in the MAC frame header to the
               node's own address and the Destination Address field to
               the Source Address of the current frame (i.e. the
               previous hop).

           3.  Hand the current frame over to the underlying MAC layer
               for transmission.  The frame should be stored in memory
               (as discussed in Section 6), until the lower layer
               informs DFF of transmission success or failure.  If the
               transmission fails, the frame MUST NOT be deleted from
               the memory.

       2.  Otherwise, if the return flag of the current frame is set
           (RET = 1):

           1.  Set RET := 0.

           2.  Execute the "poisoning" procedure specified in
               Section 12.

Herberg, et al.         Expires September 3, 2012              [Page 15]
Internet-Draft                     DFF                        March 2012

           3.  Select the next hop (denoted "next_hop") for the current
               frame, as specified in Section 11.

           4.  Modify the current tuple:

               -  P_next_hop_neighbor_list := P_next_hop_neighbor_list@
                  [next_hop];

               -  P_time := current time + P_HOLD_TIME.

           5.  If the selected next hop is equal to P_prev_hop of the
               current tuple (i.e. all neighbors have been
               unsuccessfully tried), set the RET flag (RET := 1).  If
               this node has the same address as the Originator Address
               of the current frame, drop the frame.

           6.  Set the Source Address in the frame header to the node's
               own address and the Destination Address field to
               next_hop.

           7.  Hand the current frame over to the underlying MAC layer
               for transmission.  The frame should be stored in memory
               (as discussed in Section 6), until the lower layer
               informs DFF of transmission success or failure.  If the
               transmission fails, the frame MUST NOT be deleted from
               the memory and the procedures in Section 10 SHOULD be
               executed.

9.3.  Border Gateway

   The PAN may be connected to other networks (e.g. the Internet)
   through a border gateway, i.e. a node with at least two interfaces,
   an internal one to the PAN, and an external one towards other
   networks.

   If such a border gateway receives an IPv6 packet on its external
   interface and routes the packet towards the PAN through its internal
   interface, the packet is treated according to Section 9.2, with the
   Originator and Source Address of the frames being set to the address
   of the gateway, and with a Sequence Number created on the border
   gateway.

   If an IPv6 packet is sent from within the PAN to an address outside
   the PAN (e.g. in the Internet), DFF will only be used inside the PAN
   (until the frame(s) that contain the IPv6 datagram have reached their
   Final Destination, i.e. the border gateway).

   It is assumed in this specification that PANs are considered "stub"

Herberg, et al.         Expires September 3, 2012              [Page 16]
Internet-Draft                     DFF                        March 2012

   networks, i.e. that IPv6 packets will not transit the PAN.

10.  Unsuccessful Frame Transmission

   The proposed specification requires to be notified of successful or
   unsuccessful frame transmission by the underlying MAC layer (e.g.
   using link-layer ACKs).  This information is used by DFF to try
   alternate paths if a transmission has failed.  This section first
   gives one example how DFF interacts with the IEEE 802.15.4 MAC layer
   (a link-layer supported by the LoWPAN adaption layer), and then
   specifies actions upon an unsuccessful transmission by the MAC layer.

10.1.  Example: Transmission Failure Detection by IEEE 802.15.4

   IEEE 802.15.4 [ieee802.15.4] is one MAC layer that is supported by
   the LoWPAN adaption layer as specified in [RFC4944].  In IEEE
   802.15.4, each frame is acknowledged with an ACK by the receiver (if
   requested so in the frame).

   If DFF requests the IEEE 802.15.4 layer to transmit a frame, the
   frame is sent by the MAC layer, and a timer is started to wait for an
   ACK from the receiver of the frame.  Specifically, [ieee802.15.4]
   states that:

      "If an acknowledgment is not received within macAckWaitDuration
      symbols [...], the device shall conclude that the single
      transmission attempt has failed. [...]  If a single transmission
      attempt has failed [...], the device shall repeat the process of
      transmitting the data or MAC command frame and waiting for the
      acknowledgment, up to a maximum of aMaxFrameRetries times. [...]
      If an acknowledgment is still not received after aMaxFrameRetries
      retransmissions, the MAC sublayer shall assume the transmission
      has failed and notify the next higher layer of the failure.  This
      situation eventuality is referred to as a communications failure."

   Once the MAC layer informs DFF of such a communications failure, the
   following procedures are executed.

10.2.  Procedures upon a Transmission Failure

   If a frame (the "current frame") has been sent to the next hop, as
   specified in Section 9.1 and Section 9.2, and DFF has been notified
   about the communication failure by the MAC sublayer (as described
   above), then the following steps MUST be performed:

   1.  Set the duplicate flag (DUP) of the DFF header of the current
       frame to 1.

Herberg, et al.         Expires September 3, 2012              [Page 17]
Internet-Draft                     DFF                        March 2012

   2.  Select the next hop (denoted "next_hop") for the current frame,
       as specified in Section 11.

   3.  Find the Processed Tuple (the "current tuple") in the Processed
       Set, with:

       +  P_orig_address = the Originator Address of the current frame,
          AND;

       +  P_seq_number = the Sequence Number of the current frame,

       and modify the current tuple:

       *  P_next_hop_neighbor_list := P_next_hop_neighbor_list@
          [next_hop];

       *  P_time := current time + P_HOLD_TIME.

   4.  If the selected next hop is equal to P_prev_hop of the current
       tuple, set the RET flag (RET := 1), otherwise reset it (RET :=
       0).

   5.  Set the Source Address in the frame header to the node's own
       address and the Destination Address field to next_hop.

   6.  Transmit the current frame.  If the transmission fails
       (determined by missing link layer acknowledgments), the
       procedures in Section 10 SHOULD be executed.

11.  Getting the Next Hop for a Frame

   Before a frame (the "current frame") is sent from a node towards the
   Final Destination, a valid next hop along the path has to be
   selected.  This section describes how to select the next hop (denoted
   "next_hop").  As a Processed Tuple was either existing when receiving
   the frame, or otherwise was created, it can be assumed the a
   Processed Tuple for that frame (the "current tuple") is available.

   The next hop is chosen from a list of neighbors in order of
   decreasing preference of the following conditions.  This list is only
   a suggestion, any other order of priority MAY be used, however,
   P_prev_hop of the current tuple SHOULD be the last entry.  The list
   SHOULD NOT contain addresses which are listed in
   P_next_hop_neighbor_list of the current tuple, and an address SHOULD
   NOT appear more than once in the list.

Herberg, et al.         Expires September 3, 2012              [Page 18]
Internet-Draft                     DFF                        March 2012

   1.  If a mesh-under routing protocol is used in conjunction with DFF,
       then a next hop along the path to the Final Destination Address
       of the frame may be added, where next hops with lower route costs
       have a higher priority.

   2.  All other neighbors from an external neighborhood discovery
       process can be added.

   3.  P_prev_hop of the current tuple SHOULD be added last; this case
       is only used for returning the frame to the previous hop, in
       which case the RET flag MUST be set to 1.

   It is possible to exclude neighbors as candidates for the next_hop
   (e.g. to only select neighbors that are indicated as next hop by a
   mesh-under routing protocol, used in conjunction with DFF).  This may
   limit undesired "full" depth-first searches of Final Destinations,
   but may also hinder successful delivery of a frame.

12.  Poisoning

   When a frame is returned (i.e. a frame with RET = 1 is received by a
   node) or a link layer acknowledgment (ACK) has not been received for
   a forwarded frame, and if a mesh-under routing protocol is used in
   conjunction with DFF, the cost for the route MAY be increased in that
   routing protocol.  Thus, future transmissions prefer other routes.
   For the case of a missing link layer ACK, in addition to increasing
   the route cost, the link cost to the neighbor MAY also be increased
   if such is supported by the neighborhood discovery process.

   It is up to the implementation to decide by how much the route and
   link cost should be increased, and is out of scope of this document.

13.  Route Repair Mechanism

   If DFF is used in conjunction with a mesh-under routing protocol,
   route repair mechanisms of that mesh-under routing protocol MAY be
   disabled in order to avoid unnecessary flooding of the network.  As
   DFF finds alternate paths for the data traffic, and in addition may
   "poison" unused routes of the mesh-under routing protocol, route
   repair mechanisms may be unnecessary and even reduce the stability of
   the network (e.g. because of collisions when Route Requests or Link
   State Advertisements are flooded in the network).

Herberg, et al.         Expires September 3, 2012              [Page 19]
Internet-Draft                     DFF                        March 2012

14.  Sequence Numbers

   Whenever a node generates a frame (the "Originator"), a sequence
   number is required in the DFF header.  This sequence number needs to
   be unique only locally on each node.  For example, a sequence number
   may start at 0 for the first generated frame, and then increase in
   steps of 1 for each new frame.  The sequence number MUST not be
   greater than 8191 and SHOULD wrap around to 0.

   Note that the "Originator", generating the locally unique sequence
   number, designates the node that adds the LoWPAN frame to the IPv6
   packet (after possible link-layer fragmentation), which is not
   necessarily the source of the IPv6 packet.  For example, an IPv6
   packet may be received on a border gateway from outside the PAN (e.g.
   from the Internet), potentially fragmented, and then each frame is
   encapsulated with the LoWPAN header.  The sequence number is then
   locally generated on the border gateway, in the same way that they
   are for IP packets originating from the border gateway.

15.  Proposed Values for Parameters and Constants

   This section lists the parameters and constants used in the
   specification of the protocol, and proposed values of each that MAY
   be used.

   o  P_HOLD_TIME := 5 seconds

   o  MAX_HOPS_LEFT := 255

16.  Deployment Experience

   DFF has been deployed and experimented with both in real deployments
   and in network simulations, as described in the following.

16.1.  Deployments in Japan

   The majority of the large Advanced Metering Infrastructure (AMI)
   deployments using DFF are located in Japan, but the data of these
   networks is property of Japanese utilities and cannot be disclosed.

16.2.  Kit Carson Electric Cooperative

   DFF has been deployed at Kit Carson Electric Cooperative (KCEC), a
   non-profit organization distributing electricity to about 30,000
   customers in New Mexico.  As described in a press release
   [KCEC_press_release], DFF is running on currently about 400 electric

Herberg, et al.         Expires September 3, 2012              [Page 20]
Internet-Draft                     DFF                        March 2012

   meters, and will be further extended to 2,100 meters in summer 2012.
   All meters are connected through a mesh network using an unreliable,
   wireless medium.  DFF is used in conjunction with a distance vector
   mesh-under routing protocol.  Metering data from each meter is sent
   towards a gateway periodically every 15 minutes.  The data delivery
   reliability is over 99%.

16.3.  Simulations

   DFF has been evaluated in OMNEST simulations, in conjunction with a
   distance vector mesh-under routing protocol.  The performance of DFF
   has been compared to using only the routing protocol without DFF.
   The results published in peer-reviewed academic papers
   ([DFF_paper1][DFF_paper2]) show significant improvements of the
   packet delivery ratio compared to using only the distance vector
   protocol.

16.4.  Open Source Implementation

   Fujitsu Laboratories of America is currently working on an open
   source implementation of DFF, which is to be released in summer 2012,
   and which allows for interoperability testings of different DFF
   implementations.  The implementation is based on Java, and can be
   used both on real machines and in the Ns2 simulator.

17.  Security Considerations

   Based on the recommendations in [RFC3552], this section describes
   security threats to DFF, lists which attacks are out of scope, which
   attacks DFF is susceptible to, and which attacks DFF protects
   against.

17.1.  Attacks Out of Scope

   As DFF is designed as mesh-under data forwarding protocol on Layer 2,
   any security issues concerning the payload of the frames (i.e. layers
   3 and above) are not considered in this section.

   It is recommended to use appropriate security mechanisms, such as
   IPsec / TLS / etc., to protect the upper layers.  As DFF does not
   modify the contents of IP datagrams, nor the way IP packets are
   exchanged between endpoints, no special considerations for IPsec have
   to be addressed.

Herberg, et al.         Expires September 3, 2012              [Page 21]
Internet-Draft                     DFF                        March 2012

17.2.  Protecion Mechanisms of DFF

   DFF itself does not provide any additional integrity, confidentiality
   or authentication features compared to the underlying MAC layer
   security.  Therefore, the level of protection of DFF depends on that
   MAC layer security (as well as protection of the payload by upper
   layer security).  Many MAC layers, such as IEEE 802.15.4
   [ieee802.15.4], provide link-layer (i.e. hop-by-hop) security.

   In the following sections, whenever encrypting or digitally signing
   frames is suggested for protecting DFF, it is assumed that nodes are
   not compromised (i.e. do not possess the credentials).

17.3.  End-to-end Security

   While [RFC4944] defines end-to-end LoWPAN headers (e.g. the Mesh
   Addressing header) to be used in mesh forwarding (as specified in
   Section 11 of [RFC4944]), there is currently no specification of
   securing these headers other than by the underlying MAC layer
   security, which is hop-by-hop only.

   Therefore, until a mechanism is specified for signing or encrypting
   LoWPAN end-to-end headers, neither the DFF header nor the Mesh
   Addressing header used by this specification can be secured other
   than on a hop-by-hop basis by the MAC layer.  As such a security
   mechanism would not be limited to DFF headers, but to all LoWPAN
   headers, it is out of scope to define security in this specification.

17.4.  Attacks In Scope

   This section discusses security threats to DFF, and for each
   describes whether (and how) DFF is affected by the threat.  DFF is
   designed to be used in lossy and unreliable networks.  Predominant
   examples of lossy networks are wireless networks, where nodes send
   frames via broadcast.  The attacks listed below are easier to exploit
   in wireless media, but can also be observed in wired networks.

17.4.1.  Denial of Service

   Denial of Service attacks are possible when using DFF by either
   exceeding the storage on a node, or by exceeding the available
   bandwidth of the channel.  As DFF does not contain any algorithms
   with high complexity, it is unlikely that the processing power of the
   node could be exhausted by an attack on DFF.

   The storage of a node can be exhausted by increasing the size of the
   Processed Set, i.e. by adding new entries, or by increasing the size
   of each entry.  New entries can be added by injecting new frames in

Herberg, et al.         Expires September 3, 2012              [Page 22]
Internet-Draft                     DFF                        March 2012

   the network, by replaying frames or by modifying frames (as described
   in Section 17.4.3, Section 17.4.4, and Section 17.4.2 respectively).

   Moreover, a malicious node can effectively increase the size of each
   entry if it has access to a mesh-under routing protocol, used in
   conjunction with DFF.  It can advertise a large number of (non-
   existing) neighbors to a node by spoofing addresses and sending
   control messages.  When forwarding a frame, a node would not only try
   to (unsuccessfully) forward the frame to all these neighbors, leading
   to reduced bandwidth and higher energy drain, but would also increase
   the size of the list of already tried neighbors in the Processed
   Tuple.

   Another possible attack is to send frames to a non-existing address
   in the network.  DFF would perform a full network-wide depth-first
   search, with the worst possible path length.

   If security provided by the MAC layer is used (or LoWPAN end-to-end
   security), this attack can be mitigated if the malicious node does
   not possess valid credentials, since other nodes would not forward
   data through the malicious node.  Moreover, any mesh-under routing
   protocol used in conjunction with DFF must also be protected using
   encryption or digital signatures.

17.4.2.  Frame Modification

   The Mesh Addressing header, the DFF header and the payload may be
   modified by a malicious node, but only modifications to the DFF
   header are in scope of this document.

17.4.2.1.  Return Flag Tampering

   A malicious node may tamper the "return" flag of a DFF frame, and
   send it back to the previous hop.  This node would then try
   alternative neighbors, possibly leading to packets never reaching
   their Final Destination, as well as unnecessary depth-first search in
   the network (bandwidth exhaustion / energy drain).

   This attack can be mitigated by using appropriate security of the
   underlying MAC layer.  As the return flag is set hop-by-hop, an end-
   to-end LoWPAN security layer would not help mitigating this attack.

17.4.2.2.  Duplicate Flag Tampering

   A malicious node may modify the Duplicate Flag of a frame that it
   forwards.

   If it sets the flag from 0 to 1, the frame would be detected as

Herberg, et al.         Expires September 3, 2012              [Page 23]
Internet-Draft                     DFF                        March 2012

   duplicate by other nodes in the network, effectively disabling the
   loop protection for that frame.  Otherwise, the attack has no effect.

   If the Duplicate Flag is set from 1 to 0, and a node receives that
   frame for the second time (i.e. it has already received a frame with
   the same Originator Address and Sequence Number before), it will
   wrongly detect a loop, possibly poison routing entries and return the
   frame back to the previous hop.  This may disrupt end-to-end
   communication and alter the routing tables.

   This attack can be mitigated by using appropriate security of the
   underlying MAC layer.  As the duplicate flag is set hop-by-hop, an
   end-to-end LoWPAN security layer would not help mitigating this
   attack.

17.4.3.  Frame Insertion

   A malicious node may inject new frames in the network.  Other nodes
   will then use resources for storing the sequence numbers for each
   frame in the Processed Set, which may lead to a denial of service
   attack (refer to Section 17.4.1).

   If security provided by MAC layer is used (or LoWPAN end-to-end
   security), this attack can be mitigated if the malicious node does
   not possess valid credentials.

17.4.4.  Frame Replay

   Any node can eavesdrop on frames and replay them at a later time or
   another place without modifying the content.  Even if a node does not
   have the credentials to decrypt an encrypted frame, it can thus harm
   the network integrity, as well as exhaust in-node resources (by
   adding a Processed Tuple for each replayed frame).  Moreover, a node
   receiving a replayed frame would treat it like a looped packet, and
   potentially poison links and routes to the destination.

   Compared to simply creating a new frame, replaying a frame may be
   more difficult to detect as attack (since the Originator Address will
   not be that of the malicious node), and more difficult to protect
   against: encryption alone is not sufficient, unless some freshness
   information is contained in the frame.

17.4.5.  Frame Deletion

   If a node eavesdrop frames (as described in Section 17.4.6), it may
   also decide to not forward them, even though the DFF specification
   would dictate so.  In that case, the malicious node would disturb the
   network communication between end points.

Herberg, et al.         Expires September 3, 2012              [Page 24]
Internet-Draft                     DFF                        March 2012

   If security provided by MAC layer is used (or LoWPAN end-to-end
   security), this attack can be mitigated if the malicious node does
   not possess valid credentials, since other nodes would not forward
   data through the malicious node.

17.4.6.  Eavesdropping

   Any node within radio range can eavesdrop frames that are exchanged
   using the mechanism specified in this document.  If frames are not
   encrypted using MAC layer security, any eavesdropper may read the
   content of the DFF headers, the Mesh Addressing header and the
   payload (which in turn may be encrypted, e.g., using IPsec).  Based
   on the information in the DFF header, the attacker can learn the
   sequence number, whether the frame is a duplicate and whether it is a
   returned frame.  The attacker can, of course, also eavesdrop on the
   payload (IPv6 header and payload) and the Mesh Addressing header,
   which is out of scope for this document.

   If the payload of the frame is encrypted, however, DFF (as well as
   other LoWPAN headers and the IP payload) are protected against
   eavesdropping if nodes are not compromised (and acquire the
   credentials).

17.4.7.  Route Poisoning

   While DFF allows to "poison" routes (Section 12) of a mesh-under
   routing protocol, used in conjunction with DFF, poisoning is only
   performed locally on a node.  A malicious node could only poison its
   own routing table, which has similar effects to frame deletion
   described in Section 17.4.5.

   However, it is recommended to protect control messages of mesh-under
   routing protocols, used in conjunction with DFF, in order to mitigate
   attacks on other nodes routing tables.

17.4.8.  Man-in-the-Middle Attacks

   Man-in-the-middle attacks may affect the upper layers (i.e. the
   payload in frames), and are out of scope of this document.

18.  IANA Considerations

   IANA is requested to allocate a value from the Dispatch Type Field
   registry for LOWPAN_DFF.

Herberg, et al.         Expires September 3, 2012              [Page 25]
Internet-Draft                     DFF                        March 2012

19.  Acknowledgements

   Jari Arkko (Ericsson), Thomas Clausen (Ecole Polytechnique), Yuichi
   Igarashi (Hitachi), Kazuya Monden (Hitachi), Geoff Mulligan (IPSO),
   Hiroki Satoh (Hitachi), Ganesh Venkatesh (Mobelitix), and Jiazi Yi
   (Ecole Polytechnique) provided useful reviews of the draft and
   discussions which helped to improve this document.

20.  References

20.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007.

   [ieee802.15.4]
              Computer Society, IEEE., "IEEE Std. 802.15.4-2003",
              October 2003.

20.2.  Informative References

   [DFF_paper1]
              Cespedes, S., Cardenas, A., and T. Iwao, "Comparison of
              Data Forwarding Mechanisms for AMI Networks",  2012 IEEE
              Innovative Smart Grid Technologies Conference (ISGT),
              January 2012.

   [DFF_paper2]
              Iwao, T., Iwao, T., Yura, M., Nakaya, Y., Cardenas, A.,
              Lee, S., and R. Masuoka, "Dynamic Data Forwarding in
              Wireless Mesh Networks",  First IEEE International
              Conference on Smart Grid Communications (SmartGridComm),
              October 2010.

   [KCEC_press_release]
              Kit Carson Electric Cooperative (KCEC), "DFF deployed by
              KCEC (Press Release)",  http://www.kitcarson.com/
              index.php?option=com_content&view=article&id=45&Itemid=1,
              2011.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.

Herberg, et al.         Expires September 3, 2012              [Page 26]
Internet-Draft                     DFF                        March 2012

Appendix A.  Examples

   In this section, some example network topologies are depicted, using
   the DFF mechanism for data forwarding.  In these examples, it is
   assumed that DFF is used in conjunction with a mesh-under routing
   protocol.  This protocol provides a list of neighbors of each node,
   and a routing table with one or more next hops if the topology
   provides a path from the node to the Final Destination.

A.1.  Example 1: Normal Delivery

   Figure 3 depicts a network topology with seven nodes A to G, with
   links between them as indicated by lines.  It is assumed that node A
   sends a frame to G, through B and D, according to the mesh-under
   routing protocol.

                                        +---+
                                    +---+ D +-----+
                                    |   +---+     |
                            +---+   |             |
                        +---+ B +---+             |
                        |   +---+   |             |
                      +-+-+         |   +---+   +-+-+
                      | A |         +---+ E +---+ G +
                      +-+-+             +---+   +-+-+
                        |   +---+                 |
                        +---+ C +---+             |
                            +---+   |             |
                                    |   +---+     |
                                    +---+ F +-----+
                                        +---+

                   Figure 3: Example 1: normal delivery

   If no link fails in this topology, and no loop occurs, then DFF will
   not modify the usual data forwarding mechanism.  Each node adds a
   Processed Tuple for the incoming frame, and selects the next hop
   according to Section 11, i.e. it will first select the next hop for
   node G as determined by the mesh-under routing protocol.

A.2.  Example 2: Forwarding with Link Failure

   Figure 4 depicts the same topology as the Example 1, but both links
   between B and D and between B and E are unavailable (e.g. because of
   wireless link characteristics).

Herberg, et al.         Expires September 3, 2012              [Page 27]
Internet-Draft                     DFF                        March 2012

                                        +---+
                                    XXX-+ D +-----+
                                    X   +---+     |
                            +---+   X             |
                        +---+ B +---+             |
                        |   +---+   X             |
                      +-+-+         X   +---+   +-+-+
                      | A |         XXXX+ E +---+ G +
                      +-+-+             +---+   +-+-+
                        |   +---+                 |
                        +---+ C +---+             |
                            +---+   |             |
                                    |   +---+     |
                                    +---+ F +-----+
                                        +---+

                     Figure 4: Example 2: link failure

   When B receives the frame from node A, it adds a Processed Tuple, and
   then tries to forward the frame to D. Once B detects that the frame
   cannot be successfully delivered to D because it does not receive
   link layer ACKs, it will follow the procedures listed in Section 10,
   by setting the DUP flag to 1, selecting E as new next hop, adding E
   to the list of next hops in the Processed Tuple, and then forwarding
   the frame to E.

   As the link to E also fails, B will again follow the procedure in
   Section 10.  As all possible next hops (D and E) are listed in the
   Processed Tuple, B will set the RET flag in the frame and return it
   to A.

   A determines that it already has a Processed Tuple for the returned
   frame, reset the RET flag of the frame and select a new next hop for
   the frame.  As B is already in the list of next hops in the Processed
   Tuple, it will select C as next hop and forward the frame to it.  C
   will then forward the frame to F, and F delivers the frame to its
   Final Destination G.

A.3.  Example 3: Forwarding with Missed Link Layer Acknowledgment

   Figure 5 depicts the same topology as the Example 1, but the link
   layer acknowledgments from C to A are lost (e.g. because the link is
   uni-directional).  It is assumed that A prefers a path to G through C
   and F.

Herberg, et al.         Expires September 3, 2012              [Page 28]
Internet-Draft                     DFF                        March 2012

                                        +---+
                                    +---+ D +-----+
                                    |   +---+     |
                            +---+   |             |
                        +---+ B +---+             |
                        |   +---+   |             |
                      +-+-+         |   +---+   +-+-+
                      | A |         +---+ E +---+ G +
                      +-+-+             +---+   +-+-+
                        .   +---+                 |
                        +...+ C +---+             |
                            +---+   |             |
                                    |   +---+     |
                                    +---+ F +-----+
                                        +---+

           Figure 5: Example 3: missed link layer acknowledgment

   While C successfully receives the frame from A, A does not receive
   the ACK and assumes the frame has not been delivered to C. Therefore,
   it sets the DUP flag of the frame to 1, in order to indicate that
   this frame is a duplicate.  Then, it forwards the frame to B.

A.4.  Example 4: Forwarding with a Loop

   Figure 6 depicts the same topology as the Example 1, but there is a
   loop from D to A, and A sends the frame through B and D.

                        +-----------------+
                        |                 |
                        |               +-+-+
                        |           +---+ D +
                        |           |   +---+
                       \|/  +---+   |
                        +---+ B +---+
                        |   +---+   |
                      +-+-+         |   +---+   +-+-+
                      | A |         +---+ E +---+ G +
                      +-+-+             +---+   +-+-+
                        |   +---+                 |
                        +---+ C +---+             |
                            +---+   |             |
                                    |   +---+     |
                                    +---+ F +-----+
                                        +---+

                         Figure 6: Example 4: loop

Herberg, et al.         Expires September 3, 2012              [Page 29]
Internet-Draft                     DFF                        March 2012

   When A receives the frame through the loop from D, it will find a
   Processed Tuple for the frame.  Node A will set the RET flag and
   return the frame to D, which in turn will return it to B. B will then
   select E as next hop, which will then forward it to G.

Authors' Addresses

   Ulrich Herberg
   Fujitsu
   1240 E. Arques Avenue, M/S 345
   Sunnyvale, CA  94085
   US

   Phone: +1 408 530-4528
   Email: ulrich.herberg@us.fujitsu.com

   Alvaro A. Cardenas
   Fujitsu
   1240 E. Arques Avenue, M/S 345
   Sunnyvale, CA  94085
   US

   Phone: +1 408 530-4516
   Email: alvaro.cardenas-mora@us.fujitsu.com

   Tadashige Iwao
   Fujitsu
   Shiodome City Center, 5-2, Higashi-shimbashi 1-chome, Minato-ku
   Tokyo,
   JP

   Phone: +81-44-754-3343
   Email: smartnetpro-iwao_std@ml.css.fujitsu.com

   Michael L. Dow
   Freescale
   6501 William Cannon Drive West
   Austin, TX  78735
   USA

   Phone: +1 512 895 4944
   Email: m.dow@freescale.com

Herberg, et al.         Expires September 3, 2012              [Page 30]
Internet-Draft                     DFF                        March 2012

   Sandra L. Cespedes
   U. Icesi/U. of Waterloo
   Calle 18 No. 122-135 Pance
   Cali, Valle
   Colombia

   Phone:
   Email: slcesped@bbcr.uwaterloo.ca

Herberg, et al.         Expires September 3, 2012              [Page 31]