14.2 Multicast Characteristics


In Chapter 2 we discussed that IPv4 has three fundamental address types: unicast, broadcast, and multicast. The only difference between a multicast IP packet and a unicast IP packet is the presence of a group address in the IP header destination address field. Multicast addresses use the Class D address format. This chapter is concerned with the technologies that enable multicast to operate effectively. Let's review the purpose of a multicast addresses and operation.

The Multicast Transmission Model is used to move a single packet across the network from one sender to multiple receivers. This differs from broadcasts in that the packet is intended for multiple nodes, but not necessarily every node on the network. These concepts are shown in Figure 14-3. In the figure, traffic flow is moving from the source on the left to a select group of destination hosts on the right.

Figure 14-3. Comparison of Multicasting and Multiple Unicasts

graphics/14fig03.gif

Specifically the server is transmitting to Hosts A, B, and C. Through the use of the multicast model, the server is able to transmit once, and later on the network routers will transmit separately to each host in the multicast group (A, B, and C) as shown in Figure 14-4. This allows for bandwidth and load savings by many devices in the network.

Figure 14-4. Multicast Transmission Model

graphics/14fig04.gif

14.2.1 Multicast Addresses

Multicast addresses utilize addresses out of the IANA reserved Class D range. This range has all addresses with their high-order bits as 1110 , and all addresses are expressed in the dotted decimal notation as 224.0.0.0 239.255.255.255 or 224.0.0.0/4 . Out of the range of possible addresses available, Table 14-1 shows those that have been allocated or reserved. To review the format of IP addresses, refer to Chapter 2.

Table 14-1. Multicast Address Allocations
Address Function/Reservation
224.0.0.0 Reserved for future use
224.0.0.1 All hosts on a subnet used to address all IP multicast hosts on the directly connected network
224.0.0.2 All routers on a subnet
224.0.0.4 All DVMRP (Distance Vector Multicast Routing Protocol) routers
224.0.0.5 All OSPF routers
224.0.0.6 All OSPF DRs
224.0.0.9 All RIPv2 routers
224.0.0.11 Mobile IP Agent Devices
224.0.0.13 All PIM routers
224.0.0.18 VRRP
224.0.0.19 “224.0.0.255 Unassigned
224.0.0.0 and 224.0.0.255 Reserved for routing protocols and other low-level topology discovery or maintenance protocols
224.0.1.1 NTP
224.0.1.2 SGI Dogfight
224.0.1.7 Audio News
224.0.1.11 IETF Audio
224.0.1.12 IETF Video
224.0.13.000 224.0.13.255 Net News
239.0.0.0 239.255.255.255 Administratively scoped addresses

IANA owns a block of Ethernet addresses that in hexadecimal is represented as 00:00:5e . This is the high-order 24 bits of the Ethernet address, meaning that this block includes addresses in the range 00:00:5e:00:00:00 to 00:00:5e:ff:ff:ff . The IANA allocates half of this block for multicast addresses. Given that the first byte of any Ethernet address must be 01 to specify a multicast address, the Ethernet addresses corresponding to IP multicasting are in the range 01:00:5e:00:00:00 to 01:00:5e:7f:ff:ff .

This allocation allows for 23 bits in the Ethernet address to correspond to the IP multicast group ID. The mapping places the low-order 23 bits of the multicast group ID into these 23 bits of the Ethernet address, as shown in Figure 14-5. Because the upper five bits of the multicast address are ignored in this mapping, the resulting address is not unique. It is thus possible to map 32 different multicast group IDs map to each Ethernet address as shown in Figure 14-5.

Figure 14-5. Ethernet Address Allocations for Multicast

graphics/14fig05.gif

Because the mapping is not unique and because the interface card might receive multicast frames in which the host is really not interested, the device driver or IP modules must perform filtering to determine which are destined for it and which are not.

14.2.2 Multicast Functional Overview

In multicast there are some fundamental and general differences between the different solutions that we will be discussing. It is important to understand these issues prior to learning about the specific implementations of the different types of multicasting available. The differences form the foundation of multicast operation and are key learning points. This section will look at some of the functional aspects of multicast routing and how it differs from the routing protocols that we have discussed in previous chapters.

Let's begin by doing an operational comparison between unicast routing and multicasting. Multicast routing differs from unicast routing in several fundamental areas as shown in Table 14-2.

Table 14-2. Comparison Between Unicast and Multicast Routing
Unicast Routing Multicast Routing
Hosts are individuals Hosts are grouped as belonging to a multicast event
Datagram reception is standardized Receiving of datagrams has additional steps
Builds route tables Builds distribution trees
TTL works normally TTL values can have additional uses
Uses a variety of forward route selection methodologies (e.g., link, distance vector, path ) Uses RPF
Many different varieties; OSPF and BGP preferred Two categories: dense and sparse
Routing decisions are based on the destination Routing decisions are based on the source
14.2.2.1 Hosts and Groups

