Multicast over BAGNet

General Information about BAGNet Multicast

Multicast over BAGNet is done through a point to multipoint pvc setup with 15x4 p2mp trees. There is one tree from each BAGNet host to every other host on BAGNet. These P2MP PVCs are unidirectional and used only to send data to a multicast channel. In order to receive the multicast traffic one has to bind all incoming P2MP PVCs to the class D-IP address space. Klick here to take a look at the P2MP PVCs currently assigned.

BTW, the BAGNet multicast channel is bound to the class D IP address 224.2.175.194 and video is sent an port 48072 (I have no clue why we did not pick 224.8.8.8/8888 or something, but maybe it were just too easy...) and audio is sent to 224.2.175.194/48073 (which should be changed soon since this is the session port of a vic session on data port 48072 - see the RTPv2 spec for details)

Information about BAGNet Multicast at ICSI

Multicast using the Synoptics ATM SBus Adapter Model 975-192

Note: This adapter currently does not support real multicast

To send on the BAGNet multicast channel we bind the Class D IP address (currently 224.2.175.194) to our outgoing point to multipoint PVC (which is PVC 502 on port 15 or PVC 170 on port 2).
To receive data from the BAGNet multicast channel we use some bogus Class C IP addresses and bind each incoming point to multipoint PVCs to one of these addresse.
Afterwards we have to reroute the multicast traffic (224.0.0.0) to our local ATM interface. That means we have to delete the old routing table entry for multicast traffic (if any) and set a new entry with "route add 224.0.0.0 icsibag1 0". Click here to see a shellscript wich does all that.

The Synoptics drivers do not work properly with Solaris 2.4, so we send multicast from our efficient or interphase boards.

Multicast using the Efficient ENI-155s-MF Adapter

The efficient boards are supposed to support real multicast, however, we couldn't find out yet how it works. Therefore we use more or less the same approach as with the Synoptics boards.

To send on the BAGNet multicast channel we bind the Class D IP address (currently 224.2.175.194) to our outgoing point to multipoint PVC (which is PVC 503 on port 15 or PVC 171 on port 3).
To receive data from the BAGNet multicast channel we use some bogus Class C IP addresses and bind each incoming point to multipoint PVCs to one of these addresse.
Afterwards we have to reroute the multicast traffic (224.0.0.0) to our local ATM interface. That means we have to delete the old routing table entry for multicast traffic (if any) and set a new entry with "route add 224.0.0.0 icsibag2 0".

The ARP hack A PVC can be assigned only to one IP address (on boards not providing multicast). If we now wnat to send with a second (or third, or...) IP multicast address on the same PVC, we have to tell the ATM driver to use the same VCI. There is no command to do that, but a hack around: The drivers for the ATM boards are using the ARP (Adress Resolution Protocol) table to store and retrieve the VCI for each IP number. The protocol was designed for Ethernet but the table can be used for any IP number to layer 2 address mapping. After creating the PVC for 224.2.175.194 we can find the exact arp entry with the command "arp 224.2.175.194". We can now set this entry for other IP addresses with "arp -s 224.2.175.255 [arp entry]". The IP address in the example is the one sd uses.

Click here to return to ICSI's BAGNet Home Page.

Marco Alfano (alfano@icsi.berkeley.edu)