NSIS-ka
A free C++ implementation of NSIS protocols

IP Multicast Support for NSIS

Our proposed changes were published at IWQoS 2011 Advanced Quality-of-Service Signaling for IP Multicast.

The current implementation can be checked out here:

svn co https://svn.tm.kit.edu/nsis/dist/nsis-ka/branches/20090723-multicast

Since our implementation is based on Linux, we used the SMCRoute Software for multicast forwarding. The configuration of the hosts can be best explained using our evaluation scenario depicted in the Figure below.

Network topology used for NSIS multicast evaluation tests

We used 16 standard PCs to build a multicast tree where tb6 served as the tree's root (data flow sender) and tb14 to tb21 served as the tree's leaves (data flow receivers). In this scenario tb7 to tb13 acted as intermediate nodes that actively participated in both, the multicast forwarding and the QoS NSLP signaling session.

All 16 PCs ran an instance of the 20090723-multicast branch of the NSIS-ka software. For testing purposes, we used the multicast address 224.7.7.7. The following configurations were used for the different entities:

Configuration of the flow sender (tb6)

The flow sender does not need to run the SMCRoute software and the NSIS-ka software can also be used without any specific configuration adjustments.

In order to use ping to test multicast forwarding, the TTL value of ICMP packets must be increased, since this value is set to 1 by default on Linux for IP multicast addresses. This can be accomplished by the following iptables rule:

iptables -t mangle -A POSTROUTING -d 224.7.7.7 -j TTL --ttl-inc 9

Configuration of intermediate nodes (tb7 to tb13)

The intermediate NSIS nodes must be configured to support IP multicast in terms of IP forwarding and QoS signaling. Therefore, the NSIS-ka configuration file etc/nsis-ka.conf must contain the IP addresses of the node's interfaces (localaddr-v4), the multicast address which should be interpreted by QoS NSLP (local-equiv-addrs), and (optionally) a value in miliseconds for GIST's multicast response delay (multicast-response-delay). Here is an example of tb7's nsis-ka.conf entries:

localaddr-v4 = "10.6.7.7 10.7.8.7 10.7.9.7"
local-equiv-addrs = "224.7.7.7"
multicast-response-delay = 20

Furthermore, the SMCRoute daemon must be configured to forward incoming multicast packets on specific interfaces. In terms of tb7 the incoming interface was eth0 and it used two outgoing interfaces, namely eth1 and eth2. We used the following script to start the daemon:

#!/bin/sh

# Forward incoming multicast packets coming from 10.6.7.6 on eth0
# and destined to 224.7.7.7 on interfaces eth1 and eth2
sudo smcroute -k
sudo smcroute -d
sudo smcroute -a eth0 10.6.7.6 224.7.7.7 eth1 eth2

Configuration of the flow receivers (tb14 to tb21)

The data flow receivers are the leaves of the multicast tree. In order to allow ping tests to be used for multicast packets, multicast ICMP packets need to be echoed back:

echo 0 | tee /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

Regarding NSIS signaling, the flow receivers must be configured to act as last signaling hops by additionaly using the QoS NSLP specific nsis-ka.conf's variable subscribed-multicast-groups:

subscribed-multicast-groups = "224.7.7.7"

The SMCRoute daemon must be set up in a way that this node acts as multicast receiver, e.g., for tb20:

#!/bin/sh

# configure as multicast receiver
smcroute -k
smcroute -d
smcroute -j eth0 224.7.7.7

Testing and Evaluation

In order to test and evaluate NSIS signaling in an IP multicast environment, the SMCRoute daemons must run and on each host an instance of the NSIS-ka software (with corresponding configuration parameters in the etc/nsis-ka.conf file) must be compiled and started via

svn co https://svn.tm.kit.edu/nsis/dist/nsis-ka/branches/20090723-multicast
cd 20090723-multicast/
make -f Makefile.svn
./configure
make
cd qos-nslp/src/
sudo ./start-qosnslp

For performance tests remember to deactive the logging output via the configure option --disable-logging. After that, you can start sender- or receiver-initiated reservations from the data flow sender. In order to do that, start a new shell on tb6 and use the mcast-client application to initiate multiple reservation requests subsequently:

cd 20090723-multicast/qos-nslp/src/
sudo ./mcast-client <src_address> <dst_address> <rounds> [R]
Last modified 6 years ago Last modified on Feb 14, 2012, 3:34:41 PM

Attachments (1)

Download all attachments as: .zip