Internet DRAFT - draft-cardenas-dff
draft-cardenas-dff
Internet Engineering Task Force U. Herberg
Internet-Draft A. Cardenas
Intended status: Experimental T. Iwao
Expires: September 27, 2012 Fujitsu
M. Dow
Freescale
S. Cespedes
U. Icesi/U. of Waterloo
March 26, 2012
Depth-First Forwarding in Unreliable Networks
draft-cardenas-dff-05
Abstract
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.
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 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 27, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
Herberg, et al. Expires September 27, 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 . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . 13
9.2. Data Frame Processing . . . . . . . . . . . . . . . . . . 14
9.3. LoWPAN Border Routers . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . 18
11. Getting the Next Hop for a Frame . . . . . . . . . . . . . . . 18
12. Poisoning . . . . . . . . . . . . . . . . . . . . . . . . . . 19
13. Route Repair Mechanism . . . . . . . . . . . . . . . . . . . . 20
14. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . . . 20
15. Proposed Values for Parameters and Constants . . . . . . . . . 20
16. Deployment Experience . . . . . . . . . . . . . . . . . . . . 20
16.1. Deployments in Japan . . . . . . . . . . . . . . . . . . . 21
16.2. Kit Carson Electric Cooperative . . . . . . . . . . . . . 21
16.3. Simulations . . . . . . . . . . . . . . . . . . . . . . . 21
16.4. Open Source Implementation . . . . . . . . . . . . . . . . 21
17. Security Considerations . . . . . . . . . . . . . . . . . . . 21
Herberg, et al. Expires September 27, 2012 [Page 2]
Internet-Draft DFF March 2012
17.1. Attacks Out of Scope . . . . . . . . . . . . . . . . . . . 21
17.2. Protection Mechanisms of DFF . . . . . . . . . . . . . . . 22
17.3. End-to-end Security . . . . . . . . . . . . . . . . . . . 22
17.4. Attacks In Scope . . . . . . . . . . . . . . . . . . . . . 22
17.4.1. Denial of Service . . . . . . . . . . . . . . . . . . 23
17.4.2. Frame Modification . . . . . . . . . . . . . . . . . 23
17.4.2.1. Return Flag Tampering . . . . . . . . . . . . . . 23
17.4.2.2. Duplicate Flag Tampering . . . . . . . . . . . . 24
18. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
20.1. Normative References . . . . . . . . . . . . . . . . . . . 24
20.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 25
A.1. Example 1: Normal Delivery . . . . . . . . . . . . . . . . 25
A.2. Example 2: Forwarding with Link Failure . . . . . . . . . 26
A.3. Example 3: Forwarding with Missed Link Layer
Acknowledgment . . . . . . . . . . . . . . . . . . . . . . 27
A.4. Example 4: Forwarding with a Loop . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Herberg, et al. Expires September 27, 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
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 routing protocol, ND, HELLO message
exchange). If none of the next hops successfully receives or
forwards 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 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 27, 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 at the same time to increase delivery success rates.
If a 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 routing protocol which allows for providing an
order of preference for 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 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 27, 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].
LoWPAN Border Router - A border router located at the junction of
separate LoWPAN networks or between a LoWPAN network and another
IP network.
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.
Herberg, et al. Expires September 27, 2012 [Page 6]
Internet-Draft DFF March 2012
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 routing protocol used in
conjunction with DFF. Such a protocol provides "hints" to DFF in
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 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 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 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 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 routing protocol thus only
serves DFF to give recommendations (or "hints") where to forward a
Herberg, et al. Expires September 27, 2012 [Page 7]
Internet-Draft DFF March 2012
frame. That also implies that if the 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.
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 uniquely 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
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.
Herberg, et al. Expires September 27, 2012 [Page 8]
Internet-Draft DFF March 2012
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
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
Herberg, et al. Expires September 27, 2012 [Page 9]
Internet-Draft DFF March 2012
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):
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, and that data frames conform with the format
specified in [RFC4944]. In particular, [RFC4944] states that
Herberg, et al. Expires September 27, 2012 [Page 10]
Internet-Draft DFF March 2012
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.
After these two headers, any other LoWPAN header, e.g. header
compression or fragmentation headers, 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.
Herberg, et al. Expires September 27, 2012 [Page 11]
Internet-Draft DFF March 2012
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
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 LoWPAN Border Routers.
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
Herberg, et al. Expires September 27, 2012 [Page 12]
Internet-Draft DFF March 2012
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].
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 for 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:
Herberg, et al. Expires September 27, 2012 [Page 13]
Internet-Draft DFF March 2012
* 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
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;
Herberg, et al. Expires September 27, 2012 [Page 14]
Internet-Draft DFF March 2012
+ 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 := [];
+ 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).
Herberg, et al. Expires September 27, 2012 [Page 15]
Internet-Draft DFF March 2012
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.
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. LoWPAN Border Routers
The PAN may be connected to other networks (e.g. the Internet)
through a LoWPAN Border Router, i.e. a node with at least two
interfaces, an internal one to the PAN, and an external one towards
Herberg, et al. Expires September 27, 2012 [Page 16]
Internet-Draft DFF March 2012
other networks.
If such a LoWPAN Border Router 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
LoWPAN Border Router.
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 LoWPAN Border Router).
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."
Herberg, et al. Expires September 27, 2012 [Page 17]
Internet-Draft DFF March 2012
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.
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
Herberg, et al. Expires September 27, 2012 [Page 18]
Internet-Draft DFF March 2012
"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.
1. If a 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
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 routing protocol is used in conjunction
with DFF, the cost for the route MAY be increased in that routing
protocol. Thus, future transmissions will 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.
Herberg, et al. Expires September 27, 2012 [Page 19]
Internet-Draft DFF March 2012
13. Route Repair Mechanism
If DFF is used in conjunction with a routing protocol, route repair
mechanisms of that 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 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).
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 LoWPAN Border Router 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 LoWPAN Border Router, in the same way that
they are for IP packets originating from the LoWPAN Border Router.
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.
Herberg, et al. Expires September 27, 2012 [Page 20]
Internet-Draft DFF March 2012
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
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
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 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
Herberg, et al. Expires September 27, 2012 [Page 21]
Internet-Draft DFF March 2012
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.
Any attack that is not specific to DFF, but that applies in general
to forwarding mechanisms in wireless environments, is out of scope.
In particular, these attacks are: Eavesdropping, frame insertion,
frame replaying, frame deletion, and man-in-the-middle attacks.
Appropriate MAC-layer encryption can mitigate part of these attacks.
17.2. Protection 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
Herberg, et al. Expires September 27, 2012 [Page 22]
Internet-Draft DFF March 2012
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
the network, by replaying frames or by modifying frames.
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 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.
Herberg, et al. Expires September 27, 2012 [Page 23]
Internet-Draft DFF March 2012
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
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.
18. IANA Considerations
IANA is requested to allocate a value from the Dispatch Type Field
registry for LOWPAN_DFF.
19. Acknowledgements
Jari Arkko (Ericsson), 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.
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.
Herberg, et al. Expires September 27, 2012 [Page 24]
Internet-Draft DFF March 2012
[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.
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 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 routing
protocol.
Herberg, et al. Expires September 27, 2012 [Page 25]
Internet-Draft DFF March 2012
+---+
+---+ 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 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).
+---+
XXX-+ D +-----+
X +---+ |
+---+ X |
+---+ B +---+ |
| +---+ X |
+-+-+ X +---+ +-+-+
| A | XXXX+ E +---+ G +
+-+-+ +---+ +-+-+
| +---+ |
+---+ C +---+ |
+---+ | |
| +---+ |
+---+ F +-----+
+---+
Figure 4: Example 2: link failure
Herberg, et al. Expires September 27, 2012 [Page 26]
Internet-Draft DFF March 2012
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.
+---+
+---+ 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
Herberg, et al. Expires September 27, 2012 [Page 27]
Internet-Draft DFF March 2012
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
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
Herberg, et al. Expires September 27, 2012 [Page 28]
Internet-Draft DFF March 2012
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
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 27, 2012 [Page 29]
