/ccnx-dhcp

DCHP-like server & client to setup faces for ccnx

Primary LanguageC

- How to compile

Edit the variable CCNX_DIR in the Makefile to the location of your already installed ccnx, and then "make". 

- How to run

usage can be asked by passing -h
but typical usage will be:
#for primary server
ccndhcpserver
#for everyone else
ccndhcpnode

- What it does and how to configure it

The server reads a set of routes from its configuration file and listens to the local multicast face. The client multicasts an Interest and the server replies with the set of routes. The client can then configure its faces according to the routes it receives. If the client does not get the server's reply (e.g., not reachable via multicast), it will install a fallback face from the client's configuration.

In the configuration file, there should be a three tuple per line separated by some white spaces
(name-prefix, host, port)
if the line starts with '#' it is considered a comment and ignored
if the line starts with '!' it is a fallback entry -- if a client gets no response it will set up these instead.
The server only sends out the regular routes (those with nothing preceding the start of the line).
Look at the sample files 'ccn_dhcp_server.conf' and 'ccn_dhcp_client.conf'.

A common configuration, for example, is the following.

The server (hobo) at arizona.edu is configured with two routes:
ccnx:/ 224.0.23.170 59695
ccnx:/arizona.edu 224.0.23.170 59695

A client is configured with a fallback:
ccnx:/ 150.135.82.77 9695
#150.135.82.77 is the server's unicast IP address

If the client is in the same multicast LAN as the server, it will receive the two routes from the server and configure its faces accordingly. If it doesn't receive the routes from the server, it will install the fallback route, which is unicast to the server. The server is supposed to have CCND_AUTOREG configured to accommodate this client. Either way, the client gets network connectivity via the server.

Right now faces are setup using UDP, an option for changing this will be available soon.

- Implementation Details:

DHCP group: 224.0.23.170
DHCP port: 59695
DHCP prefix: ccnx:/local/dhcp
DHCP content name: ccnx:/local/dhcp/content
DHCP configuration file: specified by -f parameter, or ./ccn_dhcp_server.conf and ./ccn_dhcp_client.conf by default depending on usage.

DHCP Node:
1. Join DHCP group
    1) join multicast group
    2) create a new face towards the DHCP group and port (the new face uses UDP)
    3) bind DHCP prefix to this new face
2. (Server is S, Client is C)
    S1) read DHCP configuration file (all entries of the config file are sent to the requesting node in one message)
    C1) get a response from the server (with all entries to enter) or read the fallback entries from the config_file
    2) construct DHCP entries into a ccnx message (with DHCP content name) and send to local ccnd (a new entry "CCN_DTAG_DHCPContent = 115" is added to enum ccn_dtag)
    C3)For each forwarding entry (with prefix, host and port):
        1) create a new face to the host and port (the new face uses UDP)
        2) bind the prefix to the face 
S3. The Server will respond with all the entries that is known to them.
C3. The Client will exit.


notes:
If you want to get rid of the entries you will have to kill ccndhcpnode that is running as the server (in the same subnet) and then wait for the data to become stale.
Multicast needs to be enabled. it is turned on by default by linux kernel.

TODO:
Scheduled updates to update faces when the lease expires (leases now are forever)
Have a check that only allows certain signers entries to be used.