ActionScripting in Flash MX

4.1 Multicast application and routing concepts

Before launching into detail about various protocols of importance in multicasting, we need to review some of the key application and technology issues.

4.1.1 Multicast groups

A fundamental part of multicast support is the concept of a multicast group. A multicast group is a logical association of senders and receivers, usually related by application. Groups are usually formed dynamically; receivers request to join or leave a group at will, although statically configured membership is also possible. If there is only one sender, the group is called a point-to-multipoint group. If there are multiple senders, the group is called a multipoint-to-multipoint group. In the IP world a multicast group is associated with a specific class D IPv4 address—for example, 224.0.0.5 is the multicast group used by OSPF routers on which to send hello messages on multiaccess networks. Some of the more important (for this chapter) well-known addresses designated by IANA include the following:

Transient addresses, which may be assigned and reclaimed dynamically, include the following:

4.1.2 Mapping multicasts onto MAC addresses

We learned in Chapter 2 that IPv4 multicasts use the class D address format (with 1110 as the high-order bits and the remaining 28 bits made available for the group address). Reference [3] discusses how IP multicast addresses get mapped onto MAC addresses prior to forwarding on the wire. To recap:

4.1.3 Multicast application models

It is important to understand from the outset that multicasting is inappropriate for most traditional applications. The types of application best suited for multicast distribution are generally characterized by a high degree of asymmetry, the need to send the same information to many receivers simultaneously, and typically (though not always) some real-time constraint. Applications in this class include live market data feeds, videoconferencing, audioconferencing, push applications, streaming media, interactive whiteboards, database replication, corporate communications, data warehousing, distributed computation, real-time workgroups, and interactive distance learning. This does not preclude other specialized application types from the benefits of multicasting—for example, applications that synchronize information among multiple nodes or attempt to discover services are likely to benefit from multicasting (in fact the latest generation of routing protocols such as OSPF have made good use of multicasting for some time). For applications suitable for multicasting there are essentially two data distribution models of interest, as follows:

To date, most networked applications have relied almost exclusively on unicast or broadcast delivery mechanisms, with multicasting limited to specialized applications such as routing or control protocols. For certain types of user applications (e.g., market data feeds, multiuser videoconferences, and interactive distance learning) this is a particularly inefficient way to distribute information. These applications have a significant feature in common: large amounts of identical data being sent to many receivers simultaneously. Unicast and broadcast models can be described as follows:

Both unicast and broadcast mechanisms place increasing load on device CPUs and the network as the number of group members increases. Unicast distribution also requires the server to maintain session states for each individual receiver. Neither of these approaches can scale. In contrast, multicasts are handled differently by the receiver's NIC; a receiving station can be a member of one or more multicast groups, and the NIC can discard any frames not destined for those groups (typically using a high-speed hash function) without interrupting the CPU. Another advantage from the network designer's perspective is that multicasts can be filtered if required, since they can be differentiated from background broadcast traffic. This might be appropriate for additional traffic management purposes or for security (security policies could be applied on devices such as firewalls).

4.1.4 Multicast application design guidelines

Reference [4] describes the host requirements for supporting IP multicast and the default behavioral characteristics of multicast applications, as follows:

Reference [4] recommends a number of API functions for configuring multicast support. These include the ability to join or leave a multicast group, set the Time to Live (TTL), define local interfaces for multicast transmission or reception, and disable loopback of outgoing multicast datagrams. All of the APIs discussed in the following section support these functions as a minimum.

IP multicast APIs

Most of the major TCP/IP host implementations now offer multicast support, either integrated directly into the OS or via system patches. These implementations also typically support IGMP [4]. The three best-known APIs for UNIX, Windows, and Apple MAC operating systems are as follows (as one would expect, these APIs offer broadly the same functionality).

To meet the requirements set out in [4], basic support for multicasting involves the addition of five new socket options. The Berkeley Socket Multicast API specifies two sets of functions with the prefix IP_ or IPV6_ for IPv4 and IPv6, respectively, as follows:

