The purpose of this application note is to provide the user with the details of how to configure the DACS for voice communications in a multicast networking scenario. Additionally, the user will be instructed about to communicate simultaneously in both unicast, broadcast and/or multicast modes.
First version of Model Builder to support multicast addressing. User can put entity, transmitter and receiver PDUs on a single multicast group and put the signal PDUs on a completely separate multicast group. No IGMP implemented in this version of Model Builder. The absence of IGMP reports means that the DACS will not automatically tell the router that it wishes to join a multicast group. If the DACS is to join a multicast group over a WAN then the system router must be manually configured to permit the DACS to join its multicast group(s). This capability was carried over into the MB4.x series.
Allows the user to split entity, transmitter, receiver and signal PDUs onto four different multicast groups.
Permits the above features and additionally allows the user to join separate multicast groups based on DIS exercise numbers. This version of software also allows the user to communicate over the voice network using both unicast, broadcast and/or multicast addressing schemes simultaneously. First version of Model Builder to support IGMP therefore permitting multicast routing over a WAN.
Class D addresses are reserved for multicast group usage. Multicasting is a way to communicate with more than one host simultaneously. More specifically, multicasting allows a device with no knowledge of the IP addresses of other systems on the network to find all the devices that have some commonality. Obviously the devices being searched for must be configured to listen for multicast datagrams destined for a specific Class D address.
For further reading on networks and addressing schemes we recommend "TCP/IP Addressing" by Buck Graham, published by AP Professional.
Note 1: Any IP addresses in the following sections are for illustration purposes only. The addresses and subnet masks used for your particular network will be determined by your local network administrator.
Note 2: The term "radio" is the only word used below to describe a voice stream. The actual voice stream used could be a DIS radio, a networked intercom object or a signal pdu stream. The term "radio" is used for simplicity.
When using this addressing scheme the entity, signal, transmitter (TXER) and receiver (RXER) PDUs of all valid DIS objects and for all DIS exercise numbers in the model are networked using this multicast group.
Configuration file commands (config file commands are not case sensitive but they are shown here in all caps for illustration purposes):
DIS=ON DIS:BROADCAST_IP=xxx.xxx.xxx.xxx DIS:IGMP=ON DIS:TIME_TO_LIVE=z
If no value is specified, the default is 60.
If no value is specified, the default is 0, disabling multicast operation. Enter a non-zero integer value to enable multicast operation. We have found that a nominal value of 10 works for most situations.
The "Time To Live" (TTL) command determines the number of router hops a particular packet is capable of making. Every time a packet is passed through a router its TTL value is decremented by 1. A TTL value of 0 means that the packet will not be passed by any routers.
The "IGMP Time" refers to the rate at which the DACS publishes it IGMP reports without being queried by a router. An IGMP report is submitted automatically when the DACS starts and joins the network and whenever it is queried by a router. A non-zero value is required to enable multicast operation.
Starting from the main model menu (Models, Cell Interface, Host Interface, DIS network, etc) select "DIS network" then "Status" in order to see the multicast address you have entered in the configuration file. Also under the "DIS network" menu go into "Options" to view the IGMP parameters. If the desired values are not set then check the configuration file for proper syntax or duplicate commands. When Model Builder loads the configuration file commands it will load the last valid command if there are duplicate commands present. For instance if you specify a multicast address and then a broadcast address 2 lines later in the configuration file Model Builder is going to start with the broadcast address.
When using this addressing scheme the entity, signal, transmitter and receiver PDUs of all valid DIS objects and for all DIS exercise numbers are put on separate multicast groups. The user also has the option to put all of the administrative PDUs (entity, TXER, RXER) on one multicast group and all of the signal PDUs on a separate multicast group.
Configuration file commands:
DIS=ON DIS:BROADCAST_IP=www,xxx,yyy,zzz DIS:IGMP=ON DIS:TIME_TO_LIVE=z
If no value is specified, the default is 60.
If no value is specified, the default is 0.
For the "Broadcast IP" command above, www = the address of the multicast group for the entity state PDUs, xxx = the address of the multicast group for the signal PDUs, yyy = the address of the multicast group for the transmitter PDUs and zzz = the address of the multicast group for the receiver PDUs.
If only the www and xxx multicast groups are specified then the transmitter, receiver and entity PDUs are assigned to the first multicast group and the signal PDUs are assigned to the second multicast group.
When using this addressing scheme the "Broadcast IP" addresses specified in the configuration file provide the base addresses for the system for all the radios participating in DIS exercise #1. Additional multicast groups are automatically joined based on the subsequent DIS exercise numbers used in the model.
For example if 220.127.116.11 is the base multicasting address for DIS exercise 1, then 18.104.22.168 is the multicast group joined by all radios having a DIS exercise number of 2. This pattern continues until all valid DIS exercise numbers, 1 through 255, have been used. Model Builder searches through the list of active DIS objects and makes the assignments to the various multicast groups automatically.
If non-sequential DIS exercise numbers are used then the multicast group corresponding to that number is not joined. For example if the base address is 22.214.171.124 and exercises 1, 2 and 4 are used then multicast groups 126.96.36.199, 188.8.131.52 and 184.108.40.206 would be joined.
DIS=ON DIS:BROADCAST_IP=www DIS:IGMP=ON DIS:MULTICAST=EXERCISE DIS:TIME_TO_LIVE=z
If no value is specified, the default is 60.
If no value is specified, the default is 0. NOTE: To avoid potential network difficulties it is recommended to have the DIS exercise numbers remain static throughout the course of a given training scenario or exercise. If the DIS exercise numbers for a radio object are changed during the course of an exercise, an IGMP report will be published to put the radio on the new multicast group. The potential exists that the radio will be displayed on the new and original multicast groups until the DIS and/or IGMP report times have passed and the object identifier times out and is removed from the original group.
The above commands put all of the DIS PDUs for that exercise on a single multicast group. In order to put the DIS PDUs on separate groups and join multicast groups based on DIS exercise numbers all you have to do is add the base addresses for the signal, TXER and RXER multicast groups to the the "Broadcast IP" address as shown below:
DIS=ON DIS:BROADCAST_IP=www,xxx,yyy,zzz DIS:IGMP=ON DIS:MULTICAST=EXERCISE DIS:TIME_TO_LIVE=z DIS:IGMP_TIME=y
Where www,xxx,yyy,zzz are the base multicast addresses for the entity, signal, transmitter and receiver PDUs respectively.
The DACS and Model Builder can be used to limit the amount of traffic that would be put out over a wide area network. This is useful if you have a facility with several systems and not all of the voice traffic needs to go out over the WAN. Voice traffic can consume quite a bit of bandwidth (64 Kbits/sec per mulaw or 16 Kbits/sec per CVSD voice stream) and unecessary voice streams on a WAN could cause potential bottlenecking problems.
The idea is really quite simple, voice streams passed through the router onto the WAN will have DIS exercise numbers corresponding to multicast groups that are in use all across the WAN. For local voice traffic multicast groups are formed locally but no IGMP reports are submitted to the router for these groups, therefore they never get passed through. The DACS on the local network however can process these packets and permit voice communications.
The DIS exercise number is used as a discriminator to determine if voice is passed over the WAN. For radios having DIS exercise numbers below the cutoff point, IGMP reports are submitted, for radios having DIS exercise numbers above the cutoff point no IGMP reports are published.
or just www as the address
DIS:IGMP=ON DIS:MULTICAST=EXERCISE DIS:IGMP_LAST_EXERCISE=s
Exercise #s above "s" will not have IGMP reports submitted
For example, I have 2 sets of wide area networked communications objects and 2 sets of locally networked communications objects. My wide area networked comm objects would have DIS exercise numbers of 1 and 2, my other two sets of comm objects would have DIS exercise numbers of 3 and 4 and I would use the config file command: "DIS:IGMP_LAST_EXERCISE=2".
When using this addressing scheme voice traffic is put on the network using broadcast, unicast and/or multicast addressing modes. The DIS exercise number is used as a discriminator to determine which voice streams belong to which addressing type. The first address in the configuration file command line could be unicast, broadcast or multicast. The "IGMP First Exercise" command is used as the cutoff point for the first addressing type and for the start of multicasting.
DIS=ON DIS:BROADCAST_IP=220.127.116.11,18.104.22.168 DIS:IGMP=ON DIS:MULTICAST=EXERCISE DIS:IGMP_FIRST_EXERCISE=3 DIS:TIME_TO_LIVE=40 DIS:IGMP_TIME=10
In the above example for radios having DIS exercise numbers 1, 2 and 3 their voice traffic will go out over the broadcast address of 22.214.171.124. For radios having DIS exercise numbers 4 and higher their voice traffic will join multicast groups based on their DIS exercise numbers starting with the base address of 126.96.36.199. DIS exercise 4 would go on multicast group 188.8.131.52, #5 on 184.108.40.206, and so on.
The multicast addressing scheme could be further expanded by putting the signal, transmitter and receiver PDUs on separate multicast groups. Since the DACS processes but does not generate entity state PDUs they will always be associated with the first address.
Again, the first address group could be unicast, broadcast or multicast. The user can lump a group of voice streams onto this address based on their DIS exercise numbers. This greatly increases the flexibility of the system.
In short, broadcast, unicast or multicast for the first 1 through X DIS exercise numbers, IGMP supported multicasting for X+1 through Y DIS exercise numbers, and non IGMP supported multicasting for Y+1 through 255 DIS exercise numbers.
(See Note 1 below)
DIS:IGMP=ON DIS:MULTICAST=EXERCISE DIS:IGMP_FIRST_EXERCISE=3 DIS:IGMP_LAST_EXERCISE=12 DIS:TIME_TO_LIVE=40 DIS:IGMP_TIME=10
In the above example for radios having DIS exercise numbers 1, 2 and 3 their voice traffic will go out over the broadcast address of 220.127.116.11. For radios having DIS exercise numbers 4 through 12 their voice traffic will join multicast groups based on their DIS exercise numbers starting with the base address of 18.104.22.168. DIS exercise 4 would go on multicast group 22.214.171.124, #5 on 126.96.36.199, and so on. For voice streams having DIS exercise numbers of 13 and higher they will still join multicast groups based on their DIS exercise numbers they will just have their IGMP functions disabled.
Disabling the IGMP for these voice streams means that they won't be passed by a router and can remain on the local network. Even though IGMP has been disabled, other DACS on the local network can still communicate on these multicast groups.
Note: If the base address (188.8.131.52 above) is not a multicast address you will have to individually specify the multicast groups for the txer and rxer signal PDUs, otherwise they will be associated with the non-multicasted base address. The txer and rxer PDUs could be put on separate multicast groups if desired.
For the above example if you wanted a broadcast base address and a single multicast address for the txer, rxer and signal PDUs then the address command would be: