GNRS Service Deployment

Running a Single-Server GNRS:

The server requires a main configuration file as the only command-line argument. Besides defining several runtime parameters, it also defines locations of configuration files used by certain server modules such as Berkeley DB that we use for persistently storing mappings. A sample set of configuration files is available under <code>gnrs/jserver/sample-configs/single-server/</code>. The main file, <code>server.xml</code>, is XML-based and has comments describing each configurable parameter.

Since the one server handles the entire namespace used to partition the storage of GUID mappings, the IPv4 prefix for this server will be 0.0.0.0/0 (specified in <code>prefixes.ipv4</code> file). For a more general deployment configuration, refer to the multi-server deployment description in the later sections.

Here's how to run the server from the JAR while in the <code>gnrs/jserver</code>:

java -Dlog4j.configuration=file:sample-configs/single-server/log4j.xml \
    -jar target/gnrs-server-1.0.0-SNAPSHOT-jar-with-dependencies.jar \
    sample-configs/single-server/server.xml

Note that the jar file is the one created following the build instructions provided here.

Multi-Server Deployment

A multi-server topology emulates GNRS servers deployed by a collaborative set of networks where each handle a part of the GUID namespace. The portion of the namespace assigned to each server can be thought of as proportional to the size or capability of the network/AS hosting the server. One way to do the partitioning is to use the IPv4 prefix space announced by ASs. In the scheme described in our DMap paper, the GUID is first hashed to the IPv4 namespace and it's hosting AS is determined by reverse lookup of the prefix announces. The latter mappings can be gotten from the BGP table, for instance.

While a BGP table provides prefixes for a Internet-scope AS topology, for experimentation, we provide a set of tools to enumerate a smaller AS-to-prefixes list that still aspires to emulate the Internet in structure.

AS-to-IPv4-Prefix List Generation

As described above, the GNRS requires the list of IPv4 prefixes that each participating AS is responsible for. This is provided by the <code>prefixes.ipv4</code> file in the sample configurations accompanying the sources. All of the following 4 methods produce 2 output files when considering a n-AS inter-network:

# topology.data: [as1, as2, latency in usec] # prefix.data [prefix, AS#]

Common data files

topologyData.mat - DIMES data set stored as MATLAB file : [as1, as2, latency in usec] - Need reference ASPrefixData.mat - BGP routing table data (DIX-IE) [announced IPV4 prefix in CIDR, AS#] - Need reference

Method 1: Top 'm' AS by Degree

Most links

degreeTopoGenerator.m - Octave script reads DIMES data set and ASPrefixData and generates Top 'm' ASs by degree. Considers only direct links between the chosen ASs. Assumes all ASs have atleast 1 link into the graph.

Method 2: Top 'm' AS by Size

Largest prefix space: by announcements - number of IPv4 addresses

sizeTopoGenerator.m: reads DIMES and ASPrefix, outputs top 'm' by size. Considers only direct links between the chosen ASs. If an AS has no links to other chosen ASs, then it is dropped and the next in rank is considered.

Method 3: 'm' AS synthetic topology based on Jellyfish model need reference

jellyfishTopoGenerator.m: input are clique.mat, shellMem.mat, and hangMem.mat, topology data for 3 layers of the Jellyfish model clique.mat: set of ASs that belong to the clique (top/core) layer shellMem.mat: A row for each shell layer (1..4), list of ASs for each shell hangMem.mat: A row for each hang layer (1..4), list of ASs for each shell

script XXXX (Feixiong will send): The above 3 AS data sets were derived by analyzing the DIMES data set: first determine clique nodes, and derived hang and shell nodes by looking at their connectivity from clique nodes and down.

Links for the final topology are derived by mapping the DIMES graph to the culled node set - again only direct links. No peer links between Hang nodes, even though the Jellyfish model does allow for this.

Testing with Clients

Some simple client applications ('add', 'lookup') are included with the GNRS C++ API library in folder <code>gnrs/api/cpp/test-apps</code>.

Trace-driven Client

A client that takes the is included and can be run from the same JAR by invoking the class <code>edu.rutgers.winlab.mfirst.client.TraceClient</code>.

The client takes 3 command-line arguments: client config, trace file, request interval.

• Client config - Contains all of the runtime configuration options for the client. This includes things like the server hostname and port, local sending port, and more. The configuration file is written in XML and fully commented.
• Trace file - Contains a set of messages to send and to the server. The format will be more formally specified at a future date.
• Request Interval - The interval between messages, in microseconds.

Once you've gotten all of your files in order, you're ready to go. Assuming you've just finished building the JAR file with Maven, you can launch the client (using the included example files) like this:

java -Dlog4j.configuration=file:sample-configs/trace-client/log4j.xml \
    -cp target/gnrs-server-1.0.0-SNAPSHOT-jar-with-dependencies.jar \
    edu.rutgers.winlab.mfirst.client.TraceClient \
    sample-configs/trace-client/client.xml \
    sample-configs/trace-client/example.trace 1