| Version 9 (modified by , 11 years ago) ( diff ) |
|---|
Click-based MobilityFirst Router
Contents
0. Requirements
- Software prototype with reference implementations of dynamic GNRS resolution, hop-by-hop block transfer, storage aware routing (GSTAR)
- Reference implementation/handling of network layer header with service identifier, 160-bit src/dst GUID, src/dst NA(s) and extensible headers for service options processing
- Multicast and anycast forwarding implemented using GNRS maintained membership and routing state from GSTAR
- Configuration and parameter tuning for router roles: core, access
1. System architecture
Figure below outlines the packet-processing pipeline architecture. The pipeline shows two main paths: data and control. The control path implements GSTAR intra-domain routing control protocol including: neighbor discovery, link quality estimation, link-state flooding, and pair-wise DTN state exchange (TBC). The control path also computes the forwarding table entries using a hybrid periodic and on-demand basis. The data path handles the forwarding functions for MobilityFirst data packets, and includes transit buffers, network-address resolution, service classification, packet cloning (in multicast, for example), compute-plane hand off, and hold buffers for temporary storage of data blocks. Functions are implemented as modular Click elements for easy construction of custom router roles such as a that of a core router (or an access router. The architecture supports variable number of input and output ports/interfaces (as long as the processing hardware resources are scaled appropriately) that can be easily aggregated for data/control path processing through elements available with the core distribution of the Click modular router.
PKT PROCESSING OVERVIEW
+++++++++++++++++++++++
___________
| |
-->| Routing X |---
/ |___________| \
/ | \
/ _________|_ \
ctrl. pkt / | | | \ ctrl. pkt
-------------- ->| GSTAR | |--------------
/ |_________|_| \
in / | | \ out
_________ __________ / _________v__v__ \ ___________ _________
| | | | / | | \ -->| | | |
|Device(s)| -> |Classifier| -> | Forward LUT | | Scheduler | -> |Device(s)|
|_________| |__________| \ |_______________| / -->|___________| |_________|
\ ^ | /
\ ________|__v______ /
\ | | /
----------> | Data pkt proc. | -----------
data pkt |__________________| data pkt
Separation of data and control paths simplifies resource allocation (threads, scheduling policy) and prioritization of packet flows. For example, a scheduler element currently prioritizes outbound control packets over data packets, to limit queuing delays in the control plane. The design can also easily accommodate control protocols implemented outside of Click. Such protocol implementations can currently use IP networking to build routing state, and utilize the API exported by the forwarding table module in Click (TBF) to install and manage forwarding entries. Future work may export a messaging API allowing applications to transmit payloads as MobilityFirst packets on the wire.
1.1 Data Path
DATA PATH
+++++++++
_ _ _ _
( ) ______________
( GNRS ) | |
( _ _ _ _ ) | Forward LUT |
^ | |______________|
GUID lookup | | ^ |
____________ ____|_v__ ______|__v___ ___________
| | | | | |forward| |
data pkt | Hop |chunk | Network | | Next-Hop |-----> | Hop | data pkt
----->| Aggregator | --> | Binder | -> | Lookup | | Segmentor | -----> to out port
|____________| |_________| |_____________|----. |___________|
^ |
| |store
| ____v______
| rebind after timeout | |
. ---------------------- |Chunk Store|
|___________|
Hop Block Transfer
Routeable data blocks (complete with an L3 header) are progressed towards the destination in a hop by hop manner. This Hop block transfer is achieved through a Segmentor module that fragments and transmits the block as MTU-sized packets, and a corresponding Aggregator module for reassembly. A simple bit-array based ACK mechanism (a bit for each fragment of the block) ensures reliable transmission. For back pressure, downstream nodes omit ACKs to initial SYN sent by upstream node. Hop by hop transport is ideal for wireless links esp. under variable link quality and packet loss conditions. For reliable segments of the network, MF proposes a L3 bypass that allows a hop to be a consolidation of two or more physical links (TBC).
Name Resolution
When deployed in a single domain, the routers can work without external name resolution - at the cost of propagating all end point GUIDs through the network. For a scalable control plane and limiting the forwarding table size, however, an external service such as the GNRS can be accessed to retrieve end point network addresses (NA). No resolution is required for a packet (routeable data block) with a previously established NA, until and unless a forwarding failure occurs. For packets that have only a dest. GUID, a resolution (i.e., an address lookup for the GUID) is initiated at the NetBinder module. This request is asynchronous and the packet is buffered while awaiting a response. Later, NAs from the response are used to populate the packet before progressing it to the forwarding stage. The implementation supports a GNRS client module that should be configured with the address (IP, port) of a GNRS server. The server itself may reside either on the router (this is common deployment scenario for our software router) or on a separate node on the network.
Buffer Management
1.2 Control path
Generalized Storage Aware Routing (GSTAR)
GSTAR CONTROL PATH
++++++++++++++++++
lnk. prb ____________ lnk prb
+ ack | | + ack
------->| Link Est. |------
/ |____________| \
/ ____________ \
ctrl. pkt / lsa pkt | | lsa pkt \ ctrl. pkt
----------------------------->| LS Rtg. |-----------------------> to out port
\ |____________| /
\ ____________ /
\ | | /
------->| DTN Rtg. |------
d-lsa pkts |____________| d-lsa pkts
____________ ____________ Periodic _____________
| | | | Updates | |
|Neighbor Tbl| | Routing Tbl|--------> | Forward LUT |
|____________| |____________| |_____________|
LUT: lookup table, LS: link state, LSA: link state announcement, D-LSA: DTN LSA
Figure 1: Main components of the Click-based MobilityFirst router
2. Installation
The following instructions are for Ubuntu distributions and in particular have been tested with 10.04 and 12.04 (with the differences noted where applicable).
2.1 Required Packages
sudo apt-get update sudo apt-get -y install git-core subversion curl
2.2 Click Modular Router
MobilityFirst router elements are currently implemented as user-level elements, and pose no compatibility issues with kernel versions. The latest versions of Click can be obtained from it's public site. Click sources are also maintained on a Git repository and can be pulled as shown below :
git clone git://github.com/kohler/click.git click
While the latest Click sources presented no issues as of this writing, a safe option is to check out version 2.0.1 from the installed repository:
cd click git checkout v2.0.1
Set and export the path of Click sources root folder ('click') to env. variable CLICK_SRC.
2.3 MobilityFirst Sources
- Release tarball:
Uncompress the MobilityFirst release tar ball and set the path of root folder ('mobilityfirst') to the variable MF_SRC.
- SVN: The development versions of the prototype components can be checked out from the MobilityFirst SVN (this presently requires an account on the ORBIT testbed that has been approved for accessing MobilityFirst SVN):
svn checkout https://svn.orbit-lab.org/mobilityfirst/trunk/code/prototype mobilityfirst
Set and export path of folder 'mobilityfirst' to the variable MF_SRC
2.4 Compiling Click with MobilityFirst Elements
Copy sources of MobilityFirst elements into designated folder under Click sources for compilation:
cd $MF_SRC/click/elements cp gstar/* gnrs/* app/* test/* utils/* $CLICK_SRC/elements/local/
From within Click source root folder, configure and compile for user-level operation, to include locally added elements, and to support multi-threading:
cd $CLICK_SRC ./configure --disable-linuxmodule --enable-local --enable-user-multithread make elemlist make sudo make install
The last step should install user-level Click binary under /usr/local/bin
2.5 Optional Packages
OML Client Libraries
This is required for compiling the optional Click monitor module. It can be installed from the OML repository at Opensuse.org:
Append the following line to /etc/apt/sources.list
#10.04 deb http://download.opensuse.org/repositories/home:/cdwertmann:/oml/xUbuntu_10.04/ ./ #12.04 deb http://download.opensuse.org/repositories/home:/cdwertmann:/oml/xUbuntu_12.04/ ./
You will also need to add the repository key:
#10.04 curl http://download.opensuse.org/repositories/home:/cdwertmann:/oml/xUbuntu_10.04/Release.key | sudo apt-key add - #12.04 curl http://download.opensuse.org/repositories/home:/cdwertmann:/oml/xUbuntu_12.04/Release.key | sudo apt-key add -
You can now install the necessary OML client packages:
sudo apt-get update sudo apt-get -y install liboml2 liboml2-dev
Refer to detailed installation instructions at the project site.
2.6 Compiling Click Monitor
Note: This is known to compile correctly on 10.04 only, and is being adapted to work with updates to OML libraries for Ubuntu 12.04.
cd $MF_SRC/click/monitor make
3. Running the MobilityFirst Router
3.1. Router Configurations
Several sample configurations for MobilityFirst routers with differing functions can be located under MF_SRC/eval/conf/click eval/conf/click.
Basic Router
The below command line starts up a basic MobilityFirst router instance:
/usr/local/bin/click $MF_SRC/eval/conf/click/MF_BasicRouter.click my_GUID=<router GUID> topo_file=<topology file> core_dev=<interface>
where MF_BasicRouter.click defines the packet processing pipeline, topology file defines the GUID-based connectivity graph with other routers, and the interface is the network interface to operate on (e.g., eth0 or wlan0)
This version implements GSTAR with Hop and GUID based forwarding. It does not resolve NAs for GUIDs using the GNRS service.
Router with Dynamic Name Resolution (GNRS) Support
The following starts up a MobilityFirst router with access to GNRS for resolving GUID to NA:
/usr/local/bin/click $MF_SRC/eval/conf/click/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 MF_Router.click defines the packet processing pipeline, topology file defines the GUID-based connectivity graph with other routers, and the interface is the network interface to operate on (e.g., eth0 or wlan0). The GNRS server parameters correspond the location of local or remote instance of the global name resolution service.
3.2 Topology Control
Since multiple routers may run in a single LAN, connectivity needs to be enforced and packets destined to non-neighbor nodes be dropped. This is enabled in the MobilityFirst router pipeline by way of topology enforcement element that takes a GUID-based connectivity graph passed as a topology file at start up time. Consider below a simple topology with three MobilityFirst routers:
MFR1 ---- MFR2 ---- MFR3 MFR - MobilityFirst Router
The following file defines the 3-node topology illustrated above:
#syntax: <node-GUID> <neighbor-count> <neighbor-GUID1> [<neighbor-GUID2>] ... 1 1 2 2 2 1 3 3 1 2
Sample topology definition files can be located under the folder MF_SRC/eval/topology.
3.3 Logging Configuration
Set environment variable 'MF_CLICK_LOG_LEVEL' to integer between 1 and 7, corresponding to the following debug levels:
| Value | Log Level | Description |
| 1 | DEBUG | |
| 2 | INFO | |
| 3 | TIME | Used for timing analysis outputs |
| 4 | WARN | |
| 5 | ERROR | |
| 6 | CRITICAL | Cases of out of memory, approaching resource limits, etc. |
| 7 | FATAL | Unable to proceed, or when integrity may be compromised |
