MBONE: Multicasting Tomorrow's Internet

More on Bandwidth

SDR introduces a new concept, administrative scopes. This new concept is a much more user-friendly way to specify a scope for a conference.

In SD, we used TTLs to specify the area within which an MBONE event would be constrained. Not only do the default TTL values in SD not necessarily correspond to the threshold values for the various tunnels in multicast routers around your site, but you also have to actually know these threshold values so that you can decide a good TTL value to use. It can rapidly become confusing for the novice users who are just given permission to use the MBONE. One of the drawbacks of the MBONE is the grief caused by users who are improperly informed of the proper procedures; they have in their hands very powerful tools that can send an awful lot of traffic to the Internet.

Administrative scopes will solve a big part of this particular problem, even if the primary reason for their existence was not this. Administrative scopes will be handled by the multicast router using the multicast address of the conference rather than using the TTL field in a multicast packet.

In multicast routers, an administratively scoped region will be defined using the "boundary" argument to the tunnel or phyint options in the mrouted.conf file. Here are the tunnels from my own mrouted.conf file, and I have set boundaries as if I had already set up these administratively scoped regions. Of course, the addresses I use are fake because the IANA (Internet Assigned Numbers Authority) will be assigning them, and I have not gone through this process yet (see Appendix E on how to contact the IANA).

# First, let's name our boundaries.
# The syntax is IP address/mask. In the Montreal Example,
# all addresses from 239.124.0.0 to 239.124.255.255 will be part
# of that administratively scoped region (See below for more		#	details).
name CC 239.123.0.0/16
name Montreal 239.124.0.0/16
name Canada 239.125.0.0/16
name McGill 239.126.0.0/16

phyint  132.216.30.10 metric 1 threshold 1

# Department of Algorythms
tunnel 123.456.78.90 123.456.3.4 metric 1 threshold 8 boundary CC

# Faculty of Harmonies
tunnel  123.456.78.90 123.456.141.16 metric 1 threshold 8 
boundary CC

# Department of Finding New Ways to Fly
tunnel  123.456.78.90 123.456.186.10 metric 1 threshold 8 
boundary CC
# Department of Having a Look Inside Human Bodies
tunnel  123.456.78.90 123.456.101.182 metric 1 threshold 8 
boundary CC

# University of The Other Side of the City
tunnel  123.456.78.90 123.457.90.90 metric 1 threshold 16 
boundary CC
boundary McGill

# A very collaborative site
tunnel  123.456.78.90 123.456.210.1 metric 1 threshold 16 
boundary CC
boundary McGill

# University of Far To the East
tunnel  123.456.78.90 124.222.4.3 metric 1 threshold 32 boundary Montreal boundary McGill boundary CC

# My Feed from which I get the MBONE Traffic
tunnel  123.456.78.90 130.130.130.130 metric 1 threshold 64 boundary Canada boundary Montreal boundary McGill boundary CC
Figure 10-6: mrouted configuration file with administrative scopes.

To scope a region, all you have to do is put a boundary on every link leaving the region you want to scope. The traffic that will be within the address range of that administrative scope will not be sent onto that link. In Figure 10-6, we can have a look at the tunnel to JVNC. If someone in Canada creates an MBONE session that uses "Canada" for an administrative scope, the address is automatically set by SDR so that it is within the range of addresses for that scope. The traffic of that session is not sent down to JVNC. This is valid in both directions, meaning that the address range that I use for the "Canada" scoped region could be reused elsewhere because it would not be in conflict. However, that address range could only be used outside of Canada. Another example of this address reuse is every other department at my site reusing the same address range that I use for my CC boundary. All I have to do is add a "boundary <department>" argument to the tunnel line for that department. Because the traffic from a department that would have created a session using the scope for their own department does not leave the department, no conflict of addresses occurs and every other departement could have a session local to them using the same address range.

The only problem so far with administrative scopes is that SDR currently has no way to automatically know about the various scoped region names, which have to be configured for each user. This is done with SDR's configuration file. This file lives in your home directory on the UNIX machine and is called .sd.tcl. In this file you have to put a series of commands to tell your SDR that it will now know and care about your local administrative scopes. Here is a sample .sd.tcl file:

add_admin Canada 239.125.255.255 1234 239.125.0.0 16 63
add_admin Montreal 239.124.255.255 1235 239.125.0.0 16 31
add_admin McGill 239.126.255.255 1236 239.126.0.0 16 15
add_admin CC 239.123.255.255 1237 239.123.0.0 16 7
In the preceding example, we can see that the syntax for the add_admin command is

add_admin <scope name> <announcement address> <annoucement port> <scope band base address> <netmask> <ttl>
Where the following conditions apply: The next major release of SDR will include two improvements:

Do not forget that SDR is totally new and the version that is available at this moment is an alpha release (which, nevertheless, is very usable). The author of that application (Mark Handley at UCL) has done a great job, and I am sure that he will give us more things in SDR to amaze us.

Table of Contents | Previous Section | Next Section