HSC welcomes all external visitors to this site, especially students and members of the academic community. Please use the comments box at the bottom of each page to record any comments or suggestions for improvement.

Introduction

There are three fundamental types of IPv4 addresses: unicast, broadcast, and multicast. A unicast address is designed to transmit a packet to a single destination. A broadcast address is used to send a datagram to an entire sub network. A multicast address is used to enable the delivery of datagram to only those set of hosts that have announced that they want to receive multicast from a particular multicast group identified by the multicast address. The interested hosts or members of a multicast group may be a part of various scattered sub networks. Applications that take advantage of multicast include video conferencing, corporate communications, distance learning, distribution of software, stock quotes, and news.

IP Multicast Overview

Traditional IP communication allows a host to send packets to a single host (unicast transmission) or to all hosts of a subnet (broadcast transmission). IP multicasting falls between IP unicast and IP broadcast communication and enables a host to send IP packets to a group of hosts anywhere within the IP network. The group is identified by a special form of IP address called an IP multicast group address (the IPv4 Class D address i.e. from 224.0.0.0 through 239.255.255.255).This is used as the destination address in a packet of IP multicast stream

IP multicast is a bandwidth-conserving technology that reduces traffic by simultaneously delivering a single stream of information to potentially thousands of corporate recipients and homes. IP multicast delivers application source traffic to multiple receivers without burdening the source or the receivers while using a minimum of network bandwidth. Multicast packets are replicated in the network at the point where paths diverge by routers, resulting in the most efficient delivery of data to multiple receivers.

With multicast, however, it is necessary to advise the IP stack which multicast groups a host is interested in. That is, the host has to "join" those multicast groups. Depending on the underlying hardware, multicast datagram are filtered by the hardware or by the IP layer (and, in some cases, by both). Only those with a destination group previously registered via a join are accepted.

Înter%

In the example shown in Figure 1

1. The receivers are interested in receiving different data stream from the source. As shown R(1), R(4) & R(5) interested in A packets and R(2) & R(3) in B packets.
2. The receivers indicate their interest by sending an Internet Group Management Protocol (IGMP) host report to the routers in the network.
3. Adjacent routers also use this protocol to communicate with upper layer and process continues up to Source.
4. The routers are then responsible for delivering the data from the source to the receivers. The routers use Protocol Independent Multicast (PIM) to dynamically create a multicast distribution tree.
5. The data stream will then be delivered only to the network segments that are in the path between the source and the receivers as shown in Figure 2.

Înter%

In the example shown in Figure 2

1. Source multicast 3 types of packets (A, B, C).
2. At very first network segment, there are members for A & B packets. Thus C packets discards & packet B multicast towards next layer. But packet A replicated & then multicast to both branch of network.
3. Receivers receive only packets in which they are interested.

Need for Reliability

As we see Multicast was developed as an efficient method of data delivery over an IP packet-switched network that allows a server to send a single data stream to a local multicast-capable router that then redistributes it to other local hosts. In multicast, each packet is sent from one sender to multiple receivers with a single "transmit" operation which helps in reducing bandwidth usage. But the basic service provided by IP multicast is an unreliable datagram multicast service. Thus Multicasting is not connection oriented. A multicast datagram is delivered to destination group members with the same best-effort reliability as a standard unicast IP datagram. This means that a multicast datagram is not guaranteed to reach all members of the group, or arrive in the same order relative to the transmission of other packets. UDP is the transport mechanism generally used by the multicasting services which does not allow for reliable data transmission. Since there is no acknowledgement mechanism between the sender and the receiver in UDP, there is no recovery mechanism for lost packets. While this approach is useful for one-way broadcasts such as video or voice streaming, it does not allow for the deployment of applications such as interactive multimedia or software distribution, both of which require a reliable transport mechanism to ensure that packets are properly delivered. The biggest issue in delivering reliable IP multicast is where exactly the retransmissions should occur. Obviously, each multicast receiver can't communicate directly with the source of the multicast transmission, since a potential of hundreds or even thousands of connections would overwhelm the ability of the sender to manage them.

Criteria for Reliable Protocols

Given below are the characteristics which make a protocol reliable for data delievery: - Loss should be detected & repair in finite time. - Data should be free of error. - All packets delivered in source order. If not its responsibility of receiver to display it in order. - Proper utilization of network. There should not useless packets in network. - Packets are safely deleted with in finite time (source memory should be properly utilized).

Different Reliable Multicast protocols

A number of protocols either exist or are under development to enable reliable transport of IP Multicast traffic. Three popular solutions have been discussed below although none of them have been physically deployed in real networks. Scalable Reliable Multicast Reliable Multicast Transport Protocol Pragmatic General Multicast

Scalable Reliable Multicast

