Multicast is UDP-based best effort delivery: Drops are to be expected. Multicast application must not expect reliable delivery of data and should be designed accordingly. Reliable multicast applications will address this issue.
No congestion avoidance: The lack of the TCP windowing and "slow-start" mechanisms can result in network congestion. If possible, multicast applications should attempt to detect and avoid congestion conditions.
Duplicates: some multicast protocol mechanisms result in the occasional generation of duplicate packets. Multicast applications should be designed to expect occasional duplicate packets.
Out of sequence delivery: Network topology changes affect the order of delivery the application must properly address the issue.
Now we completed, Multicast advantages and disadvantages. It will help you to decide, will it be beneficial for your company requirements.
For our opinion;
Multicasting is more efficient means, delivering of content where a single sender needs to deliver the content to multiple receivers. This task may be achieved through the use of multicast groups.
3. Multicast Routing
The main tasks of multicast support in the network layer can be found in the following aspects:
■ Route exchange
■ Group dynamics
■ Multicast address allocation
Data is not forwarded to individual receivers in a network but to a group of receivers. This requires multicast trees to be set up within the network. New routing algorithms and, consequently, new routing protocols are needed.
This chapter will briefly present some basics about routing algorithms using examples from point-to-point communication. Then group dynamics and tree construction on the Internet is introduced, since they serve as the basis for many of the approaches to multicast routing discussed. A discussion of scoping and multicast address allocation follows that introduces the basic problems and concepts. The main part of the chapter focuses on basic concepts related to multicast routing and presents examples of current multicast routing protocols.
3.1. Group Dynamics
Suitable mechanisms to deal with group dynamics are required for the support of group communication. They should define how to join or leave groups and provide information about existing groups.
IGMP The Internet Group Management Protocol (IGMP) was introduced for group management within subnetworks or edge networks. The current version is IGMP version 2 (IGMPv2) . Similar to the Internet Control Message Protocol (ICMP) required for error control, IGMP is an integral part of IP It has to be implemented and provided with IP if IP multicast is to be supported.
IGMP provides the following operations for joining and leaving groups on the Internet. It distinguishes between queries and reports:
■ General membership query
■ Group-specific membership query
■ Version 2 membership report
■ Version 1 membership report
■ Leave group
General membership queries are used to obtain information about groups that have members in an attached subnetwork. The operation group-specific membership queries checks whether a specific group has members in a subnetwork. Membership queries are sent periodically from the Querier router (see below) to the group of all end systems (all host groups).
Membership reports inform multicast routers of new group mem-berships. End systems reply with a membership report to a member-ship query issued by a multicast router. The multicast router then records this information about group membership and sets the group membership timer to the group membership interval. This value cor-responds to the time that must pass before a multicast router decides that a group does not have any members left in the subnetwork. The default value for this interval is set to 260 seconds.
Note that routers are only interested in whether a group has members or not. They need this information only for the binary decision to forward data belonging to that group into the subnetwork or not. The individ-ual members themselves are not of interest. A membership report should further be sent by an end system immediately after a group has been joined. The version 1 membership report is included in order to provide backward compatibility with version 1 of IGMP. Version 1 membership reports do not carry a field for the maximum response time.
Leave group signals that a group membership has been finished. This operation was not available with IGMP version 1. However, it is essential in order to improve the efficiency of group membership ter-mination. As indicated previously, the corresponding timeout value is set to 260 seconds by default. Improving leave efficiency is important for highly dynamic groups.
The format of IGMP data units. The key components are the group address and the checksum. The type field is used to identify a transmitted IGMP data unit. The following type values are defined: 0x11 for membership queries, 0x16 for version 2 membership reports, 0x12 for version 1 membership reports, and 0x17 for leave group. General and group-specific membership queries are further distinguished by the group address. The field for the maximum response time is only important with membership queries. It controls the time interval that can pass before the membership report is to be sent. After having received a membership query, a timer is associated with either the specific group or each group the end system participates in. The timer value is randomly selected in the interval (0, maximum response time], where maximum response time corresponds to the value received in the query. In a default value of 10 seconds is recommended for the maximum response time. If the timer expires, the end system transmits a membership report. If it receives such a membership report from a different end system in the subnetwork, it IGMP data units.
Figure 2: IGMP Data Unit
Stops the timer and does not issue a membership report. This avoids duplicate reports on a subnetwork. The use of the maximum response time allows a regulation of the leave latency (i.e., the time between the last member leaving the group and the routing protocol being in-formed about this fact). It is an improvement of IGMPv2 compared to IGMPv1. Furthermore, the maximum response time can help to re-duce the burstiness of IGMP traffic.
IGMP data units are encapsulated into IP datagrams during trans-mission. In this sense, IGMP is logically located above the IP protocol. All IGMP data units are sent with a TTL (time to live) of one, which means they do not leave the local subnetwork. Membership in a group is therefore only available to local IGMP routers. Multicast routing protocols have responsibility for the further distribution of membership information in the network.
With IGMP, a multicast router can have two states:
■ Querier
■ Non-Querier
Normally, only a single multicast router in the network is in the Querier Querier state. The Querier has the task of periodically querying for group members in the network. During initialization, all multicast routers assume that they are Queriers. Ultimately, the one with the lowest IP address is the one selected as the actual Querier. Therefore, if a multicast router receives a query from a router with a lower IP address, it changes from the state of Querier to the state of non-Querier.
Non-Querier If a router is in the non-Querier state, it does not issue periodic queries . However, a non-Querier receives IGMP reports sent on the subnetwork and analyzes them.
If the Querier router fails, no further periodic queries are issued on the corresponding subnetwork. This situation is detected by the non- Queriers present on the subnetwork. If a non-Querier did not receive a membership query on the network for a certain time interval (derived from the Querier present time), it sends a general query and changes its state from non-Querier to Querier. A default value of 255 seconds is suggested for that timer .
If the Querier receives a response to its query, it keeps the group membership in its database and sets a timer with a calculated default value of 260 seconds. This timer has a great influence on the leave latency. Database entries can be updated by end systems through periodic transmissions of reports. In case of a time-out, the router as-sumes that no group exists locally and, consequently, deletes the entry. It therefore does not forward any multicast data units for this group over the corresponding interface.
Figure 3: IGMP Response
When they leave a group, end systems can send leave data units to the multicast routers. Before deleting the entry, however, the router should send another query to the network to determine whether any other members are still active. If this is not the case, the entry is deleted and the forwarding of corresponding data units is stopped.
Routers send general membership queries relatively infrequently. In RFC 2236, it is recommended that the queries be repeated every 125 seconds. End systems can send reports even if they have not received a direct query, in order to accelerate their acceptance in a group or to signal their entry to a group in the network.
The concept for group management used by IGMP cannot guarantee that all group members are known. An end system can receive data that has been sent to a group address without responding to general membership queries if, for example, another end system in the same subnetwork also belongs to this group. The other group members will not be aware that such an end system is receiving the data being sent to the group. Thus no known groups can be implemented with IGMP alone because, in principle, undetected eavesdropping by others is possible. Additional effort is needed at the application level to implement and ensure known groups.
Nodes with IGMPv1 and IGMPv2 may operate concurrently within a subnetwork. The following rules need to be applied: IGMPv2 may run on end systems within a subnetwork, although the Querier router has not yet been updated with IGMPv2. In this case, the end system with IGMPv2 needs to send version 1 membership reports since version 2 membership reports are not understood by the Querier router. Furthermore, the IGMPv1 router will send general queries with the maximum response time set to zero. This must be interpreted as a value of 10 seconds by the IGMPv2 end system. The end system therefore needs to keep track of whether it is interacting with an IGMPv1 or an IGMPv2 Querier router. If a router in the subnetwork still runs IGMPv1, then the Querier router is obliged to run IGMPv1. This needs to be configured manually. No automatic procedure is available until all end systems in a subnetwork are upgraded to IGMPv2, those end systems that are already upgraded must be able to suppress their membership reports by either a version 1 membership report or a version 2