Introduction ============ NSIS (Next Steps In Signaling) is a modular framework developed at the IETF NSIS working group. It provides means to establish and manage network control state along a data path between two nodes communicating on the Internet. NSIS builds upon the General Internet Signaling Transport (GIST) protocol. (Note: GIST was formerly known as the General Internet Messaging Protocol for Signaling (GIMPS) but was renamed in the 63th IETF meeting) GIST provides the basic transport functionality that is common to all signaling applications (e.g. signaling aware node discovery and transport layer connections). Above GIST, a number of signaling protocols, known as NSIS Signaling Layer Protocols (NSLPs), can be run. Examples are QoS NSLP and NAT/FW NSLP. The implementation provided in this release contains GIST and the so called "Ping tool", a light-weight NSLP that is able to gather information about the path taken by GIST. In addition this release ships initial versions of QoS NSLP and NAT/FW NSLP. Quick-start =========== Build the sourcecode by running: # make This creates a number of binaries: bin/nsis, bin/gistPing, bin/qos_server bin/qos_client, bin/natfw_server bin/natfw_client Before you can run the NSIS daemon, you need to adjust the configuration file (Default: bin/nsis.conf). In this file you specify your local IP addresses and a routing table telling the NSIS daemon the local address that should be used for outgoing messages. Check the file manual/Configuration for more information about the configuration file. In order to run the NSIS daemon, please use the following syntax using the root account: # bin/nsis -ping This starts a standard nsis instance running the "Ping tool". After starting nsis on a set of nodes, gistPing can be used to test GIST. Run gistPing on a node running nsis and use another node as the ping target. Ping messages will traverse the network and information about the signaling path will be collected on all GIST aware nodes. # bin/gistPing This will run the "Ping tool" with UDP as transport. To tell GIST to use TCP or TLS use (-r and -s). -r alone, will use TCP and -r -s will use TLS. If you want to use the "Ping tool" over IPv6, use the following syntax: # bin/gistPing -v6 The other options (-r, -s, etc.) are also available for IPv6. Requirements ============ Currently there is no automake or other mechanisms in place to adapt the build process to different build environments. The release is tested to work on a number of standard linux systems. The versions we use are: Linux kernel: 2.6.8 and 2.6.11 G++: 3.3.5 (GNU)Make: 3.80 OpenSSL: 0.9.7e Other versions should work too. iptables (if node runs NAT/FW NSLP and is an NSLP Forwarder) NAT/FW NSLP =========== In the current version of NAT/FW NSLP you need to define the variables "is_NAT" and "is_FW" in "nslp/natfw/NatFwServer.h" to specify the NF behaviour. A later version will move this into the NSIS configuration file. Note: After changing these variables you need to rebuild the sourcecode. You do so by: # make clean # make Start the natfw_server with the local IP addresses as arguments. # bin/natfw_server If NSIS runs on a set of nodes you can run the natfw_client using e.g. following command: # bin/natfw_client CREATE For more information on how to use the NAT/FW NSLP see the documention in the file manual/NatFW. QoS NSLP ======== Start the qos_server application on all nodes. # bin/qos_server If NSIS and the QoS NSLP runs on a set of nodes (see examples) you can run the qos_client on ONE node (this will then be your QNI) using a varied set of commands to built several types of messages and adjust them to your needs. # bin/qos_client MESSAGETYPE DEST-IP FLAGS GENERICFLAGS [OBJ1] [OBJ2]... For more information on how to use the QoS NSLP see the documentation in the file manual/QoS Running TCP with TLS as Transport ================================= In order to use TLS, you need to create certificates. This release provides a script to create them. First of all, you need to create a (self signed) CA: # cd tools/certs # ./mkca This creates root_cert.pem and root_privkey.pem. The CA needs to be shared by the nodes that are supposed to communicate to each other over TLS. Afterwards you need to create certificates for the nodes. If your nodes have IP addresses of 10.0.0.1 and 10.0.0.2, you create the certificates with: # ./mkcert 10.0.0.1 # ./mkcert 10.0.0.2 Now you got _cert.pem and _privkey.pem. The certificates need to be copied to the certs/ directory. Each node needs root_cert.pem, _cert.pem and _privkey.pem in there. # cp root_cert.pem _cert.pem _privkey.pem ../../certs/ Now TLS should work properly. Configuration ============= The current implementation can be configured by changing the constants.h file and recompiling afterwards. Configuration switches include refreshrates, certificate paths and debug output. Debug output can also be enabled using by using the command line option "-debug x", where 1 <= x <= 5. Higher values of x indicate less debug output. Team ==== Bernd Schloer Christian Dickmann Xiaoming Fu Henning Peters Ingo Juchem Niklas Steinleitner Andreas Westermaier Hannes Tschofenig Contributors ============ Elwyn Davies Cedric Aoun Sebastian Willert Julien Abeille Youssef Abibi Alexander Zrim Further information can be obtained from our website: http://user.informatik.uni-goettingen.de/~nsis/ Have fun!