Overview

The NRL Simplified Multicast Forwarding (nrlsmf) project is a user-space software implementation of the forwarding engine for Simplified Multicast Forwarding (SMF, RFC 6621). This software is was developed by the Naval Research Laboratory (NRL) PROTocol Engineering Advanced Networking (PROTEAN) Research Group. The goal of this effort is to provide an implementation of experimental techniques for robust, efficient distribution of broadcast or multicast packets in dynamic, wireless networks such as Mobile Ad-hoc Networks (MANETs). The nrlsmf application can be run as a stand-alone application capable of providing "classic" flooding of broadcast and multicast traffic for a specified network interface or can be used in conjunction with a controlling program to perform more sophisticated multicast forwarding. An interprocess communication "remote control" interface is provided so that a compatible program (e.g. NRL-OLSR) may issue real-time commands to nrlsmf to control the multicast forwarding process. Both IPv4 and IPv6 operation are supported. Versions of nrlsmf can be built for the following operating systems: Linux, MacOS, BSD, Win32, and WinCE.

Theory of Operation

The nrlsmf program acts as a packet forwarding engine by promiscuously "sniffing" packets on a specified interface and then retransmitting packets (using its local network interface MAC address) according to set forwarding rules. Currently, nrlsmf only receives and forwards packets on a single, specified network interface for operation within the "routing area" corresponding to that (generally wireless) interface. However, future iterations of nrlsmf will also allow for packet reception and forwarding across multiple interfaces to allow for configurable gateway operation. Currently, nrlsmf will forward incoming (non-locally generated) packets that are IP Multicast with time-to-live (TTL) greater than one.

Duplicate packet detection is an important facet of wireless network multicast forwarding since packets often must be forwarded on the same interface as they are received. Thus, neighbors' subsequent retransmission of forwarded packets will be "heard" and the local forwarding engine must discriminate between new packets and previously-forwarded packets to avoid unnecessary retransmission. Accomplishing duplicate packet detection of native (unencapsulated) IP packets presents several challenges:

1. While the IPv4 packet "id" field (a 16-bit sequence) number is available to discriminate duplicate packets, its implementation varies in different operating systems (e.g. always set to ZERO, incremented on a "per socket" basis instead of global, etc). Furthermore, when incremented on a global basis (with respect to the originating host's IP packet transmission), other data flows (TCP sockets or other multicast or unicast flows) may cause the field to be incremented haphazardly (or wrap quickly) with respect to a specific flow of traffic to be forwarded by an SMF engine. Ideally, a sequence number that incremented on a per-IP destination basis (with respect to an originating source) would be most useful for duplicate packet detection. There are also further issues to consider with respect to the possibility of IP security (IPSec) operation or network address translation (NAT) presence that complicate matters here. However, regardless of these issues, the current nrlsmf implementation boldly uses the IP "id" field for duplicate packet discrimination. Work is in progress to develop mechanisms to "correct" the IP "id" field (or possibly insert an header option) on hosts participating in networks with SMF.
2. In IPv6, there is no equivalent to the IPv4 "id" field, so duplicate detection is further complicated. The current nrlsmf implementation has a partially-implemented feature that attempts to mitigate this by adding a hop-by-hop options header for detected, locally-generated IPv6 flows. Then, incoming flows that have the option header are forwarded. This results in two copies of each generated multicast packet on the first hop, but correct forwarding on subsequent hops. A similar approach could be adopted to "correct" IPv4 "id" fields on systems where this is needed in lieu of outbound packet interception. Again, we are investigating approaches to outbound packet interception for supported operating systems to provide a more efficient experimental capability for long-term use.
3. Also under investigation are approaches to using "hash" functions for duplicate detection. Preliminary results indicate these approaches are complex for per-packet processing and imperfect with respect to false duplicate detection which results in undesirable packet loss, perhaps unrecoverable even with end-to-end reliability mechanisms. But further investigation is merited.
4. Encapsulation of packets for forwarding has some advantages in that discrimination for duplicate packet detection can be carefully controlled. The principle disadvantage is that edge wireless systems (not participating in packet forwarding) without explicit SMF support for decapsulation would be unable to receive multicast transmissions they would have otherwise been able to receive had native IP packet formats been used.

The nrlsmf currently forwards based on its configuration and possibly the source MAC address of received packets meeting TTL criteria. If "default forwarding" is enabled, nrlsmf will forward all non-duplicate, TTL > 1, multicast packets. Otherwise, nrlsmf only forwards packets with MAC source addresses matching those in a list provided by a separate controlling program (e.g. NRL-OLSR). Future versions of nrlsmf will feature additional options to control the forwarding process and allow experiments with different algorithms and techniques.

User's Guide

Please see the NRLSMF User's Guide for detailed information on compilation and usage.

Downloads

Source and binary distributions of nrlsmf are available at http://downloads.pf.itd.nrl.navy.mil/smf/. Please note that nrlsmf also requires ProtoLib.

If you are interested in more information about SMF, please contact smf_info@nrl.navy.mil.