Scalable Reliable Multicast (SRM) is a reliable multicast framework for application level framing and light-weight sessions. The algorithms of this framework can be summarized by describing the three types of packets: heartbeats, NACKs and repairs.

Înter%

1. Each member periodically sends out a heartbeat including the sequence number of the latest sent packet (as shown in figure 3). These heartbeats are used by the other members to detect packet loss by comparing the sequence number in the heartbeat and the sequence number of the last data-packet received.
2. When a packet is lost, a negative acknowledgment (NACK) is sent to all members using the same method of transportation as the original data. In figure 3 receiver at middle send NACKs on detection of loss. NACKS are indicated by red arrows. As all members see these NACKs, everyone can participate in the repair of the traffic. This is important because it lessens the burden on the original sender and makes the repair process faster if the distance between the NACK sender and the original sender is large.
3. Each member of the session cache the latest data-packets received (and sent) and if they see a NACK for a packet they have in their cache, they retransmit that packet to the whole group as a repair(show by green arrow in figure 3).

To minimize the number of NACKs and repairs, these two operations are preceded by exponential back-off. This means that instead of sending the packet directly, the client waits for a random time (based on the distance to the related other party) and if another client sends a corresponding packet it withdraws its own potential transmission.

Reliable Multicast Transport Protocol

RMTP is a reliable multicast transport protocol for the Internet. RMTP provides sequenced, lossless delivery of a data stream from one sender to a group of receivers. RMTP is based on a multi-level hierarchical approach, in which the receivers are grouped into a hierarchy of local regions, with a Designated Receiver (DR) in each local region. Înter%

1. Receivers in each local region periodically send acknowledgments (ACKs) to their corresponding DR (shown in figure 4).
2. DRs send ACKs to the higher-level DRs,
3. Until the DRs in the highest level send ACKs to the sender, thereby avoiding the ACK-implosion problem.
4. DRs cache received data and respond to retransmission requests of the receivers in their corresponding local regions. If there is no acknowledgement DR retransmit the packet (shown by red arrow), thereby decreasing end-to-end latency. RMTP uses a packet-based selective repeat retransmission scheme for higher throughput.

Pragmatic General Multicast (RFC 3208)

PGM guarantees that a receiver in the group either receives all data packets from transmissions and repairs, or is able to detect unrecoverable data packet loss. For that purpose PGM defines four basic packet types: three that flow downstream (SPMs, DATA, NCFs), and one that flows upstream (NAKs). Source Path massage (SPM) have two functions, first establish source path state PGM network elements & they provoke prompt detection of missing packets in the absence of data to transmit. Figure 5 shows the sequence in a NAK/NCF scenario. Recall that all multicasts originating from PGM NEs are generated as if they originated from the sender, so that the non-PGM routers will forward them on the same multicast tree used for multicast data coming from the sender. Înter%

This scenario begins when the receiver on the far left detects a loss and

1. Unicasts a NAK to its PGM parent.
2. Its PGM parent router multicasts a NAK confirmation, suppressing any NAKs that the other receivers might have generated for that packet.
3. The router now unicasts a NAK to its parent
4. Who multicasts an NCF. Note that this NCF is not forwarded by the downstream PGM nodes. The PGM router on the right will store the NCF for future reference.
5. A unicast NAK is then sent to the sender,
6. Who responds with a multicast NCF (again, not forwarded by downstream PGM routers).
7. At a later time, another receiver detects the loss of the same packet and unicasts a NAK to its PGM parent, who multicasts an NCF
8. The parent does not send an upstream NAK, as it has already noted the reception of the corresponding NCF (NAK anticipation).
9. Repair will multicast to the same network.

Network elements do not attempt to ensure that RDATA is received in response to a NAK. It is up to receivers to re-issue the NAK. When repairs are sent, PGM NEs will only forward them on interfaces for which they have received a NAK corresponding to the repair. Thus, repairs are only forwarded to sub-trees containing receivers who need the repair. Note that PGMs scheme of propagating NAKs upstream follows the same sequence of PGM networks on which the ODATA was forwarded, but in reverse. This allows the appropriate NAK state to be established in the NEs to support constrained forwarding. SPMs, NCFs, and RDATA require special treatment by PGM network elements. An obvious way to discover these packets is to examine every packet in the network for the PGM transport protocol and packet types. However, the burden on the NE of examining every packet is prohibitive. Instead, SPMs, NCFs, and RDATA are transmitted with the IP router alert option. This option gives network elements a network-layer indication that a packet should be extracted from IP switching for more detailed processing. Original data packets are forwarded just as any other IP multicast packets would be, without any special router attention.

Categories: Broadband

Comments

Add Comment
Email address(will be kept hidden)
Enter code: