Internet Multicasting

As mentioned in Section , multicasting is essential to many multimedia applications. Therefore, in the sense of an integrated services model, QoS reservations and predictions, flow control, network management, addressing, and routing must be designed to support multicasting.

This section will examine several multicast techniques developed for IP networks. Other multicast-capable network or transport protocols, such as ST-II, XTP, or VTMP, that do not use IPv4, are not covered here.

IP Multicasting

   IP multicasting is defined in [RFC1112] as an extension to the standard network-layer IP protocol.

Multicast host groups are identified by means of   Class D addresses. Potential Class D addresses range from 224.0.0.0 to 239.255.255.255. They can be used as destination addresses only.
A host group may either be permanent or transient. Permanent groups have well-known, administratively assigned IP addresses.

IP multicasting relies on external address and group management protocols to inform hosts about multicast group addresses and control membership access.
The     Internet Group Management Protocol (IGMP), as defined in [RFC1112], is used by IP hosts to report their group memberships to any immediately-neighbouring multicast(-capable) router. A host sends an IGMP group membership report message to a neighbouring router whenever it joins or leaves a multicast host group, or whenever it receives a query message, which is periodically sent by the router.

IP multicast routing uses modified distance vector protocols to construct a spanning tree per group that covers all member hosts of the group.

Because TCP is only compatible with point-to-point connections and UDP offers no flow control or error correction mechanisms, other multicast-capable transport protocols must be used on top of IP multicasting.

Multicast Transport Protocol---MTP

    MTP [RFC1301] is designed to be an efficient and reliable multicast transport-layer protocol that could be used on top of network-layer protocols such as IP multicasting. MTP leaves the allocation or dissemination of group addresses up to entities, which are not part of MTP itself.

A set of communicating processes, called a web, is governed by a principal member, called the master. The master controls the web's membership and operational parameters, which include rudimentary resource reservations. New members must register with the master for group membership, thereby requesting certain resources such as minimum bandwidth.

To synchronise the reception order of messages in the web, the master hands out transmit tokens to members who wish to send data.

To reduce control overhead, error recovery is implemented by a negative-acknowledgement (NAK) based selective-retransmission scheme. Nevertheless, the amount of overhead, especially the one generated by the ordering mechanism, might prove troublesome, because almost all control traffic passes by the master, which could turn out to become a bottleneck.

MGA, RAMP, MRP

Braudes and Zabale [RFC1458] analyse different multicast protocols, and propose a new protocol suite, which tries to eliminate the deficiencies of existing protocols.
This protocol set is designed to fit into the Integrated Services Architecture, and to take advantage of the information transmitted by reservation systems such as RSVP. The integrated protocol set comprises three cooperating components:

• Multicast Group Authority (MGA).
     The MGA manages the multicast address space (the Class D addresses), registers services and their QoS state, and controls group membership.
  The MGA is structured hierarchical, like the Domain Name System. Service requests are first made to a local agent, which may propagate the requests upwards in the hierarchy if necessary.
• Reliable, Adaptive Multicast Protocol (RAMP).
      RAMP is transport-layer protocol, which offers reliable as well as unreliable multicast service, using a network-layer protocol such as IP multicasting.
  Error recovery is done by a NAK-based selective-retransmission scheme. A retransmission of a packet set is performed by means of multicasting if a certain threshold of NAK messages for that set is exceeded; otherwise the packets to be retransmitted are sent by unicast, thereby seeking a compromise between unicast and multicast retransmission.
  Flow control is achieved by means of a rate-based approach.
• Modified Routing Protocol (MRP).
      MRP must be integrated into routers similar to IGMP. The tasks of MRP are path set-up, path tear-down, forwarding based on QoS values, and prioritised packet loss due to congestion.
  When making a routing decision, MRP considers not only the destination address in a packet---as conventional routing algorithms do---but also ensures that the QoS level offered by a possible path matches the level that is requested for a particular packet.

Multicast Backbone---MBone

   MBone facilitates the worldwide broadcasting of digital audio and video, such as the live transmission of meetings of the Internet Engineering Task Force (IETF).
It is a virtual overlay network imposed on the Internet: MBone consists of multicast-capable islands each containing one or more   multicast routers (mrouters), which connect the islands logically by tunnels.
MBone packets are encapsulated in normal IP packets, which are sent as regular unicast packets from mrouter to mrouter. This encapsulation is necessary as long as not all routers on the way between two mrouters support multicasting. The tunnels are set up manually by configuring the tables of the mrouters.

The scope of multicast message is limited by the  IP time-to-live (TTL) field, which is decremented by the weight that is assigned to every passed tunnel.

MBone multicasting utilises Class D IP addresses to identify multicast host groups, and the IGMP protocol to report group membership inside an island. Initially, the DVMRP protocol was used between mrouters. Newer research work proposes the   Multicasting OSPF (MOSPF) [RFC1584] or   Protocol Independent Multicast (PIM) [Hui95] protocols, which try to improve MBone routing.