For further information on these APIs, the interested reader should refer to references [4–11].

Enabling legacy unicast applications for IP multicast

Converting an existing application to use a multicast distribution model can be relatively straightforward. The key issue is whether the application relies on a connection-oriented transport protocol (e.g., TCP) or a datagram-based transport protocol (e.g., UDP). These protocols can be described as follows:

Design and implementation issues

While multicast applications can be very efficient in bandwidth utilization, they can get out of hand without some constraint in their implementation and delivery mechanisms. In particular, developers of multicast applications should aim for the following goals:

In a small number of cases, the assignment of one or more permanent IP multicast addresses is warranted for multicast service. For example, standardized (well-known) applications and content providers with constant media streams may justify permanent multicast addresses. Permanent address and port number allocation falls under the control of the IANA [2]. In most cases addresses must be allocated from the available pool of free addresses, and on a large public internetwork there is no foolproof way for an application to select unique addressing parameters, since, by their very nature, multicast service and membership are dynamic. Strategies such as listening on an address for traffic or querying IGMP devices for membership information are, therefore, likely to fail. What is required is a coordinated approach based on a single or shared directory. Note that the MBone makes use of an application called Session Directory (SD), described in section 4.7.2, which resolves the problems of application conflicts.

4.1.5 Deployment issues on local and wide area networks

Local area deployment issues

On a multiaccess LAN, multicasting is relatively easy to implement, since IEEE 802 and other LAN protocols already provide for multicasting at the MAC layer. However, one of the main problems with real network topologies is multicast leakage—specifically, how to stop multicasts from flooding the wire once the multicast frame gets beyond a Layer 3 device. For example, many LANs employ multiport repeaters or multiport switches to collapse parts of the local area backbone for device concentration. If multicast routers are interconnected via such devices, then these concentrators will, by default, inject multicasts into all interfaces (other than the receive interface), whether there are group members attached or otherwise (see Figure 4.1). In this figure, Switch-1 receives incoming multicast packets, which it forwards (as expected) to all interfaces other than the receiving interface. Unfortunately, in this case only two users are interested in receiving these multicasts (situated on Net-1 and Net-3). The server farm and the bridged LAN (Net-4) are also affected unnecessarily. This problem exists regardless of whether or not VLANs are deployed [3]).

Figure 4.1: Multicast leaking in a flattened LAN environment.

Without careful monitoring you might inadvertently be flooding multicasts and wasting valuable bandwidth on parts of the network that should never see this traffic. There are several ways to resolve such problems, including the following:

It is fair to say that network designers often overlook the deployment of IP multicast applications when the initial design is proposed, which in many cases is understandable. Furthermore, if you have flattened your original network with switches in key areas to take advantage of performance benefits, then this can lead to some nasty surprises when IP multicasting is subsequently enabled. Unfortunately, shared hubs and switches that don't constrain multicast flooding will need to be replaced.

Wide area deployment issues

On wide area networks, and especially on NonBroadcast MultiAccess (NBMA) networks, multicasting can be much more difficult to implement, because the wide area is often characterized by point-to-point links and circuits, as illustrated in Figure 4.2. A new approach to information distribution is required, and this has led to a new generation of multicast protocols specifically geared toward efficient information delivery across wide area internetworks. As we can see in Figure 4.2, the network comprises a number of point-to-point links and a wide area mesh network between routers. Each router attaches one or more LANs. There are several problems to resolve to provide efficient multicast delivery. How does the server know which LANs are used to attach group (G) members? How do group members register for service? What topology should be used to avoid replication? These are just some of the problems that multicast routing protocols have to resolve.

Figure 4.2: Example internetwork topology required to support multicasting.