Multicast events allow users to join and participate. When a host decides to join, it becomes part of that multicast group. The use of groups allows the server to transmit once, then have that transmission replicated by routers and delivered wherever there may be hosts in that group. There are no physical restrictions on the location of hosts or the number that can join a multicast group. Plus, a host can be a member of multiple groups at the same time.

Routers use a group membership protocol that enables them to learn about the presence of hosts wishing to join the multicast group on their directly connected networks (e.g., Ethernet segment). The concepts of groups and hosts are shown in Figure 14-6, which shows a network running a multicast routing protocol. This protocol will provide the routing of the multicast transmission, and the next step is to determine which of the potential hosts would like to receive this multicast transmission. Determining host membership is the responsibility of the group membership protocol as it probes the Ethernet listening for requests to join the multicast transmission group.

Figure 14-6. Multicast Routing and Group Membership Protocols

graphics/14fig06.gif

When a host wishes to join a group, it transmits a join request for the group(s) from which it wishes to receive multicast packets. As a part of this process of joining a multicast group, the host's NIC begins to accept additional packets, as we will discuss in the next section.

14.2.2.2 Receiving IP Datagrams

Multicast sends a packet by specifying a group of multicast participants as the destination. This makes sense and is straightforward because we have already discussed how one of the benefits of multicast is its ability to group users together; you know, however, that there is a but coming! But, when a host receives a multicast packet, the process to understand it is a bit more complicated.

Before a host can receive a multicast packet, it must first request to be a part of a multicast group (e.g., "I want to view today's live press conference with the President"). This membership request is sent to the host local router and potentially to others as well. This gets interesting when we recall that for the router to forward the multicast event over the LAN, the MAC address must be known. Multicast, however, is a one-to-many technology, so a new virtual MAC address is created and the hosts on the LAN that have joined the group now listen to their native MAC address and this newly created multicast group MAC address for their LAN. Thus, when the LAN router receives the multicast stream, it forwards the datagrams with the destination address of the multicast group. The receiving host(s) participating in the multicast event will, upon receiving a multicast frame destined for them, read the entire message. They de-encapsulate the frame passing the multicast message up to the TCP/IP protocol stack until the user's application presents the data to the user and he or she can see or hear the company's president speaking or, perhaps, the Super Bowl!

Multicast has been implemented very nicely here in the sense that the LAN router does not track the destination host's MAC address. Recall that in unicast IP, MAC addresses and IP addresses are bound together; this is not so in multicast. Multicast-enabled routers only need to know the list of multicast groups that are on its LAN. Thus, a multicast router attached to an Ethernet segment need associate only a single Ethernet multicast address with each host group having a local participant. This means the router doesn't care who the receivers are, only that a group has one local member on the LAN.

14.2.2.3 Distribution Trees

Referring back for a moment to Figure 14-4, we can see how multiple branches in a tree need to be created to track the flow of multicast packets. This is similar to how IP routing determines path data as well. In multicast this function is handled by the multicast routing protocol in use.

In cases where more than one router is present in a subnetwork, the one physically closer to the source of a multicast message is elected to be in charge of forwarding multicast messages. All other routers will simply discard the multicast messages sent from that source. If there is more than one router on the subnetwork with the same distance from the source, the router with the lowest IP address is elected to forward the multicast. IGMPv2 uses the multicast address of 224.0.0.1 for the entire multicast system to compare the IP addresses on every network; the router with the lowest is elected to be in charge.

14.2.2.4 TTL

The scope (transmission range) of an IP multicast packet can be limited by using the TTL field in the IP header. Each IP multicast packet uses the TTL field of the IP header as a scope-limiting parameter. The TTL field controls the number of hops that an IP multicast packet is allowed to propagate. Each time a router forwards a packet, its TTL is decremented. A multicast packet whose TTL has expired (is 0) is dropped without an error notification to the sender. Table 14-3 lists the conventional TTL values used to limit the scope of multicast packets. This mechanism prevents messages from needless transmission to regions of the worldwide Internet that lie beyond the subnets containing the multicast group members .

Table 14-3. TTL Values for Limiting the Scope of Multicast Packets
TTL Multicast Scoping
Restricted to same host
1 Restricted to same subnet
15 Restricted to same site
63 Restricted to same region
127 Worldwide
191 Worldwide limited bandwidth
255 Unlimited

TTL thresholds in multicast routers prevent datagrams with less than a certain TTL from traversing certain subnets. This can provide a convenient mechanism for confining multicast traffic to within campus or enterprise networks.

Juniper Networks documentation does clearly point out that though this is a viable method of scoping, there have been issues with this type of scoping deployment. Specifically, sometimes shortening the route can result in the multicast information from not reaching a router anymore. Needless to say, each implementation will be different, so keep an eye on this just in case as some features from TTL used in scoping can in fact increase the reliability and stability of the multicast platform.



Juniper Networks Reference Guide. JUNOS Routing, Configuration, and Architecture
Juniper Networks Reference Guide: JUNOS Routing, Configuration, and Architecture: JUNOS Routing, Configuration, and Architecture
ISBN: 0201775921
EAN: 2147483647
Year: 2002
Pages: 176

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net