DLEP is a proposed IETF standard for protocol for radio-router communication. The intention is to be able to transport information such as layer 1/2 information from a radio to a router e.g. over a standard ethernet link. Depending on the final feature-set the router might even be able to (re-)configure certain settings of the radio.
For more information on how DLEP is integrated into the research node architecture please refer to our IEEE paper.
The DLEP service automatically runs on all research devices for all direct interfaces. For experimentation, the service is accessible via a standard telnet interface from the all deployed slivers on the private bridge with the address fdbd:e804:6aa9::1 (see Addressing in CONFINE). This provides easy access with minimal efforts to get familiar with the service.
For push notification the experiment can run a DLEP client of its own connected to the internal bridge.
The FKIE radio-router communication application “dlep_proxy” provides an example of such radio-router communication. It combines a draft compatible DLEP router which receives information from external direct interfaces, a nl80211 based netlink listener to query local wifi cards and a DLEP radio that can relay this information directly to the sliver experiments through the internal bridge.
“dlep_router” is the receiver part of the DLEP daemons. It connects with a dlep_radio and receives layer2 information through this connection. The plugin uses a UDP multicast to establish a TCP connection between both daemons. The dlep_proxy uses the plugin to receive information from external dlep_capable radios.
“dlep_radio” is the transmitter part of the DLEP daemons. It connects with a dlep_router and transmits layer2 information through this connection. The plugin waits for an UDP multicast from the router to establish a TCP connection between both daemons. The dlep_proxy uses this plugin to provide the layer2 information to the slivers.
“nl80211_listener” queries the local wifi cards for layer2 information. This data will be transmitted through the dlep_radio plugin in addition to data received by the dlep_router plugin.
“layer2info” provides a telnet command to query the current set of layer2 information and return the data as ascii tables of JSON code.
The dlep_proxy is part of the CONFINE packages of the CONFINE Node. It is installed as part of the confine_recommended package.
The dlep_proxy itself is installed to “/usr/sbin/dlep_proxy”, the executable already contains all necessary plugins for the application.
The daemon ist started/stopped with “/etc/init.d/dlep_proxy (start|stop)”. Automatic startup may be enabled/disabled with “/etc/init.d/dlep_proxy (enable|disable)”. If you installed the package “oonf-dlep-proxy” or “confine-recommended”, the DLEP daemon will be “enabled” as default.
The default mode of operation for the DLEP daemon on a CONFINE node is to run as a “service”. Layer 2 information is being polled by the “nl80211_listener” from the wifi cards used as direct interfaces and by “dlep_router” through all other direct interfaces. The information can be queried over the internal bridge by telnet or a dlep_client. Each direct interface has its own dlep_radio instance, they can be reached over the UDP-port 22222 and the following ports.
The current DLEP implementation use UDP multicasts for service discovery and TCP to transport the data towards the DLEP radios.Access control for slivers can be implemented by using iptables/ebtables to block the multicast and unicast packets being sent between internal bridge and slivers.
The OLSR.org wiki has example configurations for the DLEP Plugins.