Introduction ============ CASP is a modular potocol for establishing and managing network control state along a data path between two nodes communicating on the Internet. It was developed as a protocol candidate for the IETF Next Steps in Signaling (NSIS) working group. The CASP framework includes a general purpose messaging layer (M-layer), which supports a number of client layers for particular signalling applications (e.g. QoS, MIDCOM). In addition, there are distinct, special purpose client components for next-peer discovery. Quick-start =========== After installation of GoCASP (see the INSTALL file for details), you should make sure that your LD_LIBRARY_PATH environment variable includes the path to the CASP modules ('[INSTALLATION_PATH]/lib' in most cases) and your PATH environment includes the path to the GoCASP binaries (most likely '[INSTALLATION_PATH]/bin'). Before you start the CASP daemon you'll have to decide which of your network interfaces should accept CASP messages and what kind of mechanism should be used for discovery. Currently we support static and scout-based discovery. Static discovery: Static discovery will mostly be used in network endpoints with a single outbound route, e.g. home machines. No peer discovery is done at all, but the route to the next hop is given on startup. Not much to do here in preparations as caspd is self-contained with static discovery. Just figure out your gateways IP address and call caspd as follows: caspd --dscmodule libstatic_discovery.so \ --option dsc_nexthop=[GATEWAY-IP] --bind [IF-ADDR] (where GATEWAY-IP is the IP address of your gateway and IF-ADDR the IP address where caspd should listen for CASP messages) Scout discovery: Scout-based discovery relies on an external daemon (which included in the GoCASP distribution) to search for appropriate peers as described in the CASP draft. This daemon has to be started with root privileges: scoutd The scoutd uses IP_ROUTER_ALERT to discover the next hop on the path to the end-destination. Simply speaking it's addressing it's packet to the end-destination but 'stamping' it so that the next CASP-aware router will reply. This way the next hop can (theoretically) easily be determined. After the scout daemon has been started, you can start caspd with the following parameters: caspd --dscmodule libscout_discovery.so --bind [IF-ADDR] (where IF-ADDR is the IP address where caspd should listen for messages) Common options: caspd listens on port 2345 by default. You may change this by adding the option '--port [NUMBER]' to the call (which isn't a good idea right now because we can't discover port numbers yet). Both executables support the '--debug' option which will cause them to write a lot of debug messages to syslog and STDERR (at least if you have enabled them during configuration) and caspd additionally understands '--verbose' which will reduce the amount of output significantly. Client support ============== You now have a running CASP daemon with discovery in place. Let me guess, you are thrilled to see what it can do, aren't you? Unfortunately, caspd is just a M-layer and can't do anything on its own. You need to load at least one CASP client during startup of the daemon which uses the M-layer as transport for its messages. Right now the only supported client is an unofficial one, which we dubbed 'ping client' because it doesn't do anything than responding to a message by sending the data payload back to the initiator where its integrity is checked. You can start caspd with support for this client with this command: caspd [OPTIONS AS ABOVE] --client libping_client.so Using the 'ping client' ======================= Now your caspd runs with support for the 'ping client' protocol. Pretty neat, isn't it? Oh, you still haven't seen anything, have you? OK, let's set up a small network first. I'll assume you have a CASP daemon listening on the interfaces 10.0.0.1 to 10.0.0.3. It doesn't really matter if these interfaces belong to different machines we'll just need the different IP addresses. I'll assume those interfaces are on a single box for simplicity, if your setup is different, you need to change your hosts inbetween the commands. If the network is set up correctly, start a chain of CASP daemons with static discovery (we can't use scout discovery here, as it will find the fastest route between 10.0.0.1 and 10.0.0.3 and you can bet that 10.0.0.2 isn't on it). On the 10.0.0.2 box: caspd --client libping_client.so --dscmodule libstatic_discovery.so \ --option dsc_prevhop=10.0.0.1 --option dsc_nexthop=10.0.0.3 \ --bind 10.0.0.2 On the 10.0.0.3 box: caspd --client libping_client.so --dscmodule libstatic_discovery.so \ --option dsc_prevhop=10.0.0.2 --bind 10.0.0.3 On the 10.0.0.1 box: caspd --client libping_client.so --dscmodule libstatic_discovery.so \ --option dsc_nexthop=10.0.0.2 --bind 10.0.0.1 NOTICE: the option dsc_prevhop is not useful except for testing the M-layer implementation. If you connect to more than one hop, you will be better of using scout-based discovery. (If the interfaces reside on the same machine, it is vital to start the 10.0.0.1 daemon last, as there is just a single socket for local calls to CASP clients, and that is owned by the last instance of caspd running) With all this set up correctly, you can now use the cp_benchmark program on the machine serving 10.0.0.1 to talk to the client on 10.0.0.3: cp_benchmark --agent 10 --count 3 --dst 10.0.0.3 This command will create 10 agents that use the 'ping client' on 10.0.0.1 to communicate with the client on 10.0.0.3. They will send 3 messages during a period of roughly 30 seconds and then exit and give you a simple performance report.