For maximum efficiency we ideally want to send a multicast packet exactly once on each link. The topology formed is a shortest path tree, with the sender at its source. We refer to this as a multicast tree, illustrated in Figure 4.3. As indicated earlier, for a network supporting different multicast groups there are likely to be many logical Spanning Tree distribution topologies at any particular time. In Figure 4.3, note that several networks have been pruned from the tree, since they do not currently have group members. Note also that Net 5 has two possible router interfaces and so R4 has been pruned back automatically, with R5 elected as the designated forwarder (avoiding packet replication on Net 5).

Figure 4.3: Multicast Spanning Tree, rooted at S, for the example network shown in Figure 4.2.

Given that these topologies can vary over time as group membership shifts, one can imagine that there are some interesting problems to resolve. Several of these problems are summarized as follows, and this chapter attempts to resolve these and other related questions via a number of protocols and algorithms.

With IP multicasting it is important to recognize that the sender and receiver are decoupled, treated as two separate entities within a multicast group, for a reason. The sender need not know the physical location or address of a receiver; it uses the multicast address as a Rendezvous Point (RP) so that the two parties can communicate. Receivers must join the RP-rooted tree, and senders must register their existence with the RP. In this way the sender is insulated from the recipients, relying upon the network to take care of multicast distribution. Note that the term rendezvous point used in this context is purely an abstraction; some routing protocols implement a physical entity (typically software running on a router) called the rendezvous point to act as an intermediary between senders and recipients.

4.1.6 Common multicast techniques

Multicasting in a wide area network introduces some particular complexities. There are potentially a large number of receivers and many sources. Sources and receivers may join or leave groups even while multicast distribution is in progress. This requires that the multicast trees must be dynamically updated to reflect current status. In multiaccess LANs (such as Ethernet or FDDI) another problem is introduced. If we have multiple access points to these LANs, say via multiple routers (as illustrated in the case of Network-5 in Figure 4.2), then we could end up forwarding duplicate multicasts to each LAN. We need to exploit the broadcast nature of such networks and ensure that only one multicast is forwarded.

If a multicast is to be forwarded to receivers over multiple router hops, then we could simply flood all multicasts throughout the network to ensure that all receivers get the data. For a single application with a well-distributed set of receivers this would work, but for a network supporting several multicast applications and a diverse population of receivers this cannot scale and is potentially highly inefficient (many segments will be receiving unwanted multicasts, which simply wastes bandwidth). Flooding runs the risk of excessive packet replication. We could avoid this by maintaining state information at each router indicating which multicasts have already been forwarded, but this is not very attractive. A better mechanism is, therefore, required for receivers to inform individual routers as to which multicasts they are interested in receiving and how to avoid duplicates.

Reverse Path Forwarding (RPF)

One simple technique for flooding multicasts intelligently is referred to as reverse path forwarding (sometimes called reverse path multicasting). With this technique a router will forward a packet from a source, S, to all its interfaces, if, and only if, the packet arrives on an interface that corresponds to the router's shortest path tree to S. An interface that passes this check is called the RPF interface. An RPF lookup for a source returns the RPF interface and the next-hop information. Packets that are received on interfaces that are not in the Spanning Tree for a particular multicast tree are simply discarded.

Reverse path forwarding allows a data stream to reach all LANs but does not prevent duplicates from occurring entirely, since we use no intelligence on the downstream flooding mechanism. We can extend the technique further by making use of the unicast routing table to control which interfaces to downstream routers are used to flood. If the downstream router, R, is not included in the shortest path tree, then it should not receive multicasts from S. This introduces another potential problem, where multiple equal-cost paths are introduced, but this can be resolved using tie breakers and heuristics, as described later in this chapter. Reverse path forwarding, and its extensions, requires each router to know its shortest path to every source and the shortest path from each neighbor to every source. This information can be recovered from the unicast routing table maintained by IGPs such as RIP, OSPF, and BGP.

Pruning and grafting

