Router Configurations

Sample configurations for the Click-based router can be located under router/click/conf/. They differ in feature set and role. For instance, the most basic router supports just unicast and forwards based on GUID alone. On the other end of the spectrum, and Multi-Router supports hybrid GUID/NA forwarding and multiple delivery services including anycast, multihoming, and multicast. The command lines with required parameters accompanying each router type assume Click with MF routing elements have been installed at default locations.

1. Basic Router

This version implements GUID based forwarding with Hop data transfer and GSTAR routing control. It does not interface with GNRS to dynamically resolve NAs for destination GUIDs. The following starts up the basic MobilityFirst router:

/usr/local/bin/click $MF_CLICK_OPTIONS $MF_SRC/router/click/conf/MF_BasicRouter.click \
                     my_GUID=<router GUID> \
                     topo_file=<topology file> \
                     core_dev=<interface>

where MF_BasicRouter.click defines the packet processing pipeline configuration, the topology file defines the GUID-based connectivity graph of all network elements (refer to section on network deployment for details on setting up a topology), and the interface is the network interface to operate on (e.g., eth0 or wlan0). The Click options variable MF_CLICK_OPTIONS could be set to '-j 4 -p xxxx', where option '-j' defines number of task threads, and option '-p' sets the port number for Click's control interface - required when deploying the router with a monitor that queries the Click router for current state, traffic statistics, etc. through the control interface.

2. Router with Dynamic Name Resolution (i.e., w/ GNRS integration)

The following starts up a router that supports GUID to NA resolution by interfacing to a GNRS server instance:

/usr/local/bin/click $MF_CLICK_OPTIONS $MF_SRC/router/click/conf/MF_Router.click \
                     my_GUID=<router GUID> \
                     topo_file=<topology file> \
                     core_dev=<interface> \ 
                     GNRS_server_ip=<server-IP> GNRS_server_port=<port> \
                     GNRS_listen_ip=<local-IP> GNRS_listen_port=<client-port>

where the GNRS server parameters point to a local or remote instance of the global name resolution service - refer to section on GNRS configuration for bringing up a server instance.

3. Multi-Router: Support for Multiple Routing Services

The basic routers above support the default set of delivery/routing services: unicast, GSTAR, and GNRS-based dynamic address binding. The MultiRouter additionally supports a richer set of delivery services, including multihome delivery, multicast and anycast, each invoked according to the Service IDentifier (SID) field in a packet's network header. The following brings up a MultiRouter instance:

/usr/local/bin/click $MF_CLICK_OPTIONS  $MF_SRC/router/click/conf/MF_MultiRouter.click \
                     my_GUID=<router GUID> \
                     topo_file=<topology file> \
                     core_dev=<interface> \ 
                     GNRS_server_ip=<server-IP> GNRS_server_port=<port> \
                     GNRS_listen_ip=<local-IP> GNRS_listen_port=<client-port>

The MultiRouter, as configured, supports anycast, end-point multihoming, and basic multi-endpoint delivery.

4. Access Router / IP Access Router: Host-Network Access Services

        Host ---- (edge-interface) Access_MFR (core-interface) ---- MFR ---- ....  

Refer to the host stack configuration page for bringing up a host connected to an access router. An access router implements three important functions to enable network access for hosts. First, the router implements one or more access network interfaces corresponding to particular radio access networks or Ethernet. Second, the router (along with the host protocol stack) implements a low-level association protocol whereby it pairs the host's GUID (or the GUID of the network-attached object) with the network address (NA) corresponding to the attachment point and inserts the mapping into the GNRS. Third, it implements any protocol translation required to accommodate non-MobilityFirst access networks - present configurations supports only MF or IPv4 networks The sample access router configurations packaged here supports 1 access/edge-side interface and 1 back-haul or core-side interface (see figure above) and can be brought up using:

/usr/local/bin/click $MF_CLICK_OPTIONS $MF_SRC/router/click/conf/MF_AccessRouter.click \
                     my_GUID=<router GUID> \
                     topo_file=<topology file> \
                     core_dev=<core interface> \ 
                     GNRS_server_ip=<server-IP> GNRS_server_port=<port> \
                     GNRS_listen_ip=<local-IP> GNRS_listen_port=<client-port> \
                     edge_dev=<edge interface>

IP Access Router: In cases where access network supports only IP packets, the host protocol stack can encapsulate all MF packets (data and control) within IP packets with the destination IP set to the IP-addressed edge interface on the access router. The router then performs the protocol translation by either stripping or adding IP headers to provide connectivity to/from the MobilityFirst network, respectively. Any number of hosts can associate with an access router in this manner, and the router embeds a MAC/IP learning module that enables it to forward properly encapsulated packets on the correct interfaces that a particular host is connected on. An IP access router configured with a single edge and core interfaces can be brought up with the following:

/usr/local/bin/click $MF_CLICK_OPTIONS $MF_SRC/router/click/conf/MF_IPAccessRouter.click \
                     my_GUID=<router GUID> \
                     topo_file=<topology file> \
                     core_dev=<core interface> \ 
                     GNRS_server_ip=<server-IP> GNRS_server_port=<port> \
                     GNRS_listen_ip=<local-IP> GNRS_listen_port=<client-port> \
                     edge_dev=<edge interface> \
                     edge_dev_ip=<edge i/f IP>

