One document matched: draft-cardenas-dff-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="exp" docName="draft-cardenas-dff-06" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, routerrivativesTrust200902,
or pre5378Trust200902
you can add the attributes ups="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="DFF">Depth-First Forwarding in Unreliable Networks (DFF)</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Ulrich Herberg" initials="U.H." surname="Herberg" role="editor">
<organization>Fujitsu</organization>
<address>
<postal>
<street>1240 E. Arques Avenue, M/S 345</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94085</code>
<country>US</country>
</postal>
<phone>+1 408 530-4528</phone>
<email>ulrich.herberg@us.fujitsu.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Alvaro A. Cardenas" initials="A.C." surname="Cardenas">
<organization>Fujitsu</organization>
<address>
<postal>
<street>1240 E. Arques Avenue, M/S 345</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94085</code>
<country>US</country>
</postal>
<phone>+1 408 530-4516</phone>
<email>alvaro.cardenas-mora@us.fujitsu.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Tadashige Iwao" initials="T.I." surname="Iwao">
<organization>Fujitsu</organization>
<address>
<postal>
<street>Shiodome City Center, 5-2, Higashi-shimbashi 1-chome, Minato-ku</street>
<city>Tokyo</city>
<region/>
<code/>
<country>JP</country>
</postal>
<phone>+81-44-754-3343</phone>
<email>smartnetpro-iwao_std@ml.css.fujitsu.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Michael L. Dow" initials="M.L." surname="Dow">
<organization>Freescale</organization>
<address>
<postal>
<street>6501 William Cannon Drive West</street>
<city>Austin</city>
<region>TX</region>
<code>78735</code>
<country>USA</country>
</postal>
<phone>+1 512 895 4944</phone>
<email>m.dow@freescale.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Sandra L. Cespedes" initials="S.C." surname="Cespedes">
<organization>U. Icesi/U. of Waterloo</organization>
<address>
<postal>
<street>Calle 18 No. 122-135 Pance</street>
<city>Cali</city>
<region>Valle</region>
<code/>
<country>Colombia</country>
</postal>
<phone/>
<email>slcesped@bbcr.uwaterloo.ca</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2012"/>
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>DFF</keyword>
<keyword>Depth first forwarding</keyword>
<keyword>IPv6</keyword>
<keyword>Forwarding plane</keyword>
<keyword>Lossy networks</keyword>
<keyword>Reliability</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
This document specifies the "Depth-First Forwarding" (DFF) protocol for IPv6 networks, a data forwarding mechanism that can increase reliability of data delivery. 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. 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).
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
This document specifies the Depth-First Forwarding (DFF) protocol for IPv6 networks, both for IPv6 forwarding (<xref target="RFC2460"/>, henceforth denoted "route-over"), and also for "mesh-under" forwarding using the LoWPAN adaptation layer (<xref target="RFC4944"/>). The protocol operates entirely on the forwarding plane, but may interact with the routing plane. The purpose of DFF is to increase reliability of data delivery in networks with dynamic topologies and/or lossy links.
</t>
<t>
DFF forwards data packets using a "depth-first search" for the destination of the packets. DFF relies on an external neighborhood discovery mechanism which lists neighbors of a router that may be attempted as next hops for a data packet. In addition, DFF may use information from the Routing Information Base (RIB) for deciding in which order to try to send the packet to the neighboring routers.
</t>
<t>
If the packet makes no forward progress using the first selected next hop, DFF will successively try all neighbors of the router. If none of the next hops successfully receives or forwards the packet, DFF returns the packet to the previous hop, which in turn tries to send it to alternate neighbors.
</t>
<t>
As network topologies do not necessarily form a tree, loops can occur. Therefore, DFF contains a loop detection and avoidance mechanism.
</t>
<t>
DFF may provide information, which may - by a mechanism outside of this specification - be used for updating cost of routes in the RIB based on failed or successful delivery of packets through alternative next hops. Such information may also be used by a routing protocol.
</t>
<section title="Motivation">
<t>
In networks with dynamic topologies and/or lossy links, even frequent exchanges of control messages between routers for updating the routing tables cannot guarantee that the routes correspond to the effective topology of the network at all times. Packets may not be delivered to their destination because the topology has changed since the last routing protocol update.
</t>
<t>
More frequent routing protocol updates can mitigate that problem to a certain extent, however this requires additional signaling, consuming channel and router resources (e.g., when flooding control messages through the network). This is problematic in networks with lossy links, where further control traffic exchange can worsen the network stability because of collisions. Moreover, additional control traffic exchange may drain energy from battery-driven routers.
</t>
<t>
The data-forwarding mechanism specified in this document allows for forwarding data packets 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 at the same time to increase delivery success rates.
</t>
<t>As this specification is intended for experimentation, the mechanism is also specified for forwarding on the LoWPAN adaption layer (according to Section 11 of <xref target="RFC4944"/>), denoted "mesh-under", in addition to IPv6 forwarding as specified in <xref target="RFC2460"/> (denoted "route-over").
Other than different header formats, the DFF mechanism for route-over and mesh-under is similar, and is therefore first defined in general, and then more specifically for both IPv6 route-over forwarding (as specified in <xref target="route_over_MoP"/>), and for LoWPAN adaptation layer mesh-under (as specified in <xref target="mesh_under_MoP"/>).</t>
</section>
<section title="Protocol Dependencies">
<t>
DFF MAY use information from the Routing Information Base (RIB), notably for determining an order of preference for to which next hops a packet should be forwarded (e.g., the packet may be forwarded first to neighbors that are listed in the RIB as next hops to the destination, preferring those with the lowest route cost).
</t>
<t>
DFF MUST have access to a list of bidirectional neighbors for each router, provided by a mechanism such as, e.g., <xref target="RFC6130">NHDP</xref>. That neighborhood discovery protocol is not specified in this document.
</t>
</section>
</section>
<section title="Notation and Terminology">
<t>
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 <xref target="RFC2119"/>.
</t>
<t>
Additionally, this document uses the notation in <xref target="notation"/> and the terminology in <xref target="terminology"/>.
</t>
<section anchor="notation" title="Notation">
<t>The following notations are used in this document:
<list style="hanging">
<t hangText="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.
</t>
<t hangText="Concatenation of lists:">
If L1 and L2 are lists, then L1@L2 is a new list with first all elements of L1, followed by all elements of L2 in that order.
</t>
</list>
</t>
</section>
<section anchor="terminology" title="Terminology">
<t>The following terms are used in this document. As the DFF mechanism is specified both for route-over IPv6 and for mesh-under LoWPAN adaptation layer, the terms are generally defined in this section, and then specifically mapped for each of the different modes of operation in <xref target="MoPs"/>.
<list style="hanging">
<t hangText="Mode of Operation (MoP)">
- The DFF mechanism specified in this document can either be used as "route-over" IPv6 forwarding mechanism (Mode of Operation: "route-over"), or as "mesh-under" LoWPAN adaptation layer (Mode of Operation: "mesh-under").
</t>
<t hangText="Packet">
- An IPv6 Packet (for "route-over" MoP) or a "LoWPAN encapsulated packet" (for "mesh-under" MoP) containing an IPv6 Packet as payload.
</t>
<t hangText="Packet Header">
- An IPv6 extension header (for "route-over" MoP) or a LoWPAN header (for "mesh-under" MoP).
</t>
<t hangText="Address">
- An IPv6 address (for "route-over" MoP), or a 16-bit short or EUI-64 link layer address (for "mesh-under" MoP).
</t>
<t hangText="Originator">
- The router which added the DFF header (specified in <xref target="packet_format"/>) to a Packet.
</t>
<t hangText="Originator Address">
- An Address of the Originator. This Address SHOULD be an Address configured on the interface which transmits the Packet, selected according to <xref target="RFC3484"/>.
</t>
<t hangText="Destination Address">
- An Address to which the Packet is sent.
</t>
<t hangText="Next Hop">
- An Address of the next hop router to which the Packet is sent along the path to the Destination.
</t>
<t hangText="Previous Hop">
- The Address of the previous hop router from which a Packet has been received.
</t>
<t hangText="Hop Limit">
- An upper bound how many times the Packet may be forwarded.
</t>
</list>
</t>
</section>
</section>
<section anchor="applicability" title="Applicability Statement">
<t>
This protocol:
<list style="symbols">
<t>
Is applicable for use in IPv6 networks, either as "route-over" forwarding mechanism using IPv6 (<xref target="RFC2460"/>), or as "mesh-under" forwarding mechanism using the frame format for transmission of IPv6 packets defined in <xref target="RFC4944"/>.
</t>
<t>
Assumes addresses used in the network are either IPv6 addresses (if the protocol is used as "route-over"), or 16-bit short or EUI-64 link layer addresses, as specified in <xref target="RFC4944"/> if the protocol is used as "mesh-under".
</t>
<t>
Assumes that the underlying link layer provides means to detect if a Packet has been successfully delivered to the Next Hop or not (e.g., by L2 ACK messages).
</t>
<t>
Is designed to work in networks with lossy links and/or with a dynamic topology.
</t>
<!-- <t>
Can increase reliability of data delivery by trying alternative paths, using a "depth-first forwarding" approach.
</t>-->
<!-- <t>
Provides a loop detection and avoidance mechanism. Optionally, an external mechanism (which is not specified in this document) may use the information from DFF to update routing metrics in the RIB, and/or inform the routing protocol of the updated topology.
</t> -->
<t>
Is designed to work in a completely distributed manner, and does not depend on any central entity.
</t>
<t>
Is designed for networks with little traffic in terms of numbers of Packets per second (such as common in Low-Power and Lossy Networks (LLNs)), since each recently forwarded Packet increases the state on a router. The routers have to be provisioned with enough memory to maintain the state required for this specification.
</t>
<t>
Is designed for dense topologies with multiple paths between each source and each destination. Certain topologies may be less suitable for DFF (e.g. a network topology that can be partitioned by the removal of a single router or link, or a network topology with multiple stub routers that each have a single link to the network). It is out of scope for this document to provide guidelines as to in which topologies DFF is or is not beneficial. In topologies unsuitable for DFF, the Packet may never reach the Destination, and therefore unnecessary transmissions of data Packets may occur until the Hop Limit of the Packet reaches zero and the Packet is dropped. This may consume channel and router resources.
</t>
<t>
Is used for unicast transmissions only.
</t>
</list>
</t>
</section>
<section anchor="overview" title="Protocol Overview and Functioning">
<t>
When a Packet is to be forwarded by a router using DFF, the router creates a list of candidate Next Hops for that Packet. This list is ordered, containing first Next Hops listed in the RIB, if available, ordered in increasing cost, followed by other neighbors provided of by an external neighborhood discovery. DFF proceeds to forward the Packet to the Next Hop listed first in the list. If the transmission was not successful (as determined by the underlying link layer) or if the Packet was "returned" by a Next Hop to which it had been sent before, the router will try to forward the Packet to the next Next Hop on the list. A router "returns" a Packet to the router from which it was originally received, once it has unsuccessfully tried to forward the Packet to all elements in the candidate Next Hop list. If the Packet is eventually returned to the Originator of the Packet, it is dropped.
</t>
<t>
For each recently forwarded Packet, a router running DFF stores the list of Next Hops to which a Packet has been sent. Packets are identified by a sequence number that is included in the Packet Header. This list of recently forwarded Packets also allows for avoiding loops when forwarding a Packet.
</t>
<section title="Information Base Overview">
<t>
This specification requires a single set on each router, the Processed Set. This set stores the sequence number, the Originator Address, the Previous Hop and a list of Next Hops, to which the Packet has been sent, for each recently seen Packet. Entries in the set are removed after a predefined time-out. Each time a Packet is forwarded to a Next Hop, that Next Hop is added to the list of Next Hops of the entry for the Packet.
</t>
<t>Note that an implementation of this protocol may maintain
the information of the Processed Set in the indicated form, or in any other organization which offers access to this information. In particular, it
is not necessary to remove Tuples from a Set at the exact time indicated, only to behave as if the Tuples were removed at that time.</t>
</section>
<section title="Signaling Overview">
<t>
DFF requires additional header information in each data Packet by a router using this specification. This information is stored in a Packet Header that is specified in this document as LoWPAN header and as IPv6 Hop-by-Hop Options extension header respectively, for the intended "route-over" and "mesh-under" Modes of Operations. This DFF header contains a sequence number used for uniquely identifying a Packet, and two flags: RET (for "return") and DUP (for "duplicated").
</t>
<t>
If none of the transmissions of a data Packet to the neighbors of a router have succeeded, the Packet is returned to the Previous Hop, indicated by setting the return flag (RET := 1). The RET flag is required to discern between a deliberately returned Packet and a looping Packet: if a router receives a Packet with RET = 1 that it had already forwarded, the Packet was deliberately returned, and the router will continue to successively send the Packet to routers from the candidate Next Hop list. If the received Packet has RET = 0, the router assumes that the Packet is looping and returns it to the Previous Hop. An external mechanism may use this information for increasing the route cost of the route using the Next Hop which resulted in the loop the RIB, and/or the routing protocol may be informed.
</t>
<t>
Whenever a Packet transmission to a neighbor has failed (as determined by the underlying link layer, e.g., using L2 ACKs), the duplicate (DUP) flag is set in the Packet Header for the following transmissions. The rationale is that the Packet may have been successfully received by the neighbor and only the L2 ACK has been lost, resulting in possible duplicates of the Packet in the network. The DUP flag tags such a possible duplicate. The DUP flag is required to discern between a duplicated Packet and a looping Packet: if a router receives a Packet with DUP = 1 that it had already forwarded, the Packet is not considered looping, and successively forwarded to routers from the candidate Next Hop list. If the received Packet has DUP = 0, the router assumes that the Packet is looping and returns it to the Previous Hop (with RET flag set). Again, an external mechanism may use this information for increasing route costs and/or informing the routing protocol.
</t>
</section>
</section>
<section title="Information Sets" anchor="information_sets">
<t>
This section specifies the information sets used by DFF.
</t>
<section title="Candidate Neighbor List" anchor="neighbor_list">
<t>
DFF MUST have access to a list of Addresses of bidirectional neighbors of the router, provided by an external neighborhood discovery mechanism, which is not specified within this document.
</t>
</section>
<section title="Processed Set" anchor="processed_set">
<t>
Each router maintains a Processed Set in order to support the loop detection functionality. The Processed Set lists sequence numbers of previously received Packets, as well as a list of Next Hops to which the Packet has been sent successively as part of the depth-first forwarding mechanism. The set consists of Processed Tuples
<list style="hanging">
<t hangText="">
(P_orig_address, P_seq_number, P_prev_hop, P_next_hop_neighbor_list, P_time)
</t>
</list>
where
<list style="hanging">
<t hangText="">
P_orig_address is the Originator Address of the received Packet;
</t>
<t hangText="">
P_seq_number is the sequence number of the received Packet;
</t>
<t hangText="">
P_prev_hop is the Address of the Previous Hop of the Packet;
</t>
<t hangText="">
P_next_hop_neighbor_list is a list of Addresses of Next Hops to which the Packet has been sent previously, as part of the depth-first forwarding mechanism, as specified in <xref target="packet_processing"/>;
</t>
<t hangText="">
P_time specifies when this Tuple expires and MUST be removed.
</t>
</list>
</t>
</section>
</section>
<section anchor="packet_format" title="Packet Header Fields">
<t>This section specifies the information required by DFF in the Packet Header. Note that, depending on whether DFF is used in the "route-over" MoP or in the "mesh-under" MoP, the DFF header is either an IPv6 Hop-by-Hop Options extension header (as specified in <xref target="route_over_MoP_packet_format"/>) or a LoWPAN header (as specified in <xref target="mesh_under_MoP_packet_format"/>). Those sections specify the precise order, format and encoding of the fields that are listed in this section.</t>
<t>
<list style="hanging">
<t hangText="Duplicate Packet Flag (D)">
- This 1-bit flag is included in the DFF header to indicate that the Packet has been re-sent as a duplicate. The flag MUST be set to 1 by the router that re-sends the Packet after detecting link-layer failure to deliver through the last attempted Next Hop, as specified in <xref target="packet_processing"/>. Once the flag is set to 1, it MUST NOT be modified by routers forwarding the Packet.
</t>
<t hangText="Return Packet Flag (R)">
- This 1-bit flag is included in the DFF header to indicate that the Packet 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 sending the Packet back to the Previous Hop and MUST be set to 0 when a router receives a Packet with RET = 1, as specified in <xref target="packet_processing"/>.
</t>
<t hangText="Sequence Number">
- A 14-bit field, containing an unsigned integer sequence number generated by the Originator, unique to each router for each new generated Packet, as specified in <xref target="seqno"/>. The Originator Address concatenated with the sequence number represents an identifier of previously seen data Packets.
Refer to <xref target="seqno"/> for further information about sequence numbers.
</t>
</list>
</t>
</section>
<section anchor="parameters" title="Protocol Parameters">
<t>
The parameters used in this specification are listed in this section.
<list style="hanging">
<t hangText="P_HOLD_TIME">
- is the time period after which a newly created or modified Processed Tuple expires and MUST be deleted. An implementation SHOULD use a value for P_HOLD_TIME that is high enough that the Processed Tuples for a Packet is still in memory on all forwarding routers while the Packet is transiting the routing domain. The value SHOULD at least be MAX_HOP_LIMIT times the expected time to send a Packet to a router on the same link.
</t>
<t hangText="MAX_HOP_LIMIT">
- is the initial value of Hop Limit, and therefore the maximum number of times that a Packet is forwarded in the routing domain. When choosing the value of MAX_HOP_LIMIT, the size of the network, the distance between source and destination in number of hops, and the maximum possible "detour" of a Packet SHOULD be considered (compared to the shortest path). Such information MAY be used from the RIB, if provided.
</t>
</list>
</t>
</section>
<section title="Data Packet Generation and Processing" anchor="generation_processing">
<t>
The following sections specify the process of handling a new Packet, generated on a router (<xref target="packet_generation"/>), as well as forwarding a data Packet from another router (<xref target="packet_processing"/>).
</t>
<section title="Data Packet Generation" anchor="packet_generation">
<t>This section applies for any data Packets upon their first entry into a routing domain, in which DFF is used. This occurs when a new data Packet is generated on this router, or when a data Packet is forwarded from outside the routing domain (i.e., from a host attached to this router or from a router outside the routing domain in which DFF is used). Before such a data Packet (henceforth denoted "current Packet") is transmitted, the following steps MUST be executed:
<list style="numbers">
<t>
If required, encapsulate the Packet as specified in <xref target="scope_limitation"/>.
</t>
<t>
Add the DFF header to the current Packet (to the outer header if the Packet has been encapsulated), with:
<list style="symbols">
<t>
Duplicate Packet Flag (D) := 0;
</t>
<t>
Return Packet Flag (R) := 0;
</t>
<t>
Sequence Number := a new sequence number of the Packet (as specified in <xref target="seqno"/>).
</t>
</list>
</t>
<t>
Select the Next Hop (henceforth denoted "next_hop") for the current Packet, as specified in <xref target="getnexthop"/>.
</t>
<t>
Add a Processed Tuple to the Processed Set with:
<list style="symbols">
<t>
P_orig_address := the Originator Address of the current Packet;
</t>
<t>
P_seq_number := the sequence number of the current Packet;
</t>
<t>
P_prev_hop := the Originator Address of the current Packet;
</t>
<t>
P_next_hop_neighbor_list := [next_hop];
</t>
<t>
P_time := current time + P_HOLD_TIME.
</t>
</list>
</t>
<t>
Pass the current Packet to the underlying link layer for transmission to next_hop. If the transmission fails (as determined by the MAC layer), the procedures in <xref target="missed_ACK"/> MUST be executed.
</t>
</list>
</t>
</section>
<section anchor="packet_processing" title="Data Packet Processing">
<t>
When a Packet (henceforth denoted the "current Packet") is received by a router, then the following tasks MUST be performed:
<list style="numbers">
<t>
If the Packet Header is malformed (i.e., the header format is not as expected by this specification), drop the Packet.
</t>
<t>
Otherwise, if the Destination Address of the Packet matches an Address of an interface of this router, deliver the Packet to upper layers.
</t>
<t>
If no Processed Tuple (henceforth denoted the "current tuple") exists in the Processed Set, with:
<list style="hanging">
<t hangText="+">
P_orig_address = the Originator Address of the current Packet, AND;
</t>
<t hangText="+">
P_seq_number = the sequence number of the current Packet.
</t>
</list>
Then:
<list style="format %d." counter="my_count1">
<t>
Add a Processed Tuple (henceforth denoted the "current tuple") with:
<list style="symbols">
<t>
P_orig_address := the Originator Address of the current Packet;
</t>
<t>
P_seq_number := the sequence number of the current Packet;
</t>
<t>
P_prev_hop := the Previous Hop Address of the current Packet;
</t>
<t>
P_next_hop_neighbor_list := [];
</t>
<t>
P_time := current time + P_HOLD_TIME.
</t>
</list>
</t>
<t>
Decrement the value of the Hop Limit field by one (1). Drop the Packet if Hop Limit is decremented to zero.
</t>
<t>
Set RET to 0 in the DFF header.
</t>
<t>
Select the Next Hop (henceforth denoted "next_hop") for the current Packet, as specified in <xref target="getnexthop"/>.
</t>
<t>
P_next_hop_neighbor_list := P_next_hop_neighbor_list@[next_hop].
</t>
<t>
Pass the current Packet to the underlying link layer for transmission to next_hop. If the transmission fails (as determined by the MAC layer), the procedures in <xref target="missed_ACK"/> MUST be executed.
</t>
</list>
</t>
<t>
Otherwise, if a tuple exists:
<list style="numbers">
<t>
If the return flag of the current Packet is not set (RET = 0) (i.e., a loop has been detected):
<list style="numbers">
<t>
Decrement the value of the Hop Limit field by one (1). Drop the Packet if Hop Limit is decremented to zero.
</t>
<t>
Set RET := 1.
</t>
<t>
Pass the current Packet to the underlying link layer for transmission to the Previous Hop.
</t>
</list>
</t>
<t>
Otherwise, if the return flag of the current Packet is set (RET = 1):
<list style="numbers">
<t>
If the Previous Hop of the Packet is not contained in P_next_hop_neighbor_list of the current tuple, drop the Packet.
</t>
<t>
Decrement the value of the Hop Limit field by one (1). Drop the Packet if Hop Limit is decremented to zero.
</t>
<t>
Set RET := 0.
</t>
<t>
Select the Next Hop (henceforth denoted "next_hop") for the current Packet, as specified in <xref target="getnexthop"/>.
</t>
<t>
Modify the current tuple:
<list style="symbols">
<t>
P_next_hop_neighbor_list := P_next_hop_neighbor_list@[next_hop];
</t>
<t>
P_time := current time + P_HOLD_TIME.
</t>
</list>
</t>
<t>
If the selected Next Hop is equal to P_prev_hop of the current tuple, as specified in <xref target="getnexthop"/>, (i.e., all neighbors have been unsuccessfully tried), set the RET flag (RET := 1). If this router (i.e., the router receiving the current packet) has the same Address as the Originator Address of the current Packet, drop the Packet.
</t>
<t>
Pass the current Packet to the underlying link layer for transmission to next_hop. If transmission fails (as determined by the MAC layer), the procedures in <xref target="missed_ACK"/> MUST be executed.
</t>
</list>
</t>
</list>
</t>
</list>
</t>
</section>
</section>
<section anchor="missed_ACK" title="Unsuccessful Packet Transmission">
<t>
DFF requires that the underlying link layer provides information as to if a Packet is successfully received by the Next Hop. Absence of such a signal is interpreted as delivery failure of the Packet (henceforth denoted the "current Packet"). Whenever <xref target="generation_processing"/> explicitly requests it in case of such a delivery failure, the following steps MUST be executed:
<!--
<section anchor="missed_ACK_802154" title="Example: Transmission Failure Detection by IEEE 802.15.4">
<t>
<xref target="ieee802.15.4">IEEE 802.15.4</xref> is one MAC layer that is supported by the LoWPAN adaption layer as specified in <xref target="RFC4944"/>. In IEEE 802.15.4, each frame is acknowledged with an ACK by the receiver (if requested so in the Packet).
</t>
<t>
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 Packet. Specifically, <xref target="ieee802.15.4"/> states that:
<list style="hanging">
<t>
"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 aMaxPacketRetries times. [...] If an acknowledgment is still not received after aMaxPacketRetries 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."
</t>
</list>
Once the MAC layer informs DFF of such a communication failure, the following procedures are executed.
</t>
</section>
-->
<!--
<section anchor="missed_ACK_procedures" title="Procedures upon a Transmission Failure">
<t>
If a Packet (the "current Packet") has been sent to the Next Hop, as specified in <xref target="packet_generation"/> and <xref target="packet_processing"/>, and DFF has been notified about the communication failure by the MAC layer, then the following steps MUST be performed:-->
<list style="numbers">
<t>
Set the duplicate flag (DUP) of the DFF header of the current Packet to 1.
</t>
<t>
Select the Next Hop (henceforth denoted "next_hop") for the current Packet, as specified in <xref target="getnexthop"/>.
</t>
<t>
Find the Processed Tuple (the "current tuple") in the Processed Set, with:
<list style="hanging">
<t hangText="+">
P_orig_address = the Originator Address of the current Packet, AND;
</t>
<t hangText="+">
P_seq_number = the sequence number of the current Packet,
</t>
</list>
</t>
<t>
If no current tuple is found (e.g., because it has expired), drop the Packet.
</t>
<t>Otherwise, modify the current tuple:
<list style="symbols">
<t>
P_next_hop_neighbor_list := P_next_hop_neighbor_list@[next_hop];
</t>
<t>
P_time := current time + P_HOLD_TIME.
</t>
</list>
</t>
<t>
If the selected next_hop is equal to P_prev_hop of the current tuple, as specified in <xref target="getnexthop"/> (i.e., all neighbors have been unsuccessfully tried):
<list style="symbols">
<t>RET := 1</t>
<t>
Decrement the value of the Hop Limit field by one (1). Drop the Packet if Hop Limit is decremented to zero.
</t>
</list>
</t>
<t>
Otherwise
<list style="symbols">
<t>RET := 0</t>
</list>
</t>
<t>
Transmit the current Packet to next_hop. If transmission fails (determined by the MAC layer), and if the next_hop does not equal P_prev_hop from the current tuple, the procedures in <xref target="missed_ACK"/> MUST be executed.
</t>
</list>
</t>
<!--</section>-->
</section>
<section anchor="getnexthop" title="Determining the Next Hop for a Packet">
<t>
When generating or forwarding a Packet, a router determines a valid Next Hop for that Packet as specified in <xref target="generation_processing"/>. This section specifies how to select the Next Hop (henceforth denoted "next_hop"). As a Processed Tuple was either existing when receiving the Packet (henceforth denoted the "current Packet"), or otherwise was created, it can be assumed the a Processed Tuple for that Packet (henceforth denoted the "current tuple") is available.
</t>
<t>
The Next Hop is chosen from a list of candidate Next Hops in order of decreasing priority. This list is only a suggestion, any other way of constructing the list MAY be used. The list SHOULD NOT contain Addresses which are listed in P_next_hop_neighbor_list of the current tuple, in order to avoid sending the Packet to the same neighbor multiple times. Moreover, an Address SHOULD NOT appear more than once in the list, for the same reason.
<list style="numbers">
<t>
If the RIB of the router contains one or more entries corresponding to the Destination, add the Next Hop(s) from these entries to the list of Next Hops for the Packet, where entries with lower cost have a higher preference.
</t>
<t>
Add a subset or all other neighbors from an external neighborhood discovery process.
</t>
</list>
</t>
<t>
If the candidate Next Hop list so created is empty, the selected Next Hop MUST be P_prev_hop of the current tuple; this case applies when returning the Packet to the Previous Hop.
</t>
</section>
<section anchor="poison" title="Informing the Routing Protocol">
<t>
When a Packet is returned (i.e., a Packet with RET = 1 is received by a router) or a link layer acknowledgment (ACK) has not been received for a forwarded Packet, an external mechanism (not specified in this document) MAY use this information to increase the cost for the route in the RIB, and/or to inform the routing protocol. Care has to be taken by this external mechanism not to create loops. The rationale for such a mechanism is to update routes based on information from DFF, so that future packet transmissions will take better routes.
</t>
</section>
<!--
<section anchor="route_repair" title="Route Repair Mechanism">
<t>
If a routing protocol supports that, route repair mechanisms of that routing protocol MAY be disabled in order to, e.g., avoid unnecessary flooding of the network. As DFF finds alternate paths for the data traffic, and in addition may "poison" unused routes of the 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).
</t>
</section>
-->
<section anchor="seqno" title="Sequence Numbers">
<t>
Whenever a router generates a Packet or forwards a Packet on behalf of a host or a router outside the routing domain where DFF is used, a sequence number MUST be created and included in the DFF header. This sequence number MUST be unique locally on each router where it is created. A sequence number MUST start at 0 for the first generated Packet, and then increase in steps of 1 for each new Packet. The sequence number MUST not be greater than 16383 and MUST wrap around to 0.
</t>
<!--
<t>
Note that the "Originator", generating the locally unique sequence number, designates the router that adds the DFF header to the data Packet, which is not necessarily the source of the Packet. For example, a Packet may be received on a Border router from outside the routing domain using DFF. The sequence number is then locally generated on the Border router and add with the DFF header. TODO
</t> -->
</section>
<section anchor="MoPs" title="Modes of Operation">
<t>
DFF can be used either as "route-over" IPv6 forwarding protocol, or alternatively as "mesh-under" data forwarding protocol for the LoWPAN adaptation layer (<xref target="RFC4944"/>). Previous sections have specified the DFF mechanism in general; specific differences for each MoP are specified in this section.
</t>
<section anchor="route_over_MoP" title="Route-Over">
<t>
This section maps the general terminology from <xref target="terminology"/> to the specific terminology when using the "route-over" MoP.
</t>
<section anchor="route_over_MoP_terminology" title="Mapping of IPv6 Terminology to DFF">
<t>
The following terms are those listed in <xref target="terminology"/>, and their meaning is explicitly defined when DFF is used in the "route-over" MoP:
<list style="hanging">
<t hangText="Packet">
- An IPv6 packet, as specified in <xref target="RFC2460"/>.
</t>
<t hangText="Packet Header">
- An IPv6 extension header, as specified in <xref target="RFC2460"/>.
</t>
<t hangText="Address">
- An IPv6 address, as specified in <xref target="RFC4291"/>.
</t>
<t hangText="Originator Address">
- The Originator Address corresponds to the Source address field of the IPv6 header as specified in <xref target="RFC2460"/>.
</t>
<t hangText="Destination Address">
- The Destination Address corresponds to the Destination field of the IPv6 header as specified in <xref target="RFC2460"/>.
</t>
<t hangText="Next Hop">
- The Next Hop is the IPv6 address of the next hop to which the Packet is sent; the MAC address from that IP address is resolved by a mechanism such as <xref target="RFC4861">ND</xref>. The MAC address is then used by L2 as destination.
</t>
<t hangText="Previous Hop">
- The Previous Hop is the IPv6 address from the interface of the previous hop from which the Packet has been received.
</t>
<t hangText="Hop Limit">
- The Hop Limit corresponds to the Hop Limit field in the IPv6 header as specified in <xref target="RFC2460"/>.
</t>
</list>
</t>
</section>
<section anchor="route_over_MoP_packet_format" title="Packet Format">
<t>
In the "router-over" MoP, all IPv6 Packets MUST conform with the format specified in <xref target="RFC2460"/>.
</t>
<t>
The DFF header, as specified below, is an IPv6 Extension Hop-by-Hop Options header, and is depicted in <xref target="IPv6-DFF-header"/>. This document specifies a new option to be used inside the Hop-by-Hop Options header, which contains the DFF fields (D, and R flags and sequence number, as specified in <xref target="packet_format"/>).
</t>
<t>
<xref target="RFC6564"/> specifies:
<list style="hanging">
<t>
New options for the existing Hop-by-Hop Header SHOULD NOT be created or specified unless no alternative solution is feasible. Any proposal to create a new option for the existing Hop-by-Hop Header MUST include a detailed explanation of why the hop-by-hop behavior is absolutely essential in the document proposing the new option with hop-by-hop behavior.
</t>
</list>
<xref target="RFC6564"/> recommends to use Destination Headers instead of Hop-by-Hop Option headers. Destination Headers are only read by the destination of an IPv6 packet, not by intermediate routers. However, the mechanism specified in this document relies on intermediate routers reading and editing the header. Specifically, the sequence number and the D and R flags are read by each router running the DFF protocol. Modifying the D flag and R flag is essential for this protocol to tag duplicate or returned Packets. Without the D flag, a duplicate Packet cannot be discerned from a looping Packet, and without the R flag, a returned Packet cannot be discerned from a looping Packet.
</t>
<figure anchor="IPv6-DFF-header" title="IPv6 DFF Header">
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | OptTypeDFF | OptDataLenDFF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|R| Sequence Number |0|0|0|0|0|0|0|1|0|0|0|0|0|0|0|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>
Field definitions of the DFF header are as follows:
<list style="hanging">
<t hangText="Next Header">
- 8-bit selector. Identifies the type of header
immediately following the Hop-by-Hop Options
header. As specified in <xref target="RFC2460"/>.
</t>
<t hangText="Hdr Ext Len">
- 8-bit unsigned integer. Length of the Hop-by-Hop Options header in 8-octet units, not
including the first 8 octets. As specified in <xref target="RFC2460"/>. This value is set to 0 (zero).
</t>
<t hangText="OptTypeDFF">
- 8-bit identifier of the type of option as specified in <xref target="RFC2460"/>. This value is set to IP_DFF. The two high order bits of the option type MUST be set to '00' and
the third bit is equal to '1'. With these bits, according to
<xref target="RFC2460"/>, routers that do not understand this option on a received Packet skip over this option and continue processing the header. Also, according to <xref target="RFC2460"/>, the values within the option are expected to change en route.
</t>
<t hangText="OptDataLenDFF">
- 8-bit unsigned integer. Length of the Option
Data field of this option, in octets as specified in <xref target="RFC2460"/>. This value is set to 2 (two).
</t>
<t hangText="DFF fields">
- The D and R flags and the sequence number follow, as specified in <xref target="packet_format"/>.
</t>
<t hangText="PadN">
- Since the Hop-by-Hop Options header must have a length of multiples of 8 octets, a PadN option with length N=2 is used, as specified in <xref target="RFC2460"/>.
</t>
</list>
</t>
</section>
</section>
<section anchor="mesh_under_MoP" title="Mesh-Under">
<t>
This section maps the general terminology from <xref target="terminology"/> to the specific terminology when using the "mesh-under" MoP.
</t>
<section anchor="mesh_under_MoP_terminology" title="Mapping of LoWPAN Terminology to DFF">
<t>
The following terms are those listed in <xref target="terminology"/> (besides "Mode of Operation"), and their meaning is explicitly defined when DFF is used in the "mesh-under" MoP:
<list style="hanging">
<t hangText="Packet">
- A "LoWPAN encapsulated packet" (as specified in <xref target="RFC4944"/>, which contains an IPv6 packet as payload.
</t>
<t hangText="Packet Header">
- A LoWPAN header, as specified in <xref target="RFC4944"/>.
</t>
<t hangText="Address">
- A 16-bit short or EUI-64 link layer address, as specified in <xref target="RFC4944"/>.
</t>
<t hangText="Originator Address">
- The Originator Address corresponds to the Originator Address field of the Mesh Addressing header as specified in <xref target="RFC4944"/>.
</t>
<t hangText="Destination Address">
- The Destination Address corresponds to the Final Destination field of the Mesh Addressing header as specified in <xref target="RFC4944"/>.
</t>
<t hangText="Next Hop">
- The Next Hop is the destination address of a frame containing a LoWPAN encapsulated packet, as specified in <xref target="RFC4944"/>.
</t>
<t hangText="Previous Hop">
- The Previous Hop is the source address of the frame containing a LoWPAN encapsulated packet, as specified in <xref target="RFC4944"/>.
</t>
<t hangText="Hop Limit">
- The Hop Limit corresponds to the Deep Hops Left field in the Mesh Addressing header as specified in <xref target="RFC4944"/>.
</t>
</list>
</t>
</section>
<section anchor="mesh_under_MoP_packet_format" title="Packet Format">
<t>
In the "mesh-under" MoP, all IPv6 Packets MUST conform with the format specified in <xref target="RFC4944"/>. All data Packets exchanged by routers using this specification MUST contain the Mesh Addressing header as part of the LoWPAN encapsulation, as specified in <xref target="RFC4944"/>.
</t>
<t>
The DFF header, as specified below, MUST follow the Mesh Addressing header. After these two headers, any other LoWPAN header, e.g., header compression or fragmentation headers, MAY also be added before the actual payload. <xref target="mesh-header"/> depicts the Mesh Addressing header defined in <xref target="RFC4944"/>, and <xref target="DFF-header"/> depicts the DFF header.
</t>
<figure anchor="mesh-header" title="Mesh Addressing Header">
<artwork align="center"><![CDATA[
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<figure anchor="DFF-header" title="Header for DFF data Packets">
<artwork align="center"><![CDATA[
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| sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]>
</artwork>
</figure>
<t>
Field definitions of the Mesh Addressing header are as specified in <xref target="RFC4944"/>. When adding that header to the LoWPAN encapsulation on the Originator, the fields of the Mesh Addressing header MUST be set to the following values:
<list style="symbols">
<t>
V := 0 if the Originator Address is an IEEE extended 64-bit address (EUI-64); otherwise, V := 1 if it is
a short 16-bit address.
</t>
<t>
F := 0 if the Final Destination Address is an IEEE extended 64-bit address (EUI-64); otherwise, F := 1 if it is
a short 16-bit address.
</t>
<t>
Hops Left := 0xF (i.e., reserved value indicating that the Deep Hops Left field is following);
</t>
<t>
Deep Hops Left := MAX_HOP_LIMIT.
</t>
</list>
</t>
<t>
Field definitions of the DFF header are as follows:
<list style="hanging">
<t hangText="Mesh Forw">
- A 6-bit identifier that allows for the use of different mesh forwarding mechanisms. As specified in <xref target="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.
</t>
<t hangText="DFF fields">
- The D and R flags and the sequence number follow after Mesh Forw, as specified in <xref target="packet_format"/>.
</t>
</list>
</t>
</section>
</section>
</section>
<section title="Scope Limitation of DFF" anchor="scope_limitation">
<t>The forwarding mechanism specified in this document MUST be limited in scope to the routing domain in which DFF is used. That also implies that any headers specific to DFF do not traverse the boundaries of the routing domain. This section specifies, both for the "route-over" MoP and the "mesh-under" MoP, how to limit the scope of DFF to the routing domain in which it is used.</t>
<t>
<xref target="scope-1"/> to <xref target="scope-4"/> depict four different cases for source and destination of traffic with regards to the scope of the routing domain in which DFF is used. <xref target="scope_limitation_mesh_under"/> and <xref target="scope_limitation_route_over"/> specify how routers limit the scope of DFF for the "route-over" MoP and the "mesh-under" MoP respectively for these cases. In these sections, all routers "inside the routing domain" use DFF, and all sources or destinations "outside the routing domain" are either hosts attached to a router running DFF or routers not running DFF.
<figure anchor="scope-1" title="Traffic within the routing domain (from S to D)">
<artwork align="left"><![CDATA[
+-----------------+
| |
| (S) ----> (D) |
| |
+-----------------+
Routing Domain
]]>
</artwork>
</figure>
<figure anchor="scope-2" title="Traffic from within the routing domain to outside of the domain (from S to D)">
<artwork align="left"><![CDATA[
+-----------------+
| |
| (S) --------> (R) --------> (D)
| |
+-----------------+
Routing Domain
]]>
</artwork>
</figure>
<figure anchor="scope-3" title="Traffic from outside the routing domain to inside the domain (from S to D)">
<artwork align="left"><![CDATA[
+-----------------+
| |
(S) --------> (R) --------> (D) |
| |
+-----------------+
Routing Domain
]]>
</artwork>
</figure>
<figure anchor="scope-4" title="Traffic from outside the routing domain, traversing the domain and then to the outside of the domain (from S to D)">
<artwork align="left"><![CDATA[
+-----------------+
| |
(S) --------> (R1) -----------> (R2) --------> (D)
| |
+-----------------+
Routing Domain
]]>
</artwork>
</figure>
</t>
<section anchor="scope_limitation_route_over" title="Route-Over MoP">
<t>
In <xref target="scope-1"/>, both the source and destination of the traffic are routers within the routing domain in which DFF is used. If traffic is originated at S, the DFF header is added to the IPv6 header (as specified in <xref target="route_over_MoP_packet_format"/>). The Originator Address is set to S and the Destination Address is set to D. The packet is forwarded to D using this specification. When router D receives the packet, it decapsulates the inner IPv6 packet if encapsulation was used, and then processes the payload of the IPv6 packet in upper layers.
</t>
<t>
In <xref target="scope-2"/>, the source of the traffic (S) is within the routing domain in which DFF is used, and the destination (D) is outside of the routing domain. If traffic is originated at router S, the IPv6 packet MUST be encapsulated according to <xref target="RFC2473"/>, and the DFF header added to the outer IPv6 header. The Originator Address is set to S and the Destination Address is set to R (in the outer IPv6 header). The packet is forwarded to R using this specification. When router R receives the packet, it decapsulates the IPv6 packet and forwards the inner IPv6 packet to D, using normal IPv6 forwarding as specified in <xref target="RFC2460"/>.
</t>
<t>
In <xref target="scope-3"/>, the source of the traffic (S) is outside of the routing domain in which DFF is used, and the destination (D) is inside of the routing domain. For traffic originated at S, the IPv6 packet is forwarded to R using normal IPv6 forwarding as specified in <xref target="RFC2460"/>. Router R MUST encapsulate the IPv6 packet according to <xref target="RFC2473"/>, and add the DFF header (as specified in <xref target="route_over_MoP_packet_format"/>) to the outer IPv6 header. The Originator Address is set to R, the Destination Address to D (both in the outer IPv6 header), the sequence number in the DFF header is generated locally on R. The packet is forwarded to D using this specification. When router D receives the packet, it decapsulates the inner IPv6 packet and processes the payload of the inner IPv6 packet in upper layers.
</t>
<t>
In <xref target="scope-4"/>, both the source of the traffic (S) and the destination (D) are outside of the routing domain in which DFF is used. For traffic originated at S, the IPv6 packet is forwarded to R1 using normal IPv6 forwarding as specified in <xref target="RFC2460"/>. Router R1 MUST encapsulate the IPv6 packet according to <xref target="RFC2473"/> and add the DFF header (as specified in <xref target="route_over_MoP_packet_format"/>). The Originator Address is set to R1, the Destination Address to R2 (both in the outer IPv6 header), the sequence number in the DFF header is generated locally on R1. The packet is forwarded to R2 using this specification. When router R2 receives the packet, it decapsulates the inner IPv6 packet and forwards the inner IPv6 packet to D, using normal IPv6 forwarding as specified in <xref target="RFC2460"/>.
</t>
</section>
<section anchor="scope_limitation_mesh_under" title="Mesh-Under MoP">
<t>
In <xref target="scope-1"/>, both the source and destination of the traffic are routers within the routing domain in which DFF is used. If traffic is originated at router S, the LoWPAN encapsulated packet is created from the IPv6 packet as specified in <xref target="RFC4944"/>. Then, the Mesh Addressing header and the DFF header (as specified in <xref target="mesh_under_MoP_packet_format"/>) are added to the LoWPAN encapsulation on router S. The Originator Address is set to S and the Destination Address is set to D. The packet is then forwarded using this specification. When router D receives the packet, it processes the payload of packet in upper layers.
</t>
<t>
In <xref target="scope-2"/>, the source of the traffic (S) is within the routing domain in which DFF is used, and the destination (D) is outside of the routing domain. For traffic originated at router S, the LoWPAN encapsulated packet is created from the IPv6 packet as specified in <xref target="RFC4944"/>. Then, the Mesh Addressing header and the DFF header (as specified in <xref target="mesh_under_MoP_packet_format"/>) are added to the LoWPAN encapsulation on router S. The Originator Address is set to S and the Destination Address is set to R. The packet is then forwarded using this specification. When router R receives the packet, it restores the IPv6 packet from the LoWPAN encapsulated packet and forwards it to D, using normal IPv6 forwarding as specified in <xref target="RFC2460"/>.
</t>
<t>
In <xref target="scope-3"/>, the source of the traffic (S) is outside of the routing domain in which DFF is used, and the destination (D) is inside of the routing domain. For traffic originated at S, the IPv6 packet is forwarded to R using normal IPv6 forwarding as specified in <xref target="RFC2460"/>. Router R creates the LoWPAN encapsulated packet from the IPv6 packet as specified in <xref target="RFC4944"/>. Then, R adds the Mesh Addressing header and the DFF header (as specified in <xref target="mesh_under_MoP_packet_format"/>). The Originator Address is set to R, the Destination Address to D, the sequence number in the DFF header is generated locally on R. The packet is forwarded to D using this specification. When router D receives the packet, it restores the IPv6 packet from the LoWPAN encapsulated packet and processes the payload in upper layers.
</t>
<t>
In <xref target="scope-4"/>, both the source of the traffic (S) and the destination (D) are outside of the routing domain in which DFF is used. For traffic originated at S, the IPv6 packet is forwarded to R1 using normal IPv6 forwarding as specified in <xref target="RFC2460"/>. Router R1 creates the LoWPAN encapsulated packet from the IPv6 packet as specified in <xref target="RFC4944"/>. Then, it adds the Mesh Addressing header and the DFF header (as specified in <xref target="mesh_under_MoP_packet_format"/>). The Originator Address is set to R1, the Destination Address to R2, the sequence number in the DFF header is generated locally on R1. The packet is forwarded to R2 using this specification. When router R2 receives the packet, it restores the IPv6 packet from the LoWPAN encapsulated packet and forwards the IPv6 packet to D, using normal IPv6 forwarding as specified in <xref target="RFC2460"/>.
</t>
</section>
</section>
<!--
<section anchor="proposed_values" title="Proposed Values for Parameters and Constants">
<t>
This section lists the parameters used in the specification of the protocol, and proposed values of each that MAY be used.
<list style="symbols">
<t>
P_HOLD_TIME := 5 seconds
</t>
<t>
MAX_HOP_LIMIT := 255
</t>
</list>
</t>
</section>
-->
<section anchor="Security" title="Security Considerations">
<t>
Based on the recommendations in <xref target="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.
</t>
<section anchor="security_out_of_scope" title="Attacks Out of Scope">
<t>
As DFF is a data forwarding protocol, any security issues concerning the payload of the Packets are not considered in this section.
</t>
<t>
It is the responsibility of upper layers to use appropriate security mechanisms (IPsec, TLS, ...) according to application requirements. As DFF does not modify the contents of IP datagrams, other than the DFF header (which is a Hop-by-Hop Options extension header in the "route-over" MoP, and therefore not protected by IPsec), no special considerations for IPsec have to be addressed.
</t>
<t>
Any attack that is not specific to DFF, but that applies in general to the link layer (e.g., wireless, PLC), is out of scope. In particular, these attacks are: Eavesdropping, Packet insertion, Packet replaying, Packet deletion, and man-in-the-middle attacks. Appropriate MAC-layer encryption can mitigate part of these attacks and is therefore RECOMMENDED.
</t>
</section>
<section anchor="security_protection" title="Protection Mechanisms of DFF">
<t>
DFF itself does not provide any additional integrity, confidentiality or authentication. Therefore, the level of protection of DFF depends on the underlying link layer security as well as protection of the payload by upper layer security (e.g., IPsec).
</t>
<t>
In the following sections, whenever encrypting or digitally signing Packets is suggested for protecting DFF, it is assumed that routers are not compromised.
</t>
</section>
<!--
<section anchor="security_end_to_end" title="End-to-end Security">
<t>
While <xref target="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 <xref target="RFC4944"/>), there is currently no specification of securing these headers other than by the underlying link layer security, which is hop-by-hop only.
</t>
<t>
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.
</t>
</section>-->
<section anchor="security_in_of_scope" title="Attacks In Scope">
<t>
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 routers send Packets via broadcast. The attacks listed below are easier to exploit in wireless media, but can also be observed in wired networks.
</t>
<section anchor="security_DoS" title="Denial of Service">
<t>
Denial of Service attacks are possible when using DFF by either exceeding the storage on a router, 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 router could be exhausted by an attack on DFF.
</t>
<t>
The storage of a router can be exhausted by increasing the size of the Processed Set, i.e., by adding new tuples, or by increasing the size of each tuple. New tuples can be added by injecting new Packets in the network, or by forwarding overheard Packets. <!-- (as described in <xref target="security_message_insertion"/>, <xref target="security_replay"/>, and <xref target="security_modification"/> respectively).-->
</t>
<t>
Another possible DoS attack is to send Packets to a non-existing Address in the network. DFF would perform a depth-first search until the Hop Limit has reached zero. Is is therefore RECOMMENDED to set the Hop Limit to a value that limits the path length.
</t>
<t>
If security provided by the MAC layer is used, this attack can be mitigated if the malicious router does not possess valid credentials, since other routers would not forward data through the malicious router.
</t>
</section>
<section anchor="security_modification" title="Packet Header Modification">
<t>
The following attacks can be exploited by modifying the Packet Header information, unless additional security (such as MAC layer security) is used:
</t>
<section anchor="security_return_flag" title="Return Flag Tampering">
<t>
A malicious router may tamper the "return" flag of a DFF Packet, and send it back to the previous hop, but only if that router had been selected as next hop by the receiving router before (as specified in <xref target="packet_processing"/>). If the malicious router had not been selected as next hop, then a returned Packet is dropped by the receiving router.
If, otherwise, the malicious router had been selected as next hop by the receiving router, and the malicious router has set the return flag, the receiving router would then try alternative neighbors. This may lead to Packets never reaching their Destination, as well as unnecessary depth-first search in the network (bandwidth exhaustion / energy drain).
</t>
<t>
This attack can be mitigated by using appropriate security of the underlying link layer.
</t>
</section>
<section anchor="security_dup_flag" title="Duplicate Flag Tampering">
<t>
A malicious router may modify the Duplicate Flag of a Packet that it forwards.
</t>
<t>
If it changes the flag from 0 to 1, the Packet would be detected as duplicate by other routers in the network and not as looping packet. This may have an impact on route repair mechanisms, if an external mechanism as described in <xref target="poison"/> is used.
</t>
<t>
If the Duplicate Flag is set from 1 to 0, and a router receives that Packet for the second time (i.e., it has already received a Packet with the same Originator Address and sequence number before), it will wrongly detect a loop. This may have an impact on route repair mechanisms, if an external mechanism as described in <xref target="poison"/> is used.
</t>
<t>
This attack can be mitigated by using appropriate security of the underlying link layer.
</t>
</section>
</section>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>
IANA is requested to allocate a value from the Dispatch Type Field registry for LOWPAN_DFF.
</t>
<t>
IANA is requested to allocate a value from the Destination Options and Hop-by-Hop Options registry for IP_DFF. The first three bits of that value MUST be 001.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>
Jari Arkko (Ericsson), Antonin Bas (Ecole Polytechnique), Thomas Clausen (Ecole Polytechnique), Yuichi Igarashi (Hitachi), Kazuya Monden (Hitachi), Geoff Mulligan (Proto6), 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.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor='RFC4291'>
<front>
<title>IP Version 6 Addressing Architecture</title>
<author initials='R.' surname='Hinden' fullname='R. Hinden'></author>
<author initials='S.' surname='Deering' fullname='S. Deering'></author>
<date year='2006' month='February' />
</front>
<seriesInfo name='RFC' value='4291' />
<format type='TXT' octets='52897' target='http://www.rfc-editor.org/rfc/rfc4291.txt' />
</reference>
<reference anchor='RFC3484'>
<front>
<title>Default Address Selection for Internet Protocol version 6 (IPv6)</title>
<author initials='R.' surname='Draves' fullname='R. Draves'></author>
<date year='2003' month='February' />
</front>
<seriesInfo name='RFC' value='3484' />
<format type='TXT' octets='55076' target='http://www.rfc-editor.org/rfc/rfc3484.txt' />
</reference>
<reference anchor='RFC6564'>
<front>
<title>A Uniform Format for IPv6 Extension Headers</title>
<author initials='S.' surname='Krishnan' fullname='S. Krishnan'></author>
<author initials='J.' surname='Woodyatt' fullname='J. Woodyatt'></author>
<author initials='E.' surname='Kline' fullname='E. Kline'></author>
<author initials='J.' surname='Hoagland' fullname='J. Hoagland'></author>
<author initials='M.' surname='Bhatia' fullname='M. Bhatia'></author>
<date year='2012' month='April' />
</front>
<seriesInfo name='RFC' value='6564' />
<format type='TXT' octets='12879' target='http://www.rfc-editor.org/rfc/rfc6564.txt' />
</reference>
<reference anchor='RFC2460'>
<front>
<title abbrev='IPv6 Specification'>Internet Protocol, Version 6 (IPv6) Specification</title>
<author initials='S.E.' surname='Deering' fullname='Stephen E. Deering'>
</author>
<author initials='R.M.' surname='Hinden' fullname='Robert M. Hinden'>
</author>
<date year='1998' month='December' />
</front>
<seriesInfo name='RFC' value='2460' />
<format type='TXT' octets='85490' target='http://www.rfc-editor.org/rfc/rfc2460.txt' />
<format type='HTML' octets='99496' target='http://xml.resource.org/public/rfc/html/rfc2460.html' />
<format type='XML' octets='93343' target='http://xml.resource.org/public/rfc/xml/rfc2460.xml' />
</reference>
<reference anchor='RFC6130'>
<front>
<title>Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)</title>
<author initials='T.' surname='Clausen' fullname='T. Clausen'>
<organization /></author>
<author initials='C.' surname='Dearlove' fullname='C. Dearlove'>
<organization /></author>
<author initials='J.' surname='Dean' fullname='J. Dean'>
<organization /></author>
<date year='2011' month='April' />
</front>
<seriesInfo name='RFC' value='6130' />
<format type='TXT' octets='190678' target='http://www.rfc-editor.org/rfc/rfc6130.txt' />
</reference>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
</author>
<date year='1997' month='March' />
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<reference anchor='RFC4944'>
<front>
<title>Transmission of IPv6 Packets over IEEE 802.15.4 Networks</title>
<author initials='G.' surname='Montenegro' fullname='G. Montenegro'>
<organization /></author>
<author initials='N.' surname='Kushalnagar' fullname='N. Kushalnagar'>
<organization /></author>
<author initials='J.' surname='Hui' fullname='J. Hui'>
<organization /></author>
<author initials='D.' surname='Culler' fullname='D. Culler'>
<organization /></author>
<date year='2007' month='September' />
</front>
<seriesInfo name='RFC' value='4944' />
<format type='TXT' octets='67232' target='http://www.rfc-editor.org/rfc/rfc4944.txt' />
</reference>
<!--
<reference anchor='ieee802.15.4'>
<front>
<title>IEEE Std. 802.15.4-2003</title>
<author initials = 'IEEE' surname='Computer Society' fullname='IEEE Computer Society'>
<organization/>
</author>
<date year='2003' month='October'/>
</front>
</reference>
-->
<reference anchor='RFC2473'>
<front>
<title abbrev='Generic Packet Tunneling in IPv6'>Generic Packet Tunneling in IPv6 Specification</title>
<author initials='A.' surname='Conta' fullname='Alex Conta'>
</author>
<author initials='S.' surname='Deering' fullname='Stephen Deering'>
</author>
<date year='1998' month='December' />
</front>
<seriesInfo name='RFC' value='2473' />
<format type='TXT' octets='77956' target='http://www.rfc-editor.org/rfc/rfc2473.txt' />
<format type='HTML' octets='93015' target='http://xml.resource.org/public/rfc/html/rfc2473.html' />
<format type='XML' octets='84253' target='http://xml.resource.org/public/rfc/xml/rfc2473.xml' />
</reference>
</references>
<references title="Informative References">
<reference anchor='KCEC_press_release'>
<front>
<title>DFF deployed by KCEC (Press Release)</title>
<author initials = '' surname='Kit Carson Electric Cooperative (KCEC)' fullname='Kit Carson Electric Cooperative'>
<organization/>
</author>
<date year='2011'/>
</front>
<seriesInfo name='' value ='http://www.kitcarson.com/index.php?option=com_content&view=article&id=45&Itemid=1' />
</reference>
<reference anchor='DFF_paper1'>
<front>
<title>Comparison of Data Forwarding Mechanisms for AMI Networks</title>
<author initials = 'S' surname='Cespedes' fullname='Sandra Cespedes'>
<organization/>
</author>
<author initials = 'A' surname='Cardenas' fullname='Alvaro A. Cardenas'>
<organization/>
</author>
<author initials = 'T' surname='Iwao' fullname='Tadashige Iwao'>
<organization/>
</author>
<date year='2012' month='January'/>
</front>
<seriesInfo name='' value='2012 IEEE Innovative Smart Grid Technologies Conference (ISGT)' />
</reference>
<reference anchor='DFF_paper2'>
<front>
<title>Dynamic Data Forwarding in Wireless Mesh Networks</title>
<author initials = 'T' surname='Iwao' fullname='Tadashige Iwao'>
<organization/>
</author>
<author initials = 'T' surname='Iwao' fullname='Tadashige Iwao'>
<organization/>
</author>
<author initials = 'M' surname='Yura' fullname='Masakazu Yura'>
<organization/>
</author>
<author initials = 'Y' surname='Nakaya' fullname='Yuuta Nakaya'>
<organization/>
</author>
<author initials = 'A' surname='Cardenas' fullname='Alvaro A. Cardenas'>
<organization/>
</author>
<author initials = 'S' surname='Lee' fullname='Sung Lee'>
<organization/>
</author>
<author initials = 'R' surname='Masuoka' fullname='Ryusuke Masuoka'>
<organization/>
</author>
<date year='2010' month='October'/>
</front>
<seriesInfo name='' value='First IEEE International Conference on Smart Grid Communications (SmartGridComm)' />
</reference>
<reference anchor='RFC3552'>
<front>
<title>Guidelines for Writing RFC Text on Security Considerations</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<author initials='B.' surname='Korver' fullname='B. Korver'>
<organization /></author>
<date year='2003' month='July' />
</front>
<seriesInfo name='BCP' value='72' />
<seriesInfo name='RFC' value='3552' />
<format type='TXT' octets='110393' target='http://www.rfc-editor.org/rfc/rfc3552.txt' />
</reference>
<reference anchor='RFC4861'>
<front>
<title>Neighbor Discovery for IP version 6 (IPv6)</title>
<author initials='T.' surname='Narten' fullname='T. Narten'></author>
<author initials='E.' surname='Nordmark' fullname='E. Nordmark'></author>
<author initials='W.' surname='Simpson' fullname='W. Simpson'></author>
<author initials='H.' surname='Soliman' fullname='H. Soliman'></author>
<date year='2007' month='September' />
</front>
<seriesInfo name='RFC' value='4861' />
<format type='TXT' octets='235106' target='http://www.rfc-editor.org/rfc/rfc4861.txt' />
</reference>
</references>
<!--
<section title="Packet Buffering" anchor="Packet_buffering">
<t>
While Packets 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 link layer. This section provides some considerations for how to design the Packet buffer, and how the DFF implementation interacts with the underlying link layer.
</t>
<t>
If possible, it is recommended to share the memory with the underlying link layer, i.e., to store a Packet in the same memory during processing of DFF operation (e.g., successive Packet transmissions to different neighbors during the "depth-first search"), and during the actual transmission by the MAC layer. Keeping a separated copy of the Packet in memory under control of DFF would require additional memory resources.
</t>
<t>
Once the underlying link layer has been tasked to transmit a Packet, 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 Packet 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 Packet in order to resend to other neighbors.
</t>
<t>
Therefore, one of the following two implementation designs is recommended (but other implementation designs may be possible):
<list style="symbols">
<t>
If the memory for the Packets is shared between DFF and the MAC layer, the MAC layer must not delete Packets from the buffer on its own. Instead, the MAC layer should mark the Packet as ready for deletion, so that DFF can decide when to delete the Packet from memory.
</t>
<t>
If the memory is not shared, but instead a copy of each Packet is kept in memory under control of DFF, DFF can decide independently when to delete the Packet from memory.
</t>
</list>
</t>
<t>
In either of the above cases, DFF must not delete a Packet from the memory if DFF is informed by the underlying link layer that the transmission of that Packet has failed. If the transmission has succeeded, the Packet should be deleted from memory. In <xref target="generation_processing"/> (Packet Generation and Processing), the places where the Packet must not be deleted from memory is explicitly stated, whereas otherwise the implementation may implicitly delete the Packet from memory where appropriate.
</t>
<t>
The size of the buffer should be large enough to contain all Packets while they are processed by DFF. The size depends on the available memory, the expected rate of incoming Packets and their size, as well as the reliability of the network; the more the network is unreliable, the longer a Packet has to be kept in the buffer while the Packet is successively sent to the neighbors of the router.
</t>
<t>
If the buffer is exhausted, no new Packets 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 link layer treats buffer exhaustion.
</t>
</section>
-->
<section anchor="Appendix1" title="Examples">
<t>In this section, some example network topologies are depicted, using the DFF mechanism for data forwarding. In these examples, it is assumed that a routing protocol is running which adds or inserts entries into the RIB.
</t>
<section anchor="example1" title="Example 1: Normal Delivery">
<t>
<xref target="example1_fig"/> depicts a network topology with seven routers A to G, with links between them as indicated by lines. It is assumed that router A sends a Packet to G, through B and D, according to the routing protocol.
<figure anchor="example1_fig" title="Example 1: normal delivery">
<artwork align="center"><![CDATA[
+---+
+---+ D +-----+
| +---+ |
+---+ | |
+---+ B +---+ |
| +---+ | |
+-+-+ | +---+ +-+-+
| A | +---+ E +---+ G +
+-+-+ +---+ +-+-+
| +---+ |
+---+ C +---+ |
+---+ | |
| +---+ |
+---+ F +-----+
+---+
]]></artwork>
</figure>
If no link fails in this topology, and no loop occurs, then DFF forward the Packet along the Next Hops listed in each of the routers RIB along the path towards the destination. Each router adds a Processed Tuple for the incoming Packet, and selects the Next Hop as specified in <xref target="getnexthop"/>, i.e., it will first select the next hop for router G as determined by the routing protocol.
</t>
</section>
<section anchor="example2" title="Example 2: Forwarding with Link Failure">
<t>
<xref target="example2_fig"/> 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).
<figure anchor="example2_fig" title="Example 2: link failure">
<artwork align="center"><![CDATA[
+---+
XXX-+ D +-----+
X +---+ |
+---+ X |
+---+ B +---+ |
| +---+ X |
+-+-+ X +---+ +-+-+
| A | XXXX+ E +---+ G +
+-+-+ +---+ +-+-+
| +---+ |
+---+ C +---+ |
+---+ | |
| +---+ |
+---+ F +-----+
+---+
]]></artwork>
</figure>
When B receives the Packet from router A, it adds a Processed Tuple, and then tries to forward the Packet to D. Once B detects that the Packet cannot be successfully delivered to D because it does not receive link layer ACKs, it will follow the procedures listed in <xref target="missed_ACK"/>, 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 Packet to E.
</t>
<t>
As the link to E also fails, B will again follow the procedure in <xref target="missed_ACK"/>. As all possible next hops (D and E) are listed in the Processed Tuple, B will set the RET flag in the Packet and return it to A.
</t>
<t>
A determines that it already has a Processed Tuple for the returned Packet, reset the RET flag of the Packet and select a new next hop for the Packet. As B is already in the list of next hops in the Processed Tuple, it will select C as next hop and forward the Packet to it. C will then forward the Packet to F, and F delivers the Packet to its Destination G.
</t>
</section>
<section anchor="example3" title="Example 3: Forwarding with Missed Link Layer Acknowledgment">
<t>
<xref target="example3_fig"/> 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.
<figure anchor="example3_fig" title="Example 3: missed link layer acknowledgment">
<artwork align="center"><![CDATA[
+---+
+---+ D +-----+
| +---+ |
+---+ | |
+---+ B +---+ |
| +---+ | |
+-+-+ | +---+ +-+-+
| A | +---+ E +---+ G +
+-+-+ +---+ +-+-+
. +---+ |
+...+ C +---+ |
+---+ | |
| +---+ |
+---+ F +-----+
+---+
]]></artwork>
</figure>
While C successfully receives the Packet from A, A does not receive the L2 ACK and assumes the Packet has not been delivered to C. Therefore, it sets the DUP flag of the Packet to 1, in order to indicate that this Packet may be a duplicate. Then, it forwards the Packet to B.
</t>
</section>
<section anchor="example4" title="Example 4: Forwarding with a Loop">
<t>
<xref target="example4_fig"/> depicts the same topology as the Example 1, but there is a loop from D to A, and A sends the Packet to G through B and D.
<figure anchor="example4_fig" title="Example 4: loop">
<artwork align="center"><![CDATA[
+-----------------+
| |
| +-+-+
| +---+ D +
| | +---+
\|/ +---+ |
+---+ B +---+
| +---+ |
+-+-+ | +---+ +-+-+
| A | +---+ E +---+ G +
+-+-+ +---+ +-+-+
| +---+ |
+---+ C +---+ |
+---+ | |
| +---+ |
+---+ F +-----+
+---+
]]></artwork>
</figure>
When A receives the Packet through the loop from D, it will find a Processed Tuple for the Packet. Router A will set the RET flag and return the Packet 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.
</t>
</section>
</section>
<section anchor="deployments" title="Deployment Experience">
<t>
DFF has been deployed and experimented with both in real deployments and in network simulations, as described in the following.
</t>
<section anchor="Japan" title="Deployments in Japan">
<t>
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.
</t>
</section>
<section anchor="KitCarson" title="Kit Carson Electric Cooperative">
<t>
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 <xref target="KCEC_press_release"/>, DFF is running on currently about 400 electric 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 together with a distance vector routing protocol. Metering data from each meter is sent towards a gateway periodically every 15 minutes. The data delivery reliability is over 99%.
</t>
</section>
<section anchor="Simulations" title="Simulations">
<t>
DFF has been evaluated in OMNEST simulations, in conjunction with a distance vector 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 (<xref target="DFF_paper1"/><xref target="DFF_paper2"/>) show significant improvements of the Packet delivery ratio compared to using only the distance vector protocol.
</t>
</section>
<section anchor="OpenSource" title="Open Source Implementation">
<t>
Fujitsu Laboratories of America is currently working on an open source implementation of DFF, which is to be released in 2012, and which allows for interoperability testings of different DFF implementations. The implementation is written in Java, and can be used both on real machines and in the Ns2 simulator.
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:54:59 |