Reverse path forwarding ensures that all LANs receive multicasts, but clearly some LANs may not require them. A router attached to a LAN that does not want to receive a particular multicast group can send a prune message to its parent up the shortest path distribution tree, in order to prevent further packets from being transmitted. For example, in Figure 4.3, if group members on Network 7 decide to leave the group or are switched off, then Router-6 can send a prune request up to Router-3. Router-3 will no longer forward multicasts over Network 4 to Router-6 (it must still forward multicasts to Router-5 of course). Prune messages can be associated with a multicast group or with a particular multicast group and a multicast source (in the case where there are multiple senders you could, therefore, decide which sender to register with). In the simple case a router only needs to maintain prune indications on an output interface basis for a whole group. In the latter case a router needs to maintain information on each interface indicating both the group and sender address associations.

The mechanism for adding new branches to the multicast tree is called grafting. If a router receives requests for multicasts (from devices attached to an interface not in the current tree), it can request addition to a multicast tree by sending a graft request to its parent. In our example network (Figure 4.3), if a host on Network 6 decides to rejoin the multicast group, then Router-6 must send a graft request up to Router-3. Note that only one Round-Trip Time (RTT) from the new receiver to the nearest active branch of the tree is required for the new receiver to start receiving traffic.

Expanding ring search

Expanding ring search is a clever technique used to discover resources dynamically. It is used to discover the nearest available resources (e.g., IGMP hosts use this technique to discover the nearest multicast server). The technique exploits the Time to Live (TTL) field of IP, exploiting the following information:

By starting with a TTL of one, and then incrementing the TTL by one at each pass, a sender can perform an expanding ring search for a resource until the nearest listening resource responds. On receiving a response the sender locates the closest resource (in hops). For example, a host can use this technique to locate the nearest available server, printer, or gateway.

4.1.7 Multicast routing protocols

It is important to understand that multicast routing is quite different from unicast routing; the differences are subtle but fundamental. Whereas unicast routing is concerned primarily with the destination of a packet, multicast routing is largely concerned with its source. In a sense multicast routing is backward oriented. IP multicast traffic for a particular source-destination group pair (s, g) is transmitted from the source to multiple receivers via a Spanning Tree, which connects all the hosts in that particular group. This implies that in a large internetwork there could be many overlaid Spanning Trees, one for each group, with each topology dependent upon the location and distribution of multicast sources and recipients. Some protocols also support the concept of shared trees (*, g), where several multicast groups share a common tree. Another subtle difference is that multicast routing is generally much more dynamic compared with unicast routing. Multicast routes and multicast traffic flows depend upon the state of a multicast source and whether nodes wish to receive multicasts at any particular time. Multicast routes may, therefore, appear and disappear as part of normal operations.

There are currently a number of multicast routing protocols available for IP, and each uses different techniques to construct its multicast delivery trees. These protocols generally follow one of two basic approaches, depending on the anticipated distribution of multicast group members throughout the network. They can be described as followed:

Sparse-mode protocols have a number of significant advantages over dense-mode protocols. First, sparse mode offers better scalability, since only routers on the path between a source and a group member must maintain state information. By contrast, dense mode requires state information to be maintained in all routers in the network. Secondly, sparse-mode protocols are much more conservative in their use of network bandwidth, since receivers must explicitly join a group to initiate multicast traffic flow to their particular location. The disadvantages of sparse-mode protocols largely relate to the use of an RP. For example, the RP could prove a single point of failure, either through actual device failure or system overloading (although it is typically possible to deploy RPs in a load-sharing mode). The RP can also become a magnet for multicast traffic leading to nonoptimal paths. Protocols such as PIM—SM solve this problem by switching from a shared tree (*, g) to an optimal shortest path tree for the particular (s, g) multicast pair, once a specified traffic threshold is reached.

All of these multicast routing algorithms and protocols have evolved rapidly over the last few years, and currently there is no absolute winner. This chapter compares and discusses the pertinent features and deployment issues so that useful design choices can be made. We will also investigate strategies for interoperability and discuss some of the new protocols available to support real-time multicast applications.

Related

Категории