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.