5. Test Configurations: File Sender and Receiver

While one would deploy the routers with hosts attached at the edges to test end-to-end topologies, you could also run quick tests of the forwarding-routing functions using Click-based file transfer source and sink modules. The sender constructs packets with MF network header (unicast delivery by default), simple transport header, and payload read from a specified file. Minor modifications to the sender element can enable traffic for testing other delivery types such as multicast - basically, by changing the SID. Since the sender and receiver are derived from basic router configurations, sender/receiver nodes will also participate in MF control protocol. They do not, however, forward packets not destined for them. The following brings up an instance of file sender:

/usr/local/bin/click $MF_CLICK_OPTIONS $MF_SRC/router/click/conf/test/MF_FileSender.click \
                     my_GUID=<router GUID> \
                     topo_file=<topology file> \ 
                     core_dev=<interface> \
                     GNRS_server_ip=<server IP> GNRS_server_port=<port> \
                     GNRS_listen_ip=<local-IP> GNRS_listen_port=<client-port> \
                     src_GUID=<sender GUID> \
                     dst_GUID=<dest GUID> \
                     file_to_send=<full path of file to send> \
                     chk_size=<size of chunk in bytes> \
                     delay=<seconds to wait before starting to send> \
                     pkt_size=<size of L2 (header + payload) in bytes>

Note that the router GUID and the sender GUID above can be the same. A chunk here is granularity of reliable data transfer at each hop. MobilityFirst protocol considers chunk sizes of several KB to a few MB, and may go up to to a few hundred MB for large data transfers (e.g., music and video files). Smaller chunks for short messages are also quite efficiently supported. The following brings up a file receiver instance:

/usr/local/bin/click $MF_CLICK_OPTIONS $MF_SRC/router/click/conf/test/MF_FileReceiver.click \
                     my_GUID=<router GUID> \
                     topo_file=<topology file> \ 
                     core_dev=<interface>

The file receiver is a simple sink that stores the received data as a file (random generated name) in a designated folder. Note that the router GUID of the receiver should be the GUID used as destination parameter when starting the sender.

6. Setting up WiFi Access on Router

The following instructions assume a Debian derivative Linux distro.

# Install required packages
# -------------------------

sudo apt-get -qq -y install hostapd dnsmasq


# Bring up driver for the local wifi adaptor
# ------------------------------------------

# If the wifi interface is not up already, you can use tools such as 'lspci' 
# or 'lsusb' to find which wifi adaptor is installed and load the appropriate
# driver. E.g., for all Atheros IEEE 802.11n PCI/PCI-Express and AHB WLAN based 
# chipsets use the 'ath9k' driver.
sudo modprobe ath9k

# To determine which interface came up from above driver action, check using
sudo ifconfig -a 

# Note: if your node uses NetworkManager to manage an active Internet connection 
# (e.g., if you are using a laptop to run as an access router), you may have to 
# disable this daemon first and activate the device if blocked:
sudo nmcli nm wifi off
sudo rfkill unblock wlan


# Configure interface 
# -------------------

# bring up WiFi interface with IP and netmask. This will be the AP's IP.
sudo ifconfig wlan0 192.168.1.1 netmask 255.255.255.0 up


# Set up DHCP (optional)
# ----------------------

# Edit DHCP configuration in /etc/dnsmasq.conf to alter interface, IP range,
# and to add any particular MAC-IP assignment bindings to be enforced
# See sample configuration in section below.
sudo vi /etc/dnsmasq.conf

# restart DHCP service:
sudo service dnsmasq restart


# Configure and Bringup hostapd
# -----------------------------

# Create/edit a hostapd.conf (sample shown below) to configure interface, essid, 
# channel, passphrase etc., for the AP. Using '/etc/hostapd/hostapd.conf' as
# the location makes it convenient for automation
sudo vi /etc/hostapd/hostapd.conf

# To automate initialization, edit '/etc/default/hostapd' to uncomment and set 
# DAEMON_CONF to the absolute path of your hostapd configuration file. This also 
# enables hostapd to be started at boot.
sudo vi /etc/default/hostapd

#DAEMON_CONF="/etc/hostapd/hostapd.conf"

# To start, stop, restart hostapd:
sudo /etc/init.d/hostapd {start|stop|restart}

# or use 'service' tool
sudo service hostapd {start|stop|restart}

# Here's the manual way to bring up hostapd if needed (-B sets background mode):
sudo hostapd -BtKd /etc/hostapd/hostapd.conf

Sample hostapd Configuration

interface=wlan0
driver=nl80211
ssid=mfaccess-test
# hw_mode: always a subset of a, b, g
hw_mode=g
channel=11
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
# wpa=3 enables wpa & wpa2
wpa=3
wpa_passphrase=mfaccess-test
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Refer to the ​hostapd documentation for further details.

Sample Dnsmasq Configuration

interface=wlan0
# dhcp-range=<startIP>, <endIP>,<lease time>
dhcp-range=192.168.1.128,192.168.1.254,24h
dhcp-host=aa:22:bb:44:cc:66,192.168.1.128

Bringing up Access Router

Now that the wireless interface is setup for clients to connect and authenticate, bring up MobilityFirst access router as show on top of this page